Why Is Your Medical Website So Slow, and What It Costs You

A patient searching for care on a phone, on mobile data, in a hospital parking lot, will not wait six seconds for your site to load. They will go back to the results and tap the next one. You never see that visit, which is what makes slow sites so easy to ignore. The damage is invisible.

Google measures this directly through Core Web Vitals, so a slow site costs you twice: patients who leave, and rankings that never arrive.

The Five Causes We Find Most Often

1. A Page Builder Doing Far Too Much

Elementor, Divi, and similar tools are wonderful for building quickly and expensive at runtime. They ship large CSS and JavaScript bundles on every page, including the pages that use almost none of it. On healthcare sites we take over, this is the single largest cause.

2. Images Straight From a Camera

A photo of your facility, uploaded at 4000 pixels wide and 5 MB, displayed in a box 600 pixels across. The browser downloads all 5 MB and then shrinks it. Multiply by a gallery and the page is doomed before any code runs.

This is also the easiest thing to fix, and usually the biggest single win. We regularly cut a 5 MB image to 300 KB with no visible difference.

3. Plugins Nobody Remembers Installing

The average WordPress site we audit runs somewhere between twenty and forty plugins. Several are inactive in practice but still loading assets. A few duplicate each other. One is usually a page builder addon pack where a single feature is in use.

4. Hosting That Is Too Cheap for the Job

Shared hosting at a few dollars a month puts you on a server with hundreds of other sites. When they are busy, you are slow. For a healthcare site where a slow load can mean a patient going elsewhere, that is a false economy.

5. Third-Party Scripts You Forgot About

A chat widget, two analytics tools, a heatmap recorder, a review widget, a booking embed. Each is small. Together they often outweigh the site itself. On healthcare sites there is a second reason to audit these: tracking scripts on pages that reveal a patient condition create a compliance problem as well as a speed one.

How to Tell Which One Is Yours

Run your homepage and one service page through Google PageSpeed Insights, and read the mobile score rather than the desktop one. Desktop scores flatter almost every site.

Then read the diagnostics rather than the number:

• Largest Contentful Paint over 2.5 seconds usually means images or hosting
• Cumulative Layout Shift above 0.1 usually means images without dimensions, or fonts loading late
• Interaction to Next Paint that is poor usually means JavaScript, which usually means the page builder or third-party scripts

Those three point at different culprits, which is why the overall score on its own tells you very little.

What Fixing It Actually Involves

In rough order of return on effort: compress and resize every image, then remove or replace the page builder on your highest-traffic pages, then audit third-party scripts and drop what nobody looks at, then add caching and a CDN, then move hosting if the server is genuinely the bottleneck.

Most sites get most of the way there on the first two. We have taken healthcare sites from the 60s into the high 90s on mobile without touching the design, because the design was rarely the problem.

The Compliance Angle Nobody Mentions

There is a second reason to audit third-party scripts on a healthcare site, and it has nothing to do with speed.

Tracking scripts on pages that reveal something about a person's health can transmit that association to a vendor you never signed an agreement with. A pixel firing on a page about a specific condition, or anywhere behind a patient login, is a potential disclosure of protected health information.

Large health systems have been caught by exactly this. The fix is the same work as the speed fix: inventory every script, decide what each one is for, and remove or restrict the ones that cannot justify themselves. You end up with a faster site and a smaller compliance surface from a single afternoon of work.

A Thirty-Minute Self-Diagnosis

Before you call anyone, you can narrow this down yourself.

• Run PageSpeed Insights on your homepage and one service page. Read the mobile tab, and read the diagnostics rather than the score.
• Open your site in a private window on a phone, on cellular data rather than wifi. That is the real experience. Count the seconds out loud.
• Right-click, View Page Source, and search for "script src". Count them. More than fifteen on a brochure site is worth investigating.
• Right-click your largest image and open it in a new tab. If the file is over 500 KB, you have found part of the problem.
• Check your WordPress plugin list. Count how many you cannot immediately explain the purpose of.

Those five checks locate the cause about eighty percent of the time, and you will know whether you are dealing with an afternoon of work or a rebuild.

What Good Actually Looks Like

Targets worth holding yourself to, all measured on mobile rather than desktop:

• Largest Contentful Paint under 2.5 seconds. The main content visible before the visitor reconsiders.
• Cumulative Layout Shift under 0.1. Nothing jumps as the page loads, which matters most on phones where a shifting layout causes mis-taps.
• Interaction to Next Paint under 200 milliseconds. Taps feel immediate rather than laggy.
• Total page weight under 1.5 MB on a content page. Most healthcare sites we audit are running three to four times that.

Hitting all four is achievable on WordPress without exotic engineering. It mostly requires being willing to remove things, which is the part that meets resistance internally.

Why This Gets Worse Over Time

Sites rarely launch slow. They become slow, because every addition is individually reasonable. Marketing adds a chat widget. Somebody adds a review carousel. A new campaign adds a tracking pixel. A staff photo goes up straight from the camera.

No single decision is wrong, and after eighteen months the site takes seven seconds to load. This is why speed belongs in a maintenance routine rather than in a one-off project. Check it quarterly, and the fixes stay small.

Common Questions

Will a caching plugin fix this?

It helps, and it is worth having, but caching hides symptoms rather than removing causes. A page carrying 8 MB of images is still slow for every first-time visitor, and first-time visitors are the ones you are trying to win.

Do we need to rebuild the site?

Often not. Images, scripts, and caching are all fixable in place. A rebuild makes sense when the site has other problems as well, or when a page builder is so deeply embedded that removing it is most of a rebuild anyway.

Does speed really affect rankings?

Core Web Vitals are a confirmed ranking signal, though a modest one next to relevance. The larger effect is behavioral. Slow pages get abandoned, and abandonment is a signal Google reads clearly.

What score should we aim for?

Above 90 on mobile is a reasonable target and achievable for most healthcare sites. Chasing 100 usually means removing things patients actually benefit from.