Thanks Ryan for pushing this through (pun not intended..) What timeline did y'all have in mind for deprecation and removal? Any progress on the public communication front discussed earlier <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com?utm_medium=email&utm_source=footer> ?
Cheers :) Yoav On Mon, Aug 8, 2022 at 11: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/CAL5BFfXUamWaHLe%3DNS602BEzA8yUiB-0LWtXDhC4SRfeoQ78gA%40mail.gmail.com.
