Time to first byte: what to get right first

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. If you only fix one thing about time to first byte this quarter, make it the first item below.

Real-world numbers from actual visitors matter more than a score produced on a fast laptop. Doing this properly once is usually cheaper than doing it approximately three times.

Start here

Slow server response caps how fast the page can ever be. None of that requires a large budget, only a decision and someone to own it. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Then this

Caching at the edge often fixes it outright. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Eventually

Cheap shared hosting shows up here first. In practice this is a scheduling problem more than a technical one. Doing this properly once is usually cheaper than doing it approximately three times.

What this looks like day to day

Speed is a feature people notice only in its absence, and then they leave rather than complain. Three things worth confirming about time to first byte before you move on:

• Someone can say what the current setup is without going to look
• Slow server response caps how fast the page can ever be — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.