Guide Speed & Performance

Why your website is slow, and how to find out

A way to work out whether your site is slow because of the server, the page itself, or the network in between.

iFastHosting Support Team Updated 26 August 2026 9 min read Beginner

"My website is slow" is not a diagnosis, it is a symptom, and it has at least four unrelated causes. A site can be slow because the server took too long to answer, because the page is carrying more images and scripts than it needs, because a third-party script is blocking the browser, or because the connection between your visitor and the server is simply a long way. Each of those has a different fix, and none of them are fixed by the other three.

Most people's first move is to upgrade hosting. Sometimes that is right. More often it is not, because most slow sites are slow for reasons a bigger server does not touch. This guide is the diagnostic step to do first, so that whatever you fix next is the thing that was actually wrong.

Stop guessing from how it feels

Your own experience of your own site is the least reliable measurement available. Your browser has cached most of the page already, you are probably close to the server geographically, and you know it well enough to not notice the parts that are slow. Run a proper speed test before you do anything else — it replaces a feeling with a set of numbers you can act on.

The four places slowness comes from

Cause	What it looks like	Where to check
Server response time	A long wait before anything appears, even on a simple page	Time to First Byte (TTFB) in your testing tool
Page weight	The page eventually loads but pulls a lot of data to do it	Total page size and request count
Render-blocking resources	The page is visible but not interactive, or content jumps around as it loads	Waterfall chart, JavaScript execution time
Network distance	The site is fine for you, slow for visitors elsewhere	Testing from a location near your actual audience

These stack. A page can have a fast server and still load slowly because it is three megabytes of uncompressed images, and a page can be small and well-optimised and still feel slow because the server takes a second and a half to start responding. Fixing the wrong one leaves the complaint exactly where it was.

Page weight is the most common cause, by a distance

Before looking anywhere near the server, check what the page is actually made of. On most slow sites the answer is: too many images, saved at a resolution nobody needed, in a format that has not compressed well, loaded by a page that also ships more JavaScript than it uses. A hosting upgrade does not shrink an image or remove a script — it just serves the same oversized page slightly faster, which the visitor may not even notice.

Worth checking specifically:

Images saved at their original camera or design resolution rather than the size they display at on the page.
Plugins, widgets or tracking scripts that were added once and never removed once the reason for them had gone.
Web fonts loaded in several weights when the design only uses two.
Third-party embeds — social feeds, chat widgets, video players — that load fully on every page even when nobody interacts with them.

Guides on each of these are linked from the checklist at the end of this article. The point here is only to notice, before you touch hosting, whether this is where your time is really going.

A faster server does not fix a heavy page

If a page ships four megabytes of uncompressed images, moving it to faster hardware still delivers four megabytes of uncompressed images, just slightly sooner. The visitor's connection speed, not your server's, is usually the bottleneck for a page that heavy — and that is exactly the part hosting cannot change.

How to tell if the server genuinely is the problem

Look specifically at Time to First Byte — the gap between the request going out and the first byte of the response coming back, before the browser has downloaded or rendered anything. A consistently high TTFB on a simple, uncached page — not a product listing running a dozen database queries — is one of the few symptoms that genuinely points at the server or the application running on it, rather than at the page's content.

Separately: does the delay happen on every page, including ones with almost nothing on them, or only on the heavy ones? A slow homepage and a fast contact page usually means content. A slow homepage and an equally slow, near-empty page points further upstream — the server, the database, or code running on every request regardless of what it outputs.

A short diagnostic checklist

Test from outside your own network
Use a testing tool rather than your own browser, and if you can, test from a location near where your visitors actually are.
Note the TTFB separately from the full load time
A slow TTFB points at the server or the application. A fast TTFB with a slow full load points at the page itself.
Check total page size and request count
Anything over a few megabytes, or dozens of separate requests for a simple page, is worth investigating before anything else.
Look at what is largest in the breakdown
Most testing tools show a split by resource type. Images and JavaScript dominate on the majority of slow sites.
Test a near-empty page on the same site
If it is also slow, the cause sits further back than page content — worth reading whether hosting is actually the bottleneck next.

When it genuinely is hosting

Hosting is the right thing to look at when a site is consistently slow under normal, everyday traffic — not just during a spike — when TTFB is high on simple pages that have already been checked for heavy database queries, or when the account is regularly hitting resource limits shown in your control panel's usage panel. Those are signals worth taking to a hosting review; a page carrying unoptimised images is not, no matter how slow it feels.

Once you know which of the four causes you actually have, the rest of this section has a guide for it: compressing images, minifying CSS and JavaScript, cutting the number of requests a page makes, and reading a waterfall chart to see exactly where the time inside a single page load goes.