Blurred figure rushing past a stone doorway with a stopwatch resting on the threshold, illustrating which page speed metrics actually matter for clinic websites.

Page speed for clinic sites: what actually matters in 2022

ByGus

Every audit I do, the same conversation: the clinic’s marketing person shows me a PageSpeed Insights score of 38 on mobile and asks how we get it to 90. The honest answer is that the score is not the goal, and the path from 38 to 90 has very little to do with what a parent in a parking lot actually experiences. The score is a proxy. Like all proxies, it tells you something true and several things misleading. Clinic site page speed is the thing that score is a proxy for, and the two are not the same.

This post is about what to actually optimize on a clinic site in 2022, in the order that actually matters.

What “clinic site page speed” actually is

Page speed is not one number. It is a collection of measurable events along the timeline of a page loading. Google has standardized three of them under Core Web Vitals:

  • Largest Contentful Paint (LCP). How long until the biggest visible element on the page finishes rendering. Target: under 2.5 seconds.
  • First Input Delay (FID), now being replaced by Interaction to Next Paint (INP). How long the page takes to respond when the user taps something. Target: under 100 ms for FID, under 200 ms for INP.
  • Cumulative Layout Shift (CLS). How much the page jumps around as it loads. Target: under 0.1.

Those three are the ones Google uses in ranking. They are also the ones that most closely match what the parent in the parking lot actually experiences. The PageSpeed Insights overall score is a weighted blend of these plus several others, and the weighting changes between releases. Chasing the score chases a moving target. Chasing LCP, INP, and CLS directly is the work.

The interventions that actually move LCP

LCP is usually the bottleneck on clinic sites. Five interventions move it more than anything else, in roughly this order of impact:

  1. Optimize the hero image. The home page hero is almost always the LCP element. Most clinic sites serve a 3000-pixel-wide JPEG when the phone needs an 800-pixel one. Convert to WebP or AVIF, serve responsive sizes via srcset, lazy-load everything else. This one change usually drops LCP by 1 to 2 seconds.
  2. Cache HTML aggressively. Most clinic sites do not change content hourly. A 4-hour Nginx FastCGI cache or equivalent at the CDN edge turns a 1.2-second TTFB into a 40-millisecond TTFB. The browser waits less, the LCP triggers earlier.
  3. Self-host fonts. Every external font request is a TCP handshake, a TLS negotiation, and a download from a third party. Self-hosted fonts with preload hints save 200-500 ms on the first paint and remove a third-party dependency. We have written elsewhere about the broader case for self-hosting.
  4. Defer non-critical CSS. Page builders ship 200 to 600 KB of CSS, of which the home page uses about 20 KB. Inlining the critical CSS and deferring the rest moves LCP earlier without changing what the user sees.
  5. Drop the page builder’s runtime, if possible. Some page builders ship a JavaScript runtime that loads before the page can paint. On Kadence or Bricks this is minimal. On older Divi or Elementor builds it can be 200 KB of blocking JavaScript. The fix is either a different builder or a build pipeline that strips the runtime when not needed.

If those five are done, LCP is usually under 2.5 seconds on a mid-range Android phone on 4G. That is the threshold Google’s algorithm cares about, and it is the threshold the parent cares about.

The interventions that move INP

INP measures how long the page takes to respond when the user taps something. The bottleneck is almost always JavaScript executing on the main thread.

  • Remove third-party scripts you do not need. Every analytics script, chat widget, and tag manager tag executes on the main thread, often for hundreds of milliseconds.
  • Defer the scripts you do need. Most scripts do not need to execute before the page is interactive. Move them to defer or async attributes, or load them after window load.
  • Minimize page builder bloat. The same page builders that ship 600 KB of CSS often ship 400 KB of JavaScript. The interactive parts of the page (forms, navigation) usually need 20 KB.

INP is rarely the worst problem on a clinic site, because clinic sites tend to be lightly interactive. But a chat widget or a tracker can push INP past 200 ms without anyone noticing.

The interventions that move CLS

CLS is the cheapest to fix and the most often forgotten. The page jumps because elements are rendered before their dimensions are known, and the layout shifts when they finally load.

  • Set explicit width and height attributes on every image, including responsive ones. The browser reserves the space, the image fills it, no jump.
  • Reserve space for ad slots, embeds, and dynamic content. If a third-party widget renders late, give it a fixed-size container so the rest of the page does not move.
  • Avoid late-loaded fonts that swap and reflow text. Use font-display: optional or font-display: swap with a metric-matched fallback.
  • Skip animated entrance effects on above-the-fold content. They look modern in design tools and cost CLS in production.

A clean clinic site can have CLS under 0.05 just by setting image dimensions and not animating the hero. Most do not, because the page builder did not enforce it by default.

What does not actually matter

A few things show up in optimization advice that are not worth your time for a clinic site in 2022:

  • Minifying HTML. Saves a kilobyte. Cache and Brotli compression already handle this.
  • Eliminating render-blocking CSS in a way that breaks the design. Deferring all CSS produces a flash of unstyled content that is worse than the original problem.
  • Server-push of resources. The HTTP/2 push spec has been deprecated. Use preload links instead.
  • Service workers. For a marketing site that is rarely revisited, the cache benefit is minor and the maintenance cost is real.
  • HTTP/3. Marginal improvement on top of HTTP/2 for most sites. Worth turning on at the CDN if it is free, not worth chasing.

Each of these appears in SEO checklists. Each of them, on a clinic site, has diminishing returns compared to the LCP and INP work above.

The right measurement loop

PageSpeed Insights runs against an idealized device. The Chrome User Experience Report (CrUX) data inside it shows what real users are experiencing. Look at the field data first, lab data second. If field data shows your LCP is 4.2 seconds and lab data shows 1.8 seconds, the lab is misleading and the field is right. Your users are slower than the test.

Set up Web Vitals tracking in real production. There are small libraries that send LCP, INP, and CLS measurements from real users to your analytics platform. After two weeks of data, you know exactly where you stand and where to invest.

The score will follow. It always does. Optimizing for the score in isolation is chasing the proxy. Optimizing for what the parent in the parking lot experiences is the actual work, and the score takes care of itself. See the related post on what Monday mornings teach, where this same principle shows up from a different angle.

Similar Posts