A fast medical website loads its main content within 2.5 seconds, responds to taps within 200 milliseconds and does not jump around while it loads. Those are Google's Core Web Vitals targets, measured on real visitors' phones and computers. Most clinic sites that miss them do so for the same few reasons: a booking widget or chat tool loading on every page, a stack of tracking scripts, a homepage slider, and photos uploaded straight from a camera.
This guide gives the exact thresholds from Google's web.dev documentation, shows how to read a PageSpeed Insights report, and walks through each common culprit with how to check it and how to fix it.
The Core Web Vitals thresholds
Google defines three Core Web Vitals. A page passes when the 75th percentile of visits, measured separately for mobile and desktop, is in the "good" band for all three (web.dev).
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | When the main content (usually the hero image or headline) appears | 2.5 s or less | 2.5 to 4.0 s | Over 4.0 s |
| Interaction to Next Paint (INP) | How quickly the page responds to taps, clicks and typing | 200 ms or less | 200 to 500 ms | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
INP replaced First Input Delay as a Core Web Vital in 2024 (web.dev). Older audits that still report FID are out of date.
Time to First Byte
Time to First Byte (TTFB) is how long the server takes to start sending the page. It is a supporting metric. web.dev says "Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds" (web.dev). You may see "aim for under 600 ms" quoted elsewhere; Google's own guide uses 0.8 seconds as the rough target. A slow TTFB pushes every other metric later, and the fix is usually hosting, server caching or a CDN.
How fast medical and other sites really are
Most of the web still fails on mobile. The HTTP Archive Web Almanac 2024, which analyses millions of sites using Chrome's real-user data, reports:
| Measure (2024) | Mobile | Desktop |
|---|---|---|
| Sites with good Core Web Vitals overall | 43% | 54% |
| Good LCP | 59% | |
| Good INP | 74% | 97% |
| Good CLS | 79% | |
| Good TTFB | 42% |
Mobile is where clinic sites lose. Patients search on phones over mobile networks, and Google indexes the mobile version of your site. Our page speed statistics page collects more of these numbers with sources.
How to read PageSpeed Insights
PageSpeed Insights shows two reports for any URL, and they answer different questions (Google).
- Field data ("Discover what your real users are experiencing"). This comes from the Chrome User Experience Report: real Chrome visitors over the previous 28 days. The pass or fail verdict at the top uses the 75th percentile of LCP, INP and CLS. If your page has too few visits, PageSpeed Insights falls back to data for the whole origin, and smaller practice sites may show no field data at all.
- Lab data (the Lighthouse score out of 100). This is one simulated load on a mid-range phone with a throttled connection. It is useful for finding causes and testing fixes, but it does not measure INP, and the score moves from run to run.
A practical routine:
- Test the homepage, your top service page, one location page and the booking page. These are the pages patients land on.
- Check the mobile tab first.
- Read the field verdict. If it fails, note which metric.
- Scroll to the Lighthouse diagnostics and match them to the culprits below.
- Fix one thing, retest in the lab, and wait 28 days for the field data to reflect it.
For sites with enough traffic, the Core Web Vitals report in Google Search Console groups URLs with the same problem, which saves testing pages one at a time.
Common culprits on clinic sites, and how to fix each
These are the patterns that show up again and again on practice websites. The table gives the quick version; details follow.
| Culprit | Usually hurts | How to check | Fix |
|---|---|---|---|
| Unoptimised hero and team photos | LCP | Lighthouse "Properly size images", "Serve images in next-gen formats" | Resize, convert to WebP or AVIF, preload the hero |
| Lazy-loading the hero image | LCP | Lighthouse "Largest Contentful Paint image was lazily loaded" | Load the hero eagerly with high priority |
| Homepage slider or carousel | LCP, CLS | LCP element is a slide; layout shifts as slides load | One static hero image with one clear message |
| Booking widget on every page | INP, LCP | Lighthouse "Reduce the impact of third-party code" | Load it only on booking pages, or on click |
| Live chat widget | INP | Same report; chat script in the long tasks | Delay until the visitor interacts or after a few seconds |
| Stacked tracking scripts and pixels | INP | Count tags in your tag manager; check third-party report | Remove unused tags; review each for privacy |
| Reviews or social feed embeds | INP, CLS | Third-party report; layout shift on load | Static review excerpts with a link out |
| Images and embeds without set dimensions | CLS | Lighthouse "Image elements do not have explicit width and height" | Set width and height or aspect-ratio |
| Web fonts loading late | CLS, LCP | Text flashes or reflows on load | Fewer font files, font-display: swap, preload the main font |
| Slow hosting | TTFB, LCP | TTFB over 0.8 s in field data | Page caching, better hosting, a CDN |
Images
Images are the LCP element on 73% of mobile pages, and 16% of mobile pages with an image LCP were lazy-loading it in 2024, which delays it (Web Almanac 2024). The same report found 66% of mobile pages had at least one image without set dimensions, a common cause of layout shift.
Clinic sites are photo-heavy: the building, the team, the treatment rooms, before-and-after galleries. Resize each image to the largest size it will display, convert it to WebP or AVIF, and give the hero image high fetch priority. On WordPress, a caching plugin such as WP Rocket or an image optimisation plugin can do most of this automatically; see our WordPress plugin guide.
Booking widgets, chat and other third-party tools
The Web Almanac found 92% of pages load at least one third-party resource (Web Almanac 2024, third parties). On a medical site these are usually the online booking widget from the practice management system, a live chat or AI chat tool, a reviews widget, a map embed and several analytics or ad tags.
Each one adds JavaScript that competes with the patient's taps. Fixes, in order of impact:
- Scope. Load the booking widget on the booking page and the chat tool on the pages where people actually use it. Most tag managers and WordPress performance plugins can restrict a script by URL.
- Delay. Load chat and review widgets after the first interaction or a few seconds after load. A "Book online" button that opens the widget on click costs nothing until it is clicked.
- Replace. Swap a live Google Maps embed for a static map image linked to your Google Business Profile, and a reviews carousel for a few written quotes with a link.
- Remove. Audit your tag manager. Old campaign pixels and duplicate analytics tags are common, and each one is also a privacy question on a healthcare site. Google says it does not offer a BAA for Google Analytics (Google), and HHS has published guidance on tracking technologies (HHS). Fewer tags is faster and lower risk.
Sliders and page builders
Homepage sliders load several large images, shift the layout as they rotate, and usually put the LCP element behind a script. Replace them with one hero image, one headline that says what you treat and where, and one booking button. Heavy page builders add CSS and JavaScript to every page; if your theme relies on one, a caching plugin's "remove unused CSS" and "delay JavaScript" options often recover a large share of the cost.
Hosting
Shared hosting that is slow to respond pushes TTFB past 0.8 seconds before anything else happens. Turn on page caching first, then add a CDN, then upgrade hosting if TTFB is still slow in the field data. If your site collects any PHI through forms, the host also needs to sign a BAA, which narrows the choice.
Why speed matters for a practice
Google says "Core Web Vitals are used by our ranking systems," and also that there is "no single signal" and that relevance comes first (Google Search Central). Relevance decides first. Between two equally good clinic pages, the faster one has the edge.
The larger effect is on patients. Published case studies collected by Google's web.dev team include a 31% LCP improvement at Vodafone that led to 8% more sales, and a 43% better bounce rate at The Economic Times after passing Core Web Vitals (web.dev). These are retail and media sites, and the same mechanism applies to clinics: a patient deciding between three practices on a phone gives up on the one that stalls.
A 30-day speed plan for a clinic site
| Week | What to do | Why |
|---|---|---|
| 1 | Test the 4 key templates on mobile; list failing metrics; remove unused plugins and tags | Find the causes; take the free wins |
| 2 | Compress and resize images; fix the hero image; set image dimensions | Fixes most LCP and CLS problems |
| 3 | Scope or delay booking, chat, reviews and map embeds | Fixes most INP problems |
| 4 | Turn on page caching and a CDN; review hosting TTFB | Lifts every metric |
| Then | Recheck field data after 28 days | Field data lags changes by up to 4 weeks |
Speed is one item in a wider technical health check. Our guide to common healthcare website problems covers the rest, and the technical SEO audit checklist puts it in one list.
FAQ
What is a good page speed for a medical website?
Use Google's Core Web Vitals targets: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, at the 75th percentile of real visits on mobile. Treat the Lighthouse score out of 100 as a lab estimate, and judge patients' experience by the field data verdict.
Why is my PageSpeed score different every time I test?
The Lighthouse score comes from a single simulated load, so network timing, server load and third-party scripts change it from run to run. The field data at the top of the report is a 28-day rolling measure from real Chrome users and is far more stable. Make decisions on the field data and use the lab score to test fixes.
Does page speed affect Google rankings?
Yes, to a degree. Google says Core Web Vitals are used by its ranking systems, but that relevance and helpfulness come first and that chasing a perfect score purely for SEO may not be the best use of time. Speed matters most when your page and a competitor's are otherwise similar.
Do online booking widgets slow down a website?
They often do, because they load the vendor's JavaScript, fonts and sometimes an iframe on every page where they appear. Load the widget only on the booking page, or open it when the patient clicks "Book online," so the rest of the site stays fast.
My site has no field data in PageSpeed Insights. What should I do?
Smaller practice sites often lack enough Chrome traffic for page-level field data. Check whether origin-level data is shown, and use the Lighthouse lab results to find and fix problems. The thresholds are the same, so fixing lab issues on mobile is still worth it.
