Web · Page speed
Core Web Vitals in plain language: what to fix first
Three numbers, one order of work
Core Web Vitals are Google’s three measures of how a page feels to real visitors: loading (LCP, good under 2.5 seconds), responsiveness (INP, good under 200 milliseconds) and visual stability (CLS, good under 0.1). For most Danish business sites, fix the largest image and slow server response first, then layout shifts, then heavy scripts.
On this page
What are the three Core Web Vitals?
Google introduced Core Web Vitals to put numbers on the experience of using a page. There are three, and each answers a question a visitor would ask without knowing the jargon.
| Metric | The visitor’s question | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Has the main thing on the page appeared yet? | 2.5 s or less | Over 4 s |
| Interaction to Next Paint (INP) | When I tap, does anything happen? | 200 ms or less | Over 500 ms |
| Cumulative Layout Shift (CLS) | Does the page jump around while I read it? | 0.1 or less | Over 0.25 |
INP replaced an older metric, First Input Delay, in March 2024. If an old report or plugin still talks about FID, its advice is out of date. Between “good” and “poor” sits a middle band that Google labels “needs improvement”.
A page passes when all three metrics are good for at least 75 per cent of real visits. That 75th percentile matters. Your own phone on office Wi-Fi in Copenhagen is not the visitor on a three-year-old Android on a train between Odense and Aarhus.
Why do my test scores keep changing?
There are two kinds of measurement, and confusing them causes most of the frustration around page speed.
- Field data comes from real Chrome users, collected in the Chrome User Experience Report over a rolling 28 days. This is what Google uses. You see it at the top of PageSpeed Insights and in the Core Web Vitals report in Search Console, provided your site has enough traffic.
- Lab data is a single simulated test, usually Lighthouse, run on a throttled device. It is useful for diagnosing problems, but it varies from run to run and does not measure INP directly.
The practical consequence: chase the field data, use the lab data to find causes, and expect a fix to take up to four weeks to show fully in the field numbers. A Lighthouse score of 100 is pleasant but not the goal. Smaller Danish sites often have too little traffic for page-level field data, in which case Google falls back to grouping similar pages or the whole origin.
Fix first: why is the main content slow to load?
LCP is the metric most sites fail, and the cause is usually one of a short list. Find your LCP element first. PageSpeed Insights names it, and on most business sites it is the large photo or headline at the top of the page.
- Make the hero image smaller. Serve it in AVIF or WebP, at the size it is displayed, with responsive
srcsetso phones get a phone-sized file. A 3 MB photo straight from a camera is the single most common problem we see. - Do not lazy-load it. Lazy loading is right for images further down, but applied to the hero it delays the very thing LCP measures. Give the hero
fetchpriority="high"instead. - Speed up the server. If Time to First Byte is over roughly 800 milliseconds, no front-end tweak will save you. Page caching, better hosting or a CDN with a European edge location usually helps more than anything else.
- Remove render-blocking files. Large stylesheets and scripts in the page head make the browser wait. Inline the critical CSS and defer the rest.
- Check sliders and carousels. They often load several large images and a script before showing the first slide.
On WordPress sites, a heavy page builder theme combined with cheap shared hosting accounts for a large share of poor LCP. Sometimes the honest fix is a lighter theme rather than another optimisation plugin. Our performance and Core Web Vitals work starts with exactly this diagnosis.
Fix second: why does my page jump while loading?
Layout shift is the most irritating problem for visitors, and often the cheapest to fix. Something loads late and pushes everything else down, so the visitor taps the wrong link or loses their place.
- Images and videos without dimensions. Always set
widthandheightattributes, or a CSS aspect ratio, so the browser reserves space. - Cookie banners. In Denmark nearly every site has one. A banner that pushes content down rather than overlaying it counts as a shift. Use an overlay or reserve the space.
- Embeds and ads. Maps, booking widgets, social posts and video players load late. Give their containers a fixed minimum height.
- Web fonts. When a custom font swaps in, text can reflow. Preload the main font files and choose a fallback with similar proportions.
- Content injected from the top. Announcement bars and “free shipping” strips added by a script after load are a classic cause.
Fix third: why does the page feel slow to respond?
INP measures the delay between an interaction, such as a tap on a menu or a click on “add to basket”, and the next visual update. When it is poor, the cause is almost always JavaScript keeping the browser busy.
- Audit third-party scripts. Tag managers collect tracking codes over the years. Remove anything nobody uses, and question chat widgets, heatmaps and review badges that load on every page.
- Look at the consent tool. Some consent platforms are heavy and run work on every click. Test with and without it.
- Break up long tasks. Any script that runs for more than 50 milliseconds blocks input. Developers can split work into smaller pieces or move it off the main thread.
- Simplify menus and filters. Mega menus and product filters that rebuild large parts of the page on every tap are frequent offenders on shops.
INP problems show most clearly on mid-range phones, which is another reason to test on real devices. Building mobile-first from the start avoids many of them, because heavy desktop features never make it into the build.
How much do Core Web Vitals affect Google rankings?
Honestly, less than many tool vendors suggest. Google has said Core Web Vitals are part of its page experience signals, and that relevant, helpful content still matters more. A slow page with the best answer can outrank a fast page with a weak one.
The stronger argument for fixing them is commercial. Visitors leave slow pages, and the people most affected are on phones, often arriving from paid ads you have already paid for. A faster landing page can improve conversion rate and, on Google Ads, the landing page experience component of Quality Score.
Fix by template, not by URL. Most sites have a handful of page types: the home page, service pages, articles, product pages and checkout. Search Console groups URLs with similar problems, and a fix to the template repairs every page built on it at once. Start with the templates that carry the most traffic and enquiries.
So treat Core Web Vitals as a hygiene standard. Get every important template into the good band, keep it there when new scripts and campaigns are added, and then spend your effort on content and offers. Checking Search Console once a month is usually enough to catch a regression before it costs you.
Speed questions
What site owners ask
about page speed
It means your page or site has too few real Chrome visits for Google to report field data. The Chrome User Experience Report only publishes figures once enough visits are collected over the previous 28 days, and many small Danish sites fall below that line for individual pages. PageSpeed Insights then shows the whole origin if it has enough data, or nothing at all. In that case, rely on lab tests in Lighthouse, test on a real mid-range phone, and consider adding a real user monitoring tool that records the metrics from your own visitors. The absence of data is not a penalty in itself.
Sometimes it fixes loading, but it rarely fixes all three metrics. A good caching plugin reduces server response time and can minify and defer files, which often improves LCP noticeably. It cannot shrink an oversized hero image you uploaded, reserve space for a cookie banner, or remove a chat widget that blocks the main thread. Aggressive settings can also break menus and forms, so test carefully after enabling each option. If a site still fails after caching, the theme, page builder or hosting is usually the underlying cause, and that calls for a developer rather than another plugin.
The container itself is light, but what you load through it can slow the site considerably. Tag Manager makes it easy to add analytics, advertising pixels, heatmaps and remarketing tags without a developer, and over a few years containers fill up with tags for campaigns that ended long ago. Each one adds scripts that compete for the browser’s attention, which mainly hurts responsiveness (INP). Review the container every quarter, pause tags nobody uses, fire tags only on the pages that need them, and delay non-essential tags until after the page has loaded. Server-side tagging can move some of the work off the visitor’s device.
Expect around four weeks before the report fully reflects a fix. Search Console uses field data averaged over a rolling 28-day window, so old slow visits drop out gradually as new fast ones arrive. You can start the validation process in the report once you have deployed the change, and Google will monitor the affected URLs during that period. To confirm earlier that the fix works, check the lab results in PageSpeed Insights straight after deployment, and watch your own analytics or monitoring tool for changes in real visits. Do not reverse a fix simply because the report has not moved after a week.