LGTM2 to remove with the condition that there be a public blog post specific to it that outlines (briefly is ok) what is happening, why, and recommended alternatives for developers.
Thanks! I appreciate the diligence and patience of the team, I recognize this has been a long process. On Wed, Aug 17, 2022 at 8:41 AM Alex Russell <slightly...@chromium.org> wrote: > Per today's OWNERS meeting, LGTM1 > > On Tuesday, August 16, 2022 at 10:41:57 AM UTC-7 jme...@google.com wrote: > >> So it will be disabled by default in 106 then? >> >> 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 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/75de20ed-1f99-4675-b589-c251738582c7n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75de20ed-1f99-4675-b589-c251738582c7n%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/CAOMQ%2Bw96opMf%3DYxj4SNeBFXm1hSJJKoQ2i9oPZvN3qf6GcALFQ%40mail.gmail.com.
