Site speed generates disproportionate anxiety. It is a real but modest ranking factor and a genuine factor in whether patients stay. This lesson explains the metrics plainly and, more importantly, says when to stop.
The three metrics
Core Web Vitals measure loading, interactivity, and visual stability:
- Largest Contentful Paint. How long until the main content appears. This is the one that correlates with people leaving.
- Interaction to Next Paint. How quickly the page responds when someone taps or clicks.
- Cumulative Layout Shift. How much the page jumps around while loading. High shift is why someone taps the wrong thing as content moves.
Each has good, needs-improvement, and poor thresholds. Aim for good, and treat the boundary as a target rather than an emergency.
Why it matters for a clinic
Less for ranking than people assume, and more for conversion:
- Patients often arrive on mobile, sometimes on poor connections.
- A patient in distress has little patience for a slow page.
- Layout shift on mobile makes the call button move as someone reaches for it.
- Speed is a tiebreaker between otherwise comparable results, not a primary factor.
So treat it as removing friction from the path to a phone call, which is a clearer way to think about it than chasing a score.
What actually causes slow clinic sites
In practice the causes are boringly consistent:
- Enormous unoptimised images. The single biggest cause. A full-resolution photograph of the waiting room served at original size.
- Too many third-party scripts. Analytics, chat widgets, booking embeds, tracking pixels, tag managers. Each one blocks and each one was added by someone who has left.
- Heavy page-builder themes loading code for features you do not use.
- Hero video, which is almost never worth its cost.
- Web fonts loaded in several weights.
- Chat widgets, which are frequently the heaviest single item on a clinic site.
- Cheap shared hosting with slow response times.
The fixes, in order of return
- Compress and resize every image, serve modern formats, and lazy-load anything below the fold. This alone usually fixes most of the problem.
- Audit third-party scripts and remove what nobody uses. Be ruthless: if you cannot name who reads the data, delete it.
- Reserve space for images and embeds so nothing shifts as it loads. This fixes layout shift directly.
- Defer non-essential scripts, including chat, until after the page renders.
- Limit font weights and load them efficiently.
- Use decent hosting and a CDN.
- Enable caching.
When to stop
This is the part usually missing. Stop when all three metrics are in the good range on mobile for your important pages.
Do not pursue a perfect score. Diminishing returns arrive quickly, and past a certain point people start removing things patients need, such as the map embed or the appointment form, to win points that change nothing. A site that loads promptly and lets someone call in one tap has succeeded, whatever the score says.
Measuring sensibly
- Test on mobile, since that is where the constraint is.
- Prefer field data from real visitors over lab tests where available. Search Console reports this.
- Test your actual important pages: homepage, an office page, a treatment page.
- Re-test after adding any third-party script, because that is how sites silently degrade.
Accessibility is next, and it overlaps with this more than you would expect.

