Resource hinting: Do not preconnect to emoji CDN.

[peterwilsoncc]

From @johnbillion in #34292:

Including a default preconnect entry for s.w.org seems unjustified. This means every single visitor (with a supporting browser) to every single WordPress site in the world will be performing a preconnect to s.w.org, purely to save a few ms in case an emoji is used that's not supported by the browser.

Does this really justify a preconnect to s.w.org on every site?

@superpoincare echoed some of these concerns

Putting against teh milestone to encourage consideration before the resource hinting feature launches.

[peterwilsoncc]

Related #37386, #37388

[peterwilsoncc]

I've been thinking about this overnight, my proposal:

• punt it from PHP, we don't know if the client requires the PNG or SVG CDN at that point. They can differ, although don't by default
• if the client fails the browser sniff, add a preconnect to the appropriate CDN via JS per the spec. The preconnection will happen while twemoji runs.
• per my comment in ##34292, I'm not concerned about the extra connection client side but less keen for the sake of the CDN.

Thoughts?

[dd32]

if the client fails the browser sniff, add a preconnect to the appropriate CDN via JS per the spec. The preconnection will happen while twemoji runs.

This seems like the more correct option over always performing it, although it's only shaving a few ms in the event that a emoji is in use.
I'm not sure myself if it should be in the list at all, a fallback emoji loading a few ms later isn't going to be the end of the world, and browsers are getting better at supporting everything already.
I'd say the vast majority of WordPress sites don't actually have any Emoji's on them, so a few ms in those cases would be fine.

[voldemortensen]

I think this approach would be best. I didn't realize there were two CDN's or this may have been caught prior to now.

To echo @peterwilsoncc, even if a preconnect happened on every WP everywhere, I'm not concerned about client-side performance. It all comes down to how it will effect the s.w.org CDN.

[peterwilsoncc]

That's a quorum, to avoid an unnecessary refresh #37385 will need to be committed before a patch can be worked up. I'll drop a note in here once this is done.

[peterwilsoncc]

#37385 is committed, this ticket is ready for a patch. Both source and tests will need updating.

[swissspidy]

See #33210 for the original suggestion to add the preconnect entry for the CDN. @pento mentioned that it improved emoji render time by 90ms.

[peterwilsoncc]

Replying to swissspidy:

See #33210 for the original suggestion to add the preconnect entry for the CDN. @pento mentioned that it improved emoji render time by 90ms.

Yep, let's get in for 4.7 and accounting for the two CDNs. I added the second one earlier in the 4.6 cycle and it slipped my mind in the context of these tickets, I'm afraid.

[pento]

Let's change it to a dns-prefetch, which will still give us some advantage.

• As has been discussed, the preconnect will be potentially pretty heavy on the CDN. With the Unicode 9.0 emoji update, almost all browsers will trigger the preconnect, even if we wait until after they've failed the emoji render test. This will reduce over time, as browsers add native Unicode 9.0 support.
• The preconnect only opens one connection, but s.w.org is HTTP/1.1, so the browser will use the preconnected connection for the first emoji, then it has to open new connections for subsequent emoji. That seems... not very helpful. :-)

[pento]

Also, the esc_url() in wp_resource_hints() adds http:// to s.w.org, which is not helpful when emoji are always loaded over HTTPS.

[peterwilsoncc]

A first pass in 37387.diff​.

There is both cleaner and messier code in WP core.

[pento]

wordpress-develop$ ack -i TODO | wc -l
632

Let's not increment that number with another TODO comment that will live forever, just create a new ticket instead.

Apart from that, I'm cool with this patch, it's a nice way of grabbing the vast majority of (I'm willing to bet all) custom CDNs.

[ocean90]

In 38122:

Script Loader: Use dns-prefetch for the Emoji CDN.

• preconnect will be potentially pretty heavy on the CDN. With the Unicode 9.0 emoji update, almost all browsers will trigger the preconnect.
• preconnect only opens one connection, but s.w.org is HTTP/1.1, so the browser will use the preconnected connection for the first emoji, then it has to open new connections for subsequent emoji.

Also use the same URL as we use for the emoji_svg_url filter. This will print the hint for the correct CDN in case someone uses a custom CDN.

Props peterwilsoncc.
Fixes #37387.

[audrasjb]

In 53904:

Script Loader: Remove default DNS prefetch entry for s.w.org.

A default DNS prefetch entry for s.w.org was previously included to save a few ms in case an emoji is used that is not supported by the browser. It appears this use case doesn't justify a prefetch to s.w.org on every WordPress website.

This changesets removes emoji_svg_url prefetch from wp_resource_hints(). It also updates unit tests in Tests_General_wpResourceHints by removing test_should_have_defaults_on_frontend() entirely and removing s.w.org prefetch from expected output of ten other test functions.

Plugin authors can use the wp_resource_hints filter if they need to re-add the DNS prefetch entry for s.w.org.

Follow-up to [37920], [38122].

Props joelhardi, superpoincare, jhabdas, garrett-eclipse, sabernhardt, SergeyBiryukov.
Fixes #40426.
See #37387.