HTTP/2 is shipping in browsers and servers throughout 2016. The protocol brings multiplexing, server push, and binary framing—fundamental changes that supposedly invalidate HTTP/1.1 optimization practices like domain sharding and sprite sheets.
Reality is messier. Not all browsers support it. Not all servers either. And some HTTP/1.1 optimizations still help. The transition period is awkward.
What HTTP/2 Changes
HTTP/1.1 has been standard since 1999. Its limitations shaped web development:
Head-of-line blocking: Only one request per connection. Opening many connections is expensive.
Header overhead: Headers sent with every request, adding kilobytes of redundant data.
No prioritization: Can't tell browser "this resource matters more."
Sequential: Requests must wait for responses.
HTTP/2 fixes these:
Multiplexing: Multiple requests on one connection, no head-of-line blocking
Header compression: HPACK compresses headers, reducing overhead
Server push: Server can send resources before requested
Prioritization: Specify which resources are critical
Binary protocol: More efficient parsing than text-based HTTP/1.1
These changes are significant. The question is how they affect development practices.
The "Best Practices" That Change
HTTP/1.1 optimization tactics become anti-patterns:
Domain sharding (using multiple domains for parallel downloads): HTTP/2's multiplexing makes this unnecessary and harmful. One connection is better.
Concatenation (combining files): Bundling all JavaScript into one file means cache invalidity on any change. HTTP/2's cheap connections make multiple small files viable.
Spriting (combining images): Same reasoning. Individual images are better for caching and compression.
Inlining (base64 assets in CSS/HTML): Hurts caching. Not needed with cheap requests.
These practices were workarounds for HTTP/1.1 constraints. HTTP/2 removes the constraints.
The Messy Reality
But we can't just abandon HTTP/1.1 practices:
Browser support isn't universal. Chrome, Firefox, Safari, Edge support HTTP/2. IE 11 has limited support. Older browsers don't support it at all.
Serving both protocols: Servers need to support both HTTP/1.1 and HTTP/2, falling back based on client capabilities.
CDNs vary: Not all CDNs support HTTP/2 well. Some do, some are catching up.
Build tools assume HTTP/1.1: webpack, browserify, build pipelines optimize for concatenation. Retooling is complex.
HTTPS required: HTTP/2 requires HTTPS (technically optional but browsers enforce it). Migration to HTTPS is its own project.
The transition means supporting two protocols with different optimizations simultaneously.
What Still Matters
Some optimizations remain valuable:
Minification: Smaller files are still better
Compression: gzip/brotli still essential
Image optimization: Reduce image size always helps
Critical rendering path: Progressive enhancement still matters
Caching: Cache headers remain important
HTTP/2 doesn't eliminate all performance work—it changes which tactics work best.
Server Push: Promising but Tricky
Server push lets servers send resources before requested:
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=scriptThe server sees the HTML request and pushes CSS/JS immediately. This eliminates round-trips.
But it's complex:
- Push too much, waste bandwidth
- Push what's cached, waste bandwidth
- Push timing is tricky
- Browser support varies
- Cache coordination between push and normal requests is hard
Server push is powerful in theory but requires careful implementation. Easy to get wrong.
The Migration Path
Moving to HTTP/2 isn't flipping a switch:
- Enable HTTPS (required for HTTP/2)
- Enable HTTP/2 on server (nginx, Apache, Node)
- Test with both protocols (some clients still use HTTP/1.1)
- Gradually adopt HTTP/2 optimizations (undoing concatenation is risky)
- Measure impact (some sites see big improvements, some don't)
This is multi-month effort, not weekend project.
The Bundling Debate
HTTP/2 theoretically makes bundling unnecessary—just load individual modules. But:
Dead code elimination: Bundlers remove unused code. Individual files can't.
Tree shaking: webpack 2 (coming) shakes out unused exports. Requires bundling.
Processing: Transpilation, minification, optimization happen during bundling.
Deployment: Deploying thousands of small files is operationally complex.
Maybe bundling changes—smaller bundles per route instead of one mega-bundle. But "no bundling" seems unrealistic for complex apps.
Browser DevTools Lag
Chrome DevTools shows HTTP/1.1-style waterfall charts. Understanding HTTP/2's multiplexing in these charts is confusing. Tooling hasn't caught up to protocol changes.
Debugging performance in HTTP/2 requires new mental models and tools that don't fully exist yet.
When HTTP/2 Helps Most
HTTP/2 benefits vary by application:
Helps most:
- Sites with many small resources
- Sites with high latency (mobile networks)
- Sites with complex dependency chains
- First-load performance critical
Helps less:
- Sites with few large resources
- Sites optimized for HTTP/1.1 caching
- Static content sites
- Low-latency connections (HTTP/1.1 is "good enough")
HTTP/2 isn't universally faster—it's faster in specific scenarios.
Looking Forward
HTTP/2 adoption will continue through 2016-2017. Eventually it becomes standard and HTTP/1.1 optimizations disappear.
But the transition is years, not months. Teams will support both protocols for foreseeable future.
The promise of HTTP/2—simpler development, better performance—is real but distant. For now, we optimize for both protocols and accept the complexity.
Resources:
