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.

[Mi Tar‏]

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

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

Given the relative freshness of this feature and how implementations in back-end libraries have slowly trickled into existence, it seems very premature.

[Mitar‏]

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

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

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

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:

• Apache supports push https://httpd.apache.org/docs/2.4/mod/mod_http2.html#h2push since version 2.4.18 released 22 Dec 2015 http://mail-archives.apache.org/mod_mbox/httpd-announce/201512.mbox/%3C06F0486F-683E-443...@apache.org%3E
• Nginx supports push since NGINX 1.13.9 released February 20, 2018 https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/
• Cloudflare supports push April 28, 2016 https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/
• LiteSpeed supports push https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:server_push since version 5.2 released 7-11-2017 https://www.litespeedtech.com/products/litespeed-web-server/release-log-archive
• Microsoft IIS supports push https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis since 09/16/2016

[Lenny Primak‏]

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

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

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

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

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

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

Unfortunately no, this is my qualitative opinion, as even if I had any data, it would be a drop in the bucket.

[Brad Lassey‏]

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

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

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjsk17coSp9fgX7YN%3D4Qss2L2Sxb1dr0%3DU17CZX4-Rm4b9Pig%40mail.gmail.com.

[Lenny Primak‏]

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

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

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

+Eric and Guoye from Apple.

[Guoye Zhang‏]

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

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

WebTransport provides no remedy. The intent & desire was to use the web browser's inbuilt capabiities to observe PUSHes & react to those. That's what we wanted for half a decade. 

WebTransport provides another Do-It-Ourself means to ignore HTTP, ignore the browser, ignore the caches, & built alternate un-web systems for pushing data around. WebTransport provides no remedy.

HTTP Push is the only first class citizen the web has ever had for asserting resources. Developers said what they needed to use these features. No replacements have been proposed anywhere. Telling developers to go build some custom protocols for themselves via WebTransport, ignore REST, ignore http caches, is a massive massive step back from where we were 5 years ago, from what PUSH should become.

[Brad Lassey‏]

This is true, but it is not all that different from Push. In both cases the server can tell the client to unconditionally load a resource, but with a push promise that resource can contain additional headers and if the response also contains vary headers specifying those custom headers the matching logic in the push cache (in the case of a push promise) or the http cache (in the case of preload) will take those headers into consideration. Depending on this behavior sounds pretty foot-gun-y to me, and likely to result in behavior similar to what was recently described here [https://twitter.com/patmeenan/status/1359337536125075460]. Depending on circumstances, at least with Auth, this could still be achieved with a 401 response telling the client to include an Authorization header. 

That said, link headers (and tags) allow for extensions, so if this is an important use case, we could explore defining an extension to specify custom headers. I'll note though, that based on our telemetry, it does not appear that this is at all common.

-Brad

 

Mitar

[Ian Swett‏]

As others have expressed, I’m concerned that your efforts to benchmark push aren’t representative of real-world performance, including the time it takes to increase the congestion window. Connection reuse across page loads is quite low, so a fully warmed up congestion window should be treated as the exception, rather than the rule. This is because servers want to reclaim resources, as well as restrictions on connection pooling.

As a result, the amount of extra data that can be transferred in the first round trip is typically only a few kB, if anything. By the time the push is cancelled, typically it’s already been sent into the kernel buffers and/or network, so cancelling has no practical benefit. For users on slower connections, this wasted bandwidth substantially increases page load time.

I agree that Early Hints could help greatly improve performance while avoiding over-pushing and I’m excited Chrome is actively working on them as Kinuko recently indicated. Google servers are also going to start experimenting with Early Hints soon in collaboration with Chrome, but we shouldn’t be looking at Early Hints as a replacement for Push (or a blocker for Push deprecation) since Push does not deliver these benefits.

Thanks, Ian

[Kévin Dunglas‏]

Sure, but it's what "Cache Digests for HTTP/2" (https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-05) intends to solve (if it's implemented one day). In the meantime it's possible to use "user land" implementations such as CASPer (https://h2o.examp1e.net/configure/http2_directives.html#http2-casper). It's a bit of a pity to kill Server Push before having explored these solutions, on the other hand I totally understand that you don't want to maintain complex code not giving results as good as expected, and I hope that the 103 status code will be a success.

Cheers!

[Chris Harrelson‏]

Hi everyone,

Thank you for all the feedback and discussion on the thread.

The API owners have discussed this intent in detail, and also conferred with the intent owners a few times. (This is one reason it took so long to reply.)

Our conclusion is that while we are in general supportive of removing HTTP/2 push for the reasons given, we'd like support to be removed only once there is an Early Hints implementation that can be tested in the wild. While Early Hints is not solving exactly the same problem, its motivation is similar and therefore sites may be able to obtain similar performance to HTTP/2 push with that feature. Waiting for this will allow sites to potentially switch to Early Hints and not lose overall performance.

I would also like to note that one of the motivations for this intent is the maintenance burden of the feature. It does appear that in the short term the maintenance burden is limited, which is one reason we decided to wait for Early Hints. However, if additional large maintenance burdens surface in the meantime, we are open to changing our minds. Another point is that developers should not expect further features, enhancements, or possibly even corner-case bug fixes, to the HTTP/2 push implementation going forward; this will minimize the maintenance burden.

Chris, on behalf of the API owners

--
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/CADU7aouUZJSoQYhrQ5zAJPJ4xS%3D1U0Swe91c92jK3pFd_enNgA%40mail.gmail.com.

[Kinuko Yasuda‏]

Hi,

As an update, the basic part of Early Hints is now implemented in Chromium (for preload and navigation requests only) and we are starting an experiment with a small fraction of the traffic in M91.  You can find the intent thread for Early Hints experiment here:

https://groups.google.com/a/chromium.org/g/blink-dev/c/xb_NHDS3twY/m/F6onMGOuAAAJ

Sites who are interested in this feature can now start trying it with the real preloading behavior, though the current experiment population is still relatively small.  We also plan to implement a new attribute in Resource Timing API in coming milestones (targeting M93), this will tell the sites about when their resources are actually fetched by Early Hints or not, so that sites can measure their performance benefit more easily.  +Kenichi Ishibashi is the primary owner of Early Hints and the Resource Timing API addition.  We hope this helps the push discussion move forward.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9_OcNayBkRQmcz54h4vx90Cm9WQsE93hWgYw-azkJPGw%40mail.gmail.com.

[Thomas Castiglione‏]

Just to add a datapoint to the conversation, I have no particular opinion on HTTP push itself, because I've never had the opportunity to use it. I build web frameworks and applications for enterprise use (sometimes known as the "line of business" industry). My clients generally use the Microsoft stack, hosting either in IIS or the Azure cloud. Azure doesn't support server push. IIS theoretically does, but only the latest versions; customers that use IIS tend to use servers that are many years behind the bleeding edge. In practice, I've only seen one client engagement where it was possible to rely on even HTTP/2 being enabled.

In this environment, the idea of introducing a protocol feature and then deprecating it after a few years seems silly, as no architects will even have got around to evaluating the technology within that timeframe.

[Ryan Hamilton‏]

Thanks for the update on the origin trial, Kinuko!

Chris / API Owners, the decision in March was "Our conclusion is that while we are in general supportive of removing HTTP/2 push for the reasons given, we'd like support to be removed only once there is an Early Hints implementation that can be tested in the wild." Since we have now reached that threshold shall we now move forward with the Intent to Remove process?

Cheers,

Ryan

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNZKCFW-CxpY_tiK0Zn%3DDNCYqiUOmNHcs5n9BjGbYM%3DMSg%40mail.gmail.com.

[rektide‏]

please don't speed along this death, Ryan et. al.

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/K3rYLvmQUBY/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAJ_4DfRAFsfBDX5wgJN7h2Z3fnu0NNv9ociSyj1njH35kSx5Rg%40mail.gmail.com.

[Yoav Weiss‏]

I think it may be better to wait till we get some results from the experiment and know more about Early Hints' shipping schedule. Does that make sense?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfRAFsfBDX5wgJN7h2Z3fnu0NNv9ociSyj1njH35kSx5Rg%40mail.gmail.com.

[rektide‏]

On Wed, Dec 30, 2020 at 2:11 PM Brad Lassey <las...@chromium.org> wrote:

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?

 

It seems farcical to me that we are going to need to run HTTP3 over WebTransport to get a usable implementation of Push.

The browser should be good at HTTP. We should have these capabilities. Deciding to make everyone invent and bring their own userland WebTransport stack to be able to tell that an HTTP resource was pushed is a huge waste of bandwidth to send that userland stack, & a colossal mass of complexity to do the tunneling, & generates a far far more complex networking situation than if the browser would implement the one optional part of HTTP. Where-as before an a service might have run on HTTP3, pushed a resource, & seen it arrive, the service must host an WebTransport tunnel that carries HTTP3 inside of it. Now we have to worry about X-Forwarded-For like concerns.

WebPush Protocol already takes advantage of these capabilities, for example, to create a simple to implement, elegant notification service, used by all browsers: but without the Fetch standards I linked, it is unusable for such obvious cause. Without Push, we grow complex systems like grpc-web, which are partial, incomplete, radically complex alternatives to what the browser ought just be able to do, what only the most minor, long requested additions to Push would have allowed.

And now here we are, building Early Hints to try to reclaim only the most minor, smallest of advantages Push gave us. Focused only on this one tiny bit of the puzzle. And told that we must DIY alternatives if we want them, using WebTransport, and told that this web browser will not support the one optional component of the HTTP standard.

Words have not had an effect on me. This decision continues to have a profound & disturbing effect on me, and it should be reversed. Hopefully before we need to start implementing HTTP3 over WebTransport, but I rather suspect not.

[Francesco Montanari‏]

Is it already removed? I've implemented it but it doesn't seem to work in Chrome. 

Anyway, please don't kill it. 

Now that Google Search is deploying the "web vitals" update, which makes the loading speed a key factor for ranking, more and more developers are working to improve the sites speed, and pushing key assets would be very helpful.

[Bence Béky‏]

Hi Francesco,

Responding to the first part of your email only: no, HTTP/2 push is currently not disabled by default or removed from Chrome.  However, there is a 1% holdback experiment running on Stable channel to allow monitoring of *hypothetical* performance benefits.  If push does not work for you, your browser session might have been randomly assigned to the experiment.  In that case, restarting Chrome will fix it (with 99% probability).

Cheers,

Bence

[Maxim Makarov‏]

Please don't remove HTTP/2 Server Push support

[Andrew Wilder‏]

I run an agency that supports and maintains over 500 WordPress sites -- and we do a lot of site speed optimization work. Most of them are food blogs, and because of their complexity, it's very difficult to get them to pass the three Core Web Vitals requirements (especially LCP and CLS).

I've been experimenting with Server Push as a way to get assets loaded faster -- especially web fonts, which are often a source of shifts, as they switch from the default fallback font to the web font. Often we run into situations where the Origin Summary CLS is 2.6 or 2.7 seconds.  Being able to get fonts loaded earlier may help prevent shifts as they load; or to shave off even 0.1 second for the LCP element (especially if it's an image) may be enough to get the site to pass CWV completely. 

On some sites we exhausted other ways to speed things up to pass CWV, and it was starting to look like Server Push might be able to get us across the finish line. But I paused on getting further into development on this, because I found this thread! Unfortunately, you're now creating a self-fulfilling prophecy of killing off Server Push.  By announcing that you're considering removing it -- primarily because not enough people use it -- you're discouraging further people to start using it!  Oh, the irony.

Considering Google's push on site speed and Core Web Vitals, it seems quite contradictory for you to disable Server Push. Instead, it would be far better to invest more resources into helping people utilize it -- and making it more effective to help improve speed and user experience.  

[Andrew Wilder‏]

Sorry, I meant to say that Origin Summary CLS is just over 0.10, and/or LCP is 2.6s or 2.7s.  Just wanted to clear that up so you don't think I don't know what I'm talking about! 😉

[Brad Lassey‏]

Hi Andrew,

I just want to clarify one point, we are proposing to depreciate and remove HTTP Push because it has not proven to provide performance benefits over other, less complex and technically burdensome techniques such as preload (which I would encourage you to look at if you haven't already). The discussion of the amount of usage of Push is largely making the case that this depreciation represents a low risk of web breakage.

Thanks,

Brad

[Francesco Montanari‏]

It's not necessarily complex to implement for the developer.

For example, Cloudflare gives it by default, you just need to add the HTTP preload header ( https://www.cloudflare.com/it-it/website-optimization/http2/serverpush/ )

and they have a smart implementation of it, they push assets only at the first visit, they don't push them again when they know the browser should have it already in its cache.

They also were the first to offer SSL for free to everyone in 2014, and today nobody would pay for a SSL cert. So good things take time to spread... 

It's just a matter of time, when the WordPress themes start adding the preload HTTP header for their resources (it's a one-liner in PHP), all the wordpress sites which are on cloudflare will automatically have HTTP push with zero configuration, and the usage stats will rise as well.

[Andrew Wilder‏]

Brad, thanks for the clarification.  We're definitely utilizing preload -- that's pretty much "table stakes" for passing Core Web Vitals at this point. We're also utilizing many other tools, including Critical Path CSS and delaying JavaScript until after user interaction. Those are far more complicated to implement properly than Server Push (especially with Cloudflare's excellent implementation, as Francesco pointed out).

The new Page Experience requirements from Google have changed the game when it comes to site speed. Previously, speed was known to be a ranking factor, but the details were secret, and it was more of a "relative" factor compared to the competition. "Just be faster than your competition" was sufficient before. 

But with Core Web Vitals, the requirements are now absolute criteria, and it's pass/fail regardless of other sites in your vertical. There's no gray area here -- and for many sites, passing all three CWV criteria, while keeping the features that site owners need, is quite challenging. 

Furthermore, you mentioned "this depreciation represents a low risk of web breakage."  But keeping Server Push is not detrimental - it has zero risk of web breakage. So why remove support for it?  

So it seems we have one department of Google (Search) pushing for a faster web, and another Department (Chrome) considering taking away a tool that, with proper implementation, should actually help achieve that goal. 

  

Having said that, the truly important question that we're kind of dancing around is: Is Server Push actually beneficial?  

If the answer to that is "yes," then I think it's better for Chrome to keep supporting it -- and, instead of killing it, to make efforts to increase adoption.

But if you're able to demonstrate that, when properly implemented, it has no actual speed/CWV benefits compared to using <preload> links in the <head>, I'll be grateful because it means I don't have to spend time finding that out on my own.  :)

Thanks again,

Andrew

[Francesco Montanari‏]

Off-topic: regarding the webfonts Andrew, if I can give you a suggestion, I'd just remove them... all the devices already have good fonts, the user doesn't even notice the difference... 

you can do like Facebook that gives a different font-family based on the device, or even much easier like example.com, a single list to cover all:

font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;

I spent much time on Facebook and I never thought "it has an ugly font", it's the same I'm already used to in the rest of the device, the user appreciates more the fact that the site loads fast, imho

sorry for the OT

---

Da: Andrew Wilder <and...@andrewwilder.com>
Inviato: venerdì 25 giugno 2021 23:53
A: Francesco Montanari <francesco...@outlook.com>
Cc: blink-dev <blin...@chromium.org>; las...@chromium.org <las...@chromium.org>; Maxim Makarov <maxpa...@gmail.com>; b...@chromium.org <b...@chromium.org>; rektide <rek...@gmail.com>; dsch...@chromium.org <dsch...@chromium.org>; ians...@chromium.org <ians...@chromium.org>; Ben Lesh <b...@benlesh.com>
Oggetto: Re: Intent to Remove: HTTP/2 and gQUIC server push

 

[Andrew Wilder‏]

Oh yes, we're big fans of the system font stack!  :)  But our clients often insist on keeping their pretty fonts, so... 

[Brad Lassey‏]

On Fri, Jun 25, 2021, 4:53 PM Andrew Wilder <and...@andrewwilder.com> wrote:

Brad, thanks for the clarification.  We're definitely utilizing preload -- that's pretty much "table stakes" for passing Core Web Vitals at this point. We're also utilizing many other tools, including Critical Path CSS and delaying JavaScript until after user interaction. Those are far more complicated to implement properly than Server Push (especially with Cloudflare's excellent implementation, as Francesco pointed out).

The new Page Experience requirements from Google have changed the game when it comes to site speed. Previously, speed was known to be a ranking factor, but the details were secret, and it was more of a "relative" factor compared to the competition. "Just be faster than your competition" was sufficient before. 

But with Core Web Vitals, the requirements are now absolute criteria, and it's pass/fail regardless of other sites in your vertical. There's no gray area here -- and for many sites, passing all three CWV criteria, while keeping the features that site owners need, is quite challenging. 

Furthermore, you mentioned "this depreciation represents a low risk of web breakage."  But keeping Server Push is not detrimental - it has zero risk of web breakage. So why remove support for it?  

So it seems we have one department of Google (Search) pushing for a faster web, and another Department (Chrome) considering taking away a tool that, with proper implementation, should actually help achieve that goal. 

  

Having said that, the truly important question that we're kind of dancing around is: Is Server Push actually beneficial?  

If the answer to that is "yes," then I think it's better for Chrome to keep supporting it -- and, instead of killing it, to make efforts to increase adoption.

But if you're able to demonstrate that, when properly implemented, it has no actual speed/CWV benefits compared to using <preload> links in the <head>, I'll be grateful because it means I don't have to spend time finding that out on my own.  :)

Our data shows that it is not providing a speed benefit in practice and in fact is an overall slight performance regression for Chrome users. 

As far as differentiating "proper" use versus naive use, I cut the data by which CDN hosted each domain and didn't see any one CDN with a net performance benefit, which I interpret as not indicating that there is necessarily a proper vs improper way to use the feature. This intuitively makes sense as the theoretical potential benefit over preload is vanishingly small (1 RT worth of data minus your initial resource) and depending on the situation very possibly nil, versus the relatively high penalty of pushing the wrong thing.

[Andrew Wilder‏]

Interesting, thanks Brad.

I'd imagine that the performance benefit is actually greater for sites that don't use a CDN at all, since one RT is likely to take much longer... so if you're only looking at CDNs, that might explain part of the difference?

With the extremely tight requirements of Core Web Vitals, one round-trip's time potentially could make a significant difference in some cases.  I was recently working on a site where I just couldn't get the Largest Contentful Paint metric to pass the 75th percentile of 2.5s in CRuX.  I was stuck, soooo close, at 2.6s. (And it was testing great in Lab Data...just not in the field data, frustratingly)

A roundtrip can take well over 100ms, so that alone could be enough to shave off 0.1s under the right conditions, or maybe more, to get the site to pass CWV.  But I also stopped short of actually bothering to implement and test this when I saw this thread (I wasn't even sure if Chrome was still working for Server Push or not -- though I see that was answered a few messages back.)

I don't think I would have argued this point before core web vitals, since one round-trip does seem nearly negligible -- but because now we have absolute metrics we need to hit, which are pretty tough in some cases, I think keeping this one additional tool in the toolbelt may be worthwhile... 

Thanks again,

Andrew

[Brad Lassey‏]

On Fri, Jun 25, 2021, 6:58 PM Andrew Wilder <and...@andrewwilder.com> wrote:

Interesting, thanks Brad.

I'd imagine that the performance benefit is actually greater for sites that don't use a CDN at all, since one RT is likely to take much longer

Due to initial window sizes, one RT worth of data is measured in bytes, not time and does not vary based on round trip times.

... so if you're only looking at CDNs, that might explain part of the difference?

We looked at all sites that were using Push, but in addition cut the data by CDN to look for correlations.

With the extremely tight requirements of Core Web Vitals, one round-trip's time potentially could make a significant difference in some cases.  I was recently working on a site where I just couldn't get the Largest Contentful Paint metric to pass the 75th percentile of 2.5s in CRuX.  I was stuck, soooo close, at 2.6s. (And it was testing great in Lab Data...just not in the field data, frustratingly)

I'd suggest you look at how big your initial resources are and what's left over after the initial window. Again, the reference to a round trip is to the amount of data, not time.

[Patrick Meenan‏]

It feels like there are a lot of different things going on here and it might be useful to unpack it a bit.

Web Vitals thresholds - they aren't a hard line where you pass or you don't. The last updates from the team explained that each metric is looked at independently and there is a progressive boost in the "needs improvement" zone based on how close a given URL is to the "good" threshold. That doesn't really help if you're being held to the "number of URLs that need improvement" in the search console but there is not much practical difference between a 2.6 and a 2.5 LCP (not like the cliff that it initially sounded like it would be).

Layout Shifts from late-loading fonts - Using PUSH to try to fix this race condition feels like the wrong tool for the job. Even with font-display: block it is possible that a text element won't be sized correctly until the font loads, causing something after it in the DOM to be moved. Preload can help get the font loaded sooner so it will be there at layout time more often but it will still be racy. PUSH is also still racy but makes it even more likely that the font will be there early but at the cost of delaying literally everything else (including the HTML in a lot of cases). It feels like we need a better primitive to tell the browser to block layout until the text sizes are known (if that is something a site wants to do) so that things can still load asynchronously but the rendering can be controlled. It's a lot like CSS blocking layout/render - otherwise unstyled content is flashed for FOUC. font-display: block prevents the render of text in the wrong font but nothing lets you block incorrect layout (that I know of). Fixing that properly rather than wedging fonts ahead of everything else is a better fix.

Push sounds like a great solution, particularly when it can be done intelligently to not push resources already in cache and if it can exactly only fill the wait time while a CDN edge goes back to an origin for the HTML but getting those conditions right in practice is extremely rare. In virtually every case I have seen, the pushed resources end up delaying the HTML itself, the CSS and other render-blocking resources. Delaying the HTML is particularly bad because it delays the browser's discovery of all of the other resources on the page.  Preload works with the normal document parsing and resource discovery, letting preloaded resources intermix with other important resources and giving the dev, browsers and origins more control over prioritization.

[Brad Lassey‏]

No, the Push API (https://developer.mozilla.org/en-US/docs/Web/API/Push_API) is entirely unrelated other than the name.

-Brad

On Wed, Jun 30, 2021, 9:00 AM Vito De Giosa <vito.d...@gmail.com> wrote:

Does it mean that also that the webpush protocol, Push Api won't work anymore?

[Vito De Giosa‏]

Does it mean that also that the webpush protocol, Push Api won't work anymore?

On Monday, 28 June 2021 at 17:15:54 UTC+2 pme...@chromium.org wrote:

[Joel Szegedin‏]

One of the main reasons why consumers have not adopted to use HTTP/2 Server Push is because usage would be centralized to static content, yet most CDN providers have not yet implemented a usable Architecture for HTTP/2 Push.

So rather than removing this useful feature (yes, it's useful), perhaps work with CDN providers to implement this feature so it can be utilized properly.

[Daniel Micay‏]

It's now a year since the removal of HTTP/2 push was announced and Chromium still has HTTP/2 push. Are you waiting until browsers and servers implement 103 Early Hints? We use push but we halted optimizing it further due to the announced removal.

[Bence Béky‏]

Hi,

We are waiting on results from an ongoing experiment to confirm that
Early Hints works and improves performance. There should be an update
in three weeks.

Bence

[yue li‏]

It's 3 weeks now, we're waiting for the update. Anything I missed?

[Kenichi Ishibashi‏]

We have early results that indicate improvements on FCP/LCP. We'd like to talk to some experiment participants to confirm these results.

--

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/5bf6cbf0-3b96-4bdd-9a9a-cb1f10b76f1fn%40chromium.org.

[Kenichi Ishibashi‏]

Clarification: I'm talking about the experiment evaluating the effect of using Early Hints. We have been collaborating with a CDN and their customers for the experiment.

[Morgaine‏]

I'm not sure if you are being deliberately cruel & malicious, or just accidentally cruel. Web developers have been begging for Fetch to please for the love of everything holy please report HTTP PUSH responses for 3/4 of a decade now, so we might implement Webpush Protocol or other similar reactive techniques via using Push. There have been a couple explorations of this, but after a series of proposals, nothing has materialized, nothing has developed. Rather than ever making PUSH useful, rather than acknowledge that PUSH could implement a reactive, Webpush Protocl like system, you seem intent on using negligence to destroy the baby before it has a chance. This has been requested & begged for, there's been a couple spins, but you seem ready to destroy possibility in this deprecation, before even having made the most minimum bid to make the technology useful. Please, heed https://github.com/whatwg/fetch/issues/51 & try to do some little bit of good in the world, before you go running off macabely destroying possibility.

Chrome had a number of attempts where some good responsible smart actually-know-something developers saw that PUSH could be useful, and proposed trying to make Fetch spec be useful, proposed making PUSH useful. That the current crop of developers doesn't understand & see this possibility, either denies or is ignorant to the sad long history of begging, pretty please, to let us observe & react to PUSH requests, is a tragedy. We are headed for using HTTP3-over-WebTransport, because ya'll are sending in the wrecking ball, rather than following up & doing the bear minimum, most essential, most basic spec-authoring work on Fetch, that was begged for, pleaded for, for 3/4 of a decade now. This is such a sad sad route, and it's going to be such a gross boondogle working around the apathy browser developers gave for PUSH, their unlove, their incapability to provide even some simple basic capabilities to use PUSH. https://github.com/whatwg/fetch/issues/51 needed some love. It still does. Turn the ship around. Do the minimum viable feature, before you decide to axe it. You might even be able to not put the PUSH into cache, if that makes you happy, so long as you provide an alternative means to receive the PUSH responses to a Fetch. Doing nothing, permitting nothing: that's such a misdeed. Please, again, don't do this. And don't tell us something that is deeply related, that is at the heart of this disaster, that has gone unaddressed & unimprove for so long, is unrelated.

[Mitar‏]

Hi!

So I finally got to experiment a bit with HTTP2 push, preload link
header, and 103 early hints and to compare them, especially in the
context of API endpoints (similar to Vulcain [1]). My observations
are:

Go does not yet support 103 Early hints (but PRs exist [2][3]). 103
Early hints seem to be very verbose if the main use case is to send
preload link headers: "rel=preload;" could be maybe just implied? And
if I want to specify "crossorigin=use-credentials" across multiple
links, it becomes repetitive. Maybe it would be simpler to have 103
Preload with slightly modified syntax which would allow one to group
preload links together based on attributes.

Using a regular preload link header seems to be acted upon only after
both HTTP headers and response body has been consumed by the browser.
So it seems to me that the whole 103 Early hints is just because
browsers do not process HTTP headers immediately when they receive
them (if I force flush them before even sending the response body).
Make me wonder if it would not be easier to standardize early
processing of HTTP headers and early acting upon link headers in there
instead of the whole 103 Early hints approach which requires new
support across the full HTTP stack. Am I missing something here? Why
do we even need 103 Early hints?

HTTP2 push is even in 2022 sadly lacking high quality support across
the stack and this makes it hard to use. Go does not support it in
HTTP client library [4] and doing HTTP pushes seems to be slow [5].
Nor Chrome nor Firefox provide any insights into HTTP pushes in
developer tools, so it is really hard to observe them and debug them
(timings, headers, have they been canceled by the browser, informing a
developer if HTTP push has not been used). With such bad support
across the stack I do not wonder anymore why people have a hard time
using HTTP pushes and using them effectively.

So my conclusion is: given how hard it is to get HTTP pushes to be
implemented across the stack, I worry that the same thing will happen
with 103 Early hints. E.g.: will they be and how will they be exposed
in developer tools? How will one be able to observe when they are in
effect and when they are not? I wonder if in 5 years we will not be at
the same point thinking about removing 103 Early hints. Maybe simply
do early processing of HTTP headers and acting upon any link headers
in there might be much simpler to both implement and expose in
developer tools in browsers (almost no work needed there, only
resources will be fetched earlier in timelines). And no need for any
changes to the rest of the HTTP stack.

[1] https://github.com/dunglas/vulcain
[2] https://github.com/golang/go/pull/42597
[3] https://github.com/golang/net/pull/96
[4] https://github.com/golang/go/issues/18594
[5] https://github.com/golang/go/issues/51361


Mitar



Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

[Daisuke Enomoto‏]

Hello,

We conducted an experiment for Early Hints (chromestatus) with partners in Q3 - Q4, 2021. The experiment data suggests that the performance impact is highly positive. Based on these insights, we are confident that Early Hints will be a viable alternative to H/2 Push for performance use cases. In addition, by design Early Hints will not run into the overpushing concerns that bogged down H/2 Push. We are working with some of our partners to share a bit more details.

Next steps (for Early Hints)

We are actively working on finalizing the shipping plan / timeline. In particular, Early Hints requires updating multiple specs. Once our plan becomes clearer, the details will be shared on a new Intent to Ship thread.

Non performance use cases

For other perceived use cases beyond performance improvements, we recommend sharing more details over at WICG Discourse with a focus on the problem you are trying to solve rather than how H/2 Push could be used. In addition, if you currently rely on H/2 Push in ways that Early Hints can’t address, please share details about how critical this is to your product/service, on top of your use case.

Thanks

Daisuke

--

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/06cb378d-e243-4200-9af5-5eb2868388bcn%40chromium.org.

[Chris Harrelson‏]

The API owners met today and discussed this intent at some length.

We are very happy that Early Hints is showing very positive promise in terms of experimental data, and feel the positive experimental data is enough to justify starting the process to remove HTTP/2 push.

To that end, we approve starting official deprecation of the feature now, with a (publicly communicated) goal to remove support from Chromium in the next 6-9 months. We  recommend publishing a blog post describing what's happening and the recommended migration paths.

However, we would like to see an Early Hints intent-to-ship before approving actual removal of HTTP/2 Push; please do not consider this an email an approval to actually remove it until we send LGTMs for such. Our understanding is that Early Hints is well on the way to a finished spec and readiness to ship, and the remaining pieces of the specification are to nail down integration with other related APIs such as Fetch. We think this sounds feasible to complete and reach a shipped-in-stable-channel status within the proposed deprecation period, which would allow sites to potentially have a seamless transition.

We recognize that this is a long time period, and especially long given the time since the start of the request to deprecate. The reason is that we'd really like to avoid the "old thing is deprecated, new thing is not yet available" situation if possible. Thank you everyone for your patience and efforts.

Regards,

Chris

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com.

[BIANCONI Thomas‏]

I am sad to read this...
A new step before the deprecation of server push.

I would love to see comparaison in term of performance between server push and early hint.

On a pure theoric point of view early hint starts during the html parsing whereas the server push start with the response header. So server push by design is better.

Regarding the complexity to put it in place early hints is easy when you serve different page but for Single Page Application the build process don't generate differentiate serving based on the route since the routing of the application is generally managed in the frontend.

So for Single Page Application to managed server push not global to all route it will more complexe to include it in the build process.

Just wanted to share my feeling about this whole topic.

 

Thanks

 

Regards

 

Thomas BIANCONI

Head of Data Technologies

& Data Privacy Champion

Global CDMO Team

41 Rue Martre - 92110 Clichy

Mob : +33 (0) 6 15 35 33 57

Ph : +33 (0) 1 47 56 45 95

E-mail : thomas....@loreal.com

---

De : Chris Harrelson <chri...@chromium.org>
Envoyé : mercredi 2 mars 2022 18:51
À : Daisuke Enomoto <deno...@chromium.org>
Cc : blink-dev <blin...@chromium.org>; las...@chromium.org <las...@chromium.org>; pme...@chromium.org <pme...@chromium.org>; Francesco Montanari <francesco...@outlook.com>; Maxim Makarov <maxpa...@gmail.com>; b...@chromium.org <b...@chromium.org>; dsch...@chromium.org <dsch...@chromium.org>; ians...@chromium.org <ians...@chromium.org>; rektide <rek...@gmail.com>; Ben Lesh <b...@benlesh.com>; Andrew Wilder <and...@andrewwilder.com>; Vito De Giosa <vito.d...@gmail.com>
Objet : Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

 

Notice: External mail

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/K3rYLvmQUBY/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com.

This message and any attachments are confidential and intended solely for the addressees.
If you receive this message in error, please delete it and immediately notify the sender. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, copying or dissemination is prohibited. E-mails are susceptible to alteration. Neither LOREAL nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

C1 - Internal use

[Kenji Baheux‏]

Hi Thomas,

I'm part of the team working on Early Hints.

On Wed, Mar 16, 2022 at 6:58 AM BIANCONI Thomas <Thomas....@loreal.com> wrote:

I am sad to read this...
A new step before the deprecation of server push.

I would love to see comparaison in term of performance between server push and early hint.

On a pure theoric point of view early hint starts during the html parsing whereas the server push start with the response header. So server push by design is better.

If I understand correctly, I believe that there is some misunderstanding about Early Hints.

Clearly, it's on us to make this easier to understand. Sorry... 

We'll put extra efforts in providing clear & detailed developer documentation when Early Hints ships.

In the meantime, here is a high level summary of what Early Hints is, and how it works:

1. Early Hints is a status code (103) which is used in HTTP responses while the server is preparing the final response. This intermediate response can include other HTTP headers, in particular LINK REL headers such as preload or preconnect.
2. In some cases, it can take time for the server to prepare the main response: accessing the DB, having an edge cache go talk to the origin server, etc. So, the idea is to speed up overall page load times by giving the browser hints about what it might do while waiting for the actual response. Typically, the hints are about critical sub-resources or origins which would be used by the final response.
3. The browser processes these hints, and decides to preconnect or preload any missing origins/resources while waiting for the final 200 OK response (usually containing the main resource). Since the browser got some work done ahead of time, the overall page load time is improved.

In other words, the key point here is that Early Hints doesn't start during the HTML parsing: it starts with the non-final response headers, way before HTML parsing kicks in since that is blocked on the final response.

See this section of the RFC for an example of how this looks at the HTTP level.

 

Regarding the complexity to put it in place early hints is easy when you serve different page but for Single Page Application the build process don't generate differentiate serving based on the route since the routing of the application is generally managed in the frontend.

So for Single Page Application to managed server push not global to all route it will more complexe to include it in the build process.

The MPA angle is indeed easier, deployment wise.

We'll look into the SPA case in more details including discussion with various framework authors.

I hope this was useful.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PA4PR05MB90898054ACE52E707A43508D81109%40PA4PR05MB9089.eurprd05.prod.outlook.com.

[Mitar‏]

Hi!

Kenji, I have been following progress around HTTP2 push and it looks to me that all the focus is on HTTP2 pushes which happen at the page loading time. But there are also pushes which happen later on, after the page has already loaded. Concrete example: I have an app which subscribes to notifications from the server (using SSE or WebSockets), when it gets a notification that some resource changed, the app makes a HTTP request to fetch the new resource (to then update DOM reactively). By separating notification from payload and not pushing data itself over WebSocket, those resources can be cached so that the next time the page loads they can be reused. With HTTP2 push the server can send the resource to the client together with the notification itself, so that data is available together with the notification. I do not see something like possible with Early Hints?

Another limitation of Early Hints seems to be that resources which require Authorization header cannot be preloaded, am I mistaken? With HTTP2 push you can push such a resource and add a corresponding anticipated header.

Mitar

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADWWn7WEBYWRR3EAu0-XHZ9DAce8ifhxtm11b7xPyLS_ghSrsA%40mail.gmail.com.

[Kenji Baheux‏]

Hi Mitar, 

Thanks for the feedback, and sorry for the delay.

The Authorization header should be supported in Early Hints.

Please share a concrete example if this doesn't work as you'd hope.

Also, we would like Early Hints to be useful beyond the main request (page navigation).

In particular, with SPAs, the current scope would have a limited impact.

However, there is some additional trickiness in the code with regards to CORS/CORP/CORB that the team needs to figure out.

A few more comments & questions inline:

On Tue, Apr 12, 2022 at 7:29 PM Mitar <mmi...@gmail.com> wrote:

Hi!

Kenji, I have been following progress around HTTP2 push and it looks to me that all the focus is on HTTP2 pushes which happen at the page loading time. But there are also pushes which happen later on, after the page has already loaded. Concrete example: I have an app which subscribes to notifications from the server (using SSE or WebSockets), when it gets a notification that some resource changed, the app makes a HTTP request to fetch the new resource (to then update DOM reactively). By separating notification from payload and not pushing data itself over WebSocket, those resources can be cached so that the next time the page loads they can be reused. With HTTP2 push the server can send the resource to the client together with the notification itself, so that data is available together with the notification. I do not see something like possible with Early Hints?

IIRC, H2/Push isn't really well-suited for the notification part though, and the push design has proven problematic in practice (i.e. overpushing).

That said, going back to your SSE/WebSocket (notification / commands) + Fetch based solution, I think there might be an opportunity.

Mark Nottingham recently wrote an article which seems related.

What Mark calls Intermediation in his article is appealing, including for browsers.

If the browser had an understanding that new resources are being announced through this notification channel, it could take care of the rest (i.e. only load what's missing, cache them, etc) and make sure that everything is working as usual (e.g. service worker) without requiring web developers to roll their own workarounds.

Perhaps, we would see a lot more adoption of such a fancy technique if it embraced the existence of intermediaries eager to help.

It could even be something that is announced in the response for the main resource, which the browser would subscribe to automatically.

Mark suggests options for SSE, WebSocket/WebTransport, or HTTP itself.

I'm a bit skeptical of the last one because that would be an entirely new endeavor.

Augmenting SSE seems less risky / faster, and possibly features a better adoption story (already deployed / well-understood).

I'm assuming that we could define a special type of event (binary even?) that intermediaries including browsers would understand (i.e. the data would be some usual HTTP lingo).

Caveat: none of this has been vetted by the engineering team, so I could be extremely naive about the cost & risks.

Thoughts?

[Daisuke Enomoto‏]

Hello,

In case you have not noticed, Early Hints is on track to ship in M103 (I2S, Chrome Status).

[Carlos Lopez‏]

So, I've been using HTTP2 push for almost 2 years now and as I continue to write more SPA with more native code (now that IE11 is dead-dead), not having Push will keep us stuck in the single file bundling mess of CSS and JS, and all it's bundlers and debugging complexity. 

With Javascript, ESM imports (instead of ES5) would be able to reference multiple files and have the server push the JS files as needed.

With CSS, I wanted to ditch the bundling and eliminate SASS by using the `@import layer` system, but if we're still going to be tied to single files, then that goes out the window too.

I get the early hints, but that does nothing for first interaction (before the service worker kicks in and caches). For HTML, It's no better than `<link rel=preload>`, since both the hint and the content likely comes in the same network packet (partial HTML header), so why bother? I believe the same would apply to JS and CSS, though I don't know if Chrome active reacts to partial JS import lines with ESM (or if it does with topline CSS @import statements). Also, if people aren't doing HTTP2 push already which happens outside the response stream, why would people do it with Early Hints. In userland, it would be nearly same code: `response.addHint('styles.scss')` vs `response.addPush('styles.css')`, so I don't see why devs believe the lack of adoption from users is going to change. Yes, you solve overly pushing content, but you're not really solve the  time-to-first-byte (TTFB) problem, which HTTP2 Push was meant to address.

In the end, if we want fast first-meaningful-paint (FMP) and HTTP2 push goes away, we're going to have to embed CSS and JS in HTML instead of Pushing (and using rel=preload fallback). Now it makes development even more harebrained and complex. Before, I could have my HTTP2 server know to push a `firstpaint.css` and `firstpaint.js` on `index.html` request, and let it paint a splash-like screen, and then let deferred styles and JS kick in later. No HTTP2 just means even more bundling in the HTML layer itself, (eg: EJS/PUG), instead of regular HTML files.

[mup co.il.‏]

please DONT remove HTTP SERVER PUSH‏‏

This feature is very useful and miraculously improves the loading speed if it is implemented correctly, there is no need to remove it just because "people do not know how to implement it correctly".

ב-יום שני, 23 במאי 2022 בשעה 18:41:23 UTC+3, Carlos Lopez כתב/ה: