Hello

Pages

Search

Start a project

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.

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.

MetricThe visitor’s questionGoodPoor
Largest Contentful Paint (LCP)Has the main thing on the page appeared yet?2.5 s or lessOver 4 s
Interaction to Next Paint (INP)When I tap, does anything happen?200 ms or lessOver 500 ms
Cumulative Layout Shift (CLS)Does the page jump around while I read it?0.1 or lessOver 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.

  1. Make the hero image smaller. Serve it in AVIF or WebP, at the size it is displayed, with responsive srcset so phones get a phone-sized file. A 3 MB photo straight from a camera is the single most common problem we see.
  2. 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.
  3. 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.
  4. Remove render-blocking files. Large stylesheets and scripts in the page head make the browser wait. Inline the critical CSS and defer the rest.
  5. 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 width and height attributes, 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

Failing in Search Console?

Let us find what is
slowing your pages

Send us the URLs Search Console flags and we will tell you which fixes matter, in what order, and what they involve.

Request a speed review
WhatsApp