Algeria AgencyWeb & software
Why your website is slow — and what it costs you
Site speed is not measured on your desktop, and that is where the whole misunderstanding starts.
Almost every client who tells us "my site is fast" tests it on a desktop, on fibre, with the site already cached because they open it ten times a day. Their visitors arrive on a mid-range phone, on variable 4G, with nothing cached.
The gap between those two experiences is large, and it is never visible from the desk. That is why a slow site is almost always discovered late, usually when someone asks why the advertising has become so expensive.
What follows is what we find most often on opening the bonnet, in the order it costs money. Every number quoted here comes from a named public source, printed under the chart it belongs to — we do not publish an in-house measurement dressed up as a statistic.
It is written to be applied without us: the checks run from your phone, and the first two fixes need no rebuild.
Where the three-second number comes from
You have heard that a visitor leaves after three seconds. The number is real, it has a source, and it is worth knowing which one: Google analysed more than 900,000 mobile advertising landing pages and published the result in 2016. As load time goes from one second to three, the probability of a visitor bouncing rises by 32%. At five seconds it rises by 90%.
Two honest caveats before going further. First, these are bounce probabilities, not a bounce rate: the study does not say 90% of people leave at five seconds, it says the risk of them leaving is close to doubled. Second, the study is ten years old and looked at advertising pages, which are a special case — the visitor did not choose to be there.
It remains the most solid measurement the field has, and its general shape has never been contradicted since: the decay is not linear. Going from one second to two costs little; going from three to five costs a lot. That is why an already-slow site degrades quickly when a feature is added to it, and a fast site absorbs the same addition without anyone noticing.
There is a reason for that curve, and it is better understood than memorised. A visitor’s wait is not measured against zero, it is measured against what they expected: at one second they have had no time to form an expectation; at three they have one and it is disappointed; at five they have had time to wonder whether they are in the wrong place. The threshold does not measure patience, it measures the moment doubt becomes conscious.
Think with Google, 2016 — analysis of over 900,000 mobile pages
A median page now weighs nearly three times what it did
The HTTP Archive crawls millions of sites and publishes what it finds every year. In the July 2025 crawl, the median mobile home page weighs 2,362 kilobytes. Ten years earlier, in July 2015, the same measurement gave 845 kilobytes.
Median, not average: half the pages on the web weigh more than that. This is not a figure dragged upward by a few monstrous sites, it is the middle of the pack, and your site is probably in it.
What makes the number useful is that it did not grow because pages became richer in content. The text on a small-business home page has not tripled in ten years. What tripled is everything loaded around the text, and almost none of it was a deliberate decision by the site owner.
That accumulation has a recognisable shape: it is made of individually reasonable additions. An extra typeface for one heading, a measurement tool installed by a previous supplier, a banner added for a promotion that ended two years ago, a reviews module loading a script on every page to display five stars. None of those decisions is bad on its own, and that is exactly why nobody revisits them: there is no moment in the life of a website when somebody is responsible for removing things.
HTTP Archive, Web Almanac 2025 — global July crawls
What those two megabytes are made of
The same crawl breaks the median page down. Images account for 1,058 kilobytes, JavaScript for 697, and everything else — HTML, stylesheets, fonts, video, data — shares the remaining 607.
That split explains why the order of the fixes is not a matter of taste. Images alone outweigh JavaScript and everything else combined in many cases, and they are also the ones that can be fixed without touching the code, without a rebuild, and with no risk of breaking anything.
It also explains why so many optimisation projects fail. You start with the JavaScript because that is where the interesting technical work is, spend two weeks on it, win two hundred kilobytes, and the page stays slow because the cover photo still weighs four megabytes.
One nuance the chart does not show: these categories do not cost at the same moment. Images mainly delay the instant the page looks complete; JavaScript delays the instant it becomes usable — a button can be visible and do nothing for two seconds. A visitor who taps with no effect does not conclude the site is slow, they conclude it is broken, and that is not a thought people come back from.
- Images1 058KB
- JavaScript697KB
- Everything else607KB
HTTP Archive, Web Almanac 2025 — global July crawls
The home page is not the worst case
Almost every optimisation we see was done on the home page, because that is the one the owner looks at. But it is not the page that receives the most visitors arriving from a search, and it is not the one with the worst problems either.
On inner pages — a product listing, an article, a service page — the HTTP Archive measures fewer images but more JavaScript than on the home page. Total weight falls, while the share that has to be executed by the phone’s processor rises.
That distinction matters, because the two do not cost the same thing in the same place. A megabyte of images costs bandwidth, which is time and data the visitor pays for. A megabyte of JavaScript costs bandwidth and then computation, and on a low-end phone the computation is often the longer of the two.
The consequence for your priorities is direct. If most of your visitors arriving from a search land on inner pages — which becomes true as soon as the site has content — then optimising the home page improves the one page fewest people see first. Open your statistics, look at which pages receive the most entries, and fix those. That list almost never resembles what you imagine before reading it.
| Page type | Images | JavaScript |
|---|---|---|
| Home page | 1,058 KB | 697 KB |
| Inner page | 442 KB | 719 KB |
HTTP Archive, Web Almanac 2025 — global July crawls
Why your test from the office lies
Three things make your own visit unrepresentative, and they compound. Your browser already holds the site’s images, fonts and scripts in cache, so it downloads almost none of them. Your connection is fixed and stable. And your computer runs JavaScript several times faster than a thirty-thousand-dinar phone.
The result is a site that opens instantly for the one person who does not need it to open quickly. Nobody is lying: the site owner is sincerely describing what they see.
It is also why the problem is nearly always reported by someone outside — a client on the phone, a salesperson on the road, a friend trying to place an order. Those are the only people around you who see the site under real conditions.
There is a fourth distortion, subtler and more stubborn: you know where to click. You do not read the page, you cross it toward a known destination, which makes you insensitive to the intermediate waits your visitor endures while searching. A site its owner finds fast is very often a site they stopped exploring long ago.
The Algerian ground truth: your visitor is on a phone
This is not an impression. In ARPCE’s internet market observatory for the second quarter of 2025, out of 59.10 million internet subscriptions in Algeria, 88.71% are mobile subscriptions and 11.29% are fixed.
In other words, roughly nine accesses in ten come over a mobile network. Designing and testing for the desktop means optimising for a tenth of your audience — and not the tenth that is hardest to convince, since it is usually the tenth that already knows you.
To which add something the percentage does not say: on mobile, data is not merely slow, it is paid for. A visitor who downloads eight megabytes to read three paragraphs is spending their credit on your code. They will never put it that way, but they will not come back.
A last effect appears on no dashboard: variability. A mobile connection is not merely slower than fibre, it is irregular — it changes with the hour, the place, the number of people on the same mast. A light page crosses that irregularity without the visitor noticing; a heavy page turns it into visible waiting, rarely the same twice, which makes the problem hard to reproduce for whoever tries to diagnose it.
- Mobile subscriptions88.71%
- Fixed subscriptions11.29%
ARPCE, internet market observatory, second quarter of 2025
Images, and why they come first
A photo taken on a phone and uploaded as-is weighs several megabytes and is often four thousand pixels wide. It is then displayed in a six-hundred-pixel slot. The browser downloads the whole file and throws most of it away on screen.
Resized to the dimensions actually displayed and converted to a modern format, the same image weighs a few tens of kilobytes and looks, to anyone, identical. This is not a quality-for-speed trade: it is a properly prepared file against one that was not.
Three mistakes recur without fail. The first is the home page carousel that loads all six of its images while one is visible. The second is the logo saved as a high-resolution PNG when it was vector to begin with. The third is the decorative background image, invisible on mobile because the layout hides it, and downloaded anyway.
The durable fix is not reprocessing the existing images once: it is making sure the next one does not create the problem. As long as whoever publishes uploads from their phone into a field that accepts anything, the weight returns within months. Automatic processing at upload is what separates a site that was fixed from a site that will stay fixed.
Third-party scripts, or the cost of what nobody removed
A chat widget, an advertising pixel, a measurement tool, a consent banner, a font loaded from another domain, a reviews module, an interactive map. Each was added one day for a good reason, each looks harmless, and nobody ever removes them because nobody knows which ones are still doing anything.
The cost is not only their weight. A third-party script is hosted elsewhere: the browser has to resolve an extra domain name, open a connection, negotiate encryption, and then wait. On a mobile network where every round trip costs time, it is that latency that hurts, not the kilobytes.
The rule we apply in an audit is blunt and works well: any script whose purpose nobody in the business can explain in one sentence gets removed. If something breaks, it goes back — which rarely happens. There is almost always at least one, and often three.
That rule has a side effect we did not anticipate when we wrote it: it reveals who is responsible for what. A script nobody claims is nearly always the residue of a previous supplier or a forgotten campaign, and the conversation it starts — “who still has access to that account?” — is often worth more than the kilobytes recovered.
Hosting, distance, and what it adds
A cheap shared server, geographically distant, adds delay to every request before the first byte of content even leaves. That delay shows up on no image and is fixed by no plugin.
It is rarely the main problem, which is why it comes last in this list: changing host while a page loads eight megabytes of images produces no measurable effect. But it is the one item that penalises every page at once, including the clean ones.
So the right moment to deal with it is precise: once the images are handled, the pointless scripts removed, and the site is still slow. Only at that point does distance become the dominant share and the move justify itself.
One sign tells you without instruments: if every page, including the lightest, takes the same time before anything at all appears, that constant delay is the server’s response time. It does not depend on the content — which is why it is identical everywhere, and also why no page optimisation will reduce it.
Measuring honestly: the protocol
Take a real phone, not an emulator. Turn off Wi-Fi and switch to mobile data. Open a private browsing window, so you do not benefit from the cache. Do it at a busy hour, not at six in the morning when the network is empty.
Then supplement it with an online tool set to simulate a modest device and network, never a desktop connection. The aim is not to score well: it is to see the page as someone discovering your business for the first time sees it.
Write the result down somewhere before changing anything. Without a starting measurement you have no way of knowing whether your work helped, and experience shows memory is very forgiving toward fixes one has just made oneself.
Measure three times rather than once, a few minutes apart, and keep the worst. A mobile connection varies enough that a single reading is an anecdote, and keeping the best of three is precisely how people convince themselves a problem is solved when it is not.
Where to start, and what not to do
In order: images, then third-party scripts whose usefulness cannot be defended, then fonts, then hosting. That order follows the ratio of gain to effort, and it holds on the large majority of sites we open.
Change one thing at a time and re-measure between each. Three simultaneous changes leave you with a faster page and no idea what worked, which condemns you to redo everything at the next slowdown.
And do not start with a rebuild. A rebuild resets a problem whose cause you have not identified: the new site will be fast on launch day, then return to the same weight within eighteen months, because nothing about the way you publish will have changed. Fix first, rebuild afterwards if the need survives.
Finally, set a limit and write it down: a maximum weight per page that nobody may exceed without raising it. It is the only measure on this list that acts on the future rather than the past, it costs nothing, and it turns speed into a publishing constraint instead of a project restarted every two years.
What we do, if you would rather not do it yourself
We start by measuring, before touching anything: from a real phone, on mobile data, at the hours your visitors actually arrive. That starting measurement is written down and handed to you, because without it nobody — you or us — will be able to say afterwards whether the work helped.
We then give you the ordered list of what costs time on your site, with the expected gain from each fix and the effort it takes. You decide how far to go. It often turns out the first two lines are enough, and we say so, including when that shrinks the work you were about to give us.
We then handle what you chose: the images and automatic processing at upload, removing the scripts nobody claims any more, the fonts, and the page weight limit to hold to afterwards. We re-measure between each change rather than at the end, so the gain is attributable to a cause.
And we tell you when the problem is not ours to fix. A site that is slow because the server’s line is saturated is not corrected by page optimisation, and selling you three weeks of work in that case would be selling you time. That is the kind of answer the free audit exists to produce before any commitment.
Frequently asked questions
Does the site need rebuilding?
Rarely. Images and pointless scripts explain most of the cases we measure, and neither needs a rebuild. A rebuild started before the cause is known usually reproduces the same problem within a year and a half.
What load time should we aim for?
Under three seconds on a mid-range phone over 4G. The exact figure matters less than the conditions it is measured in: three seconds at the office on fibre means nothing.
Are online tool scores reliable?
As an indicator, yes; as a target, no. A site can post a good score and stay slow for a real visitor, and the reverse happens too. The test from a real phone on mobile data stays the arbiter.
Is changing host enough?
Rarely on its own. It helps once everything else is clean, and does nothing while a page loads eight megabytes of images. It is the last step on the list, not the first.
The Google study is from 2016 — does it still hold?
Its order of magnitude does, and its shape above all: decay accelerates with waiting time. Pages have grown a great deal since, which makes the problem more common rather than less.
How long does a fix like this take?
Handling the images and stripping pointless scripts generally takes a few days on a small-business site. It is the audit that takes time, because you have to measure before, between and after.
Where we come in
Opening your own site on a phone, on mobile data and in private browsing, at the hour your customers do, is the only measurement that counts. It is free.
- We measure before touching anything, under the same conditions you did.
- We hand back the list ordered by expected gain, not by technical difficulty.
- We process images on upload, so it holds without you.
When the slowness comes from the server’s line or from your host, we say so and we do not bill for an optimisation that would change nothing.
Read next
A website does not break down, it goes out of date
Almost every website failure is silent: nothing stops, nothing alerts, and nobody notices before a customer does.The decision queue: what the project is waiting on at your end, and what each wait costs in weeks
A project at this level almost never waits on code. It waits on a decision, a piece of data, or a photograph nobody has taken yet.Website, app or custom software: which one, and in what order
Three very different things share the name "IT project". Choosing the wrong one costs more than building the right one badly.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.