Most of us leave a site that opens slowly, jumps around while we read, or does nothing for a moment after we tap a button. Google has boiled this annoying experience down to three numbers called Core Web Vitals. You do not need to be an engineer to understand what each number is and where to look for its problem.
The three metrics at a glance#
| Metric | What it measures | Plain question |
|---|---|---|
| LCP | How fast the largest above-the-fold content appears | How soon does the main content show up? |
| INP | Responsiveness to clicks, taps and typing | How long after a click do I see a reaction? |
| CLS | Sudden shifting of elements | Does the text jump while I read? |
The "good" and "poor" thresholds for these metrics are published officially by Google and on web.dev, and they are occasionally revised; check the exact numbers at that source. In short, the goal is for the page to be in the "good" range for at least most real users.
LCP: how soon the main content arrives#
LCP (Largest Contentful Paint) is the time it takes to show the largest visible element in the first screen; usually a large image, an article's featured image or a block of text. Common causes of slowness:
- A heavy or unoptimized image, or a featured image that downloads late because of lazy loading;
- A slow server response and no caching;
- Heavy CSS and JavaScript that block rendering;
- Heavy fonts that show the text late.
Where to start: compress the featured image to the size you need, speed up the first page load with caching, and do not lazy-load the LCP element. The details of this part are in speeding up WordPress.
INP: how soon the page responds#
INP (Interaction to Next Paint) measures how long it takes for the page to visibly react to a user interaction; for example, from the moment you tap a mobile menu to the moment it opens. When a page responds slowly, the browser is usually busy running heavy JavaScript. Common culprits:
- Third-party scripts such as chat tools, ads and tracking pixels;
- Plugins and themes that load a lot of code;
- Forms and menus built with heavy code.
How to fix it: remove unnecessary scripts, load the ones that stay later or with defer, and find which plugin carries the most load.
CLS: keep the layout from jumping#
CLS (Cumulative Layout Shift) is the sum of sudden layout shifts. It is that bad experience when you go to tap a button and a banner appears and pushes the button down. Common causes:
- Images and videos without set dimensions (
widthandheight); - An ad or banner that opens up space after loading;
- A font that changes the text's shape after it loads.
A simple fix: reserve space in advance for all images and ad slots so the browser knows how much room to keep.
Field data or lab data#
There are two kinds of data, and each has its own use:
- Field data: collected from real users. Google uses this for assessment, and you see it in the Core Web Vitals report in Search Console.
- Lab data: comes from a controlled run, like a Lighthouse report. It is great for debugging and for testing a change.
If the two disagree, the reason is usually that your real users have a different connection and device than the test. Treat field data as the benchmark.
Common measuring tools: PageSpeed Insights, the Core Web Vitals report in Search Console, and browser developer tools. A low-traffic site may not have enough field data; then you only see lab data. Read the report status with the Search Console tutorial.
Order of work for a small site#
- Open the Search Console report or PageSpeed Insights for a few important pages.
- See which metric is weak; do not treat all three at once.
- Fix the problem with the simplest solution: compress images, set dimensions, remove an extra plugin.
- After a change, wait a few weeks for the field data to update.
- Write down the result so you know which change worked.
If the browser still shows the old version after you change CSS, read browser cache and new CSS not arriving.
A practical example of a fix#
Suppose you have a small online store and the report says LCP on product pages is poor. Opening the page shows that the main product image is several times larger than needed and loads late because of lazy loading. You make three simple changes: shrink and compress the image to its real display size, turn off lazy loading for that first image, and enable page caching. A few weeks later, the field data improves.
The same site might have a bad INP on the checkout page. When you disable plugins one by one and see that an old chat tool loads a large chunk of the JavaScript, you can load it only on the pages where it is needed. Here too the solution is not complicated; finding the main cause does the job.
A few misconceptions#
- "I need to score 100": the overall score from a lab tool is not the final goal. What matters is that real users' metrics are in the good range.
- "I have to fix every page one by one": Google groups similar pages. Fixing a template or a single plugin may improve the whole group.
- "Speed is only about hosting": hosting matters, but image size, scripts and theme structure play a big part too.
- "After a fix, the number changes tomorrow": field data is collected over a period and changes gradually.
When not to worry#
If your site has low traffic and not enough field data, there is no need to obsess over the numbers. Start with a few simple steps: keep images light, remove unused plugins and choose a lightweight theme. A good experience for the user, regardless of any particular number, is the main goal, and the rest is the result of that care.
Summary#
- Core Web Vitals are three user experience metrics: LCP, INP and CLS.
- LCP measures how fast the main content appears; images and server response play the biggest role.
- INP measures responsiveness; heavy scripts are the main cause.
- CLS measures layout jumping; it is fixed by setting dimensions and reserving ad space.
- Field data is the real benchmark, and lab data is for debugging.
- Improving these metrics does not guarantee a first-place rank, but it will definitely improve the user experience.
