Why your medical website is slow, and what it is costing you
Most practice sites fail Google’s speed thresholds for the same four reasons. Here is how to find out whether yours does, and what to do about each.
Site speed is a ranking factor, but that undersells the problem. The bigger cost is the patients who leave before the page appears, and they never show up in any report you are reading, because they never became a session worth counting.
Google measures this through three metrics called Core Web Vitals. They are worth understanding, because each has a different cause and a different fix.
The three metrics
LCP, Largest Contentful Paint. How long until the biggest visible thing finishes loading, usually your hero image or headline. The threshold is 2.5 seconds. This is the closest proxy for “how long until the page looks ready”.
INP, Interaction to Next Paint. When someone taps something, how long until the page visibly responds. The threshold is 200 milliseconds. This is what makes a site feel sluggish even after it has loaded.
CLS, Cumulative Layout Shift. How much the content jumps around while loading. The threshold is 0.1. This is what makes someone tap the wrong thing because a banner pushed the page down.
Google measures these on real visitors using real devices, not in a lab. A site that is fast on your desktop can be failing badly for a patient on a mid-range Android over mobile data, which is the majority of your traffic.
The four usual causes
1. Uncompressed images
By far the most common. A practice uploads photographs straight from a phone or a camera, often several megabytes each, and the browser downloads the full file to display it at 400 pixels wide.
The fix is unglamorous: resize images to the dimensions they actually display at, serve them in a modern format like WebP or AVIF, and load anything below the fold lazily. This alone resolves the majority of failing LCP scores we see.
2. Page builders
Drag-and-drop builders trade page weight for editing convenience. They load large JavaScript and CSS bundles covering every feature the builder supports, whether your page uses them or not. A site built this way frequently ships several hundred kilobytes of JavaScript to render what is fundamentally a text page.
This is the hardest problem to fix incrementally, because the weight is the architecture rather than a setting.
3. Third-party scripts nobody audited
Chat widgets, analytics, heatmaps, ad pixels, review widgets, social embeds, booking widgets. Each was added for a reason, each loads code from someone else’s server, and nobody has reviewed the list since launch.
Third-party scripts are the most common cause of poor INP, because they compete with your page for the main thread. Audit what is actually loading. Most practices find at least one script for a tool they stopped using years ago.
For medical sites there is a second dimension here: advertising and analytics trackers on pages about specific conditions transmit sensitive inferences to third parties, and that has attracted regulatory enforcement. Worth reviewing on those grounds alone.
4. Fonts loaded from someone else’s server
Loading fonts from a third-party font service adds a connection to another domain before any text can render in the intended typeface. Self-hosting the font files removes that round trip. Setting font-display: swap ensures text is visible in a fallback face immediately rather than invisible while the webfont downloads.
How to check your own site
Two tools, both free:
PageSpeed Insights (pagespeed.web.dev), enter your URL. The top section shows real-world data from actual visitors, which is what Google uses. The lower section is a lab simulation useful for diagnosis. Pay most attention to the mobile tab.
Search Console, the Core Web Vitals report shows every page grouped by status, so you can see whether a problem affects one template or the whole site.
If real-world data is unavailable, your site does not have enough traffic for Google to have collected it. That is worth knowing on its own.
What good looks like
A well-built practice site should load its main content in well under two seconds on a mid-range phone, respond instantly to taps, and not shift while loading. That is achievable without sacrificing anything visual, the sites we build are static HTML with minimal JavaScript, and they look exactly as designed.
Speed is not really a technical goal. It is the difference between a patient reading your page and a patient going back to the search results.