How to get response compression right
This is cheap to get right at the start and expensive to retrofit. The short answer to response compression is that it is mostly a sequence of small decisions, not one big one.
Performance work is mostly subtraction, which makes it unpopular and effective. It rarely shows up as a line item, which is exactly why it slips.
What it costs to ignore
Text compresses dramatically and costs almost nothing to enable. That sounds obvious written down. It is still the thing most often skipped. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
The steps
- Establish what you have today before changing anything
- Modern algorithms beat older ones by a useful margin
- Already-compressed formats gain nothing from it
- Write down the decision so the next person does not re-litigate it
Already-compressed formats gain nothing from it. The teams that handle this well are rarely the ones with the biggest budgets. Budget a little time for it every quarter and it never becomes a project of its own.
Where to go from here
How to tell if yours is fine
Speed is a feature people notice only in its absence, and then they leave rather than complain. Three things worth confirming about response compression before you move on:
- Someone can say what the current setup is without going to look
- Modern algorithms beat older ones by a useful margin — 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.