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
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.
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 PhelpsOutsmartly
--
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.
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.
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.
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.
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.
--
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.
> 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.
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.
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?
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.
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.
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 iteasy 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.
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 personallydevelop 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)
Synergy with Service WorkersCorrect me if I'm wrong, but the intended scheme for Server Push is :
- Client with no SW asks Server for index.html
- Server answers index.html + push all resources through prefetch -> Link: <sw.mjs>;rel=prefetch;as=script;type=module ...
- Client download resources, activate SW
- Client is now SW controlled, and never again hit the server
- Later on, sw.mjs change (update published)
- Client download only new files
It is perfectly fine, and works like a charm in this scenario.BenchmarksIf 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 }.ConclusionThe technology itself is amazing.Keep it.
--
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.
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.
Mitar
--
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfRAFsfBDX5wgJN7h2Z3fnu0NNv9ociSyj1njH35kSx5Rg%40mail.gmail.com.
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, 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. :)
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)
Does it mean that also that the webpush protocol, Push Api won't work anymore?
--
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.
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.--
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.
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.
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
E-mail : thomas....@loreal.com
Notice: External mail |
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
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.
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.
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.
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?
The Authorization header should be supported in Early Hints.Please share a concrete example if this doesn't work as you'd hope.
--
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/CAPq58w7y_FUBmmzY2k1jSrqS%2BYSELDpBhTUR2anNLXwGw6TaRQ%40mail.gmail.com.
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,ChrisOn Wed, Mar 2, 2022 at 1:47 AM Daisuke Enomoto <deno...@chromium.org> wrote: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.ThanksDaisukeOn Sun, Feb 20, 2022 at 6:40 PM Morgaine <rek...@gmail.com> wrote: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.On Wednesday, June 30, 2021 at 9:42:26 AM UTC-4 las...@chromium.org wrote:No, the Push API (https://developer.mozilla.org/en-US/docs/Web/API/Push_API) is entirely unrelated other than the name.-BradOn 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?On Monday, 28 June 2021 at 17:15:54 UTC+2 pme...@chromium.org wrote: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.On Friday, June 25, 2021 at 7:32:05 PM UTC-4 Brad Lassey wrote: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 longerDue 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.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,AndrewOn Fri, Jun 25, 2021 at 3:28 PM Brad Lassey <las...@chromium.org> wrote: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.Thanks again,AndrewOn Fri, Jun 25, 2021 at 1:25 PM Francesco Montanari <francesco...@outlook.com> wrote: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.On Friday, 25 June 2021 at 22:58:41 UTC+3 las...@chromium.org wrote: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,BradOn Fri, Jun 25, 2021, 1:08 PM Andrew Wilder <and...@andrewwilder.com> wrote: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! 😉On Friday, June 25, 2021 at 10:02:13 AM UTC-7 Andrew Wilder wrote: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.On Friday, June 25, 2021 at 8:45:09 AM UTC-7 Maxim Makarov wrote:Please don't remove HTTP/2 Server Push supportOn Monday, June 21, 2021 at 5:32:25 PM UTC+3 b...@chromium.org wrote: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,BenceOn Sat, Jun 19, 2021 at 3:58 PM Francesco Montanari <francesco...@outlook.com> wrote: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.On Monday, 7 June 2021 at 23:25:02 UTC+3 rektide wrote: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.
--
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.
--
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/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com.
--
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/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfSJ7kapqg0-S-WQfTBcuLBrVuazwswo6gwoFWV3m4jk%3DA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfSJ7kapqg0-S-WQfTBcuLBrVuazwswo6gwoFWV3m4jk%3DA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKcm_gOqvdCDfNvv6SqJqeQaLnhXg8jOL%3D7a945ok2qgAt5xXg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfSJ7kapqg0-S-WQfTBcuLBrVuazwswo6gwoFWV3m4jk%3DA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.
--
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+unsubscribe@chromium.org.
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.
--
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+unsubscribe@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.
--
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+unsubscribe@chromium.org.
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.
--
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/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com.
--
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/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com.
--
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/CAJ_4DfSJ7kapqg0-S-WQfTBcuLBrVuazwswo6gwoFWV3m4jk%3DA%40mail.gmail.com.
--
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/75de20ed-1f99-4675-b589-c251738582c7n%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw96opMf%3DYxj4SNeBFXm1hSJJKoQ2i9oPZvN3qf6GcALFQ%40mail.gmail.com.
Currently i have an http/2 server serving my app locally, counting 271 js modules, pushing them all at the first response. It takes about 400-500ms for the browser to load everything and startup the app. The implementation is trivial and has all the goodies automatically. Each dependency, since it sits at its real path, can locate its own assets, sourcemaps etc. With Early Hints, Link: and all other methods, since every module has to do an extra request for its dependencies, and those for their dependencies, etc. the same app takes about 4-5 seconds to load in Chrome and 2-3s with all the modules in its cache, locally. There is no more room for improvement, except for push or bundling.So now with this change, the only solution becomes "bundling", which is only marginally better than the original http/2 push server and using esbuild which is essentially doing the same thing as "push", only that now i had to introduce an extra build step that before was provided by the push technology at the HTTP level. A step which is far more complicated to implement and maintain than the http/2 push version. Bundling assets and workers become problematic since the dependencies are no longer at their real path relative to their assets but they're all bundled down to a single file. So it becomes a non-trivial issue, the tree structure of the source code no longer matches the one that is deployed, where before it was itself that was being deployed, without any extra transformations. Raw source code without http/2 push becomes non-deployable without an extra bundling step from the user.That is an unnecessary step backwards IMO, we have a technology that works very well *at least* for local development, it has a very low barrier to entry, and which has the potential to deploy something without the overhead of dealing with 3rd party bundlers, meaning a more open web where source code and dependencies are pulled in raw and are more easily accessible, e.g you post an importmap at a package registry and you get all of the tree in that single response, trivially handled by "push".The rationale for removing it is because it's not used too much in the wild, even though 1.25% of all the sites in the world is still, i think, a huge number of sites. And the only viable alternative now becomes using bundlers and 3rd party technologies to deploy anything on the web that exceeds a handful of dependencies, a task which is non-trivial and requires resources to maintain. It becomes a less open web.I believe we should keep "push" and instead try and fix its issues and improve it, mainly overpushing, perhaps along with information provided by importmaps. In general, strive for an open web where source code is accessible and the barrier to entry is creating an .html file and uploading it somewhere.
--
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/2bb46e42-a270-78a2-a473-e37739058d98%40chromium.org.
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)endresponse.body.read # etcBut 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,SamuelOn Thursday, November 12, 2020 at 3:26:20 PM UTC+13 Ian Swett wrote: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 PhelpsOutsmartlyOn Wednesday, November 11, 2020 at 9:00:52 PM UTC-5 Ian Swett wrote: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, ...)IanOn Wednesday, November 11, 2020 at 8:35:24 PM UTC-5 Morgaine wrote: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.