Do not buy a redesign because one speed score is low. Identify the slow pages, what the visitor experiences and which resources cause delay. Then make a measured repair and repeat the same test.
Record the page and symptom.
Write down the URL, device, connection and what feels slow: first content, the main image, a menu response or booking widget. Test an important service or contact page as well as the homepage. One result cannot describe every patient journey.
Keep laboratory tests separate from real-user data. A simulated test diagnoses behaviour under stated conditions; real-user measurements describe visits that occurred. A small site may not have enough field data. Missing data is not proof of good or bad performance.
Understand what the measures describe.
Core Web Vitals cover loading, interactivity and visual stability through Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. They do not measure clinical quality, visual taste or whether reception answers the phone.
Wellfront's free source check is different. It finds signals in fetched HTML, but does not run a browser performance audit or establish Core Web Vitals. Read the score explanation before treating a source finding as a repair specification.
Check image downloads first.
web.dev explains that images can be heavy resources and that appropriate sizes and formats can reduce transferred bytes. Ask the developer to inspect actual downloads, not only how small pictures look on screen. A small card should not require an unnecessarily large original photograph.
Request responsive sizing, sensible compression and a visual quality check. Keep the main image clear. Avoid a blanket rule that lazy-loads every image, including the important image visible immediately. Choose changes from measured evidence rather than adding an optimisation plugin by default.
Give video and widgets a job.
A video, chat tool, map or booking embed should earn its place. Third-party JavaScript can affect loading and responsiveness. List each external component, supplier and what the site loses if it is removed or delayed.
Do not remove a working appointment tool without checking the workflow. In staging, compare with and without a suspected component under the same conditions. A simple link or user-activated embed may be appropriate, but confirm the experience and privacy handling before changing it.
Do not trade speed for broken interactions.
Caching and script-delay settings can break menus, validation or booking tools. Apply one change at a time, keep a rollback copy and test important interactions. A faster page that cannot receive a request is not a successful repair.
Ask for a before-and-after record: page, method, conditions, change and result. Comparable repeat tests are more useful than selecting the best screenshot from unrelated setups. Do not promise that a better score will create a particular ranking or revenue increase.
Choose the smallest useful repair.
If one oversized photograph is the problem, start there. If a shared template or essential third-party tool is responsible, agree a broader plan. Rebuilding becomes a separate decision about maintainability and the patient journey, not an automatic response to a red badge.
Use the worksheet below to brief a supplier. Pair it with our quote checklist so the proposal names what will be tested and what is excluded. Keep contact and request-form tests alongside performance in the acceptance criteria.
Speed-repair evidence worksheet
- URL and symptom: describe what is late or unresponsive.
- Conditions: device, network, tool and whether evidence is lab or field data.
- Resource lead: mark a suspected image, script or server issue as a hypothesis until tested.
- Proposed change: one repair, owner and rollback method.
- Result: comparable evidence, including unchanged measures.
- Journey check: menus, contact links and appointment route still work.
Source notes
Platform guidance checked 18 October 2026. Checklists are Wellfront recommendations, not ranking, booking, clinical or legal guarantees.