So it will be disabled by default in 106 then? Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | 816-678-7195 *If an API's not documented it doesn't exist.*
On Mon, Aug 15, 2022 at 8:13 AM Brad Lassey <las...@chromium.org> wrote: > 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/CAJUhtG9M1GMpnSAWf_UweaDDkp2y8s%2Bydzd0Gxk4-DOcjnifSw%40mail.gmail.com.
