Skip to content 
A real estate agency in Vancouver called me last September because their Google rankings had been dropping steadily for three months. Traffic was down 23%. They’d checked their backlinks, their content was solid, and no algorithm update seemed to explain it. Fifteen minutes into my technical audit, I found the answer: all three Core Web Vitals were failing. LCP was 6.2 seconds (threshold: 2.5s). INP was 340ms (threshold: 200ms). CLS was 0.28 (threshold: 0.1). Google had been warning them through Search Console for months, but nobody was checking. Three weeks of optimization later: LCP dropped to 1.9s, INP to 78ms, CLS to 0.03. Rankings recovered within 45 days. Traffic returned and exceeded the previous baseline by 11%.
Core Web Vitals are Google’s page experience metrics. They directly influence rankings. Not as a tiebreaker, but as a measurable ranking factor that compounds across every page on your site. This guide covers what each metric measures, why WordPress sites specifically fail them, and the exact fixes I apply across client sites on Upwork.
What Are Core Web Vitals?
Three metrics that measure real-user experience on your website:
LCP (Largest Contentful Paint). How long until the biggest visible element loads. Usually your hero image or main heading. Threshold: under 2.5 seconds = good. 2.5-4 seconds = needs improvement. Over 4 seconds = poor.
INP (Interaction to Next Paint). How fast your page responds when someone clicks, taps, or types. Replaced FID in March 2024. Threshold: under 200 milliseconds = good. 200-500ms = needs improvement. Over 500ms = poor.
CLS (Cumulative Layout Shift). How much the page content jumps around while loading. Text shifting down when an ad loads, buttons moving when a font swaps in, content bouncing when images appear. Threshold: under 0.1 = good. 0.1-0.25 = needs improvement. Over 0.25 = poor.
Google measures these using real user data from Chrome browsers (CrUX data), not lab tests. Your PageSpeed Insights score can be 95, but if real users on mobile connections experience slow loads, Google uses the real data for rankings. The field data section of PageSpeed Insights shows what Google actually sees.
Where to Check Your Core Web Vitals
Google Search Console > Core Web Vitals. The definitive source. Shows page-level data grouped by status (good, needs improvement, poor) for both mobile and desktop. This is the exact data Google uses for ranking decisions. Check this first.
PageSpeed Insights (pagespeed.web.dev). Enter any URL. The “field data” section (top) shows real-user CrUX data. The “lab data” section (bottom) shows simulated test results. Field data matters for rankings. Lab data helps diagnose issues but doesn’t directly affect rankings.
Chrome DevTools > Performance tab. The most detailed diagnostic tool. Record a page load, and the performance panel shows exactly which elements cause LCP delays, which scripts cause INP problems, and which layout shifts cause CLS issues. Press F12, click Performance, click the record button, reload the page, stop recording.
Web Vitals Chrome Extension. Real-time overlay showing LCP, INP, and CLS as you browse your own site. Useful for spotting issues during development and testing.
LCP: How to Get Under 2.5 Seconds on WordPress
LCP is the metric most WordPress sites fail. The largest element is usually a hero image, header background, or above-the-fold heading block. Everything between the user’s click and that element appearing counts toward LCP.
LCP has four components: server response time (TTFB), resource load delay (how long before the browser starts loading the LCP element), resource load duration (how long the LCP element takes to download), and element render delay (how long after download until it appears on screen). Fix each one:
Fix 1: Reduce TTFB (server response time).
Your server needs to respond in under 200ms. Shared hosting often exceeds 600ms before a single byte reaches the browser. The fix is hosting infrastructure. Cloudways Vultr High Frequency ($14-$28/month) consistently delivers 80-150ms TTFB. SiteGround GrowBig ($15/month) delivers 100-180ms. Kinsta ($35+/month) delivers 60-120ms. Enable server-level page caching (every quality host provides this). Add Cloudflare CDN (free tier works) to serve cached pages from edge servers closest to your visitors. I covered hosting recommendations in detail in the speed optimization guide.
Fix 2: Optimize the hero image.
The hero image or background is the LCP element on 70%+ of pages I audit. Optimization checklist: serve WebP format (30-50% smaller than JPEG at equivalent quality), resize to actual display dimensions (if the hero container is 1200px wide, don’t upload a 3000px image), compress to 80-85% quality (visually indistinguishable from 100% but dramatically smaller), set explicit width and height attributes (prevents CLS and helps the browser allocate space immediately), and add fetchpriority=”high” to the hero image tag so the browser prioritizes it over other resources.
Never lazy-load your hero image. Lazy loading delays images until they’re near the viewport. Your hero image is already in the viewport on page load. Lazy loading it adds an unnecessary delay directly to your LCP time. ShortPixel, Imagify, or Smush handle automatic compression and WebP conversion.
Fix 3: Inline critical CSS.
The browser can’t render anything until it downloads and parses your CSS files. If your main stylesheet is 200KB, the browser must download all 200KB before painting the first pixel. Critical CSS extracts only the styles needed for above-the-fold content and inlines them directly in the HTML head. The browser renders above-the-fold content immediately while the full stylesheet loads asynchronously. WP Rocket handles this automatically with “Optimize CSS Delivery” enabled. For manual control, use the Critical CSS plugin with Autoptimize.
Fix 4: Preload the LCP image.
Add a preload hint in the HTML head so the browser starts downloading the hero image immediately, before it even encounters the img tag in the page body. In WordPress, add to your theme’s header or via a plugin: a link rel=”preload” tag pointing to your hero image with as=”image” and the correct type. WP Rocket’s preload feature handles this, or use Perfmatters for manual preload control.
INP: How to Get Under 200ms on WordPress
INP measures responsiveness. When someone clicks a button, taps a menu, or types in a form, INP measures the delay between their action and the browser’s visual response. WordPress sites fail INP primarily because of JavaScript bloat from plugins.
Why WordPress sites have INP problems. Every plugin that adds front-end interactivity loads JavaScript. A slider plugin, a popup plugin, a chat widget, an analytics tracker, a social sharing plugin, a lazy loading plugin, a consent banner, and a newsletter popup. Each one adds event listeners to the page. When the user interacts, the browser must process all active JavaScript before responding visually. Ten plugins with event listeners create a queue of JavaScript execution that delays every interaction.
Fix 1: Audit and reduce JavaScript.
Open Chrome DevTools > Coverage tab (Ctrl+Shift+P, type “coverage”). Reload the page. The coverage report shows how much of each JavaScript file is actually used. Most WordPress sites have 60-80% unused JavaScript loading on every page. The culprits are typically: slider plugins loading on pages without sliders, contact form plugins loading on pages without forms, WooCommerce cart fragments loading on non-shop pages, and popup/chat widget scripts initializing before the user could possibly interact with them.
Use Perfmatters or Asset CleanUp to disable JavaScript on pages where specific plugins aren’t needed. A contact form plugin should only load its JavaScript on pages with a contact form. This alone can reduce JavaScript payload by 40-60%.
Fix 2: Defer and delay JavaScript.
Defer: tells the browser to download the script without blocking page rendering, then execute after HTML parsing completes. Delay: tells the browser to not even download the script until the user interacts with the page (scrolls, clicks, taps, moves mouse). WP Rocket provides both options. Defer JavaScript adds the defer attribute to non-critical scripts. Delay JavaScript execution (WP Rocket’s key INP feature) holds all non-essential JavaScript until user interaction. This means the page loads with zero JavaScript processing overhead, and scripts only execute when the user actually needs them.
Scripts that should be deferred: analytics, social widgets, non-critical animations. Scripts that should be delayed: popup builders, chat widgets, comment systems, social sharing buttons. Scripts that should NOT be deferred or delayed: critical navigation, above-the-fold interactivity, consent management.
Fix 3: Minimize main thread work.
Long tasks (JavaScript execution exceeding 50ms) block the main thread and create INP delays. Chrome DevTools Performance panel shows long tasks as red-flagged blocks. Common WordPress long tasks: theme JavaScript initializing complex menus, Elementor front-end scripts calculating responsive layouts, WooCommerce cart fragment updates via AJAX, and Google Analytics processing. For Elementor sites specifically: disable unused Elementor experiments, minimize motion effects on mobile, and use Elementor’s built-in performance settings (improved asset loading, reduced DOM output).
CLS: How to Get Under 0.1 on WordPress
CLS measures visual stability. Every time a visible element moves after initial render, it contributes to your CLS score. Users find layout shifts frustrating, especially on mobile where a shifted button causes a mis-tap.
Fix 1: Set explicit image dimensions.
The most common CLS cause. A browser encounters an img tag without width and height. It doesn’t know how tall the image will be, so it allocates zero space. The image downloads, and the browser pushes all content below it downward. This single shift can produce a CLS of 0.15+, failing the metric from one image.
Every image in your WordPress content must have width and height attributes. Elementor adds these automatically for images placed through its widgets. For images in Gutenberg content, WordPress 5.5+ adds width and height automatically. For background images, set min-height on the container in CSS so the space is reserved before the image loads.
Fix 2: Preload fonts and use font-display: swap.
Custom fonts cause two types of CLS. First, the browser renders text in a fallback font, then swaps to the custom font when it loads. If the custom font has different character widths, every line of text reflows, causing massive layout shifts. Second, if using font-display: block, the browser shows invisible text until the font loads, then all text appears at once causing a shift.
The fix: preload your primary font files so they’re available before first render, use font-display: swap (text appears in fallback font immediately, swaps to custom font when ready), and choose fallback fonts with similar metrics to minimize reflow. Astra theme handles font loading efficiently by default. If using Google Fonts, host them locally (OMGF plugin or Perfmatters) to eliminate the render-blocking Google Fonts stylesheet.
Fix 3: Reserve space for dynamic content.
Ads, embeds, and lazy-loaded elements that appear after initial render push content down. For any element that loads dynamically, set explicit dimensions on its container before the content loads. For iframe embeds (YouTube, Google Maps), always include width and height attributes or use CSS aspect-ratio. For cookie consent banners, position them as fixed/sticky overlays rather than pushing page content down. For WooCommerce sites, set explicit height on product image galleries to prevent shifts during image lazy loading.
Fix 4: Avoid injecting content above existing content.
Notification bars, announcement banners, and sticky headers that push content down after page load cause CLS. Render these elements server-side in the initial HTML rather than injecting them via JavaScript after load. If using Elementor popups or notification bars, configure them to appear on load rather than after a delay.
The WordPress CWV Optimization Stack
The specific tools I use on every client site to pass all three metrics:
Hosting. Cloudways Vultr High Frequency or Kinsta. TTFB under 200ms. This is the foundation. No amount of plugin optimization compensates for slow hosting.
Caching. WP Rocket ($59/year). Page caching, browser caching, Optimize CSS Delivery (critical CSS), Delay JavaScript Execution (major INP improvement), lazy loading (with hero image excluded), database optimization, and Cloudflare CDN integration.
Images. ShortPixel or Imagify for automatic WebP conversion and compression on upload. Target 80-85% quality. Maximum upload dimensions matching display size. Explicit width and height on every image.
Fonts. Self-hosted (OMGF or manual), preloaded, font-display: swap. Maximum 2 font families to limit HTTP requests.
Asset management. Perfmatters ($24.95/year) for per-page script/style control. Disable unused CSS and JavaScript on pages where specific plugins aren’t needed. This is the highest-impact INP optimization for sites with 10+ plugins.
Theme. Astra Pro. Under 50KB. Clean DOM output. Built-in performance optimizations. Zero render-blocking resources from the theme itself. Combined with Elementor Pro’s improved asset loading, the theme layer adds virtually zero performance overhead.
This stack consistently produces: LCP under 2 seconds, INP under 100ms, CLS under 0.05, and PageSpeed scores of 90+ on both mobile and desktop. The full speed optimization process covers implementation details.
Testing and Verification
After implementing fixes, verify systematically:
Immediate testing. Run PageSpeed Insights on 5 representative pages: homepage, a service page, a blog post, a product page (if e-commerce), and the most image-heavy page on your site. All should show green Core Web Vitals in lab data.
Field data (real users). CrUX field data in PageSpeed Insights and Search Console updates approximately monthly. After optimization, expect 2-4 weeks before field data reflects improvements. The “28-day collection period” means Google needs a full month of real-user data showing passing metrics before your field data updates.
Ongoing monitoring. Google Search Console > Core Web Vitals report. Set a monthly calendar reminder to check this report. URL groups showing “needs improvement” or “poor” need immediate attention before they impact rankings. A single failing URL template (like all blog posts or all product pages) can drag down your entire site’s page experience signal.
Frequently Asked Questions
Do Core Web Vitals actually affect rankings?
Yes. Google confirmed Core Web Vitals as a ranking factor in 2021 and expanded their weight with each page experience update. They’re not the strongest ranking factor (content relevance and backlinks still dominate), but they’re a measurable factor that compounds across pages. In competitive niches where content quality is similar between competitors, Core Web Vitals often determine who ranks 3rd versus 8th.
My PageSpeed score is 95 but Search Console shows failing CWV. Why?
PageSpeed lab score simulates loading on a controlled connection. Search Console uses real-user data from Chrome. If your visitors are on slow mobile connections or older devices, their experience may be worse than the lab simulation. Fix for real-user data, not lab scores.
Which metric matters most for SEO?
LCP has the strongest correlation with rankings in my testing across client sites. A 4+ second LCP consistently correlates with lower positions than competitors with similar content and backlink profiles. INP matters increasingly as Google has strengthened its weighting since the FID-to-INP transition in 2024.
Can plugins alone fix Core Web Vitals?
Plugins handle 70-80% of optimization. The remaining 20-30% requires hosting quality, image preparation before upload, and theme/builder configuration. WP Rocket + Perfmatters + quality hosting handles most sites. Complex sites with heavy JavaScript or large product catalogs may need deeper technical optimization.
How often should I check Core Web Vitals?
Monthly minimum via Google Search Console. After any major site change (new plugin, theme update, design changes), re-test immediately. Set up real-time monitoring with the Web Vitals extension during development.
Need Core Web Vitals Fixed?
Core Web Vitals optimization is a fixed-price project on Upwork. I audit all three metrics, identify every failing element, implement the fixes, and verify with before/after data. Most sites pass all three metrics within 1-2 weeks of optimization. Same stack, same process, proven across 400+ projects.
Browse the portfolio, case studies, and reviews. Related: speed optimization, technical SEO, SEO audits, WordPress development, Elementor, WooCommerce, maintenance, and malware removal. Guides: speed guide, technical SEO checklist, RankMath vs Yoast, and starting an online store. FAQ. Contact.
