Cutting alert latency from 677 ms to 37 ms

In a tsunami early warning system, the alert itself is the product. Everything else in Padang Rescue, the map, the shelters, the routes, only matters if the warning reaches a phone in time. So when I measured the first version, the number that bothered me most was latency.

The cost of asking again and again

The early build delivered warnings through regular request and response calls. Each one carried the cost of opening a connection, sending headers and waiting for an answer. On a congested mobile network those costs add up, and average delivery time sat at 677.57 ms.

Keeping the line open

I moved hazard warnings onto persistent WebSocket connections. The phone opens one connection and keeps it, and the server pushes a warning down that open line the moment it is issued. There is no handshake to repeat and no polling interval to wait out.

• Average latency dropped to 37.39 ms.
• That is roughly an 18x improvement.
• The server sends one small message per alert instead of answering a stream of requests.

What I would tell myself earlier

Measure before optimising, and measure the thing users actually feel. In an emergency app, that is the time between a warning being issued and a person seeing it.