• Resolved mikka23

    (@mikka23)


    Hi,

    The plugin looks very promising but I have various questions. Hopefully somebody can provide some information.

    1. Under the hood what is being used to generate the critical CSS? I’ve tested a few different packages and I would be interested to know how that is currently working. It will also help me understand how changing the viewport + user agent of the request might be done.

    2. Related to the above, how is the CSS read/passed on while it is generating the critical CSS? During my tests it seems like sometimes the full CSS is not being read when generating the critical path, which results in the critical CSS being very small/unrepresentative and therefore results in large CLS. Especially true if the styles are being loaded in page rather than in a separate CSS file.

    3. Are there any usage limits/rate limiting?

    4. I am seeing what looks like some problems with icon CSS in critical. For example:

    content:\"\\e906\"

    Thanks

    • This topic was modified 3 years, 7 months ago by mikka23.
    • This topic was modified 3 years, 7 months ago by mikka23.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Mark (a11n)

    (@thingalon)

    Hi @mikka23. Thanks for your interest in Jetpack Boost!

    1. Under the hood what is being used to generate the critical CSS? I’ve tested a few different packages and I would be interested to know how that is currently working.

    Jetpack Boost uses its own custom-built Critical CSS generator. We considered pre-existing libraries for the task, but couldn’t find any that supported all the features we needed.

    It will also help me understand how changing the viewport + user agent of the request might be done.

    Jetpack Boost generates Critical CSS using three pre-defined viewport sizes; the most common mobile, tablet and desktop screen sizes. At the moment, there isn’t any official support for configuring it to use different screen sizes. However, if there is demand for it, we could add a filter to allow users to override its viewport sizes.

    Our Critical CSS generator uses an invisible iframe in your wp-admin area to render your site at various viewport sizes. The user-agent string is supplied automatically by your browser, and I’m not aware of any reliable way to override that.

    2. Related to the above, how is the CSS read/passed on while it is generating the critical CSS? During my tests it seems like sometimes the full CSS is not being read when generating the critical path, which results in the critical CSS being very small/unrepresentative and therefore results in large CLS. Especially true if the styles are being loaded in page rather than in a separate CSS file.

    Our Critical CSS generator doesn’t include inline styles. Its goal is to find the most important CSS rules for rendering your “above-fold” content in external CSS files, and bring them inline – so that your browser can render your page as quickly as possible.

    I would be happy to investigate any case where our Critical CSS generator fails to find important rules in external CSS files. If you do find such cases, please let me know the URL where the issue occurs so that I can check it out.

    3. Are there any usage limits/rate limiting?

    There are no usage limits on our Critical CSS generator. It runs wholly in your browser, so you can run it as frequently as you need to.

    I am seeing what looks like some problems with icon CSS in critical. For example:

    Would you mind sending me the URL where you have seen this issue, so that I can take a look?

    Thread Starter mikka23

    (@mikka23)

    Hi,

    Thanks for the information. I didn’t even realise it was possible to do that in the browser, so that explains a lot of my misunderstanding!

    For the icon aspect, it seems that is no longer an issue, rather the issue is just that the src appears to be stripped from the font-face declaration. Is that intentional?

    Something new I am now seeing is that CSS seems to be repeated in the critical CSS, which also varies depending on the page type which is a bit strange. For example, homepage appears mostly okay, just 1 copy. Sub-page I am seeing the same CSS 4x. Single post 2x, category 2x.

    To add some context, I am currently testing this for a particular theme to see if this is a viable solution to recommend to our user base. Part of the issue likely comes from the fact the CSS is unique per page and generated on first page load. With the duplication aspect I imagine this is coming from the small, medium and large viewport emulation you mentioned. So likely won’t be a core bug in the plugin but a combination of factors.

    If you would like access to a test site I can provide that but would rather not provide on a public platform.

    Thanks

    • This reply was modified 3 years, 6 months ago by mikka23.
    Anonymous User 18700194

    (@anonymized-18700194)

    You can send the URL to [email protected] and we can take a look.

    Please reference this forum thread in your email.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Critical CSS Generation Questions’ is closed to new replies.