Core Web Vitals on a hospital CMS: where the four seconds go

Hospital websites are slow for structural reasons, not lazy ones. A hospital site is built by a committee, edited by a communications team, extended by three agencies over eight years, and carries appointment booking, doctor directories, department pages, a news section and usually a patient portal login.

That accretion is where the four seconds go. This is the audit we run, in the order that recovers the most time.

The three metrics, briefly

LCP — Largest Contentful Paint. When the biggest above-the-fold element finishes rendering. Target under 2.5 seconds. Almost always the metric a hospital site fails.

INP — Interaction to Next Paint. How quickly the page responds to a tap. Replaced First Input Delay in March 2024. Target under 200ms.

CLS — Cumulative Layout Shift. How much the page jumps while loading. Target under 0.1.

Two things worth knowing about their weight. They are a genuine but modest ranking factor in classical search, and they are unlikely to move you past a substantially better page. But AI Overviews are grounded in the classical index, so anything suppressing indexation or crawl efficiency has a downstream effect on citation eligibility. The argument for fixing them is mostly that a four-second page loses frightened patients on mobile connections, which is a better reason anyway.

Where the time actually goes, in order of recovery

1. The hero image nobody compressed — typically 1.2 to 2.0 seconds

The single largest recoverable cost on most hospital sites.

A 2.4MB JPEG of a building exterior or a stock photograph of a smiling clinician, served at full resolution to a phone, above the fold, blocking LCP.

The fix: convert to WebP or AVIF, serve responsive sizes with srcset, and set fetchpriority="high" on the LCP image so the browser stops treating it as equal to everything else. Lazy-load everything below the fold — and never lazy-load the LCP image itself, which is a common and self-defeating error.

Expect 40–60% of the total problem to be here.

2. Render-blocking third-party scripts — 0.5 to 1.5 seconds

Count what a typical hospital page loads before it renders: analytics, tag manager, a chat widget, an appointment booking script, a review widget, a font provider, a heatmap tool, sometimes two competing analytics installations from different agency eras.

The fix: audit every third-party script and ask who owns it and whether it is still used. In our experience two or three are always orphans from a previous agency. Then defer everything non-critical, and load chat widgets on interaction rather than on page load — a chat bubble does not need to exist before the content does.

Related benefit: this is also the audit that surfaces the trackers firing before consent, which is a DPDP problem as well as a speed one.

3. Fonts — 0.3 to 0.8 seconds

Hospital sites frequently load four to six font weights across two families, from a third-party host, with no fallback strategy. Text is invisible until the font arrives.

The fix: self-host, preload the one or two weights actually used above the fold, and set font-display: swap so text renders in a fallback immediately. Then audit which weights are genuinely used — usually two of the six.

4. The doctor directory — variable, sometimes catastrophic

A page listing 200 consultants, each with a photograph, loading all of them at once. We have seen these exceed 15MB.

The fix: paginate or virtualise, lazy-load below-fold images, and serve directory thumbnails at thumbnail dimensions rather than full-resolution portraits scaled down in CSS.

This page matters disproportionately because it is where the entity graph lives and where referrers land.

5. Layout shift from late-loading elements — CLS

Cookie banners injected after render, appointment widgets that appear once their script loads, images without dimensions, ad slots.

The fix: reserve space. Explicit width and height on every image, min-height on containers that will receive injected content, and render the cookie banner server-side rather than injecting it.

The cookie banner is the most common CLS cause on Indian and Australian clinical sites and among the easiest to fix.

The constraints nobody mentions

Three realities specific to hospital environments that generic performance advice ignores.

You often cannot change the CMS. It is an enterprise platform chosen by IT, integrated with the HIS, and the marketing team has template-level access at best. Recommendations requiring a rebuild are not actionable.

Work within it. Image optimisation, script deferral, font strategy and lazy loading are almost always achievable at template level.

The booking widget is untouchable. It is integrated with the appointment system and nobody will let you defer it in case it breaks.

Negotiate placement instead. If it cannot be deferred, it can usually be moved below the fold or loaded on interaction from a button, which achieves most of the benefit.

Changes go through IT, and IT has a queue. A two-week fix becomes a two-month fix.

Bundle them. One consolidated change request with everything specified beats six separate tickets, and it survives the queue better.

What to measure, and what to ignore

Use field data, not lab data. PageSpeed Insights gives you both. The lab score is a simulation on a specified device; the field data is the Chrome User Experience Report — real visits from real users on real connections.

For an Indian hospital site, the field data is the truth, and it will be substantially worse than the lab score, because a meaningful share of your users are on mid-range Android devices on congested mobile networks.

Ignore the composite score out of 100. It is a weighted lab simulation and moving it from 42 to 68 may not change a single user's experience. Track the three metrics on field data, at the 75th percentile, which is how the thresholds are assessed.

Measure the pages that matter, not the homepage. Consultant profiles, condition pages and the booking flow. The homepage gets audited because it is first in the list; it is rarely where patients land from search.

A realistic sequence

Assuming template-level access and a normal IT queue:

Week one. Audit. Field data for the top twenty pages. Full inventory of third-party scripts with an owner for each. Identify the LCP element on each template.

Week two. Specify. One consolidated change request: image formats and responsive sizes, fetchpriority on LCP images, script deferral list, font subset and preload, explicit dimensions on images, min-height on injection points.

Weeks three to six. Implementation, through whatever queue exists.

Week seven. Re-measure lab data. Field data will take 28 days to reflect the change, because CrUX uses a rolling window — do not panic when it appears unchanged at first.

Expected outcome on a typical unoptimised hospital site: LCP from roughly 4.5 seconds to under 2.5, CLS to under 0.1. INP is harder and usually requires reducing JavaScript rather than reordering it, which is a bigger conversation.

The honest framing

This is Pillar 01 work. It is unglamorous, it takes six to ten weeks on a real hospital estate, and it produces no visible marketing outcome.

It is also non-negotiable, because everything downstream depends on it. Content nobody waits for is content nobody reads. Entity markup on a page that times out on a mobile connection is markup that never gets crawled properly.

The argument we would actually make to a hospital board is not about rankings. A four-second page, loading for a frightened person on a mid-range phone at two in the morning, is a page a meaningful proportion of them abandon before it renders. Everything else in the marketing budget is spent getting them there.