We can talk about website UX issues, the use of A/B tests to determine whether it is better to put CTA button on the left or the right side of the website, or if it is better to use appropriate color schemes to lower the cognitive load in order to enhance webshop conversion rate. However, the main thing that we know for sure is that poor website performance is making businesses lose their customers.
Amazon did a study in which they deliberately slowed down the speeds of loading pages and they came up with interesting results: every 100ms of latency reflects in a sales drop of 1%. Also, Google conducted a similar study in which they found that 53% of users will leave a website if it takes longer than 3 seconds to load!
What makes websites load slow?
A website is a collection of documents and resources (scripts, styles, images, etc.) which have to be downloaded in order for browsers to display something on the screen. When a user wants to connect to a certain website, various processes are happening in the background, which in turn adds up to the website’s loading time: DNS lookup, TCP handshake and TLS/SSL handshake. Another unfavorable factor affecting loading speed is the distance between a requested location (a web-server location of a hosted website) and a user location. For example, if the user in central Europe (i.e. Zagreb, Croatia) is requesting a website located in, for instance, New York, the distance between those two locations is around 6900km. Knowing the distance between the two locations and knowing the fact that network packages (data) are traveling through the network at near the speed of light (around 200,000km/s), we can easily calculate the latency. In the previous example, the latency would be 69ms (34.5ms to New York, and 34.5ms back to Zagreb).
We, as developers, do not have much of an influence on the above-mentioned process or physical limitations, but we can use various methods and techniques to improve loading speed performance by handling latency issues differently. All these techniques work in an ahead-of-time manner, establish a connection or even download a resource now and use it later when you need it.
As mentioned before, for a browser to establish a connection to a website, certain actions have to be done, and that requires time. To remove that initial data round-trip latency, we can use preconnect. What preconnect does immediately is: resolves DNS, performs TCP handshake and sets up TLS for data that can be used for current navigation.
Let’s now see preconnect in action and how we can get the best of it.
Imagine you want to use Google font in your project. The regular way to include web fonts from Google Fonts is:
To apply this beautiful font Girassol all over, we need to adjust our stylesheet:
Now, we can test this and see what happens:
From this waterfall diagram, we can see the process
- Step 1. Getting HTML document (DNS lookup, initial connection, document download)
- Step 2. & 3. Loading resources (stylesheets) defined in HTML header started at the same time however, Google Fonts stylesheet starts again with DNS Lookup, Initializing connection, etc.
- Step 4. After steps 2 & 3 are completely finished, the process of web font (woff) download is being started (@fontface property is defined in Google Fonts stylesheet). That process is again starting with DNS lookup, Initializing connection, SSL Negotiation, etc.
Let’s see what happens once we apply preconnect to this code. It is rather easy to apply preconnect; we need another line of code in our HTML head tag.
We are pre-connecting to URL https://fonts.gstatic.com. This location is where the actual Google Font is located (.woff file). If you wonder why cross-origin is used, it is because fonts are subject to the same cross-origin policy and font face specification requires download in the anonymous CORS mode. For more on this topic: https://webmasters.stackexchange.com/questions/89466/when-should-i-use-the-crossorigin-attribute-on-a-preconnect-link
This example demonstrates how using preconnect on Google Fonts has already resolved DNS, connection and TLS handshake before stylesheets (CSS) is completely downloaded and evaluated. However, the actual font file download starts after stylesheets are loaded.
Time for a full load requested website:
- Without preconnect – 0.499s
- With preconnect – 0.397s
Speed improvement is evident. You might think that 100ms is not much of an improvement, but bear in mind, this is just a basic HTML file with only a few lines of code. Imagine if this were a case of a large project with a need of using dozens of resources.
Implementation in real world websites or apps
Amazon uses preconnect for autocomplete (search) features for the blazing fast search results. Actually, Amazon search is a different app that sleeps on another host - https://completion.amazon.com. Inspecting Amazon website, we can see this:
Another thing to keep in mind is browser support. In this case, we have very decent browser support with 89.71% browser coverage including Chrome, Firefox, Opera and Edge. However, it is not possible to get benefits of preconnect in IE but does one care for IE in 2020. :)
DNS-prefetch is similar to preconnect with some key differences. DNS-prefetch only does DNS lookup, without opening TCP connection and TLS handshaking. DNS-prefetch would be probably used in scenarios where resources might be needed in the future, but we don’t know for sure.
A good use-case of DNS-prefetch would be for the example if you have a website that calls a bunch of JS files from CDN which might be used later for some website functionality. So, at the begging of website load, you can specify DNS-prefetch to CDN to resolve DNS so the resources that would be loaded later can be downloaded/used at a faster pace.
Now, you may ask the question "Why to use DNS-prefetch over preconnect?". Well, the answer has more than one connotation. One aspect is definitely a good software development practice. Preconnect is more “heavy” operation than DNS-prefetch, therefore using it for getting resources we don’t know if they are going to be used or not is not a particularly good practice.
Another connotation is from a business perspective. Let’s get back to the Amazon example. For sure, they could use DNS-prefetch instead of preconnect for their autocomplete functionality, because they actually don’t know if the user/visitor would use the search or not. But what their research showed is that the majority of users actually do search the website at some point in their journey, so it is wise to provide users’ search results as fast as possible.
Browser support percentage is overall lower than preconnect however, all major browsers support DNS-prefetch, including IE.
With prefetch you can download a resource (script, images, etc) in a low-priority manner and use it in later/future navigation. Keep in mind downloaded resources are not immediately executed, they are just stored in the browser’s cache.
Developers need to be careful how and when they use prefetch because putting prefetch too early on resources that might never be used may result in slowing down the current page at which the user is already looking.
Implementation of prefetch is easy as other methods mentioned before
With one exception, however. We now have “as” attribute and we use it to define asset type. We need to define it to prioritize browser requests, i.e. the “stylesheet” asset type needs to be downloaded before the asset type “image”.
If a user clicks on a shopping cart on an e-commerce website, we can anticipate that the user will proceed with the checkout process, so we can prefetch resources that would be used in checkout to provide a better user experience. Furthermore, eBay implemented prefetch on the first five results to speed up future page loads and witnessed a positive impact on conversion rates.
Prefetch has decent browser support however, it is not supported on Safari and iOS Safari. The main reason why we would use all mentioned speeding methods is to lower latency and speed up the website/app loading process. The problem is more evident on mobile platforms and 3G connections where latency might be so high that it significantly affects web performance. Moreover, that is the main reason why developers might give up using prefetch altogether because of iOS Safari’s current support. The good thing is that we can combine different methods, so if one method is not supported by a browser, we can use another one that is.
And last, but not least, preload is maybe the most interesting among them all. Preload is a bit different than prefetch in a way that preload forces a browser to download a resource for the current page, something like early prefetch.
Here’s a practical example. If Page A initiates a prefetch request for resources that will be used on Page B, the resource and navigation requests can be completed simultaneously. On the other hand, if we use preload for this case, it will immediately be canceled on Page A’s unload.
If we go back to our initial example with a web font and use the preload request for the font asset, we can write HTML as follows:
By using a preload request we can see what actually happens on the waterfall chart:
A font asset (number 3) is being processed (DNS lookup, TCP connection and TLS handshake) and downloaded simultaneously with other assets like style files. That kind of action significantly improves user experience, because of resources being displayed immediately on the user’s screen.
Implementation in real-world websites or apps
Shopify.com implemented preload requests for their web fonts and experienced a 50% improvement rate of the time it takes the text to appear on the screen.
Preload has a rather decent browser support. The biggest concern is Firefox which actually can use preload, but it must be manually enabled in the Firefox settings. However, we can hope that Firefox will enable preload to work out-of-the-box and there are some hints that they will do exactly that. https://bugzilla.mozilla.org/show_bug.cgi?id=1222633
Today’s typical Internet persona demands information as fast as they can. On the other hand, websites or apps have more features than ever before. In fact, so much more that many sites struggle to achieve a high level of performance.
Web optimization is an interdisciplinary field and a much broader term than just preconnect, dns-prefetch, prefetch and preload, but with the use of these simple methods, we can significantly improve website/app speed and increase overall user experience. The difference, though, is more dramatic with mobile platforms using slower connections, such as 3G.
And if we learned anything from an abundance of available analyses and research is that the speed of a website or an application is crucial for reaching business goals.