TLS Record Size Optimization: Balancing Latency and Throughput at the Edge

Last year we were chasing a stubborn 180ms delay on cached HTML from our Singapore edge. Origin was fast, cache hit was confirmed, TCP handshake was clean — but Time to First Byte still looked bad on WebPageTest. It turned out the culprit wasn't the network path at all. It was our perfectly standard, 16KB TLS records holding up that first tiny chunk of HTML until the buffer filled.

Why a Full 16KB TLS Record Kills Time-to-First-Byte

TLS has to encrypt and authenticate data in records, and the spec allows up to 16,384 bytes of plaintext per record plus overhead. That default made sense ten years ago when throughput was the metric everyone optimized for. Fewer records meant fewer header and authentication tag bytes on the wire, and less CPU spent on crypto operations. If you're pushing a 2MB JavaScript bundle or a 4K video segment, you definitely want those big records.

The problem is how that design interacts with small, latency-sensitive responses. When your edge serves a 1.2KB HTML document or the first bytes of an API response, Nginx or OpenSSL will by default wait to coalesce data into a 16KB record before encrypting and sending it. I've seen this exact behavior add 40-80ms on slow-start connections where the congestion window is still small. You're not waiting for the network; you're waiting for your own TLS stack to decide it has enough data to be efficient. It gets even worse with HTTP/2 and HTTP/3 multiplexing, where one stalled record can block other streams.

We first ran into this on a news site migration back in 2019. Their origin sent `Cache-Control` headers correctly and our edge cache was hitting at 94%, but they kept complaining about First Contentful Paint regressing after moving to us. Turning on `ssl_buffer_size` in Nginx was the first lever we tried. Most folks never change it from the default 16k, and many don't realize it even exists. There's a related interaction with certificate validation too — if your handshake is already delayed by slow OCSP checks, buffering just compounds the pain, which is why we pair record tuning with OCSP Stapling for CDN: Eliminating Certificate Validation Delays on every edge we operate.

# Default Nginx behavior - buffers up to 16KB before sending
# This maximizes throughput but hurts latency for small responses

ssl_buffer_size 16k;

# Tuned for lower latency - flush much sooner
ssl_buffer_size 4k;

# What this actually does in BoringSSL/OpenSSL:
# SSL_MODE_RELEASE_BUFFERS will flush when:
# 1. Buffer reaches ssl_buffer_size, OR
# 2. write timer expires (~200ms), OR
# 3. SSL_send_flush() is explicitly called

How Dynamic Record Sizing Fixes It Without Killing Throughput

A static 4KB buffer is a crude fix. It helps TTFB, but you'll pay for it on large file delivery — more records, more AES-GCM operations, and about 1-2% bandwidth overhead from extra record headers and tags. On a 100 Gbps edge, that overhead isn't trivial. That's why we've moved entirely to dynamic record sizing over the last five years. The idea is simple: start small for the first few records to get the initial bytes out fast, then ramp up once the connection proves it needs throughput.

Cloudflare pioneered this approach with their patch for Nginx and it's now baked into BoringSSL and available in OpenSSL 3.x with some custom logic. The algorithm I've had the best results with is straightforward: send the first record at ~1,368 bytes to fit inside a single TCP segment with headers, the next at around 2,736 bytes, double again, then cap at 16KB after about 5-6 records or ~32KB of data. That first 1.3KB record flies out immediately without waiting, so your HTML head and critical CSS aren't stuck behind a timer. I've used this on edges handling both small API calls and large image payloads and it neatly solves both cases without manual tuning per route.

Implementing it doesn't require a custom build anymore if you're on a recent BoringSSL or you use the Nginx dynamic patch. You'll still want to monitor your certificate layer though. Dynamic sizing only helps after the handshake is done, so if your cert rotation is lagging or you're redeploying full chains frequently, you'll still see handshake jitter. We automate all of that separately as described in Certificate Lifecycle Automation: From Issuance to Renewal at CDN Scale — keeping handshakes fast means your record sizing gains actually matter. And if you're debating Wildcard vs SAN Certificates for CDN: Making the Right Choice, remember larger chains from SAN certs mean larger handshakes, which makes that first-record latency even more important to optimize.

// Simplified dynamic record sizing logic (concept from BoringSSL/Cloudflare patch)
size_t get_dynamic_record_size(SSL *ssl) {
    // ssl->num_sent_records tracks records sent on this connection
    // ssl->bytes_sent tracks total application bytes
    if (ssl->bytes_sent < 1368) {
        return 1368;  // Fits in one TCP segment (MSSS ~ 1460 - overhead)
    } else if (ssl->bytes_sent < 4104) { // 1368 + 2736
        return 2736;
    } else if (ssl->bytes_sent < 8200) {
        return 4096;
    } else if (ssl->bytes_sent < 16384) {
        return 8192;
    } else {
        return 16384; // Steady state - maximize throughput
    }
}

// In nginx.conf with the dynamic patch enabled:
ssl_dynamic_record on;
ssl_dynamic_record_threshold 32k; // Switch to 16k after this many bytes
ssl_dynamic_record_timeout 50ms;  // Force flush if no new data

Production Numbers: What Different Record Sizes Actually Cost

We tested this on a production edge cluster in Ashburn that serves a mix of HTML, API, and images — about 60% of responses are under 14KB. We A/B tested four configurations over 14 days, with around 180M requests per variant, all on the same hardware and TLS 1.3 with AES-GCM. Clients were real Chrome and Safari users, not synthetic tests, so we saw real last-mile loss and varied TCP congestion windows. The data lines up closely with what the HTTP Working Group Specifications at https://httpwg.org/specs/ and performance guides on https://web.dev/articles/ suggest about head-of-line blocking and record granularity.

What surprised our team wasn't that dynamic sizing won — we expected it — but how badly a static 16KB setting performed on p75 TTFB for small objects. Users on 4G connections saw a median 35ms TTFB improvement just by switching to dynamic, with no throughput loss on large assets. The static 4KB setting was great for TTFB too, but throughput for 1MB+ assets dropped by about 6-8% due to crypto overhead and our CPU utilization went up nearly 10% on that PoP. That CPU hit alone would have meant adding two more servers per rack.

If you're running an edge today, don't just copy a config value. Measure your response size distribution first. If your p50 response is 2KB, a 16KB static record is almost certainly hurting you. If you push mostly large objects over 500KB, you can be more conservative and ramp faster to 16KB. Below is the summarized result from our Ashburn test — your numbers will vary, but the tradeoff shape is consistent across our other PoPs in Frankfurt and Tokyo.

Putting It Into Practice: Dynamic Sizing on Real Edge Nodes

Here’s the frustrating part — most off-the-shelf TLS stacks don’t give you dynamic record sizing out of the box. Nginx’s ssl_buffer_size is static. Set it to 4k and you’ve improved TTFB by ~30-40ms on a typical 3G link, but you’re leaving throughput on the table for large assets. Set it to 16k and you’re back to buffering 11ms worth of data at 11 Mbps before the first byte hits the wire. You can’t win with a fixed value.

What we run in production is stupidly simple and it works. Start small, then grow. First record is ~1,369 bytes — that’s 1,500 byte MTU minus ~40 bytes IP/TCP, minus 20-30 bytes TLS header/MAC. It fits in a single packet so it gets ACKed immediately. After ~10KB sent, bump to 4,096 bytes. After ~100KB, go full 16,384. For connections that never exceed 10KB — which is 73% of our HTML document requests — we never pay the large-record penalty. For a 2MB image, the overhead of those first few small records is noise: about 0.4% extra framing overhead versus pure 16KB records.

// Simplified dynamic record sizing - Go / BoringSSL-style logic
func nextRecordSize(bytesSent int64, cwnd int) int {
    // Fit first flight into single packet for fast TTFB
    if bytesSent < 10 * 1024 {
        return 1369  // 1 x MSS
    }
    if bytesSent < 100 * 1024 {
        // Ramp phase - adapt to congestion window
        if cwnd < 10 {
            return 2048
        }
        return 4096  // 3 x MSS
    }
    // Steady state - maximize throughput
    return 16384 // max TLS record
}

// On the edge, tie it to TCP_NOTSENT_LOWAT or BBR cwnd
// to avoid buffering more than the network can actually send
setsockopt(fd, IPPROTO_TCP, TCP_NOTSENT_LOWAT, 16384);

Advanced Patterns and Troubleshooting When It Goes Sideways

If you just flip this on and walk away, you’ll miss half the win. The real magic is coupling record size to the congestion controller. With BBR or Cubic, you don’t want to queue a 16KB record when cwnd is only 4 packets — you’ve just created bufferbloat inside your own TLS layer. We set TCP_NOTSENT_LOWAT to ~16KB and check TCP_INFO before framing. If cwnd is tight, we stay at 1.3k even past the 100KB mark. That alone shaved another 12-18ms off p95 TTFB for clients on lossy mobile networks during our last rollout. And it plays nicely with 0-RTT — for resumed connections, you can start at 4k immediately since you already know the path’s capacity.

When it breaks, here’s what to look for. If you see a 5-8% CPU increase after enabling small records, that’s not a bug — it’s AES-GCM and SHA overhead per record. Each record adds ~16 bytes tag + 16 bytes header. At 1,369 bytes, you’re doing 12x more crypto operations than at 16KB. On a Broadwell-era edge core doing ~30k handshakes/core, that can push you from 62% to 68% CPU. The fix isn’t to go back to 16KB, it’s to batch intelligently. Another classic: middleboxes that re-segment records. Some enterprise firewalls will coalesce your beautifully-sized 1.3k records into 16k anyway. You’ll spot this in Wireshark as TCP segment of a reassembled PDU without a corresponding TLS record boundary. If you’re already hardening your handshake, review how this interacts with TLS Fingerprinting Defense: Preventing Client Identification Through Handshake Analysis — record size patterns are fingerprintable too.

Don’t forget the trust layer either. Dynamic sizing changes how often you flush, which can subtly affect session ticket and OCSP stapling delivery timing. We had a case where stapled responses were delayed by one record and triggered soft-fail revocation checks on old Android clients. If you’re modernizing your edge auth, consider Beyond Certificate Pinning: Modern Alternatives for CDN Trust Verification alongside this, and make sure your HSTS Preloading for CDN Domains: Permanent HTTPS Enforcement Guide config isn’t forcing an extra redirect that negates your TTFB win. Measure end-to-end with qlog or ss -ti, not just synthetic curl timings.

Frequently Asked Questions