Why Is My Business Website Slow—and What Should I Fix First?
Check what is slowing your website down, understand PageSpeed Insights and prioritise improvements to images, scripts and loading without chasing a perfect score.
A slow business website can have several causes: oversized photographs, too many scripts, a slow server response or extra services that take time to load. The first useful step is to identify where the delay occurs.
Does the screen stay empty? Does the main photograph arrive late? Or does the page appear quickly but hesitate when you tap the menu? Those are different symptoms, and they point towards different fixes.
Start with the pages customers actually use
Test your homepage, a main service page and your contact page. Open them on your phone using a typical mobile connection as well as on desktop.
Note when the main content becomes readable, whether the menu responds and whether anything moves while you try to tap it. Complete a test enquiry so you include the most important action.
Run those same URLs through PageSpeed Insights. Save the results and date so you have a baseline. One homepage score cannot describe every page or every customer’s experience.
Understand what the speed report is telling you
PageSpeed Insights combines real-user measurements, when available, with a simulated test. The real-user section covers a trailing 28-day period; the test provides a diagnostic snapshot. A smaller site may not have enough real-user data, which does not itself indicate a fault.
Check whether the real-user results describe the specific page or the wider site. Google’s PageSpeed Insights explanation describes the distinction and why results can differ.
Three measures are especially useful to recognise:
- Largest Contentful Paint (LCP): when the largest visible image or text block appears.
- Interaction to Next Paint (INP): how promptly the page visually responds to interactions.
- Cumulative Layout Shift (CLS): how much content unexpectedly moves around.
These are the Core Web Vitals. Their respective “good” thresholds are 2.5 seconds or less, 200 milliseconds or less, and 0.1 or less, assessed at the 75th percentile of visits. See web.dev’s Web Vitals guide for the definitions and measurement details.
Check large photographs first when loading is the problem
A photograph straight from a camera can be much larger than the version needed on a web page. A gallery containing many such files can create unnecessary downloads.
Ask your developer to check image dimensions, compression and whether smaller screens receive appropriately sized versions. Modern formats such as WebP or AVIF can help, but the resulting quality and file size still need checking.
Images further down a page can often wait to load until they approach the visible area. The main image at the top needs different treatment: delaying it can make the page feel slower. web.dev explains the trade-offs in its image loading guidance.
Review scripts, widgets and embedded services
Maps, chat widgets, video players, tracking tools and booking systems can each add work for the browser. Make a list of what is installed and what purpose it serves.
Identify obsolete tools and duplicated integrations. Consider whether a heavy feature needs to load on every page. For example, a location map may be most useful on the contact page, while an embedded video might only need to load when selected.
Ask a developer to test changes before removing anything that powers enquiries, consent choices, payments or other essential functions. If the page displays quickly but taps feel delayed, script execution is one area to investigate.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Investigate hosting when the initial response is slow
If there is a long wait before the page begins arriving, the issue may involve server processing, caching or delivery. Changing the visual design alone may not address it.
Ask what the evidence shows before buying a different hosting package. A server-side delay and a large image download require different work. A useful report should explain the cause, the proposed change and the pages affected.
Our hosting information explains how hosting fits into an AfterWorks website purchase. Performance improvements and development should be described in the agreed scope; hosting is not automatically an ongoing optimisation service.
Fix moving content as well as slow content
A page can load quickly and still feel frustrating if a button jumps just as someone selects it. Images without reserved space, late banners and changing font sizes can contribute to movement.
Watch the page load from the beginning and note what shifts. Ask for space to be reserved for images and embedded content, and for banners to behave predictably. Recheck on a narrow screen, where movement can be more disruptive.
Choose the first fix and check the result
Use the largest observed obstacle to choose your starting point:
- A late main image: investigate its size, delivery and loading priority.
- Unresponsive controls: investigate scripts and browser work.
- A long initial wait: investigate server response and caching.
- Jumping buttons or text: investigate layout stability.
Repeat the same tests after changes, under similar conditions. Simulated scores vary, and real-user results take time to reflect a new version. Also check that menus, forms and useful content still work.
The goal is a smoother customer journey. If the site feels faster but still produces few contacts, use our enquiry troubleshooting checklist. Where performance problems sit alongside outdated structure and content, explore what a website rebuild could address together.
