Core Web Vitals are three measurements of how a page feels while loading and responding: Largest Contentful Paint (LCP) for loading, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for responsiveness. A single "performance score" blends many lab metrics and is easy to game; these three are closer to what a real visitor experiences.
LCP: the main content took too long to appear
LCP is usually the hero image or the largest heading. Common causes, in order of frequency: an oversized hero image, slow server response time, render-blocking CSS or fonts, and a hero image loaded lazily when it is above the fold.
- Serve the hero in a modern format at the dimensions it is displayed — not 3000px wide for a 700px container.
- Do not lazy-load above-the-fold media; preload the hero image instead.
- Preload self-hosted fonts and use font-display: swap so text is not invisible while waiting.
- Check the server: a consistently slow time to first byte cannot be fixed in the front end.
- Remove or defer the large carousel library if the hero uses a carousel; most hero carousels are not worth their cost.
CLS: content jumped while loading
Layout shift happens when something is inserted above content that has already rendered. The usual culprits are images without width and height attributes, banners injected by scripts, fonts that swap to different metrics, and cookie or chat widgets that push the page down.
- Set explicit width, height or aspect-ratio on every image and embed.
- Reserve fixed space for ad slots, cookie notices and late-loading widgets.
- Use a fallback font with similar metrics, or a size-adjusted font fallback.
- Avoid inserting promotional banners above existing content after load — place them where space is already reserved.
INP: clicks felt unresponsive
INP measures the delay between a user interaction and the screen updating. It is almost always caused by JavaScript doing too much on the main thread: heavy third-party tags, large event handlers, hydration of entire pages, or long tasks triggered by analytics.
The most common offender
A tag manager container with eight tags, a heatmap, two chat widgets and a personalisation script. Each is cheap to add and expensive to run. Audit them quarterly and remove what nobody uses.
Why optimisation plugins often make things worse
Plugins that combine, minify, defer and preload everything tend to conflict with each other and with the theme. When three layers of caching and four layers of minification are applied, breakage is common and diagnosis becomes difficult. It is usually faster to fix the actual causes: compress images properly, serve modern formats, remove unused libraries, and configure caching at the server or CDN level.
How to measure honestly
- Pick three or four representative templates: home, a commercial page, a content page, a listing or product page.
- Record lab data for each, on both a mobile and a desktop profile.
- Use field data if you have enough traffic — real-user measurements include network and device variance that lab tests miss.
- Change one category of thing at a time: images, then scripts, then fonts.
- Re-measure with the same tool, device profile and connection setting.
Lab scores vary between runs, especially with third-party scripts enabled. Report a range and the specific metrics you improved rather than a single number that will differ on the next run. And be cautious about attributing ranking changes to speed work alone: speed is one factor among many, and search systems update continuously.
A realistic starting point
If you only do three things: compress and correctly size your images, remove or defer third-party scripts you do not actively use, and set dimensions on media so nothing shifts. On most business sites, those three account for the majority of the available improvement.