Should you use preconnect with stylesheets?

2.1k Views Asked by At

When you want to include a font from Google Fonts it suggests ([1]) you do it like this:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Roboto&display=swap">

The preconnect to fonts.gstatic.com makes sense since the browser will otherwise only find out about that domain after it has downloaded the stylesheet. But what's the point of the preconnect to fonts.googleapis.com when the link to the stylesheet is right after it? Won't the browser process both of those at the same time?


[1] See: https://fonts.google.com/share?selection.family=Roboto, select some style and and click briefcase icon in the upper-right corner.)

Google Fonts Roboto page with selected font and right "Use" pane opened. There is HTML code similar to the snippet above, with two preconnects and one stylesheet links

5

There are 5 best solutions below

0
On

By preconnecting with https://fonts.googleapis.com, the webpage is optimizing the loading of the font stylesheet itself. As Google documents:

<link rel="preconnect"> informs the browser that your page intends to establish a connection to another origin, and that you'd like the process to start as soon as possible.

The performance bump is likely negligible since the stylesheet itself is usually tiny, so I'm not sure why this is included by default. However, it does still technically do something. I'd suggest removing it, as it makes no difference in load times.

1
On

Using preconnect for external domains, especially those from which your page will fetch resources, can be a good practice to improve performance by reducing the latency associated with establishing connections.

1
On

The link with rel of preconnect has nothing to do with stylesheet itself.

<link rel="preconnect"> will provide a benefit to any future cross-origin HTTP request, navigation or subresource.

Preconnecting speeds up future loads from a given origin by preemptively performing part or all of the handshake (DNS+TCP for HTTP, and DNS+TCP+TLS for HTTPS origins).

Read the full doc here: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preconnect

0
On

But what's the point of the preconnect to fonts.googleapis.com when the link to the stylesheet is right after it?

I'd rather agree that in your code sample the benefit will be minimal, but the connection to that css host will start a bit earlier. And the browser parses HTML sequentially and this preconnect link can get some real profit especially when you place other external css links between preconnect links and google css link. So Google does not know about your site structure and gives you "good practice" code for most cases.

Won't the browser process both of those at the same time?

Not really. A resource fetching will reuse current preconnect state from the browser pool. I think this is pretty common situation because a preconnect job - DNS resolution, TCP connection and TLS negotiation - can take a really long time(tens of milliseconds and more).

Some related links:

  1. https://html.spec.whatwg.org/multipage/links.html#link-type-preconnect
  2. https://andydavies.me/blog/2019/04/17/three-ways-of-checking-your-rel-equals-preconnect-resource-hints-are-working/
1
On

Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high latency costs of establishing a connection. Preconnect is supported by most browsers and improves Google Fonts performance.

You can have a look to the full article https://www.cdnplanet.com/blog/faster-google-webfonts-preconnect/#:~:text=The%20preconnect%20hint,-Preconnect%20is%20one&text=Initiating%20an%20early%20connection%2C%20which,and%20improves%20Google%20Fonts%20performance.