Re: Extensible Priorities and Reprioritization
Patrick Meenan <patmeenan@gmail.com> Mon, 06 July 2020 20:22 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0983A0A53 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Jul 2020 13:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7MPH0Jz_paH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Jul 2020 13:22:17 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7743A0A52 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 6 Jul 2020 13:22:17 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jsXad-0005Xu-Nj for ietf-http-wg-dist@listhub.w3.org; Mon, 06 Jul 2020 20:19:48 +0000
Resent-Date: Mon, 06 Jul 2020 20:19:47 +0000
Resent-Message-Id: <E1jsXad-0005Xu-Nj@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <patmeenan@gmail.com>) id 1jsXac-0005X4-GD for ietf-http-wg@listhub.w3.org; Mon, 06 Jul 2020 20:19:46 +0000
Received: from mail-il1-x12b.google.com ([2607:f8b0:4864:20::12b]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <patmeenan@gmail.com>) id 1jsXaU-0000rc-Oc for ietf-http-wg@w3.org; Mon, 06 Jul 2020 20:19:46 +0000
Received: by mail-il1-x12b.google.com with SMTP id q3so23342516ilt.8 for <ietf-http-wg@w3.org>; Mon, 06 Jul 2020 13:19:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FV8SRrNFby3NnKv11d5djxPxgYXQFtlK/K2oS67UYmQ=; b=m6c0YXniWtTZJMhzfrE6qCTuU9eR9wiGtcAXidjasS84HzpOqc6Agod8bAvKWCQDvd G5yWfaUwyF5ruL6Qw236eeTSVTKbDCc9hbMIpp90vdl6K7SQsbAgTTytDXfseQckf3eF lgRa5p5a5Z+iuQLuB4TeVUwXPbiVwu0r7ov921YotQl2Ka36Tt46vuZ0bml6z2FCXjy/ l5meCCCZ1RdUyKT3VXY7kxrVUGp1ZupJCFQgCQ/PCqjLXULnrvuhwacspLwAWt0XNQnr XwNCfLx3MMX4WUAz4ofsranUyxyMgNuHaOfml+GnzdRyMqvYcTJZc7tOHAqYSZGjT/iJ sSGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FV8SRrNFby3NnKv11d5djxPxgYXQFtlK/K2oS67UYmQ=; b=rLzLHQ5RBpnIysl7suLV0NYB09U5NxDcWpMhmTlHFyZjeEuWQ1jgjRr3fbEoVd8GO9 RVSXStBdPBLzESBaEhc4ioB2QRV+IkUOrNoYSxjkLYNs7vgpI9RLG/jiW87mr4V0QgkJ AaeSUtTfOGx2pkndv3EfdiPiSSRZ1aCH+t2vk7iXrKfT6QdiLmUcc7MjXm22naj1pRmo UL1pOCJHnelIZcE+2bhfQb1OKZyFHT3dGuKVFVsNC9jRRXA2iW+mgX7oiE1RWxTNqzAZ lgzeNFLqRhymiXxFurtMuyk5ghh4f/QIBt1oluy2+WXSlX9uVu4Yl/x/w6ts6SoRvmZZ NFPA==
X-Gm-Message-State: AOAM532kCYroIl0TuvhvHbwaMZpvkqCv3ypJ8WEVDe7OfA1UCbCy37fv zQRakjGgc6jf4geFWEldOlPY7KR5o+MlUSoTpPA=
X-Google-Smtp-Source: ABdhPJxvKro8/velHwmwHIoMVJV82m2X5MDDbEbwH6bNKaG+OV8vANKLcusA7kRmzFiUdYXVE7FcfAUUoZwjTHcimkk=
X-Received: by 2002:a92:b655:: with SMTP id s82mr33096863ili.268.1594066766420; Mon, 06 Jul 2020 13:19:26 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com> <459C86F8-A989-4EF4-84DC-3568FF594F36@apple.com> <CANatvzwSpSHd7kZD-4tyMGkBJDdCBi6r_pLBvnaT8rrQy6SBHQ@mail.gmail.com> <CACMu3treK0m2mbpw9FebOjOcEed0bW-DbLbryHJH1DWAHoz+9g@mail.gmail.com> <CAJV+MGy2CytgPVEwEO3nDfpZ6h9+CCL-bODk=65cXexvS3N7Lw@mail.gmail.com> <CALGR9oYDApddLFzXv180TEXpmTaOpDCDNY41PxmbMJK7N4F4zQ@mail.gmail.com> <CAMWgRNaMZxph3zQv+O-SW7=PKBtDuGZNQ4+3X2geyXU545Vx9w@mail.gmail.com> <CAMWgRNaBAodWewpbi4cqFiMLWVd0SDnau7B4x0tjk+i=sMURpQ@mail.gmail.com> <CANatvzyQiNXY6xOYju8afe7-T6ZNMtQTPQE-AkfFK=2_yTzB1Q@mail.gmail.com> <CACj=BEhh+K=uMS613OsDFmvH18miNvm9m11M7QsL02Lc+JxUhg@mail.gmail.com> <CAJV+MGx3-cvPER2q1SPsgTbVP0TwAgPzNCQk_40dDPSr3JfkNg@mail.gmail.com>
In-Reply-To: <CAJV+MGx3-cvPER2q1SPsgTbVP0TwAgPzNCQk_40dDPSr3JfkNg@mail.gmail.com>
From: Patrick Meenan <patmeenan@gmail.com>
Date: Mon, 06 Jul 2020 16:19:15 -0400
Message-ID: <CAJV+MGwXLoVe3RWPMCw9iJQ1Qr0TrJOezWq1VWOqrWYnBneQ4Q@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Kinuko Yasuda <kinuko@chromium.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Bence Béky <bnc@chromium.org>, Eric Kinnear <ekinnear@apple.com>, Patrick Meenan <pmeenan@webpagetest.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000005c60aa05a9cb970d"
Received-SPF: pass client-ip=2607:f8b0:4864:20::12b; envelope-from=patmeenan@gmail.com; helo=mail-il1-x12b.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jsXaU-0000rc-Oc c8ddec8b2921fd74938e6b4df975b251
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <https://www.w3.org/mid/CAJV+MGwXLoVe3RWPMCw9iJQ1Qr0TrJOezWq1VWOqrWYnBneQ4Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37842
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Sorry about the delay, just gathered the results. The full raw results are here <https://docs.google.com/spreadsheets/d/14iyeO--I-K-l7er1kGuW-iTKogsgXFz4Z3M-aowSUdI/edit?usp=sharing>. It looks like the impact dropped quite a bit across the full 25k URLs but looking at individual tests the impact is quite dramatic when it does impact (and it does exactly what we'd expect it to do for those outlier cases). The 95th percentile numbers tend to be the more interesting ones and in the data set, reprioritization enabled is the control and disabled is the experiment so positive changes means disabling reprioritization is that much slower. Largest Contentful Paint: 4% slower without reprioritization Speed Index: 2.75% slower without reprioritization Dom Content Loaded: 1.3% faster without reprioritization This is pretty much (directionally) what we'd expect since reprioritization boosts the priority of visible images (LPC/Speed Index) above late-body scripts (DCL). It's particularly dramatic for pages that use background images for any part of the page because they are discovered after all other resources and would normally be scheduled after all other scripts and inline images but if they are visible in the viewport the reprioritization helps them load much sooner. Looking at a few examples of the extreme cases: https://www.thehelm.co/ - (Filmstrip <https://www.webpagetest.org/video/compare.php?tests=200625_MT_32af039543326a2bdb5d87e2adb95fe7-r%3A3-l%3AStock%2C200701_HY_6bb4d26adff32186e991c5b96ffaecea-r%3A1-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>) - The main background image in the interstitial loads at < 10s vs 90s without reprioritization https://blog.nerdfactory.ai/ - (Filmstrip <https://www.webpagetest.org/video/compare.php?tests=200616_KZ_496553703935231e5725c252844918db-r%3A1-l%3AStock%2C200616_BJ_798e2417374c03dfa3995586b01444a3-r%3A3-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>) - The background image for the main content loads at <5s vs 70s without reprioritization. No cost to DCL, just prioritized ahead of not-visible images. https://events.nuix.com/ - (Filmstrip <https://www.webpagetest.org/video/compare.php?tests=200628_1A_0e61aa9f59e08f3bbb8e5d9690fe64fb-r%3A3-l%3AStock%2C200628_Q2_1793a50022566cedd6ab48dd871d5c7e-r%3A3-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>) - Another hero background image (detecting a theme?) loads at 10s vs 60s Looking at a few of the bigger DCL regressions: https://oaklandcitychurch.org/ - (Filmstrip <https://www.webpagetest.org/video/compare.php?tests=200627_XR_fae3bd7aa57238591cb122c9fe634cb7-r%3A2-l%3AStock%2C200627_R9_26ad61b65965e7bf89a8aa27a7d78ff1-r%3A2-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>) - DCL got much slower (11s -> 33s) as a direct result of the background image moving from 30s to 10s (the pop-up interstitial was delayed along with the scripts that control it). For the specific case that most of these tests exposed (background image discovered late by CSS) it is theoretically possible for Chrome to detect the position before making the initial request (since it is only discovered at layout anyway) but that wouldn't help any of the more dynamic cases like when a user scrolls a page or a carousel rotates and what is on screen changes dynamically. I'm still of the pretty strong opinion that we need reprioritization but the web won't necessarily break without it and sites (and browsers) may be able to minimize the impact of not being able to reprioritize (though that might involve holding back requests and prioritizing locally like Chrome does for slow HTTP/2 connections). On Sat, Jun 20, 2020 at 10:17 AM Patrick Meenan <patmeenan@gmail.com> wrote: > An early read on Yoav's Canary test is that most metrics are neutral but > Largest Contentful Paint degrades ~6.8% on average and 12% at the 95th > percentile without reprioritization and Speed Index degrades 2.6% on > average and 5.4% at the 95th percentile. This is not entirely unexpected > because the main use case for reprioritization in Chrome right now is > boosting the priority of visible images after layout is done. > > We'll see if it holds after the full test is complete. The early read is > from 3,000 of the 25,000 URLs that we are testing (all https hosted on > Fastly for simplicity since we know it handles HTTP/2 reprioritization > correctly). The tests are all run at "3G Fast" speeds with desktop pages > to maximize the liklihood that there will be time for reprioritization to > happen. I'll provide the full raw data as well as summary results when the > test is complete (at least another week, maybe 2). > > On Wed, Jun 17, 2020 at 5:43 AM Yoav Weiss <yoav@yoav.ws> wrote: > >> >> >> On Wed, Jun 17, 2020 at 9:55 AM Kazuho Oku <kazuhooku@gmail.com> wrote: >> >>> >>> >>> 2020年6月11日(木) 6:46 Kinuko Yasuda <kinuko@chromium.org>: >>> >>>> (Sorry, sent it too soon...) >>>> >>>> On Thu, Jun 11, 2020 at 6:12 AM Kinuko Yasuda <kinuko@chromium.org> >>>> wrote: >>>> >>>>> 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 >>>>> >>>> >>>> Let me stress though that testing this with servers that can properly >>>> handle reprioritization could change the landscape, and again this isn't >>>> really capturing how it affects long-lived request cases, or cases where >>>> tabs go foreground & background while loading, so for now I'm not very >>>> motivated to remove the reprioritization feature either. >>>> >>> >>> Hi Kinuko, >>> >>> Thank you for sharing your data. I feel a bit sad that reprioritization >>> isn't showing much benefit at the moment. I tend to agree that we are >>> likely to see different results between server implementations and HTTP >>> versions being used. The effectiveness of reprioritization depends on the >>> depth of the send buffer (after prioritization decision is made), at least >>> to certain extent. >>> >> >> FWIW, I added a flag >> <https://chromium-review.googlesource.com/c/chromium/src/+/2232923> to >> turn off Chromium's H2 request prioritization. I believe +Pat Meenan >> <patmeenan@gmail.com> is currently running tests with and without this >> flag a list of servers we estimate is likely to handle them well. >> >> >>> >>> >>>> >>>> >>>>> 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 >>>>>> >>>>>> >>> >>> -- >>> Kazuho Oku >>> >>
- Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Extensible Priorities and Reprioritization Eric Kinnear
- Re: Extensible Priorities and Reprioritization Kazuho Oku
- Re: Extensible Priorities and Reprioritization Martin Thomson
- Re: Extensible Priorities and Reprioritization Bence Béky
- Priority implementation complexity (was: Re: Exte… Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Dmitri Tikhonov
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Dmitri Tikhonov
- Re: Priority implementation complexity (was: Re: … Roy T. Fielding
- Re: Extensible Priorities and Reprioritization Kinuko Yasuda
- Re: Extensible Priorities and Reprioritization Kinuko Yasuda
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Martin Thomson
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Barry Pollard
- Re: Priority implementation complexity (was: Re: … Barry Pollard
- Re: Extensible Priorities and Reprioritization Kazuho Oku
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Tom Bergan
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Tom Bergan
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Reprioritization - implementation intent Mark Nottingham
- Re: Reprioritization - implementation intent Eric Kinnear
- Nice to have guidance (was: Re: Reprioritization … Lucas Pardue
- Re: Nice to have guidance (was: Re: Reprioritizat… Eric Kinnear
- Re: Reprioritization - implementation intent Yoav Weiss
- Re: Reprioritization - implementation intent Yoav Weiss
- Re: Reprioritization - implementation intent Yoav Weiss