Skip to content
Breitloh

Why your website is slow

Nearly every slow site is slow for the same three reasons, and none of them are the ones people guess. It is rarely the images, usually the scripts, and always worse on a phone on mobile data than on the laptop it was signed off on.

Book a callWebsite rebuild
A page that used to assemble itself slowly, loading in a fraction of the time

Where it usually hurts

It was tested on a desk
On a fast laptop on office broadband, everything is fine. On a four year old Android phone on a train, the same page takes eleven seconds to become useful, and that is the visit that decides whether anyone reads it.
The page assembles itself while you watch
Text jumps as fonts load, a banner pushes the article down, and a button moves just as somebody taps it. That is measured now, it counts against you, and it is the thing people describe as the site feeling cheap without knowing why.
Every plugin brought friends
A cookie banner, a chat widget, three analytics tags, a font service, and a slider, each loading its own script. Nobody chose that as a whole, and the total is what a visitor waits for.

What the job covers

  • Measurement on a real mid range phone on a throttled connection, not a score from a laptop
  • Field data from real visitors where it exists, because a lab number and a person's experience often disagree
  • A ranked list of what is actually costing time, with the seconds attached to each item
  • The fixes carried out, largest first, with a before and after you can see rather than take on trust
  • A plain statement of what cannot be fixed without a rebuild, and what a rebuild would be worth

What it has to talk to

Your analytics and tag manager
Usually the biggest single win, and the most political. Tags accumulate because nobody is allowed to remove them, and a list of what each one costs in seconds tends to settle that conversation.
Your cookie and consent banner
Consent tools block rendering by design, and a badly configured one is often the first second of the wait. There is nearly always a version that is both compliant and quick.
Whatever serves your images and fonts
Images the wrong size for the space and fonts loaded from three places are the routine offenders. Both are fixable without touching the design anyone signed off.

A worked approach, not a client

How I would find out why a site is slow

  1. 01

    Measure the thing people actually experience

    Largest contentful paint, interaction latency, and layout shift, on a mid range phone on a throttled connection, on the pages that matter rather than only the home page.

  2. 02

    Attribute the seconds

    Every script, font, and image on the critical path, with what it costs. This is the part that changes minds, because it turns an argument about opinions into a list with numbers beside it.

  3. 03

    Fix in order of size, then re measure

    Biggest first, one change at a time, with the numbers taken again after each. Anything that cannot be fixed without a rebuild is written down as exactly that, along with what it would take.

Questions I get asked about this

The ones that come up on almost every first call. If yours is not here, ask it and you will get a straight answer.

What are Core Web Vitals, and do they affect rankings?

Three measures Google takes from real visitors: how quickly the main content appears, how quickly the page responds to a tap, and how much it moves about while loading. They are a genuine ranking factor, though a modest one. The stronger argument is that people leave slow sites, which affects rankings by a longer route.

Our PageSpeed score is 40. How bad is that?

Bad enough to fix, and less meaningful than it looks. The score is a lab simulation, and it swings between runs. Field data from actual visitors is what Google uses and what tells you whether real people are waiting. I look at both, and I would not chase a number at the expense of the experience.

Can you make our WordPress site faster without rebuilding it?

Usually, and by a worthwhile margin. Removing unused plugins, fixing image sizes, tidying scripts, and caching properly gets most sites into an acceptable state. What that will not do is fix a page builder producing enormous markup, which is a structural problem and the point at which moving off it becomes the cheaper answer.

Is it the images or the code?

Almost always the code. Oversized images are easy to spot and easy to fix, so they are the first thing everyone tries. Scripts are harder to see and cost more, particularly on a phone, where the processor rather than the connection is the limit.

How much faster can we realistically get?

On a typical plugin heavy site, two to four times quicker to first useful content without a rebuild. Rebuilt properly it is a different category of fast, but I would rather quote the honest improvement on what you have than sell the rebuild by implying the fixes will not work.

Will a caching plugin sort it?

It will help with the server's part and do nothing about the browser's, which on modern sites is most of the wait. Caching is worth having and it is not a strategy. If the page ships a megabyte of JavaScript, caching means it arrives from nearer by.

Does hosting make a difference to speed?

To the first byte, yes, and that is a smaller share of the total than people think. Moving a slow site to expensive hosting buys a fraction of a second and leaves the rest untouched. What hosting should cost is worth reviewing on its own merits rather than as a performance fix.

How do we stop it getting slow again?

Decide who is allowed to add a script, and measure after anything is added. Sites do not become slow in one afternoon, they accumulate. A number checked monthly is enough to catch it while it is still a small conversation.

Related

Tell me what you have now

Half an hour on a call, and a straight answer about whether this is the right job and whether I am the right person for it.

Book a callhello@breitloh.com