The short answer
Core Web Vitals are three Google measures of how a page feels to real visitors: how fast the main content appears (LCP, aim for 2.5 seconds or less), how quickly the page reacts to taps and clicks (INP, under 200 milliseconds) and how much the layout jumps around (CLS, under 0.1). Google says good scores line up with what its ranking systems reward, but relevant, helpful content still comes first. Check the Core Web Vitals report in Search Console, fix the page groups marked Poor or Need improvement, starting with your most visited pages, and confirm the fix with real visitor data.
What Core Web Vitals are and how Google uses them
Core Web Vitals are a set of metrics that measure real visitors' experience of loading, responsiveness and visual stability. Google's Search Central page on Core Web Vitals recommends that site owners reach good scores, and says they form part of the page experience that its core ranking systems aim to reward.
Google's page experience guidance adds two important limits. Relevance comes first, so a slower page with the best answer can still rank. And good results in the Core Web Vitals report do not guarantee top positions. Where several practices have similarly useful pages, a better experience can help. The honest way to think about it: fix real problems for real visitors, and do not expect speed work to make up for thin service pages.
Largest Contentful Paint (LCP)
LCP is the time until the biggest image or block of text in the first screen appears. Google's target is 2.5 seconds or less from when the page starts loading. On most practice websites, the LCP element is the hero photo or the main headline on the homepage and service pages.
The usual causes of a slow LCP are a slow server response, a large hero image, an image that starts loading late, and scripts or styles that hold up the first paint. The web.dev guide to optimizing LCP breaks it into those parts. One easy mistake to check for: lazy loading the hero image. It delays the very element LCP measures.
Interaction to Next Paint (INP)
INP measures how quickly the page visibly responds after a visitor taps, clicks or types, across the whole visit. Good is under 200 milliseconds; web.dev rates anything over 500 milliseconds as poor. INP replaced the older First Input Delay metric.
On practice sites, slow INP usually comes from too much JavaScript: chat widgets, booking embeds, review carousels, several tracking tags and page builder add-ons all competing for the same processor. A patient who taps "Request appointment" and sees nothing happen may tap again, or leave. Removing scripts you no longer use is often the biggest single improvement.
Cumulative Layout Shift (CLS)
CLS scores how much visible content moves unexpectedly while the page is in use. Good is under 0.1; web.dev treats values over 0.25 as poor. A shift is what happens when a patient goes to tap the phone number and a banner loads above it, pushing the link down.
Common causes are images and video embeds without set dimensions, cookie or promotion bars that push content down instead of overlaying it, web fonts that swap in at a different size, and widgets that insert themselves after load. The fix is usually to reserve space: give images and embeds width and height, and place late-loading elements where they will not move existing content.
How to measure them
There are two kinds of data, and it helps to know which one you are looking at:
- •Field data: measurements from real Chrome users over the previous 28 days, from the Chrome UX Report. This is what Google's thresholds apply to, judged on the 75th percentile of visits for mobile and desktop separately, as web.dev explains.
- •Lab data: a simulated page load on one device and network, run by Lighthouse. It is good for finding causes and testing fixes, but per Google's PageSpeed Insights documentation a good lab score (90 or above) does not guarantee good real-world experience.
Start with the Core Web Vitals report in Search Console. It groups similar pages, labels each group Poor, Need improvement or Good by its worst metric, and shows mobile and desktop separately. Smaller sites may see "not enough data", because Chrome only reports pages and origins with enough real visits; in that case use PageSpeed Insights lab results as your guide.
Then run PageSpeed Insights on one page from each problem group. It shows the field data, if any, plus lab diagnostics that point to the specific image, script or element causing the problem. Test the mobile view first, since most patients visit on phones.
Common fixes on practice websites
Work through these in order, checking the report after each change rather than doing everything at once:
- •Right-size images: export photos at the size they display, compress them and use a modern format such as WebP or AVIF. Load the hero image normally and consider giving it a high fetch priority; lazy load only images further down the page.
- •Audit third-party scripts: list every chat, booking, review, video and tracking script. Remove the ones nobody uses, and load the rest after the main content where the vendor allows it.
- •Reserve space: set width and height on images, video and map embeds, and keep banners from pushing content down after load.
- •Speed up the server response: good hosting, caching and a content delivery network help pages start arriving sooner. Avoid chains of redirects on your main pages.
- •Trim page builder weight: heavy themes and plugins load code on every page. Removing unused features or moving to a lighter build can help all three metrics.
Pro tip
After a fix goes live, open the issue in the Search Console report and choose Start Tracking. That starts a 28-day check of real visitor data. It does not ask Google to recrawl anything, so there is no need to request indexing for speed changes. Our site speed guide goes deeper on loading problems, and our mobile guide covers layout and tap targets on phones.
Why it matters for patients
The search effect is real but modest. The bigger reason to care is what happens after someone lands on your site: a patient looking for an emergency appointment on a phone wants the phone number and booking button to appear quickly, respond to the first tap and stay where they are. Each of the three metrics maps to one of those moments.
Measure the effect on your own site instead of relying on industry averages. Note the date of each fix, then compare calls, form submissions and online bookings from the affected pages for the weeks before and after, using the conversion tracking you already have. If your site needs a rebuild rather than a tune-up, our website design service builds pages with speed checks as part of the process.
Sources
- •Google Search Central: Understanding Core Web Vitals and Google search results
- •Google Search Central: Understanding page experience in Google Search results
- •web.dev: Web Vitals
- •web.dev: Optimize Largest Contentful Paint
- •web.dev: Interaction to Next Paint (INP)
- •web.dev: Cumulative Layout Shift (CLS)
- •Search Console Help: Core Web Vitals report
- •PageSpeed Insights: About PageSpeed Insights
Frequently Asked Questions
What Core Web Vitals scores count as good?
Google's targets are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. They are judged on the 75th percentile of real visits, separately for mobile and desktop, so most of your visitors need to have a good experience, not just you on office Wi-Fi.
How much do Core Web Vitals affect rankings?
Google says good Core Web Vitals line up with what its ranking systems reward, but relevance comes first: it will still show the most relevant page even if its page experience is weak. Good scores do not guarantee top positions. Treat them as basic site quality that helps most when several practices have similarly useful pages.
Why do PageSpeed Insights and Search Console show different results?
PageSpeed Insights shows two kinds of data. Field data comes from real Chrome users over the previous 28 days and is what Search Console uses. Lab data is a single simulated load on one device and network, useful for finding causes. A good lab score does not always mean real visitors have a good experience.
Do I need a developer to fix Core Web Vitals?
Some fixes are simple, such as resizing and compressing photos or removing a widget you no longer use. Others, like slow server response, heavy scripts or layout shifts from embeds, usually need whoever built or hosts the site. Start with the Search Console report so the work goes to the page groups that actually need it.
How long until fixes show up in Search Console?
Field data covers a rolling 28-day window, so changes appear gradually. After a fix, use Start Tracking on the issue in the Core Web Vitals report to begin a 28-day validation. Starting tracking does not ask Google to recrawl or reindex anything; it just watches the data.