Thanks for getting back so quick, these answers have been very good to understand what's the potential ways of achieving what i was looking for

What i meant is that loading in beforeRender, we are appending the head asset content before the actual template content, right? If we have nested components, beforeRender will not only be invoked on the parent template but also on the children. What I'm trying to see is a way to avoid some templates of ours that render hundreds of templates and avoid that each one of them includes the head or any sharable asset. Does this make sense what I'm describing?

If we have nested components, is this going to repeat the import? I'm just worried on having multiple times, probably with the solution that you've provided to simply avoid multiple imports, it should do the trick if we use the same approach here, right? (something that checks whether the head has been added and if so just skip since the head will be available for the whole report?)

I haven't tried it yet but the need for this request was based on having a "head" asset globally available and not having to load on each template, we do have standalone components/templates, and when developing we often end up importing them and it's just an extra boilerplate that I'm trying to avoid.
The idea would be to have a beforeRender invoking the custom load asset that you've provided but even so, is there any impact on performance using beforeRender to import assets?

Neat, thank you @jan_blaha

Is there a way to make sure an asset is only loaded once? Currently, if i import a CSS asset in multiple components, once they are building I noticed they are inserted in the DOM multiple times and it would be great avoiding repeated imports (of any kind of asset)

Currently, I'm migrating "components" that are essentially sections in the old v2 format but some require tailwind or some assets. Is there any way that at least we can ensure tailwind is present in the components? I'm not sure if using beforeRender in a global script would eventually make it available

That makes sense, thanks for the quick answers
I'll definitely try beforeRender and possibly post something here to help the others that are probably facing the same questions of mine

Thanks for getting back to me so fast.
You mentioned that chrome HTML to pdf is not exactly "fast", what are the recommendations to speed it up when we have multiple components per sections and those components are kinda complex?

Another question of mine is basically what's actually faster, external resources vs local resources (CSS, js scripts, images)
I was curious about how the images are loaded when its a local file:

• If I request the same file twice, is it cached already, or will it always read directly from the disk?
• If we have multiple images, is the loading parallelized?

The questions regarding resources is that within a section that i have, we can generate hundredths of components and often they repeat the same icon multiple times, I'm trying to understand if that's something that JSReport optimizes for us

I've been using JSReport for a while and something that I'm curious about (whether it is an opt-in config value or just by default) is a way to cache section/components artifacts.
A practical example would be:
Given a report that is composed of 3 sections(or components, not sure of the actual term), if only 1 section (data/dependencies) changes, I would want that the other 2 unchanged sections/component's final output/artifact is cached(or memoized) and it would just hydrate the changed piece and probably speed up the time it takes to generate.

Not sure if the example above describes really well what I'm trying to achieve/request here but I'm trying to figure out ways to speed up the pdf generation