Mark (a11n)

Hi @jsmo,

I have tested WP Super Cache alongside Autoptimize on my test site, and can’t see any issue with running these plugins together.

The error message “Problem with nonce” is interesting. It can mean a few different things, depending on a number of circumstances. The most likely explanation is that you were viewing a very old cached version of your homepage.

This might happen if you have “Enable caching for all visitors” selected in the WP Super Cache “Advanced” settings, and a very high number under “Cache Timeout” on the same page. Can you please check both of these settings?

Generally, I’d recommend only enabling caching for users who are not logged in.

But the weird part is that you report still seeing that error message after deleting your cache via the wp-admin area. Do you have any other caching tools enabled, which may be caching your homepage?

Can you please try an experiment, to see if it gets past the issue? It’s quick an easy:

1. Visit your homepage, but add “?cache_buster=” followed by a random number to the web address. e.g.: “http://example.com/?cache_buster=12234”
2. Try clicking on the Delete Cache option in the admin bar.

That first step should bypass any caching that may be loading a stale nonce. If that works, try visiting your homepage normally, and checking if the “Delete Cache” button still gives an error.

Hi @dickraney,

Thanks for bearing with us and being willing to experiment.

I can’t see anything in your settings that should prevent supercache files from being created.

As @mikemayhem3030 indicated, your debug log sample shows WP Super Cache serving a pre-built wp-cache file. When a wp-cache file already exists, it won’t re-cache a supercache version. It doesn’t tell us why it didn’t create a super-cache file when caching the page.

I’m sorry to be a bother, but would you mind:

1. Turn debug logging on again,
2. Clearing your cache again,
3. Loading a page on your site as an unauthenticated visitor (e.g.: using a private / incognito window), and finally
4. Post the logs from that pageload?

That should show us a sample of WP Super Cache caching your file anew. That will hopefully give us insight into why you aren’t getting any supercache files.

Jetpack Boost’s “Optimize CSS Loading” feature and Autoptimize’s “Critical CSS” feature both do the same thing; they both move the most important CSS styles to the top of your page’s HTML code to make them render faster.

There is no benefit to running both of these features on the same site – and in fact they can cause issues with each other. We recommend disabling the Critical CSS feature in one of these plugins.

Jetpack Boost can generate Critical CSS for your site for free, without needing an external API key. It does so using a process which runs inside your WordPress site’s admin dashboard.

You also mentioned that Jetpack is unable to use the Critical CSS feature when Autoptimize is deactivated? Can you please tell me more about what happens there? Does it show an error message when you try to use it?

Hi there!

Thanks for taking the time to try to debug the issue, and sending in your site URL via our support forms.

The error messages “Blocked script execution” are expected behavior, and don’t indicate that anything has gone wrong. Jetpack Boost uses an invisible iframe with strict security settings while generating Critical CSS, and some browsers report everything the iframe settings block as errors in the console. It’s noise I wish we could eliminate, but browser security rules don’t allow that.

The Jetpack Boost UI uses WordPress’ JSON API to talk to the server – but by the time you see “Blocked script execution” messages in your console, it has already successfully spoken to the server – so it seems unlikely to be an issue with server communications. I doubt this is an issue with your XMLRPC settings.

The IP address you’ve seen on other forum threads is out of date now. Early versions of Jetpack Boost used a callback mechanism when generating Speed Scores, which required some users to allow-list our IP address. But due to problems we have changed the way speed scores are returned to sites, eliminating the need to allow that IP address.

I’ve taken a look at your site, and I can’t see anything there which should break our Critical CSS Generator.

Can I ask you some more questions about the way it fails?

Does the Jetpack Boost dashboard show an error at the end of the generation process? It should appear in red text below the Critical CSS toggle. If so, can you please let me know what it says there?

If it doesn’t show anything useful there, it may be worth scrolling to the bottom of your browser’s console to see if there is an error generated at the end of the process which doesn’t say “Blocked script execution” – in case that sheds some light on what has gone wrong.

Finally, can I please ask which browser you are using while generating Critical CSS for your site? I do test our plugin in a variety of browsers, but you never know – it may turn out to be something we hadn’t thought of before.

Thanks for bearing with us, I hope we can get this sorted out.

— Mark George
Jetpack Boost developer

Hi again!

Thanks for writing in. I’m sorry to hear that you’ve had more trouble. On the bright side, you keep on bringing us interesting puzzles to solve. 🙂

TBT is a complicated metric, which can be affected by a lot of different things. It measures the total time your browser spends “blocked” by long tasks – i.e.: tasks which take longer than 50ms. It’s linked to your TTI score.

When you found your TBT score was worsened, did you find that your TTI score was affected, too?

As for your questions:

1. I do have one theory as to how Boost could increase your site’s TBT: When Jetpack Boost has Critical CSS enabled, it forces your main CSS files to lazy-load by altering their media type until they have finished loading. As each finishes loading, it re-enables them – which may cause your browser to reconsider your page’s CSS rules. Each event may contribute towards a TBT score – especially if you have a lot of separate CSS files. We are currently researching ways to make the transition from Critical CSS to main CSS “smoother” to reduce side-effects.

2. Jetpack Boost stores your Critical CSS in your posts table – as a custom post type called “jb_store_css”. It’s stored in the post_content field – in a serialized string which has been base64-encoded. You could extract it either using PHP (using base64_decode, then unserialize), or using MySQL (using FROM_BASE64 – and then manually extracting the string from the serialized object).

If you do follow up with your experiment from question 2, I would be very interested to hear the results. If you find that a particular HTML setup avoids extra TBT time then I would be keen to hear about it.

Hi there,

Thanks for writing in. I’ve taken a look at your site, and hopefully I can help.

I normally add font preloads via wp_head hook in functions.php with a priority 1.

Our wp_head hook uses a priority of 0 because we generally want to get in first. Technically WordPress supports negative priorities, so you can use a hook with -1 to force yours to run first.

I’ve looked at the waterfalls it appears the font swap is still occuring. Even with fonts stored locally in WOFF2 with preload and @font-face occuring before jetpack critical CSS.

The problem appears to be the “font-display” property in your @font-face blocks. Your font blocks specify “font-display: swap”.

This tells the browser to display your site using alternate fonts first, then swap with your preferred fonts once they have finished loading. If you switch that to either “fallback” (i.e.: block for up to 100ms then show your fallback fonts), or “block” (i.e.: do not render text until your font has finished loading), it should prevent the flash of incorrect fonts from showing.

• This reply was modified 4 years, 10 months ago by Mark (a11n).

Hi again Chas,

Thanks for writing in with your experiment results.

I’ve done some research, and I think I may be onto the problem. I think that our “Optimize CSS Loading” feature is not compatible with WPtouch.

Most sites adapt to mobile devices without altering the main page content – by using “responsive” style rules. However, it looks like WPtouch serves up different HTML page content for mobile vs. desktop browsers (most likely based on the user-agent header).

The WPtouch documentation includes a page on how to configure various caching plugins to work around their approach. Unfortunately, at this stage there is no way to configure Jetpack Boost to make the same accommodation when generating Critical CSS (for the “Optimize CSS Loading” feature).

When generating Critical CSS for your site, Jetpack Boost does not alter your browser’s user-agent headers – and so it will not trigger WPtouch’s alternate HTML view for mobile devices. As a result, your Critical CSS will only take the “desktop” version of your site into account.

We will investigate ways we can work around this kind of issue in future versions of Jetpack Boost.

In the meantime, it seems that our “Optimize CSS Loading” feature may not be compatible with WPtouch.

It may be possible to work around the issue by generating your Critical CSS from a mobile device (i.e.: visiting wp-admin on your phone and following the usual procedure to generate Critical CSS). However, as that will only consider the “mobile” version of your page, it may similarly impact the performance of your site on desktops.

Otherwise, I recommend leaving the “Optimize CSS Loading” feature off for now – and keeping an eye on future Jetpack Boost releases which may offer solutions to this problem.

Cheers
— Mark

• This reply was modified 4 years, 10 months ago by Mark (a11n).