One of the main reasons why consumers have not adopted to use HTTP/2 Server Push is because usage would be centralized to static content, yet most CDN providers have not yet implemented a usable Architecture for HTTP/2 Push.
So rather than removing this useful feature (yes, it's useful), perhaps work with CDN providers to implement this feature so it can be utilized properly. On Wednesday, June 30, 2021 at 12:23:35 PM UTC-4 Vito De Giosa 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/524f5be4-a5b5-4567-947a-dffe18d24036n%40chromium.org.
