-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve speed of HTML processing #78
Comments
We also seen this in Angular SSR angular/universal#2106 |
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. |
@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 The only drawback is that html and css parsers from 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. |
@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 |
I'm seeing 4x-5x faster processing on our typical html page after switching to dropcss-based approach. EDIT: actually, 10x using |
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 ? |
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. |
@amakhrov did beastcss do the trick? How did you go about implementing this in Angular with SSR? |
@brjadams we didn't move on with it, and just turned off inline critical CSS in the meantime |
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 |
We've been getting reports of performance hits when using critters for per-request inlining of styles using SSR. See for example:
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
The text was updated successfully, but these errors were encountered: