Intent to Remove: HTTP/2 and gQUIC server push

19176 views
Skip to first unread message

Brad Lassey

unread,
Nov 11, 2020, 5:00:39 PM11/11/20
to blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org

Primary eng (and PM) emails

las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org


Summary

Remove the ability to receive, keep in memory, and use HTTP/2 and gQUIC push streams sent by the server.  Send SETTINGS_ENABLE_PUSH = 0 at the beginning of every HTTP/2 and gQUIC connection to request that servers not send them.


Background

HTTP/2 allows servers to “push” a resource that the client will likely need before the client actually requests it, see https://httpwg.org/specs/rfc7540.html#PushResources.  The specification allows the client to reject the pushed resource at its discretion.


gQUIC is a non-standard protocol supported by Google servers, Akamai, and Litespeed.  It also allows servers to push resources in a fashion very similar to HTTP/2.  gQUIC is being obsoleted by HTTP/3 and support will eventually be removed entirely.


HTTP/3 is an almost-RFC protocol that also defines server push, see https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-server-push.


Chrome currently supports handling push streams over HTTP/2 and gQUIC, and this intent is about removing support over both protocols.  Chrome does not support push over HTTP/3 and adding support is not on the roadmap.


Motivation

Almost five and a half years after the publication of the HTTP/2 RFC, server push is still extremely rarely used.  Over the past 28 days, 99.95% of HTTP/2 connections created by Chrome never received a pushed stream (Net.SpdyStreamsPushedPerSession), and 99.97% of connections never received a pushed stream that got matched with a request (Net.SpdyStreamsPushedAndClaimedPerSession).  These numbers are exactly the same as in June 2019.  In June 2018, 99.96% of HTTP/2 connections never received a pushed stream.  These numbers  indicate the lack of active efforts by server operators to increase push usage.  On top of this, less than 40% of received pushes are used, down from 63.51% two years ago.  The rest are invalid, never get matched to a request, or already in cache.


Server push is very difficult to use well.  Akamai publicly shared two studies showing that push over HTTP/2 either does not change performance or improves performance marginally when used with certain restrictions, see https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0078.html.  However, these studies had been done more than a year ago and push usage data still does not indicate wide deployment even within Akamai’s network.  In light of this it is doubtful that smaller server operators have the resources to successfully deploy server push.


A contrasting result has been presented to the same IETF in 2018: a large experiment done by Chrome to measure the effect of server push on page load latency when using HTTP/2 showed that push increases latency at the long tail, see https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf.


As far as gQUIC goes, over the past 28 days, less than 1 out of 1,200,000 connections have seen any pushed streams.  We are not aware of any studies done on the effect of latency.


There is significant code complexity associated with Chromium supporting push: pushed requests have to be stored in an in-memory cache, looked up by URL across connections but only if the connection is authoritative for the request, matched by other parameters (method and other headers), and evicted after a timeout.  Running associated tests burden developers and infrastructure when developing unrelated features, and users bear the burden of increased binary size.  We believe that these outweigh the theoretical performance benefits.


Interoperability and Compatibility Risk

There is no compatibility risk.  Server push is meant as a performance optimization, a client is allowed to choose to reject any pushed streams.  In order to minimize wasted downlink capacity, Chromium would cancel pushed streams that a buggy server might open despite Chromium disabling server push by sending SETTINGS_ENABLE_PUSH = 0 in the initial SETTINGS frame.  Note however that in the experiment conducted two years ago no server was observed to send pushes when this setting was sent.


Firefox and Safari both support HTTP/2 push and we are not aware of any plans for removal.


Alternative implementation suggestion for web developers

It is recommended that servers use the <link rel="preload"> element to notify the client about subresources that it is expected to need.  Admittedly these resources will then need to be requested by the client, making them arrive 1 RTT later than a pushed resource would.  On the other hand, <link rel="preload"> allows the client to avoid fetching resources which are already cached.  Repeated efforts to analyze the latency gains of push found little or no benefit.


Because of limitations of HTTP/2 stream multiplexing, a server may normally only send <link rel="preload"> elements when the rest of the final headers are available, otherwise it would block other responses on the connection.  The 103 Early Hints status code (https://tools.ietf.org/html/rfc8297) is expected to provide better performance under certain circumstances by allowing information about resources that the client should request to be sent as soon as available and then making the connection available for carrying data on other streams until the final response is sent.  There is active effort to measure the potential latency gain of 103 Early Hints (compared to not using it, without using server push in either case), with the understanding that resources will be allocated to implementing it in Chromium in case data look promising.  See https://chromium.googlesource.com/chromium/src/+/master/docs/early-hints.md for more details.


It is interesting to note that server push has been used in ways other than originally intended.  One prominent example is to stream data from the server to the client, which will be better served by the upcoming WebTransport protocol.


Usage information from UseCounter

N/A: this network stack feature is not instrumented to use UseCounter.


Entry on the feature dashboard

https://www.chromestatus.com/feature/6302414934114304


Morgaine

unread,
Nov 11, 2020, 8:35:24 PM11/11/20
to blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
On Wednesday, November 11, 2020 at 5:00:39 PM UTC-5 las...@chromium.org wrote:

Chrome currently supports handling push streams over HTTP/2 and gQUIC, and this intent is about removing support over both protocols.  Chrome does not support push over HTTP/3 and adding support is not on the roadmap.


This is horrifying to hear. Please support the HTTP protocol. Please do not remove support, roll back the web, just because we have not figured out yet the good ways to use an advanced feature. Please have a plan for supporting HTTP!!!!!!! This is so scary to hear, and so unacceptable.

This is something that should make the web better. Web sites have been slow to figure out how to make this feature effective. But I believe in it fully. Not shipping HTTP support in Chrome would certainly be the death-knell for Push, and such a massive revolutionary change as Push deserves to have a decade plus for us to figure out how to use it effectively. Don't pull the plug on push like this. Don't. Please, please, don't. This is so scary to hear. I can not believe I am reading this.

Tiago Cardoso

unread,
Nov 11, 2020, 8:54:17 PM11/11/20
to blink-dev, Morgaine, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
HTTP Pipelining all over again.

Ian Swett

unread,
Nov 11, 2020, 9:00:52 PM11/11/20
to blink-dev, Morgaine, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
To clarify, server push is an optimization in HTTP/2(and presumably HTTP/3) that is optional and there is no requirement to implement it in either spec.  It does not exist in HTTP/1.1.  This is not an indicatoin Chrome does not support HTTP(S), since clearly Chrome would be useless if that occurred, but rather about removing an optimization that was not widely used and when it was used, typically not used wisely.

I support this change because I think efforts would be better spent elsewhere(ie: Alt-SVC, DoH, HTTP/3, ESNI, ...)

Ian

Ian Swett

unread,
Nov 11, 2020, 9:26:20 PM11/11/20
to Jay Phelps, blink-dev, Morgaine, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Anyone who objects should feel free to share data publicly which supports their case, as Akamai did a few years ago.  That data was very mixed and not particularly compelling on average, and the metrics have degraded since then, so I expect the metrics would look worse today.

On Wed, Nov 11, 2020 at 9:22 PM Jay Phelps <j...@outsmartly.com> wrote:
We disagree with this decision based on the real world data we have seen and the products we build around Http/2 Push. Just making our objection known.

--
Jay Phelps
Outsmartly

Morgaine

unread,
Nov 11, 2020, 10:56:23 PM11/11/20
to blink-dev, Ian Swett, blink-dev, Morgaine, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Jay Phelps
My issue is that PUSH has been unusable for web app development for half a decade[1] & no one has tried at all to create standards to make it useful or interesting to developers. This is tragic.

Cache digest was ultimately aborted but this vector of thought- that the server & client can work together to figure out what to send- is a place that desperately needs research before it is discarded forever & cast aside. Eliminating the ability to experiment & try to find a way forwards is radically premature & unbelievably cry-into-palms tragic & messed up beyond words. We should not be here. Real change, on such a deep level, to the web, needs time to happen. Pulling the plug on this is not ok at all. This to me is ghastly & an unbelievably horrific & scary situation. Don't do this without a road map forward. Please. If there was any signs that things would get better, that's great, but right now you have very much staged this as pulling the plug, and that's horrific. We need more time to understand, to learn, to try to optimize. That progress is not up to your desired pace is not an OK sign for us to pull the plug on this core feature of HTTP. 

This feature got created in HTTP and then the web standards side failed entirely to do anything about it. This feature should be brought forward & supported on the web, which it never has been. Pulling the plug on it is not in any way OK or acceptable. Please do not injure the web like this. Provide a road map or intentions to support the HTTP again on the web with your web browser. Do not remove this, having never supported it adequately in the first place.


Samuel Williams

unread,
Nov 12, 2020, 12:13:08 AM11/12/20
to blink-dev, Ian Swett, blink-dev, Morgaine, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Jay Phelps
As someone who has implemented HTTP/2 push in both the client and server, I fully support this change and would like to see it deprecated from the RFCs. The complexity in both the client and the server is non-trivial, and the benefit has not been proven even in isolation.

The HTTP request/response model is well understood and lends itself to relatively sane client and server interfaces. The addition of server push extends clients and servers in an unnatural way, where a response can can potentially trigger more responses than the client was interested in. When you try to write code that handles this, the only abstraction that comes to mind is a queue:

response = client.request(path)
response.promises.each do |promise|
  add_to_cache(promise)
end
response.body.read # etc

But this is very unnatural to most users. Not to mention that this also invites issues around concurrency.

Browsers (and clients in general) are far better at knowing what resources they need. My experience has been that HTTP/2 push can only helps users on the first request. Looking at implementations like h2o, we see the extreme level of complexity required to try and avoid superfluous pushing. After the first request, the local browser has cached everything of interest, and from that point on HTTP/2 push does not serve any purpose as far as I can tell.

The level of complexity introduced by this feature does not balance out with the value it brings.

To repeat, I fully support this change.

Kind regards,
Samuel

Nick Sweeting

unread,
Nov 12, 2020, 12:13:08 AM11/12/20
to blink-dev, Morgaine, Ian Swett, blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Jay Phelps
I maintain an HTTP/2 server-push library for Django projects called https://github.com/pirate/django-http2-middleware.  When you enable the most aggressive mode, you can push all the static resources needed for the page's first paint above the fold (<100kb in our case) in 1RTT.  It provided noticeable gains for first-time visitors, which was the target demographic that mattered most for our situation.

We're no Google by any means, but It was effective enough that we've kept it turned on for our production site 30k users for 2+ years. As long as it's used sparingly, and only the *essential* resources are pushed, it's a useful tool in some situations. That being said if it's really such a burden for Chrome to maintain, can it be kept via a shim API on top of the infrastructure used for HTTP/3 push?

Jay Phelps

unread,
Nov 12, 2020, 12:13:08 AM11/12/20
to blink-dev, Ian Swett, Morgaine, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
We disagree with this decision based on the real world data we have seen and the products we build around Http/2 Push. Just making our objection known.

--
Jay Phelps
Outsmartly

On Wednesday, November 11, 2020 at 9:00:52 PM UTC-5 Ian Swett wrote:

Morgaine

unread,
Nov 12, 2020, 1:07:56 AM11/12/20
to blink-dev, Samuel Williams, Ian Swett, blink-dev, Morgaine, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Jay Phelps
far too early to call it. we just don't know what hte benefits are. the simple-minded "rely on the tried and tested" "well understood" idea sounds nice & fluffy, but we can not be so petrified of doing better.

works like cache-digest have only just begun to be explored. we can't cancel this entire realm of research, just because it's been a couple seasons since we realized the last attempt didn't work.

i challenge that it is way way way way way way way way way way way way too early to be making these kind of extremely harsh super brutal judgement calls. we need more time to understand & experiment. we can not kill this off so easily.

to repeat earlier sentiments, i think this is absolute gobsmackingly wrong & super brutal & meanspirited. absolutely not.

Yoav Weiss

unread,
Nov 12, 2020, 4:29:56 AM11/12/20
to Brad Lassey, blink-dev, dsch...@chromium.org, Bence Béky, ians...@chromium.org
I'm recusing myself from making a call here due to past affiliation and involvement, but I thought I'd chime in, with my API owner hat off.

My opinions haven't changed over the last few years, and I still think Push has (had?) potential.

At the same time, I believe Chrome's data shows that at the very least, it's being largely misused in the wild and in practice, not helping our users.
I don't think we *know* why and how it's often misused (is it lack of Cache Digests? People pushing the wrong things? H2 prioritization? Something else?), but investigating that seems like a non-trivial effort.
Weighing the opportunity vs. cost of doing that analysis and then acting on it (by tackling the related problems), the networking team's decision to invest their resources elsewhere (e.g. H3) is understandable.

I have hopes that experiments with Early Hints will prove beneficial, and will prove that they are able to tackle most of the use-case for Push, with reduced server complexity (and hence, with reduced chances of servers getting it wrong). They are not a perfect replacement, as they would start downloads 1 network RTT later than Push, but they also have benefits compared to Push (e.g. ability to preload CORS-fetched resources like fonts, which couldn't have been used when pushed, as well as cross-origin critical resources).
Early Hints are still prone to misuse in some of the same ways as Push (e.g. if people would be preloading the wrong things, instead of pushing them), but being aware of this potential issue may enable us to catch that in time this time around, before the misuse drowns the potential benefits.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjsk17dH_4W0Dsbhb1CRfh50tE7OdSTrZrRJ%2BmVbs8bKXjJww%40mail.gmail.com.

Brad Lassey

unread,
Nov 12, 2020, 8:40:48 AM11/12/20
to Nicolas DE MARQUE, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org


On Thu, Nov 12, 2020 at 8:22 AM Nicolas DE MARQUE <nic...@limengo.com> wrote:
Hello,

Frameworks and solutions using server push are just at the beginning of the testing phase. Server push can permit a real time application like with mercure, you can find a description here : 

https://symfony.com/blog/symfony-gets-real-time-push-capabilities
This is using SEE which is unrelated to HTTP/2 and gQuic Push. To be honest, I don't know what they're referring to with "connection-less push" but HTTP/2 and gQuic Push don't work without a connection. 

-Brad


Server push is not only for a better loading of the css and simples styles ans images resources. This is for the data resources that it can be a real new solution.

Brad Lassey

unread,
Nov 12, 2020, 9:23:10 AM11/12/20
to Nicolas DE MARQUE, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org


On Thu, Nov 12, 2020 at 8:54 AM Nicolas DE MARQUE <nic...@limengo.com> wrote:
Exact, sorry for the wrong link : it's vulcain another part of the api platform which used the server push  : https://github.com/dunglas/vulcain
For these sorts of use cases WebTransport is being developed which should meet the needs more directly. https://w3c.github.io/webtransport/ 


For the connection less, i'm not sure, i suppose that a identification mark (jwt) is exchanged and resend if the connection is lost.

Morgaine

unread,
Nov 12, 2020, 10:13:21 AM11/12/20
to blink-dev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
I am really really not looking forward to needing to run HTTP3 over HTTP3, because the user-agent doesn't implement HTTP3 features in a useful manner.

https://github.com/whatwg/fetch/issues/65%20and%20https://github.com/whatwg/fetch/issues/607 were both already pushing in that direction already, making PUSH no where near as useable as it should be, & getting no love or respect from any browser vendors quite very unfortunately.

This further shirking of the ability to let the server push resources is, I have to say, quite very unexpected. Last week, I could not have told you the situation could have gotten worse. This is impressively bad ends for an amazing feature that humanity needs more time, and that browser vendors needed to support a little better to let shine.

Morgaine

unread,
Nov 12, 2020, 10:16:13 AM11/12/20
to blink-dev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
This is the perfect use case for HTTP push, but alas, no one ever got around to building an api into fetch or other to let developers observe resources being pushed.

Rather than give the feature the short stick, the browser should try implementing a version of push that would help people like Vulcan do what they want to, which is push resources to the server, & then be able to respond to those changes.

Please see and design and implement:

Please don't break a wonderful, if unnecessarily/weirdly limited feature that was only 1/4 ever delivered to us.

Mirasoft GmbH & Co. KG

unread,
Nov 12, 2020, 10:35:34 AM11/12/20
to blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
We as portal operators have been waiting for years to finally use this feature. According to the discussions it is a chicken and egg problem.
Our backend (.net core) does not support this feature yet, so we cannot use server push yet. Now the feature should be put on the roadmap (see here), which is now in jeopardy, since the removal in Chrome is being discussed.
I consider this feature to be very useful and (for the website owner) quite easy to implement.

Sholto

unread,
Nov 12, 2020, 10:35:34 AM11/12/20
to blink-dev, Morgaine, Samuel Williams, Ian Swett, blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Jay Phelps
AWS CloudFront has only supported http/2 since late  2016, what's that 3.5 years for every server to change their app architecture to http/2?
Curious that you won't be supporting http/3,
I dunno, this all seems a bit odd.

Daniel Carosone

unread,
Nov 12, 2020, 10:35:34 AM11/12/20
to blink-dev, Morgaine, Samuel Williams, Ian Swett, blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Jay Phelps

If I'm building something where either side can initiate messages and content, I'll use websockets

Matīss Treinis

unread,
Nov 12, 2020, 10:35:58 AM11/12/20
to blink-dev, yo...@yoav.ws, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, las...@chromium.org
I am for this change - it's been years since server push was introduced and I rarely see it used in the wild - I suspect because the benefit is really quite marginal 9if any) and from my personal experience, not worth the effort to implement.

Bright Morning

unread,
Nov 12, 2020, 10:35:58 AM11/12/20
to blink-dev, yo...@yoav.ws, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, las...@chromium.org

Based on data and studies given, HTTP/2 push needs to change, and gQuic is a short-term work-around. However, the place to decide that change is not the browsers. Instead, it is the standards development organizations. And HTTP/3 has a solution. I am not saying browsers don't drive change, they often do. But, as a user and a developer, I would hope that continues to be done by (1) adding test features behind opt-in feature flags and then (2) submitting the design and test results to an SDO for discussion, refinement, and integration into an RFC or other spec. The place to change this is in the standard - push for it there, in another revision of the HTTP/3 internet draft.

This is one of those times where the technical considerations of the change take a back seat to the non-technical implications. Consider that we have been down this road before - the browser wars, where Internet Explorer, Chrome, and Opera all decided they were going to compete by adding their own features or changing existing ones. Usually it was done in the name of performance, sometimes in the name of new capability - but the users saw it as a race to supremacy, and the developers saw it as, well, hell. To quote Trinity, "You know that road. You know exactly where it ends. And I know that's not where you want to be."

Rob Belics

unread,
Nov 12, 2020, 10:35:59 AM11/12/20
to blink-dev, yo...@yoav.ws, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, las...@chromium.org
This sounds like wanting to remove push due to lack of usage and not lack of functionality. Is that right? I guess I'm the 1 that uses it and always assumed it was part of H2 and, next, H3 that makes things wonderful in the new world. Is this only a lack of educating developers?

Nicolas DE MARQUE

unread,
Nov 12, 2020, 10:36:17 AM11/12/20
to blink-dev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
Exact, sorry for the wrong link : it's vulcain another part of the api platform which used the server push  : https://github.com/dunglas/vulcain

For the connection less, i'm not sure, i suppose that a identification mark (jwt) is exchanged and resend if the connection is lost.

Le jeudi 12 novembre 2020 à 14:40:48 UTC+1, Brad Lassey a écrit :

Nicolas DE MARQUE

unread,
Nov 12, 2020, 10:36:17 AM11/12/20
to blink-dev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
It's a jws which is integrate in the Authentification header https://mercure.rocks/spec#authorization and https://tools.ietf.org/html/rfc7515

Le jeudi 12 novembre 2020 à 14:40:48 UTC+1, Brad Lassey a écrit :

Nicolas DE MARQUE

unread,
Nov 12, 2020, 10:36:18 AM11/12/20
to blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Hello,

Frameworks and solutions using server push are just at the beginning of the testing phase. Server push can permit a real time application like with mercure, you can find a description here : 

https://symfony.com/blog/symfony-gets-real-time-push-capabilities

Server push is not only for a better loading of the css and simples styles ans images resources. This is for the data resources that it can be a real new solution.

Le mercredi 11 novembre 2020 à 23:00:39 UTC+1, las...@chromium.org a écrit :

Anton Dorofeev

unread,
Nov 12, 2020, 11:41:28 AM11/12/20
to blink-dev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
> Almost five and a half years after the publication of the HTTP/2 RFC, server push is still extremely rarely used.

This is true. But it's not a reason to give up the idea. WebP is there for 10 years, since September 2010, and the usage is still below 0.5%!
https://w3techs.com/technologies/history_overview/image_format/all/y

However, there's a noticeable upcoming trend in search requests, people do google for WebP more often than before, and the trend started just couple years ago.

https://trends.google.com/trends/explore?date=today%205-y&q=webp

And WebP is way easier to integrate than something like HTTP/2 Push. WebP only requires browser support and good encoding software. I'd expect HTTP/2 Push to emerge massively only after following stages:
- spec is published (2015)
- browsers add support for receiving Pushed content (2016https://caniuse.com/http2
- popular edge HTTP servers (e.g., NGINX) add support for sending Pushes (2018https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/
- web frameworks / website engines add support for http/2 (2018-...)
- developers switch / upgrade their framework to new major versions that support push (we are here)

It's totally unfair to count from the moment when spec was published. Give it another 2-4 years, then we can talk about "no demand"!

I currently run a small early-stage startup, it offers zero coding website acceleration. We use lots of different techniques to speed up pages, and one of the most efficient is automated HTTP/2 Pushes that work with no changes on the server side (we automatically detect assets that need to be pushed). It works with any backend, because we don't rely on something like Link headers, and just detect assets that need to be pushed ourselves. Something like this could become a transition technology to let PUSHes takeoff. Right now our "push as a service" technology is beneficial for 99% of websites. In a few years, when more websites will upgrade to framework versions with built-in PUSH support, and part of our tool will become a niche solution, for legacy websites. Of course, if you guys don't kill this toddler technology sooner :)

Btw, we still run into issues with PUSHes, in 2020! There seems to be a bug somewhere in Golang http/2 implementation:
https://github.com/golang/go/issues/42534
https://groups.google.com/g/golang-nuts/c/CJwsb1H9mGg

Another reason to say that it's too early to judge about low demand! Let technologies grow mature first, then businesses will start using it.

Also, there's another good reason why devs did not implement it in 2017, and why they would in 2021. Google started pushing website owners to think about performance in 2018:
https://developers.google.com/web/updates/2018/07/search-ads-speed

My other business is a product company that offers a web widget for e-commerce websites, it adds UGC medias for their goods that have a significant impact on conversions. We run it since 2016. In 2016 and 2017 only our dev team did care about performance, and starting with 2018 it changed a lot, our old customers started asking about performance, and even buying 3rd party audits. 3 of 4 of our potential customers in 2019 asked about performance and page load time impact on pre-sell demo calls. Btw, we're adding PUSH support in the next release, and I'm not sure if it's possible to use preload instead, because it's an embeddable widget.

So, I claim that it wasn't possible to use Push before 2018, and it's not realistic to expect massive use in 2020. Because yes, it's a tricky technology, and it's a process for the industry to get it adopted on all levels.

And last thing to note - HTTP/2 Push as a selling feature for HTTP/2. It's easy to get what it does, it adds obvious benefit to business, and is easy for developer to sell it to a supervisor manager. It's fun. You can enable it and see it working in developer tools. Devs like it and write articles about this technology:
https://medium.com/@nikita.malyschkin/the-future-of-web-deployment-without-bundlers-or-compromises-es-modules-nodejs-and-http-2-push-3ab3ce25a36b

Kévin Dunglas

unread,
Nov 12, 2020, 11:41:28 AM11/12/20
to blink-dev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
Hi!

Vulcain and Mercure maintainer here.

Indeed Mercure doesn't rely on Server Push at all (it relies on Server Sent Events), and it will not be impacted by this change. "Connection-less" push is a capability provided by SSE. The spec allows the carrier to use a lower level mobile protocol to route the event to the device: https://html.spec.whatwg.org/multipage/server-sent-events.html#eventsource-push
AFAIK, this feature is not widely implemented (and is probably not compatible with HTTPS).

However Vulcain relies a lot on HTTP/2 Server Push. This specification is dedicated to web APIs (REST / hypermedia). It allows to use Server Push as an alternative to GraphQL-like compound documents. The main idea is to reduce the latency introduced by a traditional, atomic, REST-like API. When following this style, each document has a dedicated URL and the client needs to download and to parse the response associated with the first URL before requesting its relations. This introduces latency, and if the client needs to retrieve a graph of resources, this creates a waterfall effect.
Vulcain fixes this latency problem by pushing all the relations needed by the client in response to the explicit HTTP request.

The main benefits of this approach over creating compound documents (GraphQL, JSON:API's include...) are:
  • the ability to send several documents in parallel in different HTTP streams (multiplexing)
  • a better hit rate if you use a HTTP cache layer (because you have several small atomic documents with their own URLs, instead of a big document containing everything and that will have to be invalidated frequently)
  • the ability to leverage the semantic of HTTP for each resource: authorization, content negotiation and of course cache
  • it's usually simpler for the API developer to implement and secure (small documents, no embedding, no nesting...)
According to our benchmarks, using this strategy allows to be as fast as using compound documents (and sometimes faster, because of multiplexing).

Vulcain already supports using Preload links instead of Server Push. The reverse proxy we provide (which implements the spec, built on top of Caddy Server) does it automatically when Server Push is disabled.
Using Preload links increases (a bit) the latency compared to using Server Push but on the other hand this also improves caching: the browser never requests a resource if it already has it. With Server Push - because Cache Digest has never been finished and implemented - the server starts pushing all relations. It doesn't known if the browser already has this resource in cache or not. The browser cancels the push early if it already has the resource in cache, but some server power and some bandwidth are wasted. Using preload hints also decreases the complexity and removes some limitations of common web servers regarding which headers are copied in Server Push requests: https://github.com/w3c/preload/pull/149

Using Preload links with Vulcain would benefit from Early Hints (the 103 status code). Early Hints will reduce the latency compared to waiting for all headers to be ready. This will still be 1 additional RTT compared to Server Push, but the removed complexity is maybe worth it.

Unfortunately, unlike Server Push, Early Hints are not supported at all by the ecosystem (Chrome, Firefox, the Go language... none of these tools support them). Server Push works right now, even if the lack of bloom filter is annoying. Server Push is already implemented by all modern browsers, Go, NGINX, Apache, Caddy...

Regarding WebTransport, it's not implemented by the ecosystem either, and it's too low level to be really useful in our case. One strength of Vulcain (and of Server Push) is that using it is totally transparent for the frontend developer. You don't have to install a JS lib or something like that. You use the primitives provided by the browser such as fetch and it works.

Maybe a good compromise could be to not remove Server Push until Early Hints are implemented at least in Chrome?

I summarized this post in a Twitter thread: https://twitter.com/dunglas/status/1326552735404060672

Best regards,

Jon Wu

unread,
Nov 12, 2020, 2:30:47 PM11/12/20
to blink-dev, Anton Dorofeev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
I agree with Anton's sentiment that Google has recently put more of an emphasis and incentive for improving performance in terms of ads and SEO.

Anton Dorofeev wrote:
Also, there's another good reason why devs did not implement it in 2017, and why they would in 2021. Google started pushing website owners to think about performance in 2018:
https://developers.google.com/web/updates/2018/07/search-ads-speed
...

So, I claim that it wasn't possible to use Push before 2018, and it's not realistic to expect massive use in 2020.

Up until recently, you could have a pretty fast initial load without worrying about push, but given that Google will start using Core Web Vitals (including cumulative layout shift) as a ranking signal in 2021, Lighthouse recommends display: swap, and fonts that aren't downloaded yet and are using display: swap cause FOUT (flash of unstyled text) and a layout shift, push becomes more important. The recommendation to preload helps, but still results in more shifts overall and a longer FOUT.

On our site, we saw a significant reduction in first visit font load times and therefore layout shift after proxying and pushing fonts, using Cloudflare's Fast Google Fonts with Cloudflare Workers blog post as inspiration. Admittedly, this wasn't very simple, and you have to add some logic to not wastefully push fonts on future page views, so I can definitely see how complexity is an issue, even without taking the browser or server into consideration. However, it just feels like the tooling needs to catch up.

Evert Pot

unread,
Nov 12, 2020, 6:15:58 PM11/12/20
to blink-dev, Jon Wu, Anton Dorofeev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
My take: https://evertpot.com/http-2-push-is-dead/

tl;dr:: Sad this is going away. This feature has great potential but needed more work to be truly useful anyway.

Kinuko Yasuda

unread,
Nov 13, 2020, 1:59:16 AM11/13/20
to Kévin Dunglas, blink-dev, Brad Lassey, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
On Fri, Nov 13, 2020 at 1:41 AM Kévin Dunglas <ke...@dunglas.fr> wrote:
Hi!

Vulcain and Mercure maintainer here.

Indeed Mercure doesn't rely on Server Push at all (it relies on Server Sent Events), and it will not be impacted by this change. "Connection-less" push is a capability provided by SSE. The spec allows the carrier to use a lower level mobile protocol to route the event to the device: https://html.spec.whatwg.org/multipage/server-sent-events.html#eventsource-push
AFAIK, this feature is not widely implemented (and is probably not compatible with HTTPS).

However Vulcain relies a lot on HTTP/2 Server Push. This specification is dedicated to web APIs (REST / hypermedia). It allows to use Server Push as an alternative to GraphQL-like compound documents. The main idea is to reduce the latency introduced by a traditional, atomic, REST-like API. When following this style, each document has a dedicated URL and the client needs to download and to parse the response associated with the first URL before requesting its relations. This introduces latency, and if the client needs to retrieve a graph of resources, this creates a waterfall effect.
Vulcain fixes this latency problem by pushing all the relations needed by the client in response to the explicit HTTP request.

The main benefits of this approach over creating compound documents (GraphQL, JSON:API's include...) are:
  • the ability to send several documents in parallel in different HTTP streams (multiplexing)
  • a better hit rate if you use a HTTP cache layer (because you have several small atomic documents with their own URLs, instead of a big document containing everything and that will have to be invalidated frequently)
  • the ability to leverage the semantic of HTTP for each resource: authorization, content negotiation and of course cache
  • it's usually simpler for the API developer to implement and secure (small documents, no embedding, no nesting...)
According to our benchmarks, using this strategy allows to be as fast as using compound documents (and sometimes faster, because of multiplexing).

Vulcain already supports using Preload links instead of Server Push. The reverse proxy we provide (which implements the spec, built on top of Caddy Server) does it automatically when Server Push is disabled.
Using Preload links increases (a bit) the latency compared to using Server Push but on the other hand this also improves caching: the browser never requests a resource if it already has it. With Server Push - because Cache Digest has never been finished and implemented - the server starts pushing all relations. It doesn't known if the browser already has this resource in cache or not. The browser cancels the push early if it already has the resource in cache, but some server power and some bandwidth are wasted. Using preload hints also decreases the complexity and removes some limitations of common web servers regarding which headers are copied in Server Push requests: https://github.com/w3c/preload/pull/149

Using Preload links with Vulcain would benefit from Early Hints (the 103 status code). Early Hints will reduce the latency compared to waiting for all headers to be ready. This will still be 1 additional RTT compared to Server Push, but the removed complexity is maybe worth it.

Unfortunately, unlike Server Push, Early Hints are not supported at all by the ecosystem (Chrome, Firefox, the Go language... none of these tools support them). Server Push works right now, even if the lack of bloom filter is annoying. Server Push is already implemented by all modern browsers, Go, NGINX, Apache, Caddy...

As is mentioned in the intent, there's some ongoing measurement so that the potential impact of Early Hints can be evaluated in Chrome.  If you think this feature can be a potential replacement, participating in this and starting to send Early Hints could help us and the ecosystem measure more data. (Doing so should virtually have no side-effects for now but would allow browsers and ecosystem to evaluate more)
 
Regarding WebTransport, it's not implemented by the ecosystem either, and it's too low level to be really useful in our case. One strength of Vulcain (and of Server Push) is that using it is totally transparent for the frontend developer. You don't have to install a JS lib or something like that. You use the primitives provided by the browser such as fetch and it works.

WebTransport is being actively developed in Chrome and discussion is happening with the community, you're right that it's relatively low level but I'm expecting that this will start to have more support by the ecosystem. Your feedback on the spec will be also awaited here: 
https://github.com/w3c/webtransport
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Kévin Dunglas

unread,
Nov 13, 2020, 6:48:04 AM11/13/20
to Jean Boussier, blink-dev, Kinuko Yasuda, Brad Lassey, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
> As is mentioned in the intent, there's some ongoing measurement so that the potential impact of Early Hints can be evaluated in Chrome.  If you think this feature can be a potential replacement, participating in this and starting to send Early Hints could help us and the ecosystem measure more data. (Doing so should virtually have no side-effects for now but would allow browsers and ecosystem to evaluate more)

The Vulcain specification already recommends to use Early Hints when Server Push isn't available. However, the open source reverse proxy we provide doesn't implement Early Hints because it is written in Go, and even the Go HTTP server (which is very popular and supported by Google) has no support for 1XX status codes yet: https://github.com/golang/go/issues/36734#issuecomment-684799300

Also, in our case, even if Go had support for the 103 status code, and even if we implemented it in our reverse proxy, almost no clients would receive Early Hints because the 103 status code is only a fallback in case Server Push isn't supported, and currently all modern browsers - including Chrome - support Server Push.


On Fri, Nov 13, 2020 at 10:11 AM Jean Boussier <jean.b...@shopify.com> wrote:
> As is mentioned in the intent, there's some ongoing measurement so that the potential impact of Early Hints can be evaluated in Chrome.  If you think this feature can be a potential replacement, participating in this and starting to send Early Hints could help us and the ecosystem measure more data. (Doing so should virtually have no side-effects for now but would allow browsers and ecosystem to evaluate more)

I do think Early Hints are the far superior solution because they are infinitely simpler to implement and they properly leverage the browser cache. That's why I did the work to add support for it in various Ruby/Rails ecosystem tools.

However I think that this data oriented experiment is kind of doomed from the start. I got a lot of push back from various players (inside my org, and in the open source community) from experimenting with it because:

  - They do not provide any gains whatsoever today. 
  - If deployed incorrectly they might breaks older browsers.

So it is seen as a risky investment that is unlikely to yield anything any time soon. So nobody want's to do the first move.

I know this thread is more about Server Push, but if you want Early Hints to be an alternative, Chrome has to actually implement them.

Jean Boussier

unread,
Nov 13, 2020, 12:13:25 PM11/13/20
to blink-dev, Kinuko Yasuda, blink-dev, Brad Lassey, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE, ke...@dunglas.fr
> As is mentioned in the intent, there's some ongoing measurement so that the potential impact of Early Hints can be evaluated in Chrome.  If you think this feature can be a potential replacement, participating in this and starting to send Early Hints could help us and the ecosystem measure more data. (Doing so should virtually have no side-effects for now but would allow browsers and ecosystem to evaluate more)

Lenny Primak

unread,
Nov 13, 2020, 6:57:17 PM11/13/20
to blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
I want to add to the chorus of not removing HTTP/2 push support. Just because currently the usage is low, it doesn't mean the feature is not useful,
and given time and effort by the community, I believe it will speed up the web considerably once more servers support it out of the box.

Aman Nanner

unread,
Nov 16, 2020, 5:54:55 PM11/16/20
to blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org

In reference to the Akamai study that was published last year, I disagree with the characterization presented here that its conclusion was, "HTTP/2 either does not change performance or improves performance marginally when used with certain restrictions". The study did in fact show that Server Push provided a non-marginal benefit (improvements of hundreds of milliseconds to DocTime) to a set of Akamai customer web sites when the quantile of 1% overall slowest responses was excluded from the set.

I agree with the comments in regard to the implementation complexity of Server Push; I know that Akamai had made some significant efforts in optimizing the Server Push implementation on the server. It feels like that continued effort and investment in Server Push would have heralded further optimizations and improvements in both client-side and server-side implementations as the broader community gained more experience with it.

Early Hints + Preload could be an interesting replacement to Server Push, and while simpler in terms of implementation complexity, it's not quite the same in that there is a loss of a roundtrip in sending back data and it may not cover exactly the same set of use cases that Server Push is covering. In the end, it's the performance that matters, and it is possible that Early Hits + Preload could provide equivalent performance. I think some of us have actually viewed Early Hints + Preload to be complementary to Server Push, rather as something that is mutually exclusive.

There is another performance study underway in Akamai on Server Push usage, but with focus on Core Web Vitals as the framework of measurement. I'm not sure on the timing quite yet of when it will be released, but we can report the results when completed.

A major issue here is that an aggressive disablement of Server Push in Chromium will result in a large "gap" of time between when Server Push is no longer available, and when Early Hints support will be available and adopted. If Early Hints were already available now, this would make a transition more palatable and we would not be leaving performance on the table with nothing to replace it.

If the removal of Server Push support in Chromium is inevitable, then our request would be that the disabling of Server Push on HTTP/2 to occur a few months after Early Hints is fully implemented and deployed in Chrome (i.e. not behind any experimental flags). This would allow time for organizations that are successfully leveraging Server Push to migrate to a new solution.

Mi Tar

unread,
Nov 19, 2020, 12:33:48 PM11/19/20
to blink-dev, ke...@dunglas.fr, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Nicolas DE MARQUE
Hi!

I love Vulcan and its approach to API. I think it solves a fundamental problem which is otherwise solved by embedding related resources into a response, which makes all sorts of troubles (you cannot embed binary data like that, you cannot take advantage of caching, etc.). Another API spec, Braid, currently being drafted, also assumes Server Push will be around (https://github.com/braid-work/braid-spec).

I am curious, has those measurements/data take into the account API-based requests? Akamai report seems to be focusing only on HTML requests/responses? Also Chrome experiment (https://chromium.googlesource.com/chromium/src/+/master/docs/early-hints.md) looks like measuring effect of Early Hints on page load and not API requests which might happen during the life of the page? So maybe Server Push was meant to solve the issue of related HTML content, but maybe it is turning out to be a solution for simpler HTTP APIs?

Because even with cache digests, Server Push works better than embedding inside responses: for embedding you always have to transfer whole response contents, for Server Push clients can cancel cached responses. In the worst case you end up with same amount of data as if you would embed, but with, ideally, multiplexed transfer, so still better.

I do not believe Early Hints can help with API requests, because you still first have to make a database query before you can issue Early Hints. For HTML pages you might know in advance which JavaScript or CSS bundle you will anyway want the client to fetch. But for API requests you have to first do the query to discover related resources and then you can send something to the client. Which means that regular Preload links are probably what you need. And Preload links are adding one additional RTT in comparison with Server Push (not to mention that those Preload-based requests will probably force another hit of the database, while for Server Push you might have data already ready to send).

WebTransport does not look like a solution to me for API cases, because caching seems to be out of its scope. And caching is where you get advantage of Server Push over embedding.

So I do not see really any good alternatives to Server Push when thinking about current and future HTTP-based APIs and minimizing latency, maximizing caching, and simplifying those APIs.


Mitar

Ben Lesh

unread,
Dec 2, 2020, 2:43:22 PM12/2/20
to blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Perhaps this is covered elsewhere in this thread.. and it might be a really stupid question... But will this effect getting multiple streaming responses with `fetch` over a single TCP connection?

To clarify, if I'm using JavaScript to programmatically `fetch` multiple streams of data (streaming them out of `response.body`), will all of those streams still be over a single TCP connection? Or will that go away?

This is something I'm looking at trying (experimentally) and I want to know if anything about this decision is going to change what I want to try to use down the road. (There's probably other limitations to this idea I'm not aware of or didn't think of).

On Wednesday, November 11, 2020 at 4:00:39 PM UTC-6 las...@chromium.org wrote:

Avamander /

unread,
Dec 3, 2020, 1:06:24 PM12/3/20
to blink-dev, Ben Lesh, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Given the relative freshness of this feature and how implementations in back-end libraries have slowly trickled into existence, it seems very premature.

Mitar

unread,
Dec 9, 2020, 11:28:35 AM12/9/20
to Avamander /, blink-dev, Ben Lesh, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Hi!

I just noticed that while Chromium is planning to deprecate HTTP/2
server push, Google itself has just recently announced support for
HTTP2/ for its crawling bot:

https://developers.google.com/search/blog/2020/09/googlebot-will-soon-speak-http2

I think this shows that it really takes time for such technology like
HTTP/2 to be integrated with all parts of the web. Which holds even
more for server push.

One more thing to consider. <link rel="preload"> and Early Hints do
not allow one to provide custom headers (e.g., access token in
Authorization header) to be used when (pre)fetching those resources.
As such those approaches seem to be useful mostly for public/static
content and not so much for APIs trying to push related data.


Mitar

Mike West

unread,
Dec 17, 2020, 3:19:44 PM12/17/20
to blink-dev, mmi...@gmail.com, blink-dev, Ben Lesh, Brad Lassey, dsch...@chromium.org, Bence Béky, ians...@chromium.org, Avamander /
Hey folks,

There's been a good deal of feedback on this thread and elsewhere, and it seems like the team needs to take that into consideration and respond to it. Given that, the API owners consider this intent to be on hold, and look forward to further conversation.

-mike

Brad Lassey

unread,
Dec 22, 2020, 4:13:18 PM12/22/20
to Ben Lesh, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
On Wed, Dec 2, 2020 at 1:57 PM Ben Lesh <b...@benlesh.com> wrote:
Perhaps this is covered elsewhere in this thread.. and it might be a really stupid question... But will this effect getting multiple streaming responses with `fetch` over a single TCP connection?

To clarify, if I'm using JavaScript to programmatically `fetch` multiple streams of data (streaming them out of `response.body`), will all of those streams still be over a single TCP connection? Or will that go away?
No, this is unrelated. We are only talking about deprecating server-pushed streams. Any interaction where the client is initiating the request is unaffected. In fact, the fetch spec (https://fetch.spec.whatwg.org/) doesn’t even mention Push. 

Brad Lassey

unread,
Dec 22, 2020, 4:18:35 PM12/22/20
to Lenny Primak, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
On Fri, Nov 13, 2020 at 4:43 PM Lenny Primak <lenny...@gmail.com> wrote:
I want to add to the chorus of not removing HTTP/2 push support. Just because currently the usage is low, it doesn't mean the feature is not useful,
and given time and effort by the community, I believe it will speed up the web considerably once more servers support it out of the box.

Push has been available in Apache for 5 years and Chrome for more than 6 years. We think this has given plenty of time for the ecosystem to adopt
Looking at the most common servers according to https://w3techs.com/technologies/overview/web_server, they all support push:

Lenny Primak

unread,
Dec 22, 2020, 6:03:41 PM12/22/20
to Brad Lassey, Lenny Primak, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Hi, Brad,

Thanks for your well-researched (and lengthy!) response.
I do realize that most servers have the feature included, and included for a while. However, none of them make it
easy to use, have well-written documentation, tutorials, etc.
The feature is simple not on may people’s radars. It’s really in “stealth” mode now.
As you know, web development ecosystem is really still in infancy and people have much better things to do than optimize for server push,
especially if it isn’t straightforward or easy.
Most web frameworks don’t support push out-of-the-box these days, and do not have it documented nor easily implementable.
This is the reason push is not widely used currently.
I really feel that push needs more support, work, marketing and TLC rather than removing it.

Morgaine

unread,
Dec 23, 2020, 10:25:17 PM12/23/20
to blink-dev, Brad Lassey, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Ben Lesh
As I stated in the very first reply to this thread, it is a horrific tragedy that the situation is like this. It's been HALF A DECADE OF IGNORING DEVELOPERS on https://github.com/whatwg/fetch/issues/65 and https://github.com/whatwg/fetch/issues/607 , who have begged for fetch to support push, have BEGGED, & gotten no where. To say that the fetch spec does not mention push is to spit in our faces. This is farce & tragedy. Perhaps it's only ignorance you speak from, but I can not be more hurt to hear you say this. I have repeated time & time again in countless threads the desires for fetch to PLEASE FOR THE LOVE OF GOD support fetch. It's insulting that there has been zero progress.

Brad Lassey

unread,
Dec 30, 2020, 2:11:31 PM12/30/20
to Morgaine, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, Ben Lesh
On Wed, Dec 23, 2020 at 10:25 PM Morgaine <rek...@gmail.com> wrote:
As I stated in the very first reply to this thread, it is a horrific tragedy that the situation is like this. It's been HALF A DECADE OF IGNORING DEVELOPERS on https://github.com/whatwg/fetch/issues/65 and https://github.com/whatwg/fetch/issues/607 , who have begged for fetch to support push, have BEGGED, & gotten no where. To say that the fetch spec does not mention push is to spit in our faces. This is farce & tragedy. Perhaps it's only ignorance you speak from, but I can not be more hurt to hear you say this. I have repeated time & time again in countless threads the desires for fetch to PLEASE FOR THE LOVE OF GOD support fetch. It's insulting that there has been zero progress.
I am sorry that my words had this effect on you. I believe the use cases that you've articulated are being addressed with WebTransport (https://github.com/w3c/webtransport/). If you don't believe so, can you file issues there to make sure they are properly considered?

-Brad

Brad Lassey

unread,
Dec 30, 2020, 2:38:48 PM12/30/20
to Lenny Primak, Lenny Primak, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
On Tue, Dec 22, 2020 at 6:03 PM Lenny Primak <lpr...@hope.nyc.ny.us> wrote:
Hi, Brad,

Thanks for your well-researched (and lengthy!) response.
I do realize that most servers have the feature included, and included for a while. However, none of them make it
easy to use, have well-written documentation, tutorials, etc.
The feature is simple not on may people’s radars. It’s really in “stealth” mode now.
As you know, web development ecosystem is really still in infancy and people have much better things to do than optimize for server push,
especially if it isn’t straightforward or easy.
Most web frameworks don’t support push out-of-the-box these days, and do not have it documented nor easily implementable.
This is the reason push is not widely used currently.
I really feel that push needs more support, work, marketing and TLC rather than removing it.
Hi Lenny,
I'll disagree with you that these server implementations are not easy to use or well documented. All of the links in my previous post to the various implementations describe how to use it quite clearly, save for the IIS one where the documentation is one link away. In cloudflare's case, existing use of preload got you push and you had to opt-out of that with the nopush declaration. But, I'll also admit that this is purely a difference of opinion.

What isn't a difference of opinion though is that the usage of push peaked in 2018 and has been trending down since then. If Push just needed more time for adoption we'd expect to see it's usage trending up or at least holding steady. Instead we've seen the usage drop steadily and precipitously over the course of the last 2+ years. There is no indication in the data that more time will change that, but as Ian stated up thread in November and I said when we presented at the IETF in 2018, we would love to see data that makes a convincing counter argument.

-Brad

Lenny Primak

unread,
Dec 30, 2020, 4:16:04 PM12/30/20
to Brad Lassey, Lenny Primak, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Thanks, Brad,

I obviously do not have the data that Google has, but I can speak about the little corner of web clients I do see.
People I deal with mostly run a 5-year old version of Apache, PHP and WordPress. Other than that,
I see smattering of HubSpot, Weebly, SquareSpace, etc.

None of those frameworks enable push by default, and it’s because it’s (IMHO) not easy.
In order to get the data to tick up, major infrastructure vendors must enable push by default,
and then, wait for their customers to upgrade to more current versions of the systems.
As you can imagine, this could take years.

Personally, I have no real dog in this game, but the reason I am even active in this discussion is because I personally
develop in JSF and PrimeFaces. JSF w/PrimeFaces enables server push by default, and does it correctly, out-of-the-box.
I have seen the difference in page loads, and it’s orders of magnitude better just by looking at it (without even measuring)

Thus, again IMHO, push has not been given a half of a chance to work.
I believe what’s needed is more marketing and ease of use improvements for push, not a shut-down.

Brad Lassey

unread,
Dec 30, 2020, 4:19:24 PM12/30/20
to Lenny Primak, Lenny Primak, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
On Wed, Dec 30, 2020, 4:16 PM Lenny Primak <lpr...@hope.nyc.ny.us> wrote:
Thanks, Brad,

I obviously do not have the data that Google has, but I can speak about the little corner of web clients I do see.
People I deal with mostly run a 5-year old version of Apache, PHP and WordPress. Other than that,
I see smattering of HubSpot, Weebly, SquareSpace, etc.

None of those frameworks enable push by default, and it’s because it’s (IMHO) not easy.
In order to get the data to tick up, major infrastructure vendors must enable push by default,
and then, wait for their customers to upgrade to more current versions of the systems.
As you can imagine, this could take years.

Personally, I have no real dog in this game, but the reason I am even active in this discussion is because I personally
develop in JSF and PrimeFaces. JSF w/PrimeFaces enables server push by default, and does it correctly, out-of-the-box.
I have seen the difference in page loads, and it’s orders of magnitude better just by looking at it (without even measuring)
Hi Lenny,
Do you have data you can share showing this?

-Brad

Lenny Primak

unread,
Dec 30, 2020, 4:20:35 PM12/30/20
to Brad Lassey, Lenny Primak, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Unfortunately no, this is my qualitative opinion, as even if I had any data, it would be a drop in the bucket.

Brad Lassey

unread,
Jan 19, 2021, 8:26:29 AMJan 19
to Denis TRUFFAUT, blink-dev, Lenny Primak, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Hi Denis,
HTTP/2 Push isn't really related to Service Workers and adoption of Service Workers isn't a gating function for adoption of Push.

-Brad


On Sun, Jan 17, 2021 at 1:44 AM Denis TRUFFAUT <denis.t...@gmail.com> wrote:
Synergy with Service Workers
Correct me if I'm wrong, but the intended scheme for Server Push is :
  1. Client with no SW asks Server for index.html
  2. Server answers index.html + push all resources through prefetch -> Link:  <sw.mjs>;rel=prefetch;as=script;type=module  ...
  3. Client download resources, activate SW
  4. Client is now SW controlled, and never again hit the server
  5. Later on, sw.mjs change (update published)
  6. Client download only new files
It is perfectly fine, and works like a charm in this scenario.

Benchmarks
If Server push is not widely used, it is mainly because the optimal scheme is bound to the comprehension and adoption of Service Workers. Moreover, I don't think the benchmarks of Akamai & co are able to highlight this level of precision, they are biased because being Cloud providers, and administrating servers as their main activity, they take only into account the server side, and forget the client side. I'm pretty sure zero benchmark took into account the synergy { Server push + Service Worker }.

Conclusion
The technology itself is amazing.
Keep it.

Denis TRUFFAUT

unread,
Jan 19, 2021, 12:47:15 PMJan 19
to blink-dev, Lenny Primak, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org, las...@chromium.org
Synergy with Service Workers
Correct me if I'm wrong, but the intended scheme for Server Push is :
  1. Client with no SW asks Server for index.html
  2. Server answers index.html + push all resources through prefetch -> Link:  <sw.mjs>;rel=prefetch;as=script;type=module  ...
  3. Client download resources, activate SW
  4. Client is now SW controlled, and never again hit the server
  5. Later on, sw.mjs change (update published)
  6. Client download only new files
It is perfectly fine, and works like a charm in this scenario.

Benchmarks
If Server push is not widely used, it is mainly because the optimal scheme is bound to the comprehension and adoption of Service Workers. Moreover, I don't think the benchmarks of Akamai & co are able to highlight this level of precision, they are biased because being Cloud providers, and administrating servers as their main activity, they take only into account the server side, and forget the client side. I'm pretty sure zero benchmark took into account the synergy { Server push + Service Worker }.

Conclusion
The technology itself is amazing.
Keep it.
Le mercredi 30 décembre 2020 à 22:20:35 UTC+1, Lenny Primak a écrit :

Kinuko Yasuda

unread,
Jan 21, 2021, 6:49:43 PMJan 21
to Brad Lassey, Denis TRUFFAUT, blink-dev, Lenny Primak, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Hi,

Just wanted to chime in again, Chrome is planning to start implementing Early Hints soonish (we'll start a separate Intent thread).  I can't say the definite timeline but we're expecting that we have a working implementation sometime early this year, so that people who might be interested in replacing Push with EH can experiment with it.  Hope this helps the situation!


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Lenny Primak

unread,
Jan 21, 2021, 6:59:30 PMJan 21
to Kinuko Yasuda, Brad Lassey, Denis TRUFFAUT, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Ok, and how long is that going to last? 6 months? 3? 
Push is plenty good and should be continued, instead of starting a new unknown tech that does the same thing.

Kinuko Yasuda

unread,
Jan 21, 2021, 7:17:26 PMJan 21
to Lenny Primak, Brad Lassey, Denis TRUFFAUT, blink-dev, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
On Fri, Jan 22, 2021 at 8:59 AM Lenny Primak <lpr...@hope.nyc.ny.us> wrote:
Ok, and how long is that going to last? 6 months? 3? 
Push is plenty good and should be continued, instead of starting a new unknown tech that does the same thing.

I don't think having a minimum working code takes very long, but we will update when we have a more clear timeline.

It's not a new unknown tech, it's been a RFC since like 2017, as you probably know, and what it does is not the same thing but can achieve a similar effect with one more RTT in some use cases.  What I meant to say was it'd be useful if it becomes experimentable when it's discussed as one of alternative technologies, and thought that it should be shared on this thread too.

Bence Béky

unread,
Jan 26, 2021, 10:46:09 AMJan 26
to Aman Nanner, blink-dev, las...@chromium.org, dsch...@chromium.org, ians...@chromium.org
Hi Aman,

Sorry for misstating the conclusion of the Akamai studies.

Our major argument for removing push is that it does not provide a performance win for Chrome's users overall.  This is in part due to the very low adoption rate.  I disagree with the sentiment expressed on this thread that the ecosystem needs more time to adopt push: push usage has not changed significantly over the past two years (when measured as the proportion of HTTP/2 connections that carry any pushed streams), and the proportion of useful pushed streams has dropped significantly.  The lack of upward trend multiple years after the publication of the HTTP/2 specs and implementation by most major servers and clients makes me very pessimistic about seeing significant increase in adoption in the future.

Also, even for the small number of sites using push, our analysis shows that push results in a minor performance degradation when looking from Chrome users' perspective.  The results were presented at IETF102.  Of course the two studies, Akamai's and Chrome's, do not contradict each other: the latter includes all sites Chrome users visited (that received enough traffic and were known to push), whereas the former was limited to the ones served by Akamai to Chrome.  Also, slightly different metrics were used.  The different results just indicate that the effect of server push varies by site, and different server implementations might result in different affects.  You convinced me that for certain sites server push is a performance win, but since in reality these sites receive a very small proportion of Chrome's user traffic, I still don't believe it is worth the cost for Chrome to keep the implementation around.

I cannot disprove that "continued effort and investment in Server Push would have heralded further optimizations and improvements".  However, it is important to recognize that a fair bit of work has gone into push by many companies and individuals over the last more than six years and it is still a net performance negative for Chrome users.  I argue that this indicates the inherent difficulty of the problem, and at this point it makes sense to allocate resources, both of Chrome and of other network software developers, to other performance optimizations.  I would like to avoid falling victim to the sunk cost fallacy.  I think an important point of disagreement on this thread is about how much more effort would be required to make server push a net performance win.

Because push is a net performance loss for Chrome users and is very rarely used anyway, I believe that it would be beneficial to remove support from Chrome, regardless of the implementation status of Early Hints.

Cheers,

Bence

Ryan Hamilton

unread,
Feb 3, 2021, 3:11:20 PMFeb 3
to blink-dev, Bence Béky, blink-dev, Brad Lassey, dsch...@chromium.org, ians...@chromium.org, Aman Nanner, ekin...@apple.com, guoye...@apple.com, ryan_c_...@apple.com
+Eric and Guoye from Apple.

Guoye Zhang

unread,
Feb 3, 2021, 4:06:37 PMFeb 3
to Ryan Hamilton, blink-dev, Bence Béky, Brad Lassey, dsch...@chromium.org, ians...@chromium.org, Aman Nanner, Eric Kinnear, Ryan Hamilton
Looking at WebKit's usage, as well as general HTTP usage on Apple platforms, we're seeing roughly 0.01% of resources fetched using server push, although I don't think we've dug into any performance delta experienced by those resources nearly as much as others in this conversation.

We are also aware of issues around wasted bandwidth since a server has no knowledge of client caching state. Additionally, early beta versions of Low-Latency HTTP Live Streaming (LLHLS) adopted server push to reduce latency, but ultimately used Blocking Preload Hints (hanging GETs) due to a number of factors, one of them being incompatibility with some CDN architectures.

Removing server push support would reduce maintenance burden, as it doesn't appear to provide significant benefit for end users.

That said, we'd be interested in experimenting with options to provide a real user benefit in this area, even if those options aren't server push.

- Guoye Zhang

Henry Price

unread,
Feb 10, 2021, 11:30:46 AMFeb 10
to blink-dev, las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org
Thank you for providing an update on this!

I can't see any information for when this will happen, Is there a confirmed date for when this would go ahead?

Morgaine

unread,
Feb 10, 2021, 1:07:57 PMFeb 10