Intent to Remove: HTTP/2 and gQUIC server push

[Brad Lassey]

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]

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]

HTTP Pipelining all over again.

[Ian Swett]

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]

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]

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.

[1] https://github.com/whatwg/fetch/issues/65

[2] https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-05

[Samuel Williams]

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]

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]

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]

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]

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]

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]

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]

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]

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:

https://github.com/whatwg/fetch/issues/65

https://github.com/whatwg/fetch/issues/607

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

[Mirasoft GmbH & Co. KG]

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]

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]

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

[Matīss Treinis]

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]

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]

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]

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]

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]

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]

> 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 (2016) https://caniuse.com/http2
- popular edge HTTP servers (e.g., NGINX) add support for sending Pushes (2018) https://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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cdd151dd-beba-480a-aa15-c0c7d81089a4n%40chromium.org.

[Kévin Dunglas]

> 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]

> 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]

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]

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.