The team still concatenates thirty JavaScript files "because HTTP/1" — while nginx has served HTTP/2 for two years. The monolithic bundle breaks cache on every hotfix. Meanwhile, another project spreads assets across static1, static2, static3: three TLS handshakes, cancelling multiplexing with habits inherited from HTTP/1.
HTTP/2 multiplexes multiple requests on one TCP/TLS connection. Gone is HTTP/1.1's six parallel connection slots — not gone is render-blocking JavaScript or four-megabyte images. Understanding multiplexing means knowing what it fixes and what it leaves untouched.
Multiplexing: what actually changes
Under HTTP/1.1, browsers limited parallel connections to the same domain — hence domain sharding, CSS sprites, and file concatenation. HTTP/2 opens independent streams on a single connection, with HPACK header compression.
| HTTP/1 practice | Under HTTP/2 |
|---|---|
| Domain sharding | Counter-productive |
| CSS sprites | Less needed |
| Single huge bundle | Modules + hash-based cache |
| Six keep-alive connections | One rich connection |
Multiplexing speeds transport — not file size or JavaScript execution order.
A site loading twelve synchronous scripts in <head> stays slow, HTTP/2 or not. The network constraint changed; the critical rendering path constraint did not.
Prioritisation, head-of-line blocking, limits
HTTP/2 suffered TCP-level head-of-line blocking: one lost packet stalled all streams. HTTP/3 (QUIC) improves this over UDP. In practice, reducing synchronous scripts in <head> matters more than tweaking stream priorities in nginx.
Stream priorities between browser and server have modest real impact compared to optimising the LCP image or deferring non-critical JavaScript. Measure LCP, TBT, and INP — not just the protocol in response headers.
CDN, TLS termination, and origin
HTTP/2 termination at the CDN (Cloudflare, etc.) to an HTTP/1.1 origin remains very common: the client gets multiplexing; the origin keeps a simpler stack. Verify ALPN negotiation with:
curl -I --http2 https://your-site.example
On shared hosting without native HTTP/2, a free CDN in front of the origin often suffices. Compare offers via our directory — ALPN h2 support depends on the web server and certificate, not just a panel checkbox.
HTTP/2 server push is largely deprecated: Chrome removed it, and preload via <link rel="preload"> offers finer control without wasting bandwidth on already-cached resources.
HTTP/3 and progressive migration
HTTP/3 runs on QUIC (UDP) and improves performance on mobile networks with packet loss. Enablement happens progressively at the CDN — Cloudflare, Fastly, and others turn it on without application changes. Your PHP or Node.js code does not need to change; the network layer evolves.
Remove HTTP/1 practices that became harmful first: domain sharding, monolithic bundles, unnecessary sprites. Then enable HTTP/3 if your CDN offers it — a bonus, not a prerequisite.
Post-HTTP/2 checklist
- Remove domain sharding on static assets.
- Split bundles logically (by route or feature).
- Preload the LCP image; defer or async non-critical JavaScript.
- Keep Brotli or gzip compression — HTTP/2 does not compress response bodies.
- Align cache headers so network gains are not cancelled by excessive revalidation.
The peak: HTTP/2 badge, still slow site
Here is what the protocol shown in DevTools does not guarantee.
Understanding multiplexing means stopping HTTP/1 optimisation while still optimising content and the critical path.
Decide and move forward without blind spots
In half a day, verify HTTP/2 delivers real gain:
- Confirm HTTP/2 is active client-side (
curl --http2or Protocol tab in DevTools). - Remove domain sharding on assets — measure LCP before and after.
- Replace the monolithic bundle with reasonable modules with hashed filenames.
- Enable HTTP/3 via CDN if available, without waiting for an application rewrite.
- Compare hosts with TLS and HTTP/2 via the directory and compare tool.
If the site stays slow after HTTP/2, the bottleneck is elsewhere — images, JavaScript, database. The technical blog has complementary guides on caching and image formats.
Frequently asked questions
Does HTTP/2 make domain sharding useless?
Yes, in principle. One multiplexed connection serves many files without opening new TCP/TLS connections. Sharding recreates costly handshakes and often cancels multiplexing benefits. Keep one clean HTTP/2 origin or CDN.
Should I still concatenate CSS/JS?
Less than HTTP/1.1, but a huge bundle keeps poor cache granularity: every change invalidates the whole file. Aim for reasonable modules, not forty uncacheable micro-files.
Is HTTP/2 server push useful?
Largely no. Chrome removed support, and preload via <link> tag offers finer control. Do not configure nginx push without measuring bandwidth impact.
What does HTTP/2 everywhere require from hosting?
TLS with ALPN h2, valid certificate, recent web server (nginx, Apache, Caddy), or CDN terminating HTTP/2. On shared hosting, check panel support; otherwise, put a CDN in front of an HTTP/1.1 origin.
HTTP/2 fixes the network queue — not the JavaScript queue.