Why is my website so slow?

Oversized images are the most common culprit

The single most common reason a website is slow is straightforward: it is serving photographs at a size meant for printing or full-screen viewing, when a browser only needs enough pixels to fill the space the image actually occupies on the page. A photo straight off a modern camera or downloaded from a stock library commonly runs 3 to 10 megabytes, and every one of those megabytes has to travel over the visitor's connection before anything appears - the browser has to download the whole file before it can even begin decoding and displaying it. A heavy hero image at the top of the page directly delays the moment visitors see anything at all. Check your largest, most prominent image first: if it is over roughly 300 kilobytes, compress it and re-save it in a modern format like WebP or AVIF, both of which hold visual quality at a fraction of the file size of a JPEG or PNG. On many sites, this one change alone cuts load time by half, because it removes the single biggest file the browser has to wait for.

Too much JavaScript before anything paints

Every plugin, page builder component, chat widget, popup, and tracking snippet added to a page brings its own JavaScript file, and the browser generally has to download, parse, and execute that code before it can finish rendering the page and respond properly to a click or tap. Individually none of these feel heavy. Stacked together, which is exactly what happens on a site that has grown organically over a few years, they add up to real, cumulative delay. Google measures the visible symptom of this through two Core Web Vitals: Largest Contentful Paint, which times how long the main content takes to appear, and Interaction to Next Paint, which times how sluggish the page feels once it has loaded. If your homepage sits blank, or shows a half-rendered skeleton, for a second or more before anything useful appears, script weight - not images, not the server - is almost always the reason, and the fix is usually auditing what is actually installed and removing whatever is not earning its place.

Cheap or distant hosting

Hosting affects every request your site handles, which makes it different from a single heavy image - fix a slow server and every page gets faster at once, not just the one you happened to optimise. Shared hosting, where your site sits on a server alongside hundreds of others competing for the same limited resources, slows down under load in ways that are hard to diagnose from the outside, because the problem is not in your code at all. Distance matters too: a server on the other side of the world from your visitors adds delay to every request simply because data has to travel further and pass through more network hops to arrive. Time to First Byte, the gap between a browser requesting a page and the server sending back the first byte of a response, is the number to watch - anything above roughly 800 milliseconds points at the server rather than the page itself. A content delivery network, which caches your content at locations closer to your visitors, or moving to a host based in your visitors' own region, addresses the distance half of this directly.

No caching

Without caching, your server rebuilds an identical page from scratch for every visitor who requests it, even when nothing on that page has changed since the last request a minute earlier. Browsers face a version of the same problem: without the right caching headers set on your images, CSS, and JavaScript, a returning visitor's browser re-downloads files it already has sitting in its own cache, gaining nothing from having visited before. Turning on page caching at the server level, combined with long cache lifetimes for static assets, means a repeat visit loads almost instantly, because most of the work has already been done once and simply gets reused. Most hosting platforms and content management systems have this built in - it is very often just switched off by default or was never enabled during setup, rather than genuinely unavailable to you.

Third-party embeds you forgot about

Booking widgets, social media feeds, embedded maps, customer review carousels, and A/B testing scripts all have one thing in common: while your page is loading, the visitor's browser is also reaching out to someone else's servers, waiting on a response you have no control over and no way to speed up from your end. If that third party's server is slow, having a bad day, or simply based somewhere with a slow connection to your visitor, your page waits for it regardless of how well-optimised everything else on the page is. Some embeds genuinely earn their place - a booking widget that drives real conversions is worth the cost. Others get added once for a campaign, a test, or a request from years ago and are simply never removed. Go through what is actually embedded on your key pages and cut anything that is not still doing a job.

Render-blocking CSS and web fonts

Stylesheets and custom fonts sit in an unusual position: by default, a browser will not display any content until it has downloaded and processed the CSS needed to style it, because showing unstyled text and then immediately restyling it produces a jarring flash. That is sensible in principle, but it means a large stylesheet, especially one loaded from an external server rather than your own, directly delays the first thing a visitor sees. Web fonts add a second version of the same problem: if body text is set in a custom font that has to be downloaded before it can display, visitors either see invisible text until it arrives, or a flash as a default font swaps out for the real one. Neither failure is catastrophic alone, but both are avoidable - trimming unused CSS and loading fonts so readable text shows immediately rather than making visitors wait for the exact right typeface.

How to find YOUR cause in about a minute

Guessing which of these is actually your problem, and fixing it based on a hunch, is the slow way to get a fast site - most people who try this fix the thing that was easiest to find rather than the thing actually costing the most time. A scan that measures real Core Web Vitals gives you the answer directly instead. AuditHQ pulls this data from Google PageSpeed Insights, the same source Google itself uses when it factors speed into rankings, and reports back whether images, script weight, server response time, or third-party requests are the actual bottleneck on your specific pages, naming the specific offending files rather than leaving you to work it out. The free AuditHQ quick scan takes about 60 seconds and needs no signup, which makes it worth running before spending money on a fix aimed at the wrong cause.

Frequently asked questions