Website loads slowly: the most common causes and how to find them

“Slow” means different things. A page can take three seconds before anything appears, or appear at once and then keep shifting and loading for ten more seconds. The fix is different in each case, so the first step is to find out which kind of slow you have.

Every browser has the tools you need. Open the page in a private window (so that your login and cached files do not flatter the result), open the developer tools and look at the Network tab, then reload the page. You will see a waterfall: every file the page requested, in order, with a bar showing how long each one took. Two figures matter most.

• Time to first byte (TTFB): how long the server took to start answering the request for the page itself, the first line of the waterfall. This is the server’s share. On a well set up site it is well under half a second from inside the same continent.
• Time until the page is usable: when the main content is visible and you can click on it. The gap between this and the first byte is the browser’s share: images, scripts, styles, fonts and embedded content.

If the first byte takes two seconds, your problem is on the server: caching, hosting or the application. If the first byte arrives quickly and the page still takes five seconds to settle, the problem is in what the page loads afterwards. Test from a phone on mobile data as well as from your office, and test a few pages, not only the home page. Product and category pages are often the slow ones.

For small and medium company websites, the causes below account for almost every complaint we see, roughly in this order. Work down the list; the most likely cause is at the top.

No page cache. A content management system builds each page from the database on every request. With a page cache the server keeps the finished page and hands it out without rebuilding it, which turns a one-second response into a few milliseconds. Many sites have a caching plugin installed but not switched on, or configured so that a cookie set by a consent banner or analytics tool keeps every visitor out of the cache. The test is simple: load a page twice in a private window. If the second response is not much faster than the first, there is no effective cache.

Slow or crowded hosting. Cheap shared hosting puts hundreds of sites on one server, so your first byte depends on what the neighbours are doing. If your measurements swing between 0.4 and 4 seconds across the day with no change on your side, the server is the bottleneck. A page cache hides much of this, but admin work, searches and checkout still suffer.

Uncached personalised pages. Shops and portals cannot cache pages that show a basket, a customer price or an account name, so those pages are built fresh every time. Fast sites keep the personal part small and load it separately, so that the rest of the page can still come from the cache. If only logged-in pages are slow, this is the cause, and the application itself needs attention, not the hosting.

Database bloat. Years of revisions, spam comments, expired sessions, logs from plugins and leftovers of plugins removed long ago make the database large and slow. Each page then runs the same queries against far more data. The symptom is a site that was fine when launched and has slowed a little every month since. A clean-up and a few indexes often give back most of what was lost.

Oversized images. The most common cause after caching, and the easiest to fix. A photo straight from a camera is 4 to 8 megabytes; the page needs a version of a few hundred kilobytes at most, in a modern format, sized for the space it fills. Sort the waterfall by size: if the biggest entries are images, resize and compress them, and make the content management system do it automatically for every upload from now on.

Too many plugins and scripts. Every slider, pop-up, social feed, tracking tag and form builder adds JavaScript that the browser must download and run before the page is fully usable. Thirty active plugins is not unusual on a site that has grown for years, and many of them are no longer used. Each one you remove makes the page lighter and the site easier to keep secure.

External embeds. An embedded map, video player, chat widget or booking calendar loads from someone else’s server, and your page waits for it. A single chat widget can add a megabyte of scripts. Load such things only when the visitor needs them: show a static map image with a link, load the video on click, open the chat only after the page has finished.

No CDN for far-away visitors. If your server is in Frankfurt and your customers are in Lisbon or Warsaw, every file travels across the continent. A content delivery network keeps copies of your images, scripts and styles close to the visitor. It does not help a slow server, but for a company that sells across Europe it is the difference between fast at home and fast everywhere.

The figures are illustrative, not measurements of a real site, but the shape is typical. The product page of a small manufacturer took 7.3 seconds in total. Switching on the page cache cut the server response from 1.8 to 0.3 seconds. Resizing and compressing the images, which were the camera originals, took the image share from 2.4 to 0.6 seconds. Removing nine unused plugins and loading the map and the chat widget only on demand saved most of the remaining time. The page now settles in 1.8 seconds, and nothing about its design changed. Three cheap changes delivered almost all of the gain, and none of them required a new website.

With these notes you can either fix the obvious things yourself or give a performance review a clear starting point instead of a vague complaint. If the measurements point at the server, compare what you pay for with what managed hosting for a business site should provide: a page cache that works, enough capacity at peak times and someone who watches the response times. Settle speed before a redesign, because a new design on the same slow foundations will disappoint in the same way.