WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#37387 closed defect (bug) (fixed)

Resource hinting: Do not preconnect to emoji CDN.

Reported by: peterwilsoncc Owned by: ocean90
Milestone: 4.6 Priority: normal
Severity: normal Version: 4.6
Component: Script Loader Keywords: good-first-bug has-patch commit
Focuses: Cc:
PR Number:

Description

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.

Attachments (1)

37387.diff (4.2 KB) - added by peterwilsoncc 3 years ago.

Download all attachments as: .zip

Change History (15)

#1 @peterwilsoncc
3 years ago

Related #37386, #37388

Last edited 3 years ago by peterwilsoncc (previous) (diff)

#2 @peterwilsoncc
3 years ago

  • Keywords needs-patch needs-unit-tests added

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?

#3 @dd32
3 years ago

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.

#4 @voldemortensen
3 years ago

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.

#5 @peterwilsoncc
3 years ago

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.

#6 @peterwilsoncc
3 years ago

  • Keywords good-first-bug added

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

#7 follow-up: @swissspidy
3 years ago

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

#8 in reply to: ↑ 7 @peterwilsoncc
3 years ago

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.

#9 @pento
3 years ago

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. :-)

#10 @pento
3 years ago

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.

This ticket was mentioned in Slack in #core by peterwilsoncc. View the logs.


3 years ago

@peterwilsoncc
3 years ago

#12 @peterwilsoncc
3 years ago

  • Keywords has-patch added; needs-patch needs-unit-tests removed

A first pass in 37387.diff.

There is both cleaner and messier code in WP core.

#13 @pento
3 years ago

  • Keywords commit added
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.

#14 @ocean90
3 years ago

  • Owner set to ocean90
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.