Web Development
Core Web Vitals Explained: Is Your Website Fast Enough?
Google measures real-world page experience with three Core Web Vitals: loading, responsiveness and visual stability. Here is what each one means, the thresholds to aim for, and how to improve them.
SAG Encoders · · 3 min read
A slow or jumpy website costs you enquiries. Visitors on mobile data will not wait for a heavy page to load, and a button that does nothing for a second feels broken. Google turned these experiences into three measurable signals called Core Web Vitals. They are worth understanding even if you never think about search rankings, because they describe what your customers actually feel.
The three Core Web Vitals
Largest Contentful Paint (LCP): loading
LCP measures how long it takes for the largest image or block of text in the visible part of the page to appear. It is a good stand-in for "when does the page look ready?". Google's target is 2.5 seconds or less; anything above 4 seconds is rated poor.
Interaction to Next Paint (INP): responsiveness
INP measures how quickly the page updates on screen after someone clicks, taps or types, observed across the whole visit rather than just the first click. A good score is 200 milliseconds or less; above 500 milliseconds is poor. INP officially replaced the older First Input Delay (FID) metric on 12 March 2024.
Cumulative Layout Shift (CLS): visual stability
CLS measures how much content moves unexpectedly while the page is in use, such as a paragraph jumping down when an image or banner loads above it, often just as you try to tap something. Aim for 0.1 or less; above 0.25 is poor.
Google assesses each metric at the 75th percentile of real page loads, separately for mobile and desktop. In practice that means at least three out of four visits should meet the "good" threshold, not only visits from fast laptops on fibre.
How to measure your site
- PageSpeed Insights shows field data from real Chrome users (when Google has enough data for your site) alongside a lab test you can run on demand.
- Google Search Console has a Core Web Vitals report that groups your pages into good, needs improvement and poor.
- Lighthouse, built into Chrome DevTools, runs a lab test on your own computer. It is ideal for checking a fix before you publish it. Because no real person is clicking during its standard test, it reports Total Blocking Time as a stand-in for responsiveness.
Field data is what matters. A page can score well in a lab test on a powerful computer and still be slow for customers on mid-range Android phones and busy mobile networks, so always test on the kind of device your customers use.
Common fixes
Improving LCP
- Compress and correctly size images, and serve modern formats such as WebP or AVIF.
- Do not lazy-load the main image at the top of the page; it should load as early as possible.
- Reduce server response time with caching and a content delivery network (CDN).
- Remove CSS and JavaScript that blocks rendering but is not needed for the first view.
Improving INP
- Break up long JavaScript tasks so the browser can respond to input between them.
- Audit third-party scripts such as chat widgets, trackers and ad tags, and remove the ones you do not need.
- Keep the work done inside click and input handlers small, and show visual feedback immediately.
Improving CLS
- Give images, videos and embeds explicit width and height (or an aspect ratio) so space is reserved before they load.
- Reserve space for banners, cookie notices and ads instead of pushing content down when they appear.
- Load web fonts carefully so text does not reflow when the font arrives.
Why mobile matters most
Google predominantly uses the mobile version of a site's content for indexing and ranking, an approach it calls mobile-first indexing. For most businesses in Nigeria, mobile is also where the majority of visitors are. Design and test for a modest phone on a mobile connection first; a site that is fast there will be fast everywhere.