Re: Extensible Priorities and Reprioritization

Patrick Meenan <> Sat, 20 June 2020 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 361493A0D6B for <>; Sat, 20 Jun 2020 07:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.748
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q6rylDrtfbpa for <>; Sat, 20 Jun 2020 07:20:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01DBE3A0D0D for <>; Sat, 20 Jun 2020 07:20:55 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jmeJO-0002Ma-Hn for; Sat, 20 Jun 2020 14:17:38 +0000
Resent-Date: Sat, 20 Jun 2020 14:17:38 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jmeJM-0002Lp-A3 for; Sat, 20 Jun 2020 14:17:36 +0000
Received: from ([2607:f8b0:4864:20::131]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jmeJJ-0002sT-QQ for; Sat, 20 Jun 2020 14:17:36 +0000
Received: by with SMTP id c75so11929682ila.8 for <>; Sat, 20 Jun 2020 07:17:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wRO3Qx3kwTjo64Y9mM4Lr+ycQMusybH7yDVJro+sM4s=; b=RdtsJWwSUZTgdqN0CtX3kSK9tYbSdgPSzWTmLhnLT5EuxmuMR34+TlRzkzuFqeK1hJ Bgal4vQDzHuEerlqK4m5VuZlpB9ZjPV+YQWZ2bPsaKq8iPur/Wd/xf6RHfe8e/2zSv1T LmFWfTjOioWF4wNT6t3aQOwLMJmFTwcvY06pjxCnC9qRbb/JTgg23DlZBAJa+BSburzG Ja2EBsElZLGMD5THFKY101cTPCZ0TZdBuslz6bz6QRNbGt36Shr3aPdaIzAbkXJgBESy DdA7vHFPUYJHOOFHU41CNfFZZJaZ0xypkSc5ngtg38UqQysiWKe8ug2iRl3Wn+2MyIyZ F9Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wRO3Qx3kwTjo64Y9mM4Lr+ycQMusybH7yDVJro+sM4s=; b=Rn7IkCgozRjJr4ZtP9QOMBLZrORq518jKNXhypyvbK04zzixRzm7tAciatMxPeRzwB jlIaj4f32wh5nxvBD8hFx+zgNd/eL0md7tC/K4qNxuq7c917WVgvuLZ7+aMHwn1kdan/ /YWGmogjclqcoGjw0cArd+0fj+ZG0o21bqDC08PsrnYu1+Iz+l1DcxP2dIe9Cu6IgbEE KG9hvTF4QNQblSenhRuXwyzJeIsBPgEPP1veN+HvuBe7jzczqXNXj0uOO4PUP65bnJHN Bp9/3IkmWpSQMNJ6w4D/j+Vf4lCMkOfsEu3MlEg6kexd4G60veiDX0u3vTllH1O/3el8 KdZA==
X-Gm-Message-State: AOAM53308NgKQD82xoL4rNTPp45XJ+Er5GwWEQ0jcluvBHfJxbldAudQ D2v3W5ekVPvtCy1i9L7nhp/wqrha0kplL+bD5ho=
X-Google-Smtp-Source: ABdhPJwvMfTSoc3gHvodHiTpCemHsdR2bMPwlPOUsScFXnfwIVQBwcOdvWHWGqygwgPjxWMh92T76uH9HORWEq3WKcE=
X-Received: by 2002:a92:d984:: with SMTP id r4mr8362053iln.302.1592662642518; Sat, 20 Jun 2020 07:17:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Patrick Meenan <>
Date: Sat, 20 Jun 2020 10:17:11 -0400
Message-ID: <>
To: Yoav Weiss <>
Cc: Kazuho Oku <>, Kinuko Yasuda <>, Lucas Pardue <>, =?UTF-8?Q?Bence_B=C3=A9ky?= <>, Eric Kinnear <>, Patrick Meenan <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000000df07905a884ab30"
Received-SPF: pass client-ip=2607:f8b0:4864:20::131;;
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: 1jmeJJ-0002sT-QQ 721e8d250e034c6f009157455a4175e9
Subject: Re: Extensible Priorities and Reprioritization
Archived-At: <>
X-Mailing-List: <> archive/latest/37805
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 <> wrote:

> On Wed, Jun 17, 2020 at 9:55 AM Kazuho Oku <> wrote:
>> 2020年6月11日(木) 6:46 Kinuko Yasuda <>rg>:
>>> (Sorry, sent it too soon...)
>>> On Thu, Jun 11, 2020 at 6:12 AM Kinuko Yasuda <>
>>> 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
> <> to
> turn off Chromium's H2 request prioritization. I believe +Pat Meenan
> <> 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 <
>>>>> wrote:
>>>>> On Tue, Jun 9, 2020 at 4:27 PM Patrick Meenan <>
>>>>> 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