Performance optimisation is a never ending journey. There’s always something new to try, something else to explore. And there’s no “one size fits all” as so much depends on the type of content, how often it changes, and what your audience expects. But there is one thing that’s always true, internet latency will cause you problems.
The internet is an inherently messy architecture. There was no grand master plan, no overseeing agency to organise it all, it’s hodgepodge and chaotic. Packets flying about all over the place, hoping they all arrive in vaguely the same order they were sent. And latency is a measure of the time a packet takes to get from source to destination, from A to B.
When someone types the address of your website into their browser (or clicks on a link to it) a number of things happen behind the scenes…
- DNS Lookup – this is where the address of your website is converted into an IP address, which is what the browser actually uses to request your website. This is usually relatively quick and low-latency, as it’s provided by your ISP.
- TCP Handshake – the browser sends a request to the IP address it’s been given, trying to establish a connection with the server – this takes 1 round trip (request and response).
- TLS Handshake – having made a connection, the browser and server now decide on what encryption protocol they’re both happy using – with TLS 1.2 and lower this takes 2 round trips but with TLS 1.3 it’s down to 1 round trip.
- Page Fetch – now they’re talking the same language, the browser requests the content of your website and this is returned by the server – this takes 1 more round trip.
Saying that the TLS Handshake takes 2 round trips (for TLS 1.2 and lower) is not entirely accurate. It would be fairer to say that the first time they visit your site in a while it takes 2 round trips to create a new session, but if a session is being resumed then this only takes 1 round trip.
The TLS Handshake for TLS 1.3 is always 1 round trip, for both a new session and a resumed one, which is one of the performance benefits of it, at least for new sessions. Cloudflare says that new sessions may up around 60% of the traffic it sees, so what about the 40% of traffic that are resuming sessions?
Well that’s where Zero Round Trip Time Resumption (or 0-RTT) comes in. This is a mechanism within TLS 1.3 which allow the session to be resumed without any round trip being required.
So here’s a summary of that…
- TLS 1.2 (and lower)
- New session: DNS + 4 round trips
- Resumed session: DNS + 3 round trips
- TLS 1.3
- New session: DNS + 3 round trips
- Resumed Session: DNS + 3 round trips
- TLS 1.3 with 0-RTT
- New Session: DNS + 3 round trips
- Resumed Session: DNS + 2 round trips
This may not seem like a lot, but remember that all of this has to happen before the browser can even start to render any of your website’s content, because this is all required in order to fetch the content. So your user is seeing a white screen during all of this – we need it to be as quick as possible!
The good news is that this is available to you in Cloudflare. On the Crypto tab is an option called “TLS 1.3” which you can set to…
- Disabled (don’t do this – we like new securer protocols)
- Enabled (good for security)
- Enabled+0RTT (good for security and performance)
Too good to be true? Perhaps. But no, only in the sense that it does theoretically open your website up to replay attacks. But let me be very clear, your application should protect itself against replay attacks anyway. And Cloudflare have been cautious in their implementation, only allowing GET requests to work with 0-RTT. As a GET request should never modify anything on the server, only return a result, this means that there should be zero risk to your website.
If you want to read a bit more about this really handy little feature, read the blog post that Cloudflare posted a couple of years ago when they were Introducing Zero Round Trip Time Resumption.