In August 2026, fewer than one WordPress site in two passed Core Web Vitals on mobile, according to Chrome UX Report data compiled by HTTP Archive. The web as a whole did slightly better. Above all, on mobile, only about one WordPress site in four answered fast enough with its first byte, against nearly one in two across the web as a whole.
That figure shows where the problem lies. WordPress is not slow to respond to clicks: on that front, it does better than average. It is slow to load, first on the server side, then on the page’s main image. The fixes below are ranked in that order.
Our selection of speed plugins already exists; this list gathers fixes, each tied to the metric it improves, to what WordPress already does on its own, and to the way you check the result.
The three thresholds and what Google does with them
Core Web Vitals are three measures of real visitors’ experience. LCP (Largest Contentful Paint) measures how long the largest visible element takes to render: good under 2.5 seconds, poor above 4. INP (Interaction to Next Paint) measures responsiveness to clicks and typing: good under 200 milliseconds, poor above 500. CLS (Cumulative Layout Shift) measures layout jumps: good under 0.1, poor above 0.25.
These thresholds apply at the 75th percentile of visits, separately on mobile and desktop. INP replaced FID on March 12, 2024: an article that still talks about FID is out of date.
Google confirms that its ranking systems use these metrics, but specifies that there is no single page experience signal and that it will always show the most relevant content, even if the page experience is sub-par. Core Web Vitals mostly help break ties between pages of comparable relevance.
How we ranked them
Field data from August 2026 shows that WordPress sites do better than the web average on INP and CLS on mobile, but clearly worse on server response time and LCP. So we start with the server and the main image, then move on to resources, fonts, stability and responsiveness.
The last one is about measurement, without which none of the other nine can be confirmed.
1. A page cache to cut response time
Why it matters
TTFB (Time to First Byte), the time before the first byte of the response arrives, is not a Core Web Vital. But it eats into the LCP budget: until the server has answered, nothing renders. Google considers a TTFB under 0.8 seconds good. It is the main weakness of WordPress sites, which build each page on demand in PHP.
How to do it
A page cache, at the server or CDN level, serves anonymous visitors a pre-built version of the page. For what cannot be cached, such as the admin, the cart or customer accounts, a persistent object cache reduces database work. The quality of your WordPress hosting, however, sets the limit of what caching can gain.
How to check
Since WordPress 6.1, Site Health tests for a page cache and compares server response time with a 600-millisecond threshold. The test only appears on a site whose environment type is production. Response headers also tell you whether a page came from the cache. Field TTFB appears in PageSpeed Insights.
2. Make the LCP image discoverable and prioritized
Why it matters
On most pages, the LCP element is an image: the header photo, the banner, the featured image. Google observes that a significant share of these images is not discoverable in the initial HTML, because they are loaded by JavaScript or declared as CSS backgrounds. The browser finds them too late.
How to do it
Since WordPress 6.3, core adds fetchpriority="high" to the image it judges most likely to be the LCP element, provided it measures at least 50,000 square pixels. But the performance team acknowledged in 2023 that this guess was right only about half the time. Check your template: in a custom theme, pass the attribute explicitly.
echo wp_get_attachment_image( $image_id, 'full', false, array( 'fetchpriority' => 'high' ) );For a CSS background image, which the browser cannot see in the HTML, a high-priority preload is required. The wp_preload_resources filter has allowed such a preload since WordPress 6.1, and high priority, through its fetchpriority key, since 6.6. The performance team’s Image Prioritizer plugin goes further, choosing which image to prioritize from real-visitor data, but it is still in beta and depends on the Optimization Detective plugin, which collects that data.
How to check
PageSpeed Insights identifies the LCP element and flags it when it is discovered late. In the developer tools, the priority column of the Network tab shows whether the image is loaded at high priority.
3. Lazy loading in the right place, never on the LCP image
Why it matters
Lazy loading delays images below the fold. Applied to the main image, it does the opposite of what you want: the browser waits to know whether the image is visible before requesting it. According to the 2025 Web Almanac, about one page in six still makes this mistake.
How to do it
By default, WordPress excludes the first three content media elements, images or iframes, from lazy loading. The risk comes mostly from themes, page builders and optimization plugins that add their own lazy loading, either with the native loading="lazy" attribute or in JavaScript with attributes such as data-src. Across the web, the native attribute is in fact the more common cause. Exclude the header image from it and, in your templates, pass 'loading' => false to the image output function.
How to check
View the source and look for the loading="lazy" attribute on the main image. PageSpeed Insights explicitly flags a lazy-loaded LCP image.
The real case: when WordPress had to fix its own lazy loading
The most instructive story about WordPress and Core Web Vitals is that of an optimization that became a brake, then was fixed thanks to field data. Felix Arntz, then the project’s performance team, documented it step by step on the official developer blog.
A good idea applied everywhere
On August 11, 2020, WordPress 5.5 turned on native lazy loading for every image with a width and a height. The intent was sound: save bandwidth on images the visitor may never see. Iframes followed with WordPress 5.7, in March 2021.
The measurement that contradicted the default
In July 2021, Felix Arntz, then an engineer at Google, who would co-found the WordPress performance team a few months later, tested the 50 most popular themes across 200 scenarios. The result was clear: lazy-loading the first content image hurt LCP. Without it, median LCP improved by about 7%, for the same image weight. He proposed no longer lazy-loading the first image, which WordPress 5.9 did in January 2022.
From exclusion to priority
In 2023, the team pushed the logic further: since core knows which image not to lazy-load, it can also mark it as a priority. WordPress 6.3, on August 8, 2023, added fetchpriority="high" to the presumed LCP image, raised to three the number of images excluded from lazy loading, and fixed header images in classic themes.
Validation on 500,000 sites
In September 2023, the team compared more than 500,000 WordPress home pages in HTTP Archive and the Chrome UX Report, before and after the update. The mobile LCP pass rate went up, and sites that stopped lazy-loading their LCP image while giving it the right priority gained far more than the others. The share of sites lazy-loading their LCP image dropped sharply.
The team also published its limits: the prioritized image was the right one only about half the time, and the share of sites with a good desktop TTFB fell by about 5% for classic themes and 9% for block themes. At the end of the year, it estimated that version 6.3 had been the most useful release of 2023 for WordPress sites’ mobile LCP.
What to take away
An optimization applied without looking at the page can slow down its most important element. The fix came from field data, not from a lab score. And even core’s rules cannot see everything: a header set as a CSS background or a JavaScript slider escapes them. The loading and fetchpriority attributes of your main image remain the first thing to check.
4. Modern formats and correctly sized images
Why it matters
A lighter LCP image arrives sooner. WordPress has accepted WebP since version 5.8, and AVIF since 6.5. According to WordPress’s official dev notes, a WebP file is on average about 30% lighter than an equivalent JPEG or PNG, and an AVIF up to 50% lighter than a JPEG at the same quality. Yet the vast majority of LCP images on the web are still JPEG or PNG.
How to do it
A point often misunderstood: WordPress does not convert your JPEGs to WebP or AVIF. It accepts these formats on upload, nothing more. Conversion goes through the image_editor_output_format filter or a plugin. The performance team’s Modern Image Formats module generates AVIF if the server supports it, otherwise WebP, for new uploads. Our comparison of image optimization plugins covers the other options.
How to check
In Site Health’s Info tab, the Media Handling section shows whether your server can produce AVIF. In the Network tab, the LCP image’s content type should be image/avif or image/webp. Images already online need to be regenerated.
5. Remove unused CSS and JavaScript
Why it matters
Every render-blocking stylesheet and script delays rendering. On a WordPress site, many of these files come from plugins that load their resources on every page, even where they serve no purpose: sliders, forms, share buttons.
How to do it
WordPress has made a lot of progress. Since version 6.3, a script can be loaded with defer or async. Since 6.9, classic themes only load the styles of blocks actually present on the page, and assets of hidden blocks are omitted.
According to the 6.9 field guide, the sample page of the bundled themes carries 45% less CSS on average, a lab measurement. In return, the same guide warns that the output buffering that makes this possible makes TTFB somewhat worse for classic themes.
As a site owner, list the plugins that load resources everywhere, and remove them from pages that do not need them. The “remove unused CSS” features of optimization plugins are effective but delicate: test them on a copy, since they readily break menus and modal windows.
How to check
The Coverage tab in Chrome’s developer tools shows how much code goes unused. PageSpeed Insights lists render-blocking requests and unused JavaScript.
6. Fonts and font-display
Why it matters
A web font that arrives late delays the text, or makes it jump when it replaces the fallback font. The first case weighs on LCP when the main element is a heading, the second on CLS.
How to do it
Limit the number of families and weights, host WOFF2 files on your server and preload only the font used by the main text. Since WordPress 6.5, the Font Library downloads Google Fonts to your server instead of calling Google. Fonts declared in the theme.json file use font-display: fallback by default, a reasonable compromise you can change.
To remove the jump on replacement, adjust the fallback font’s metrics with size-adjust, as Google recommends, or switch to font-display: optional if the typographic identity is not critical.
How to check
The Network tab shows the number of font files and their priority. The Performance panel flags layout shifts at the moment of replacement.
7. CLS: dimensions, ads and embeds
Why it matters
Text that jumps just as you are about to click is the frustration CLS measures. The classic causes are well known: images without dimensions, ads and embeds that resize themselves, banners injected at the top of the page. CLS is not WordPress’s main weakness on mobile, but it remains more fragile on desktop.
How to do it
Since version 5.5, WordPress automatically adds width and height to Media Library images inserted into content. For the rest, reserve the space: a fixed minimum height for ad slots, an aspect ratio for embedded videos, a cookie banner as an overlay rather than at the top of the page. The performance team’s Embed Optimizer plugin, still in beta, also reserves space for embeds, provided it runs alongside the Optimization Detective plugin.
How to check
PageSpeed Insights lists the elements responsible for shifts. Beware: a lab test does not see shifts that happen after scrolling or an interaction, which field CLS measures throughout the visit.
8. INP: long tasks and third-party scripts
Why it matters
INP measures the delay between a visitor’s action and the display of its result. It degrades when the browser is busy with long tasks, over 50 milliseconds, often caused by third-party scripts: tag managers, chat tools, ads, shop filters. On average, WordPress does well on this metric, but a site loaded with scripts can fail badly.
How to do it
List third-party scripts, remove duplicates, such as two analytics tools or forgotten ad pixels, and delay non-essential scripts until the first interaction. In your own code, split heavy processing so the browser gets control back.
The case published on web.dev in January 2025 by QuintoAndar engineers shows what is possible: the Brazilian housing platform cut its INP by 80% in about ten months of 2024, by moving third-party pixels off the browser and splitting its tasks. The site does not run WordPress, but the method carries over. Avoid, on the other hand, the performance team’s Web Worker Offloading plugin: its own page calls it experimental and says it is intended to be sunset.
How to check
INP can only really be measured in the field, with Chrome UX Report data or a real-user monitoring tool. In the lab, Lighthouse uses Total Blocking Time as a proxy, which does not capture real clicks.
9. Speculative loading and the back/forward cache
Why it matters
These two techniques do not speed up the first page, but make the following ones almost instant. Speculative loading fetches the page a visitor is about to open. The back/forward cache, or bfcache, restores a page instantly when you use the back and forward buttons, which accounts for one navigation in ten on desktop and one in five on mobile, according to Google.
How to do it
Since WordPress 6.8, core adds speculative loading rules for logged-out visitors on sites with pretty permalinks: a conservative prefetch, triggered when the visitor starts to click. WordPress 7.1 lets a site or host change that default with two constants, WP_SPECULATIVE_LOADING_DEFAULT_MODE and WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS. The automatic switch to moderate eagerness on sites with both a page cache and an object cache, planned in the 7.1 roadmap, did not ship.
To go further without code, the performance team’s Speculative Loading plugin turns on moderate prerendering by default. To disable the core feature, one filter is enough:
add_filter( 'wp_speculation_rules_configuration', '__return_null' );On the bfcache side, WordPress sends a no-store header to logged-in users, which has historically prevented this caching. The core fix is still pending; the Instant Back/Forward plugin offers a workaround in the meantime.
How to check
In Chrome’s developer tools, the Application tab shows speculative loads and offers a back/forward cache test. Logged out, or in a private window, the source should contain a <script type="speculationrules"> block. Speculative loading only works in Chromium-based browsers. The bfcache, however, exists in all major browsers, including Safari and Firefox.
10. Measure with field data
Why it matters
A Lighthouse score of 100 does not mean you pass Core Web Vitals. Lighthouse is a lab test, on a simulated device and a single network. Google relies on Chrome UX Report field data, at the 75th percentile, over the last 28 days. The two can diverge sharply, especially for INP, which the lab does not measure.
How to do it
In Search Console, the Core Web Vitals report groups similar URLs and grades each group by its worst metric. After a fix, start a validation: it tracks progress over 28 days. PageSpeed Insights shows field data at the top of the page and lab results below. Our selection of WordPress speed optimization plugins then helps you apply the fixes.
The limits of measurement
The Chrome UX Report only collects data from Chrome on desktop and Android: iPhone visitors are not included. A low-traffic site may have no data at all. And metric definitions change with Chrome releases, so a score can move without any change on the site.
Where to start
Open Search Console’s Core Web Vitals report, identify the metric that makes your URL groups fail, then go back to the matching fix. A slow LCP points to fixes 1 to 6, a high CLS to fixes 6 and 7, a poor INP to fixes 5 and 8.
For a typical WordPress site, the most profitable order is almost always the same: a page cache, then the main image, then sorting out scripts. For pages the cache cannot serve, such as the cart or the customer area, a Redis object cache takes over.
Summary table
| Fix | Metric | What WordPress does | How to check |
|---|---|---|---|
| Page cache | TTFB, LCP | Site Health test (6.1) | Headers, field TTFB |
| LCP image priority | LCP | Automatic fetchpriority (6.3) | Network priority column |
| Lazy loading | LCP | First three images excluded (6.3) | Header source code |
| WebP and AVIF | LCP | Formats accepted, no conversion | Image content type |
| Unused CSS and JS | LCP, INP | defer and async (6.3), on-demand styles (6.9) | Coverage tab |
| Fonts | LCP, CLS | Locally hosted fonts (6.5) | Network tab |
| Dimensions and reserved space | CLS | Width and height added (5.5) | Culprit elements in PageSpeed |
| Third-party scripts | INP | Nothing, it is up to you | Field data only |
| Speculative loading | LCP of next pages | Conservative prefetch (6.8) | Application tab |
| Field measurement | All three | Not applicable | Search Console, 28 days |
Frequently asked questions
Do Core Web Vitals affect Google rankings?
Yes, but they never outweigh relevance. Google uses them in its ranking systems, while stating that content relevance comes first and that a good score does not guarantee a good position. They matter most between pages of comparable relevance.
Why is PageSpeed green while Search Console is red?
Because one measures in the lab and the other in the field. The PageSpeed score comes from a simulated test, Search Console from 28 days of real visits, on devices and networks that are often slower, with interactions the test does not reproduce.
How long before a fix shows up?
Up to 28 days, the field data collection period. Search Console validation follows the same period. Lab tests, on the other hand, show the effect immediately.
Should I turn on prerendering?
On a well-cached site, moderate prerendering makes navigation almost instant in Chrome. It does, however, load pages the visitor will not always open, which increases server load and can inflate some analytics. Test it, then watch your server.
My site has no field data: what should I do?
A low-traffic site may not appear in the Chrome UX Report. Work with lab tests, knowing they do not measure real INP, or install a real-user monitoring tool based on Google’s web-vitals library.
Conclusion
WordPress sites do not suffer first from responsiveness, but from loading: a server too slow to answer, then a main image discovered too late or lazy-loaded by mistake. Fixing these two points solves a good part of the problem, before you even touch scripts.
The lazy-loading story is a final reminder that an optimization is checked in the field, never on a score. Measure, fix, then wait 28 days before drawing conclusions. And if your site has other invisible weaknesses, our list of WordPress mistakes to avoid will help you spot them.
Sources
- web.dev (October 31, 2024). Web Vitals
- web.dev (September 4, 2025). Largest Contentful Paint (LCP)
- web.dev (September 2, 2025). Interaction to Next Paint (INP)
- web.dev. Cumulative Layout Shift (CLS)
- web.dev (March 12, 2024). Interaction to Next Paint is officially a Core Web Vital
- web.dev (October 31, 2024). The most effective ways to improve Core Web Vitals
- web.dev (March 31, 2025). Optimize Largest Contentful Paint
- web.dev (November 28, 2025). Time to First Byte (TTFB)
- web.dev (December 19, 2024). Optimize long tasks
- web.dev (July 2, 2026). Back/forward cache
- Google Search Central (September 22, 2026). Understanding page experience in Google Search results
- Google Search Console Help. Core Web Vitals report
- Google for Developers. About PageSpeed Insights
- Chrome for Developers. CrUX methodology
- HTTP Archive (August 2026 data). Technology Report, WordPress
- HTTP Archive (January 15, 2026). Web Almanac 2025, Performance
- Make WordPress Core, Felix Arntz (July 15, 2021). Refining WordPress core’s lazy-loading implementation
- Make WordPress Core, Felix Arntz (July 13, 2023). Image performance enhancements in WordPress 6.3
- Make WordPress Core, Felix Arntz (September 19, 2023). Analyzing the Core Web Vitals performance impact of WordPress 6.3 in the field
- Make WordPress Core, Felix Arntz (December 19, 2023). WordPress performance impact on Core Web Vitals in 2023
- Make WordPress Core, Adam Silverstein (February 23, 2024). WordPress 6.5 adds AVIF support
- Make WordPress Core, Felix Arntz (March 6, 2025). Speculative Loading in 6.8
- Make WordPress Core, Weston Ruter (November 18, 2025). WordPress 6.9 Frontend Performance Field Guide
- WordPress Developer Resources. wp_get_speculation_rules_configuration()
- web.dev, Mari Viana et al. (January 22, 2025). How QuintoAndar reduced INP by 80%
- WordPress.org. Web Worker Offloading
- Make WordPress Core, Adam Silverstein (June 7, 2021). WordPress 5.8 adds WebP support
- WordPress.org. Optimization Detective
LaFactory designs, builds and maintains WordPress and WooCommerce sites, performance optimization included, and develops its own plugins. Talk to us about your WordPress project.