Add preconnect tag for CDN CNAME

[GeekPress]

Is your feature request related to a problem? Please describe.
« Establish third-party connections early » is one of the optimizations recommended by Google to improve LCP.

Server requests to third-party origins can also impact LCP, especially if they're needed to display critical content on the page. Use rel="preconnect" to inform the browser that your page intends to establish a connection as soon as possible.

We are now using only a DNS-Prefetch on CDN CNAME which helps to resolve DNS lookups faster. The preconnect value is doing more than DNS-Prefetch: TCP, TLS, etc...

As CDN are using everywhere on a website, there are a lot of chances to load critical content, this enhancement is welcoming.

Describe the solution you'd like
Add <link rel="preconnect" href="{CNAME_URL}"> in addition to DNS-Prefetch.

Preconnect isn't yet compatible with Firefox for HTTPS origin (https://caniuse.com/?search=dns-prefetch). We can still use DNS-Prefetch as a fallback

[remyperona]

Scope a solution ✅

• In Engine/CDN/Subscriber, add a new method add_preconnect_cdn(), as a callback to the wp_resource_hints filter
• The method should bail-out early if there is no CDN URL, if the CDN option is disabled, or if the bypass query is set
• This method will add the currently stored CDN urls to the preconnect. Ideally, it needs to add each one twice, one with the crossorigin attribute, and one without

We need to write automated tests for the new method.

Estimate the effort ✅

Effort [S]

[iCaspar]

Adding the preconnect both with and without crossorigin will not be possible using wp_resource_hints().
Why?

wp_resource_hints() allows only one hint per hint type (dns-prefetch, preconnect, etc) per domain.

@see https://core.trac.wordpress.org/browser/tags/5.6/src/wp-includes/general-template.php#L3353

So once we add a preconnect hint for //123456.rocketcdn.me, it will not add a second preconnect hint for that domain.
Ideally, as @Tabrisrp mentioned in the grooming note, we need both. This is because CSS resources will need crossorigin version, and JS resources will not use crossorigin.

We could add these tags using a custom method, but we will have to be careful somehow filter on the wp_resource_hints() output to avoid risk actual duplication of the hint, if somehow a domain is added by wp_resource_hints() and the new custom method.

In any case, I'm revising the estimate to [M], as a new strategy will have to be devised here.

[GeekPress]

@iCaspar @Tabrisrp FYI, I've just submitted a patch to allow wp_resource_hints to allow multiple usages of a relation type:
https://core.trac.wordpress.org/ticket/52465

[GeekPress]

@iCaspar @Tabrisrp until this enhancement will be approved and merged in the core (🤞), let's implement the first enhancement.

I don't think we need to complexify the code on our side to have both preconnect right now. The benefits in terms of performance don't worth it.

Having already the preconnect without the crossorigin will be better than just the actual dns-prefetch (Better done than perfect ^^).

We have two solutions:

1. We extend the wp_resource_hints filter by adding only the preconnect without the crossorigin (it will be helpful for all resources, except for fonts in CSS files).

2. We extend the wp_resource_hints filter to add both preconnect. We will add them in this order:

<?php
function preconnect_mycdn( $hints, $relation_type ) {
        $domains = [
                [
                        'href'        => '//mycdn.test/',
                        'crossorigin' => 'anonymous',
                ],
                [
                        'href'        => '//mycdn.test/',
                ],
        ];

        foreach ( $domains as $domain ) {
                if ( 'preconnect' === $relation_type ) {
                        $hints[] = $domain;
                }
        }

        return $hints;
}
add_filter( 'wp_resource_hints', 'preconnect_mycdn', 10, 2 );

In this way, with the current behavior the version without the crossorigin will be printed.

But once the wp_resource_hints will allow both usage, I don't know if having the crossorigin first will be a bad thing.

@iCaspar @Tabrisrp What do you think about the solution to adopt? And could you update the effort according to the new solution?