I'd like to move my client's site entirely to HTTPS in order to allow HTTP2 to work, however I was wondering is it ok (in the eyes of search engines) to serve older traffic (of which there is a lot and which would otherwise suffer a perf hit) that do not support HTTP2?
Is this dangerous to do from an SEO point of view? and
could you do the detection with tools like WURFL?
I want to stay current and offer improved perf/security to those on newer browsers but don't want those on older browsers in developing countries to suffer.
For what is worth, I did some tests a few weeks ago and I got the impression that Google's spiders don't see HTTP/2 yet. But as #sbordet pointed out the upgrade to HTTP/2 is optional, so just be sure to have a site that also responds to HTTP/1.1. Here are a few thoughts more:
Google's algorithms will penalize slower sites, but it is unlikely that you will take a big performance hit from using HTTPS in your servers.
Using HTTPS can actually boost your SEO. Doesn't have anything to do with HTTP/2.
Popular browsers that don't support HTTP/2: Safari and IE. Safari doesn't support any TLS crypto-suite compatible with HTTP/2, AFAIK. But that won't cause problems as long as you list HTTP/2-compatible suites first in your TLS server hello: ECDHE-RSA-AES128-GCM-SHA256 and ECDHE-RSA-AES256-GCM-SHA384 are the ones I know of. Then you can list weaker suites.
You don't need to serve different content depending on whether you use HTTP/2 or HTTP/1.1, as your question title may hint (sorry if I misunderstood).
Also, just because you updated to HTTP/2, it does not mean that your server cannot serve HTTP/1.1 anymore.
You can easily update to HTTP/2, and retain HTTP/1.1 support for older devices or networks that do not support or do not allow HTTP/2 traffic.
Whether a client and a server can speak HTTP/2 is negotiated: only if the server detects that the client supports it, then it will use it, otherwise the server will fallback to HTTP/1.1. Therefore you don't risk to make your site unavailable for older browsers in developing countries.
Then again, HTTP/2 implementations may vary, but typically they have to be prepared to clients that don't speak HTTP/2, and use HTTP/1.1 for those (because otherwise they won't be able to serve content and it will appear that the service is down).
Related
I would like to know if it's possible to make G-WAN 100% compatible with HTTP/2 by using for example the solution nghttp2 (https://nghttp2.org)
Sorry for the late answer - for any reason Stackoverflow did not notify us this question and I have found it only because a more recent one was notified.
I have not looked at this library so I can't tell for sure if it can be used without modifications, but it could certainly be used as the basis of an event-based G-WAN protocol handler.
But, from a security point of view, there are severe issues with HTTP-2, and this is why we have not implemented it in G-WAN: HTTPS-2 lets different servers use the same TCP connection - even if they weren't listed in the original TLS certificate.
That may be handy for legit applications, but that's a problem for security: DOH (DNS over HTTP-2) prevents users from blocking (or even detecting) unwanted hosts at the traditionally used DNS requests level (the "hosts" file in various operating systems).
In facts, this new HTTP standard is defeating the purpose of SSL certificates, and defeating domain-name monitoring and blacklisting.
Is it purely a theoretical threat?
Google ads have been used in the past to inject malware designed to attack both the client and server sides.
I plan to code a mighty web server. But I am unsure: should I do it in HTTP/1.x, or HTTP/2? I really don't like doing it in both (I know HTTP/2 is backward compatible to HTTP/1.x, but if it's superior AND is going to be adopted by the majority then I will only do it in HTTP/2 without the backward compatibility aspect).
How is the future looking like for HTTP/2? Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
Is HTTP/2 really worth it?
Finally, how is the expected HTTP/2 adoption by web browsers?
I would say this question is too broad for stack overflow, but will attempt and answer anyway:
I plan to code a mighty web server. But I am unsure: should I do it in
HTTP/1.x, or HTTP/2? I really don't like doing it in both (I know
HTTP/2 is backward compatible to HTTP/1.x, but if it's superior AND is
going to be adopted by the majority then I will only do it in HTTP/2
without the backward compatibility aspect).
No offence, and will give you the benefit of the doubt here that you are not trolling, but writing a web server is a major undertaking and you'd need to have detailed knowledge of the HTTP protocol amongst other things and it appears you don't have that to be honest. So you'll need to do a few years reading on the subject first.
HTTP/2 is not backwards compatible to HTTP/1.1. You basically start in HTTP/1.1 and upgrade to HTTP/2 if you support it (at a simplistic level). So you need to support both. And will do for some time. Even though browser support is good (see below) there will be numerous devices that won't speak HTTP/2 for some time. Some devices (primarily bots admittedly) still only speak HTTP/1.0.
How is the future looking like for HTTP/2? Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
Way too broad for Stackoverflows format.
Is HTTP/2 really worth it?
Yes.
Finally, how is the expected HTTP/2 adoption by web browsers?
HTTP/2 adoption can be seen here: http://caniuse.com/#search=http2
How is the future looking like for HTTP/2? and Finally, how is the expected HTTP/2 adoption by web browsers?
The HTTP/2 standard has passed acceptance and is being implemented by all major server vendors. In fact, server support has advanced, all major server vendors support HTTP/2 in their current releases. You can track all known implementations of HTTP/2 here.
Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
There will not be an HTTP 2.x. The standards body has already made this clear (although I can't find a link that proves it). the next version will be HTTP/3.
Is HTTP/2 really worth it?
Yes. The benefits of HTTP/2 are too long to list here. This article discusses them in depth.
When developing a web server you will need to take account of both HTTP1.x and HTTP/2. At the moment we are transitioning to HTTP/2 but you should provide backward compatibility to HTTP/1.x.
How can we know how many browsers support HTTP 2.0?
How can we know how many browsers support HTTP 2.0?
A simple Wikipedia search will tell you. They cover at least 60% of the market and probably more once you pick apart the less than 10% browsers. That's pretty good for something that's only been a standard for a month.
This is a standard people have been waiting for for a long time. It's based on an existing protocol, SPDY, that's had some real world vetting. It gives some immediate performance boosts, and performance in browsers is king. Rapid adoption by browsers and servers is likely. Everyone wants this. Nobody wants to allow their competitors such a significant performance edge.
Since http 2.0 is rolling out, does tricks like asset bundle still be necessary?
HTTP/2 is designed to solve many of the existing performance problems of HTTP/1.1. There should be less need for tricks to bundle multiple assets together into one HTTP request.
With HTTP/2 multiple requests can be performed in a single connection. An HTTP/2 server can also push extra content to the client before the client requests, allowing it to pre-load page assets in a single request and even before the HTML is downloaded and parsed.
This article has more details.
When can we move on to the future of technologies and stop those dirty optimizations designed mainly for HTTP 1?
Three things have to happen.
Chrome has to turn on their support by default.
This will happen quickly. Then give a little time for the upgrade to trickle out to your users.
You have to use HTTPS everywhere.
Most browsers right now only support HTTP/2 over TLS. I think everyone was expecting HTTP/2 to only work encrypted to force everyone to secure their web sites. Sort of a carrot/stick, "you want better performance? Turn on basic security." I think the browser makers are going to stick with the "encrypted only" plan anyway. It's in their best interest to promote a secure web.
You have to decide what percentage of your users get degraded performance.
Unlike something like CSS support, HTTP/2 support does not affect your content. Its benefits are mostly performance. You don't need HTTP/1.1 hacks. Your site will still look and act the same for HTTP/1.1 if you get rid of them. It's up to you when you want to stop putting in the extra work to maintain.
Like any other hack, hopefully your web framework is doing it for you. If you're manually stitching together icons into a single image, you're doing it wrong. There are all sorts of frameworks which should make this all transparent to you.
It doesn't have to be an all-or-nothing thing either. As the percentage of HTTP/1.1 connections to your site drops, you can do a cost/benefit analysis and start removing the HTTP/1.1 optimizations which are the most hassle and the least benefit. The ones that are basically free, leave them in.
Like any other web protocol, the question is how fast will people upgrade? These days, most browsers update automatically. Mobile users, and desktop Firefox and Chrome users, will upgrade quickly. That's 60-80% of the market.
As always, IE is the problem. While the newest version of IE already supports HTTP/2, it's only available in Windows 10 which isn't even out yet. All those existing Windows users will likely never upgrade. It's not in Microsoft's best interest to backport support into old versions of Windows or IE. In fact, they just announced they're replacing IE. So that's probably 20% of the web population permanently left behind. The statistics for your site will vary.
Large institutional installations like governments, universities and corporations will also be slow to upgrade. Regardless of what browser they have standardized on, they often disable automatic updates in order to more tightly control their environment. If this is a large chunk of your users, you may not be willing to drop the HTTP/1.1 hacks for years.
It will be up to you to monitor how people are connecting to your web site, and how much effort you want to put into optimizing it for an increasingly shrinking portion of your users. The answer is "it depends on who your users are" and "whenever you decide you're ready".
So I'm running a static landing page for a product/service I'm selling, and we're advertising using AdWords & similar. Naturally, page load speed is a huge factor here to maximize conversions.
Pros of HTTP/2:
Data is more compressed.
Server Push allows to send all resources at once without requests, which has MANY benefits such as replacing base64 inline images, sprites...etc.
Multiplexing over a single connection significantly improves load time.
Cons of HTTP/2:
1) Mandatory TLS, which slows down load speed.
So I'm torn. On one side, HTTP/2 has many improvements. On the other, maybe it would be faster to keep avoiding unnecessary TLS and continue using base64/sprites to reduce requests.
The total page size is ~1MB.
Would it be worth it?
The performance impact of TLS on modern hardware is negligible. Transfer times will most likely be network-bound. It is true that additional network round-trips are required to establish a TLS session but compared to the time required to transfer 1MB, it is probably negligible (and TLS session tickets, which are widely supported, also save a round-trip).
The evidence is that reducing load speed is definitely worth the effort (see the business case for speed).
The TLS session is a pain and it is unfortunate that the browser vendors are insisting on it, as there is nothing in HTTP2 that prevents plain text. For a low load system, were CPU costs are not the limiting factor, TLS essentially costs you one RTT (round trip time on network).
HTTP/2 and specially HTTP/2 push can save you many RTTs and thus can be a big win even with the TLS cost. But the best way to determine this is to try it for your page. Make sure you use a HTTP/2 server that supports push (eg Jetty) otherwise you don't get all the benefits. Here is a good demo of push with SPDY (which is that same mechanism as in HTTP/2):
How many HTTP requests does these 1000 kb require? With a page that large, I don't think it matters much for the end user experience. TLS is here to stay though... I don't think you should NOT use it because it may slow your site down. If you do it right, it won't slow your site down.
Read more about SSL not being slow anymore: https://istlsfastyet.com/
Mandatory TLS doesn't slow down page load speed if it's SPDY/3.1 or HTTP/2 based due to both supporting multiplexing request streams. Only non-SPDY or non-HTTP/2 based TLS would be slower than non-https.
Check out https://community.centminmod.com/threads/nginx-spdy-3-1-vs-h2o-http-2-vs-non-https-benchmarks-tests.2543/ clearly illustrates why SPDY/3.1 and HTTP/2 over TLS is faster for overall page loads. HTTP/2 allows multiplexing over several hosts at same time while SPDY/3.1 allows multoplexing per host.
Best thing to do is test both non-https and HTTP/2 or SPDY/3.1 https and see which is best for you. Since you have a static landing page it makes testing that much easier to do. You can do something similar to page at https://h2ohttp2.centminmod.com/flags.html where you setup both HTTP/2, SPDY and non-https on same server and be able to test all combinations and compare them.
I have been studying the Upgrade header field in HTTP 1.1 (RFC 2817) and happened to read the wikipedia entry for HTTP. That article has the following statement:
"Browser support for the Upgrade header is, however, nearly non-existent, so HTTPS is still the dominant method of establishing a secure HTTP connection."
I was hoping to implement my web service so that it relied on the Upgrade header field in order to avoid having to listen on two sockets (one for HTTP and the other for HTTPS). This statement, which I have not been able to verify any other place, makes me somewhat nervous about doing so. Is the above statement in wikipedia anywhere near correct or is it a gross generalisation?
I was researching this for that Wikipedia page actually and came across this question. I've looked around and here's the browser support situation as near as I can tell:
Chromium supports the Upgrade header as indicated by, for instance, this bug.
Firefox does not support "Upgrade: TLS" despite an open bug from 2005, last comment from 2010. My guess is they won't be adding it anytime soon.
Internet Explorer 10+ probably does, given this article that describes using Upgrade to connect to a websocket server. This commit message also implies IE 10 supports "Upgrade: websocket".
Safari 6+ supports Upgrade (see here).
For all of the supported browsers, I only found examples of "Upgrade: websocket" usage, none saying that upgrades to TLS would work. So the overall answer is that it's risky to rely on this in a production application.
Server support seems better; Apache has had "Upgrade: TLS" support since 2.1.
I would rather like to have it all in http, but the current situation leans more to Server Name Indication, as its widely supported. Its also hard to indicate that you want the client to upgrade using the url. So, if the goal is virtual hosting, one way to do this is TLS "server name indication". See RFC 3546 http://www.ietf.org/rfc/rfc3546.txt or http://en.wikipedia.org/wiki/Server_Name_Indication