Improve speed of HTML processing

[danielroe]

We've been getting reports of performance hits when using critters for per-request inlining of styles using SSR. See for example:

• some kind of cache? nuxt-modules/critters#21
• Global styles are included in the bundle nuxt/nuxt#8569 (comment)
• Css optimizations vercel/next.js#16539 (comment)

What do you think? Should we be restricting critters to the initial static generation rather than running per-request?

EDIT: updated with reproduction repository: https://github.com/danielroe/critters-test

[alan-agius4]

We also seen this in Angular SSR angular/universal#2106

[developit]

IIRC @janicklas-ralph has done some experimenting to improve performance for this use-case. It's a trade-off though, and any caching would need to be controllable by the caller.

[freddy38510]

@developit , @alan-agius4 , @danielroe

I successfully made a fork of Critters and implemented dropcss to prune not used CSS rules (keeping keyframes and fonts Critters features).

To parse and process stylesheets (preload strategy, merge stylesheets, etc) i'm using node-html-parser. I found it faster than parse5 to parse and serialize html. This is just a little gain of speed.

The overall result is a huge speed improvement mainly thanks to dropcss. I didn't do proper benchmarks but i would say this is around 10x faster.

The only drawback is that html and css parsers from dropcss are very sensible. Only valid html and css inputs could be processed.

I didn't push my locals commits to the forked repository yet. I will do it later and let you know if some of you are interested.

It also opens the possibility to prune external stylesheets from multiple Critters runs with the same (or not) instance.
This is possible thanks to the whitelist technique from dropcss.

[amakhrov]

@freddy38510 any news on that? do you have your changes available anywhere? i'd love to try it on our project and see if it solves the performance issues

[freddy38510]

@amakhrov,

I ended up creating a new project called beastcss because the code was very different from Critters.

You can make a try and open new issues if you find some bugs or for asking new features. And please, i'll be glad if you let me know about the performance improvement :)

[amakhrov]

I'm seeing 4x-5x faster processing on our typical html page after switching to dropcss-based approach.
It's definitely a great boost - but still not sufficient for enabling it in production for us (with Angular Universal).

EDIT: actually, 10x using beastcss with caching of parsed stylesheets

[freddy38510]

@amakhrov ,

I came to this solution under a different context than yours. I'm using a Static Site Generator for Quasar with SSR pre-rendering. Also, i didn't test beastcss with html that contains a lot of DOM nodes.

Did you measure the duration of the overall processing ? What would be the maximum acceptable duration for your use-case ?

[amakhrov]

Great question. So when we tried to enable inlineCritical on prod with Angular last time, we got around 500-600ms overhead of pure computations, and it was just too much, we started dropping requests.
Frankly I'm not sure how much lower it needs to be for our case - will have to try and see, I guess.
10x improvement (with beastcss) sounds like it should do the trick.

[brjadams]

@amakhrov did beastcss do the trick? How did you go about implementing this in Angular with SSR?

[amakhrov]

@brjadams we didn't move on with it, and just turned off inline critical CSS in the meantime

[janicklas-ralph]

I've made some changes in v0.0.19 to help with improving the speed of processing. It's a combination of adding a cache and also some user intervention. Please try this version out and let me know if it helps