Why is my website slow? The 12 real causes
The 12 real reasons websites load slowly, ranked by how often they are the culprit — with a free diagnostic method for each.
Most slow websites are slow for one of three reasons: oversized images, too many scripts and plugins, or a slow server response. Start by measuring Time to First Byte. If it is above 600ms the problem is your server or application; if it is fast but the page still feels slow, the problem is in the front end.
First, find out where the time goes
Do not start fixing before you measure. Run the page through a speed test and look at one number first: Time to First Byte. It splits the problem cleanly in two.
TTFB above 600ms means the delay happens before the browser receives anything — hosting, database, or application code. TTFB under 200ms with a slow-feeling page means the delay is in what you are sending — images, scripts, fonts and layout.
Server-side causes
- Underpowered or oversold hosting. The most common single cause. Shared plans with no guaranteed CPU slow to a crawl at peak.
- No caching. Rebuilding every page from the database on every request wastes the majority of your response time.
- Slow database queries. Unindexed tables and bloated post-revision tables are frequent culprits on older sites.
- Outdated PHP version. Moving from PHP 7.4 to 8.3 alone often produces a substantial improvement at zero cost.
- Geographic distance. If the server is far from your visitors, every round trip pays a latency tax.
Front-end causes
- Unoptimised images. Still the number one front-end problem. A 4MB hero photo scaled down in CSS still downloads all 4MB.
- Too many plugins. Each one may add its own CSS and JavaScript to every page, including pages that never use it.
- Render-blocking resources. CSS and JavaScript in the head that must download and parse before anything paints.
- Third-party scripts. Chat widgets, analytics, pixels and ad tags. These are frequently the slowest thing on the page and the easiest to defer.
- Web fonts. Multiple families and weights loaded without
font-display: swapblock text from appearing. - No lazy loading. Loading twenty below-the-fold images before the visitor scrolls.
- Layout shift. Images without width and height attributes cause content to jump, which feels slow even when it is not.
What good actually looks like
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| TTFB | under 200ms | 200–600ms | over 600ms |
| LCP (largest paint) | under 2.5s | 2.5–4.0s | over 4.0s |
| INP (interaction) | under 200ms | 200–500ms | over 500ms |
| CLS (layout shift) | under 0.1 | 0.1–0.25 | over 0.25 |
| Total page weight | under 1MB | 1–3MB | over 3MB |
Test on a throttled 4G connection, not your office fibre. Around 60% of visits arrive on mobile networks.
Fix in this order
Impact per hour of effort, highest first:
- Compress and resize every image, convert to WebP, add width and height attributes.
- Enable server-side and browser caching.
- Update to the current PHP version.
- Defer or remove third-party scripts.
- Audit plugins and delete anything not earning its place.
- Self-host and subset fonts.
- Inline critical CSS and defer the rest.
- Only then consider upgrading hosting.
Frequently asked questions
Only partly. A CDN reduces distance-related latency for static files. If your server takes two seconds to generate the page, a CDN will not help.
It affects everything before the first byte arrives, which on a badly hosted site can be most of the load time. But it will not rescue a 5MB page.
Aim for largest contentful paint under 2.5 seconds on mobile. Under 2 seconds is a genuine competitive advantage.
Yes. Core Web Vitals are a ranking signal, and speed strongly affects bounce and conversion regardless of rankings.