Remove resources that make the browser download, parse, or execute more than the patient’s task requires. The usual contributors are oversized images, unnecessary video, too many font files, large JavaScript bundles, duplicate tracking tags, and third-party tools loaded on pages where nobody needs them. Total megabytes matter, but so do late resource discovery and long script work.
A healthcare website design audit should inventory every costly resource on one important template, state the job it performs, and test what happens when it is removed or delayed. Anything expensive with no clear visitor or operating benefit is a strong candidate for deletion.
Heavy pages cost time in different ways
Two pages can transfer the same number of bytes and feel completely different. One might display its service answer quickly while loading a gallery later. The other might block all visible content until a font, script, and animation package finish. A useful diagnosis separates four costs:
- transfer cost from images, video, fonts, CSS, and JavaScript;
- processing cost from parsing and executing code;
- rendering cost from calculating and painting the page;
- interaction cost when the main thread cannot respond promptly to a tap.
This is why “the page is 3 MB” is a clue, not a diagnosis. Record which resource is delaying which visible or interactive part of the journey.
Start with a high-intent template such as a service page, location page, provider page, or booking step. Homepage weight is relevant only if the homepage is actually where the important task begins.
Build a resource inventory you can act on
Open the page in a performance tool and capture a cold load. A cold load prevents the browser cache from hiding files that a first-time visitor must receive. Record the page URL, test date, device and network profile, total transfer, request count, and main-thread work.
Then group resources by owner and purpose.
Resource group • Questions to ask • Likely owner
- Lead and content images | Is the displayed size smaller than the source? Is the format efficient? | Design or web team
- Fonts | Which families and weights are actually used on this template? | Brand and web team
- JavaScript | Which feature needs this bundle? Does it run before interaction? | Development
- Tags and trackers | Is each tag current, approved, and free of duplication? | Marketing and privacy owners
- Maps, chat, schedulers, reviews | Is the tool needed on this page and at first paint? | Practice operations
- CSS and component libraries | Is the page shipping styles for components it never renders? | Development
Do not stop at filenames such as `vendor.js`. Trace the bundle or tag to the feature and business owner. A resource with no identified owner is not automatically safe to delete, but it is a governance problem worth resolving.
Images are often large for avoidable reasons
Compare the source dimensions with the maximum displayed dimensions. A 4000-pixel photograph does not belong in a 600-pixel card. Supply responsive variants so a phone does not receive the desktop source. Use WebP or AVIF when the delivery stack and quality review support it, and reserve the image’s layout space so content does not jump as it arrives.
Treat lead images differently from off-screen galleries. The lead visual may need early discovery because it is the page’s largest visible element. Images below the first screen can usually load later. Lazy loading the main image may delay it; eager-loading every image wastes bandwidth. Placement determines the choice.
Look for decorative assets that communicate nothing new: several photographs of the same waiting room, large background textures hidden on mobile, duplicate logos, or a looping video behind readable text. Remove one in a test branch and ask whether the patient loses a useful fact. If not, the asset was carrying cost without carrying meaning.
Font choices can quietly multiply the load
A brand system may specify one family but the website can still request many weights, italics, icon fonts, and legacy files. Check the network log rather than the design file. Each additional file creates transfer and rendering work.
Keep only the weights the rendered page uses. Prefer modern compressed formats, subset fonts when language coverage is understood, and define sensible fallbacks. Google’s web-font performance guidance also recommends checking how fonts are loaded and using `font-display` deliberately so text does not remain invisible while a file arrives.
Do not remove characters needed for clinician names, locations, or the languages the practice serves. Font subsetting is a production decision that should be tested with real content, not applied blindly to reduce a number.
Third-party tools deserve a page-by-page decision
Scheduling, maps, accessibility support, consent controls, review widgets, chat, call tracking, and analytics can each be useful. They can also add network requests, script execution, layout changes, and failure points outside the practice’s code.
Ask three questions for every external tool:
- Does the visitor need it on this page?
- Does it need to load before the visitor asks for it?
- What happens if the vendor is slow or unavailable?
A map can become a static address and “Get directions” link until the visitor chooses to open it. A scheduler can load after a clear booking action rather than during the service answer. A review widget might be replaced by a small, governed proof block. These are examples, not universal instructions. Preserve the function the patient needs and the controls the practice is required to maintain.
Google’s guidance on third-party JavaScript recommends identifying third-party cost and loading scripts efficiently. The strongest improvement is often removing a tag or feature that no longer has a valid purpose.
Set a budget for each template’s job
A page budget is a team limit, not an industry statistic. It can cover transfer size, script work, Core Web Vitals, or a combination. Create the budget from the device and network conditions your patients use, the current baseline, and the task the template must support.
For example, a practice might decide that a service template cannot add a new third-party script unless another cost is removed or the feature passes a documented patient-task test. It might require every card image to be generated at appropriate responsive widths. The exact numbers should come from measured pages and be reviewed after major releases.
Budgets work best when they apply to shared templates. Fixing one URL while future pages use the same unbounded components merely postpones the problem.
Run a deletion experiment before a rebuild
Make a copy of the template in a safe environment. Disable one suspected resource group, then repeat the same load and patient task. Record what improved, what broke, and what changed visually. This experiment turns assumptions into evidence.
Use an order that keeps the result interpretable:
- remove duplicate or unused tags;
- replace or resize the largest avoidable media;
- reduce unused font variants;
- delay nonessential third-party features;
- split or remove code that the template does not need.
Do not switch all five at once. If the page improves, you need to know why. If a booking action breaks, restore it before testing another change.
A well-designed custom conversion website keeps resource decisions at the component and template level, where future pages inherit the improvement. The first useful move today is simpler: audit one service page, find the three costliest resources with the weakest patient value, and test their removal one at a time.