Migrating a production site to HTTP/2
HTTP/2 changes how requests share a connection, but it does not remove DNS, TLS, server response or browser execution costs. Migration should simplify only the HTTP/1.1 workarounds that measurement shows are no longer useful.
Confirm the serving boundary
Identify whether the CDN, load balancer or origin negotiates HTTP/2 and verify ALPN, certificate chains and supported TLS configurations from outside the network. Keep the origin protocol documented when it differs from the browser edge.
Establish an HTTP/1.1 baseline
Capture representative waterfalls, connection counts, cache state, server timing and user metrics before changing delivery. Include repeat visits and slower connections so multiplexing is not credited for unrelated cache changes.
Review old optimisations
Test removal of domain sharding, excessive concatenation and small inlined assets independently. Sharding can create unnecessary DNS and TLS work, while one large bundle can still delay code needed for a small page.
Treat push as an experiment
Select only stable critical assets for server push and measure duplicate transfer and repeat visits. Prefer ordinary early discovery or preload where it produces the same outcome with clearer browser cache behaviour.
Monitor compatibility and fallback
Retain HTTP/1.1 negotiation for clients and intermediaries that require it, then compare errors and latency by protocol. A displayed h2 connection is deployment evidence, not proof of a user-visible improvement.
The aim is a simpler and faster delivery path, not the largest possible count of requests multiplexed over one connection.