WordPress can be fast. The problem is that most installations accumulate layers over the years: plugins that load scripts on every page, themes built on heavy page builders, unoptimized images and caching nobody reviews. In the end, the site takes four seconds on mobile and nobody knows exactly why.
Core Web Vitals help bring order, but they also create a lot of noise. This is how we read them in real projects.
What Google measures and what it does not
There are three main metrics:
- LCP (Largest Contentful Paint): how long it takes for the main element of the page to appear. On a blog post it is usually the featured image or the H1; on a store, the product image.
- INP (Interaction to Next Paint): how long the page takes to respond to an interaction. A menu that takes a while to open or a form that freezes hurts this metric.
- CLS (Cumulative Layout Shift): how much content moves while loading. The classic button that jumps when a banner appears or a font that changes size.
What Google does not measure is whether your site sells, whether the content is good or whether checkout has too many steps. A site with perfect metrics can still lose customers. That is why we review them alongside analytics and the funnel, not as an end in themselves.
The mistake of looking only at PageSpeed
PageSpeed Insights mixes lab data with field data. The lab score is useful for spotting problems, but it does not represent all your users. The field data tab — if you have enough traffic — shows the real experience.
On WordPress it is common to find a score of 90 on desktop and 35 on mobile. That contrast almost always points to the same things: large images, third-party JavaScript and a theme that loads styles the page does not need.
Before touching anything, answer three questions:
- Which page matters to the business?
- Which device and connection do those users have?
- Which metric is out of range, and since when?
Without that context, optimization becomes a list of recipes with no priority.
The four usual bottlenecks on WordPress
1. Images nobody resized
Uploading a 4,000-pixel photo and displaying it at 1,200 is the most common cause of a high LCP. WordPress generates several sizes, but the theme does not always use them. The solution is not another plugin: it is reviewing which image is being served, in which format and at which dimensions.
2. Plugins that load everywhere
Every plugin can add CSS and JavaScript to every page, even if it is only used at checkout. Before disabling something, measure the impact. Browser coverage tools or a network audit show which files load and which are unused.
3. Heavy page builders
Visual builders speed up editing, but they also add markup and scripts. They are not the enemy by default: the problem is using them without limits, with dozens of widgets and animations in every section. If the team needs autonomy, it makes sense; if the site is a single-campaign landing page, it probably does not.
4. Third parties you do not control
Chats, pixels, maps, fonts and A/B tests. Every external script competes for the same CPU. Some can be loaded after interaction; others can be removed. The right question is not “is this script fast?” but “what does it contribute, and to whom?”.
How to prioritize without breaking anything
The order that works in most projects:
- Measure a baseline with field and lab data.
- Fix LCP if the main page takes too long to show content.
- Review INP if interactions are slow, especially on mobile.
- Fix CLS by reserving space for images, ads and fonts.
- Monitor so the improvement is not lost in the next update.
The biggest wins usually come from boring decisions: fewer plugins, correct images, one less font and properly configured caching. Not from a miracle trick.
If the site runs on WordPress and the team is not sure what to touch, a performance audit separates the urgent from the cosmetic. At Coderwebs we run that diagnosis as part of performance optimization and leave a plan the team can execute or delegate.
Maintenance: where the improvement is lost
Optimizing once and forgetting about it does not work. A new plugin, a campaign with ten pixels or a theme update can bring the problem back. That is why we measure after every relevant change and set alerts when LCP or INP degrade.
If the site also has commerce or critical forms, maintenance includes checking that caching is not serving the wrong version. That work looks more like operations than design, and it is what sustains the results. You can see how we approach it in WordPress maintenance.
Conclusion
Core Web Vitals is not a score to chase for vanity. It is a way to understand where time is lost and, often, where conversions are lost. Measure first, prioritize by impact and be suspicious of any 100/100 promise without context.