Site Speed Series (Part One): DNS Lookup and TCP Connection

Last year, Google published a paper about mobile page speed and how it affects user engagement. According to webpagetest.org, the average time it takes to fully load a mobile landing page was an incredible 22 seconds! Use an online timer and see how long 22 seconds actually is.

To be fair, it's likely that this data is based off of a high number of small sites running on cheap servers; Google may have come to the same conclusion since they narrowed down their results to sites in specific industries (ie. automotive, finance, travel, etc.) and found that it takes about 7 seconds for elements to display above the fold and 10 seconds to display the entire page. Using their own analytics data, Google learned that the probability of a visitor bouncing drastically increases with load times:

While researching for this article about ways to optimize page load times, I realized that I had gone down a very deep rabbit hole that contained way too much information to put into a single post. I decided to develop a series of articles breaking down every part of a loading website from the initial DNS lookup all the way to rendering an html element. Along the way, I'll uncover my findings for ways to improve site speed at each step of the loading process. In this first part of the series, we're going to dig deeper into two events that occur right after a visitor types a domain into the browser and presses enter: the DNS Lookup and the TCP Connection.

DNS Lookup

Every website is mapped to an IP address and in order to figure out what IP 'alvintai.com' is associated with, a DNS resolver must recursively find it starting with one of the 13 root servers. To simplify this, you can think of it in the context of this comical dialogue:

Resolver: Hey Root Server, do you know where I can find the IP address for 'alvintai.com' Root Server: Nope, but I know where you can find the Top Level Domain (TLD) Server for the '.com' part. Resolver: Great! Let me go talk to the TLD Server

Resolver: Hey TLD Server, do you know where I can find the IP address for 'alvintai.com'?TLD Server: Nope, but I know where you can find the Authoritative Domain Name Server (DNS) for that domain. Resolver: Great! Let me go talk to the Authoritative DNS.

Resolver: Hey Authoritative DNS, do you know where I can find the IP address for 'alvintai.com'? Authoritative DNS: Yes! Here is it.

The resolver eventually finds a site's authoritative domain name server (DNS) which holds the key information of the domain's IP. All of this takes milliseconds. You don't have too much control over the DNS recursion since the resolver is typically determined either by the ISP that the visitor is on or by the visitor himself (a person can choose which DNS resolver to use), and you certainly don't have control over the 13 root servers or any intermediate servers. As a site owner, the only thing you have control over is the authoritative DNS provider you choose (the last part of the recursion). To optimize speed, your best bet is to choose one that resolves reliably and fast; there are many providers to choose from, but you can use dnsperf.com to zero in on the fastest ones.

DNS Caching

A common technique to improve DNS lookup times is to cache the DNS response. Several caches can occur along the way to your server (ie. browser, router, ISP, etc.), and you have control over the caching time through your DNS provider. Depending on the type of application you are operating, extending the Time To Live (TTL) of your DNS record may help avoid having to go all the way back to the authoritative DNS to find the IP. But be warned, having a long TTL can also be a security risk; anytime you need to update a record or must failover to a new origin, just remember that your visitors will still have the old IP for as long as your TTL is set.

DNS Pre-Fetching

A clever option for web developers is to implement DNS Pre-Fetching for links. You can use the rel tag to inform the browser to prefetch a DNS response for a specific link:

<link rel="dns-prefetch" href="https://example.com/">

The DNS will have already been resolved even before a visitor clicks on the link! It can be a bit 'heavy' to prefetch a DNS response from many links, but if you have a frequently used link or one that requires optimal speeds, it can be a resourceful way to speed up an application.

TCP Connection

Once the IP address has been located, a TCP connection needs to be made between client (your browser) and the website's server. This is a three-part process using SYN/ACK packets, as illustrated on the left.

Though most site owners don't or can't optimize this aspect of page loadings, there have been several newer innovations that allow you to maximize speed. In a typical TCP connection attempt, a SYN packet is sent as an initial 'hello' to the server, which will respond with a SYN/ACK packet. Not until the connection is made can the client begin sending requests.

TCP Fast Open (TFO)

In 2014, the IETF published TFO which allowed clients and servers to send additional segments with their SYN/ACK packets. A few smart researchers from Google figured out that you could send an encrypted cookie with the initial request with one of the SYN/ACK packets which allowed you to save 1 full round trip to the server. It can shave milliseconds off of the transit. The main caveat is that your hardware needs to support this type of transaction and if there are any middle boxes in between or your server doesn't know how to handle this extra information, the packet might be truncated or, even worse, the connection won't be made at all.

Multipath TCP

If you go deeper into the TCP rabbit hole, you'll also find Multipath TCP, an experimental publication by the IETF. Let's say you're on a mobile device happily perusing a website and maybe you walk out of WiFi range and suddenly your device hops over to a separate network. In this scenario, the TCP connection for that website needs to be reestablished, wasting precious internet time. With Multipath TCP, multiple connections are redundantly made so when your device hops to a different network, the connection has already been established, thus providing a seamless user experience. Similarly to TFO, your hardware needs to support this and there are load balancing conditions that need to be thought of when going down this route.

TCP keepalive

An obvious conclusion to reducing the latency caused by the TCP handshake is to minimize the number of times that handshake is performed. Depending on the type of application you're running, using TCP keepalive could be the solution. It does exactly what the name implies: it keeps TCP connections open. It does this by sending noninvasive packets to make sure the connection hasn't timed out. The performance boost by reducing the number of handshakes can be hundreds of milliseconds.

In many cases, you may not need to get this granular in improving application loading times, but in this Speed Series, we're going to be looking at how to squeeze every last bit of latency out of the stack and getting as close to the speed of light as possible. Stay tuned for Part Two where we'll start getting into the juicy bits with TLS and middle boxes.

Alvin is a network security/performance evangelist and entrepreneur. His ramblings can be found at www.alvintai.com. Follow him @thealvintai