Are you referring to "We recommend publishing a blog post describing what's happening and the recommended migration paths."?
That server push is deprecated was mentioned in the early hints blog post: https://developer.chrome.com/blog/early-hints/#relationship-to-h2push On Fri, Aug 12, 2022 at 8:38 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > Hey Ian! :) Did the public communication that Chris asked for > <https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/HERBN_EbBAAJ> > happened? > > On Thu, Aug 11, 2022 at 9:15 PM 'Ian Swett' via blink-dev < > blink-dev@chromium.org> wrote: > >> An increasing fraction of Chrome traffic is now HTTP/3 (which has >> always had server push disabled), so disabling it for HTTP/2 should be a >> fairly low impact change. >> >> I'd like to do it in Chrome Canary this week and let it move to Stable, >> given we've reached all the previously agreed upon milestones. >> >> Ian >> >> On Tue, Aug 9, 2022 at 10:10 AM Joe Medley <jmed...@google.com> wrote: >> >>> What's the intended milestone for this? >>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | >>> 816-678-7195 <(816)%20678-7195> >>> *If an API's not documented it doesn't exist.* >>> >>> >>> On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton <r...@chromium.org> wrote: >>> >>>> Howdy Chris, et al, >>>> >>>> Early Hints launched to Stable in M103. As such we would like to revive >>>> this Intent to Remove HTTP/2 Server Push. >>>> >>>> Cheers, >>>> >>>> Ryan >>>> >>>> On Wed, Mar 2, 2022 at 9:51 AM Chris Harrelson <chris...@chromium.org> >>>> wrote: >>>> >>>>> The API owners met today and discussed this intent at some length. >>>>> >>>>> We are very happy that Early Hints is showing very positive promise in >>>>> terms of experimental data, and feel the positive experimental data is >>>>> enough to justify starting the process to remove HTTP/2 push. >>>>> >>>>> To that end, we approve starting official deprecation of the feature >>>>> now, with a (publicly communicated) goal to remove support from Chromium >>>>> in >>>>> the next 6-9 months. We recommend publishing a blog post describing >>>>> what's >>>>> happening and the recommended migration paths. >>>>> >>>>> However, we would like to see an Early Hints intent-to-ship before >>>>> approving actual removal of HTTP/2 Push; please do not consider this an >>>>> email an approval to actually remove it until we send LGTMs for such. Our >>>>> understanding is that Early Hints is well on the way to a finished spec >>>>> and >>>>> readiness to ship, and the remaining pieces of the specification are to >>>>> nail down integration with other related APIs such as Fetch. We think this >>>>> sounds feasible to complete and reach a shipped-in-stable-channel status >>>>> within the proposed deprecation period, which would allow sites to >>>>> potentially have a seamless transition. >>>>> >>>>> We recognize that this is a long time period, and especially long >>>>> given the time since the start of the request to deprecate. The reason is >>>>> that we'd really like to avoid the "old thing is deprecated, new thing is >>>>> not yet available" situation if possible. Thank you everyone for your >>>>> patience and efforts. >>>>> >>>>> Regards, >>>>> Chris >>>>> >>>>> >>>>> On Wed, Mar 2, 2022 at 1:47 AM Daisuke Enomoto <denom...@chromium.org> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> We conducted an experiment for Early Hints (chromestatus >>>>>> <https://chromestatus.com/feature/5207422375297024>) with partners >>>>>> in Q3 - Q4, 2021. The experiment data suggests that the performance >>>>>> impact >>>>>> is highly positive. Based on these insights, we are confident that Early >>>>>> Hints will be a viable alternative to H/2 Push for performance use cases. >>>>>> In addition, by design Early Hints will not run into the overpushing >>>>>> concerns that bogged down H/2 Push. We are working with some of our >>>>>> partners to share a bit more details. >>>>>> >>>>>> Next steps (for Early Hints) >>>>>> >>>>>> We are actively working on finalizing the shipping plan / timeline. >>>>>> In particular, Early Hints requires updating multiple specs. Once our >>>>>> plan >>>>>> becomes clearer, the details will be shared on a new Intent to Ship >>>>>> thread. >>>>>> >>>>>> Non performance use cases >>>>>> For other perceived use cases beyond performance improvements, we >>>>>> recommend sharing more details over at WICG Discourse >>>>>> <https://discourse.wicg.io/> with a focus on the problem you are >>>>>> trying to solve rather than how H/2 Push could be used. In addition, if >>>>>> you >>>>>> currently rely on H/2 Push in ways that Early Hints can’t address, >>>>>> please share >>>>>> details <https://discourse.wicg.io/> about how critical this is to >>>>>> your product/service, on top of your use case. >>>>>> >>>>>> Thanks >>>>>> Daisuke >>>>>> >>>>>> On Sun, Feb 20, 2022 at 6:40 PM Morgaine <rekt...@gmail.com> wrote: >>>>>> >>>>>>> I'm not sure if you are being deliberately cruel & malicious, or >>>>>>> just accidentally cruel. Web developers have been begging for Fetch to >>>>>>> please for the love of everything holy please report HTTP PUSH responses >>>>>>> for 3/4 of a decade now, so we might implement Webpush Protocol or other >>>>>>> similar reactive techniques via using Push. There have been a couple >>>>>>> explorations of this, but after a series of proposals, nothing has >>>>>>> materialized, nothing has developed. Rather than ever making PUSH >>>>>>> useful, >>>>>>> rather than acknowledge that PUSH could implement a reactive, Webpush >>>>>>> Protocl like system, you seem intent on using negligence to destroy the >>>>>>> baby before it has a chance. This has been requested & begged for, >>>>>>> there's >>>>>>> been a couple spins, but you seem ready to destroy possibility in this >>>>>>> deprecation, before even having made the most minimum bid to make the >>>>>>> technology useful. Please, heed >>>>>>> https://github.com/whatwg/fetch/issues/51 & try to do some little >>>>>>> bit of good in the world, before you go running off macabely destroying >>>>>>> possibility. >>>>>>> >>>>>>> Chrome had a number of attempts where some good responsible smart >>>>>>> actually-know-something developers saw that PUSH could be useful, and >>>>>>> proposed trying to make Fetch spec be useful, proposed making PUSH >>>>>>> useful. >>>>>>> That the current crop of developers doesn't understand & see this >>>>>>> possibility, either denies or is ignorant to the sad long history of >>>>>>> begging, pretty please, to let us observe & react to PUSH requests, is a >>>>>>> tragedy. We are headed for using HTTP3-over-WebTransport, because ya'll >>>>>>> are >>>>>>> sending in the wrecking ball, rather than following up & doing the bear >>>>>>> minimum, most essential, most basic spec-authoring work on Fetch, that >>>>>>> was >>>>>>> begged for, pleaded for, for 3/4 of a decade now. This is such a sad sad >>>>>>> route, and it's going to be such a gross boondogle working around the >>>>>>> apathy browser developers gave for PUSH, their unlove, their >>>>>>> incapability >>>>>>> to provide even some simple basic capabilities to use PUSH. >>>>>>> https://github.com/whatwg/fetch/issues/51 needed some love. It >>>>>>> still does. Turn the ship around. Do the minimum viable feature, before >>>>>>> you >>>>>>> decide to axe it. You might even be able to not put the PUSH into >>>>>>> cache, if >>>>>>> that makes you happy, so long as you provide an alternative means to >>>>>>> receive the PUSH responses to a Fetch. Doing nothing, permitting >>>>>>> nothing: >>>>>>> that's such a misdeed. Please, again, don't do this. And don't tell us >>>>>>> something that is deeply related, that is at the heart of this disaster, >>>>>>> that has gone unaddressed & unimprove for so long, is unrelated. >>>>>>> On Wednesday, June 30, 2021 at 9:42:26 AM UTC-4 las...@chromium.org >>>>>>> wrote: >>>>>>> >>>>>>>> No, the Push API ( >>>>>>>> https://developer.mozilla.org/en-US/docs/Web/API/Push_API) is >>>>>>>> entirely unrelated other than the name. >>>>>>>> >>>>>>>> -Brad >>>>>>>> >>>>>>>> On Wed, Jun 30, 2021, 9:00 AM Vito De Giosa <vito.d...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Does it mean that also that the webpush protocol, Push Api won't >>>>>>>>> work anymore? >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Monday, 28 June 2021 at 17:15:54 UTC+2 pme...@chromium.org >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> It feels like there are a lot of different things going on here >>>>>>>>>> and it might be useful to unpack it a bit. >>>>>>>>>> >>>>>>>>>> Web Vitals thresholds - they aren't a hard line where you pass or >>>>>>>>>> you don't. The last updates from the team explained that each metric >>>>>>>>>> is >>>>>>>>>> looked at independently and there is a progressive boost in the >>>>>>>>>> "needs >>>>>>>>>> improvement" zone based on how close a given URL is to the "good" >>>>>>>>>> threshold. That doesn't really help if you're being held to the >>>>>>>>>> "number of >>>>>>>>>> URLs that need improvement" in the search console but there is not >>>>>>>>>> much >>>>>>>>>> practical difference between a 2.6 and a 2.5 LCP (not like the cliff >>>>>>>>>> that >>>>>>>>>> it initially sounded like it would be). >>>>>>>>>> >>>>>>>>>> Layout Shifts from late-loading fonts - Using PUSH to try to fix >>>>>>>>>> this race condition feels like the wrong tool for the job. Even with >>>>>>>>>> font-display: block it is possible that a text element won't be sized >>>>>>>>>> correctly until the font loads, causing something after it in the >>>>>>>>>> DOM to be >>>>>>>>>> moved. Preload can help get the font loaded sooner so it will be >>>>>>>>>> there at >>>>>>>>>> layout time more often but it will still be racy. PUSH is also still >>>>>>>>>> racy >>>>>>>>>> but makes it even more likely that the font will be there early but >>>>>>>>>> at the >>>>>>>>>> cost of delaying literally everything else (including the HTML in a >>>>>>>>>> lot of >>>>>>>>>> cases). It feels like we need a better primitive to tell the browser >>>>>>>>>> to >>>>>>>>>> block layout until the text sizes are known (if that is something a >>>>>>>>>> site >>>>>>>>>> wants to do) so that things can still load asynchronously but the >>>>>>>>>> rendering >>>>>>>>>> can be controlled. It's a lot like CSS blocking layout/render - >>>>>>>>>> otherwise >>>>>>>>>> unstyled content is flashed for FOUC. font-display: block prevents >>>>>>>>>> the >>>>>>>>>> render of text in the wrong font but nothing lets you block incorrect >>>>>>>>>> layout (that I know of). Fixing that properly rather than wedging >>>>>>>>>> fonts >>>>>>>>>> ahead of everything else is a better fix. >>>>>>>>>> >>>>>>>>>> Push sounds like a great solution, particularly when it can be >>>>>>>>>> done intelligently to not push resources already in cache and if it >>>>>>>>>> can >>>>>>>>>> exactly only fill the wait time while a CDN edge goes back to an >>>>>>>>>> origin for >>>>>>>>>> the HTML but getting those conditions right in practice is extremely >>>>>>>>>> rare. >>>>>>>>>> In virtually every case I have seen, the pushed resources end up >>>>>>>>>> delaying >>>>>>>>>> the HTML itself, the CSS and other render-blocking resources. >>>>>>>>>> Delaying the >>>>>>>>>> HTML is particularly bad because it delays the browser's discovery >>>>>>>>>> of all >>>>>>>>>> of the other resources on the page. Preload works with the normal >>>>>>>>>> document >>>>>>>>>> parsing and resource discovery, letting preloaded resources intermix >>>>>>>>>> with >>>>>>>>>> other important resources and giving the dev, browsers and origins >>>>>>>>>> more >>>>>>>>>> control over prioritization. >>>>>>>>>> >>>>>>>>>> On Friday, June 25, 2021 at 7:32:05 PM UTC-4 Brad Lassey wrote: >>>>>>>>>> >>>>>>>>>>> On Fri, Jun 25, 2021, 6:58 PM Andrew Wilder < >>>>>>>>>>> and...@andrewwilder.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Interesting, thanks Brad. >>>>>>>>>>>> >>>>>>>>>>>> I'd imagine that the performance benefit is actually greater >>>>>>>>>>>> for sites that don't use a CDN at all, since one RT is likely to >>>>>>>>>>>> take much >>>>>>>>>>>> longer >>>>>>>>>>>> >>>>>>>>>>> Due to initial window sizes, one RT worth of data is measured in >>>>>>>>>>> bytes, not time and does not vary based on round trip times. >>>>>>>>>>> >>>>>>>>>>>> ... so if you're only looking at CDNs, that might explain part >>>>>>>>>>>> of the difference? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We looked at all sites that were using Push, but in addition cut >>>>>>>>>>> the data by CDN to look for correlations. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> With the extremely tight requirements of Core Web Vitals, one >>>>>>>>>>>> round-trip's time potentially *could* make a significant >>>>>>>>>>>> difference in some cases. I was recently working on a site where >>>>>>>>>>>> I just >>>>>>>>>>>> couldn't get the Largest Contentful Paint metric to pass the 75th >>>>>>>>>>>> percentile of 2.5s in CRuX. I was stuck, soooo close, at 2.6s. >>>>>>>>>>>> (And it was >>>>>>>>>>>> testing great in Lab Data...just not in the field data, >>>>>>>>>>>> frustratingly) >>>>>>>>>>>> >>>>>>>>>>> I'd suggest you look at how big your initial resources are and >>>>>>>>>>> what's left over after the initial window. Again, the reference to >>>>>>>>>>> a round >>>>>>>>>>> trip is to the amount of data, not time. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> A roundtrip can take well over 100ms, so that alone could be >>>>>>>>>>>> enough to shave off 0.1s under the right conditions, or maybe >>>>>>>>>>>> more, to get >>>>>>>>>>>> the site to pass CWV. But I also stopped short of actually >>>>>>>>>>>> bothering >>>>>>>>>>>> to implement and test this when I saw this thread (I wasn't even >>>>>>>>>>>> sure if >>>>>>>>>>>> Chrome was still working for Server Push or not -- though I see >>>>>>>>>>>> that was >>>>>>>>>>>> answered a few messages back.) >>>>>>>>>>>> >>>>>>>>>>>> I don't think I would have argued this point before core web >>>>>>>>>>>> vitals, since one round-trip does seem nearly negligible -- but >>>>>>>>>>>> because now >>>>>>>>>>>> we have *absolute* metrics we need to hit, which are pretty >>>>>>>>>>>> tough in some cases, I think keeping this one additional tool in >>>>>>>>>>>> the >>>>>>>>>>>> toolbelt may be worthwhile... >>>>>>>>>>>> >>>>>>>>>>>> Thanks again, >>>>>>>>>>>> Andrew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Jun 25, 2021 at 3:28 PM Brad Lassey < >>>>>>>>>>>> las...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Jun 25, 2021, 4:53 PM Andrew Wilder < >>>>>>>>>>>>> and...@andrewwilder.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Brad, thanks for the clarification. We're definitely >>>>>>>>>>>>>> utilizing preload -- that's pretty much "table stakes" for >>>>>>>>>>>>>> passing Core Web >>>>>>>>>>>>>> Vitals at this point. We're also utilizing many other tools, >>>>>>>>>>>>>> including >>>>>>>>>>>>>> Critical Path CSS and delaying JavaScript until after user >>>>>>>>>>>>>> interaction. >>>>>>>>>>>>>> Those are far more complicated to implement properly than Server >>>>>>>>>>>>>> Push >>>>>>>>>>>>>> (especially with Cloudflare's excellent implementation, as >>>>>>>>>>>>>> Francesco >>>>>>>>>>>>>> pointed out). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The new Page Experience requirements from Google have changed >>>>>>>>>>>>>> the game when it comes to site speed. Previously, speed was >>>>>>>>>>>>>> known to be a >>>>>>>>>>>>>> ranking factor, but the details were secret, and it was more of a >>>>>>>>>>>>>> "relative" factor compared to the competition. "Just be faster >>>>>>>>>>>>>> than your >>>>>>>>>>>>>> competition" was sufficient before. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But with Core Web Vitals, the requirements are now absolute >>>>>>>>>>>>>> criteria, and it's pass/fail regardless of other sites in your >>>>>>>>>>>>>> vertical. >>>>>>>>>>>>>> There's no gray area here -- and for many sites, passing all >>>>>>>>>>>>>> three CWV >>>>>>>>>>>>>> criteria, while keeping the features that site owners need, is >>>>>>>>>>>>>> quite >>>>>>>>>>>>>> challenging. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Furthermore, you mentioned "this depreciation represents a >>>>>>>>>>>>>> low risk of web breakage." But keeping Server Push is not >>>>>>>>>>>>>> detrimental - it >>>>>>>>>>>>>> has *zero risk* of web breakage. So why remove support for >>>>>>>>>>>>>> it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> So it seems we have one department of Google (Search) pushing >>>>>>>>>>>>>> for a faster web, and another Department (Chrome) considering >>>>>>>>>>>>>> taking away a >>>>>>>>>>>>>> tool that, with proper implementation, should actually help >>>>>>>>>>>>>> achieve that >>>>>>>>>>>>>> goal. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Having said that, the truly important question that we're >>>>>>>>>>>>>> kind of dancing around is:* Is Server Push actually >>>>>>>>>>>>>> beneficial? * >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the answer to that is "yes," then I think it's better for >>>>>>>>>>>>>> Chrome to keep supporting it -- and, instead of killing it, to >>>>>>>>>>>>>> make efforts >>>>>>>>>>>>>> to increase adoption. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But if you're able to demonstrate that, when properly >>>>>>>>>>>>>> implemented, it has no *actual *speed/CWV benefits compared >>>>>>>>>>>>>> to using <preload> links in the <head>, I'll be grateful because >>>>>>>>>>>>>> it means I >>>>>>>>>>>>>> don't have to spend time finding that out on my own. :) >>>>>>>>>>>>>> >>>>>>>>>>>>> Our data shows that it is not providing a speed benefit in >>>>>>>>>>>>> practice and in fact is an overall slight performance regression >>>>>>>>>>>>> for Chrome >>>>>>>>>>>>> users. >>>>>>>>>>>>> >>>>>>>>>>>>> As far as differentiating "proper" use versus naive use, I cut >>>>>>>>>>>>> the data by which CDN hosted each domain and didn't see any one >>>>>>>>>>>>> CDN with a >>>>>>>>>>>>> net performance benefit, which I interpret as not indicating that >>>>>>>>>>>>> there is >>>>>>>>>>>>> necessarily a proper vs improper way to use the feature. This >>>>>>>>>>>>> intuitively >>>>>>>>>>>>> makes sense as the theoretical potential benefit over preload is >>>>>>>>>>>>> vanishingly small (1 RT worth of data minus your initial >>>>>>>>>>>>> resource) and >>>>>>>>>>>>> depending on the situation very possibly nil, versus the >>>>>>>>>>>>> relatively high >>>>>>>>>>>>> penalty of pushing the wrong thing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks again, >>>>>>>>>>>>>> Andrew >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Jun 25, 2021 at 1:25 PM Francesco Montanari < >>>>>>>>>>>>>> francesco...@outlook.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> It's not necessarily complex to implement for the developer. >>>>>>>>>>>>>>> For example, Cloudflare gives it by default, you just need >>>>>>>>>>>>>>> to add the HTTP preload header ( >>>>>>>>>>>>>>> https://www.cloudflare.com/it-it/website-optimization/http2/serverpush/ >>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>> and they have a smart implementation of it, they push assets >>>>>>>>>>>>>>> only at the first visit, they don't push them again when they >>>>>>>>>>>>>>> know the >>>>>>>>>>>>>>> browser should have it already in its cache. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> They also were the first to offer SSL for free to everyone >>>>>>>>>>>>>>> in 2014, and today nobody would pay for a SSL cert. So good >>>>>>>>>>>>>>> things take >>>>>>>>>>>>>>> time to spread... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It's just a matter of time, when the WordPress themes start >>>>>>>>>>>>>>> adding the preload HTTP header for their resources (it's a >>>>>>>>>>>>>>> one-liner in >>>>>>>>>>>>>>> PHP), all the wordpress sites which are on cloudflare will >>>>>>>>>>>>>>> automatically >>>>>>>>>>>>>>> have HTTP push with zero configuration, and the usage stats >>>>>>>>>>>>>>> will rise as >>>>>>>>>>>>>>> well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Friday, 25 June 2021 at 22:58:41 UTC+3 >>>>>>>>>>>>>>> las...@chromium.org wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Andrew, >>>>>>>>>>>>>>>> I just want to clarify one point, we are proposing to >>>>>>>>>>>>>>>> depreciate and remove HTTP Push because it has not proven to >>>>>>>>>>>>>>>> provide >>>>>>>>>>>>>>>> performance benefits over other, less complex and technically >>>>>>>>>>>>>>>> burdensome >>>>>>>>>>>>>>>> techniques such as preload (which I would encourage you to >>>>>>>>>>>>>>>> look at if you >>>>>>>>>>>>>>>> haven't already). The discussion of the amount of usage of >>>>>>>>>>>>>>>> Push is largely >>>>>>>>>>>>>>>> making the case that this depreciation represents a low risk >>>>>>>>>>>>>>>> of web >>>>>>>>>>>>>>>> breakage. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Brad >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Jun 25, 2021, 1:08 PM Andrew Wilder < >>>>>>>>>>>>>>>> and...@andrewwilder.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sorry, I meant to say that Origin Summary CLS is just over >>>>>>>>>>>>>>>>> 0.10, and/or LCP is 2.6s or 2.7s. Just wanted to clear that >>>>>>>>>>>>>>>>> up so you >>>>>>>>>>>>>>>>> don't think I don't know what I'm talking about! 😉 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Friday, June 25, 2021 at 10:02:13 AM UTC-7 Andrew >>>>>>>>>>>>>>>>> Wilder wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I run an agency that supports and maintains over 500 >>>>>>>>>>>>>>>>>> WordPress sites -- and we do a lot of site speed >>>>>>>>>>>>>>>>>> optimization work. Most of >>>>>>>>>>>>>>>>>> them are food blogs, and because of their complexity, it's >>>>>>>>>>>>>>>>>> very difficult >>>>>>>>>>>>>>>>>> to get them to pass the three Core Web Vitals requirements >>>>>>>>>>>>>>>>>> (especially LCP >>>>>>>>>>>>>>>>>> and CLS). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've been experimenting with Server Push as a way to get >>>>>>>>>>>>>>>>>> assets loaded faster -- especially web fonts, which are >>>>>>>>>>>>>>>>>> often a source of >>>>>>>>>>>>>>>>>> shifts, as they switch from the default fallback font to the >>>>>>>>>>>>>>>>>> web font. >>>>>>>>>>>>>>>>>> Often we run into situations where the Origin Summary CLS is >>>>>>>>>>>>>>>>>> 2.6 or 2.7 >>>>>>>>>>>>>>>>>> seconds. Being able to get fonts loaded earlier may help >>>>>>>>>>>>>>>>>> prevent shifts as >>>>>>>>>>>>>>>>>> they load; or to shave off even 0.1 second for the LCP >>>>>>>>>>>>>>>>>> element (especially >>>>>>>>>>>>>>>>>> if it's an image) may be enough to get the site to pass CWV >>>>>>>>>>>>>>>>>> completely. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On some sites we exhausted other ways to speed things up >>>>>>>>>>>>>>>>>> to pass CWV, and it was starting to look like Server Push >>>>>>>>>>>>>>>>>> might be able to >>>>>>>>>>>>>>>>>> get us across the finish line. But I paused on getting >>>>>>>>>>>>>>>>>> further into >>>>>>>>>>>>>>>>>> development on this, because I found this thread! >>>>>>>>>>>>>>>>>> Unfortunately, you're now >>>>>>>>>>>>>>>>>> creating a self-fulfilling prophecy of killing off Server >>>>>>>>>>>>>>>>>> Push. By >>>>>>>>>>>>>>>>>> announcing that you're considering removing it -- primarily >>>>>>>>>>>>>>>>>> because not >>>>>>>>>>>>>>>>>> enough people use it -- you're discouraging further people >>>>>>>>>>>>>>>>>> to start using >>>>>>>>>>>>>>>>>> it! Oh, the irony. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Considering Google's push on site speed and Core Web >>>>>>>>>>>>>>>>>> Vitals, it seems quite contradictory for you to disable >>>>>>>>>>>>>>>>>> Server Push. >>>>>>>>>>>>>>>>>> Instead, it would be far better to invest more resources >>>>>>>>>>>>>>>>>> into helping >>>>>>>>>>>>>>>>>> people utilize it -- and making it more effective to help >>>>>>>>>>>>>>>>>> improve speed and >>>>>>>>>>>>>>>>>> user experience. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Friday, June 25, 2021 at 8:45:09 AM UTC-7 Maxim >>>>>>>>>>>>>>>>>> Makarov wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please don't remove HTTP/2 Server Push support >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Monday, June 21, 2021 at 5:32:25 PM UTC+3 >>>>>>>>>>>>>>>>>>> b...@chromium.org wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Francesco, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Responding to the first part of your email only: no, >>>>>>>>>>>>>>>>>>>> HTTP/2 push is currently not disabled by default or >>>>>>>>>>>>>>>>>>>> removed from Chrome. >>>>>>>>>>>>>>>>>>>> However, there is a 1% holdback experiment running on >>>>>>>>>>>>>>>>>>>> Stable channel to >>>>>>>>>>>>>>>>>>>> allow monitoring of *hypothetical* performance benefits. >>>>>>>>>>>>>>>>>>>> If push does not >>>>>>>>>>>>>>>>>>>> work for you, your browser session might have been >>>>>>>>>>>>>>>>>>>> randomly assigned to the >>>>>>>>>>>>>>>>>>>> experiment. In that case, restarting Chrome will fix it >>>>>>>>>>>>>>>>>>>> (with 99% >>>>>>>>>>>>>>>>>>>> probability). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Bence >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Sat, Jun 19, 2021 at 3:58 PM Francesco Montanari < >>>>>>>>>>>>>>>>>>>> francesco...@outlook.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Is it already removed? I've implemented it but it >>>>>>>>>>>>>>>>>>>>> doesn't seem to work in Chrome. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Anyway, please don't kill it. >>>>>>>>>>>>>>>>>>>>> Now that Google Search is deploying the "web vitals" >>>>>>>>>>>>>>>>>>>>> update, which makes the loading speed a key factor for >>>>>>>>>>>>>>>>>>>>> ranking, more and >>>>>>>>>>>>>>>>>>>>> more developers are working to improve the sites speed, >>>>>>>>>>>>>>>>>>>>> and pushing key >>>>>>>>>>>>>>>>>>>>> assets would be very helpful. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Monday, 7 June 2021 at 23:25:02 UTC+3 rektide wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 30, 2020 at 2:11 PM Brad Lassey < >>>>>>>>>>>>>>>>>>>>>> las...@chromium.org> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 23, 2020 at 10:25 PM Morgaine < >>>>>>>>>>>>>>>>>>>>>>> rek...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> As I stated in the very first reply to this thread, >>>>>>>>>>>>>>>>>>>>>>>> it is a horrific tragedy that the situation is like >>>>>>>>>>>>>>>>>>>>>>>> this. It's been HALF A >>>>>>>>>>>>>>>>>>>>>>>> DECADE OF IGNORING DEVELOPERS on >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/issues/65 and >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/issues/607 , who >>>>>>>>>>>>>>>>>>>>>>>> have begged for fetch to support push, have BEGGED, & >>>>>>>>>>>>>>>>>>>>>>>> gotten no where. To >>>>>>>>>>>>>>>>>>>>>>>> say that the fetch spec does not mention push is to >>>>>>>>>>>>>>>>>>>>>>>> spit in our faces. This >>>>>>>>>>>>>>>>>>>>>>>> is farce & tragedy. Perhaps it's only ignorance you >>>>>>>>>>>>>>>>>>>>>>>> speak from, but I can >>>>>>>>>>>>>>>>>>>>>>>> not be more hurt to hear you say this. I have repeated >>>>>>>>>>>>>>>>>>>>>>>> time & time again in >>>>>>>>>>>>>>>>>>>>>>>> countless threads the desires for fetch to PLEASE FOR >>>>>>>>>>>>>>>>>>>>>>>> THE LOVE OF GOD >>>>>>>>>>>>>>>>>>>>>>>> support fetch. It's insulting that there has been zero >>>>>>>>>>>>>>>>>>>>>>>> progress. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am sorry that my words had this effect on you. I >>>>>>>>>>>>>>>>>>>>>>> believe the use cases that you've articulated are being >>>>>>>>>>>>>>>>>>>>>>> addressed with >>>>>>>>>>>>>>>>>>>>>>> WebTransport (https://github.com/w3c/webtransport/). >>>>>>>>>>>>>>>>>>>>>>> If you don't believe so, can you file issues there to >>>>>>>>>>>>>>>>>>>>>>> make sure they are >>>>>>>>>>>>>>>>>>>>>>> properly considered? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> It seems farcical to me that we are going to need to >>>>>>>>>>>>>>>>>>>>>> run HTTP3 over WebTransport to get a usable >>>>>>>>>>>>>>>>>>>>>> implementation of Push. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The browser should be good at HTTP. We should have >>>>>>>>>>>>>>>>>>>>>> these capabilities. Deciding to make everyone invent and >>>>>>>>>>>>>>>>>>>>>> bring their own >>>>>>>>>>>>>>>>>>>>>> userland WebTransport stack to be able to tell that an >>>>>>>>>>>>>>>>>>>>>> HTTP resource was >>>>>>>>>>>>>>>>>>>>>> pushed is a huge waste of bandwidth to send that >>>>>>>>>>>>>>>>>>>>>> userland stack, & a >>>>>>>>>>>>>>>>>>>>>> colossal mass of complexity to do the tunneling, & >>>>>>>>>>>>>>>>>>>>>> generates a far far more >>>>>>>>>>>>>>>>>>>>>> complex networking situation than if the browser would >>>>>>>>>>>>>>>>>>>>>> implement the one >>>>>>>>>>>>>>>>>>>>>> optional part of HTTP. Where-as before an a service >>>>>>>>>>>>>>>>>>>>>> might have run on >>>>>>>>>>>>>>>>>>>>>> HTTP3, pushed a resource, & seen it arrive, the service >>>>>>>>>>>>>>>>>>>>>> must host an >>>>>>>>>>>>>>>>>>>>>> WebTransport tunnel that carries HTTP3 inside of it. Now >>>>>>>>>>>>>>>>>>>>>> we have to worry >>>>>>>>>>>>>>>>>>>>>> about X-Forwarded-For like concerns. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> WebPush Protocol already takes advantage of these >>>>>>>>>>>>>>>>>>>>>> capabilities, for example, to create a simple to >>>>>>>>>>>>>>>>>>>>>> implement, elegant >>>>>>>>>>>>>>>>>>>>>> notification service, used by all browsers: but without >>>>>>>>>>>>>>>>>>>>>> the Fetch standards >>>>>>>>>>>>>>>>>>>>>> I linked, it is unusable for such obvious cause. Without >>>>>>>>>>>>>>>>>>>>>> Push, we grow >>>>>>>>>>>>>>>>>>>>>> complex systems like grpc-web, which are partial, >>>>>>>>>>>>>>>>>>>>>> incomplete, radically >>>>>>>>>>>>>>>>>>>>>> complex alternatives to what the browser ought just be >>>>>>>>>>>>>>>>>>>>>> able to do, what >>>>>>>>>>>>>>>>>>>>>> only the most minor, long requested additions to Push >>>>>>>>>>>>>>>>>>>>>> would have allowed. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> And now here we are, building Early Hints to try to >>>>>>>>>>>>>>>>>>>>>> reclaim only the most minor, smallest of advantages Push >>>>>>>>>>>>>>>>>>>>>> gave us. Focused >>>>>>>>>>>>>>>>>>>>>> only on this one tiny bit of the puzzle. And told that >>>>>>>>>>>>>>>>>>>>>> we must DIY >>>>>>>>>>>>>>>>>>>>>> alternatives if we want them, using WebTransport, and >>>>>>>>>>>>>>>>>>>>>> told that this web >>>>>>>>>>>>>>>>>>>>>> browser will not support the one optional component of >>>>>>>>>>>>>>>>>>>>>> the HTTP standard. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Words have not had an effect on me. This decision >>>>>>>>>>>>>>>>>>>>>> continues to have a profound & disturbing effect on me, >>>>>>>>>>>>>>>>>>>>>> and it should be >>>>>>>>>>>>>>>>>>>>>> reversed. Hopefully before we need to start implementing >>>>>>>>>>>>>>>>>>>>>> HTTP3 over >>>>>>>>>>>>>>>>>>>>>> WebTransport, but I rather suspect not. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06cb378d-e243-4200-9af5-5eb2868388bcn%40chromium.org >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06cb378d-e243-4200-9af5-5eb2868388bcn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to blink-dev+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfSJ7kapqg0-S-WQfTBcuLBrVuazwswo6gwoFWV3m4jk%3DA%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfSJ7kapqg0-S-WQfTBcuLBrVuazwswo6gwoFWV3m4jk%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKcm_gOqvdCDfNvv6SqJqeQaLnhXg8jOL%3D7a945ok2qgAt5xXg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKcm_gOqvdCDfNvv6SqJqeQaLnhXg8jOL%3D7a945ok2qgAt5xXg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKcm_gNiGxO_ag375Lcxha1i5Xt9yrZKRuCzFbUZX6Dx7Yvk8A%40mail.gmail.com.
