- Core web vitals WordPress scores come from real visits. Google looks at three numbers: LCP for loading, CLS for layout stability, and INP for responsiveness.
- Start WordPress speed optimization with field data in Search Console and PageSpeed Insights. Lab tests such as Lighthouse help you find the cause.
- Fix the number that is furthest from good first. Then measure again on the same template, because one change can affect another number.
01Measure core web vitals WordPress pages first
Use two sources. Search Console shows how real visitors experience groups of pages. PageSpeed Insights shows field data for one address and a lab test of the same page.
- In Search Console, open Core Web Vitals to see the groups of pages that need work.
- Open pagespeed.web.dev and enter the address of one template, such as the article page.
- In Chrome DevTools, open the Lighthouse panel, choose Performance and run a report.
02Understand LCP, CLS and INP
LCP, Largest Contentful Paint, is the time until the largest element of the first screen is visible. On many WordPress pages that element is a hero image or a large heading. Good is 2.5 seconds or less.
CLS, Cumulative Layout Shift, measures how much visible content moves while the page loads. Good is 0.1 or less.
INP, Interaction to Next Paint, measures the delay between a click, a tap or a key press and the next visual update. It replaced FID as a Core Web Vital in March 2024. Good is 200 milliseconds or less.
Google scores each number at the 75th percentile of visits. The field data covers a rolling 28-day window.
03Fix LCP: the first screen and the server
The browser must find, download and paint the largest element of the first screen as early as it can.
- Compress the hero image and serve it as WebP or AVIF.
- Do not load an image larger than the box where it appears.
- Do not lazy load the hero image. Lazy loading delays the element that LCP measures.
- Give the hero image a high fetch priority, where the theme or block allows it.
- Ask your host about server response time. A slow server delays every number.
04Fix CLS: reserve space before content arrives
Layout shift happens when the browser draws content and then moves it. Give the browser the size of each element before it loads.
- Set width and height on every image and video. WordPress adds them to most images.
- Reserve a fixed height for ads, embeds and banners.
- Do not insert a banner or a notice above existing content after the page loads.
- Load web fonts with font-display set to swap or optional, and choose a fallback font of similar size.
05Fix INP: keep the main thread free
INP is slow when the browser is busy running JavaScript at the moment a visitor clicks. Reduce the work that runs on every page.
- Remove scripts that you do not use. Each plugin that loads a script on every page adds work.
- Defer scripts that the first screen does not need, so they do not run during early clicks.
- Open the Performance panel in Chrome DevTools, record a click, and look for tasks longer than 50 milliseconds.
- Test menus, forms and search, since visitors use them often.
06Change one thing, then measure again
Change one template and one number at a time. Lab results update on each run. Field data needs days to reflect a change, because it uses a rolling 28-day window. Compare the new report with the old one, and keep the change only if the number improves.
07How Nucleo handles core web vitals on WordPress
Nucleo compiles each page to HTML and CSS when you save. The frontend gets finished files and does not call external services, so there is no build step on each visit.
Images can be served as AVIF and WebP, with the original as fallback. The site option imageFormats is off by default. The picture tag does not change the image layout or classes.
Critical CSS holds the rules for the first screen. The local command nucleo critical builds it for each template.
The quality engine checks SEO and accessibility. For field data, use Search Console and PageSpeed Insights.