A slow website does not always need rebuilding. A large photograph, an unnecessary external widget or a slow response from the server can each create a different problem. Buying more hosting or installing another optimisation plugin before diagnosing the delay can leave the original cause untouched.
For a Cheltenham business, the useful question is what a potential customer experiences when opening a service page, choosing a product or sending an enquiry. Start with that journey, then use measurements to explain it.
Describe what feels slow
Try the page on a phone using mobile data as well as your usual connection. Note the exact address and what happens. Does the screen stay blank? Does the photograph arrive late? Does a button appear promptly but ignore the first tap? Does content move while you are trying to read?
These observations point to different areas of investigation. Loading, responsiveness and stability are related, but they are not interchangeable.
Check an internal page as well as the homepage. A gallery, product listing or booking page may have different images and scripts, so one fast landing page does not establish that the whole site is fast.
Read a speed report without chasing a single score
Google's PageSpeed Insights combines information from a controlled test with real-user data where enough is available. The controlled result helps reproduce a problem; the real-user measurements describe experience over time. Treat a missing real-user report as missing evidence, rather than a pass.
The Core Web Vitals cover loading, interaction and movement: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Google's guidance assesses them at the 75th percentile of visits and distinguishes field measurements from laboratory tests. A single Lighthouse run cannot measure every part of a real visit. Google's Web Vitals guidance.
Save the report with the date, page address and test conditions. Repeating the same test makes a later comparison more useful than remembering that the old score was orange.
Work from the expensive part of the page
Ask the developer to identify the main delay and propose a change tied to it. Common investigation areas include:
- Images: photographs delivered far larger than their displayed size.
- Video: prominent background media that starts downloading before a visitor needs it.
- External tools: chat, booking, review or marketing widgets making extra requests.
- Page code: unnecessary scripts competing with customer interactions.
- Hosting: a slow first response before the browser can display anything.
- Layout: content arriving without enough space reserved for it.
These are possibilities to measure, not a diagnosis of your particular website. A visible large image may be worth improving, but it should not distract from a slow server or a broken external request.
Decide which features earn their cost
Every feature should justify its effect on the page and its ongoing maintenance. A booking tool that customers rely on may deserve space and development attention. An animated carousel that repeats information already below it may be easier to remove.
Ask what changes for the visitor if a feature disappears. If the answer is little, simplifying may be a sensible first experiment. If the feature supports a key task, investigate a lighter implementation or load it when needed.
Keep accessibility in the decision. Removing visible text or hiding essential controls to improve a numerical score would defeat the purpose. Our mobile website checklist covers usability checks that should accompany performance work.
Example: a photographic portfolio that feels heavy
Suppose a Cheltenham interior designer has uploaded full-resolution project photographs directly from a camera. This is a hypothetical example.
A useful first scope would examine the images actually delivered at different screen sizes, the order in which the page downloads them, and whether the opening photograph appears promptly. The developer could prepare appropriately sized versions and defer images further down the page where suitable.
The acceptance check would compare the same portfolio page before and after, inspect the visual quality, and open several projects on a phone. It would not stop at making the homepage score look better while the project pages remain difficult to use.
Ask for evidence with the fix
A clear performance handover should explain the cause found, what changed, what was measured and any remaining constraint. Compare like with like: the same page, similar test conditions and more than one run when results fluctuate.
Real-user reports may take time to reflect a change. A laboratory improvement supports a narrower conclusion: the measured test got better. It does not establish increased sales or a particular search ranking.
If slow pages are affecting your business, website development and improvements in Cheltenham can start with focused diagnosis. Send the slow page to James, describe the device and action involved, and include any recent changes. That gives us something concrete to investigate before discussing a rebuild.