magento2: Critical CSS blocks interactivity, shows broken image, causes jank in Luma
Preconditions (*)
Magento >2.3.4 Magento 2.4-develop
Steps to reproduce (*)
- With Luma active on Magento >2.3.4, enable Critical CSS:
bin/magento config:set dev/css/use_css_critical_path 1
Expected result (*)
- Inlined styles produces believable reproduction of site until full styles are loaded in
- Site remains somewhat interactive during loading process
- Luma critical CSS is best in class to give developers an excellent reference point
Actual result (*)
- Mandatory loader mask completely blocks interaction with site until stylesheets are loaded in, negating much of the benefits to having critical CSS
- Loader mask spinner is an image, which is a lower resource priority than the preloaded CSS. Therefore, during the time in which critical CSS could be seen, the user sees a half-built site with a gray overlay preventing clicks, and a broken image reference placed at the top of the screen
- Finally, Luma’s critical CSS, far from being best in class, is fundamentally too different from the final site to be of benefit. It actually introduces jank, rather than reducing it.
- The biggest example right now is that the inlined styles are using browser font defaults, causing the sans-serif theme to first render in Times New Roman.
- Since we’re now exposed to the header before images have even loaded, the Luma logo should be moved to an SVG so that it’s a part of the DOM and thus available for critical styles
- Some – any – PageBuilder styles would be great here. As it stands, CMS pages render on critical styles as just blobs of alt text strung together.
All told, here is what the default critical CSS experience on Magento 2.3.5’s Luma looks like:
Compare to the final loaded result:
Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 2
- Comments: 22 (15 by maintainers)
@mrtuvn depends on the site. For this issue, I’d recommend staying in the 15-50kb range, however. Increasing every page’s document size by 300kb will cause Luma’s First Contentful Paint time to increase significantly.
Yes, there are other things that could be moved off the critical path. That doesn’t mean that critical CSS is pointless though, and, besides, this issue is about the fact that the critical CSS in Luma is not good. This repo should have an example of a really well-made critical CSS file.
@roman-mer sure - we’re using Azure to handle deployments. We built a Penthouse node script that runs during the deployment that crawls through a headless Chrome instance and visits a specified number of URLs (homepage, PDP, etc). We then have some Regex that removes selectors that match to reduce the overall size. And finally, we have some manual CSS that is appended to it, which then produces a single critical.css file. It’s very much in alpha state (and proprietary) so no code to share, sadly.
Can you share your Penthouse setup in Magento 2?
Please note that critical.css file probably should contain critical css both for mobile, tablet and desktop, otherwise it will be too jumpy during page load
Here is my infor related with this problem. Which mean css critical need extra effort workaround (not well-written). Probably we miss some styles critical at the point of view FE, need for early stage above the fold Now i realised why we don’t have critical default for blank theme 😃 Leave it’s responsibility for FE devs