Core Web Vitals are currently the most important technical ranking signal in Google, and at the same time the strongest objective measure of perceived user quality on a website. Three metrics: LCP, INP and CLS, measured in CrUX field data, define how Google judges the user comfort on your site. This article breaks down each metric into its parts: what it measures, what the thresholds are, common causes of poor scores, and a concrete repair plan. The material is grounded in our audits for DACH and Polish clients, where Core Web Vitals are a standing item on the agenda.
What Core Web Vitals are and why Google weighs them in SEO
Core Web Vitals are a set of three metrics introduced by Google in May 2020 as a response to growing user frustration with slow and unstable mobile sites. May 2021 was the official inclusion of these metrics in the Google algorithm as a Page Experience signal. In March 2024 INP replaced the previous FID as the third metric, which forced an update of tools and audit methodologies across the industry.
The weight of Core Web Vitals in Google rankings is estimated at 5 to 10 percent in competitive niches, and in low-competition niches functions as a tie-breaker between sites of similar authority and content quality. Put differently: Core Web Vitals alone will not push a page into the top 3 for a hard keyword, but among 4 sites with comparable content the one with better metrics usually wins.
There is an important distinction between Core Web Vitals as a “ranking factor” and as a “user experience signal”. Google does not publish the exact weight, but empirically, from analyses of thousands of sites, dropping from “good” to “poor” on any metric correlates with a 10 to 30 percent decline in CTR and ranking, regardless of formal ranking impact.
A Core Web Vitals audit is a standing item in every website audit we run. Without LCP, INP and CLS numbers, a conversation about performance is based on impressions. With numbers it becomes an engineering conversation, where every finding has a measurable baseline and a measurable target after the fix.
LCP (Largest Contentful Paint): interpretation
LCP measures the time between the start of page load and the render of the largest element visible above the fold. That element is usually a hero image, the main H1, a video banner, or a block with a large block of text above the fold. Google publishes precise thresholds: under 2.5 seconds is “good”, 2.5 to 4 seconds is “needs improvement”, above 4 seconds is “poor”.
In practice, for WordPress sites on typical shared hosting in Poland, the baseline LCP without optimisation sits at 2.8 to 4.5 seconds. After a full audit and quick-win rollout we typically land at 1.4 to 2.2 seconds. Our own studio site hits 1.4 second LCP on mobile in CrUX field data, putting it in the top 10 percent of the custom WordPress development niche in Poland.
Most common causes of weak LCP in our audits: hero image without fetchpriority=”high” and without preload (the single biggest cause, about 40 percent of cases), slow server response time above 600 ms (typically a shared hosting issue with LiteSpeed Cache disabled or misconfigured), render-blocking CSS and synchronously loaded web fonts before first paint, third-party scripts blocking the main thread in the first second (Google Tag Manager, chat widgets such as Tawk or Crisp).
LCP repair plan in five steps: add fetchpriority=”high” on the hero image and a preload link in the head, convert the hero image to WebP or AVIF (60 to 80 percent file size reduction), add a responsive srcset with 4 variants (480w, 768w, 1280w, 1920w), enable LiteSpeed Cache or WP Rocket for full page caching (TTFB from 600 ms to 80 ms), defer all third-party scripts with the async attribute or the strategy “lazyOnload”.
A concrete example from practice: a B2B flooring niche client with a 2.3 MB hero PNG loaded via an img tag without a priority hint, LCP in CrUX 4.8 seconds on mobile. After rolling out WebP responsive srcset (total size 180 KB) plus fetchpriority=”high” plus preload, LCP dropped to 1.9 seconds. Implementation time 1.5 hours, fee 300 PLN, measurable impact in Google Search Console within 14 days as an average position gain of 3.2 points.
INP (Interaction to Next Paint): interpretation
INP replaced FID in March 2024 as the third official Core Web Vitals metric. INP measures the slowest user interaction across the entire session on the page. An interaction is a click, a tap, a keypress. Google counts the 75th percentile of interactions across visitors. Thresholds: under 200 ms is “good”, 200 to 500 ms is “needs improvement”, above 500 ms is “poor”.
The difference between FID and INP is significant. FID measured only the delay of the first interaction, so sites with a good first paint but bad overall JavaScript performance could ship FID below 100 ms. INP measures the slowest interaction, which pulls out mid-session JavaScript problems (opening a modal, filtering products in WooCommerce, an FAQ accordion).
Most common causes of weak INP in audits: long JavaScript tasks above 50 ms blocking the main thread (typically React reconciliation cost or heavy event handlers), third-party scripts executing reactively on interactions (analytics, chat widgets, cookie consent UI re-rendering after accept), heavy event handlers on frequently clicked elements (for example WooCommerce add-to-cart with pricing calculated in JavaScript instead of PHP).
INP repair plan: identify long tasks in the Chrome DevTools Performance tab with 4x CPU throttle (simulating a mid-range mobile), move heavy computation off the main thread into a Web Worker, use scheduler.yield() to break long tasks into chunks, reduce the number of third-party scripts (every chat widget blocks the main thread by 80 to 200 ms), optimise React or Vue components with useMemo and React.memo.
For a typical WordPress site without a frontend JavaScript framework INP usually sits at 80 to 150 ms (good), so it rarely needs active optimisation. Trouble starts in WooCommerce stores with many filters (AJAX filtering rebuilding the full HTML instead of a client-side filter) and on sites with active chat widgets such as Intercom or HubSpot. INP can jump to 350 to 600 ms on mobile in those cases.
A practical observation: INP improves materially after moving analytics to server-side GTM instead of client-side. Server-side GTM reduces the number of third-party scripts executing in the browser from 8 to 15 down to 1 to 2 (the GTM container itself plus optional consent UI). The average INP improvement in our audits is 80 to 120 ms, moving from “needs improvement” to “good”. The setup cost for server-side GTM is 4 to 6 hours of work plus 5 to 15 EUR per month for the endpoint hosting.
CLS (Cumulative Layout Shift): interpretation
CLS measures the sum of all unexpected layout shifts over a user session. Each shift carries a weight calculated as the product of the viewport fraction the shift impacted and the shift distance. CLS is unitless, but its thresholds are clear: under 0.1 is “good”, 0.1 to 0.25 is “needs improvement”, above 0.25 is “poor”.
CLS is the metric most often neglected in audits done in a hurry, because it does not surface as “the site is slow”. Instead it surfaces as frustration like “I clicked a button but the layout shifted and I clicked an ad” or “I was reading text and an image loaded and pushed everything down”. These experiences damage brand perception even more than slow loading.
Most common causes of weak CLS: images without width and height attributes (the browser does not know the aspect ratio, so once loaded it pushes the content), web fonts loading with FOIT (Flash of Invisible Text) causing re-layout when the font arrives, dynamically inserted content (cookie banner, newsletter popup, A/B test variant) without reserved space, ads and iframes without fixed dimensions, lazy-loaded images without an aspect-ratio CSS.
CLS repair plan in five steps: add width and height on every img tag (or aspect-ratio CSS), use font-display: swap with preload for critical fonts plus fallback font matching (Adobe font-style-matcher), reserve space for the cookie banner with fixed height and transform: translateY instead of display: block, set aspect-ratio on all iframe embeds, use content-visibility: auto on long pages for skip rendering.
From our practice CLS is the cheapest of the three metrics to fix. Most fixes are pure CSS plus theme template corrections, without touching backend PHP. A client without technical backing can implement most CLS quick wins themselves if they have child theme access. Our audit delivers a precise list with file line numbers and suggested code to add.
Concrete example: a client in legal services had CLS 0.34 in CrUX, mostly because of a cookie banner loaded asynchronously after 800 ms (the banner pushed content down by 96 pixels on mobile). After reserving a fixed 96px height placeholder for the cookie banner and applying transform: translateY(-96px) on the hide state, CLS dropped to 0.04. Implementation time 45 minutes.
Field data vs Lab data: what counts for Google
A critical distinction in Core Web Vitals audits: field data versus lab data. Google uses field data (CrUX, Chrome User Experience Report) as a ranking factor. Lab data (Lighthouse, WebPageTest) serves as a developer tool for debugging, but it does not by itself influence rankings.
CrUX field data is collected anonymously from real Chrome users who enabled “URL keywords” in sync. The data is aggregated at the origin level (domain plus subdomains) or at individual URL level, provided that URL has a minimum of 1000 visits in a 28 day window. Smaller sites might lack URL-level data and only have origin-level data.
Lighthouse lab data is a simulation: 4x throttled CPU, throttled “Slow 4G” network (1.6 Mbps download, 150 ms RTT), Chrome without extensions, 360×640 viewport. It is repeatable, good for CI/CD, but does not reflect real-world experience. A client on an iPhone 15 Pro on 5 GHz WiFi will see the site 3 to 4 times faster than Lighthouse shows.
Our practice: we test both metrics, but the decision priority is CrUX. Lighthouse is a development tool (“did I optimise the fix and can I see it locally?”), CrUX is the truth tool (“did the fix improve real users in 28 days?”). Clients do not look at Lighthouse, they look at the PSI public score, which combines CrUX (if available) with Lighthouse.
Tools: PSI vs Lighthouse vs WebPageTest vs Chrome DevTools
A Core Web Vitals audit is not done with one tool. Every tool has its strengths and limitations, and a good audit uses 3 to 4 tools in sequence.
PageSpeed Insights is the first stop. It shows CrUX field data plus a single Lighthouse run. Good for quick checks and client communication, since the PSI score (0 to 100) is understandable for a non-technical decision-maker. Not suited for debugging a single issue, because the Lighthouse run is just one and can be noisy.
Lighthouse in Chrome DevTools delivers a detailed lab report with audits, recommendations and source links. Ideal for iterative development: change something, run Lighthouse, check if the score went up. It can be run headless in CI/CD via @lhci/cli, capturing score regressions in pull requests.
WebPageTest is the gold standard for deep debugging. Waterfall view with millisecond-level granularity, supports custom throttling (3G Poland, Germany), multiple locations (test from US, Sydney, Frankfurt at once), filmstrip view (frame by frame visual rendering). Paid in the full version, but the public WebPageTest.org covers 80 percent of cases.
The Chrome DevTools Performance tab is the deepest tool, but it requires experience. It shows a flame chart of all function calls on the main thread, network waterfall, layout shift events, long tasks. Indispensable when debugging INP issues (where exactly does the main thread block during an interaction?).
Quick wins that lift Vitals in one week
A practical quick win list for a typical WordPress site that a 1 to 2 person team can ship in 5 to 8 hours of work. Each quick win carries an estimated impact in LCP seconds or Lighthouse points.
- Convert the hero image to WebP plus responsive srcset (LCP reduction 0.8 to 1.5s).
- Add fetchpriority=”high” and a preload link on the hero image (LCP reduction 0.3 to 0.6s).
- Enable LiteSpeed Cache or WP Rocket for full page caching (TTFB reduction 400 to 600ms).
- Defer non-critical JavaScript via async or the “lazyOnload” strategy (INP reduction 50 to 150ms).
- Add width and height on all img tags (CLS reduction 0.05 to 0.15).
- Font-display: swap with preload on critical fonts (CLS reduction 0.03 to 0.08 plus faster first text paint).
- Lazy-load below-fold images with native loading=”lazy” (smaller data usage, better Lighthouse score).
These 7 quick wins rolled out together turn a typical WordPress site from a 50 to 65 Lighthouse score into an 85 to 95 score. Further optimisations (Critical CSS extraction, HTTP/2 push, edge caching) add another 5 to 10 points but require advanced expertise and live inside our full services.
Our preferred stack for aggressive Core Web Vitals optimisation is WordPress plus Astra Pro plus custom child theme plus LiteSpeed Cache plus Cloudflare as CDN. This configuration delivers out-of-the-box Lighthouse 90+ on most sites, without resorting to advanced custom code. The Next.js plus Vercel alternative is the route for custom clients with a budget, where SSG plus edge functions deliver LCP below 800 ms.
FAQ
How often should I check Core Web Vitals?
CrUX updates monthly with a 28 day collection window. Checking daily has no value, the data will not move faster. We recommend monthly monitoring via PSI plus an alert in Google Search Console on the “Page experience” report. After a fix, check weekly for 4 weeks to see the trend.
Can WordPress reach a Lighthouse 99/100?
Yes. Our own studio site scores 98 to 99 performance on mobile, 100 on desktop. One of our property developer clients scores 100/100/100/100 across all four categories. WordPress is not a performance blocker, the blocker is the choice of theme and plugins. Astra Pro plus a custom child theme plus 8 to 10 core plugins instead of 35 random ones.
Does TTFB count for Google?
TTFB (Time To First Byte) is not an official Core Web Vital, but it feeds into LCP. A fast TTFB below 200 ms wins 1 to 2 seconds in LCP. Google recommends TTFB under 600 ms as the “good” threshold. The simplest way to a good TTFB is full page caching plus shared hosting in the same geography as the majority of traffic.
Mobile vs desktop scores: which one matters more?
Mobile. Google moved to mobile-first indexing in 2021, so the ranking is based primarily on the mobile version of the site. Desktop score matters for user experience, but for SEO the priority is decisively mobile. Always check mobile first, desktop as a secondary check.
If you want a Core Web Vitals audit quote for your site, drop us a line with the page URL. Reply with a preliminary PSI read plus recommendations within 24 hours. Full audit 1500 to 3000 PLN, deliverable in 5 to 10 business days.