Performance hack seen on a customer site; fix the bad LCP (due to an animation in revslider) by loading an inline (base64’ed) png image which according to FF is broken and later in the rendering process hiding & removing it.
Even though that image is not *really* used, tools such as Google Pagespeed Insights pick it up as the LCP image and the score is “in the green”.
Not sure this is really helping performance (spoiler: it’s not), but Pagespeed is happy and so is the customer. Crazy!
It’s been 2 years since AOPro was launched and a lot has happened in that time; bugs were squashed, improvements were made and some great features were added. Taking that into account on one hand and increasing costs from suppliers on the other: prices will see a smallish increase as from 2025 (exact amounts still to be determined)
But rest assured; if you already signed up, you will continue to pay the lower price, also when renewing. Same if you sign up before the end of the year too by the way, so if you’re considering switching on Autoptimize’s Pro features, now might be the moment! 🙂
Whatever you do, if you’re an Autoptimize users or not, if you’re an AOPro customer or not, have a great end of year! Peace and love to you and your loved ones, whomever you may be!
I just reviewed the performance of a customer’s WordPress site. Things got a lot worse he wrote and he assumed Autoptimize (he was a AOPro user) wasn’t working any more and asked me to guide him to fix the issue.
Instead it turns out he installed CookieYes, which adds tons of JS (part of which is render-blocking), taking 3.5s of main thread work and (fasten your seat-belts) which somehow seems to increase DOM size to over 60K elements in this case.
I knew cookie consent solutions can have a performance impact, but this? Thanks but no thanks!
So I like and use Spectra (aka “ultimate addons for gutenberg”) on some of my WordPress sites.
If you use Spectra as well, you might want to be know that Spectra 2.12 has a significant performance regression, sucking in almost all of wp-includes/js/dist.
Here’s hoping this was not intentional and that it’ll get fixed soon 🙂
More info in https://wordpress.org/support/topic/2-12-significant-performance-regression/
Update Feb. 15th: the regression is due to the new AI features, as a workaround go to Spectra -> AI features -> Manage AI features and disable “AI Assitant” (and “AI Copilot” if you don’t need/ want that either).
As of Autoptimize Pro 2.3 there is an option to delay all JavaScript. Delaying can have a bigger positive performance impact then asyncing or deferring because AOPro will only load the delayed JS after a to be defined delay or (better even) only at the moment user interaction (such as swiping/ scrolling or mouse movement) is noticed.
Obviously when delaying all JS you might want to be able to exclude and that is possible as well; you might want add data-cfasync there for example as contrary to Autoptimize’s normal behavior for deferring, delaying ignores attributes like data-cfasync, meaning that if you want to leave such JS untouched you will have to add it to the exclusion list yourself.
Lastly; if your site’s above the content depends on JavaScript to render correctly (which has serious performance impacts), delaying all JS would result in the page not rendered entirely, so test and exclude as required.
I released AOPro 2.2 today and the main new feature is the ability to delay the loading/ rendering of iFrames. Despite the fact iFrames can be lazy-loaded (using browser-native loading=lazy attribute), in reality this does not always work in WordPress, hence the new “delay iFrames” option on the Pro Boosters tab.
Apart from delaying iFrames, AOPro 2.2 also has;
none in the “Autoptimize this page” metabox. If you leave the field empty the default “removals” apply. If you put something else in there then that overrides the default removals.Ever since the advent of HTTP/2 people asked if they still needed JS/ CSS files to be combined and indeed by default aggregation is off in Autoptimize. But based on this interesting article by Harry Roberts, “bundling is here to stay for a while”. So when in doubt; test performance with and without aggregating CSS/ JS ideally both on mobile and desktop bandwidth profiles and learn which works best for your site! 🙂
WordPress has made some good progress to speed up site rendering the last couple of years and part of this is thanks to images and iframes having the “loading” attribute with value “lazy”, telling browsers these can be loaded later allowing other (more important) assets to take priority. Especially iframes can consume a lot of bandwidth (think embedded Google Maps or one or more YouTube videos), so the performance impact of lazyloading those can be very significant.
Unfortunately one cannot always rely on WordPress core to automatically make sure there is no performance penalty from stuffing your site with iframes. Here is a non-exhaustive list of when iframes will still delay your site:
loading="lazy" attribute;loading="eager" is set (which means load asap)loading="lazy" is setloading="lazy" is setConclusion; show restraint when adding iframes; adding an image of Google Maps which links to (a separate page with) Google Maps is almost always as informative and the performance benefit of using an image instead of an GMaps iframe is huge. And when using iframes then consider using alternative solutions to avoid the performance impact (for YouTube you might want to give WP YouTube Lyte a try).
There’s a first for everything and so last week I did a presentation at a WordPress Meetup in Antwerp titled “Autoptimize: 5 secrets and an intermezzo” which at least I had fun with.
You can find a PDF export of the presentation here.
Questions go below, in the comments (or in the form on the contact page).
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.