- From: Kinuko Yasuda <kinuko@chromium.org>
- Date: Thu, 11 Jun 2020 06:12:47 +0900
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Patrick Meenan <patmeenan@gmail.com>, Bence Béky <bnc@chromium.org>, Kazuho Oku <kazuhooku@gmail.com>, Eric Kinnear <ekinnear@apple.com>, Yoav Weiss <yoav@yoav.ws>, Patrick Meenan <pmeenan@webpagetest.org>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAMWgRNaMZxph3zQv+O-SW7=PKBtDuGZNQ4+3X2geyXU545Vx9w@mail.gmail.com>
Hi all, Reg: reprioritization benefit I can share some recent data for Chrome. For the two cases that are currently discussed I'm actually not fully sure about its benefit. For the renderer-triggered image reprioritization cases: this is a bit interesting one, we recently found two things: - Delaying to start low-prio requests could often work better (partly because of server-side handling) than re-prioritizing while inflight - In-lab measurements (tested with top 10k real sites, both on Mobile and Desktop) showed that removing in-flight re-prioritization doesn't impact page load performance a lot I suspect this is maybe because server-side handling is not always perfect and most of requests on the web are short-lived, and this may not be true for the cases where long-running requests matter. I don't have data for whether may impact background / foreground cases (e.g. Chrome tries to lower priorities when tabs become background) For download cases, Chrome always starts a new download with a low priority (even if it has started as a navigation), so reprioritization doesn't happen. Kinuko On Wed, Jun 10, 2020 at 1:21 AM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > On Tue, Jun 9, 2020 at 4:27 PM Patrick Meenan <patmeenan@gmail.com> wrote: > >> Eric's download example is a great one for exposing the risks that would >> come for an implementation that supported prioritization but not >> reprioritization. >> >> Take the trivial example of an anchor link that links to a download (say, >> a 200MB installer of some kind): >> - When the user clicks on the link, the browser assumes it is doing a >> navigation and issues the request with the "HTML" priority (relatively >> high, possibly non-incremental >> - When the response starts coming back, it has the content-disposition to >> download to a file. >> - At this point, the 200MB download will block every other lower-priority >> request on the same connection (or possibly navigation if it is >> non-incremental) >> - The user clicks on another page on the same site and gets nothing or a >> broken experience until the 200MB download completes >> >> Without reprioritization the browser will effectively have to burn the >> existing QUIC connection and issue any requests on a new connection (and >> repeat for each new download). >> >> Implementing prioritization without reprioritization in this case is >> worse than having no prioritization support at all. >> > > Thanks Eric for presenting this case, and Patrick for breaking it down. > That does seem like a pretty bad outcome. > > Is this a good candidate for a test case? IIUC correctly the problem might > occur today with HTTP/2 depending on how exclusive priorities are used. I'm > curious if browsers can share any more information about what they do > already. How does Firefox manage such a resource with it's priority groups? > > Cheers > Lucas > >
Received on Wednesday, 10 June 2020 21:13:13 UTC