I've attached an image and profile logs to show output - I believe this confirms Chrome is the bottleneck.

Yes, it is.

are there any specific pitfalls to avoid when it comes to using a table?

The long tables are typically slowing chrome rendering, but honestly, chrome is for us black-box just like for you, so I don't know how to trick this.

Thanks for all you do!

You are welcome. I'm sorry I'm not helpful here. Good luck!

You need to specify a proper relative or absolute path. Because now the asset is searched in the same folder as the template.

Like

await jsreport.assets.registerHelpers('/Aika/f***s/helpers/myHelpers.js')
or
await jsreport.assets.registerHelpers('../../f***s/helpers/myHelpers.js')`

Did you check in logs or v3 profile that the Chrome execution is really the main bottleneck?

Do we talk about one main template without additional extra pdf utils template merges?

Don't you use high-resolution images with the sizing problems mentioned here?
https://jsreport.net/learn/chrome-pdf#images-increasing-pdf-size

To assure the aria is really hidden, please open the output pdf with Notepad and search for the text "/StructTreeRoot". You shouldn't find it there.

However, I am afraid it can easily happen phantom is faster than Chrome. Our invoice example is also a bit faster with Phantom. Phantom is more lightweight and doesn't need to care about many modern things Chrome does. You may try to play with CSS and HTML. Chrome is slower on long <table> or some specific style combinations, but there is no rule of thumb. You may try to remove styles one by one to identify the problematic parts, but it may as well end up without success.

Some arguments for migration even with higher rendering times:

• phantomjs supports just old js/css which was used a decade ago
• phantomjs is a potential security weakness, there are no security updates for many years
• phantomjs may not work with future OS updates, it already breaks on https connections since Ubuntu Beawer which was released in 2018. (can be solved with implementing explicit proxying requests so far)

Please check the following

https://jsreport.net/learn/pdf-utils#grouping-pages
https://playground.jsreport.net/w/admin/Wy6stA8t

https://jsreport.net/learn/pdf-utils#adding-items-to-the-page
https://playground.jsreport.net/w/admin/ihh7laK2

There is no other way to speed it up.
If you split one template into 3. jsreport needs to do the whole pipeline 3x. Chrome also needs to parse scripts, build DOM and print pdf 3 times so of course it will be slower than if you do all of this just once.

here no of workers is 13 but still it takes time why?

See the description of workers.numberOfWorkers in the docs
https://jsreport.net/learn/configuration#workers

The chrome.numberOfWorkers should be in the root of the config.

Excellent! Long-time users are the best appreciation for us.Thank you

Yes, it can be done like this just by batching the data into slides
https://playground.jsreport.net/w/anon/XOUtPyY6

So rendering each template takes approximately 4 seconds so total 3x4 = 12 and from beforerender to reach afterrender of main template takes 2 second

Why do you render those templates one by one, why don't you render them in parallel using Promise.all or something like that? Note in this case it's better to increase the chrome workers to the number of templates you render inside the script. https://jsreport.net/learn/chrome-pdf#chrome-process-allocation

In general, you typically render TOC twice. The first time so it consumes the appropriate place and render headings and styles. The second time you render it again, but this time just with page numbers and merge it into the main template. Like here
https://playground.jsreport.net/w/admin/akYBA4rS
https://jsreport.net/learn/pdf-utils#toc-table-of-contents
This means that the dots should be hidden by you the second time and invisible.
Anyway, please share MINIMAL playground demo so we can take a look.