Images, fonts and page weight on clinic sites

Page weight is not an abstract quality score. It is the number of bytes a patient's phone has to receive on a mobile connection before the page is usable, and on clinic sites it is dominated by two things: photographs and typefaces.

Where image weight comes from

The typical failure is a photograph uploaded at its original camera dimensions, resized by CSS to fit a container, and served in full to every device. A four megabyte original displayed at 800 pixels wide has wasted almost all of what it transferred.

• Serve at display size. Generate the sizes you actually use and serve the right one with srcset and sizes.
• Use a modern format. WebP or AVIF with a JPEG fallback where necessary. Google's image documentation covers the practical guidance.
• Always set width and height. This reserves space and prevents layout shift, and it costs two attributes.
• Lazy load below the fold, never above it. Lazy loading the hero delays the metric you were trying to improve.
• Compress deliberately. Most photographs are visually indistinguishable at a quality setting well below the default.

Clinical imagery, handled properly

Before and after photographs and other clinical images carry regulatory requirements as well as technical ones. Treat the regulatory question first: whether the image may be published at all, with what consent and with what accompanying information. Only then optimise the file. Consent for clinical photography is a clinical record matter, not a marketing one, and should be documented as such.

Fonts

A clinic site commonly loads two or three families at five or six weights, several of which appear nowhere on the site. Each weight is a separate file and each is a request on the critical path.

1. Audit which families and weights are genuinely used, then delete the rest from the load.
2. Two families is enough for any site. Three is a decision that needs defending.
3. Preload the fonts used above the fold.
4. Use a font display strategy that shows fallback text immediately rather than leaving text invisible while the font loads.
5. Choose a fallback with similar metrics so the swap does not move the layout.
6. Self-host where it simplifies the connection sequence, or preconnect where you do not.

Video and embeds

An auto-playing background video on a clinic homepage is the single most expensive design decision available. If video is required, use a poster image, load the player only on interaction, and never autoplay a large file on mobile. The same applies to map embeds, booking widgets and review carousels: load them when they are needed, not before.

Third-party weight

Third-party scripts often exceed the site's own code. Build a list: chat, analytics, tag management, consent, booking, reviews, heatmaps, advertising pixels and anything else. For each, record what it does, who reads its output and what it costs. Anything with no owner comes off, and most clinic sites have several.

The site's own code

Page builders generate a great deal of markup and stylesheet for a small amount of visible content. The realistic clinic response is not a rebuild but a settings audit: turn off the modules and animation libraries the site does not use, and stop loading assets on pages that do not contain the components they belong to.

Setting a budget

A budget makes the decision explicit before it is made badly. A workable one for a clinic page: under one megabyte transferred for the initial view on mobile, under one hundred kilobytes of JavaScript executed before interaction, two font families with at most four weights, and one hero image under two hundred kilobytes. These are starting values to argue with, not published standards, and having any budget is better than the alternative.

Testing what patients actually get

Test at 390 pixels wide with the network throttled, and on a real mid-range device if you have one. Record the transferred bytes, the number of requests and the time until the main content is visible. Repeat after each change. A single number per page, tracked over time, keeps performance visible rather than periodic.

Alt text is not a performance issue, and matters anyway

Every meaningful image needs alternative text describing what it shows, for screen reader users and for anyone whose images fail to load. Decorative images should carry an empty alt attribute so they are skipped. WCAG 2.2 sets the standard, and for a healthcare provider this is part of providing an accessible service rather than an optimisation.

Where the weight comes back

Page weight is not fixed once. It creeps back through ordinary content editing: a new hero uploaded at full resolution, a testimonial slider added by a plugin, a tracking pixel added for a campaign that ended a year ago. Every clinic site that was optimised eighteen months ago and never checked since is heavier now than when the work finished.

The counter is a monthly measurement rather than a project. Record transferred bytes and request count for three pages: the homepage, the busiest treatment page and a location page. Three numbers, once a month, in the same document as everything else you track. When one of them jumps, you know within four weeks rather than at the next audit.

Fixing it at the point of upload

The most reliable fix is upstream of the site. Whoever adds content needs a resizing step in their routine and a maximum file size they are asked not to exceed. Most content management systems can generate the sizes automatically, and configuring that once removes the problem permanently for everyone who edits the site afterwards, including the people who will never read this article.