Core Web Vitals are the rare part of this discipline where the definitions, the thresholds and the measurement method are all published. That makes them unusually easy to work with, and it means nobody needs to speculate about what good looks like.
The three metrics
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP | Time until the largest content element renders | 2.5s or less | Over 4.0s |
| INP | Responsiveness to user interactions across the visit | 200ms or less | Over 500ms |
| CLS | Unexpected layout movement | 0.1 or less | Over 0.25 |
The definitions and thresholds are published in the Web Vitals documentation. Assessment is based on the 75th percentile of real user experiences, which is why a fast reading on your own machine tells you very little.
What they are worth
Google's page experience documentation describes these signals as part of how it assesses pages, alongside many other factors, and is clear that great page experience does not override having genuinely relevant content. Treat them as a tiebreaker in search terms.
The stronger argument is on the other side of the click. A clinic enquiry form abandoned because the page moved under a thumb is a lost patient, and that loss is measurable in your own analytics. Make the case internally on conversion and take the search benefit as a bonus.
Largest Contentful Paint on a clinic site
LCP is usually the hero image or the main heading. The LCP documentation breaks it into four phases, and on clinic sites the time is almost always lost in two of them: a slow server response, and resource load delay caused by the hero image being discovered late.
- Serve the hero image in a modern format at the size it is displayed, not a 4000 pixel original.
- Give the hero image
fetchpriority="high"and do not lazy load it. - Lazy load everything below the fold, and nothing above it.
- Inline the critical CSS and load the rest without blocking.
- Do not put the hero behind a slider or a script that has to run before the image is requested.
- Fix the server response time first if it is slow, because every other improvement sits on top of it.
Interaction to Next Paint
INP measures how quickly the page responds when someone interacts, across the whole visit. The INP documentation describes the causes, and on clinic sites they are consistent: too much JavaScript on the main thread, third-party tags, chat widgets, booking embeds and analytics all competing at once.
The fix is subtraction. Audit every third-party script and ask what it does, whether anyone reads its output, and whether it can load later or not at all. Most clinic sites carry at least one tag that nobody can explain, usually left by a previous supplier.
Cumulative Layout Shift
CLS is the most fixable of the three and the most annoying to a patient. The CLS documentation names the usual causes and they are all preventable.
- Images and iframes without width and height attributes.
- Fonts swapping and reflowing text.
- Cookie banners and promotional bars inserted above content after load.
- Review widgets and booking embeds that expand once loaded.
- Content injected by a testing or personalisation tool.
Set explicit dimensions on every image, reserve space for anything injected, and preload the fonts you actually use.
A consent banner that appears after load, pushes the page down and blocks the first interaction damages all three metrics at once. It is also usually the first thing a patient sees. Reserve its space, render it without shifting content, and keep its script small.
Field data, not lab scores
Two kinds of data exist and they answer different questions. Lab tools simulate a load on a defined device and are useful for diagnosis and for comparing changes. Field data records what real visitors experienced and is what assessment is based on. A clinic site with a strong lab score and poor field data usually has a real audience on older phones and slower connections, which is exactly the population a lab test on a fast connection does not represent.
Use the Core Web Vitals report in Search Console for field data grouped by URL pattern, and use a lab tool to work out why a group is failing.
Your own website
HIGH CONTROL- Every byte a crawler receives, and the speed it arrives at
- The entity claims: name, address, identifiers, sameAs, service list
- Canonical URLs, hreflang if used, and the internal link graph
- Whether the page answers the question it was built to answer
- How the answer is displayed once it leaves your server
- Whether a third party republishes an outdated version of your facts
- Crawl the whole site and compare the URL list against the sitemap
- Validate every JSON-LD block against the Rich Results Test
- Measure field data, not only lab scores, for Core Web Vitals
A sensible order of work
- Fix CLS first. It is cheap, mechanical and the most visible to patients.
- Fix the server response time, since everything else depends on it.
- Fix the hero image: format, dimensions, priority, no lazy loading.
- Remove or defer third-party scripts, starting with the ones nobody can justify.
- Re-measure with field data after four weeks, because field data is a trailing window.
Test on the device your patients use
Clinic traffic is predominantly mobile, frequently on mid-range Android devices and mobile networks. Test at 390 pixels wide with network throttling, on a real device if one is available. A site that is comfortable on a desktop with fibre and hostile on a three-year-old phone is a site optimised for the people who built it.
Where performance and accessibility meet
Several performance fixes are also accessibility fixes: stable layout, adequate target sizes, visible focus and content that reflows without horizontal scrolling are all covered by WCAG 2.2. For a healthcare provider, accessibility is a service obligation before it is a technical one, and the overlap means the same work satisfies both.