I believe Ian's timeline suggestion was to disable on trunk this week and let it ride to stable in m106.
-Brad On Mon, Aug 15, 2022 at 10:39 AM Joe Medley <jmed...@google.com> wrote: > Ryan, > > What's the planned schedule for deprecation and removal? > 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/CALjsk167d4GhR5yf1vcR2HqsxvQMHdNn8v-sGDRVBL-%2BMmw_0g%40mail.gmail.com.
