Why slow clinic websites lose patients — and what to do about it.

A clinic website that takes four seconds to load on a mobile phone has already lost a meaningful percentage of its potential patients before they have read a single word. This is not a hypothesis — it is well-documented user behaviour, and it is particularly acute in healthcare, where patients are often searching in a moment of need. The person who needs to book is not browsing. They are decided, or close to it, and they are impatient.

The cost of that friction is invisible in most practice management systems. It does not show up as a cancelled appointment. It shows up as an appointment that was never made — a patient who bounced before the page finished loading and booked somewhere else.

What the numbers say

Google's research on mobile performance is consistent and has held across multiple studies: as page load time increases from one second to three seconds, the probability of a mobile visitor leaving before the page loads increases by 32 per cent. From one second to five seconds, it is 90 per cent. From one second to ten seconds, it is 106 per cent.

For a practice that receives 200 website visitors a month, a 20 per cent improvement in bounce rate — achievable with a well-built site — has a direct impact on the number of patients who reach the booking flow. You can test your current site using Google PageSpeed Insights, which gives you a score and a breakdown of where the time is going.

The number Google gives you is not abstract. It is a proxy for how many of your potential patients are leaving before they see your content.

What ‘performance’ actually means

The two metrics that matter most for clinic websites are LCP and TTI. Neither requires a technical background to understand.

LCP — Largest Contentful Paint

LCP measures how long it takes for the main content of a page to become visible. On a clinic homepage, that is usually the hero image and the headline. LCP is the moment the page feels like it has arrived. Google considers anything under 2.5 seconds good. Above 4 seconds is poor. Most clinic sites we audit are in the 4–7 second range.

TTI — Time to Interactive

TTI measures how long it takes before the page is actually usable — not just visible. A page can appear loaded while buttons do not respond to taps and forms do not register input. This is a common pattern on clinic sites that use third-party booking widgets: the page looks ready, but the widget is still loading, and a patient who taps “Book Now” before it has finished loading gets nothing.

The gap between LCP and TTI — between the page looking ready and being ready — is where a lot of clinic site friction lives, and it is entirely invisible unless you measure it.

The four common causes of slow clinic sites

1. Unoptimised images

This is the most common cause by a significant margin. A hero photograph exported from a camera or a stock library at 3–5MB, uploaded directly to the site, and displayed at whatever size the browser decides. The correct size for a hero image on mobile is typically under 100kb. The image that is costing 4MB of load time is often delivering no more visual quality than one that weighs 80kb — the difference is never visible to the patient; it is only visible in the performance score.

2. Third-party booking widgets

Integrated booking systems — HotDoc, Cliniko, HealthEngine — are essential for most practices, but they introduce load time. A booking widget that adds 800 milliseconds to a page's TTI is adding it right at the most important moment: when the patient is trying to book. Widget load performance varies by provider and by how the integration is implemented. It can often be improved without changing the booking system itself.

3. Font loading handled incorrectly

Custom web fonts are a visual asset and a performance liability if they are loaded naively. The most common failure: invisible text while the font downloads, then a flash as it renders. This is not just jarring — it delays LCP and contributes to a poor perceived load experience. Handled correctly (font-display: swap, preloading critical fonts, subsetting), this penalty is negligible.

4. Shared hosting under load

A clinic website on cheap shared hosting behaves differently during business hours than it does at 2am. Server response times that look acceptable in testing degrade under normal business load. A server that takes 400ms to respond before the browser has loaded a single asset is adding 400ms to every page load, invisibly, at exactly the time when most patients are searching.

What good performance looks like in practice

A well-built clinic website should achieve a Largest Contentful Paint under 1.5 seconds on a 4G mobile connection and a Lighthouse Performance score above 85 on mobile. These are not aspirational targets — they are achievable with deliberate engineering.

The Glow Co Aesthetics clinic site achieves a 1.2 second median page load and a 98 Lighthouse Performance score on mobile. Those numbers did not come from post-launch optimisation. They came from engineering decisions made throughout the build: images processed and served in next-generation formats, fonts preloaded with correct display strategies, no render-blocking scripts, and a hosting configuration sized for the actual traffic pattern.

The key point is the last one: performance is not a feature that can be added to a slow site at the end of a project. It is a consequence of decisions made at every stage of design and build. A studio that does not think about performance until the site is finished will always struggle to achieve results like these after the fact.

If you are running a medical clinic or an allied health practice and you have not looked at your site's performance score recently, it is worth doing. The PageSpeed Insights report takes thirty seconds and will tell you, specifically, where time is being lost. If what you find raises questions, we are easy to reach.