Hi Grzegorz, HTTP/2 server push was disabled by default in Chrome 106[1]. You can achieve the almost the same latency speedup via preloading and prerendering (rel=preload [2] and rel=prerender) and HTTP Early Hints[3] (supported since Chrome 103) and speculation rules.
[1] https://developer.chrome.com/blog/removing-push/ [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload [3] https://developer.chrome.com/blog/early-hints/ Hope that helps. On Monday, October 16, 2023 at 1:41:53 AM UTC+3 Grzegorz Szeliga wrote: > Is this function still active? I was just getting around to using it to > speed up my site and here I find such threads of concern > > czwartek, 27 kwietnia 2023 o 21:14:40 UTC+2 Gerald Witichis napisał(a): > >> The reason is if your website is fast you don't need to buy CDN and >> Akamai (and the like) looses money. >> All this technical reasoning is false. >> Also fake are the statistics about saying nobody uses push. How could >> Akamai actually know how much traffic my site does with push? They simply >> can't. The only thing they can count is the number of their customers. >> But most stupid is Googles reasoning to disable a working feature in >> Chrome based on statistics. They had a very strong reason to come up with >> spdy and push in the first place. Simply leaving the feature as it is would >> not cost them a dime. But since it does harm to the CDN business the world >> is not allowed to enjoy fast sites with push. >> Oh the internet is slow I need a faster computer.... >> Also saying that because push is optional in http2, turning it off would >> leave Chrome HTTP/2 standard compliant is like saying a browser is HTTP/2 >> compliant if it downgrades to http/1.0 and gets the page. >> Push may be optional to use but it is THE killer feature of http2. Why >> should one use http2 insted? For header compression or binary - nope. With >> brotli or gzip there is already binary and why bother for a few headers. >> But every end is a new beginning. I look forward to the push enabled >> forks of the browsers. >> Goodbye Chrome. >> On Thursday, November 12, 2020 at 6:13:08 AM UTC+1 Samuel Williams wrote: >> >>> As someone who has implemented HTTP/2 push in both the client and >>> server, I fully support this change and would like to see it deprecated >>> from the RFCs. The complexity in both the client and the server is >>> non-trivial, and the benefit has not been proven even in isolation. >>> >>> The HTTP request/response model is well understood and lends itself to >>> relatively sane client and server interfaces. The addition of server push >>> extends clients and servers in an unnatural way, where a response can can >>> potentially trigger more responses than the client was interested in. When >>> you try to write code that handles this, the only abstraction that comes to >>> mind is a queue: >>> >>> response = client.request(path) >>> response.promises.each do |promise| >>> add_to_cache(promise) >>> end >>> response.body.read # etc >>> >>> But this is very unnatural to most users. Not to mention that this also >>> invites issues around concurrency. >>> >>> Browsers (and clients in general) are far better at knowing what >>> resources they need. My experience has been that HTTP/2 push can only helps >>> users on the first request. Looking at implementations like h2o, we see the >>> extreme level of complexity required to try and avoid superfluous pushing. >>> After the first request, the local browser has cached everything of >>> interest, and from that point on HTTP/2 push does not serve any purpose as >>> far as I can tell. >>> >>> The level of complexity introduced by this feature does not balance out >>> with the value it brings. >>> >>> To repeat, I fully support this change. >>> >>> Kind regards, >>> Samuel >>> On Thursday, November 12, 2020 at 3:26:20 PM UTC+13 Ian Swett wrote: >>> >>>> Anyone who objects should feel free to share data publicly which >>>> supports their case, as Akamai did a few years ago. That data was very >>>> mixed and not particularly compelling on average, and the metrics have >>>> degraded since then, so I expect the metrics would look worse today. >>>> >>>> On Wed, Nov 11, 2020 at 9:22 PM Jay Phelps <j...@outsmartly.com> wrote: >>>> >>>>> We disagree with this decision based on the real world data we have >>>>> seen and the products we build around Http/2 Push. Just making our >>>>> objection known. >>>>> >>>>> -- >>>>> Jay Phelps >>>>> Outsmartly >>>>> >>>>> On Wednesday, November 11, 2020 at 9:00:52 PM UTC-5 Ian Swett wrote: >>>>> >>>>>> To clarify, server push is an optimization in HTTP/2(and presumably >>>>>> HTTP/3) that is optional and there is no requirement to implement it in >>>>>> either spec. It does not exist in HTTP/1.1. This is not an indicatoin >>>>>> Chrome does not support HTTP(S), since clearly Chrome would be useless >>>>>> if >>>>>> that occurred, but rather about removing an optimization that was not >>>>>> widely used and when it was used, typically not used wisely. >>>>>> >>>>>> I support this change because I think efforts would be better spent >>>>>> elsewhere(ie: Alt-SVC, DoH, HTTP/3, ESNI, ...) >>>>>> >>>>>> Ian >>>>>> On Wednesday, November 11, 2020 at 8:35:24 PM UTC-5 Morgaine wrote: >>>>>> >>>>>>> On Wednesday, November 11, 2020 at 5:00:39 PM UTC-5 >>>>>>> las...@chromium.org wrote: >>>>>>> >>>>>>>> Chrome currently supports handling push streams over HTTP/2 and >>>>>>>> gQUIC, and this intent is about removing support over both protocols. >>>>>>>> Chrome does not support push over HTTP/3 and adding support is not on >>>>>>>> the >>>>>>>> roadmap. >>>>>>>> >>>>>>> >>>>>>> This is horrifying to hear. Please support the HTTP protocol. Please >>>>>>> do not remove support, roll back the web, just because we have not >>>>>>> figured >>>>>>> out yet the good ways to use an advanced feature. Please have a plan >>>>>>> for >>>>>>> supporting HTTP!!!!!!! This is so scary to hear, and so unacceptable. >>>>>>> >>>>>>> This is something that should make the web better. Web sites have >>>>>>> been slow to figure out how to make this feature effective. But I >>>>>>> believe >>>>>>> in it fully. Not shipping HTTP support in Chrome would certainly be the >>>>>>> death-knell for Push, and such a massive revolutionary change as Push >>>>>>> deserves to have a decade plus for us to figure out how to use it >>>>>>> effectively. Don't pull the plug on push like this. Don't. Please, >>>>>>> please, >>>>>>> don't. This is so scary to hear. I can not believe I am reading this. >>>>>>> >>>>>> -- 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/9b873f7f-8f6c-4a6e-9624-f2c9b9b1ee89n%40chromium.org.
