On this page
If PageSpeed Insights shows “Core Web Vitals Assessment: Failed” for your WordPress site, it isn’t about your score. It means real visitors are waiting too long for the page, watching it jump around, or tapping buttons that respond slowly. Each of those has a usual cause on WordPress, and each one has a fix.
What the assessment actually measures
Core Web Vitals are three measurements Google takes from real Chrome users visiting your site. To pass, at least 75% of visits need to be in the “good” range for all three.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long the main image or headline takes to appear | 2.5 s or less | Over 4 s |
| CLS (Cumulative Layout Shift) | How much the page jumps while it loads | 0.1 or less | Over 0.25 |
| INP (Interaction to Next Paint) | How quickly the page responds to taps and clicks | 200 ms or less | Over 500 ms |
Google uses the last 28 days of real visitor data. After you fix something, the assessment can take up to four weeks to change from failed to passed.
Step 1: find which metric is failing
Open PageSpeed Insights, enter your page and look at the top section, “Discover what your real users are experiencing”. Each of the three metrics is coloured green, orange or red. Fix the red ones first, in this order: LCP, then CLS, then INP.
If that section says there isn’t enough data, your site doesn’t get enough Chrome visits for Google to measure. Use the lab results further down the page instead.
Fixing LCP on WordPress
On most WordPress business sites the LCP element is the hero image at the top of the page. PageSpeed Insights names it under “Largest Contentful Paint element”.
The usual causes, in order of how often I find them:
- A hero image that’s too big: a 1–2 MB PNG or JPEG where a 150–250 KB WebP would look the same.
- The hero image is lazy-loaded, so the browser deliberately waits before fetching it.
- Render-blocking CSS and JavaScript from the theme, page builder and plugins.
- Google Fonts loading from another domain before the headline can show.
- A slow server with no page caching, so every visit builds the page from scratch.
- No CDN, so files travel from a server on the other side of the world.
The fixes:
01Compress the hero and serve WebP
Resize the image to the largest size it actually displays at, convert it to WebP and keep it under about 250 KB.
02Stop lazy-loading the hero, and preload it
Lazy loading is right for images further down the page and wrong for the first one. Exclude the hero from lazy loading and add a preload hint so the browser fetches it first.
03Turn on page caching and a CDN
Full-page caching (WP Rocket, LiteSpeed Cache or your host’s built-in cache) serves ready-made HTML. A CDN such as Cloudflare serves files from a location close to your visitors.
04Host your fonts locally
Serving font files from your own domain removes a DNS lookup and a connection to Google’s servers before text can render.
On the Snowden Electrical rebuild, these fixes plus a theme rebuild took LCP from 6.2 s to 1.4 s.
Fixing CLS on WordPress
Layout shift is the page jumping as things load: you go to tap a link and it moves. The usual WordPress causes:
- Images, videos and iframes without width and height attributes, so the browser doesn’t reserve space for them.
- Web fonts that load late and swap in at a different size.
- Cookie banners, promo bars or notices that appear after a delay and push content down.
- Ads or embeds that load into an empty space.
- Sliders and carousels that resize after their script runs.
The fixes are mostly simple: give every image and embed explicit dimensions, preload your main font and use font-display: swap, make cookie banners overlay the page instead of pushing it, and reserve space for anything that loads late. On the Snowden site, these took CLS from 0.18 to 0.02.
Fixing INP on WordPress
INP replaced First Input Delay in 2024 and is the metric WordPress sites now fail most often after LCP. It measures how long the page takes to respond when someone taps a menu, opens an accordion or adds to cart. When the browser is busy running JavaScript, it can’t respond.
The usual causes:
- Page-builder bundles (Elementor, Divi, WPBakery) loading on every page whether or not they’re used.
- Sliders, animation libraries and popup plugins.
- Third-party scripts: chat widgets, tracking pixels, tag managers and review widgets.
- Several plugins doing the same job.
The fixes, in order:
- Remove plugins and scripts you don’t need. This is the biggest win and costs nothing.
- Load scripts only on the pages that use them. A contact-form script doesn’t belong on your blog posts.
- Delay third-party scripts like chat and tracking until the visitor interacts with the page.
- Replace heavy sliders and animation effects with lighter alternatives.
- If a page builder is the root cause, consider rebuilding key templates without it.
When fixes aren’t enough
Most failing WordPress sites can be fixed without a rebuild. Sometimes, though, the page builder is the problem rather than the setting: every page loads dozens of scripts and styles, and there’s nothing left to switch off. That was the case at Snowden Electrical, where the Elementor version needed 72 requests and the hand-coded theme needed 18.
Thresholds to compare your own site against:
Start with the hero image, caching and a CDN.
Check images without dimensions, late fonts and banners first.
Cut JavaScript: page builders, sliders and third-party scripts.
Does passing Core Web Vitals help rankings?
It helps, but it’s one signal among many. Google uses page experience as a tie-breaker between pages of similar relevance, so a fast page won’t outrank a much more relevant one. The bigger effect is on people: faster pages lose fewer visitors before they load, and that shows up in enquiries. Snowden Electrical’s Google Ads enquiry rate went from about 1.2% to just over 3% after the speed work, on the same ad spend.