Jetpack: Create a filter for dns_prefetch links

[htdat]

Original from this issue https://github.com/Automattic/jetpack/issues/8089 , the user expects to have a filter to decide when/where Jetpack loads the dns_prefetch links. They even can add their own dns_prefetch links.

The reasoning from the user:

Now the method dns_prefetch defined in the Jetpack class is called and these rules are added. I looked also in the Jetpack class to see if I can use something to remove or filter the rules, but this method has no filters and I did not find any other method declared that modified or removed these rules. As I have seen the array holding the rules is a static array that is declared inside the dns_prefetch method and is not accessed anywhere else.

The rules are added into this array, directly, without a key.

If I was to fix this I would add the arrays of rules into this method with a key for every module like Jetpack::dns_prefetch(‘masterbar_dns_rules’, array of rules); 
Then declare the arrays for each module so they can be accessed by a variable. 
Then when it is checked if the user is logged in and what modules are active use the Jetpack::dns_prefetch method again to remove them (by sending a null value for that key) or add them by using the array of rules specific to that module.

Ref: 750284-zen

[willstocks]

+1 to this per https://wordpress.org/support/topic/filter-out-dns-prefetch-requests/

I don't know why these prefetches are added, simply because I'm not utilizing the Jetpack functionality that would rely upon these external domains. Therefore I'm seeing the following 6 unnecessary dns-prefetches:

<link rel="dns-prefetch" href="//s0.wp.com">
<link rel="dns-prefetch" href="//s1.wp.com">
<link rel="dns-prefetch" href="//s2.wp.com">
<link rel="dns-prefetch" href="//0.gravatar.com">
<link rel="dns-prefetch" href="//1.gravatar.com">
<link rel="dns-prefetch" href="//2.gravatar.com">

[jeherve]

@willstocks-tech Those prefetches are only added if you use modules that rely on them.

Those 6 requests, for example, are enabled if you use Jetpack's "WordPress.com Toolbar" feature:
https://jetpack.com/support/masterbar/

Once you deactivate that feature, Jetpack will stop trying to prefetch those domains.

It is worth noting that some of these domains are also prefetched if you use features like Jetpack's Comment form, or Likes features.

[willstocks]

@jeherve - I'm not using the toolbar feature :S
The only things I currently have enabled are as follows:

So comment likes utilizes all 6 of these domains?
Site Stats I can understand utilizing: <link rel="dns-prefetch" href="//s0.wp.com"> but I don't understand the remainder? Should these not all be added via wp_resource_hints as opposed to declared separately?

[jeherve]

Comment likes do indeed need quite a few domains, because the likes load in an iFrame that lives on WordPress.com.
https://github.com/Automattic/jetpack/blob/08d3ac7372ed9924eb5ba7bd489bb8863e435e85/modules/comment-likes.php#L14

That said, it may be good to review and see if we still need to load the Gravatar domains there, since we do not display any avatars there, not like for regular likes.
@vindl Looping you in since you originally worked on #7175.

[vindl]

@jeherve I think we can remove the Gravatar prefetch there. If I recall correctly, initially we planned to have avatars displayed on hover (similar to WP.com), but that was never implemented due to iframe and security limitations.

[jeherve]

Thanks for the feedback. This will be addressed in #10330. @willstocks-tech That should solve your issue.

[willstocks]

Brilliant, thanks @jeherve & @vindl :D

[kraftbj]

Related to this, instead of adding a filter to Jetpack, perhaps we should leverage Core's resource hints framework and add our domains via the https://developer.wordpress.org/reference/hooks/wp_resource_hints/ filter?

[willstocks]

@kraftbj - I did mention this further up, I'm surprised it's not being utilized?

[jeherve]

Copying my response from the PR mentioned above:

That function just did not exist yet when we added the prefetch feature to Jetpack in #1399.

Moving away from our own function and to wp_resource_hints() would be a good way to fix our issue.

Do not hesitate to give it a try if you'd like!

[willstocks]

@jeherve I'm not going to lie to you, it's my first proper attempt at registering a resource hint this way, but what are your thoughts on:
https://github.com/willstocks-tech/jetpack/blob/de67fffde9a4403b274c2e6babacf92c909eff80/modules/comment-likes.php#L14-L20

[jeherve]

If it tests well, I would recommend that you replace the other occurences of Jetpack::dns_prefetch in the codebase, deprecate that function, and submit a PR with everything you have. We'll review it and see if we can merge it and close this issue!

As a bonus, I had added the Hacktoberfest label to this issue, so submitting a PR would get you started with Hacktoberfest :)
https://hacktoberfest.digitalocean.com/

[willstocks]

@jeherve I think I've covered all of the bases :) Let me know your thoughts on #10349

[willstocks]

@jeherve - so I made a bit of a hash of that PR in all honesty!
I think your alternative was a better option, to convert Jetpack::dns_prefetch to utilize wp_resource_hints() instead. Therefore, I've got another branch, where I _think_ I may have managed to do the job:
https://github.com/willstocks-tech/jetpack/blob/ea59d587bbd201709e9f7b283672dc596e65285b/class.jetpack.php#L6933-L6952
In _theory_ this will allow for all existing config to remain as is, but wp_resource_hints would handle the actual <link rel=> stuff

[willstocks]

@jeherve - Just FYI, I closed off that original PR because it was just a bit of a mess. I'm hoping #10352 is more appropriate :)
Thanks for your input/assistance!!!