You open your own site on your phone and wait. The tab spins, the screen stays white, and then the page arrives in pieces. Maybe a customer mentioned it, or you ran a speed test and got a red number with a long list of suggestions you could not make sense of. Sooner or later every owner asks the same thing: why is my website so slow, and what should I fix first?
The trouble is that “slow” is a symptom, not a diagnosis. Several quite different problems can leave a website loading slowly, and each needs a different fix. Paying for better hosting does nothing for a page carrying a dozen oversized photos, and compressing photos does nothing for a server that takes four seconds to answer. This post is the triage step in our website speed guide: how to work out which kind of slow you have, using things you can see for yourself, and where each branch is covered properly.
First, describe the slowness precisely
Before opening any tool, answer five plain questions. Write the answers down, because they narrow the search more than any score will.
- Where? On phones only, or on laptops too?
- When? Every time, only on the first visit, or only at busy times of day?
- Which pages? The whole site, the home page, the shop, the checkout?
- Since when? Has it always been like this, or did it change recently?
- For whom? Visitors, or only you and your staff when you are logged in?
An answer like “always slow, every page, every device” points somewhere very different from “fine until Tuesday, now slow on the shop pages”. Keep the notes next to you for the rest of this post.
Why is my website so slow? Split the load in two
Every visit has two stages. First the browser asks your server for the page and waits for the answer. Then it reads that answer, fetches the images, styles, fonts and scripts it mentions, and builds the page on screen. Almost every speed problem lives mainly in one of these two halves, and telling them apart is the single most useful test you can run.
You can often feel the difference. A long blank wait with nothing on screen, followed by the page appearing fairly quickly, usually means the server is slow to answer. A page whose text and layout appear quickly but whose pictures crawl in, or which jumps about, or which ignores your taps for a few seconds, usually means the problem is in the second half: what the page asks the browser to download and run.
To confirm it, look at the server response time in any speed test (often labelled time to first byte, or TTFB) or in the browser’s developer tools, where the first request for the page shows how long it spent waiting. Google treats TTFB as a diagnostic measure rather than one of the Core Web Vitals, and that is exactly how to use it here: as a pointer to which half to look at.
A short decision path
Work through these in order and stop at the first one that matches what you see.
- Long blank screen before anything appears? The server is slow to produce the page. Go to the server branch below.
- Layout appears, then images load slowly or the page feels heavy? The page is carrying too much. Go to the page weight branch.
- Page looks ready but menus, buttons and forms lag? Scripts are keeping the browser busy. Go to the scripts branch.
- The page waits on requests to other companies’ servers? A third-party service is holding things up. Go to that branch.
- None of the above clearly, but the problem depends on device, timing or a recent change? Skip to the patterns section further down.
Most real sites have more than one of these at once. That is normal. Fix the branch that accounts for the biggest share of the wait first, then test again before moving on.
Branch one: the server is slow to answer
When the wait happens before the browser receives anything, the time is being spent on the server. On a WordPress site that usually means PHP is building the page from scratch for each visitor and the database is answering a lot of questions along the way.
Likely causes include:
- No page cache, so every visit rebuilds the page.
- A plugin doing slow work on every load, such as calling an outside service or running heavy database queries.
- An old PHP version, or a server short of memory and processing power.
- A crowded shared hosting plan hitting its limits.
- A server physically far from the people visiting it.
A quick check you can do yourself: open a static file on your site directly in the browser, such as an image from your media library or /robots.txt. If that arrives instantly but full pages take seconds, the network is fine and the delay is WordPress doing work. If even the static file is slow, look at the hosting and the distance to the server. Our post on what your hosting controls and what it does not covers this branch in depth.
Branch two: the page is too heavy
If the server answers quickly but the page still takes a long time to finish, the browser is downloading too much. Open your browser’s developer tools, go to the Network panel, reload the page and look at the total transferred size at the bottom, then sort the list by size. The biggest items are nearly always images, followed by video, large script bundles and web fonts.
Common finds: photos straight from a phone or camera uploaded at full resolution, a slider loading every slide at once, a background video, and images several times wider than the space they fill. The guide to how heavy images slow a site down shows how to spot the worst offenders and what to do about each.
Branch three: scripts keep the browser busy
Some pages are not especially large, yet they feel sluggish. You tap the menu and nothing happens for a moment. You scroll and the page stutters. This is usually JavaScript: the browser is busy running code from the theme, the page builder and several plugins, and it cannot respond to you until it finishes.
This branch is much worse on phones, because a mid-range phone runs scripts far more slowly than a laptop. Signs include long lists of script files in the Network panel, a speed report mentioning “reduce JavaScript execution time” or long main-thread tasks, and plugins that add features to every page even though you only use them on one. The fixes here (loading scripts later, removing unused ones, replacing heavy plugins) belong to later sections of the hub, so treat this as the place to recognise the problem rather than solve it.
Branch four: someone else’s server
Your page may be fast in itself and still wait on outside services: a chat widget, analytics and ad pixels, web fonts, an embedded map, a social feed, a booking calendar. Each one is a request to a server you do not control. If that server is slow, your visitor waits.
In the Network panel, look at the domain column. Anything that is not your own domain is a third party. Chrome lets you right-click a request and block its domain, then reload, which is a safe way to see how the page behaves without that service. If the page suddenly feels quick, you have found a major part of the problem. The post on third-party scripts and how to audit them walks through deciding what to keep.
Patterns that point somewhere specific
Go back to your five answers. Some combinations have their own explanations, and each has its own post in this section.
Fast on your laptop, slow on phones. Phones have slower processors and often slower connections, and some sites send phones different, heavier content. See why a site can be slow on mobile but fine on desktop.
Slow the first time, quick after that. The second visit benefits from files already saved in the browser and pages already cached on the server. That points to how your caching behaves, explained in why the first visit is slower than the rest.
Fine until recently. Something changed: an update, a new plugin, a problem at the host, a wave of bot traffic. The upside is that a change gives you a date to work back from. Start with what to check when a site suddenly slows down.
Slow only at busy times. That suggests the server runs out of capacity under load rather than being slow in itself. Only the home page. Look at what the home page carries that inner pages do not. Only for logged-in users. Logged-in visitors usually bypass the page cache. Each of these also has its own post in this section.
Measure before you change anything
Whatever branch you land on, take a baseline first. Without one you cannot tell whether a change helped, and speed tests vary enough from run to run to fool you.
- Pick two or three pages that matter: the home page, a main service or product page, and the contact or checkout page.
- Test each one three times with the same tool, the same location and the same device setting, and note the middle result.
- Record the server response time, the Largest Contentful Paint, the total page size and the number of requests.
- Test on mobile as well as desktop.
- After each change, repeat exactly the same tests.
A plain spreadsheet is enough. The point is to compare like with like.
Mistakes that waste time and money
- Buying new hosting before checking. If the server answers quickly, a faster server will not fix a heavy page.
- Stacking optimisation plugins. Two caching plugins, or a caching plugin plus a separate minifier plus a host’s own cache, often fight each other and can break the layout.
- Chasing the score instead of the experience. The number is a guide. What matters is how quickly a real visitor can read and use the page.
- Testing only on the office connection. Your customers are often on phones and mobile data, not on your desktop.
- Changing five things at once. If something improves, or breaks, you will not know which change did it.
Frequently asked questions
Can my website be slow for me but fast for other people?
Yes. Your own connection, device, browser extensions and the fact that you are logged in can all make the site look slower to you than to visitors. Try it on your phone over mobile data with a private tab, and ask a friend in another city to load the same page. If they see the same delay, it is real.
Is a slow website always the hosting company’s fault?
No. Hosting causes a slow server response, but many slow sites answer quickly and then load heavy images, scripts and outside services. Check the server response time first. If it is short and the page is still slow, the cause is on the page itself, and moving host will not change much.
How fast should a small business website load?
Google’s published guidance for Largest Contentful Paint is 2.5 seconds or less for a good experience, measured across real visits. Rather than chasing a precise number, aim for the main content to appear quickly on an ordinary phone and for the page to respond as soon as someone taps it.
Will installing a speed plugin fix the problem on its own?
Sometimes it helps a lot, especially if the site had no page caching at all. But a plugin cannot shrink photos already uploaded at full size, remove a heavy chat widget or make a crowded server faster. Find out which branch your problem is in first, then choose the tool that addresses it.
Once you know which branch you are in, many of the fixes are within reach of a careful owner. If you would rather hand them over, our website speed optimisation service (₹2,499 onwards) begins with an audit in PageSpeed Insights, GTmetrix and Lighthouse, gives you a prioritised list of fixes, and makes changes only with your approval.
All guides in this section
- Website Slow on Mobile but Fast on Desktop? Here’s Why
- Website Slow on First Load but Quick After That?
- Website Slow at Peak Times? Why Busy Hours Hurt
- Website Slow in Other Countries? Fixing Overseas Speed
- Website Suddenly Slow? A What-Changed Checklist
- Website Slow After Installing a Plugin? What to Check
- WordPress Slow When Logged In but Fast for Visitors?
- Homepage Loads Slowly? Why Only the Home Page Is Slow
- Website Slow After Migration? What Didn’t Move With It
- Website Slow After a Redesign? Why New Sites Get Heavier
Next in this series: Website Slow on Mobile but Fast on Desktop? Here’s Why
