The last two chapters of the 2022 Web Almanac were released this week, they were Structured Data and Performance, completing the 729-page ebook of the report. The WordPress-specific chapter was published earlier this month with metrics that indicate adoption is continuing it’s trend of growing year over year.
The Performance chapter was written by Etsy performance engineer Melissa Ada and Google web transparency engineer Rick Viscomi. Performance metrics in the chapter focus on the Core Web Vitals (CWV), which Google introduced in 2020 and then made into a ranking signal in 2021. They used the public Chrome UX Report (CrUX) dataset for the report, which collects data from eligible websites, that are publicly discoverable with an undisclosed minimum number of visitors.
Most of the data concerns the performance of the web as a whole over time, but the 2022 Web Almanac has highlighted one specific concern regarding WordPress sites’ use of lazy-loading and its impact on LCP performance. Google defines Largest Contentful Paint metric (LCP) metrics as “the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.”
Lazy-loading is a good thing when used correctly, but these stats strongly suggest that there’s a major opportunity to improve performance by removing this functionality from LCP images in particular.
WordPress was one of the pioneers of native lazy-loading adoption, and between versions 5.5 and 5.9, it didn’t actually omit the attribute from LCP candidates. So let’s explore the extent to which WordPress is still contributing to this anti-pattern.
According to the CMS chapter, WordPress is used by 35% of pages. So it’s surprising to see that 72% of pages that use native lazy-loading on their LCP image are using WordPress, given that a fix has been available since January 2022 in version 5.9. One theory that needs more investigation is that plugins may be circumventing the safeguards built into WordPress core by injecting LCP images onto the page with the lazy-loading behavior.
Similarly, a disproportionately high percentage of pages that use custom lazy-loading are built with WordPress at 54%. This hints at a wider issue in the WordPress ecosystem about lazy-loading overuse. Rather than being a fixable bug localized to WordPress core, there may be hundreds or thousands of separate themes and plugins contributing to this anti-pattern.
2022 Web Almanac – Chapter 12: Performance
Prior to the WordPress 5.9 update, WordPress’ default of lazy loading implementation was causing slower LCP performance, because it had been applied too aggressively and was lazy-loading images above the fold, which is not needed. In 5.9, WordPress shipped a fix that more eagerly loads images within the initial viewport while lazy-loading the rest as they come into view. That’s why results that show WordPress sites overusing lazy-loading are surprising to see.
“Admittedly, ‘lazy-overloading’ a hard problem to solve. We don’t always know whether an image will be the LCP. WordPress core sets it on every image by default and uses heuristics to unset it. Nearly 3/4 of pages that natively lazy-load images are on WordPress.”
Rick Viscomi said in his Twitter thread analysis.
In 2020, Viscomi commented on how quickly the adoption of native image lazy-loading shot up after the WordPress 5.5 update was released in August of that year with images then being lazy-loaded by default. WordPress has been driving adoption of this feature, which is why any implementation “anti-pattern,” as Viscomi characterized it, has an outsized effect on the performance of the web.
As of October, 10.6% of the web is using native image lazy loading, per @HTTPArchive. That number was 1.5% in July! 🤯
— Rick Viscomi (@rick_viscomi) December 30, 2020
This appears to be _entirely_ driven by WordPress at 28.9% of WP pages, which makes up one third of the web.https://t.co/QYGyyctFgc
left: all web
right: WP pic.twitter.com/RQnDw4UZ56
“What gives, WordPress? My theory is that it’s not the core heuristics that are wrong, it’s the plugins. Also, keep in mind that the majority of pages that even use lazy-loading are WP. To support the plugin theory, let’s look at custom lazy-loading of LCP: More than half of the pages that do it are built with WordPress. WordPress is ‘only’ a third of the web, so there’s clearly something going on with JS-based lazy-overloading in WP.”
Rick Viscomi
On WordPress.org there are multiple pages of performance, caching, and image and video optimization plugins that are using lazy-loading in some form or another. Plugin and theme developers who are using lazy-loading in their extensions may want to test their implementations to see if they are having a negative impact on LCP performance on the sites that are using them.
Leave a Reply