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/3841dd88-4320-4808-a77a-8c8cb10facdan%40chromium.org.
