HTTP/2 setup didn't speed up the site: where delivery speed is lost
HTTP/2 enabled in the configuration does not yet mean the page will load faster.
The protocol provides multiplexing — dozens of resources travel over a single connection — but if there is a proxy or load balancer at the edge that terminates encryption and goes to the backend over a separate channel, all the benefit remains on paper.
Externally everything is configured, yet slow page delivery is explained by a completely different part of the path.
First, look at the time to first byte from the application. Multiplexing does not help when the response takes long to generate: streams are already open, but there is nothing to send.
Alongside it, request queue blocking is usually present — the concurrent stream limit has been exhausted, and some requests queue on the server instead of proceeding in parallel.
The second layer is connection reuse. If a proxy breaks long-lived connections or rebuilds headers without compression, the client brings the channel up again: handshake, encryption negotiation, waiting again.
Extra connections to the server bring back the same stop-and-go pattern that the previous protocol version was meant to eliminate.
The third layer is the edge itself: a bottleneck at the edge shows up as a flat ceiling on the number of concurrent streams and growing latency under load.
Tweaking flags does not help here — you need to analyze the chain: where the connection is terminated, what happens to request priorities, where the cache is located. Next we show how this is found and what changes in the configuration.
What HTTP/2 setup provides: page delivery without a request queue
HTTP/2 setup changes the very scheme of page loading: instead of several parallel connections per domain, the browser keeps one and multiplexes streams within it.
The request queue stops being a bottleneck — resources are delivered simultaneously rather than in batches of six, and page delivery time drops due to eliminated idle time, not due to channel growth.
Header compression removes the second hidden cost: repeated cookies, user-agent, and security headers are transmitted as references to the connection table, not as full text for each of a hundred resources.
Resource prioritization assigns weight to requests — render-blocking styles and scripts go first, images below the fold give way to them.
The standard is described in IETF, and server behavior is also specified there: without explicit weights, the client guesses on its own, and an image often overtakes CSS.
After enabling, it is worth watching two values: page delivery time under real load and the share of repeated connections — if it grows, keep-alive is breaking somewhere or an intermediate proxy is interfering.
Configuration is not reduced to a checkbox in the config: you need concurrent stream limits, window sizes, reasonable idle timeouts, as well as a review of old techniques — domain sharding and file bundling only hurt with multiplexing.
A correct configuration provides predictable delivery under peak load: the page does not degrade in steps when dozens of clients compete for connections. Hence the breakdown of how this is tested and locked down in the infrastructure.
Comparison of approaches: HTTP/2, HTTP/3, and a hybrid delivery scheme
Choosing a protocol version is not “enable the new one and see,” but a question of compatibility with the real client fleet.
HTTP/2 over a secure channel provides request multiplexing and header compression, but all streams go through a single TCP channel: packet loss stops the loading of the entire page.
HTTP/3 and QUIC move stream control into the transport — on mobile networks with loss, additional loading is noticeably faster.
A hybrid delivery scheme removes the risk of a sudden transition: the transport is advertised to the client, and it chooses the supported option itself, while older browsers and corporate proxies continue to work over HTTP/2.
| Option | When it fits | Limitations |
|---|---|---|
| HTTP/2 over a secure channel | Heterogeneous client fleet, bottleneck is backend response | Single TCP channel: packet loss slows all streams |
| Hybrid delivery scheme | Most projects: new transport is primary, working one is backup | Requires load balancer control and metrics from both transports |
| Full transition to HTTP/3 and QUIC | High share of mobile traffic and networks with loss | Some corporate networks block UDP — cannot do it without an explicit rollback |
| Current HTTP/1.1 | Internal services with a small number of parallel requests | No multiplexing, ceiling on the number of connections |
The rollback plan for the scheme is cheaper than it seems: protocol negotiation with the client leaves the choice to it, so reverting the transport advertisement is a single configuration change, and already established connections are not broken.
We test the option on a copy of production traffic and record at which loss profile the gain disappears.
Work order: from connection audit to handover of procedures
The work order is structured so that changes at the edge can be measured and rolled back, rather than checked by the feeling that “it got faster.” Each step ends with an artifact — a measurement, diagram, configuration, or procedure by which the result is verified regardless of who performed the work.
Seven steps
- Connection audit — we determine which protocol versions are negotiated with real clients, where encryption terminates, and which intermediate nodes interfere with multiplexing.
- Latency measurements — we record the baseline: connection establishment time, number of network round trips to the first response, share of requests over the new protocol.
- Traffic path diagram — the path of a request from client to application: load balancer, reverse proxy, delivery network, cache. Without it, configuration is done blindly.
- Edge configuration — we enable the protocol at the ingress, adjust stream priorities, concurrent request limits, and timeouts; the configuration is versioned.
- Testing on a copy of traffic — we mirror the stream and run load scenarios, comparing with the baseline: negotiation errors are visible before release.
- Release and monitoring — we enable it on a share of traffic, monitor the share of successful connections and response time; rollback is a single configuration change.
- Handover of procedures — the diagram, configurations in the version control system, diagnostic checklist, and rollback order remain with your team.
Before-and-after measurements are handed over to the customer: they show exactly what the transition delivered and whether it makes sense to move to the third version of the protocol.
Handover package: configurations, diagrams, and rollback procedure
After the work, the customer is left not with a report, but with a working package: the files that production runs on and the documents by which a support engineer can repeat or roll back any change.
We hand it over in a repository with edit history, not as a set of attachments in a chat, and go through each item together with your team.
- Connection map: which domains and subdomains go through which node, where encryption terminates, for which clients the new protocol is enabled, and for which the previous one is deliberately left in place.
- Server and reverse proxy configurations: working files with comments, extracted parameters for stream prioritization, timeouts, and buffer sizes — marked with the traffic profile they were tuned for.
- Balancing diagram: how load is distributed between nodes, how their availability is checked, what happens if one of them fails, and how quickly traffic moves to the backup.
- Caching rules: what the edge serves, what the client serves, separate policies for static assets and for API, so that delivery does not conflict with the new protocol.
- Rollback procedure: by which metric we consider a change harmful, who makes the decision, which command returns the previous profile, and how long it actually takes.
- Support instructions: typical failures, what to look at in metrics, order of actions, and escalation points.
- Set of checks and before/after measurements: the script confirms that the connection is established with the required protocol and response time has not degraded.
Case study: catalog delivery time decreased threefold
Furniture catalog — several hundred thousand items, and a category page is assembled from dozens of requests to static assets, fonts, and data. In normal mode, delivery took 2.4 s, and during a sale, when traffic grew sixfold, up to 9 s.
Up to seven percent of requests ended with a gateway error: the connection pool at the edge was exhausted, and the request queue did not reach the application.
What was changed at the edge
We enabled HTTP/2: requests for a single page go over a single connection, header compression removes repeated cookies and metadata, and priorities give bandwidth to critical resources.
For the mobile segment, we added HTTP/3 over QUIC — packet loss no longer slows the remaining streams, and returning to a session does not require full renegotiation of the encrypted channel.
In parallel, we configured the connection pool to the application and keep-alive so that the connection is reused rather than recreated for every request.
What was achieved
Catalog delivery time under peak load is 0.8 s, three times lower. The share of gateway errors dropped to 0.1%, and a whole class of failures disappeared: the page no longer depended on how many connections the browser keeps per domain.
The bottleneck shifted from transport to card rendering — that is already a separate task with a different time budget.
When switching to HTTP/3 pays off and when it does not
The difference between HTTP/3 and HTTP/2 is in the transport, not in the headers.
The second works over TCP, where a single packet loss stops delivery of all parallel requests until the window is restored, while the third runs over QUIC: streams are independent of each other, and the handshake and encrypted channel establishment are combined. Hence the rule — the worse the channel, the more noticeable the gain.
On mobile networks and long-distance routes, 2–5% loss and extra round trips add up to seconds of waiting.
A shorter handshake and the absence of queue blocking reduce time to first byte and the 95th percentile of loading, whereas on a stable channel within a single city the difference becomes noise, and HTTP/2 setup gives the same result with lower complexity.
Client-side support is heterogeneous: current browsers support it, while embedded application components, old libraries, and corporate proxies often do not, and some traffic filters block UDP entirely.
Therefore HTTP/2 remains the base layer, while HTTP/3 is enabled as an add-on and rolls back automatically on failure.
We check infrastructure readiness before enabling: the load balancer and firewall pass UDP, Alt-Svc is served correctly, and metrics are taken by percentiles, not by average.
Cloudflare and other delivery networks cache the response the same way for both versions — acceleration occurs only on the path to the client, not in preparing the page.
Bottom line: a public site with a mobile audience and distributed geography benefits from HTTP/3 by default with automatic rollback to HTTP/2. For services within a single data center and traffic over a stable channel, the gain is lost in intermediate nodes and cache.
Technical doubts before changing the delivery protocol
Before changing the delivery protocol, the same five questions are asked — the answers determine whether the transition goes smoothly or turns into a night of incident analysis.
Will load balancing break?
The load balancer must operate at the application layer and negotiate the protocol — otherwise the connection will fall back to HTTP/1.1. Multiplexing reduces the number of parallel sessions, so health checks and per-node limits are reconfigured.
How does this affect caching?
Cache rules and validation headers do not change — the environment changes: the CDN and intermediate nodes must support the new protocol, and combining requests to a domain complicates cache separation.
What about intermediate proxies?
Corporate proxies and traffic inspection systems often drop the connection during negotiation. They are tested on a staging environment, while in production an automatic fallback to HTTP/1.1 is left in place.
Can it be rolled out in stages?
Yes. The protocol is enabled on a separate node or a share of traffic, delivery time is compared, and only then is coverage expanded. Rollback is switching the setting on the node, without rebuilding the application.
Will old clients stop working?
No. The version is negotiated during connection establishment, and a client without support receives HTTP/1.1. There is one condition — a valid certificate and the same set of resources on both branches.
Let's discuss the task: send us your traffic delivery diagram
To make the conversation substantive rather than about wishes, we start with the current traffic delivery picture: what stands in front of the application, where encryption terminates, which domains and subdomains are served.
From this data it is already clear where the bottleneck is — in connection negotiation, compression, static asset caching, or routing between services — and what prevents moving to HTTP/2 and HTTP/3. Send what you have at hand — polished documentation is not needed:
- traffic delivery diagram: load balancer, proxy, application, static delivery services, external integrations;
- current front-end layer configurations and routing rules;
- list of domains and subdomains with a breakdown of where static assets are served and where dynamic content is served;
- statistics: share of repeat visits, average file size, audience geography;
- how certificates are issued and renewed, whether renewal automation exists;
- constraints: security requirements, regulations, change windows, zones closed to edits;
- export of metrics or logs for a representative period — they show behavior under load.
Then we respond in two steps. First, a short analysis: what changes are needed at each layer and in what order they can be safely made.
Then we return with an implementation plan: the scope of work by stage, timeline estimates, rollback points, and a way to verify the result on live traffic.
Describe the task and attach what you have — we will return with an estimate and work plan.