A slow website rarely has one obvious cause. A large hero image, a busy tag manager and a layout that moves while loading can each create a different problem. Installing another optimisation plugin without finding the cause can leave you with a better-looking report and the same frustrating experience.
These are ten common Core Web Vitals mistakes worth checking, with practical fixes for business websites and WordPress builds. They are diagnostic starting points, not a claim that every website has all ten problems.
First, Core Web Vitals are not your PageSpeed score
The performance score out of 100 in PageSpeed Insights comes from a Lighthouse lab test. Core Web Vitals assess three aspects of the visitor experience: loading, responsiveness and visual stability. A green Lighthouse score does not prove that real visitors pass all three. Google explains the difference between lab and field data here.
- Largest Contentful Paint (LCP): aim for 2.5 seconds or less. This measures when the largest eligible image or text block becomes visible.
- Interaction to Next Paint (INP): aim for 200 milliseconds or less. This measures responsiveness to interactions such as taps and clicks.
- Cumulative Layout Shift (CLS): aim for 0.1 or less. This measures unexpected movement of visible content, not loading time.
The good thresholds are assessed at the 75th percentile, with mobile and desktop considered separately. You need to meet all three for a passing assessment where sufficient field data exists. See Google’s Core Web Vitals overview.
1. Treating one Lighthouse run as the whole picture
A single test is a useful clue, not a verdict. Device conditions, network behaviour and caching can change the result. A page that performs well on your laptop can still struggle for someone using a modest phone.
What to do: compare several runs under consistent conditions, then inspect the real-user section in PageSpeed Insights. Check whether it reports this URL or the whole origin. Origin data covers the website more broadly and can hide differences between templates. No field data means insufficient evidence, not an automatic pass.
2. Making the hero image too expensive to download
A desktop-sized image served to a small screen wastes bandwidth. If that image is the LCP element, the delay affects when the main content appears.
What to do: identify the actual LCP element, resize images sensibly, use responsive sources and choose an efficient format at acceptable visual quality. Check the file the browser downloads, not just the dimensions shown in the editor.
3. Lazy-loading the image visitors need immediately
Lazy loading helps content further down the page. Applied to the LCP image, it can delay the request. An image hidden behind JavaScript or a stylesheet may also be discovered late.
What to do: make the main image discoverable early, usually in the initial HTML. Avoid lazy-loading it and consider fetchpriority="high" for that resource. Reserve high priority for genuinely important assets. Google’s LCP optimisation guide explains how to separate download delays from rendering delays.
4. Ignoring the wait for the server
Image compression cannot recover time already lost before the HTML arrives. Slow application work, repeated redirects or a cache that misses ordinary public pages can leave the browser waiting before useful rendering can start.
What to do: investigate Time to First Byte alongside the LCP breakdown. Review redirects, hosting capacity, slow requests and caching rules. On WordPress, test as a logged-out visitor as well as an administrator. Keep personalised, account and checkout responses out of shared page caches.
5. Loading every stylesheet and feature on every page
A simple article can inherit assets intended for sliders, shops, forms and animation effects it never uses. Some stylesheets hold up rendering; unnecessary scripts also add processing work.
What to do: audit assets by template and remove unused features at the source. Load component assets where needed. Test CSS changes carefully so essential styling arrives with the content rather than producing an unstyled flash. Fewer installed plugins is not a useful target by itself: the work they cause matters more.
6. Letting third-party scripts accumulate
Chat widgets, embedded videos, heatmaps and marketing tags each have a cost. Duplicate tags and abandoned experiments are especially easy to miss when several people manage a website.
What to do: give each integration an owner and a clear purpose. Remove duplicates, inspect its network and main-thread activity, and consider click-to-load previews for heavy embeds. Keep required consent behaviour intact. Test after accepting consent too, because a clean first visit may not include the scripts returning visitors receive.
7. Testing loading but never testing interaction
A page can appear quickly and still hesitate when someone opens the menu or selects a filter. Long JavaScript tasks, expensive event handlers and heavy rendering work can delay the next visual response.
What to do: record real interactions in browser developer tools. Break up long tasks, simplify handlers and reduce unnecessary rendering. Give prompt visual feedback while longer work continues. Google’s INP guidance covers input delay, processing and presentation. A standard navigation-only Lighthouse test does not measure a visitor’s full interaction history; Total Blocking Time is a diagnostic, not a replacement for field INP.
8. Leaving no space for images and embedded content
When the browser does not know how much space an image, video or widget needs, content below it can move when it arrives. That can make reading difficult and move a link away just as someone tries to select it.
What to do: provide image width and height attributes, preserve the intended aspect ratio in responsive CSS and reserve space for embeds. Check layouts while resources are loading, not only after everything has settled.
9. Allowing fonts, banners and animations to move the page
A replacement font with different proportions can rewrap headings. A late banner inserted above the article can push the entire page down. Animating layout properties can create movement too.
What to do: use a deliberate font-loading strategy with compatible fallback metrics, reserve space for planned UI and avoid inserting unexpected content above existing text. Prefer transform and opacity for suitable animations. Test after scrolling and interacting, since layout shifts can happen beyond the initial load. See the CLS optimisation guide.
10. Fixing the homepage and calling the job finished
Your homepage may use a different template from articles, service pages or landing pages. One clean test cannot clear the rest of the website. Improvements can also disappear when new content, tags or components are added.
What to do: maintain a representative set of URLs and repeat tests after meaningful releases. Include mobile menus, forms, filters and consent states. Record what changed and compare like-for-like measurements. Add performance checks to the publishing and build process so the same problems do not return.
Which mistakes should you fix first?
Start with the experience that is failing on pages people actually use. If LCP is poor, investigate the server response and the largest element’s loading path. If INP is poor, trace interactions. If CLS is poor, find what moved and what caused it. That gives you a reason for each change.
A practical review starts with one service page, one article and any important conversion page. Save a baseline, make a focused change, test essential functionality and compare the result. Repeat across shared templates once the approach works.
CrUX field data in PageSpeed Insights covers a rolling 28-day period, so it will not immediately reflect a release. Use lab checks for immediate diagnosis and watch field measurements over time. Our guide to free SEO tools provides a broader starting point for monitoring.
Will better Core Web Vitals improve rankings?
Google uses Core Web Vitals in its ranking systems, but passing them does not guarantee higher positions. Content relevance and other signals still matter. Google explicitly advises against chasing a perfect score purely for SEO. Read its page experience guidance.
The business case is a website that loads its main content promptly, responds when people use it and stays stable while they read. Measure enquiries and task completion separately rather than assuming that a score increase proves a commercial gain.
Need help finding what is slowing your website down?
Codex Collective can help connect performance diagnostics with practical changes to your build. Explore our Enterprise WordPress, web design and development and SEO and AI search services, or get in touch to discuss your website.
