An increasing fraction of Chrome traffic is now HTTP/3 (which has always had server push disabled), so disabling it for HTTP/2 should be a fairly low impact change.
I'd like to do it in Chrome Canary this week and let it move to Stable, given we've reached all the previously agreed upon milestones. Ian On Tue, Aug 9, 2022 at 10:10 AM Joe Medley <jmed...@google.com> wrote: > What's the intended milestone for this? > Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | > 816-678-7195 <(816)%20678-7195> > *If an API's not documented it doesn't exist.* > > > On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton <r...@chromium.org> wrote: > >> Howdy Chris, et al, >> >> Early Hints launched to Stable in M103. As such we would like to revive >> this Intent to Remove HTTP/2 Server Push. >> >> Cheers, >> >> Ryan >> >> On Wed, Mar 2, 2022 at 9:51 AM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> 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 >>> >>> >>> On Wed, Mar 2, 2022 at 1:47 AM Daisuke Enomoto <denom...@chromium.org> >>> wrote: >>> >>>> Hello, >>>> >>>> We conducted an experiment for Early Hints (chromestatus >>>> <https://chromestatus.com/feature/5207422375297024>) 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 >>>> <https://discourse.wicg.io/> 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 <https://discourse.wicg.io/> about how critical this is to >>>> your product/service, on top of your use case. >>>> >>>> Thanks >>>> Daisuke >>>> >>>> On Sun, Feb 20, 2022 at 6:40 PM Morgaine <rekt...@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. >>>>>> >>>>>> -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? >>>>>> >>>>>> >>>>>>> >>>>>>> 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 >>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 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, >>>>>>>>>>>> Andrew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 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, >>>>>>>>>>>>>> Brad >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 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 support >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 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, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Bence >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 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+unsubscr...@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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06cb378d-e243-4200-9af5-5eb2868388bcn%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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+unsubscr...@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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfSJ7kapqg0-S-WQfTBcuLBrVuazwswo6gwoFWV3m4jk%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@chromium.org. 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.
