Why your website feels slow — and the five fixes that actually work

4 min read
Why your website feels slow — and the five fixes that actually work

Most sites that feel slow are not slow everywhere. They are slow in one or two specific places, and those places are almost always the same ones. This is the order we work through them, and roughly what each one is worth.

A visitor decides whether your site is fast in about a second and a half, and they decide it on the first screen — not on the page weight in your build report. That gap between what a tool measures and what a person feels is where most performance work goes wrong. You can shave four hundred kilobytes off a page and change nothing anyone notices, or move one image tag and change everything.

What “slow” actually means

Three things carry almost all of the perceived delay: how long the page stays blank, how long the biggest thing on the first screen takes to paint, and whether the layout jumps around while it settles. Everything else is secondary until those three are handled.

  • Blank time — the server and the render-blocking files in the head
  • First big paint — usually a hero image or a background
  • Layout shift — images and fonts arriving without reserved space
  • Input delay — a script blocking the main thread while someone taps

Performance work is not about making everything faster. It is about making the first screen honest.

A blockquote in the editor renders as this pull quote — no extra markup needed

Fix 1 — stop shipping images at full size

This is the single largest win on nearly every site we are handed, and it is usually the cheapest. A 2400-pixel photograph delivered to a 390-pixel phone is not a small waste; it is most of the page. Modern formats and a correct srcset together typically remove somewhere between half and four fifths of the bytes on a content page.

What to check first

Open the network panel, sort by size, and look at the top five rows. If four of them are images, you have your afternoon planned. If none of them are, move on to the next section rather than optimising something that was never the problem.

Fix 2 — cut the scripts you forgot about

Analytics, a chat widget, two tag managers, a heat-map tool nobody has opened since the redesign, and a font loader. Each was added for a reason and each reason expired. Third-party scripts are the only part of a page you pay for continuously without owning.

Key takeaways

  • Audit third-party tags quarterly, not at redesign time
  • Anything below the fold can almost always be deferred
  • One removed widget usually beats a week of code splitting

Fix 3 — cache at the edge

If your pages are the same for every visitor, they should not be rebuilt for every visitor. Edge caching moves the response closer to the person asking for it and removes the server from the critical path entirely for repeat views.

FixTypical effortTypical payoff
Image sizingHalf a dayLarge
Third-party auditAn hourLarge
Edge cachingA dayMedium
Font loadingAn hourSmall but visible

Fix 4 — load fonts on purpose

Fonts are quiet. They rarely show up as the biggest file, but they block text from painting and they cause the jump that makes a page feel unfinished. Subset them, preload the one face that appears in the first screen, and give the rest an honest fallback.

Fix 5 — measure on a real phone

A desktop with a fibre connection will tell you the site is fine. It is not lying; it is answering a different question. Test on a mid-range Android over a throttled connection and the list of what matters reorders itself immediately.


Where to start on Monday

Take the largest image on your busiest page and fix that one image properly — correct format, correct dimensions, reserved space. Measure before and after on a phone. That single change is usually worth more than the rest of the list combined, and it tells you whether the rest of the list is worth doing at all.

Share

Have a project in mind?

Tell us what you are building and we will come back with a plan, a timeline and a number.

Get a Free Quote