Latency Optimization - Tips for Optimal Performance
Network and DNS latency play a huge part in determining just how fast your website or application loads. It will always be there to some extent as you can't get past the laws of physics when it comes to delivering content. The further the content has to travel, the greater the latency. However, that doesn't mean there aren't ways to decrease it. In today's post, we want to share with you a few latency optimization tips which will help ensure the fastest load times for your visitors.
What exactly is latency?
So first off, what exactly do we mean when we talk about network latency? Network latency, or website latency, can be defined by the time is takes (measured in milliseconds) for a request to travel from the sender to the receiver and for the receiver to process that request. In other words, the round trip time from the browser to the server. This is greatly affected by how far away the user is from the server and quality of the network. Other things that contribute to latency include transmission mediums, propagation, routers and storage delays.
In one study, median desktop latency ranged from 65-145 milliseconds.
Ars Technica wrote a great article about the inside story of how the internet works on a global scale. Many people tend to forget that there are thousands of miles of fiber optic cable and infrastructure which run beneath the ocean's surface to power the internet and ISPs all around the globe. One of the longest is a Tata's Atlantic submarine cable which starts from the west coast of England and travels a little over 4,000 miles to its destination in New Jersey, in the USA. You can see an example of this global network below.
So as you can imagine, when data is traveling this far, there will be delays. You simply can't beat the laws of physics. Even fiber optics are limited by more than just the speed of light, as the cable and the repeaters or amplifiers also introduce additional delays. Ilya Grigorik, a web performance engineer at Google described it this way:
Latency is constrained by the speed of light. Hence, 20 ms RTT is equivalent to ~3000 km, or a 1860 mile radius for light traveling in vacuum. We can't do any better without changing the laws of physics. Our data packets travel through fiber, which slows us down by a factor of ~1.52, which translates to 2027 km, or a 1260 mile radius. What is remarkable is that we are already within a small constant factor of the theoretical limit.
You can measure latency in a few different ways. Three of the most common methods are ping, traceroute, and MTR.
Ping is a utility used to send out ICMP packets to an address to see how fast the response is (and if one even exists). Ping corresponds with the delay time (in milliseconds) for how long it takes the data to travel across the internet, to its destination, and then back to you. A faster ping means a more responsive connection. You can use command prompt or terminal to test ping times against a website.
KeyCDN also has a Ping Test tool you can use which allows you to ping simultaneously from 14 locations.
Traceroute, also called tracert, is another utility you can use to test latency. Similarly to ping, it also uses ICMP packets to record the route through the internet from one computer to another. The difference with traceroute is that it calculates the time taken for each hop as the packet is routed to the destination. You can once again use command prompt or terminal to run a traceroute. KeyCDN also has a Traceroute Test tool in which you can test the connectivity or routing issues from 14 test locations in parallel.
MTR is essentially a combination of both traceroute and ping which allows a user to generate a report that will list each hop in a network that was required for a packet to travel from point A to point B. The report will include details such as Loss%, Average latency, etc. Read our more in-depth post on MTR and Traceroute.
You can never get rid of latency, but the great news is that there are latency optimization techniques which you can apply to negate some of the delays that occur. These include both network latency and DNS latency.
1. Use a CDN
The reason we chose a CDN as the first way to decrease your latency is because it will be the one technique that will have the greatest affect. Especially if you have visitors from around the globe. And depending upon the platform you use, could be one of the easiest to implement. We did a case study a while back where we specifically tested the latency (ping times) on a site with a CDN running and then without. And here are the results between the two.
|Server (POP) location||No CDN RTT (ms)||KeyCDN RTT (ms)||Difference|
|New York, US||36.908||18.096||- 50.97%|
|Dallas, US (origin server)||0.751||1.138||+ 51.53%|
|San Francisco, US||39.645||18.900||- 52.33%|
|Frankfurt, DE||123.072||3.734||- 96.97%|
|London, UK||127.555||4.548||- 96.43%|
|Paris, FR||112.417||.689||- 98.5%|
|Amsterdam, NL||118.418||10.364||- 91.25%|
|Singapore, SG||202.682||2.002||- 99.01%|
|Sydney, AU||191.848||0.705||- 99.63%|
|Tokyo, JP||130.804||3.379||- 97.42%|
As you can see the results are pretty astounding! The latency between our origin server (without a CDN) and our POPs (with a CDN) on average is decreased by 83%! This is because the content is now serving from cache on edge servers located much closer to the visitor. This is one way you can get around the laws of physics when it comes to beating the distance. Simply move the content closer to them!
HTTP/2 helps reduce server latency by minimizing the amount of round trips from the sender to the receiver and with parallelized transfers. Because of browser support, you need to be running over HTTPS to take advantage of this. KeyCDN proudly offers HTTP/2 support to customers across all of our edge servers for free with our Let's Encrypt integration. You can start delivering your assets from HTTP/2 supported edge servers in a matter of minutes.
3. Decrease external HTTP requests
It is very important to always keep external HTTP requests to a minimum. Let's say you have Google Analytics script, Typekit, New Relic monitoring, and Hotjar all running on a website. Each of these requests has its own latency involved and this can add up very fast. A lot of these services have their own CDNs, but it is important to ensure that whenever you link to third party resources that they are on a fast infrastructure.
Implementing browser caching can also be very effective in reducing latency as the browser doesn't have to make repeat calls to the server. Make sure to check out our in-depth posts on HTTP cache headers and
5. DNS prefetching
DNS prefetching allows the browser to perform DNS lookups on a page in the background while the user is browsing. This minimizes latency as the DNS lookup has already taken place once the user clicks on a link. DNS prefetching can be added to a specific URL by adding the
rel="dns-prefetch" tag to the link attribute.
DNS requests are very small in terms of bandwidth, but latency can be quite high, especially on mobile networks. By speculatively prefetching DNS results, latency can be reduced significantly at certain times, such as when the user clicks the link. In some cases, latency can be reduced by a second.
Preconnect allows the browser to setup early connections before an HTTP request is actually sent to the server. This includes DNS lookups, TLS negotiations, TCP handshakes. This in turn, eliminates roundtrip latency and saves time for users.
Preconnect is an important tool in your optimization toolbox... it can eliminate many costly roundtrips from your request path - in some cases reducing the request latency by hundreds and even thousands of milliseconds.
As you can see there are lots of different latency optimization techniques you can use to ensure your websites load fast no matter where they are located. Again, you can't get rid of all latency, as you can never get around the laws of physics, but you can optimize for it. With the modern hardware, protocols, and directives everyone has access to today, latency no longer has to be a website speed killer!
Are there any other good latency optimizations that we might have missed? If so, feel free to share them below in the comments.