If you want to know how to improve Core Web Vitals, start by finding out which of the three metrics fails and on which page templates, then fix the cause behind that specific metric. Largest Contentful Paint (LCP) is usually a server or image problem, Interaction to Next Paint (INP) is usually a JavaScript problem, and Cumulative Layout Shift (CLS) is usually a layout problem. Chasing a single overall speed score wastes time; fixing the right metric on the right template does not.
This guide explains how to read the data, then gives specific fixes for each metric, with notes for WordPress and Shopify sites.
What the three Core Web Vitals measure
Google defines three metrics, each with a “good” threshold. According to Google’s web.dev documentation, a page passes when it meets all three at the 75th percentile of real page loads:
| Metric | What it measures | Good threshold |
|---|---|---|
| LCP (Largest Contentful Paint) | How long the main content takes to appear | 2.5 seconds or less |
| INP (Interaction to Next Paint) | How quickly the page responds to clicks, taps and key presses | 200 milliseconds or less |
| CLS (Cumulative Layout Shift) | How much the layout jumps around while loading | 0.1 or less |
The 75th percentile part matters. Your site does not pass because it is fast on your office connection. It passes when most real visitors, including people on mid-range phones and slow mobile networks, get a good experience.
Step 1: Read field data before lab data
Any plan for how to improve Core Web Vitals starts with the right data. There are two kinds, and mixing them up causes most wasted effort.
- Field data comes from real Chrome users. You see it in the Core Web Vitals report in Google Search Console and at the top of PageSpeed Insights. This is what counts.
- Lab data is a simulated test run on demand, shown as the score and diagnostics in PageSpeed Insights or Lighthouse. It is useful for debugging, not for judging success.
Open the Core Web Vitals report in Search Console and check mobile and desktop separately. Google groups similar URLs together, so you will usually see that one template fails, such as all blog posts or all product pages. That tells you to fix the template, not individual pages. If your site is too new or small to have field data, use lab data as a guide and focus on the templates that matter most to the business.
Step 2: Fix the server before anything else
A slow server response delays everything, and LCP in particular. Before you touch images or scripts, check Time to First Byte (TTFB) in PageSpeed Insights diagnostics or your browser’s developer tools.
Server-side fixes that tend to help most:
- Full-page caching, so most visitors get a ready-made HTML page instead of waiting for the CMS to build one.
- An object cache such as Redis for dynamic sites like WordPress, so repeated database queries are served from memory.
- A CDN such as Cloudflare in front of the site, so static files are served from a location close to the visitor.
- Adequate hosting. A cheap shared plan that struggles under normal traffic will hold back every other fix.
This is the layer we focus on when we build and host WordPress sites: Nginx, page caching, Redis object caching and Cloudflare in front. It is also where traffic spikes break sites. Our YoungEngine case study covers a webinar landing page that kept going down under load and had to be fixed at the server and code level.
Step 3: Improve LCP (loading)
Once the server is quick, find out what the LCP element actually is. PageSpeed Insights names it in the diagnostics. On most business sites it is a hero image, a large heading, or a background image in a banner.
Fixes for a slow LCP image:
- Resize and compress it. Serve the image at the size it is displayed, in a modern format such as WebP or AVIF.
- Do not lazy-load it. Lazy loading is good for images further down the page, but the hero image should load immediately. Many themes lazy-load every image by default.
- Give it priority. Adding
fetchpriority="high"to the hero image tells the browser to fetch it early. - Avoid CSS background images for the main visual, because the browser discovers them later than a normal image tag.
Fixes for a slow LCP text element:
- Reduce render-blocking CSS and JavaScript in the page head.
- Load web fonts efficiently, with
font-display: swapso text appears in a fallback font first, and preload only the one or two font files used above the fold.
Sliders and carousels at the top of the page are a common LCP problem. They often load several large images and a script before showing anything. A single static hero usually loads faster and converts just as well.
Step 4: Improve INP (responsiveness)
INP measures the delay between a visitor’s interaction and the next visual update. When it is poor, the page feels laggy: a menu that takes a moment to open, a button that does not respond right away. The cause is almost always too much JavaScript running on the main thread.
How to find and fix it:
- Audit third-party scripts. Chat widgets, heatmaps, multiple analytics tags, social embeds and ad scripts add up. Remove anything nobody uses, and load the rest after the page is interactive where possible.
- Cut plugin and app bloat. On WordPress, every plugin that adds front-end scripts has a cost. On Shopify, apps you uninstalled can leave code behind in the theme, so check the theme files.
- Break up long tasks. If you have custom code, split heavy work into smaller chunks so the browser can respond to input between them.
- Keep the page simple. Very large pages with thousands of elements make every update slower.
Use the Performance panel in Chrome DevTools to record an interaction and see which scripts run during it. That points you at the actual culprit instead of guessing.
Step 5: Improve CLS (visual stability)
Layout shift happens when something loads late and pushes content around. The fixes are mostly about reserving space.
- Set width and height on every image and video, or use CSS aspect-ratio, so the browser reserves the right space before the file arrives.
- Reserve space for ads, embeds and banners. Cookie notices and promo bars that push the page down are a frequent cause.
- Do not insert content above existing content after load, unless it responds to a user action.
- Match fallback fonts to web fonts as closely as possible, so text does not reflow when the custom font arrives.
How to improve Core Web Vitals on WordPress and Shopify
On WordPress, most gains come from the server stack (caching, object cache, CDN), a lightweight theme, fewer plugins and a performance plugin configured carefully. Test after each setting change; aggressive script deferral can break forms and menus.
On Shopify, you do not control the server, so focus on the theme and apps. Choose a fast theme, limit apps that inject scripts on every page, compress images before uploading, and review the theme code for leftovers from removed apps. Check Google’s Core Web Vitals documentation for how the metrics are used in Search.
Common mistakes when fixing Core Web Vitals
- Optimising for the lab score only. A perfect Lighthouse score on your laptop says little about real mobile users.
- Testing only the home page. Product pages, blog posts and landing pages often use different templates with different problems.
- Stacking optimisation plugins. Two caching or minification plugins fighting each other can make things slower and break features.
- Forgetting to re-measure. Field data takes time to update. Validate the fix in Search Console and keep checking.
Learning how to improve Core Web Vitals on a simple site is very doable with the steps above. When the problem sits in the hosting, the server configuration or custom theme code, our technical SEO services cover that deeper work. If you are reviewing the whole site rather than just speed, start with our step-by-step SEO audit checklist.
FAQ
How long does it take for Core Web Vitals improvements to show in Search Console?
The Core Web Vitals report uses real user data collected over a rolling window, so changes appear gradually rather than the day you deploy. Use the Validate Fix button after a fix and keep checking PageSpeed Insights lab results in the meantime.
Do I need a perfect PageSpeed score to pass Core Web Vitals?
No. The PageSpeed score is a lab score, while Core Web Vitals are judged on real user data for LCP, INP and CLS. A page can pass all three with a score below 100, and a high lab score does not guarantee a pass for real visitors.
Which Core Web Vital should I fix first?
Fix the metric that fails on the templates with the most traffic. On many business sites that is LCP on mobile, caused by a slow server response or a large hero image, but check your own Search Console report before deciding.
Will improving Core Web Vitals improve my rankings?
Google uses page experience signals, including Core Web Vitals, as part of its ranking systems, but relevance and content quality matter more. Treat Core Web Vitals as a way to make the site better for visitors and to remove a possible disadvantage, not as a ranking shortcut.
