Five mistakes teams make with response compression

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. These are the ones we run into repeatedly when we audit response compression.

Performance work is mostly subtraction, which makes it unpopular and effective. Budget a little time for it every quarter and it never becomes a project of its own.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Text compresses dramatically and costs almost nothing to enable
• Modern algorithms beat older ones by a useful margin
• Never checking whether the fix actually worked

Already-compressed formats gain nothing from it. In practice this is a scheduling problem more than a technical one. If two people in the business would answer this differently, that gap is the actual problem.

Where to go from here

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 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

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.