New booster in Autoptimize Pro 1.3: instant.page, a 3rd party JS component that can significantly improve performance for visitors going from one page to another on your site by preloading a page based on visitor behavior.
Do take into account that it could increase the number of page requests as the preloaded page might end up not being requested after all.
Critical CSS (either through Autoptimize with your own Critical CSS account or through Autoptimize Pro which includes Critical CSS) requires WordPress’ scheduling system to function to be able to communicate with criticalcss.com on a regular basis. In some cases this does not work and you might see this notification in your WordPress dashboard;
It looks like there might be a problem with WordPress cron (task scheduling)
If this is the case, go through these steps to troubleshoot:
install the “WP Crontrol“-plugin and go to Tools -> Cron Events
WP Crontrol will warn if “cron” (another name for job scheduling) is disabled
Look for “ao_ccss_queue” and check the “next run” time/ date.
Setting the delay to 0 is a bit shady because at that point you are hiding those assets for performance tests which -although artificial- is likely to improve (lab test) performance scores. If you do use the 0s delay then do take into account that *real* users will still need to load/ render those assets and that that still may be a sub-optimal experience.
Mastodon due to the decentralized nature can result in a significant extra load on your site if someone posts a link to it. Every Mastodon instance where the post is seen (which can be 1 but also 100 or 1000 or …) will request not only the page and sub-sequentially the oEmbed json object to be able to show a preview in Mastodon. The page requests should not an issue as you surely have page caching, but the oEmbed object lives behind /wp-json/ and as such is not cached by page caches. The solution; the WP Rest Cache plugin and one small code snippet (for now). A lot more info can be found in Donncha’s excellent post on the subject.