Do not use WP Rocket preconnect feature

One of the changes in WP Rocket 13.9 involves preconnecting to external domains:

• "Preconnect to external domains is now fully automated and enabled by default, optimizing connections to third-party resources, individually for both desktop and mobile"

And I've already spotted this behavior on multiple WordPress sites. One of them, a WooCommerce shop showed 15 preconnects injected by WP Rocket.

In theory, this sounds like a good idea. But in reality, it is not.

WP Rocket behavior

According to their article covering their preconnect behavior, WP Rocket automatically enables this optimization upon activation. So, once upgrading to WP Rocket v13.9, this comes out of the box. You don't even have to specify which domains your site should preconnect to. That sounds very convenient.

While the WP Rocket designed this enhancement thinking it improves the loading times of websites using WP Rocket, it is actually more likely to result in sitespeed regressions.

Multiple issues with this implementation

The `crossorigin` attribute is misplaced

The crossorigin should only be used when you're actually making cross-origin requests that need credentials or when you want to ensure CORS compliance. For many external domains like social media, analytics scripts, or CDNs, adding crossorigin unnecessarily will actually:

• Result in a DNS lookup that will be re-used by the browser, but it's the TCP/TLS handshakes that can't be reused
• When an actual resource from the same domain is loaded in a non-CORS way, it results in yet another TCP + TLS/HTTPS handshake
• Resulting in unnecessary work and overhead by the browser

For example, https://fonts.gstatic.com/ serves webfonts crossorigin and does need the attribute, but https://fonts.googleapis.com/ does not as that hostname only serves CSS. This conclusion can also be drawn when looking at the preconnects that will be suggested by Google Fonts embed code:

<link rel="preconnect" href="https://fonts.googleapis.com/">
<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>

Additional notes:

• I wrote about preconnect and crossorigin before as it's easy to misunderstand its purpose and implementing it incorrectly.
• Self-hosting web-fonts is better for both performance and privacy

Too many preconnects

This WP Rocket feature is likely to preconnect to too many hostnames (i.e. too eager) depending on the amount of external resources on your site. This can be problematic as:

• Each preconnect uses up browser connection limits
• Preconnecting to domains you rarely use wastes resources
• It can actually slow down connections to domains you frequently use
• Mobile devices especially benefit from more selective preconnecting

Privacy / GDPR risk

The privacy risk could create significant legal problems depending on local privacy regulations. It can put merchants (especially those in Austria + Germany) in extra risk, but similar concerns apply globally under regulations like CCPA, PIPEDA, and other data protection laws:

• By default, user IP addresses get logged by servers
• By preconnecting to them, IP addresses will already be shared even before any consent is given
• This violates GDPR's "consent before processing" principle for personal data and similar requirements in other jurisdictions, and may unknowingly create liability for website owners using WP Rocket

This is especially problematic because many WP Rocket users might not realize they're now automatically violating privacy regulations, particularly if they're using cookie consent banners that are supposed to prevent third-party data sharing until users explicitly agree.

Just doing a domain name lookup (rel=dns-prefetch) instead of preconnecting (rel=preconnect) doesn't come with this risk.

Check your own site

A person replied to my LinkedIn post and said the following:

I also believed that pre-connecting all third-party URLs would increase the speed. But when I tried to execute it, I found that the speed was getting slower

In other words, it can actually regress the sitespeed as experienced by real users. When you're using detailed Real User Monitoring tool to monitor sitespeed and Core Web Vitals, you should be able to determine if your visitors are affected by looking at the First Contentful Paint (FCP) metric of uncached pagehits. Be sure to focus on the 95th (or surrounding) percentiles across mobile navigations.

If you're not using a RUM tool, there's a way to see if your site is technically affected:

• Navigate to your site
• Open its the source code (Control+U on Windows desktop)
• Search for data-rocket-preconnect (Control+F on Windows desktop and typing or pasting this in the searchbox)
• If there are results, check if those elements include the crossorigin attribute

If so, then your site is using WP Rocket 13.9 or newer. If not, then your either not using WP Rocket, using an older version or using a newer version where it's fixed already.

The fix

Fix for site owners

If you're using WP Rocket 13.9 or newer, I recommend disabling this feature or switching it to dns-prefetch instead. Their article covers both options:

1. disabling its preconnect behavior
2. switching to dns-prefetch

Fix by WP Rocket

Meanwhile, I created a issue/ticket over at the WP Rocket repo to get it addressed and improved at the source. Possible fixes could be:

1. Using dns-prefetch by default and allowing site owners to switch to preconnect per domain in an admin UI;
2. And/or then only add the crossorigin attribute by matching a domain with a internally maintained list of domains that does typically require the crossorigin attribute

* Update: A WP Media team member involved with WP Rocket already replied on my LinkedIn post, suggesting the same fixed and indicating that they are on top of it (actually already became a milestone for version 3.20.1) :)