Website speed is the gap between somebody tapping a link and being able to use the page. It is not a single number, and one change rarely fixes it. Most sites are slow for two or three dull reasons, and those reasons repeat from site to site.
This article works through the usual causes in the order they matter, so you can tell a real fix from an expensive one. Some of the answer sits in the build itself, which our overview of web and mobile app development deals with. The rest you can fix on the site you already have.
What people mean by website speed
Three separate things hide inside the phrase, and knowing which one you have makes the fix obvious.
- How long until anything useful appears on the screen.
- Whether the page answers when somebody taps a button.
- Does the layout hold still, or does it jump while the rest loads?
A page can finish loading slowly and still feel quick, provided the useful part arrives first. Equally, a page can score well in a test and feel awful on a phone in a car park. Website speed is what your visitors experience, not what a tool reports.
What a slow site actually costs you
People leave. That is the whole mechanism, and it needs no statistic to be obvious.
Somebody who gives up before the page appears never sees your offer, so the cost lands twice on paid traffic: you bought that click and got nothing for it. Meanwhile the visitors who do wait form an opinion of the business from the waiting. A slow site reads as a careless one, particularly when you sell something expensive. So website speed is a sales problem before it is a technical one.
The things that really slow a website down
Start here rather than with a plugin promising to fix everything at once. Slow sites tend to share the same short list of causes.
Images, the usual culprit
Photographs are usually the heaviest thing on a page, and nobody notices because they look fine on the office connection.
A picture straight from a phone camera is far larger than any web page needs. The browser downloads all of it, then shrinks it into a small box on the screen. Resize the file to the size it actually displays, compress it, and most of the weight disappears.
A worked example, with round numbers picked to make the arithmetic easy rather than to describe your site. A gallery holds twelve photographs and each file weighs four megabytes, so the page carries forty eight megabytes of pictures. Resize and compress each one to two hundred kilobytes and the same twelve pictures come to under two and a half megabytes.
Scripts nobody remembers installing
Every tag, chat widget, popup tool, heatmap and testing script runs on the visitor's phone, competing for the same small pot of attention.
These arrive one at a time over years, usually for a campaign that ended long ago. Open your tag manager and your theme settings, then write down what loads. In practice, a few usually belong to tools nobody has opened in a year.
Fonts, sliders and video backgrounds
Custom fonts can hold up your text while the font file downloads, so the words show up late. Two weights of one family is usually plenty.
Sliders and video backgrounds are the ones worth arguing about, because the weight they add is certain and the benefit is not. They load early and push the real content down. A visitor who came for your prices gains nothing from a loop of footage. Cutting one is the rare change that speeds a page up and simplifies the design at the same time. Both are website speed decisions dressed up as design ones.
The server, and what it does before answering
Before any of that, the server has to build the page. On cheap shared hosting with a heavy theme, that step alone can take longer than everything else combined.
Two signs point here. The first byte arrives slowly even on a simple page, and the site feels worse when more people visit at once. If both are true, no amount of image work will save you.
Website speed on a phone is the test that counts
Open your analytics and look at the split between phone and desktop visits. Whichever way it falls, the phone half is the half people test least.
So do your testing there. Put the site on a phone, turn off the office wifi, and open your three most important pages. Whatever irritates you will irritate a customer with less patience and less interest in your business. A layout that only behaves on a laptop is a separate problem, and our piece on responsive web design covers that side of it.
Fix website speed in this order
Work down the list and stop when the pages feel right. The order matters, because the early items cost nothing and the later ones cost real money.
- Resize and compress every image on your busiest page templates.
- Give images and adverts a declared width and height so nothing jumps.
- Remove scripts and plugins nobody uses any more.
- Delay whatever survives that cut until after the page has painted.
- Switch caching on, then consider a CDN if your visitors are spread out.
- Only then talk about moving hosting or rebuilding the theme.
Most sites get the improvement they need from the first three. The last two are where budgets disappear quietly.
Caching, and what a CDN really does
Caching means the server stops rebuilding the same page for every visitor and hands over a copy it prepared earlier. On a content site it is often the biggest single gain for the least work. Check what your host and your platform already do before buying a plugin. You may have some of it running already.
A CDN keeps copies of your files in many places, so a visitor far from your server still receives them quickly. It earns its keep when your audience sits in several countries. For everybody else it answers a website speed problem they do not have, since distance was never the delay. A CDN also puts another layer between you and your site. That matters on the day something breaks and you have to work out which layer is serving an old copy.
How to measure website speed honestly
Two kinds of measurement exist, and people mix them up constantly.
A lab test scores one page on a machine in ideal conditions. It helps with diagnosis, because it lists what is heavy. Field data comes from real visitors on real devices, and that is the version worth reporting to anybody. Chasing a perfect lab score is a hobby rather than a project.
Test your templates rather than your home page. The article layout or the product layout covers far more addresses, and it is usually the one nobody has looked at. One template repair improves every page built from it, which is the best return available in this whole area. If you want the names these measurements go by, our explainer on core web vitals goes through them in plain language.
When website speed work stops paying
This is the part most articles leave out. Speed work has a floor, and past it you spend money on numbers nobody feels.
Once a page appears quickly on a mid range phone, the next round of tuning usually costs more than it returns. Meanwhile a page answering the wrong question stays useless at any speed. If your enquiries are thin, the copy and the offer deserve your attention first.
Automatic optimisation plugins deserve the same caution. They can break layouts and switch off scripts you needed, and hunting the damage afterwards takes longer than doing the work properly would have.
Website speed during a redesign or a rebuild
A rebuild is the cheapest moment to deal with this, because no decision has hardened yet.
Ask about page weight while the design is still on paper. A homepage with a full screen video, three sliders and six web fonts will be slow, and no amount of later tuning changes that. The platform matters too, which is why choosing a CMS is partly a speed decision. If a rebuild is already on the table, our piece on planning a website redesign covers the traffic risks that come with it.
Speed also decays. New pages, new plugins and new campaign tags arrive every month, so a site that started quickly drifts. Catching that drift belongs in ordinary website maintenance, and a quarterly look costs far less than a rescue once a year.
What to ask whoever builds your site
You do not need to read code to hold a useful conversation about website speed. Four questions do most of the work.
- Which page template is slowest, and what makes it slow?
- Do we resize images on upload, or store them as they arrive?
- What third party scripts load on every page, and who still uses them?
- How does the site behave on a mid range phone on mobile data?
Vague answers tell you something in themselves. Anybody who works on the site weekly can answer all four without checking.
One page, one afternoon
Pick the page that carries the most traffic and run that phone test on it. Then write down everything that appears before the useful content does.
Compress the images on that one page, remove one script you no longer use, and look again. Website speed improves in small visible steps like that, and the first hour usually buys more than the next ten.
Frequently asked questions
What counts as a good website speed?
There is no single figure worth quoting. Aim for the useful part of the page appearing quickly on a mid range phone using mobile data, with no jumping layout and no delay when somebody taps. Judge website speed on what real visitors experience rather than on a lab score, and compare your own pages against each other over time instead of chasing a number somebody quoted at you.
Why did my website suddenly get slower?
Something new usually arrived. A fresh plugin, a tracking tag added for a campaign, a page built with one enormous photograph, or a theme update that pulled in extra scripts. Start with what changed in the last month rather than rebuilding anything. If nothing changed on your side, ask your host whether the server is busier than it used to be.
Do images really make that much difference?
Yes, and they are often the single biggest cause. A photograph straight from a camera carries far more detail than a screen can show, and the browser downloads all of it before shrinking it into a small box. Resizing pictures to the size they display, then compressing them, removes a large share of the page weight and needs no developer on most platforms.
Does website speed affect Google rankings?
Probably a little, though nobody outside the search engines can measure how much, and the weighting changes over time. Treat speed as a tie breaker at best, between pages that answer the question equally well. It will not lift a weak page above a strong one, so ranking is a thin reason to spend on it. The better argument for fixing website speed has nothing to do with search. People leave slow pages, and a visitor who gives up costs you the same whether or not a search engine noticed.
Will a caching plugin fix everything?
No. Caching stops your server rebuilding the same page for every visitor, which helps a great deal, yet it does nothing about a gallery of huge photographs or a stack of tracking scripts. Switch caching on, because it is cheap and usually included already. Then keep working down the list, since the heavy images and the unused scripts still sit in front of every visitor.
Do I actually need a CDN?
Probably not, unless your visitors are genuinely spread across several countries. Look at the country report in your analytics before deciding, because distance is the only thing a CDN fixes. It does nothing about the weight of the page itself, since a huge photograph is still huge when it arrives from somewhere nearer. Fix the images and the scripts first, then measure again. Sign up when the map tells you to, rather than when a plugin suggests it.
How often should I check website speed?
Once a quarter suits most sites, plus a check after anything big, such as a redesign, a new tracking tag or a plugin installed for a campaign. Website speed decays quietly as pages and tools pile up, so a short scheduled look beats an emergency months later. Test on a phone, on mobile data, using the templates that carry the most pages rather than the home page.
Should I rebuild the site to make it faster?
Usually not as the first move. Compressing images, removing dead scripts and switching caching on will fix a large share of slow sites without touching the build. Rebuild when the platform or the theme is genuinely the problem, or when a redesign was already on your list. Then put speed in the brief as a requirement, rather than treating it as a repair job afterwards.
Is a perfect score in a speed test worth chasing?
No. The last few points cost far more than they return, and they usually go on details no visitor would ever notice. A green lab score on a machine in ideal conditions also says little about a phone on patchy signal. Use the test to find what is heavy, fix the heavy things, then spend the time you have left on the offer and the copy.