Quick answer
Core Web Vitals are three metrics: Largest Contentful Paint (good is 2.5 seconds or less), Interaction to Next Paint (200 milliseconds or less) and Cumulative Layout Shift (0.1 or less). INP replaced First Input Delay in March 2024. Judge your site on real-user field data in Search Console, not one lab score.
This guide is for WordPress site owners and developers looking at a red or orange PageSpeed Insights report. It is part of our SEO help centre. Start by finding out which metric is failing and for whom, because each one has different causes.
Check these first
- Open Search Console, then Experience, then Core Web Vitals. This report uses real Chrome user data. It groups similar URLs and labels them Good, Need improvement or Poor, separately for mobile and desktop.
- Run your key page in PageSpeed Insights. Read the top section ("Discover what your real users are experiencing") before the score below it. If there is no field data, your site has too little Chrome traffic and you only have lab results to go on.
- Note which metric fails. LCP, INP and CLS have different fixes. Fixing the wrong one wastes days.
- Check mobile first. Most small business sites fail on mobile long before desktop.
Field data vs lab data
PageSpeed Insights shows two different things. Field data comes from the Chrome User Experience Report: real visitors over the previous 28 days, reported at the 75th percentile. That means three out of four visits must be at or under the threshold for a pass. Lab data is a single Lighthouse test, run on a simulated mid-range phone over a throttled mobile connection from a Google data centre.
Lab scores move between runs even when nothing has changed. Use lab data to find problems and test fixes. Use field data to decide whether you have a problem at all. A Lighthouse score of 62 with passing field data is not an emergency.
The thresholds Google publishes:
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long the main image or text block takes to appear | 2.5 s or less | Over 4 s |
| INP (Interaction to Next Paint) | How quickly the page responds after a tap, click or key press | 200 ms or less | Over 500 ms |
| CLS (Cumulative Layout Shift) | How much the layout jumps around while loading | 0.1 or less | Over 0.25 |
Fixing slow LCP on WordPress
| What you see | What it means | How to fix it | How long it takes |
|---|---|---|---|
| Slow server response or high TTFB | The server takes too long to build the page | Add page caching, update PHP, or move off overloaded shared hosting | 1 hour to 1 day |
| LCP element is a large hero image | The image is too heavy or too big for the screen | Resize to the displayed size, serve WebP or AVIF, use responsive sizes | 1 to 2 hours |
| "Largest Contentful Paint image was lazily loaded" | The hero image waits for the browser to decide it is needed | Exclude the hero image from lazy loading and give it fetchpriority="high" | 30 minutes |
| Hero is a slider or background video | The main content waits for JavaScript | Replace the slider with one static image and a heading | 1 to 3 hours |
| Render-blocking CSS and fonts | The browser waits for files before showing anything | Remove unused plugin CSS, host fonts locally, limit font weights | 2 to 4 hours |
Since WordPress 6.3, core automatically adds fetchpriority="high" to the image it thinks is the LCP image and stops lazy-loading it. Page builders and themes that output the hero as a CSS background image bypass this, so check what your LCP element actually is in the PageSpeed report.
Fixing poor INP on WordPress
INP measures how long the page takes to visibly respond after someone taps a menu, opens an accordion or types in a form. Poor INP almost always means too much JavaScript running on the main thread.
| What you see | What it means | How to fix it | How long it takes |
|---|---|---|---|
| Long tasks in the Performance panel | Scripts block the browser from responding | Remove plugins you do not use; load scripts only on pages that need them | 2 to 6 hours |
| Many third-party tags (chat, heatmaps, pixels, reviews widgets) | Each one adds work on every page | Remove tags nobody uses, delay the rest until after the first interaction | 1 to 3 hours |
| Very large DOM (thousands of elements) | Every update makes the browser redraw a lot | Simplify nested page builder sections, split long pages | Half a day or more |
| Slow mega menu or filter | The click handler does too much at once | Ask your developer to break the work up and yield to the main thread | Developer time |
Delaying JavaScript (a common setting in caching plugins) can help, but test forms, menus and tracking afterwards. It is easy to break a conversion tag and not notice for weeks.
Fixing layout shift (CLS)
| What you see | What it means | How to fix it | How long it takes |
|---|---|---|---|
| Images push text down as they load | Images have no width and height set | Add width and height attributes, or CSS aspect-ratio | 30 to 60 minutes |
| Text changes size after a moment | A web font swaps in with different measurements | Preload the main font, pick a closer fallback font, use fewer font files | 1 to 2 hours |
| Cookie bar, promo banner or ad pushes content | Content is injected above existing content | Reserve the space in advance, or overlay the banner instead | 1 hour |
| Embeds (maps, video, reviews) jump in | No space reserved for the embed | Give the container a fixed height or aspect ratio | 30 minutes |
A sensible WordPress plugin stack
More performance plugins do not make a faster site. Two caching plugins fighting each other is a common cause of broken pages. A lean setup usually looks like this:
- One caching plugin that suits your host. If your host runs LiteSpeed, LiteSpeed Cache is the natural choice. Otherwise WP Rocket or a similar plugin.
- Image compression and WebP or AVIF conversion, either in that plugin or one dedicated image plugin.
- No separate minify, lazy-load or font plugins if the caching plugin already does those jobs.
Then audit the rest. Plugins that load scripts on every page (sliders, form builders, social feeds) are worth checking one by one.
When the theme or page builder is the problem
Some sites cannot pass without changing the theme. Signs include a hero built as a slider you cannot remove, a page builder nesting many layers of containers per section, and dozens of CSS and JavaScript files loading on a simple page. At that point, tuning plugins gives small gains. Rebuilding key templates, or moving to a lighter theme, is often cheaper than months of tweaking. If a rebuild means URL changes, follow our redesign without losing rankings checklist.
Australian hosting detail
If most of your customers are in Australia, hosting the site in Australia usually cuts server response time for them compared with a server in the US or Europe. A CDN helps with images and files but does not fix a slow server building each page. Note that PageSpeed Insights runs its lab test from a Google data centre that may not be in Australia, so your lab TTFB can look worse than your customers experience. Field data reflects your real visitors.
When to get help
A specialist will profile the page in Chrome DevTools, find which scripts and templates cause the failing metric, and fix them without breaking tracking or forms. If your site still fails after the basics, we can take a look.
Talk to us about website speed
For speed problems outside Core Web Vitals, see why is my website slow. If rankings fell at the same time, check whether a Google update caused it.
About this guide
Written by Amann Jhamb, Director of AR Digital Solutions, 17 years in web design, SEO and paid ads. Last checked: 3 November 2026 against web.dev: Web Vitals. Change note: first published 3 November 2026. Part of our SEO help centre.