When a website loads slowly or jumps around as you tap it, the visitor decides within a fraction of a second: stay or leave. That experience is exactly what Google measures with the Core Web Vitals. Three metrics sum up how fast the main content appears, how quickly the page responds to input and how steady the layout stays. Around 53 percent (Google) of mobile visits are abandoned when a page takes longer than three seconds to load. And improving load time by just 0.1 seconds (Deloitte) raised retail conversion rates by an average of 8.4 percent. Load time is therefore not a technical detail but a direct lever on revenue and visibility. This article explains the three Core Web Vitals in plain terms, shows the main causes of poor scores and gives a concrete plan to noticeably improve load time and user experience.
What Core Web Vitals Are and Why Google Measures Them
Core Web Vitals are three standardized metrics Google uses to assess the real user experience of a page. They answer three questions from the visitor's point of view: Is something meaningful visible quickly? Does the page respond promptly when I click or type? And does the content stay in place, or does everything shift while it loads? These three dimensions are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Together they give a more realistic picture than a single load-time number, because they treat perception, usability and visual stability separately.
The origin of the data matters. Google assesses Core Web Vitals primarily from real user data in the Chrome browser, the Chrome User Experience Report. It measures not a lab value on a fast developer machine but what real people with different devices and connections experience. Each metric is judged at the 75th percentile: only when 75 percent of page views reach the target value does a metric count as good. That prevents hiding behind good averages while a quarter of users suffer a sluggish page. How load time fits into the bigger picture of a professional build is shown in our article on the SEO basics for businesses.
The three metrics and their target values
LCP: When the Main Content Becomes Visible
Largest Contentful Paint measures the moment the largest visible element in the first screen area has finished loading, usually a hero image, a large heading or a title video. LCP is therefore the best approximation of the felt question: when do I finally see what this is about? A value under 2.5 seconds is good, between 2.5 and 4 seconds it needs improvement, and above 4 seconds it is poor. A poor LCP almost always has a handful of typical causes that can be fixed deliberately.
Oversized images
Uncompressed or oversized images are the most common LCP brake. Modern formats like WebP and AVIF and appropriate sizes per device help immediately.
Slow server response
If the server takes long to send the first byte, everything else is delayed. Caching, lean hosting and less database load shorten the response time.
Blocking resources
Large CSS and script files in the page head hold up rendering. Load critical CSS first and defer or asynchronously load everything else.
The single most effective lever is almost always the LCP image itself. It should be delivered at the correct size, modernly compressed and loaded with high priority so the browser does not queue it behind unimportant resources. Two small markup details make a big difference: a fixed width and height plus a priority hint for the most important image. How to bake fast load times firmly into a build is part of our web design work.
<!-- LCP image with fixed size and high priority -->
<img
src="hero-1200.webp"
srcset="hero-600.webp 600w, hero-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 1200px"
width="1200"
height="675"
fetchpriority="high"
decoding="async"
alt="Meaningful image text" />
<!-- Request the key file early -->
<link rel="preload" as="image" href="hero-1200.webp" />INP: How Fast the Page Reacts to Input
Interaction to Next Paint replaced the older metric First Input Delay in March 2024 (Google) and now measures far more strictly how responsive a page is across the whole visit. It measures the time between an input, such as a click, tap or key press, and the next visible reaction on screen. Good is a value under 200 milliseconds; from 500 milliseconds a page is considered sluggish. A poor INP typically becomes noticeable when a button reacts only after a delay, a menu stutters or a form stalls while typing.
The main cause is almost always too much JavaScript blocking the browser's main thread. While a large script runs, the browser cannot respond to input, so the click feels dead. The remedy is fewer and smaller scripts, splitting long tasks into short chunks and consistently removing unused libraries and third-party scripts. Tracking, chat and advertising scripts from third parties are frequent INP brakes in particular, because they occupy the main thread without delivering visible value to the user.
Less is faster
CLS: Why the Layout Must Stay Steady
Cumulative Layout Shift measures how much visible elements move unexpectedly while loading. Everyone knows the annoyance: you go to tap a link, at the last moment a late-loading image pushes in, and your finger hits the wrong spot. CLS captures this jumpiness in a single number. Good is a value under 0.10; from 0.25 the layout counts as unsteady. Unlike LCP and INP, CLS has little to do with raw speed and everything to do with reserving space cleanly.
- Give images and videos fixed width and height so the space is reserved in advance
- Load fonts so no late reflow occurs, for example with font-display: optional or swap and matching fallbacks
- Give ad slots, banners and embeds a fixed minimum height
- Do not push new content above already visible text; insert it below or into reserved areas
- Show cookie banners and notices as an overlay above the page, not as a block that pushes content down
CLS is often fixable with relatively little effort and brings noticeably more calm to the user experience. A stable page feels higher quality, reduces mis-taps and lowers the frustration that otherwise leads to a quick bounce. How a calm, clear layout translates into more enquiries is explored in our article on conversion optimization.
Why Load Time Decides Revenue and Ranking
The link between speed and business results is well documented. As load time rises, the probability of a bounce climbs sharply: going from one to three seconds increases the bounce probability by around 32 percent (Google), and from one to five seconds by about 90 percent (Google). On the revenue side, a large retail study shows the highest conversion rates occur on pages that load in zero to two seconds, and that each additional second within the first five seconds pushes the conversion rate down by roughly 4.4 percent (Portent). Historically, the retail giant Amazon already put a figure on it: every additional delay of 100 milliseconds (Amazon) costs around one percent of revenue.
Then there is the ranking layer. Google has included the Core Web Vitals as part of the page-experience signal in search (Google). Load time is therefore one of many factors that influence how a page is ranked, especially when several pages are similarly strong in content. Just as important is the indirect effect: fast pages are used more intensively, abandoned less often and shared more, which in turn generates positive user signals. Improving load time thus works on visibility and conversion at once. Across around 50 projects (Projekterfahrung) we regularly see that a noticeably faster experience lowers bounce rates and increases enquiries, even though an exact ranking position can never be guaranteed.
| Aspect | Slow, jumpy page | Fast, stable page |
|---|---|---|
| First impression | Blank screen, late content | Main content visible in under 2.5 s |
| Interaction | Clicks react sluggishly | Response in under 200 ms |
| Layout | Elements jump while loading | Calm, stable layout |
| Bounce rate | High, many lose patience | Lower, more people stay |
| Search | Weaker page-experience signal | Solid technical foundation |
The Plan: Improve Load Time Systematically
Performance work succeeds best in a fixed order rather than blind activity. First you measure where the page really stands today, then you fix the biggest brakes first. The appeal is that a few right measures often deliver most of the gain, especially on the most important image and the script budget. The following sequence has proven a workable foundation.
- Measure with real user data (Chrome User Experience Report) and a lab test to compare field and lab values
- LCP first: shrink the largest visible image, compress it modernly, load it with priority and give it fixed dimensions
- Shorten server response: enable caching, use lean hosting and remove unnecessary redirects
- Tidy the script budget: remove unused libraries and third-party scripts, defer or asynchronously load the rest
- Fix CLS: fixed dimensions for media, clean font loading and reserved space for late-loading areas
- Measure again after every change and check the effect at the 75th percentile across real users
Field versus lab data
A realistic word on expectations belongs here: good Core Web Vitals are a solid technical foundation but not an automatic route to top positions. Google computes rankings from many signals, and load time is one of them. What can be improved steadily are the measurable factors themselves, and they pay off in both search and revenue. Performance is most durable when it is a permanent part of a site's ongoing care rather than optimized once and forgotten, as our ongoing website care provides for. A lean, fast foundation in web hosting also feeds directly into server response.