Photo: Vitaly Gariev on Unsplash
A shopper in Overland Park who looks up a bakery, a dentist or a roofer on a phone decides quickly whether the website is worth the wait. Google measures that experience with three numbers called Core Web Vitals. This guide explains each number in plain English, shows how to test your own site the way phone users see it, and lists what to ask a developer to fix.
What are Core Web Vitals?
Core Web Vitals are 3 metrics from Google that measure how a page feels to a real visitor: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability.
Each metric answers one question a visitor asks without thinking about it. LCP answers “Has the main content shown up yet?” by timing how long the largest image or text block takes to appear. INP answers “Did my tap work?” by measuring the delay between a tap or click and the next visible change on screen. CLS answers “Is the page holding still?” by scoring how much content jumps around while the page loads.
The definitions and targets come from web.dev’s guide to Web Vitals, published by Google. Google Search Central adds that good Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward, and it recommends that site owners reach good scores. A fast page also removes one reason for a visitor to tap the back button and pick the next result.
Knowing what each metric measures leads to the practical question: what score counts as good?
What scores count as good for LCP, INP and CLS?
2.5 seconds or less for LCP, 200 milliseconds or less for INP and 0.1 or less for CLS are the good thresholds. Google reads each one at the 75th percentile of page loads, so at least 3 of every 4 visits have to meet the mark.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
web.dev recommends measuring those percentiles separately for mobile and desktop devices. That split matters, because a site can pass on an office laptop and fail on a phone with a weaker processor and a cellular connection.
Photo: City of Overland Park via Wikimedia Commons (CC BY 2.0, cropped)
For an Overland Park business, the phone score is the one to watch. The customer comparing two dentists from a parking lot near Oak Park Mall, or checking a contractor’s reviews from the sidelines of a youth game, sees the mobile version of the site. The desktop score tells you very little about that moment.
The next step is to see your own scores, and the free tool for that is PageSpeed Insights.
How do you test mobile speed with PageSpeed Insights?
Open PageSpeed Insights, paste a page address, select the Mobile tab and read the real-user field data before the lab score. Then repeat the test on 3 to 4 key pages, such as the home page, a top service page and the contact page, because each page scores separately.
1. Go to pagespeed.web.dev and paste the full address of one page.
2. Select the Mobile tab before you read any number.
3. Read the field data at the top first. It reflects real visits over the previous 28 days.
4. Check the Core Web Vitals assessment. A page passes only when the 75th percentile of all 3 metrics is good.
5. Scroll to the lab data and the list of diagnostics below it.
6. Record LCP, INP and CLS for each key page in a simple spreadsheet.
Photo: freestocks on Unsplash
The lab section works differently from the field section. According to Google’s documentation for PageSpeed Insights, Lighthouse runs the lab test by simulating a mid-tier mobile device on a mobile network. Pages with too few visits for field data fall back to origin-level data, which combines every page on the domain. A site with too few visits overall shows lab data only, and that lab data still points to the causes.
Poor results raise a bigger question for some owners: fix the current site or replace it. Owners weighing a repair against a rebuild can compare their spreadsheet with what a full project for web design in Overland Park covers, from cost to platform choice, before they decide.
Once the numbers are on paper, the causes behind a poor score tend to repeat from site to site.
What slows down a small business website on a phone?
Six common causes slow down mobile pages: oversized images, a lazy-loaded hero image, slow hosting, render-blocking code in the page header, too many third-party scripts, and banners or embeds that load late and push content down.
The first 4 causes delay LCP. web.dev’s guide to optimizing LCP splits the wait into 4 parts: time to first byte, resource load delay, resource load duration and element render delay. Oversized photos stretch the load duration, and the guide recommends compressed images in newer formats such as WebP or AVIF. A hero image marked for lazy loading starts late, and the same guide says never to lazy-load the LCP image. Slow hosting raises time to first byte before anything else starts, and a content delivery network shortens that wait. Synchronous scripts in the page header block rendering, and the guide notes they are almost never necessary.
Third-party scripts hurt INP. Chat widgets, review carousels, booking embeds and tracking tags all run JavaScript on the visitor’s phone. web.dev’s guide to INP explains that heavy script evaluation creates long tasks on the browser’s main thread, and those long tasks delay the response to a tap.
Late-loading content hurts CLS. web.dev’s guide to layout shifts lists images without dimensions, ads, embeds and iframes without dimensions, dynamically injected content and web fonts as the common causes. A promotional bar that drops in above the headline after the page appears pushes everything down, and a visitor who was about to tap “Call” lands on something else.
Each cause has a known fix, so the next question is which fix to request first.
What do you ask a developer to fix first?
Ask for fixes in order of the failing metric: images and the hero image for LCP, scripts for INP, reserved space for CLS, then hosting response time. Ask for a before-and-after PageSpeed Insights report for every page the developer touches.
1. Share the spreadsheet of LCP, INP and CLS for each key page, with the failing metric marked.
2. Request resized, compressed images in WebP or AVIF, with width and height set on every image.
3. Load the hero image early and keep it out of lazy loading.
4. Reserve fixed space for banners, maps, review widgets and video embeds.
5. Audit every third-party script and remove the ones nobody uses.
6. Check server response time, and add a content delivery network when hosting is the bottleneck.
7. Collect a before-and-after PageSpeed Insights report for each page.
A short, specific brief keeps the work focused and the cost predictable. Whoever does the work, the same 3 thresholds decide whether it succeeded.
A fix list is only half the job, because scores drift as a site changes.
How often do you re-check Core Web Vitals?
Once a month, and again after every change to the site, such as a new plugin, a theme update or a new chat widget. Field data covers the previous 28 days, so a fix takes up to 4 weeks to show fully in the real-user numbers.
Lab data in PageSpeed Insights updates the moment you rerun the test, which makes it the quick check right after a developer finishes. Field data moves slowly because it covers 28 days of real visits. Set a monthly reminder, rerun the same 3 to 4 pages, and add the results to the same spreadsheet. A sudden jump in LCP or CLS points straight to the most recent change on the site.
For an Overland Park business, the next step is short: open PageSpeed Insights on your own phone, test the home page and write down 3 numbers. Those numbers turn a vague feeling that the site is slow into a list a developer can act on.
About the author
Bikash Roy is a co-founder of Kansas City Web Design Pros (KC Web Design Pros), where he designs websites and runs the search side for Kansas City businesses. He has eight years in web design and SEO.
Sources
· About PageSpeed Insights, Google for Developers
· Understanding Core Web Vitals and Google search results, Google Search Central
· Optimize Largest Contentful Paint, web.dev
· Optimize Interaction to Next Paint, web.dev
Optimize Cumulative Layout Shift, web.dev