Why your website is slow and who is responsible
Website performance has multiple owners. Here's how to figure out what's causing the problem and who's responsible for fixing it.
From time to time I get confused clients on the phone complaining that their website is slow. Sometimes it's my fault, sometimes it's their fault, sometimes it's nothing to do with either of us.
Website performance is confusing. When a page takes forever to load, it's not always obvious whose problem it is. Sometimes it's the code. Sometimes it's the hosting. Sometimes it's the images you uploaded. Sometimes, honestly, it's something completely random.
Let's break it down.
The things that actually slow websites down
There are roughly four layers where slowness can live, and they have very different owners.
1. The server (your hosting)
When you visit a website, your browser sends a request to a server — a computer somewhere that has your files on it — and waits for it to respond. If that server is underpowered, overloaded, or geographically distant, everything downstream is already slow before your page has even started loading.
Cheap shared hosting is the classic culprit here. You're sharing a server with hundreds of other sites, and if one of them has a traffic spike, you all suffer. It's the broadband equivalent of everyone in the street using Netflix at once.
This one's usually on whoever set up the hosting — which might be your developer, might be you, might be a web agency from 2014 whose phone number no longer works.
2. The code and database
Once the server responds, it often needs to do some work before it sends anything — querying a database, running logic, building a page. If that process is inefficient, you wait.
This is where developer decisions matter most. An uncached database query that runs on every page load. A plugin that phones home to a third-party service on every request. Unoptimised code that does five things when one would do.
This one is squarely on the developer.
3. The assets — images, scripts, fonts
This is where it gets interesting, because this is often where clients are more involved than they realise.
Images are the single biggest source of website slowness in my experience. A photo taken on a modern phone is 5–8MB. If you've uploaded fifty of those through your CMS and nobody's compressed them, your site is serving the equivalent of a small novel just to show your team photos.
JavaScript frameworks, tracking scripts, and chat widgets all add weight too. Every time a marketing team adds a new tool — "can we just add the HubSpot tracking snippet?" — the page gets a little heavier.
Font files. Embedded videos. Third-party maps. I once shaved two seconds off a page load just by removing a Google Map nobody scrolled to.
The developer can build a system that handles this well (automatic compression, lazy loading, caching), but if you're uploading raw files, some of the problem is yours.
4. The network and device
Finally: the connection between the server and the person viewing the site. A 4G connection in rural Scotland isn't the same as fibre in central London. An older phone processes JavaScript more slowly than a new laptop.
You can't fix this directly, but you can build a site that performs well on slower connections — which is mostly about keeping assets small and the page architecture lean.
How to actually diagnose it
Quickest way to check: go to PageSpeed Insights and type in your URL. Google will give you a score and — more usefully — tell you exactly what's contributing to the slowness.
Look for:
- Render-blocking resources — scripts loading before the page appears
- Images that aren't sized correctly — large images being squished by CSS rather than resized at source
- Unused JavaScript — code being loaded that isn't needed on that particular page
- Server response time — if this is high, it's a hosting or back-end problem - speak to your dev.
These aren't always easy to fix without developer help, but knowing which bucket the problem falls into is useful before you have the conversation.
The honest version of who's responsible for what
| Problem | Likely cause | Whose problem |
|---|---|---|
| Slow server response | Cheap/shared hosting | Developer or host |
| Heavy page logic | Inefficient code | Developer |
| Huge images | Uncompressed uploads | Usually the client |
| Too many tracking scripts | Marketing additions | Usually the client/marketing team |
| Slow on mobile | Poor mobile optimisation | Developer |
| Slow on a specific network | Connection quality | Nobody — optimise for it |
None of this is blame-shifting. Most slow websites are slow for a combination of reasons, and fixing them properly usually involves a conversation between you and whoever built or maintains the site.
What you can do right now
If you have a CMS — WordPress, Squarespace, a custom admin — and you manage your own content, check your images. Download one from your site and check its file size. If it's above 500KB, that's something to address. Most CMS platforms have plugins or built-in tools to help with this; your developer can point you in the right direction.
If you don't touch the content side, send the PageSpeed Insights report to your developer and ask them to prioritise the biggest wins. Not everything on the report matters equally — a developer who knows what they're doing can tell you which red flags are actually red and which ones Google is being a bit precious about.
Nobody's ever rung me up to say "the site loaded really fast today, well done." But speed quietly affects everything — your search rankings, your bounce rate, whether someone stays long enough to actually read the page.
Got a slow website and not sure what's causing it? Give me a shout — I'll run a PageSpeed report and tell you what's actually worth fixing.
