The Eulerian marketing tag fires once per page load
Each call carries a small payload — a few dozen bytes, always under 1 KB
The endpoint's entire job is to absorb a high volume of tiny, independent, fire-and-forget requests
This document explains why enabling HTTP/2 on this specific server delivers no meaningful performance benefit, and why HTTP/1.1 over TLS is the better-matched protocol for the workload.
Eulerian Data Collection servers do not support HTTP/2 as there is no benefit to implement it. See explanations below.
TL;DR
Every headline feature of HTTP/2 — request multiplexing, header-compression amortization (HPACK), stream prioritization, and connection reuse — only pays off when many requests share a single connection. A tag that fires once per page sends exactly one request per connection, so none of those mechanisms ever engages.
Meanwhile the server still pays HTTP/2's fixed costs: binary framing, the connection preface and SETTINGS negotiation, per-connection HPACK encoder/decoder contexts, stream and flow-control state, and a larger security attack surface. For this traffic pattern HTTP/2 is not harmful so much as pointless: you carry the cost and complexity of the protocol's optimizations while being structurally unable to benefit from any of them.
What HTTP/2 was actually designed to optimize
HTTP/2 was built to fix the page-load problem of a browser fetching dozens or hundreds of resources (HTML, CSS, JS, images, fonts) from the same origin. Its mechanisms target that specific situation:
Multiplexing — many concurrent requests over one TCP connection, eliminating the HTTP-layer head-of-line blocking and the "6 connections per host" limit of HTTP/1.1.
HPACK header compression — repeated headers (Cookie, User-Agent, Accept…) are compressed against a per-connection dynamic table that grows as requests reuse the connection.
Stream prioritization — telling the server to send the critical CSS before a footer image.
Connection reuse — one expensive TLS connection amortized across the whole page's request burst.
Server Push — proactively sending assets (now removed from Chrome and effectively dead; not relevant either way).
Notice the common precondition behind all five: plurality of requests on a persistent connection. That precondition is exactly what a once-per-page tracking call does not satisfy.
Why none of those benefits apply to a single call per page
Multiplexing — nothing to multiplex. Multiplexing interleaves concurrent streams. With one request there is one stream and zero concurrency. The feature that justifies HTTP/2's entire design is inert here.
HPACK never warms up. HPACK's large wins come from the dynamic table: the first request seeds it, and every subsequent request on that connection sends headers as tiny table references instead of full strings. With one request per connection, the dynamic table starts empty and is discarded before a second request ever uses it. You only benefit from the static table (a fixed set of common header names/values), which trims some bytes but is a fraction of HPACK's value — and you still pay the CPU and memory cost of maintaining the full encoder/decoder state.
Connection reuse amortized over… one request. The whole economic argument for a rich, long-lived HTTP/2 connection is that its setup cost is spread across many requests. Spread across exactly one request, the amortization never happens. You pay full setup, use it once, tear it down.
Stream prioritization — irrelevant. There is nothing to prioritize against a single stream.
Server Push — dead and unneeded. Chrome disabled it by default in 2022; it was never relevant to a collection endpoint anyway.
What you pay for anyway
Even though the benefits don't engage, the protocol's machinery does:
Connection preface + SETTINGS exchange. An HTTP/2 connection opens with a 24-byte client preface plus a SETTINGS frame in each direction and their acknowledgements. These are fixed per-connection overhead frames that HTTP/1.1 simply doesn't have — and because you never send a second request, that overhead is never amortized.
Binary framing on every message. Every HTTP/2 message is wrapped in frames, each with a 9-byte header (HEADERS, DATA, plus connection-level SETTINGS / WINDOW_UPDATE). For a sub-1 KB payload this per-frame overhead is proportionally non-trivial, where HTTP/1.1 sends a single compact request/response.
Heavier per-connection server state — the cost that actually scales. This is the most consequential point for a high-volume collection server. Each HTTP/2 connection that carries exactly one stream still forces the server to allocate and track:
an HPACK encoder and decoder context (dynamic tables, commonly up to ~4 KB each),
stream state machinery and flow-control accounting (per-stream and per-connection windows),
in some stacks, priority-tree bookkeeping.
Across millions of one-shot connections, that is materially more memory and CPU per request than HTTP/1.1's lean per-connection footprint — spent to support multiplexing that, by definition, never occurs. For a server whose only purpose is to swallow a firehose of independent tiny hits, leaner-per-connection is exactly what you want, and HTTP/1.1 gives it.
Connection-lifecycle friction. HTTP/2 connections are designed to be long-lived because clients expect to reuse them. On a tracking subdomain the reuse rarely comes — the tag fires once and the user navigates away. So you either hold open idle, heavier-state connections waiting for a second request that never arrives, or you tune aggressive idle timeouts and work against the protocol's grain. HTTP/1.1 keep-alive lets you handle the hit and release resources without that tension.
Wire-level reality
It would be overstating the case to claim HTTP/2 bloats the wire. On a single request the picture is roughly a wash:
HTTP/2 adds the connection preface and SETTINGS/ACK/WINDOW_UPDATE frames (on the order of ~80–100 bytes of pure setup) plus 9-byte framing per message.
HTTP/2 saves some header bytes via the HPACK static table, even on a first request.
These roughly cancel. The honest takeaway is therefore not "HTTP/2 is fatter on the wire," but rather: its compression and multiplexing machinery delivers essentially nothing here, while still costing setup frames you never amortize and server-side state that scales with your request volume. The bytes are a sideshow; the wasted machinery and the per-connection state are the real story.
Latency is similar: in practice the client can send the preface, its SETTINGS, and the request together in the first flight after TLS, so HTTP/2 rarely adds a measurable round trip. We should not argue this on latency grounds — the case rests on "no benefit gained, plus avoidable server-side cost and complexity," not on a speed penalty that isn't really there.
Operational and security considerations
Larger attack surface for a publicly exposed endpoint. A collection endpoint is reachable by the entire internet, which makes it a natural DDoS target. HTTP/2's multiplexing is the very feature behind HTTP/2 Rapid Reset (CVE-2023-44487, 2023), which abused rapid stream creation and cancellation to drive record-breaking attacks. The irony is sharp: the one HTTP/2 capability we cannot use for this workload is the one that introduces a class of amplification attacks we'd otherwise be free of. Staying on HTTP/1.1 keeps that surface smaller.
More to configure, tune, and debug. HTTP/2 stacks add flow-control windows, frame-size limits, concurrent-stream caps, and HPACK table sizing to the list of things that must be set correctly and reasoned about during incidents. For a single-request endpoint that gains nothing from any of it, that is added operational risk for zero return.
Where HTTP/2 could have helped — and why it doesn't for us
To be fair and complete, there is one scenario where HTTP/2 can benefit a cross-origin request: connection coalescing. A browser may reuse an existing HTTP/2 connection for a different hostname if that hostname resolves to the same IP and the TLS certificate is valid for both (e.g. a shared *.my-customer.com wildcard or a multi-SAN cert). In that case the tracking request to tracking.my-customer.com could ride the connection already open to www.my-customer.com and skip its own handshake.
This does not apply to us for the ordinary reason that a data-collection subdomain is deliberately separate infrastructure — different server / CDN / IP from the main site — so coalescing won't trigger. It's worth noting only so the recommendation is made with eyes open: iftracking were ever served from the same endpoint and certificate as www, this one HTTP/2 advantage would come into play. As things stand, it doesn't.
Recommendation
For the tracking.my-customer.com collection endpoint, serve over HTTP/1.1 with keep-alive over TLS. It is the right-sized tool: simple, lean per connection, smaller attack surface, and it forfeits no benefit, because every HTTP/2 optimization requires a request plurality this workload structurally never produces.
The same reasoning rules out HTTP/3 for this endpoint as well — it layers even more connection machinery (QUIC) on top, again to optimize multi-request loads we don't have.