Hello, In case you have not noticed, Early Hints is on track to ship in M103 (I2S <https://groups.google.com/a/chromium.org/g/blink-dev/c/8iIvkmZNUhU/m/c6a7OBvFAgAJ?utm_medium=email&utm_source=footer>, Chrome Status <https://chromestatus.com/guide/edit/5207422375297024>).
On Mon, Apr 25, 2022 at 4:09 PM Kenji Baheux <kenjibah...@chromium.org> wrote: > Hi Mitar, > > Thanks for the feedback, and sorry for the delay. > > The Authorization header should be supported in Early Hints. > Please share a concrete example if this doesn't work as you'd hope. > > Also, we would like Early Hints to be useful beyond the main request (page > navigation). > In particular, with SPAs, the current scope would have a limited impact. > However, there is some additional trickiness in the code with regards to > CORS/CORP/CORB that the team needs to figure out. > > A few more comments & questions inline: > > On Tue, Apr 12, 2022 at 7:29 PM Mitar <mmi...@gmail.com> wrote: > >> Hi! >> >> Kenji, I have been following progress around HTTP2 push and it looks to >> me that all the focus is on HTTP2 pushes which happen at the page loading >> time. But there are also pushes which happen later on, after the page has >> already loaded. Concrete example: I have an app which subscribes to >> notifications from the server (using SSE or WebSockets), when it gets a >> notification that some resource changed, the app makes a HTTP request to >> fetch the new resource (to then update DOM reactively). By separating >> notification from payload and not pushing data itself over WebSocket, those >> resources can be cached so that the next time the page loads they can be >> reused. With HTTP2 push the server can send the resource to the client >> together with the notification itself, so that data is available together >> with the notification. I do not see something like possible with Early >> Hints? >> > > IIRC, H2/Push isn't really well-suited for the notification part though, > and the push design has proven problematic in practice (i.e. overpushing). > > That said, going back to your SSE/WebSocket (notification / commands) + > Fetch based solution, I think there might be an opportunity. > Mark Nottingham recently wrote an article > <https://www.mnot.net/blog/2022/02/20/websockets> which seems related. > What Mark calls Intermediation in his article is appealing, including for > browsers. > > If the browser had an understanding that new resources are being announced > through this notification channel, it could take care of the rest (i.e. > only load what's missing, cache them, etc) and make sure that everything is > working as usual (e.g. service worker) without requiring web developers to > roll their own workarounds. > > Perhaps, we would see a lot more adoption of such a fancy technique if it > embraced the existence of intermediaries eager to help. > It could even be something that is announced in the response for the main > resource, which the browser would subscribe to automatically. > > Mark suggests options for SSE, WebSocket/WebTransport, or HTTP itself. > I'm a bit skeptical of the last one because that would be an entirely new > endeavor. > > Augmenting SSE seems less risky / faster, and possibly features a better > adoption story (already deployed / well-understood). > I'm assuming that we could define a special type of event (binary even?) > that intermediaries including browsers would understand (i.e. the data > would be some usual HTTP lingo). > *Caveat: none of this has been vetted by the engineering team, so I could > be extremely naive about the cost & risks.* > > > Thoughts? > > >> >> Another limitation of Early Hints seems to be that resources which >> require Authorization header cannot be preloaded, am I mistaken? With HTTP2 >> push you can push such a resource and add a corresponding anticipated >> header. >> >> >> Mitar >> >> On Wed, Mar 16, 2022 at 7:05 AM Kenji Baheux <kenjibah...@chromium.org> >> wrote: >> >>> Hi Thomas, >>> >>> I'm part of the team working on Early Hints. >>> >>> On Wed, Mar 16, 2022 at 6:58 AM BIANCONI Thomas < >>> thomas.bianc...@loreal.com> wrote: >>> >>>> I am sad to read this... >>>> A new step before the deprecation of server push. >>>> >>>> I would love to see comparaison in term of performance between server >>>> push and early hint. >>>> On a pure theoric point of view early hint starts during the html >>>> parsing whereas the server push start with the response header. So server >>>> push by design is better. >>>> >>> >>> If I understand correctly, I believe that there is some misunderstanding >>> about Early Hints. >>> Clearly, it's on us to make this easier to understand. Sorry... >>> We'll put extra efforts in providing clear & detailed developer >>> documentation when Early Hints ships. >>> >>> In the meantime, here is a high level summary of what Early Hints is, >>> and how it works: >>> >>> 1. Early Hints is a status code (103) which is used in HTTP >>> responses while the server is preparing the final response. This >>> intermediate response can include other HTTP headers, in particular LINK >>> REL headers such as preload or preconnect. >>> 2. In some cases, it can take time for the server to prepare the >>> main response: accessing the DB, having an edge cache go talk to the >>> origin >>> server, etc. So, the idea is to speed up overall page load times by >>> giving >>> the browser hints about what it might do while waiting for the actual >>> response. Typically, the hints are about critical sub-resources or >>> origins >>> which would be used by the final response. >>> 3. The browser processes these hints, and decides to preconnect or >>> preload any missing origins/resources while waiting for the final 200 OK >>> response (usually containing the main resource). Since the browser got >>> some >>> work done ahead of time, the overall page load time is improved. >>> >>> In other words, the key point here is that Early Hints doesn't start >>> during the HTML parsing: it starts with the non-final response headers, way >>> before HTML parsing kicks in since that is blocked on the final response. >>> >>> See this section of the RFC >>> <https://datatracker.ietf.org/doc/html/rfc8297#:~:text=The%20following%20example%20illustrates%20a%20typical%20message%20exchange%20that%0A%20%20%20involves%20a%20103%20(Early%20Hints)%20response.> >>> for an example of how this looks at the HTTP level. >>> >>> >>> >>> >>>> Regarding the complexity to put it in place early hints is easy when >>>> you serve different page but for Single Page Application the build process >>>> don't generate differentiate serving based on the route since the routing >>>> of the application is generally managed in the frontend. >>>> So for Single Page Application to managed server push not global to all >>>> route it will more complexe to include it in the build process. >>>> >>> >>> The MPA angle is indeed easier, deployment wise. >>> We'll look into the SPA case in more details including discussion with >>> various framework authors. >>> >>> I hope this was useful. >>> >>> >>>> >>>> Just wanted to share my feeling about this whole topic. >>>> >>>> >>>> >>>> Thanks >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> *Thomas BIANCONI* >>>> >>>> Head of Data Technologies >>>> >>>> & Data Privacy Champion >>>> >>>> Global CDMO Team >>>> >>>> 41 Rue Martre - 92110 Clichy >>>> >>>> *Mob* : +33 (0) 6 15 35 33 57 <+33%206%2015%2035%2033%2057> >>>> >>>> *Ph* : +33 (0) 1 47 56 45 95 <+33%201%2047%2056%2045%2095> >>>> >>>> *E-mail* : thomas.bianc...@loreal.com >>>> >>>> ------------------------------ >>>> *De :* Chris Harrelson <chris...@chromium.org> >>>> *Envoyé :* mercredi 2 mars 2022 18:51 >>>> *À :* Daisuke Enomoto <denom...@chromium.org> >>>> *Cc :* blink-dev <blink-dev@chromium.org>; las...@chromium.org < >>>> las...@chromium.org>; pme...@chromium.org <pmee...@chromium.org>; >>>> Francesco Montanari <francesco.montan...@outlook.com>; Maxim Makarov < >>>> maxpain...@gmail.com>; b...@chromium.org <b...@chromium.org>; >>>> dsch...@chromium.org <dschin...@chromium.org>; ians...@chromium.org < >>>> iansw...@chromium.org>; rektide <rekt...@gmail.com>; Ben Lesh < >>>> b...@benlesh.com>; Andrew Wilder <and...@andrewwilder.com>; Vito De >>>> Giosa <vito.degi...@gmail.com> >>>> *Objet :* Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC >>>> server push >>>> >>>> Notice: External mail >>>> 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://urldefense.com/v3/__https://chromestatus.com/feature/5207422375297024__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzNtkXfmC$>) >>>> 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://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$> >>>> 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://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$> >>>> 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 >>>> <https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/51__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzGDYL5uJ$> >>>> & 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 >>>> <https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/51__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzGDYL5uJ$> >>>> 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 >>>> <https://urldefense.com/v3/__https://developer.mozilla.org/en-US/docs/Web/API/Push_API__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzHd5HvEU$>) >>>> 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/ >>>> <https://urldefense.com/v3/__https://www.cloudflare.com/it-it/website-optimization/http2/serverpush/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzN4sNSwd$> >>>> ) >>>> 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 >>>> <https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/65__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzEiQWO2T$> >>>> and https://github.com/whatwg/fetch/issues/607 >>>> <https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/607__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzFbdSMTO$> >>>> , 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/ >>>> <https://urldefense.com/v3/__https://github.com/w3c/webtransport/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzAN4tjvn$>). >>>> 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://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06cb378d-e243-4200-9af5-5eb2868388bcn*40chromium.org?utm_medium=email&utm_source=footer__;JQ!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzLVyveu0$> >>>> . >>>> >>>> -- >>>> 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://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT*2BpZ60evzZSUvn6jH00pVc*2BXObtK9GSk0Fw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzAh3D4lp$> >>>> . >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "blink-dev" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/K3rYLvmQUBY/unsubscribe >>>> <https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/topic/blink-dev/K3rYLvmQUBY/unsubscribe__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzMGsZ9qr$> >>>> . >>>> To unsubscribe from this group and all its topics, 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://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ*2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSU!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzCZd8FK4$> >>>> . >>>> >>>> This message and any attachments are confidential and intended solely >>>> for the addressees. >>>> If you receive this message in error, please delete it and immediately >>>> notify the sender. If the reader of this message is not the intended >>>> recipient, you are hereby notified that any unauthorized use, copying or >>>> dissemination is prohibited. E-mails are susceptible to alteration. Neither >>>> LOREAL nor any of its subsidiaries or affiliates shall be liable for the >>>> message if altered, changed or falsified. >>>> >>>> C1 - Internal use >>>> >>>> -- >>>> 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/PA4PR05MB90898054ACE52E707A43508D81109%40PA4PR05MB9089.eurprd05.prod.outlook.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PA4PR05MB90898054ACE52E707A43508D81109%40PA4PR05MB9089.eurprd05.prod.outlook.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/CADWWn7WEBYWRR3EAu0-XHZ9DAce8ifhxtm11b7xPyLS_ghSrsA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADWWn7WEBYWRR3EAu0-XHZ9DAce8ifhxtm11b7xPyLS_ghSrsA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> http://mitar.tnode.com/ >> https://twitter.com/mitar_m >> > -- 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/CAA5e699VyXBhURJetLhJWjuwYxrhzVv7Gq9v_8W3mw7jx6xV%2Bg%40mail.gmail.com.
