Публикувано: Обновено:
The speed of a website today is not just “nice to have” – it directly determines whether the user stays, interacts and converts, or hits the back button and goes to the competition. Google confirmed Core Web Vitals as a ranking signal back in 2021, and by 2026 their weight continues to grow, especially after the December 2025 core update, which tightened requirements.
The data speaks for itself: every second of delay in loading reduces conversions by 7% (Idea Fueled, 2026). Sites that cover all three Core Web Vitals report a 24% lower bounce rate (Digital Applied, 2026). And pages in position 1 in Google are 10% more likely to cover all thresholds compared with lower-ranking pages (ALM Corp, 2025).
At the same time, WordPress, the platform that powers 43.5% of websites, has a problem: only 44% of WordPress sites on a mobile device cover all three Core Web Vitals (CoreWebVitals.io, end of 2025). The average WordPress site with no optimisation scores 40-70 out of 100 in Lighthouse (LogosWebDesigns, April 2026).
In this guide we explain exactly what the three metrics are, why WordPress lags behind, and we give practical steps for optimisation – from theme and hosting choice to configuring caching, images, fonts and JavaScript. We also introduce the WordPress Performance Stack, a 5-layer framework that organises optimisation in the correct sequence, from infrastructure to monitoring, so that every layer builds on the previous one.
The three metrics: LCP, INP and CLS
LCP – Largest Contentful Paint
LCP measures the time it takes for the largest visible element on the screen (usually the hero image or the main text block) to render fully. The threshold for a “good” result is under 2.5 seconds, and new sources for 2026 note that Google already treats a result under 2.0 seconds as optimal (Idea Fueled, April 2026).
LCP is the metric users feel first – it determines how quickly the page “appears” to them. On WordPress the most common culprits for a slow LCP are: a heavy hero image with no optimisation, lazy loading applied to above-the-fold images (which is counterproductive), a slow server response (TTFB) and render-blocking CSS/JS.
INP – Interaction to Next Paint
INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. While FID only measured the first interaction, INP covers every interaction throughout the whole session – a click on a button, pressing a key, a tap on a menu. The threshold is under 200ms.
INP is especially important for WordPress sites with interactive elements: WooCommerce carts, filters, popup forms, sliders. Every plugin that adds JavaScript can potentially increase INP, because it occupies the browser’s main thread.
CLS – Cumulative Layout Shift
CLS measures visual stability – how much elements shift unexpectedly during loading. The threshold is under 0.1. Typical causes of a high CLS on WordPress are: loading web fonts that shift the text (FOUT, Flash of Unstyled Text), images with no defined width and height attributes, dynamically inserted content (ads, embeds) and late-loading CSS.
CLS is the metric users find most irritating – nothing is more frustrating than a button that moves right when you try to click it. For a full look at the role of these metrics in user experience, read our article on UI and UX design.
The WordPress Performance Stack: a framework for systematic optimisation
One of the most common mistakes in WordPress optimisation is installing a “magic” plugin in the hope of instant results, without addressing the fundamental problems. A caching plugin can improve the Lighthouse score by 10-20 points, but it cannot compensate for a heavy theme, 25 plugins and unoptimised images. This framework, which we call the WordPress Performance Stack, organises optimisation into 5 sequential layers, each built on top of the previous one.
| Layer | What it covers | Why it matters |
|---|---|---|
| 1. Infrastructure Layer | Hosting, PHP 8.3+, Redis, CDN | Without a fast foundation everything else is compromised |
| 2. Foundation Layer | A lightweight theme, minimal plugins | Theme bloat cannot be “cached” away |
| 3. Asset Optimization Layer | Images, fonts, JavaScript | 70% of the page weight is here |
| 4. Caching Layer | Page cache, object cache, browser cache, CDN | Final speed after optimisation |
| 5. Monitoring Layer | Lab + field data, continuous monitoring | Optimisation is a process, not a one-off action |
The rule of the stack: neglecting any layer compromises the final result. Installing an expensive caching plugin (Layer 4) on top of shared hosting with a TTFB of 600ms (missing Layer 1) delivers 20% of the potential speed. Optimising images (Layer 3) on top of a heavy Page Builder theme (missing Layer 2) is a cosmetic fix – the main problem remains.
Applying the framework: start with Layer 1 (Infrastructure) and go through in order. Do not skip layers and do not start from the Caching Layer – it gives real results only on top of a clean architecture. Each layer brings a 15-40% improvement, and when properly executed the cumulative effect turns the average WordPress site from 40-70/100 into 90+/100 in Lighthouse.
Why WordPress lags behind and how to overtake it
WordPress is a flexible platform, but that flexibility is also a trap: themes with dozens of embedded styles and scripts, dozens of active plugins, unoptimised images. The average WordPress site from an “out of the box” install with a Page Builder theme and 15-20 plugins is far from Core Web Vitals thresholds.
The good news is that WordPress can be exceptionally fast, as long as it is approached correctly from the very start. That is precisely why at CreateWeb, when building a website, performance is built in as a priority, not a correction after the fact. For further detail on choosing the right architecture, see our articles on customising WordPress with FSE and choosing a CMS platform.
The Infrastructure Layer: the role of hosting
TTFB and hosting types
Time to First Byte (TTFB) is the time it takes the server to start sending data. It directly affects LCP, because the sooner the server responds, the sooner rendering begins.
Shared hosting shows a TTFB of around 600ms (HostPapa, 2026), while managed WordPress hosting shows around 200ms or less. For a business site the minimum level is: managed WordPress hosting or a VPS with NVMe SSD, PHP 8.3+, OPcache and Redis/Memcached for object caching. For a detailed look at the criteria for choosing quality web hosting, see our pillar article on hosting.
CDN: global optimisation
A CDN (Content Delivery Network) further reduces TTFB for geographically distant users. Cloudflare offers a free plan with a global CDN, and specifically for WordPress, APO (Automatic Platform Optimization), which caches full HTML pages at the edge servers.
For Bulgarian businesses with a European audience, the Cloudflare free plan is entirely sufficient to start with. As traffic grows and advanced functions are needed (HTTP/3, image optimisation, bot protection), the paid plans of Cloudflare, BunnyCDN or KeyCDN are a justified investment.
The Foundation Layer: a light architecture from the start
Theme choice: lightness vs functionality
In web design, theme choice is among the most important decisions for performance. Page Builder themes load hundreds of kilobytes of CSS and JavaScript on every page, even when only a small part of it is actually used.
2026 benchmarks show the following results: Astra, around 1.9 seconds average load, 870KB; GeneratePress, 2.5 seconds, 890KB; Kadence, 2.8 seconds, 898KB; Twenty Twenty-Five (the official block theme), under 1.5 seconds, under 800KB. By comparison, a heavy Page Builder theme (Avada, Divi with active development), 4-7 seconds, 2-4MB.
The recommendation is clear: for a new project choose a light block theme and configure the design via theme.json. This eliminates the need for a Page Builder and secures a structural advantage in Core Web Vitals.
A minimum of plugins
Every active plugin adds PHP execution time, database queries and often additional CSS/JS files (PureThemes, 2026). A single poorly written plugin can add several hundred milliseconds to the loading of every page.
The practical approach is: audit the plugins with Query Monitor (a free plugin that shows the execution time and database queries of every plugin), deactivate and delete everything you do not use, and replace heavy plugins with lighter alternatives. For a detailed approach to site analysis with a focus on performance, we have a separate guide.
LCP optimisation: loading the main content
The hero image: correct priority
The most common mistake on WordPress is lazy loading the hero image. WordPress 5.5 introduced native lazy loading for all images, but the above-the-fold image (hero banner, featured image) should not be lazy loaded – it is the LCP element and needs to load with priority.
Since WordPress 6.3 the core automatically applies fetchpriority="high" to the image most likely to be the LCP. However, with custom themes and Page Builders the attribute sometimes gets applied to the wrong image, or is missing altogether. Check with PageSpeed Insights whether the LCP element has fetchpriority="high" and is not lazy loaded.
For the hero image: use WebP or AVIF format (25-50% smaller than JPEG at comparable quality), set explicit width and height attributes, and if needed, preload via <link rel="preload"> in the head section.
Image format and compression
WebP is the standard for 2026 with 95.67% browser support. AVIF offers an additional 20-35% saving over WebP, but browser support is 93.8% (Reddit/Software, 2026). The recommended strategy is AVIF as the main format with a WebP fallback.
On WordPress, plugins such as ShortPixel, Imagify and Smush automatically convert and compress images on upload. ShortPixel also supports AVIF. The goal is for every image to be under 100KB for a standard blog post, and the hero image under 200KB.
Minimising render-blocking CSS and JS
CSS and JavaScript files that load in the <head> with no defer or async attribute block the rendering of the page. Caching plugins (WP Rocket, LiteSpeed Cache, FlyingPress) offer options for critical CSS extraction (loading only the CSS needed for the above-the-fold content) and deferred/delayed JavaScript.
WP Rocket activates 80% of the optimisations automatically on install (BuddyBoss, 2026), which makes it the safest choice for users with no technical expertise. LiteSpeed Cache is more powerful on LiteSpeed servers, with server-level caching, ESI support and a built-in CDN (QUIC.cloud).
INP optimisation: responsiveness on interaction
Reducing the JavaScript payload
Every active plugin adds PHP execution time, database queries and often additional CSS/JS files. A single poorly written plugin can add several hundred milliseconds to the loading of every page.
The practical approach is: audit the plugins with Query Monitor (a free plugin that shows the execution time and database queries of every plugin), deactivate and delete everything you do not use, and replace heavy plugins with lighter alternatives.
Defer and delay for JavaScript
“Defer” means the script downloads in parallel but only executes after the HTML has been parsed. “Delay” (a WP Rocket and FlyingPress feature) postpones script execution until the user interacts with the page (scroll, click, touch).
Delay is particularly effective for third-party scripts: Google Analytics, Facebook Pixel, chat widgets, reCAPTCHA. These scripts are not needed for the initial render and keeping them active occupies the main thread that user interactions need.
Speculative Loading: the future of the browser
WordPress 6.8 integrates the Speculation Rules API, which allows the browser to speculatively prerender or prefetch pages the user is likely to navigate to. The result is near-instant loading on click. If you use an older WordPress version, the same functionality is available through the Speculative Loading plugin from the WordPress Performance Team.
CLS optimisation: visual stability
Fonts: swap, preload and local hosting
Web fonts are a main cause of CLS on WordPress. When the browser loads a custom font, the text first shows with a fallback font, then “jumps” when the real one is ready. The solutions are: font-display: swap (shows the fallback immediately, swaps when the font is ready), preloading the main font files via <link rel="preload">, and choosing a fallback font with metrics close to the custom font.
Even better: host the fonts locally instead of via Google Fonts. This eliminates the DNS lookup and connection time to an external domain. In block themes and FSE fonts are defined in theme.json and hosted locally automatically through the Font Library.
Limit fonts to a maximum of two families with two-three weights. Every additional font file is an additional HTTP request and additional bytes.
Images: width and height attributes
Every image should have defined width and height in the HTML code. Without them the browser does not know what space to reserve and elements “jump” during loading. WordPress automatically adds these attributes when uploaded via the Media Library, but with manually inserted HTML or with a CSS background-image they are missing.
Dynamic content: reserved space
Ads, embeds (YouTube, Maps), chat widgets and cookie banners all load dynamically and can shift the content. The solution is to reserve space with fixed CSS dimensions (min-height, aspect-ratio) before the element loads.
A WordPress checklist for Core Web Vitals
Hosting and infrastructure (Infrastructure Layer). Managed WordPress hosting or a VPS with NVMe, PHP 8.3+, Redis. TTFB target: under 200ms. A CDN (Cloudflare free plan or better). SSL/HTTPS.
Theme (Foundation Layer). A light block theme: Astra (~1.9s, 870KB), GeneratePress (2.5s, 890KB), Kadence (2.8s, 898KB) or Twenty Twenty-Five. Avoid heavy Page Builder themes. Configuration via theme.json for a minimalist, fast design.
Images (Asset Optimization Layer). WebP or AVIF format. Compression via ShortPixel/Imagify. Hero image: fetchpriority="high", no lazy loading. The rest: native lazy loading. Defined width/height. Files under 100-200KB.
Fonts (Asset Optimization Layer). Local hosting, a maximum of 2 families, font-display: swap, preload the main files. A fallback font with similar metrics.
JavaScript (Asset Optimization Layer). Defer all scripts. Delay third-party ones (Analytics, Pixel, chat). Query Monitor for a plugin audit. Remove unused plugins.
Caching (Caching Layer). WP Rocket (paid, easy) or LiteSpeed Cache (free on LiteSpeed servers). Activate: page cache, browser cache, critical CSS, delay/defer JavaScript, minify CSS/JS.
CLS prevention (Asset Optimization Layer). Width/height for all images. Reserved space for embeds, ads, dynamic elements. A cookie banner fixed in the DOM.
Speculative Loading (Caching Layer). WordPress 6.8+ or the Speculative Loading plugin. Prerender on hover for near-instant loading.
The database (Monitoring Layer). Periodic cleanup: post revisions (limit to 5 in wp-config.php), transients, spam comments, deleted posts. WP-Optimize or WP Rocket Database Cleanup. This is also part of the ongoing WordPress site maintenance.
The Monitoring Layer: how to test Core Web Vitals
There are two types of data: laboratory (synthetic) and field (real user data / CrUX).
Laboratory data is generated by tools that simulate loading under controlled conditions. PageSpeed Insights (pagespeed.web.dev) is the starting point, giving a Lighthouse Performance score and specific recommendations. Google Search Console → the Core Web Vitals report shows an overview for the whole site, grouped into “Good”, “Needs Improvement” and “Poor”.
Field data (CrUX, the Chrome User Experience Report) tracks the real behaviour of users on the Chrome browser. It is more reliable because it reflects diversity in devices, connection speeds and geographic locations. PageSpeed Insights shows both types, the laboratory one in the “Diagnostics” section, and the field one in the “Assess your actual performance” section.
Additional tools: GTmetrix (a visual presentation of the waterfall of requests), WebPageTest (an extended analysis from various locations), Chrome DevTools → the Performance tab (for a detailed INP analysis), and DebugBear (Core Web Vitals monitoring with historical data). A detailed look at these and other tools is in our article on the best website analysis tools.
The goal is not 100/100 in Lighthouse. The goal is: a Lighthouse Performance score of ≥90 on mobile and covering all three CrUX thresholds (LCP < 2.5s, INP < 200ms, CLS < 0.1). This is the level at which Google treats the page as “good”.
Core Web Vitals as part of the overall SEO strategy
Core Web Vitals do not exist in isolation – they are part of the Google Page Experience signal, which also includes mobile-friendliness, HTTPS and the absence of intrusive interstitials. For an overall SEO strategy performance is necessary, but not a sufficient condition.
Even a perfect Lighthouse score does not compensate for weak content, poor information architecture or a lack of E-E-A-T signals. Conversely, excellent content on a slow site still does not work – your users have to wait before they see the value. The balance between performance, SEO web design and strategy is what determines long-term results.
To measure the business effect of Core Web Vitals improvements, we recommend a systematic approach with correct marketing metrics. The correlation between better CWV results and higher conversion is measurable, but requires tracking before and after optimisation.
When speed is measured from the very start
The difference between “an optimised WordPress site” and “a WordPress site with a caching plugin installed” is fundamental. A caching plugin can improve the result by 10-20 points, but it cannot compensate for a heavy theme, 25 plugins and unoptimised images.
At CreateWeb, Core Web Vitals optimisation is built into the web design and development process: choosing a light block theme, configuring theme.json for typography and spacing (eliminates the need for a Page Builder), a minimal number of plugins, image optimisation on upload, and correct caching and CDN configuration. The result is a WordPress site that covers the Core Web Vitals thresholds from day one, not a site that needs expensive optimisation six months later.
If your current site struggles with slow loading, a low Lighthouse score and poor Core Web Vitals, it may be time for a redesign, where performance is built in from the foundations. And if you are planning a new site, request a quote from CreateWeb and let us build it correctly from the very start.
Frequently asked questions
What are Core Web Vitals?
Core Web Vitals are three Google metrics for the real user experience: LCP (loading speed of the main content, threshold < 2.5s), INP (responsiveness on interaction, threshold < 200ms) and CLS (visual stability, threshold < 0.1). They have been a confirmed ranking factor since 2021 and their weight continues to grow.
Do Core Web Vitals directly affect ranking?
Yes. Pages in position 1 are 10% more likely to cover all thresholds (ALM Corp, 2025). Covering all three metrics correlates with a 24% lower bounce rate (Digital Applied, 2026), and every second of delay reduces conversions by 7%.
How many WordPress sites cover Core Web Vitals?
Only 44% on mobile (CoreWebVitals.io, end of 2025). Shopify, 65%; Wix, over 60%. The average WordPress site with no optimisation scores 40-70/100 in Lighthouse. The reason is theme bloat, excessive plugins and a lack of optimisation – problems the WordPress Performance Stack framework addresses systematically.
What replaced FID?
INP (Interaction to Next Paint) replaced FID in March 2024. INP measures responsiveness across every interaction throughout the whole session, not just the first one. The threshold is under 200ms.
Which is the best caching plugin for WordPress?
WP Rocket is the leading paid plugin, easy configuration, stable, activates 80% of optimisations automatically. LiteSpeed Cache is more powerful on LiteSpeed servers (free, server-level). FlyingPress is an alternative with a focus on Core Web Vitals. The choice depends on the hosting.
Can I reach 100/100 in PageSpeed Insights?
On simple static pages, yes. On a functional business site with forms, analytics and dynamic content, that is rarely necessary. The goal is Lighthouse ≥90 on mobile and covering LCP < 2.5s, INP < 200ms, CLS < 0.1.
Does hosting matter?
Significantly. Shared hosting: TTFB ~600ms. Managed WordPress hosting: ~200ms or less. For a business site: managed hosting or a VPS with NVMe, PHP 8.3+, Redis is the minimum level, precisely what the Infrastructure Layer of the WordPress Performance Stack requires.
What is the WordPress Performance Stack and how is it applied?
It is a 5-layer framework for the systematic optimisation of WordPress speed: the Infrastructure Layer (hosting, PHP 8.3+, Redis, CDN), the Foundation Layer (a light block theme, a minimum of plugins), the Asset Optimization Layer (images, fonts, JavaScript), the Caching Layer (page/object/browser cache) and the Monitoring Layer (lab + field data, continuous monitoring). The principle: neglecting any layer compromises the results. Start from the bottom up, not from the Caching Layer.
Conclusion
Core Web Vitals are not a one-off exercise – they are a continuous process that starts with architectural decisions and continues with regular optimisation. The WordPress Performance Stack from this article provides a structured approach that turns chaotic optimisation into systematic work: Infrastructure (hosting + CDN), Foundation (a light theme + a minimum of plugins), Asset Optimization (images + fonts + JS), Caching (caching at every level) and Monitoring (lab + field data).
The principle is simple: start from the foundation, not from the top. A caching plugin on top of shared hosting with a heavy theme and 25 plugins is cosmetic, not a solution. A complete stack with managed hosting, a block theme, optimised images, correct caching and continuous monitoring is the difference between a WordPress site with 50/100 in Lighthouse and one with 95/100.
The numbers justify the investment: every second of delay costs 7% of conversions, position-1 pages are 10% more likely to cover the CWV thresholds, and sites with “good” Core Web Vitals have a 24% lower bounce rate. In the context of 2026, with Google’s December core update and the growing weight of user experience in ranking, performance is not a technical detail – it is a business priority.
If your current WordPress site struggles with slow loading, a low Lighthouse score and poor Core Web Vitals, do not rely on a “magic” plugin. Talk to the CreateWeb team for a free consultation. We will apply the WordPress Performance Stack to your specific case and propose an optimisation plan that addresses every layer systematically. Browse our portfolio for real project examples where performance is built in from the start.
For related specialised resources: WordPress as a platform, quality web hosting, customising WordPress with FSE, the central SEO article, SEO web design, the central article on website analysis, analysis tools, Google Analytics 4, marketing metrics, WordPress maintenance, the central article on building websites.
If you want this done by a team, see our website analysis service.
