I am confused with the current status of http2 server push. When I google "http 2 server push" there are many search results, among them 2 results stand out,
Chrome to remove HTTP/2 Push published in 2020-12-01
HTTP/2 Push is dead published in 2020-11-12
Both of them mentioned Chrome has remove server push, but other than these 2 articles there are still many articles published in 2021 introducing/explaining http2 server push.
So what exactly is the status of http2 server push as 2022 is coming ?
I am not asking an opinion-based question but a fact-based assessment. If Chrome does kills it I think it is pretty much a fact that it is dead.
--- update ---
I came across this article https://developer.chrome.com/blog/early-hints/ (published June 23, 2022). So it seems that the proposed 103 Early Hints is their answer to unsuccessful http2 server push.
As a web site option it is pretty much dead. As well as Chrome’s stated position (which has not changed but also not been actioned… yet) there is a new consideration which will likely kill it off first: HTTP/3.
HTTP/3 is already supported by 12% of websites and 20% of web traffic despite not even officially being signed off yet (though it’s as near as can be).
Chrome has not implemented push on HTTP/3 (and seem highlighlyunlikely to given their stated position to drop it for HTTP/2) and because of that neither has Cloudflare (one of the leading CDNs working on HTTP/3 and powering 10% of the internet). I’m not sure of other’s position on this but with those two out that’s a big chunk of support.
Some sites will always languish on HTTP/1.1 (without push), those that adopted HTTP/2 quickly and completely enough to use push willl likely move to HTTP/3 (especially if behind a CDN like Cloudflare) so there really is very little that’ll be left behind on HTTP/2 to be able to use push. So what little usage there is of HTTP/2 push (~1.25% of sites) will dwindle anyway until it’s a negligible amount (if it isn’t already!).
Push is dead for web browsing. Though more recently there has been a big push (pardon the pun!) by browsers and CDNs to support 103 Early Hints - a much safer, less risky option that can deliver many of the same benefits as push.
Related
I am currently making a server for dynamic and static files with Node. I'm trying to implement HTTP2. What surprises me is that it seems that the HTTP2 push does not support ETags!
When the client sends the headers to retrieve a file that starts with a push, and that it has accepted, it ignores the "IF-NONE-MATCH" header.
It's a waste, I do not understand the reason for this behavior. Is this the case or am I missing something?
As discussed in the comments the server pushes the resource, so there is no client request, so there is no Etag to send.
So HTTP/2 does support Etags - they just have no relevance for pushed requests.
And yes this does mean cached resources are ignored for Pushed resources - which is one of the big drawbacks of Push and why many people do not recommend using it. When a client sees the PUSH_PROMISE that a server sends before pushing a resource, it can reject it with a RST_STREAM request but by the time that makes it to the server often a good part (if not all) of the resource will have already been pushed.
There are a few ways around this:
You could track what has already been pushed using cookies for example. I've a simple example with Apache config here: https://www.tunetheweb.com/performance/http2/http2-push/. Of course that assumes that cookies and cache are in sync but they may not be (they can be cleared independently).
Some servers track what has already been pushed. Apache for example allows an HTTP/2 push diary to be configured (set to 256 items by default) which tracks items pushed on that connection. If you visit page1.html and it pushes styles.css, and then you visit page2.html and it also attempts to push styles.css Apache will not push it as it knows you already have it. However that only works if you are using the same connection. It you come back later on a new connection, but it's still in the cache then it will be re-pushed.
There was a proposal for Cache digests, which allow the browser to send an encoded list of what is in the cache at the start of any connection, and the server could use that to know whether to push an item or not. However work on that has been stopped recently as there were some privacy concerns about this.
Ultimately HTTP/2 Push has proven to be tricky to make useful and usage of it is incredibly low because of this. In large part due to this, but also because it is complex and there are other implication issues. Even if all those were solved, it's still easy to over push resources when perhaps it's best to let the browser request the resources in the order it knows it needs them. The Chrome team have even talked about turning it off and not supporting it.
Many are recommending using Early Hints with status code 103 instead, as it tells the browser what to request, rather than just pushing it. The browser can then use all it's usual knowledge (what's in the cache, what priority it should be requested with...etc.) rather than overriding all this like Push does.
Cheap plug, but if interested in this then Chapter 5 of my recently published book discusses this all in a lot more detail then can be squeezed into an answer on Stack Overflow.
I have a hosted webserver with http/2 (medium fast) and additionally I have a space on a fast CDN-Server with only http/1.1.
Is it recommended to load some ressources from the CDN or should I use only the webserver because of http/2?
Loading too many recources from the CDN could be a bottleneck due to http/1.1?
Would be kind to get some hints...
You need to test. It really depends on your app, your users and your servers.
Under HTTP/1.1 you are limited to 6 connections to a domain. So hosting content on a separate domain (e.g. static.example.com) or loading from a CDN was a way to increase that limit beyond 6. These separate domains are also often cookie-less as they are on separate domains which is good for performance and security. And finally if loading jQuery from code.jquery.com then you might benefit from the user already having downloaded it for another site so save that download completely (though with the number of versions of libraries and CDNs the chance of having a commonly used library already downloaded and in the browser cache is questionable in my opinion).
However separate domains requires setting up a separate connection. Which means a DNS lookup, a TCP connection and usually an HTTPS handshake too. This all takes time and especially if downloading just one asset (e.g. jQuery) then those can often eat up any benefits from having the assets hosted on a separate site! This is in fact why browsers limit the connections to 6 - there was a diminishing rate of return in increasing it beyond that. I've questioned the value of sharded domains for a while because of this and people shouldn't just assume that they will be faster.
HTTP/2 aims to solve the need for separate domains (aka sharded domains) by removing the need for separate connections by allowing multiplexing, thereby effectively removing the limit of 6 "connections", but without the downsides of separate connections. They also allow HTTP header compression, reducing the performance downside to sending large cookies back and forth.
So in that sense I would recommended just serving everything from your local server. Not everyone will be on HTTP/2 of course but the support is incredible strong so most users should.
However, the other benefit of a CDN is that they are usually globally distributed. So a user on the other side of the world can connect to a local CDN server, rather than come all the way back to your server. This helps with connection time (as TCP handshake and HTTPS handshake is based on shorter distances) and content can also be cached there. Though if the CDN has to refer back to the origin server for a lot of content then there is still a lag (though the benefits for the TCP and HTTPS setup are still there).
So in that sense I would advise to use a CDN. However I would say put all the content through this CDN rather than just some of it as you are suggesting, but you are right HTTP/1.1 could limit the usefulness of that. That's weird those as most commercial CDNs support HTTP/2, and you also say you have a "CDN server" (rather than a network of servers - plural) so maybe you mean a static domain, rather than a true CDN?
Either way it all comes down to testing as, as stated at the beginning of this answer it really depends on your app, your users and your servers and there is no one true, definite answer here.
Hopefully that gives you some idea of the things to consider. If you want to know more, because Stack Overflow really isn't the place for some of this and this answer is already long enough, then I've just written a book which spends large parts discussing all this: https://www.manning.com/books/http2-in-action
This article mentions and this site seems designed to show that HTTPS can be faster than HTTP. I'm surprised; I thought HTTPS was just HTTP plus encryption, which adds a small, likely negligable amount of work but doesn't remove any.
Why might an HTTPS page load be faster than one over HTTP?
It's a bit of a con to be honest.
HTTPS is slower than HTTP. There's no denying that. HTTPS works over HTTP so has to do everything HTTP does and more. Now, with good web server config, the computational cost of HTTPS is almost non-existent to the average user on today's modern hardware but it is there. But it also slows down the first page render as it takes a few hundred extra milliseconds to set up the HTTPS connection. Again not a big deal for most people but it is there.
Now there is the argument that someone - be it a mobile network or ISP or whatever - can change HTTP by injecting ads and the like, potentially slowing down a website, but that's not the reason for the speed difference here.
The reason that website is faster is because it is using HTTP/2 when using HTTPS and not when using HTTP. HTTP/2 is faster than HTTP/1.1 - especially for websites with lots of resources.
Of course you can say that HTTP/2 is only available over HTTPS and while that is true*, the corollary is not - implementing HTTPS does not automatically give you HTTP/2.
*Well technically it's not true that HTTP/2 requires HTTPS as per the spec, but all the browser makers have said they will only support this over HTTPS so it basically is true to all intents and purposes.
Additionally the sample website loads 360 small and near identical (but crucially not identical) resources. Precisely the sort of thing that HTTP/2 is very good at. And while average web pages are growing, most of them don't load 360 near identical images - so that network latency is basically the only bottleneck. Most have other issues as well that are nothing to do with the network latency issues that HTTP/2 massively improves.
The speed gains for HTTP/2 are hugely impressive and it is the future and everyone should use it, as latency is a major bottleneck. But that test site is an extreme example of it. Depending on the exact site's make up, HTTP/2 will mostly offset the cost of HTTPS and in many cases more than offset it - but that does not mean HTTPS itself is faster.
There are very good reasons to use HTTPS, and the article is fantastic for listing them all (except for that first one). In my opinion HTTPS should be the default and everyone should move to it - precisely for the other reasons listed. But it's a lie to say HTTPS is faster that HTTP. Or, at the very least, it obfuscates the truth by not explaining why it can be faster. And then listing HTTP/2 as a second, seemingly unrelated, reason to further confuse the reader! I just don't understand why they couldn't combine these two points into one and fully explain this so questions like this didn't need to be asked? Same for that sample site - why is there no FAQ to explain why HTTPS is apparently faster?
Historically yes, https was http+ssl/tls, so it was slower
But now with spdy/http2, it's a new protocol, which can be faster than http when dealing with multiple requests:
it can compress headers, and if you send the same header multiple times (like cookies) it doesn't need to send it fully but just an id
if can reuse tcp connections, so it avoid the overload of opening multiple tcp connections and stream efficiently data
If you use some kind of network scanner (e.g. a component of an antivirus, proxy of firewall), it may scan plain HTTP traffic causing a slowdown. At the same time, it won't touch encrypted HTTPS traffic unless you installed a special root certificate that will help the intermediate scanner to process HTTPS traffic. So if there is some kind of intermediate service scanning HTTP traffic, but not HTTPS -- using HTTPS will be much faster.
So, we have nginx + spdy running for our SSL requests / responses.
All works good.
Unfortunately, spdy is SSL only at this point.
Now, our service is fairly ajax heavy.
We have the option of fairly quickly making the required changes so the requests are sent to our ssl handler and our ssl handler reverse proxies them to where they need to go.
Does spdy really speed things up that much? Would it be worth spending what will probably be a couple of hours to make chrome / latest firefox send our ajax requests to our ssl handler and have our ssl handler reverse proxy them where they need to go?
Notes:
a) This will only be active for a select group of white listed browsers (eg: chrome latest / firefox latest). Fairly simple js change there.
b) Yes, we know how to make http -> https ajax requests on these white listed browsers.
c) From our fairly extensive testing, the nginx + spdy combo works quite well. So yes, we know its slightly alpha/beta at this point. A small risk we are willing to take.
d) Bare in mind, our service is 90%+ ajax. Only initial entry is served via non-ajax, all other 'page views' are handled via ajax. So this has the potential to speed things up quite a bit for a large subset of our users.
Thanks.
Short answer: Hell yes.
Long answer: It depends. https://www.phusionpassenger.com is heavy on images. Loading the front page takes a lot of requests. By switching from plain HTTP to SPDY we reduced loading time by 25% because the browser can download more assets with fewer roundtrips. However SPDY requires recent Chrome and Firefox versions. In our case, most of our users are technical users so that's not a problem. If your visitors are mostly MSIE, or if you don't load assets in a way that would benefit from parallelism, then SPDY will not help you much. In all other cases SPDY is great.
We are currently working on an app that uses pusher.com to maintain a list of available people on our chat application.
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work. Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
So far, here is what I'm considering:
XMPP/BOSH
socket.io (self-hosted)
pubnub
As for the scale, we will probably have to handle 100+ messages per second and 10000 concurrent users. Nobody here has ever played with socket.io (or bosh), and we do not wish to have too much maintenance work (ie deal with many servers and such). So 2 or 3 self-hosted servers is ok, 10+ isn't.
Any thoughts?
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work.
This is incorrect. Pusher (who I work for) provide fallback for older browsers. HTTP-based fallback has started to be released to go alongside the existing Flash socket fallback. So, older versions of IE were already handled with the Flash socket fallback but the HTTP-based fallback will give near 100% browser coverage.
The November 2012 issues of the Pusher newsletter has the following:
We've always loved WebSockets, and since the beginning they have been our primary transport mechanism. While they are still the best way of sending data between applications, we do sometime have to resort to various trickery to negotiate troublesome proxies. By popular demand we are soon going to be bolstering our legacy support by adding HTTP based transport to our existing fallback options.
We have already deployed some provisional endpoints which apply in a set of limited conditions, and we'll be continuing the expansion of this feature over the next few months. If you want to have early access to this as a beta user, please get in touch with support#pusher.com.
In terms of cost:
Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
Have you contacted Pusher support explaining your use case? Discounts may be available.
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
There's a realtime web tech guide which has a good list of realtime web technology solutions (it's on my site and I maintain it). If you want to support IE then a solution which offers HTTP-based fallback is the safest bet.
I would personaly go with socket.io. It supports Internet Explorer 5.5+.
It supports various transports and uses the most-appropriate one to ensure browser compatibility without having special code to work with each browser. Here is the list of transports from the website:
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
You can see the full list of browser support here.
As for BOSH, here is a discussion on BOSH vs Websockets. If you go ahead with BOSH, you will be missing out on Websockets functionality that modern browsers support.
You should check out ScaleDrone as an affordable alternative to Pusher.