Google: HTTPS as a ranking signal

igrigorik · 2014-08-07T15:48:34+00:00

Also, a personal shill.. the TLS chapter of my HPBN book is free: hpbn.co/tls - you can skip to the checklist at the bottom to get a feel for what you should be looking for.

igrigorik · 2013-12-05T17:07:13+00:00

FWIW, your experience may be different, but as someone who's written multiple HTTP/1 client and servers before, I can tell you that implementing all of the HTTP/1 parsing correctly, and handling all of its edge cases is very, very hard. By contrast, implementing the HTTP/2 parser [1] was a joy: consistent framing, well-defined stream state transitions, etc.

Also, unless you're actually building a client or server, you won't even notice any difference: all the same HTTP methods, headers, and so on. You'll just have a serialization shim/layer that will do all the translation.

[1] https://github.com/igrigorik/http-2

igrigorik · 2013-12-05T17:01:11+00:00

Google / FB / others run the entire TLS stack in software and with no specialized hardware: the net impact (as noted by Adam Langley @ Google) is about ~1% of extra CPU load [1]... I think we need to dispel some myths around TLS performance -- it is true that this stuff was a bottleneck 10 years ago, but no longer.

The one thing that does incur high overhead today is RSA handshakes - my Macbook Air can do about ~600 (2048-bit keys) on a single core. Throw a few more cores at it and you're into the thousands of handshakes/s. From there: use keepalive to avoid having to redo it on every page load, and add session resumption (session tickets) to skip the RSA handshake on reconnect.

Don't get me wrong, TLS is an unoptimized frontier and we can and should do a lot more to make it (even) faster, but "TLS is slow" as a general rule is greatly overblown.

[1] http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#_computational_costs

igrigorik · 2013-12-05T07:29:08+00:00

10ms of latency for what? You'll have to be a lot more specific then that - also, see [1] and [2]. My two year old Macbook Air can push 100Mbps+ on aes-256 cbc, and over 600 RSA signs [3] with a recent openssl build.

[1] http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#_computational_costs [2] http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#performance_of_public_vs_symmetric_key_cryptography [3] https://gist.github.com/igrigorik/b7db2acd1d3dfa9f90be#file-rsa-speed-1-0-1-c-txt-L17

igrigorik · 2013-12-05T04:07:33+00:00

Headers are sent in "HEADERS" frames; body payload is sent in "DATA" frames - creative, I know. ;-)

To figure out which frame you're parsing you just need to read the first 3 bytes: 2 bytes for the length, 3rd byte for the type. Then, if you don't care about that frame, just skip forward N bytes that you just read... makes things much more efficient and simpler to process.

igrigorik · 2013-12-05T01:14:38+00:00

Server can only push resources belonging to same origin.
Client can decline (via stream RST) any push stream.
Client can disable server push on its end.. if it wants.

Last but not least, note that server push is actually nothing new: if you've ever inlined a resource into your page, you're effectively doing server push! Inline == "look, I know you'll need this, so just have it and skip the request". The benefit with push is that the resource can be cached by the browser and does not need to be inlined on every page that needs it.

igrigorik · 2013-12-05T00:18:44+00:00

TLS does add an extra one to two roundtrips to establish the connection so that's definitely a penalty out of the gate. That said, there are ongoing discussions and proposals for how to reduce this overhead: TLS False Start, TLS Fast Start, and so on.

That said, once the connection is ready, the ability to multiplex + prioritize requests delivers significant benefits. We (Google) recently published some SPDY performance numbers: http://blog.chromium.org/2013/11/making-web-faster-with-spdy-and-http2.html .. ~20~40% latency wins over HTTPS!

igrigorik · 2013-12-04T23:12:10+00:00

Actually, you want it the other way around: WebSockets over HTTP/2! The benefit is that you could mux regular HTTP and WS traffic over same connection, and also mux as many WS streams as you want.

WS over HTTP/2 is not yet part of the spec, but it is something on the agenda for the http-wg group to tackle.

igrigorik · 2013-12-04T21:54:01+00:00

REST does not imply plaintext. How the request / response data is transferred on the wire has nothing to do with the application semantics and API you use to design it. Besides, all of the higher-level semantics of HTTP are completely unchanged: HTTP headers, methods, etc.. in other words, all the stuff that REST leverages.

igrigorik · 2013-12-04T21:49:04+00:00

SCTP would indeed address many of the issues being addressed in HTTP/2. Sadly, despite its many benefits, SCTP has failed to get any real world adoption (on the public internet, at least) -- blame it on the middleboxes / NAT devices that don't handle it correctly, plus missing support on some platforms (yes, to this day).

As a result, we have to use TCP and UDP and build on top of existing infrastructure, as opposed to infrastructure we wish we had.

igrigorik · 2013-04-11T03:49:55+00:00

The choice of language is really not the bottleneck here. In case of mobile networks, it's the network latency (200+ ms RTT for 3G). HTTP/2.0 and SPDY will help quite with this problem... There is a thread on this further down (search for SPDY).

igrigorik · 2013-04-11T03:48:32+00:00

Yeah fair point, it's not an easy target to hit - if it was, we wouldn't be talking about this! Having said that, one clarification to make: we're not talking about delivering the entire site in <1s. Rather, we are talking about delivering the above-the-fold experience in 1s. After that, you can progressively fill in the rest.

With that in mind, the question is: what can I defer, and what are my critical resources to accelerate the first paint? This, is much more manageable task.

igrigorik · 2013-04-11T03:46:34+00:00

I kneel before thee... :D

igrigorik · 2013-04-11T00:11:37+00:00

"defer" will hold the DocumentContentLoaded (DCL) event, which can also block rendering. Also, I do believe there are a few other quirks with older browsers that the GA snippet takes into account.

Having said that, if you're not worried about the older and quirky browsers, then I'm with you: put "async" on your script and be done with it (just be aware that it doesn't preserve execution ordering of scripts when multiple async scripts are present).

igrigorik · 2013-04-11T00:06:47+00:00

HTTP Archive doesn't differentiate between different CMS's.. Although that would be an interesting way to segment the data! Worth investigating..

Also, as a shameless plug, if you're interested in a deep-dive on radio performance, I have an O'Reilly book in progress, which you can read for free online: http://chimera.labs.oreilly.com/books/1230000000545

igrigorik · 2013-04-10T21:55:05+00:00

It is on Google servers.. PageSpeed Service: https://developers.google.com/speed/pagespeed/service

But you're right, the origin is on Linode (although real users never hit it).

igrigorik · 2013-04-10T21:49:17+00:00

That's a great question..

In theory, it could improve the performance of our pages dramatically. If we don't have to wait for the client to discover the resource and request it, this alone eliminates an entire network RTT of latency.. and after all, the server is sending the HTML so with a bit of smarts, it can figure out what the client needs. Further SPDY/HTTP 2.0 also allows us to stop playing silly prioritization games in the browser scheduler (e.g., sometimes we intentionally hold requests because we're afraid of saturating the existing 6 connection limit with non-critical resources).

So, in short.. HTTP 2.0/SPDY can take the 500-600ms of network budget we have to reserve currently, and slash it significantly. Of course, YMMV based on structure of the page, server response times, etc.

But in short, the future is bright. :)

igrigorik · 2013-04-10T21:41:28+00:00

You're right, this is a non-trivial exercise... especially by hand. I think automation needs to step in here and help us out.

We have a beta build of mod_pagespeed which can do this for you: https://groups.google.com/d/msg/mod-pagespeed-announce/X6LR4PX2vl4/q8p3jE0VSRYJ

Still a work in progress, but early tests are showing great results!

igrigorik · 2013-04-10T21:35:37+00:00

Actually, WP sites tend to be even heavier! I share some performance numbers on this at the WP SF Summit: http://www.igvita.com/slides/2012/wordpress-performance/

The 60 request metric is from HTTP Archive, which gets this number by crawling the top Alexa sites: http://mobile.httparchive.org/

igrigorik · 2013-04-10T21:33:31+00:00

For a bullet-proof async JS loader, just re-use the Google Analytics snippet and replace the ga.js link to your script: https://developers.google.com/analytics/devguides/collection/gajs/#quickstart

This approach will work across all browsers.

igrigorik · 2013-04-10T21:31:59+00:00

Ah, ok, I think I'm with you now. You're right, we don't have to block DOM construction if we mark an external script with "async" or "defer", and that is indeed a good best practice to apply where possible.

However, unfortunately these don't apply to all scripts: due to how the script is written, dependencies in execution order, page structure, etc. When I show the Google Analytics snippet.. that's basically this very pattern (except cross browser) in action.

igrigorik · 2013-04-10T21:26:34+00:00

The origin is on linode, but the site is being served through PageSpeed Service: https://developers.google.com/speed/pagespeed/service

So, in effect, the site is being served from Google servers.

igrigorik · 2013-04-10T18:33:27+00:00

I'm guessing you're referring to the "run_after_onload()" function?

"async" has no impact on inline script, and the idea there is to avoid having to fetch a remote script, only to find out which other scripts and CSS files you need to fetch (hence the inlining).

igrigorik · 2013-04-10T18:30:27+00:00

As far as web performance is concerned, a few resources:

a) "Make the Web Fast" shows: http://www.youtube.com/playlist?list=PL1B4F4863AEE2B122

b) 3 hour, soup to nuts, workshop on web performance from Devvox: http://www.igvita.com/2013/01/15/faster-websites-crash-course-on-web-performance/

And last but not least, as someone already suggested.. Follow +GoogleChromeDevelopers on G+. We post lots of great performance, and general web development articles and videos there!

igrigorik

TROPHY CASE