How to Improve WordPress Core Web Vitals (LCP, CLS, INP)
Core Web Vitals are three specific performance metrics that Google uses as ranking factors: Largest Contentful Paint (LCP) measures loading speed and should be under 2.5 seconds, Cumulative Layout Shift (CLS) measures visual stability and should be under 0.1, and Interaction to Next Paint (INP) measures responsiveness and should be under 200 milliseconds. Failing any of these metrics can directly hurt your Google search rankings, even if your content is excellent.
Unlike generic page speed scores, Core Web Vitals measure specific aspects of user experience that Google considers most important. A site can score 90/100 on PageSpeed Insights but still fail individual Core Web Vitals metrics — and it is the individual metrics that affect rankings, not the overall score. This guide covers how to diagnose and fix each metric specifically for WordPress sites.
For a broader overview of all WordPress speed optimization techniques, see our comprehensive speed guide. This article focuses specifically on the three Core Web Vitals metrics and the WordPress-specific fixes for each.
How to Measure Your Core Web Vitals
Google PageSpeed Insights (pagespeed.web.dev) is the primary measurement tool. Enter your URL and check the “Core Web Vitals Assessment” section. It shows two data sets: “Field Data” (real user measurements collected from Chrome users over the past 28 days — this is what Google actually uses for ranking) and “Lab Data” (simulated measurements from a controlled test — useful for debugging but not used for ranking).
If your site has enough traffic, the Field Data section shows green (good), yellow (needs improvement), or red (poor) for each metric. If Field Data is not available (low-traffic sites), rely on Lab Data but understand it may not perfectly represent real-world performance.
Google Search Console → Core Web Vitals report shows your site-wide performance across all pages, grouped by good, needs improvement, and poor. This is the best place to monitor trends over time and identify which pages need attention.
Chrome DevTools → Performance tab provides detailed breakdowns of rendering, scripting, and layout activity — essential for diagnosing specific CLS and INP issues.
Fixing Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element on the page to finish rendering. On most WordPress pages, the LCP element is either a hero image, a large heading, or a featured image. Google considers LCP good if under 2.5 seconds, needs improvement between 2.5 and 4 seconds, and poor if above 4 seconds.
Identify Your LCP Element
In PageSpeed Insights, scroll to the “Diagnostics” section and look for “Largest Contentful Paint element.” It will tell you exactly which element is your LCP — whether it is an <img> tag, an <h1>, a background image, or a video poster. Knowing what the LCP element is determines which fixes to apply.
If LCP Element Is an Image
Do NOT lazy load it. This is the most common LCP mistake on WordPress sites. WordPress adds loading="lazy" to images by default since version 5.5. If your hero image or featured image has this attribute, the browser delays loading it until it is near the viewport — which defeats the purpose for an above-the-fold image. Remove the lazy loading attribute from your LCP image. You can do this with a filter in your theme’s functions.php or by using your optimization plugin’s settings to exclude above-the-fold images from lazy loading.
Preload the LCP image. Add a <link rel="preload"> tag in your page’s <head> section to tell the browser to start downloading the LCP image immediately, before it even begins parsing the page HTML. Some performance plugins (WP Rocket, Perfmatters) can add preload tags automatically for LCP images.
Compress and serve in modern format. Ensure your LCP image is compressed (using ShortPixel, Imagify, or similar — see our image optimization guide) and served in WebP format. A 2 MB hero image served as an uncompressed JPEG will always have a poor LCP. The same image compressed and converted to WebP might be 200 KB — loading 10× faster.
Serve from CDN. If your LCP image is served from your origin server and the visitor is far away geographically, network latency adds directly to LCP time. A CDN serves the image from an edge server near the visitor, eliminating most of the latency.
If LCP Element Is Text (Heading or Paragraph)
Reduce render-blocking resources. If heavy CSS or JavaScript files must download before the browser can render any text, LCP is delayed. Defer non-critical JavaScript, inline critical CSS, and eliminate unused CSS. See our guide on deferring render-blocking resources.
Optimise web font loading. If your LCP heading uses a custom web font, the browser must download the font file before it can render the text. Use font-display: swap in your font face declarations — this tells the browser to display text immediately using a fallback font, then swap in the custom font when it loads. Preload critical font files with <link rel="preload" as="font">.
Server-Side LCP Improvements
Reduce TTFB. Time to First Byte is the foundation — if your server takes 2 seconds to respond, LCP cannot possibly be under 2 seconds. Enable page caching (see our caching plugin guide), upgrade PHP to 8.1+, and consider better hosting if TTFB remains above 600ms. See our TTFB reduction guide.
Fixing Cumulative Layout Shift (CLS)
CLS measures how much the page layout shifts unexpectedly as content loads. Every time a visible element moves position — text jumps down, a button shifts sideways, content repositions — it contributes to CLS. Google considers CLS good if under 0.1, needs improvement between 0.1 and 0.25, and poor above 0.25.
Common CLS Causes in WordPress
Images without dimensions. When an image tag does not have width and height attributes, the browser does not know how much space to reserve for it. As the image downloads, the browser must recalculate the layout — pushing text and other elements around. WordPress adds width and height to images uploaded through the media library, but images added through page builders, custom code, or third-party plugins may lack these attributes. Check your pages and add explicit dimensions to any images missing them.
Dynamically injected content. Ads, email signup popups, cookie consent banners, live chat widgets, and notification bars that inject content into the page after initial load cause layout shifts. The fix is to reserve space for these elements in your CSS before they load — set a minimum height for ad containers, position notification bars as fixed/sticky (so they do not push content), and configure popups as overlays rather than inline elements.
Web font swapping. When a custom font loads and replaces the fallback font, text can change size — causing everything around it to shift. Use font-display: swap combined with a fallback font that closely matches the dimensions of your custom font. The CSS size-adjust property can fine-tune the fallback font’s metrics to match the custom font even more closely, virtually eliminating font-swap shifts.
Embeds without dimensions. YouTube videos, Google Maps, social media embeds, and iframe content that load without explicit width and height cause layout shifts as they render. Wrap embeds in a container with a fixed aspect ratio using CSS (e.g., padding-top: 56.25% for 16:9 video) to reserve the correct space before the embed loads.
Late-loading above-the-fold elements. Sliders, carousels, and hero sections that load via JavaScript after the initial HTML renders cause the entire page to shift when they appear. These elements should render immediately with the initial HTML — not be injected by JavaScript after page load.
How to Debug CLS
In Chrome DevTools, open the Performance tab and click the record button. Interact with the page (scroll, click). Stop recording. In the timeline, look for “Layout Shift” entries. Click each one to see which element shifted and by how much. This pinpoints exactly which elements are causing your CLS problems.
Fixing Interaction to Next Paint (INP)
INP measures how quickly the page responds when a user interacts with it — clicking a button, tapping a link, typing in a form field, expanding an accordion. Google considers INP good if under 200 milliseconds, needs improvement between 200 and 500 milliseconds, and poor above 500 milliseconds. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
INP is the most difficult Core Web Vital to optimise on WordPress sites because it is caused by JavaScript execution blocking the browser’s main thread. Every plugin that loads JavaScript adds potential main-thread work that can delay responses to user interactions.
Common INP Causes in WordPress
Heavy JavaScript from plugins. Analytics scripts, chat widgets, social sharing buttons, popup plugins, slider/carousel scripts, and page builder front-end code all add JavaScript that competes for the main thread. When a user clicks a button, the browser must complete any currently executing JavaScript before it can process the click — if a plugin is running a heavy script at that moment, the click response is delayed.
Third-party scripts. Google Analytics, Facebook Pixel, Google Tag Manager, advertising scripts, and embedded social media widgets load JavaScript from external servers. These scripts are often large, execute complex code, and compete with your site’s own JavaScript for main-thread time.
Long tasks. Any JavaScript task that takes longer than 50 milliseconds is a “long task” that can block the main thread and delay user interactions. WordPress sites with many plugins often have multiple long tasks competing for execution.
How to Improve INP
Defer non-critical JavaScript. Use your caching or performance plugin’s “Delay JavaScript” feature to prevent non-essential scripts (analytics, chat, social) from loading until user interaction. WP Rocket, Flying Scripts, and Perfmatters all offer this capability. When a user interacts with the page, the deferred scripts load — but by then, the initial interaction has already been processed.
Reduce the number of plugins. Every active plugin that loads front-end JavaScript adds potential INP impact. Audit your plugins — deactivate and delete plugins you are not using, replace heavy plugins with lighter alternatives, and question whether each plugin truly needs to load JavaScript on every page. See our guide on choosing WordPress plugins without bloating your site.
Minimise third-party script impact. Load third-party scripts with async or defer attributes. Consider whether you need all the tracking scripts you are loading — many sites have Google Analytics, Google Tag Manager, Facebook Pixel, and multiple advertising scripts all loading simultaneously. Each one adds main-thread work that can delay interactions.
Break up long tasks. This is an advanced technique that typically requires developer involvement. JavaScript tasks that take longer than 50ms can be broken into smaller chunks using requestAnimationFrame or setTimeout patterns, allowing the browser to process user interactions between chunks.
Prioritising Your Fixes
If all three metrics need improvement, prioritise in this order. LCP first — it has the most visible impact on perceived speed and is usually the easiest to fix (image optimization and caching solve most cases). CLS second — layout shifts are annoying for users and the fixes are mostly straightforward (adding image dimensions, reserving space for dynamic content). INP last — it is the hardest to fix because it requires auditing and optimising JavaScript, which often means making trade-offs about which plugins to keep.
Frequently Asked Questions
Do Core Web Vitals really affect rankings?
Yes. Google has confirmed that Core Web Vitals are used as ranking signals. However, they are one factor among many — content relevance, backlinks, and domain authority are typically more impactful. That said, in competitive niches where multiple sites have similar content quality, Core Web Vitals can be the tiebreaker that determines which page ranks higher. Failing Core Web Vitals will not tank an otherwise excellent page, but passing them gives you an edge.
My PageSpeed score is 90+ but I still fail Core Web Vitals. How?
The overall PageSpeed score is a weighted composite of multiple metrics. You can have a high overall score while still failing individual Core Web Vitals. For example, excellent FCP and TTFB can boost your overall score even if your LCP is above 2.5 seconds or your CLS is above 0.1. Focus on the individual metric scores, not the overall number.
Why do my Lab Data and Field Data scores differ?
Lab Data is measured from a single simulated test on a controlled device and network. Field Data is aggregated from real Chrome users over 28 days — it includes the full range of devices, network speeds, and usage patterns your real visitors have. Field Data is what Google uses for ranking. Lab Data is useful for debugging but may not reflect real-world performance if your visitors use different devices or network conditions than the lab simulation.
How long after fixing Core Web Vitals will I see ranking improvements?
Google’s Field Data is collected over a rolling 28-day window. After you fix a Core Web Vitals issue, it takes approximately 28 days for the improved data to fully replace the old data in Google’s measurements. Ranking changes based on improved Core Web Vitals may take an additional few weeks after that. Expect 1–2 months from fix to visible ranking impact.
Need Expert Help? Let WP Ministry Handle It
Core Web Vitals optimization involves interdependent changes across images, caching, JavaScript, CSS, fonts, and hosting — and every change needs testing to ensure it does not break functionality. Our speed optimization service — included in Pro care plans and above — addresses all three Core Web Vitals metrics as part of a comprehensive performance optimization.
View our care plans → or call (901) 249-0909.
Related Articles
How to Speed Up Your WordPress Site (Complete 2026 Guide)