If you’ve ever run your site through Google PageSpeed Insights, and came across “preconnect to required origins,” this post will cover the ground on what that message conveys, and specifically, focus on the
If you’re interested in
dns-prefetch, you can check out my previously written post, where I discuss the necessary details to help you get familiarized with it.
The reason Google recommends either the preconnect or dns-prefetch is because:
- They’re both resource hints.
- Conceptually, they both try to achieve the same result, that is, helping with improving load speed.
- When overused, either can have more negative effects than positives. (Not what Google recommends, but something you should be wary of).
Fundamentally though, they both are unique from each other, and there are subtle nuances between them, and hence, my rationale for carving out a separate post on just the preconnect.
First Things First: What Is Google Trying To Tell Us With “Preconnect to Required Origins”
Let me start by addressing the elephant in the room. If you’re thrown off by the word “origin,” and while technically it has its purpose, for the context of this post, think of origin as another domain/website.
Now, narrowing down to the message itself, what Google is telling us that, hey, if you have critical third-party requests being made on your site, meaning trying to establish connections to external websites (not your own), perhaps you can request the browsers to initiate an early connection to them. (More details on what exactly
rel="preconnect" does & best practices to follow).
Examples of third party requests can be YouTube embeds or external resources pulled from an external site (again, not yours).
Making connections to third party websites can be an undertaking. A typical process may encompass:
- DNS lookup
- Calculating redirects
- Multiple trips to the destination server that’s responsible for the user query/request
- Anything else
Clearly, these processes are usually fast and intangible to the naked eye; however, the standard with which these are measured is high, and even a lag of 1 second can affect your page load or cross the border on your site being fast to slow.
Using preconnect for an external site declares your intention to the browser that you’d be needing resources from it pretty soon. So when the browser sees the
rel="preconnect" hint, it tries to establish a connection to it as soon as it can, in advance, saving you time for when you actually need that resource.
Confused? Think about it this way. Say you’re hungry, and the dinner is already ready for you, versus you having to make one and then eat.
Having the food handy will save you a significant amount of time compared to having you make it and consuming it after. For analogical purposes,
rel="preconnect" works exactly like that. Your dinner is already prepared.
What’s the Primary Difference Between
The complexity of the internet amazes me, but know this: Every time you connect to a site, the following two things (amongst others) has to happen:
- DNS lookup
- Then, form a connection to that site
dns-prefetch only takes care of step 1 — which also saves time.
rel="preconnect" takes care of both.
In fact, many experts recommend using
dns-prefetch as a fallback option in case the browser lacks support for preconnect, it can at the least perform the DNS lookup.
How To Apply
The syntax — including examples for adding a preconnect to a domain are as follows:
<link rel="preconnect" href="domain name/sub domain name"> Example: <link rel="preconnect" href="https://example.com"> OR <link rel="preconnect" href="https://subdomain.example.com">
Best Practices for Adding
In general, you need to be prudent and restrictive in applying this resource hint. Below are some of the best practices surrounding
- Preconnecting to your own site — even if multiple resources are fetched, is unnecessary and unrequired.
- Your browser keeps the preconnect open for 10-15 seconds, and then closes it if that connection is not utilized. This is another reason you need to be cautious of using preconnect. In other words, if the resources are not fetched in the said timeframe, all the legwork done for the preconnect goes to waste.
- Tying to the general statement above, it’s wise to only save it for very critical third-party domains, and not all origins. Plus, every preconnect directive adds to the CPU usage.
- Lastly, browsers have a threshold for how many HTTP(S) connections they can make. If you keep piling up the preconnect hints — and especially to unnecessary ones — this can add to a notable waste of resources. In fact, this is one of the core justifications for closing any preconnect requests that are not leveraged in the10-15 second window. Because the browser would rather use that connection for something else.
- Overall, try to keep your preconnects between 2-3. For the rest, you can use
dns-prefetch, or even
rel="preload". Nonetheless, amongst all resource hints, it’s probably best to limit those to 6-8.
You May Also Want to Check Out:
- Static and Dynamic Content: Delineating the Differences
- Basic Differences Between a CSS ID and a CSS Class
- A Basic Introduction to HTML5 Semantic Elements
- How to Tell if a Site Is Using WordPress
- What Version of WordPress Do I Have?
- What Is the strict-origin-when-cross-origin Referrer Policy?
- How to Disable Windows 10 Automatic Updates
- What Is x-content-type-options: nosniff Response Header?
rel=preconnect" can prove to be a useful resource hint in your ambitions of improving page loads, if used rightly and cautiously.
However, if you’re looking for a noticeable (in comparison) performance upgrade, you should perhaps start your endeavors with
Just remember, don’t go overboard with anything, and between all resource hints (whichever you use), limit them to a maximum of 6-8, while ensuring preconnects are between 2-3 at the most.