Skip to content
Scaleqode

InsightsWebsites

Why your website is slow, and what it costs

Slow sites lose people who never appear in any report. The causes are few, well understood, and mostly cheap to fix.

5 min read

A slow website does not announce itself. Nobody writes in to say the page took nine seconds. They leave, and they are counted as a visit that did not convert — indistinguishable from someone who simply was not interested.

That is what makes it worth checking rather than assuming. The causes are few and mostly cheap.

Measure before you spend

Run the page through Google's PageSpeed Insights and look at the mobile score, not the desktop one. Desktop is nearly always fine and nearly always irrelevant — most visitors are on a phone, often on mobile data, often on a device several years old.

Test the pages that matter: the homepage, the service page you want to rank, and whatever your ads point at. Not every page.

Cause one: images

This is the first cause by a wide margin, and it is almost always the whole problem on a small business site.

A photo straight from a phone camera is four or five megabytes. Displayed in a space a few hundred pixels wide, it still downloads at full size. Ten of those on a page is forty megabytes for something that should weigh under one.

Cheap to fix. Resize to what is actually displayed, convert to a modern format, and load images below the fold only when they are scrolled to. Usually a few hours of work, and it often fixes the entire problem.

Cause two: too many scripts

Analytics, a chat widget, a heatmap tool, two pixels, a popup builder, a review widget. Each was added for a reason and none were removed.

Every one is a file to fetch and code to run before the page settles. Marketing tools are the usual offenders because they are added by people who do not see the cost.

Cheap to fix, politically awkward. List everything loading and ask what each is for. Anything nobody has looked at in three months goes.

The fastest script is the one you removed. Every other improvement is a negotiation.

Cause three: cheap hosting

Shared hosting means hundreds of sites on one machine. When one gets busy, yours slows down, and there is nothing you can do from your end.

Moderately cheap. Better hosting is a few hundred rupees a month. Worth doing if the server response time is consistently poor while the page itself is light.

Cause four: how it is built

How it is built — page builders that generate enormous amounts of markup. A theme with twenty features where you use three. A site fetching data on every request that could have been prepared once.

Not cheap. This is the one that sometimes justifies a rebuild — but it is the least common cause, and it gets blamed constantly by people quoting for rebuilds. Rule out the first three before believing it.

Two ways the fix goes wrong

Lazy-loading everything. Loading images only when they are scrolled to is right for the ones below the fold. Applied to the large image at the top of the page, it makes the page feel slower, because the thing the visitor is waiting to see is the thing being held back. The first image on screen should load first.

Trusting one test run. PageSpeed Insights shows two kinds of number. The lab score is one simulated visit and it moves by several points between runs. The field data, when it appears, comes from real visitors over the previous month. Fix against the field data where you have it, and run the lab test three times before believing a change helped.

If it used to be fast

A site that was quick at launch and is slow now has not decayed. Something was added. Plugins installed and never removed, a new tracking script, a slider, a batch of photos uploaded without resizing, an update that changed how pages are built.

Ask who touched the site in the last few months and what they changed. If anyone kept a record, it is usually in the first thing they name. Remove the most recent addition, test again, and repeat. It is dull, and it finds the cause faster than any tool, because the cause is a change rather than a flaw.

If nobody can say what changed, that is its own finding: the site has no owner. Slowness will come back after every fix until somebody does.

When not to bother

If the site is a brochure that gets a few visits a day, and enquiries come from referrals who were going to contact you anyway, a mobile score in the sixties is not your problem. The hours are better spent on what the page says. Speed work pays when there is traffic to lose, and most of all when you are paying for it through ads.

What slow actually costs

Beyond visitors leaving, Google uses page experience as a ranking signal — modest compared to relevance, but real, and it applies to every page at once.

The larger cost is invisible: the people who left before seeing anything were often the most impatient, which frequently means the most ready to buy.

What good looks like

Under 2.5 seconds to the main content on mobile, on a normal connection. Under 4 is tolerable. Above 5 is losing you people every day.

Before you pay for a rebuild

Get the mobile score, then ask whoever quotes to say which of the four causes applies and what they will do about it. A quote that answers "it needs rebuilding" without naming the cause has not looked.

Three of the four are hours of work, not weeks. A rebuild is sometimes right — but speed alone rarely makes it so.

If you want the numbers before the conversation, the free website analyzer pulls Google's mobile figures for any address, along with what the site is built on and how many scripts it loads. Take that to whoever is quoting.

  • performance
  • websites
  • mobile

Written by

Abhishek Chaubey builds the websites, software and automation Scaleqode delivers, and made ScalePDF, Scaleqode's free PDF editor.

Read next

More on the same problems.

All insights

Start with the problem, not the service.

The first conversation is about understanding what isn’t working. Sometimes the answer is smaller than expected, and occasionally it isn’t software at all.