Before you invest in time to first byte

We end up explaining this on discovery calls often enough that it deserved writing down. Before you spend anything on time to first byte, it is worth confirming a few things are already true.

Performance work is mostly subtraction, which makes it unpopular and effective. The version that survives contact with a real deadline is the simple one.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Slow server response caps how fast the page can ever be
• You have a way to tell whether it worked

Common failure modes

Caching at the edge often fixes it outright. In practice this is a scheduling problem more than a technical one. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Cheap shared hosting shows up here first. The cost of getting this wrong is rarely visible on the day it happens. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

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
• Caching at the edge often fixes it outright — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.