HTTP/2 Prioritization and its Impact on Web Performance

Abstract

Web performance is a hot topic, as many studies have shown a strong correlation between slow webpages and loss of revenue due to user dissatisfaction. Front and center in Page Load Time (PLT) optimization is the order in which resources are downloaded and processed. The new HTTP/2 speciication includes dedicated resource prioritization provisions, to be used in tandem with resource multiplexing over a single, well-illed TCP connection. However, little is yet known about its application by browsers and its impact on page load performance.This article details an extensive survey of modern User Agent implementations, with the conclusion that the major vendors all approach HTTP/2 prioritization in widely diferent ways, from naive (Safari, IE, Edge) to complex (Chrome, Firefox). We investigate the performance efect of these discrepancies with a full-factorial experimental evaluation involving eight prioritization algorithms, two of-the-shelf User Agents, 40 realistic webpages, and ive heterogeneous (emulated) network conditions. We ind that in general the complex approaches yield the best results, while naive schemes can lead to over 25% slower median visual load times. Also, prioritization is found to matter most for heavy-weight pages. Finally, it is ascertained that achieving PLT optimizations via generic serverside HTTP/2 re-prioritization schemes is a non-trivial task and that their performance is inluenced by the implementation intricacies of individual browsers.

Debugging QUIC and HTTP/3 with qlog and qvis

“…This multiplexing can happen in various ways (e.g., files are sent sequentially as a whole or are scheduled via Round-Robin (RR) after being subdivided in chunks) and is typically steered using a prioritization system (i.e., H2's complex dependency tree [15]). However, correctly implementing H2 prioritization is difficult, which has lead to degraded Web page load performance [25,60,87]. Partially due to a lack of tooling, these issues were only discovered years after H2's standardisation [26,87] (and remain to this day [74]), which prompted a redesign of priorities in H3 [54,61].…”

“…However, correctly implementing H2 prioritization is difficult, which has lead to degraded Web page load performance [25,60,87]. Partially due to a lack of tooling, these issues were only discovered years after H2's standardisation [26,87] (and remain to this day [74]), which prompted a redesign of priorities in H3 [54,61]. Several H3 developers are now using the qvis multiplexing diagram (Figure 1) to verify their implementations of this simplified setup.…”

Towards QUIC debuggability

“…Even though HTTP/2 was already standardized in 2015, is conceptually much simpler than QUIC and various mature, interoperable implementations exist, significant operational differences remain. Unexpected issues and bugs keep popping up even now (e.g., Server Push is inconsistent [12], prioritization support is lacking or faulty [8,9,19,33], dynamic HPACK compression is missing [32]) and few implementations support the full specification (correctly) [13]. Finding these implementation discrepancies can be complex in practice, mainly due to a lack of a common logging format and specialized tools.…”

“…The H2vis project [5] has both a priority tree visualization and a timeline on which individual TCP packets are shown next to HTTP/2 frames, split out per-stream. These tools have helped us to efficiently discover differences in various implementations and led to the uncovering of several bugs [33]. While H2vis only uses packet traces, others developed similar tools based on the chrome devtools output [25].…”

“…We do not know of any similarly complex tools attempting to parse and display various server (debug) log formats directly or even use the proposed standard format [2]. Instead, to gain deeper insights, we and other academic work have had to turn to custom or adjusted HTTP/2 implementations to obtain additional debug output or test specific scenarios [13,30,33].…”