Accepting selected projects for Q2 2024 Check availability
SERVER 02SYSTEM ONLINELAST SYNC: 03:17:44RSS_FEED.XML — PARSE WARNING
HALF ASSEDTECHNICAL NOTES_
EST. 2009ISSUE 04.2BEST VIEWED AT 1024 × 768
TECHNICAL NOTES / PRACTICAL GUIDES / PLATFORM / RECORD 85fbf5
[PLATFORM]GUIDE

Migrating a production site to HTTP/2

POSTED: 09.11.2017AUTHOR: ADMIN10 MIN READCOMMENTS: 0

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.

MIGRATION OUTCOME

The aim is a simpler and faster delivery path, not the largest possible count of requests multiplexed over one connection.