Skip to content
All posts

Speed is decided before the first line of code

A slow site is rarely one bad function. It is a string of early choices, each reasonable alone, that nobody weighed together.

A budget drawn before the layout is the cheapest performance work there is.

Most performance work I am asked to do arrives late. The site is built, the numbers are red, and the request is to make it fast without changing anything. By then the expensive decisions are already in the walls.

Those decisions are small when they are made. A carousel on the home page, because the client liked one. A font family with six weights, because the design used three. A tracking script added in the week before launch. None of them is wrong on its own; together they are the reason the first screen takes four seconds on a phone.

Every addition has to fit inside the budget, or push something else out of it.

So I now treat speed as part of the brief rather than a pass at the end. Before a layout is drawn, the page gets a budget: how much it may weigh, how many requests it may make, what must be visible before anything else loads. Every addition then has to fit inside it or push something out.

It is not a technical trick. It is the same conversation as any other scope conversation, held early enough that saying no to a slider costs nothing — instead of late enough that it costs a rebuild.

In short

  • A slow site is rarely one bad function. It is a sum of small decisions nobody weighed together.
  • Give the page a budget before a layout is drawn: what it may weigh, request, and show first.
  • Saying no to a slider early costs nothing. Saying no to it late costs a rebuild.

Keep reading

Three more pieces from the same desk, on the parts of the work that are easier to get wrong than to explain.