Why your website is slow
Almost every slow website is slow for one of about five reasons, and they are findable without being a developer. Before paying anyone to "optimise" a site, it is worth knowing which one you have, because the fixes differ enormously in cost.
Measure it first, on the right device
Your own laptop on office wi-fi is the least representative test available. Check it the way your customers do: a phone, on mobile data, away from your office.
For a number rather than a feeling, run the URL through PageSpeed Insights and read the mobile tab. Ignore the score for a moment and look at the opportunities list underneath. That is the diagnosis, and the score is only a summary of it.
Reason one: the images
This is the answer far more often than anything else.
A photograph off a phone or camera is several thousand pixels wide and often several megabytes. Displayed in a 600-pixel-wide slot it looks identical to one a fraction of the size, but the browser still downloads every byte of the original.
The signs are obvious once you look: a page that takes seconds, then arrives all at once. Images that load top to bottom as you scroll. A homepage that weighs more than a few megabytes in total.
The fix is cheap and mostly mechanical: resize images to the largest size they are actually displayed at, compress them, use modern formats, and load below-the-fold images lazily so they are fetched only when needed. On a typical brochure site this alone can cut page weight by a large multiple.
Reason two: too many third-party scripts
Every tag added to a site (analytics, a chat widget, a heatmap tool, a pixel from an ad platform, a review badge, a font service) is a request to somebody else's server, and your page waits for some of them.
These accumulate invisibly because each is added by a different person for a good reason and nobody removes any.
Audit them. Any tool nobody has logged into for six months is costing you speed for nothing.
Reason three: a page builder doing too much
Drag-and-drop builders make a site anyone can edit, which is a genuine benefit. They do it by shipping a lot of generic code that must cover every layout the builder can produce, not just yours.
This one is not cheap to fix, since it usually means rebuilding, so it is worth knowing before you choose the platform rather than after. If the site is otherwise fine, a builder's overhead may be an acceptable trade for being able to edit it yourself.
Reason four: cheap or distant hosting
If the page takes a long time to begin arriving, a blank screen then everything at once, the server is slow to respond, and no amount of image work will fix it.
Two common causes: very cheap shared hosting where hundreds of sites compete for one machine, and a server physically far from your customers. If your buyers are in Kolkata and your host is in another continent, every request crosses that distance twice.
Reason five: fonts
Custom fonts are downloaded before text can be drawn in them. Loaded carelessly, they produce a page that appears with no text at all for a moment, then fills in. Loading fewer weights, and telling the browser to show a fallback while waiting, fixes most of it.
What order to do things in
Cheapest and highest-impact first:
1. Compress and resize the images. Almost always the biggest win for the least money. 2. Remove third-party scripts nobody uses. 3. Fix font loading. 4. Move to better hosting, if the server is slow to respond. 5. Rebuild off the page builder, only if the first four were not enough and speed genuinely matters to the business.
Most sites never need to reach step five.
Why it is worth doing at all
Two reasons, and the second is the one people underrate.
The obvious one: people leave. On a phone, on mobile data, patience is short, and every second costs you some of the visitors you already paid to attract.
The less obvious one: it gets worse on its own. Nobody sets out to make a site slow. It happens one uncompressed image and one forgotten tag at a time, which is the same process described in why websites get worse after launch. A site that is fixed once and not maintained will be slow again.
If you want someone to look at yours and tell you which of the five it is, send us the URL. It is a short job to diagnose, and knowing which problem you have is most of the value.
Questions people also ask
Aim for the main content appearing in about two and a half seconds on a mid-range phone on mobile data. That is the threshold Google reports on and, more usefully, roughly the point where visitors stop waiting. Test on a phone away from your office wi-fi, because a laptop on a fast connection will always look fine.
Not visibly, at sensible settings. Most of the weight in a photograph off a phone is detail nobody sees at the size it is displayed. Resizing to the largest size the page actually uses and saving at reasonable quality usually cuts the file by a large multiple with no difference a visitor could point to.
Yes, and on a phone more than anywhere else. Every extra second loses some of the people you already paid to attract through ads or search. It also compounds, because the slowest pages are usually the ones with the most images, which tend to be the product and service pages.
The largest win usually, yes. Resizing and compressing images needs no developer, and removing tracking scripts nobody logs into any more is a matter of deciding. Server speed and page-builder overhead are the two that need help, and they are also the two that matter least until the images are sorted.