Core Web Vitals, Page Experience: What are we talking about?
With its "Page Experience" algorithmic update in June 2021, Google placed the Core Web Vitals at the heart of its user experience evaluation, as explained in its official recommendations. The goal: to offer users results that are not only relevant but also fast, responsive, and pleasant to view, on mobile and desktop alike. Five years later, the principle hasn't changed, but the metrics, tools, and optimization levers have evolved significantly. This article provides an update, in 2026, on everything you need to know for a WordPress or WooCommerce site to meet these technical requirements.
A useful reminder before diving into the details: Core Web Vitals are not just a cosmetic score. They are built from your users' actual visits and influence search result rankings, in addition to content relevance. We've also dedicated a full article to the SEO impact of web performance. Beyond SEO, these metrics primarily measure what your visitors actually experience: a site that loads quickly, responds promptly, and doesn't jump around converts better, quite simply.
The three metrics that make up the Core Web Vitals
The Core Web Vitals are currently based on three complementary indicators, defined and documented by the Chrome team on web.dev: LCP for loading speed, INP for responsiveness, and CLS for visual stability. Each has precise thresholds that categorize the experience into three levels: good, needs improvement, or poor.
LCP: Perceived loading speed
The Largest Contentful Paint measures the time it takes to display the largest visible element on the page: most often a banner image, a product photo, or a large heading. It's the indicator that most closely approximates the feeling of a "page loaded" experienced by the visitor. To be considered good, the LCP must occur within 2.5 seconds of the start of navigation. Anything over 4 seconds is considered poor. On a typical WordPress site, the LCP element is almost always the featured image of the article or the main visual on the homepage. We detail the specific techniques for this metric in our dedicated article: what is LCP and how to optimize it?
INP: Responsiveness to interactions
The Interaction to Next Paint officially replaced FID in March 2024 within the Core Web Vitals. Whereas FID only measured the delay of the very first interaction, INP observes all clicks, taps, and keyboard inputs made during the page's entire lifespan, and retains one of the worst observed values. It captures the time elapsed between user interaction and the next visible screen update. To be good, INP must remain under 200 milliseconds. It is the most demanding metric for JavaScript-heavy sites, and the one that caused the most sites to fall into the red upon its introduction. Our article What is INP and How to Improve It? is entirely dedicated to it.
CLS: Display Stability
The Cumulative Layout Shift quantifies unexpected layout shifts: that button that dodges your finger as you click, that paragraph that suddenly drops because an ad just inserted itself above it. The score accumulates the amplitude and frequency of these shifts: it must remain below 0.1 to be considered good. Unlike LCP and INP, CLS is not measured in seconds: it is a unitless score, calculated from the displaced area and the displacement distance.
The 75th percentile, the rule of the game
An essential point, often misunderstood: Google does not evaluate your site based on an average visit, but on the 75th percentile of all visits. In concrete terms, 75% of your page views must reach the "good" threshold for the metric to be validated. This rule protects the experience of the least fortunate visitors: those browsing on entry-level mobile phones, on shaky 4G, far from your server. Optimizing for the 75th percentile means optimizing for the reality of your audience, not for the office fiber connection.
Lab data or field data: what does Google look at?
Before talking about optimization, we need to understand where the numbers come from. Two families of tools coexist, and it's common for them to tell different stories, as explained in the web.dev documentation.
CrUX, the source of truth
Field data comes from the Chrome UX Report (CrUX): Chrome collects, from users who have given their consent, the metrics actually measured during their visits. This data is aggregated over a rolling 28-day period and feeds the Google Search Console's "Core Web Vitals" report, the functioning of which is detailed in the official documentation. It is through this channel that the famous email alerts of the type "a page deserves your attention" are sent. Remember this: it is this field data, and only this data, that counts for your site's Page Experience evaluation.
Lighthouse and PageSpeed Insights, the diagnostic tools
Lab data is produced on demand by tools like Lighthouse or the Chrome DevTools Performance tab, under simulated and reproducible conditions. It is valuable for diagnosing and verifying a fix, but it is not definitive: a Lighthouse score of 100 does not guarantee green Core Web Vitals in the field, especially because INP cannot be measured without real interaction. PageSpeed Insights has the advantage of presenting both types of data on the same screen: CrUX data at the top, Lighthouse audit at the bottom. We have broken down the differences between these tools in our comparison PageSpeed Insights vs. Lighthouse.
What WordPress already does natively for your Core Web Vitals
Good news: WordPress has not stood still. Since 2020, a dedicated performance team (the Core Performance Team) has been improving the CMS version after version, and the results are measurable on a web scale. The HTTP Archive's Web Almanac 2024 shows that the proportion of WordPress sites validating all three Core Web Vitals on mobile has increased from 28% in 2023 to 40% in 2024, driven in particular by spectacular progress in INP. Keeping your WordPress site up to date is therefore, in itself, a web performance action.
Native lazy loading of images
Since WordPress 5.5, the loading="lazy" attribute is automatically added to images, which are then only downloaded when they approach the visible area. Version 5.9 refined the mechanism to exclude the first images on the page: lazy-loading was paradoxically delaying LCP. This is a trap we still encounter very often in audits: an LCP image deferred by an overzealous plugin can cost several hundred milliseconds.
Automatic prioritization of the LCP image
Since WordPress 6.3, the CMS automatically adds fetchpriority="high" to the image it deems to be the LCP element, instructing the browser to download it with priority, even before calculating the layout. According to the Core team, this single attribute typically improves LCP by 5 to 10%. Version 6.4 then further refined these heuristics. However, the mechanism remains an estimation: on complex templates, an audit can verify that the correct image is actually prioritized.
Modern image formats: WebP and AVIF
WordPress has supported the WebP format since version 5.8 and, since version 6.5, the AVIF format, which produces files up to 50% lighter than JPEG at equivalent visual quality. AVIF images benefit from all native tooling: responsive variations via srcset, lazy loading, and fetchpriority. The only condition is that your hosting's image library (Imagick or GD) supports the format, a point we systematically check on the WordPress hosting we operate.
Speculative loading: near-instant navigation
This is the most exciting innovation in recent years: since WordPress 6.8, the CMS natively uses the Speculation Rules API to preload pages that the visitor is about to open. By default, WordPress applies cautious preloading (prefetch): when the user starts interacting with a link, the HTML of the target page is downloaded in the background. Result: upon clicking, navigation appears almost instantaneous. The behavior can be enhanced via a simple filter, to switch to prerender (the page is fully constructed in advance, including stylesheets and scripts):
// Passer du prefetch conservateur au prerender modéré (WordPress 6.8+)
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
if ( is_array( $config ) ) {
$config['mode'] = 'prerender';
$config['eagerness'] = 'moderate';
}
return $config;
} );Caution is still advised on e-commerce sites: overly aggressive prerendering can skew certain statistics or preload pages with state (cart, customer account). WordPress excludes sensitive URLs by default, but custom configuration remains recommended. Note that this API is supported by Chrome and Edge; non-compatible browsers simply ignore the rules, with no side effects: it is progressive enhancement by nature.
How to improve LCP on WordPress?
The reference guide Optimize LCP breaks down the metric into four phases: server response time (TTFB), resource discovery delay, download time, and rendering. On WordPress, three areas concentrate the majority of the gains.
Optimize the main image
The LCP image must be served in a modern format, at the right size, and discovered as early as possible by the browser. When it's loaded in CSS background or injected via JavaScript (two common anti-patterns with page builders), the browser only discovers it after processing the stylesheets: explicit preloading fixes this. Here's what a well-done integration produces:
<!-- Dans le head : découverte immédiate de l'image LCP -->
<link rel="preload" as="image"
href="/wp-content/uploads/hero-1200.avif"
imagesrcset="/wp-content/uploads/hero-800.avif 800w,
/wp-content/uploads/hero-1200.avif 1200w"
imagesizes="100vw" fetchpriority="high">
<!-- Dans le contenu : dimensions explicites, pas de lazy loading -->
<img src="/wp-content/uploads/hero-1200.avif"
srcset="/wp-content/uploads/hero-800.avif 800w,
/wp-content/uploads/hero-1200.avif 1200w"
sizes="100vw" width="1200" height="600"
fetchpriority="high" alt="Description du visuel">The width and height attributes are essential: they allow the browser to reserve space for the image before it's downloaded, which also benefits CLS. WordPress automatically provides them for images in the media library, but visuals added manually in themes often miss out.
Reduce TTFB: hosting, PHP, and server cache
LCP can't be good if the server takes a second to respond. The Time to First Byte documentation recommends a TTFB of 800 milliseconds or less at the 75th percentile, and we aim for much less on the sites we manage. On WordPress, this requires adequately sized hosting, a recent version of PHP with OPcache, a healthy database, and above all, page caching: serving an already generated HTML rather than rebuilding the page for each visit radically changes the game. This is precisely the foundation of our high-performance WordPress hosting offer.
Is your site as fast as your visitors expect?
Bring content closer to visitors
For an international audience, a CDN physically brings static resources (and possibly HTML) closer to visitors, reducing incompressible network latency. However, the topic deserves a case-by-case analysis: for an essentially French audience served by a good local host, the gain may be marginal. We weighed the pros and cons in our article CDN and web performance: what are the advantages and disadvantages?
How to improve INP on WordPress?
INP degrades when the browser's main thread is busy executing JavaScript when the user interacts. The Optimize INP guide is clear: the main culprits are long JavaScript tasks, which block rendering and delay visual response. On WordPress, the diagnosis almost always comes back to the same causes.
Track third-party scripts
Tag managers, ad pixels, chats, A/B testing, embedded videos: third-party scripts are the primary cause of the INP degradation we observe in audits. Each one seems harmless, but their accumulation saturates the main thread. Our article on reducing the impact of third-party JavaScript details the method: inventory, remove the unnecessary, delay the non-critical, and isolate what can be isolated. Consent banners deserve special mention, as they run at the worst possible moment, as soon as you arrive on the site: we compared 11 CMPs from a performance perspective, and the differences are considerable. Even your audience measurement tool has a cost, which we quantified in our article on the impact of Google Analytics.
Load JavaScript at the right time
Since WordPress 6.3, developers can natively declare the loading strategy for their scripts, as documented by the Core team. A deferred script is only executed once the document has been parsed, without ever blocking rendering:
// Déclarer un script en defer, à la mode WordPress 6.3+
add_action( 'wp_enqueue_scripts', function () {
wp_enqueue_script(
'mon-app',
get_theme_file_uri( 'assets/app.js' ),
array(),
'1.2.0',
array(
'strategy' => 'defer',
'in_footer' => true,
)
);
} );Break down long tasks
For application code that really needs to run, the golden rule is to regularly yield control back to the browser so it can process pending interactions. The guide Optimize long tasks recommends breaking down any processing exceeding 50 milliseconds, particularly using the scheduler.yield() API:
// Rendre la main au navigateur entre chaque lot de travail
async function traiterElements(elements) {
for (const element of elements) {
afficher(element);
if ('scheduler' in window && 'yield' in scheduler) {
await scheduler.yield();
}
}
}How to improve CLS on WordPress?
CLS is probably the most satisfying metric to fix: the causes can be identified one by one, and the fixes are lasting. The guide Optimize CLS groups them into three categories: media without dimensions, late-injected content, and fonts.
Reserve space for media and injections
All images, iframes, or videos must have explicit dimensions (width and height attributes, or CSS aspect-ratio property) so that their space is reserved before loading. The same principle applies to dynamic content: a consent banner should overlay the page or have a reserved space, never push content down. Carousels are a classic example: with shifts, JavaScript weight, and non-prioritized images, they accumulate flaws, as we explain in our article Say goodbye to sliders.
Tame fonts
When a web font loads after the initial render, text is re-rendered with new metrics, and the entire page can shift. Best practices documented by web.dev include hosting fonts locally, a recommendation also long advocated by Harry Roberts (secondary source), preloading the critical WOFF2 file, and displaying text without waiting using font-display. The expert step is to adjust the fallback font with size-adjust so that the swap is visually neutral.
@font-face {
font-family: "Manrope";
src: url("/fonts/manrope.woff2") format("woff2");
font-display: swap;
}
/* Police de repli calibrée : la permutation ne décale plus rien */
@font-face {
font-family: "Manrope Fallback";
src: local("Arial");
size-adjust: 106%;
ascent-override: 103%;
descent-override: 29%;
}
body {
font-family: "Manrope", "Manrope Fallback", sans-serif;
}The subject is broader than it appears (variable fonts, character subsets, icon fonts): we have dedicated a full article to it on the impact of web fonts on performance.
Theme, plugins, cache: the foundations of a fast WordPress
Fine-tuning optimizations only make sense on a healthy foundation. Three structural choices determine a WordPress site's performance potential.
A lightweight and well-built theme
The theme dictates everything else: CSS weight, JavaScript quantity, quality of generated HTML. Themes like GeneratePress, Astra, or Blocksy are designed for simplicity, while others pack megabytes of resources for unused features. We detailed the objective selection criteria in our guide how to (properly) choose your WordPress theme? On an existing site, changing themes isn't always feasible: we then optimize the current theme, via a child theme, to correct its flaws without altering the design.
As few plugins as possible, and the right ones
Each active plugin on the front-end can add its stylesheets, scripts, and database queries. Traditional page builders (Elementor, Divi, Beaver Builder) are the most resource-intensive: the native Gutenberg editor produces much leaner HTML and can now be used to build complete sites, including e-commerce stores, as we demonstrate in our article on creating a performant WooCommerce site with Gutenberg. An expert move: after deactivating each plugin, check what has actually disappeared from the source code. It's also possible to surgically remove resources that a plugin loads where they are not needed:
// Ne charger les ressources WooCommerce que sur les pages marchandes
add_action( 'wp_enqueue_scripts', function () {
if ( class_exists( 'WooCommerce' ) &&
! is_woocommerce() && ! is_cart() && ! is_checkout() ) {
wp_dequeue_style( 'woocommerce-general' );
wp_dequeue_style( 'wc-blocks-style' );
wp_dequeue_script( 'wc-cart-fragments' );
}
}, 20 );A complete caching strategy
A page caching extension (WP Rocket, for example) transforms each page into static HTML served in milliseconds, while managing script deferral and resource optimization. On sites with high traffic or complex business logic, persistent object caching (Redis or Memcached) further relieves the database. Finally, browser cache policy (Cache-Control headers) prevents re-downloading unchanged resources on subsequent visits. We should also mention the official Performance Lab plugin, a showcase for the Core Performance Team, which allows future WordPress optimizations to be activated before they are integrated into the CMS core.
How to measure and track your Core Web Vitals?
The method we apply during an engagement has three stages. First, an assessment based on field data: Search Console and CrUX show the site's actual performance, page by page, metric by metric. Then, laboratory diagnostics: Lighthouse, the Performance tab in DevTools, and the Chrome Web Vitals extension allow us to reproduce issues and identify their exact cause. Finally, long-term verification: since CrUX data is aggregated over a rolling 28-day period, a fix takes several weeks to reflect in Search Console, hence the importance of continuous web performance monitoring that alerts to the slightest regression, long before Google notices it.
One watchword to conclude this section: measure before optimizing. Miracle cures applied blindly (aggressive minification, excessive preloading, stacked optimization plugins) sometimes do more harm than good. Each site has its own performance profile, and an audit is what prioritizes actions based on cost-benefit. To go further, our bible of 117 pro tips lists all known levers.
Need technical support in the process?
Optimizing a WordPress site remains a technical intervention that requires in-depth knowledge of web languages (HTML, CSS, JavaScript, PHP) and the internal workings of the CMS. With over 20 years of experience with WordPress and WooCommerce, our developers work on any existing site to maximize its performance level: a comprehensive audit to establish the diagnosis and prioritize, followed by WordPress optimization to implement the fixes. The site you are currently visiting was optimized by us: green Core Web Vitals and a mobile PageSpeed Insights score of 100 are entirely achievable with WordPress. Trust us to help your site reach its full performance potential!
