The site opens on the office laptop and looks fine. Then a customer mentions it took forever on their phone, or you open it yourself on mobile data in a car park and watch the logo sit alone on a white screen while the rest catches up. You search for why is my website slow, run a free speed test, and get a page of red marks and jargon that does not say what to actually do.
The usual conclusions are that the hosting needs upgrading or the whole site needs rebuilding. Sometimes one of those is true. More often the causes are few, visible in the browser you already have, and the cheap ones come first. A slow site is not only an annoyance: a visitor who has waited long enough to become irritated rarely fills in a form, and it is one of the quieter reasons a site gets visitors but no enquiries.
Why is my website slow: the usual causes
Images are far larger than the space they fill. Photos go straight from a camera or a stock library onto the page at several times the width of the box they sit in, and the browser downloads the whole file before shrinking it. The sign: the page structure appears quickly, but pictures fill in one by one, and the site is noticeably worse on a phone than on a wired desktop.
Too many plugins, widgets and scripts. A site on a CMS or a builder accumulates add-ons over the years: a slider, a chat widget, several analytics tags, a cookie banner, a booking module nobody uses any more, autoplay video in the header. Each loads its own code before the page can settle. The sign: the page keeps working long after the text is visible, buttons do not respond for a moment, and the layout jumps as pieces arrive.
The server is slow to answer. Before a single piece of the page appears, the browser waits for the server. A cheap shared hosting plan, a CMS that assembles every page from scratch on each visit because caching is off, or a database that has grown for years all show the same way: a blank white screen for a moment, then everything at once.
The visitor is far from the server. A site hosted in one country and visited from another spends time on distance alone; it feels fast at home and slow abroad, and nobody at home notices. The sign: complaints come from a particular region.
Something on the page blocks everything else. A font that must download before any text can be drawn, a map embedded on every page, a script that waits for a third-party service having a bad day. The sign: the site is fine some days and not others, or stays blank until one particular element appears.
How to tell which one is yours
Everything below is done with a phone, a laptop and the free tools already inside your browser. Go in order; the first check that fails is usually your cause.
- Open the site on a phone on mobile data, not on Wi-Fi. Time it roughly with a watch, from tapping the link to being able to read and tap, then do the same on the laptop. A phone that is dramatically worse points to images and heavy scripts.
- Watch what appears first. Reload and note the order. A blank screen followed by everything at once points to the server; text first and pictures trickling in points to images; layout jumping and buttons not responding points to scripts.
- Run one free speed test from a major search engine or browser vendor and ignore the score. Read only the list of largest files and the suggested improvements: they name oversized images, unused scripts and slow server response in plain words. Test a service page, not just the homepage.
- Open the browser’s developer tools on the network tab, reload and sort by size. If the biggest entries are image files far larger than the visible picture, that is your answer; if the list has dozens of scripts from domains you do not recognise, count the plugins.
- List every plugin, widget and third-party tag on the site and write next to each who uses it and for what. In our experience the list is longer than anyone expected, and part of it is dead.
- Check the hosting plan and the caching setting. Log into the hosting panel and see what you pay for and whether page caching is on. If you do not know, the person who built the site does, and the question takes one email.
- Test from your other markets. Ask a colleague abroad to time the same page, or use a free test that lets you choose the test location.
The fix, in order
Cheapest first. In our experience most sites recover most of their speed in the first three steps, without a rebuild.
- Resize and compress the images. Export photos at the size the layout actually uses, in a modern web format, and replace the originals; on a CMS an image-optimisation plugin does the whole library in one pass. This is the most common fix and it costs an afternoon.
- Remove what is not used. Deactivate and delete every plugin, widget and tag that nobody could name a user for, merge duplicate analytics tags into one, replace a live map embed with a static image that links to the map, and lazy-load anything below the first screen.
- Switch on caching. Page caching means the server hands out a ready-made copy instead of assembling the page for every visitor. Most CMS platforms and hosts offer it as a setting or a plugin.
- Fix the blocking elements. Load fonts so that text shows immediately in a fallback and swaps in later, defer scripts not needed for the first screen, and move any video off the header. Usually a developer’s hour rather than a project.
- Move the site closer to the visitor. A content delivery network keeps copies of your static files in many regions, so a visitor in another country downloads from nearby. Most hosts and domain services offer one; if you sell across borders this belongs on the list before any hosting upgrade.
- Upgrade the hosting only when the server is proven slow. If the blank-screen wait remains after caching is on, the plan is the bottleneck. Move to a plan that matches the traffic, not the cheapest one that technically works.
- Rebuild the heaviest pages, not the site. If a template drags dozens of components onto every page, rebuilding the key landing pages on a lighter structure is often enough. In our website projects speed is a launch criterion, and this is the step where a page is designed around what it must do rather than what the theme offers.
Speed also shapes how the site is found: search engines measure the same waits your visitors feel, so the changes above are part of any honest SEO work. And if the site has been slow for a long while, some enquiries have been lost silently; recording where each enquiry comes from, which is where our CRM and analytics projects begin, tells you whether the fix changed anything.
What to measure
- Time to a usable page on a phone over mobile data, timed by hand the same way each time, monthly.
- Page weight and number of requests for the main landing pages, from the network tab, before and after each change.
- Server response time shown in the speed test, the wait before anything arrives, which should drop once caching is on.
- Bounce rate and form completions on the pages you changed, in your analytics, a few weeks after the change against a few weeks before.
Where we come in
An owner with an evening, a developer’s hour and a hosting login can do all of this. What we add is the order: images and dead weight before hosting, caching before a rebuild, and a measurement before and after so that the improvement is a fact and not a feeling. If you would rather hand over the diagnosis, a short brief with the site address and the pages that matter most is enough to start.
