Do HTTP/2’s Multiplexing Still Need Image Sprites? Experimental Insights

1. Background

Upgrading a site to HTTP/2 often results in many small image requests. The classic front‑end performance rule of reducing request count (e.g., using sprites) raises the question of whether it still applies under HTTP/2, and whether a large number of concurrent small requests impacts the loading speed of other static resources such as JavaScript.

To answer these questions, a simple experiment was conducted, comparing several HTTP scenarios and measuring request latency.

HTTP/1.1 merge vs split

HTTP/1.1 vs HTTP/2 concurrent requests

HTTP/2 merge vs split

Effect of many vs few HTTP/2 concurrent requests on other resources

2. Experiment Setup

The theory behind merging (reducing request count) and splitting (leveraging concurrency) is explained. HTTP/2 introduces multiplexing and header compression to solve HTTP‑level head‑of‑line blocking, though TCP‑level blocking remains. Images were served from Tencent Cloud COS with CDN acceleration to avoid local server performance bias.

3. Experiment Analysis

3.1 HTTP/1.1 Merge vs Split

Splitting into many small requests took significantly longer than merging into a single request, especially on slower networks.

The request flow consists of DNS lookup, TCP handshake, request send, TTFB, and data transfer. Merging N requests can theoretically save (N‑1)*(T1+T2+T3+T4), though real‑world factors like DNS caching and keep‑alive reduce the benefit.

When file size is small, merging reduces load time; for larger files, merging offers little advantage and may hurt cache hit rates.

3.2 HTTP/1.1 vs HTTP/2 Concurrent Requests

HTTP/2’s total concurrent request time is clearly better than HTTP/1.1, with the gap widening as network speed degrades.

Multiplexing : Multiple HTTP streams share a single TCP connection, interleaving frames so they can be reassembled per stream.

Header Compression : Uses static and dynamic tables to transmit header indexes instead of full text, reducing overhead.

3.3 HTTP/2 Merge vs Split

Even with HTTP/2’s multiplexing, merging still outperforms splitting, though the performance gap is much smaller than in HTTP/1.1.

Reasons include:

The merged image (516 kB) is smaller than the total size of 361 small images (646 kB).

Even with header compression, many small requests transmit extra header and settings frames, adding roughly 100 kB of overhead.

Consequently, the observed split‑to‑merge time ratios (2.62, 2.96, 1.84) exceed the theoretical size ratio (≈1.44).

3.4 Impact of HTTP/2 Concurrent Request Count on Other Resources

When loading 360+ small images, 130+ images, 20+ images, or none, the following was observed:

JavaScript load time remains ~0.12 s regardless of image concurrency under unlimited bandwidth.

Large image load time decreases as the number of concurrent small images drops.

Under Fast3G/Slow3G limits, JavaScript loads faster when small images are present, likely because the JS shares a separate TCP connection with the large image; when no small images exist, the JS competes with the large image for bandwidth, reducing its apparent latency.

4. Conclusions

HTTP/1.1 merging still yields noticeable performance gains.

HTTP/2’s multiplexing provides a clear advantage over HTTP/1.1 for many concurrent requests, though extreme packet loss on a single TCP stream can hurt overall performance.

In HTTP/2, merging still reduces total load time compared to splitting, but the benefit is less pronounced; decisions should consider cache hit rates and resource size.

When bandwidth is ample, cross‑origin requests do not interfere, but same‑origin concurrent requests increase latency for lower‑priority resources as concurrency grows.

The experimental environment is limited; results may vary with different browsers, operating systems, server capabilities, or resource sets.