Preconnect to Required Origins: What Is rel=”preconnect”

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 rel="preconnect" aspect.

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.

What rel="preconnect" Does

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 rel="preconnect" and dns-prefetch

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:

1. DNS lookup
2. 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 rel="preconnect"

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 rel="preconnect"

In general, you need to be prudent and restrictive in applying this resource hint. Below are some of the best practices surrounding rel="preconnect":

1. Preconnecting to your own site — even if multiple resources are fetched, is unnecessary and unrequired.
2. 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.
3. 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.
4. 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.
5. 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.

Summary

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 rel="preload".

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.