There are two major issues when it comes to DNS lookup times:
1. Number of external requests
A complex website may use external libraries to add visual functionality to the front-end. This functionality includes, but it’s not limited to, frameworks (such as jQuery), sliders, carousels, fonts, icons, validation libraries and more.
Some of the most well known content delivery networks out there are:
https://developers.google.com/speed/libraries https://cdnjs.com/ https://www.jsdelivr.com/ https://unpkg.com/
The first step in improving DNS lookup time is reducing the number of hostnames used. Some libraries exists on more than one CDN, so try to use one CDN only.
The second step is evaluating the functionality and refactoring the code. Do you need the slider to load on all your pages or specific pages only?
When you have all your functionality fleshed out, move all third party resources locally.
Here’s some real life examples:
Case Study #1
I have optimized several bloated ThemeForest themes by removing 2 out of 3 slider libraries. They were all loaded for convenience and for ease of use (i.e. the admin could pick any of three sliders to spice up their homepage. I have moved the jQuery library and the slider library locally to avoid any external requests.
Case Study #2
I have optimized a map-heavy site by merging some of the Leaflet.js add-ons into one local file (the marker clusterer, the fullscreen functionality and the custom map layers). I have also hosted all Leaflet.js assets locally.
Case Study #3
I have optimized a site using Font Awesome icons by removing the library and using the SVGs inline. Font Awesome loads a JS file which injects an inline stylesheet first thing in the <head> element and then loads all (1500+) icons. Font Awesome is a great library and extremely convenient, but it jsut doesn’t scale to load 1500+ icons and only use 20 or 30. Also, note that the library itself is almost 0.5Mb.
Note that having third-party resources hosted locally help with the QA department.
Sometimes libraries have small dependencies, such as stylesheets. They can be added to the main stylesheet and avoid 2 or 3 external requests.
Sometimes, in a big project, 10 or 20 external resources may be used, such as multiselect libraries, popup libraries, validation frameworks, utilities and helpers. Often times, these resources can be loaded in a single file.
If you have access to your hosting server and you find yourself using lots of libraries, resources, fonts or SVGs for your clients’ sites, create a subdomain and dump all the resources there.
2. SSL/TLS handshake time
Preconnecting is a speed-optimization function, in which the browser sets up an early connection before an HTTP request is actually sent to the server. Connections such as DNS Lookup, and TLS negotiation can be initiated beforehand, eliminating roundtrip latency for those connections and saving time for users.
Establishing a connection to a server hosting a resource takes several steps:
- DNS lookup
- TCP handshake
A brief “conversation” between the browser and server to create the connection.
- TLS negotiation on HTTPS sites
This verifies that the certificate information is valid and correct for the connection.
This typically happens once per server and takes up valuable time — especially if the server is very distant from the browser and network latency is high.
Here’s an example for Google services:
<link rel="preconnect" href="https://fonts.gstatic.com"> <link rel="preconnect" href="https://googleapis.com"> <link rel="preconnect" href="https://maps.googleapis.com"> <link rel="preconnect" href="https://ajax.googleapis.com"> <link rel="preconnect" href="https://service.googleapis.com">
Don’t forget your other resources, such as icons, social tracking scripts, analytics, user tracking and more.
The rule of thumb here is if you can’t load it locally, preconnect it.
Use SpeedFactor to track your website. It’s simple and reliable.
See how real people experience the speed of your website. Then find (and fix) your web performance problems.