TLS session resumption lets a browser and server skip most of the full handshake on a repeat connection, by reusing previously negotiated session parameters instead of starting from scratch. This is why loading a second page on the same site, shortly after the first, generally connects faster.
How it works, in short
The server issues a session identifier or ticket during the first handshake. On reconnect within the session's lifetime, the client presents that ticket, and both sides can resume the previous session's cryptographic state rather than renegotiating everything — cutting out the more expensive parts of a full handshake.
Why it matters for real-world performance
For any site with more than a single-page visit pattern — which is most sites — session resumption meaningfully reduces the cumulative handshake cost of HTTPS across a visit. It's typically enabled automatically by modern web servers and doesn't require manual configuration, though it's worth confirming it's active if you're doing detailed TLS performance tuning.
The two specific mechanisms browsers use to resume a session
Session IDs have the server remember session state and match it against an ID the client presents on reconnect; session tickets instead have the server hand the client an encrypted blob containing the session state, which the client presents back — avoiding the need for the server to store anything per-client, a design that scales better across large, load-balanced server fleets.
Why this matters more on a content-heavy site than a single-page one
A site loading many separate resources across multiple requests, images, scripts, fonts, benefits proportionally more from session resumption than a simple, single-request page load — the cumulative handshake savings across many resumed connections within one visit add up meaningfully for a typical, image-heavy modern webpage.
How long a resumable session typically stays valid
Session resumption windows are configurable server-side but commonly range from a few hours to a day or so — long enough to benefit a typical browsing session's multiple page loads, but short enough to limit how long any single session's cryptographic state remains reusable if it were ever somehow compromised.
Why session tickets scale better than session IDs for large server fleets
Session IDs require the server to remember state for every active session, which becomes a real memory and coordination burden across a large, load-balanced fleet of servers. Session tickets instead have the server hand the client an encrypted blob containing the session state, letting any server in the fleet resume the session without needing shared session storage.
What happens to resumption when a visitor moves between different servers behind a load balancer
If session tickets are used with a shared encryption key across the entire server fleet, any server can successfully resume a session regardless of which specific server originally established it — a meaningful architectural consideration for anyone running TLS termination across multiple load-balanced servers rather than a single machine.
Why this quietly matters more than most visitors ever realize
Session resumption is one of those optimizations that works so reliably in the background that most visitors never notice it's happening at all — it's simply part of why a well-configured HTTPS site doesn't feel meaningfully slower than an equivalent HTTP one in everyday browsing.
What happens to session state when a server restarts or is redeployed
A server restart or fresh deployment typically clears any in-memory session state (for session-ID-based resumption) or invalidates the encryption key used for session tickets, meaning visitors need a fresh, full handshake immediately afterward — a normal, expected, and typically imperceptible reset rather than any kind of error.
A closing thought
A quick closing thought: this is a good example of an optimization working so reliably in the background that most visitors never notice it's happening — quietly making the modern HTTPS web feel faster than it otherwise would.