The final two chapters of the 2022 Yearbook of the Web – Structured Data and Performance – were published this week, completing the 729-page report ebook. The WordPress-specific chapter was released earlier this month, and its metrics show that adoption is growing.
The performance chapter was written by Etsy Performance Engineer Melissa Ada and Google Web Transparency Engineer Rick Viscomi. The performance metrics in this chapter focus on Core Web Vitals (CWV), which Google launched in 2020 and signaled rankings in 2021. They report using the public Chrome UX Reports (CrUX) dataset, which collects data from eligible sites – publicly discoverable sites with an undisclosed minimum number of visitors.
Most of the data is related to the performance of the entire web, but the 2022 Web Almanac highlighted a specific issue with WordPress sites using lazy loading and its impact on LCP performance. Google defines the Largest Content Paint Metric (LCP) metric as “the rendering time of the largest image or block of text visible in the viewport, relative to the time the page first starts to load”.
Proper use of lazy loading is a good thing, but these statistics strongly suggest that performance can be improved by removing this feature from LCP images.
WordPress was one of the pioneers in adopting native lazy loading, and between versions 5.5 and 5.9, it didn’t actually omit the attribute from LCP candidates. So let’s explore how much WordPress still contributes to this anti-pattern.
According to the CMS chapter, 35% of pages use WordPress. So surprisingly, 72% of pages that use native lazy loading on their LCP images are using WordPress, given that fixes have been available since January 2022, version 5.9. One theory that needs more investigation is that plugins may be bypassing protections built into WordPress core by injecting LCP images into pages with lazy loading behavior.
Likewise, 54% of pages using custom lazy loading were built using WordPress. This hints at a wider problem with lazy loading overuse in the WordPress ecosystem. There are probably hundreds or thousands of individual themes and plugins contributing to this anti-pattern rather than a fixable bug localized to the WordPress core.
Network Yearbook 2022 – Chapter 12: Performance
Prior to WordPress 5.9, WordPress’ default lazy-loading implementation caused slow LCP performance because it was applied too aggressively and lazy-loaded above-the-fold images. In 5.9, WordPress released a fix that loads images more eagerly in the initial viewport while lazy loading the rest. That’s why it’s surprising to see results showing a WordPress site overusing lazy loading.
“Admittedly, ‘lazy overloading’ is a difficult problem to solve,” Viscomi said in his Twitter thread analysis. “We don’t always know if an image is going to be an LCP. WordPress core sets it on every image by default and uses heuristics to cancel it. Nearly 3/4 of all native lazy-loading image pages are on WordPress.”
In 2020, Viscomi commented that the adoption of native image lazy loading increased rapidly after WordPress 5.5 was released in August of that year, and images are lazy loaded by default. WordPress has been driving the adoption of this feature, which is why any implementation of an “anti-pattern” (as Viscomi describes it) can have a huge impact on web performance.
“What gives, WordPress?” Vescomi said. “My theory is that it’s not the core heuristic that’s wrong, it’s the plugin. Also, keep in mind that most pages that even use lazy loading are WP.
“To support plugin theory, let’s look at LCP’s custom lazy loading: over half of the pages are built with WordPress. WordPress is only a third of the web, so obviously some JS-based lazy reloading in WP happens matter.”
There are several performance, caching, and image and video optimization plugin pages on WordPress.org that use lazy loading in some way. Plugin and theme developers who use lazy loading in their extensions may want to test their implementations to see if they negatively impact LCP performance.