I have built websites for fourteen years, and I have opened a great many slow ones. The surprising thing is how rarely the cause is exotic. It is almost never a server on fire or a clever bug. It is five ordinary decisions, made one at a time by reasonable people, that add up to a page which takes its time.

None of this is secret, but it is easy to skip when a project is moving and the launch date is fixed. So here is the list I actually work through, along with what I did on my own site, a deliberately small piece of plain HTML that I use as my test bench.

Start by measuring the right thing

Open PageSpeed Insights, paste in your homepage, and look at the mobile tab first. Most of your visitors are on a phone, and a phone on a mobile connection is a far harsher judge than your office laptop.

Ignore the big coloured score for a moment and read three numbers. Largest Contentful Paint is how long the main thing on the page takes to appear. Cumulative Layout Shift is how much the page jumps around while it loads. Interaction to Next Paint is how quickly it responds when someone taps. If those three are healthy, the score takes care of itself. If you see a field data section at the top, that is real visitors on real devices, and it matters more than the lab test below it.

1. Images that were never resized

The most common offender by a distance. Someone uploads a 4000 pixel wide photograph straight from a camera or a stock library, and the page shows it in a box 600 pixels wide. The visitor downloads the whole thing anyway.

The fix is dull and effective. Export images at the size they are actually displayed, use a modern format such as WebP, and let the browser load images lower down the page only when someone scrolls toward them. That alone often takes megabytes off a page.

2. Fonts that arrive late

Typefaces look like a design detail, but each one is a file the browser has to fetch before it can show your text properly. Pulling fonts from a third-party service adds another connection to set up before the download even starts.

On my own site I host the fonts myself. There are two files, and together they weigh about 40 KB. They are preloaded so the browser asks for them straight away, and set to swap, so text is readable immediately instead of staying blank while a font loads. If your design calls for six weights across three families, it is worth asking whether the design truly needs them all.

3. Third-party scripts nobody reviewed

Analytics, tag managers, chat widgets, heatmaps, retargeting pixels. Each one was added for a good reason by someone who may have since moved on, and each one runs on every visit. Together they are frequently the heaviest part of a page, and you do not control how fast they are.

My approach is to make them wait. Google Tag Manager on my site does not load until the visitor first interacts with the page, or six seconds after it finishes loading, whichever comes first. The page paints first and the measurement follows.

There is a trade-off, and I would rather be straight about it. Someone who lands and leaves without moving or scrolling inside those six seconds will not show up in my analytics. I am comfortable with that. You might not be, and that is a legitimate call. The point is to make the choice on purpose instead of letting a tag make it for you.

4. Plugins and page builders doing more than the page needs

A typical WordPress site I am asked to look at has a page builder, a slider, a form plugin, a social feed, an SEO plugin, a cache plugin and something that was installed once to solve a problem nobody remembers. Each of them can load its own stylesheet and scripts on every page, including pages that never use them.

The blog you are reading runs on a theme I wrote myself. It has no jQuery, none of WordPress's emoji or embed scripts, no global styles it does not need, and a single stylesheet. That is not because a custom theme is always the right answer. It is not. I simply wanted to see how fast WordPress can be when nothing is asked of it that it does not need to do.

5. Scripts that hold up the first paint

Even necessary JavaScript does not need to run before the visitor sees anything. On my site the scripts are added only after the first paint, so the first thing anyone gets is the page itself. Animation libraries and interactive extras arrive a moment later, when nobody is waiting on them.

A redesign is not a speed plan

This is the part I most want business owners to hear. A new design does not make a site faster. Left alone, it usually makes it slower, because new designs bring video backgrounds, larger images, more animation and more third-party embeds, and those are more enjoyable to approve than a performance budget.

If you are about to commission a revamp, ask for three things before any mockup is signed off:

  • A target for Largest Contentful Paint on mobile
  • A list of every third-party script that will be on the page
  • A plan for how images will be sized and served

A designer or developer who can answer those clearly is thinking about your visitors. One who cannot is probably thinking about the launch.

Where I would start

If you want a first step without hiring anyone, run your homepage through PageSpeed Insights, open the list of opportunities, and deal with the image and script items first. They are usually the cheapest wins. Then test again on mobile, not desktop.

If you would like a second opinion on your own site, send me the address. I will tell you what I would fix first, in plain language, and if the honest answer is that it is fine and you should leave it alone, I will say that too.