Loading time and Core Web Vitals

What we check

We have Google PageSpeed Insights measure the home page and evaluate three metrics that Google calls "Core Web Vitals":

Metric	What it measures	Good	We report
LCP (Largest Contentful Paint)	Time until the main content is visible	up to 2.5 s	Warning above 2.5 s, serious defect above 4 s
CLS (Cumulative Layout Shift)	How much content jumps while loading	up to 0.1	Note above 0.1, warning above 0.25
INP (Interaction to Next Paint)	Response time after a click	up to 200 ms	Warning above 500 ms

If enough people visit the website, we use field data: real measurements from Chrome users, from the smartphone where possible. Otherwise we use a lab measurement that simulates a smartphone with an average mobile connection. If the response time is missing there, we use the blocking time (TBT) and warn from 600 ms. In the report each value says where it comes from.

Why it matters

Most visitors come from a smartphone, often on the move with an average connection. Every second of waiting costs:

• Loading time (LCP): anyone who still sees an empty or half-finished page after three seconds often taps "Back" and chooses the next search result.
• Jumping content (CLS): you want to tap "Contact", at that moment a late-loading image pushes the button away, and you land somewhere else. This is annoying and looks unprofessional.
• Response time (INP): if a menu or button responds only after half a second, visitors tap several times and think the page is broken.

Google also uses these metrics as a signal for the order of search results.

How to fix it

The most common causes and what helps:

Slow main content (LCP)

• Images that are too large, above all the large header image at the top. Reduce it to the size actually displayed and save it as WebP. More on this in the article on images.
• Image sliders at the top of the page load several large images at once. A single good image is almost always faster and more effective.
• Slow server: see TTFB (Time to First Byte).
• Blocking files in the head of the page. See the article of the same name.

Jumping content (CLS)

• Specify width and height for all images so that the browser reserves the space.
• Cookie banners, notice bars and chat windows should appear over the content, not push it down.
• Web fonts with font-display: swap and a fallback font of similar size jump less.

Sluggish response (INP)

• Remove plugins and embedded services that are not needed: chat widgets, sliders, animation libraries, several tracking tools.
• Page builders such as Elementor or Divi load a lot of JavaScript. Their performance settings ("Performance", "Experiments") often help already.

WordPress

A cache plugin such as WP Rocket, LiteSpeed Cache or W3 Total Cache, combined with an image plugin such as ShortPixel or Imagify, often solves a large part of the problems already.

How to check it yourself

Enter the website's address on pagespeed.web.dev. At the top you see the field data of real visitors (if available), below it the lab measurement with concrete suggestions for improvement.

Frequently asked questions

What is the difference between field data and lab measurement?

Field data comes from real Chrome users who visited the website in the last 28 days. The lab measurement is a single, simulated page view with a throttled smartphone. Field data is more meaningful, but exists only with enough visitors.

The page loads fast on a computer. Why does the check report something different?

A computer usually has a fast connection and often already has the page in its cache. What is measured is a smartphone with an average mobile connection, the way many visitors are on the move.

Do the Core Web Vitals influence the Google ranking?

Yes, as one of many signals. The direct effect is more important: every second of waiting costs visitors before they even see the offer.