Make WordPress Core

Opened 7 years ago

Closed 6 years ago

#31801 closed enhancement (wontfix)

Use wordpress.org CDN for all hosted assets.

Reported by: peterwilsoncc's profile peterwilsoncc Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: External Libraries Keywords:
Focuses: performance Cc:

Description

Hosted assets within core come from a number of sources:

  • Google AJAX CDN (deprecated libraries)
  • Google Font Library (open sans)
  • wordpress.org CDN (emoji - pending completion of blessed ticket #31651)
  • gravatar.com CDN (gravatars)
  • wp.com CDN (gravatar custom defaults, redirected away from gravatar.com)

It would be nice to reduce DNS lookups by placing all hosted assets on wordpress.org's CDN. I suspect gravatars would need to remain as is.

Before patches get written and URLs imagined, is this something the wordpress.org team would be in to?

Change History (10)

#2 @iseulde
7 years ago

  • Version trunk deleted

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


7 years ago

#4 @dd32
7 years ago

I don't think there's anything here that we can, or should do.

Google AJAX CDN (deprecated libraries)

I don't think WordPress.org should host these outdated libraries, we use Googles CDN which is used by many others, and likely the DNS is cached locally (or close by)

Google Font Library (open sans)

As in #26072, the font isn't simply a single file, theres server-side browser-specific alterations made to the package

gravatar.com CDN (gravatars)
wp.com CDN (gravatar custom defaults, redirected away from gravatar.com)

Both of these are Automattic-owned and managed - a request could be put to the Gravatar team to host those themselves I guess. I don't see a need for WordPress.org to host the fallbacks.

Which leaves the Emoji on WordPress.org-hosted CDN.. which is also the same CDN where we host about page images and similar content.

#5 @dorianmuthig
7 years ago

  • Is inappropriate change
  • Has security implications

As per comment on GitHub: https://github.com/WordPress/WordPress/commit/81df9bffc5ffdda9cd7c16dadef21b574f9ee922#commitcomment-11859945 (most recent code change that is relevant to the issue described)
And suggestion from: https://core.trac.wordpress.org/ticket/32552?cnum_edit=9#comment:10

Please make a change and do not load libraries from external sources. This centralizes the failure point and enables the external provider to track all visitors, or worse, inject code in a targeted manner via referrer, domain, IP and public cookie matching. Please include these resources locally with the wordpress installation and make using the local copy the default. In case you'd like to provide users with the option to use a CDN, please do it in a manner which allows and encourages those managing multiple wordpress installations to 1. use their own, 2. verify the script loaded is the right one (lazy load it with JavaScript and verify a checksum) and 3. avoid leaking user's browser behavior to third parties.

#6 follow-up: @peterwilsoncc
7 years ago

@dorianmuthig,

I can see you've posted this same comment on #26072 (related to bundling external assets) after been directed away from #32552. A duel posting scatter-gun approach is not going to help your cause, in fact it's going to hinder it.

Whilst bundling assets is related, it's a slightly off-topic subject for this ticket.

My intent for this ticket as to use a single CDN - where possible - for hosting external assets. Please keep the ticket on topic.

-

Thanks for your earlier response @dd32, that all makes sense so happy if this ticket gets a few -1s for it to be posted as wontfix.

#7 in reply to: ↑ 6 @dorianmuthig
7 years ago

Replying to peterwilsoncc:

@dorianmuthig,

I can see you've posted this same comment on #26072 (related to bundling external assets) after been directed away from #32552. A duel posting scatter-gun approach is not going to help your cause, in fact it's going to hinder it.

Since the issue is related, and using external resources is actually illegal for users in all EU states, for the aforementioned reasons, external resources are blocked or considerably slower than average in restrictive regimes like China or the Middle East, where WordPress is a very important tool for activists and bedroom journalists, making you aware is a very appropriate thing.

Whilst bundling assets is related, it's a slightly off-topic subject for this ticket.

Your change is the wrong type of change and thus a bad change. If a change is to be made, it should foremost be bundling. You can then opt to use a CDN via a plugin or configuration option (the latter would need to be added).

My intent for this ticket as to use a single CDN - where possible - for hosting external assets. Please keep the ticket on topic.

I am. To me, who is looking at the spot in the code affected, this is the same thing.

#8 follow-up: @dd32
7 years ago

@dorianmuthig The point was, these are already external assets, and this ticket isn't debating whether to package them or not. we're focusing 100% on the external asset locations here, and unrelated discussion leads to confusion and no clear outcome of the ticket.

The discussion for external vs packaged assets is a much larger battle, and one that has taken place extensively for the fonts in #26072 - I'd suggest that's the best place to make yourself heard.

#9 in reply to: ↑ 8 @dorianmuthig
7 years ago

Replying to dd32:

[...] unrelated discussion leads to confusion and no clear outcome of the ticket.

Rightly, and appropriately so. After all, that was the whole point. What this ticket attempts affects the relevant portion of the code, but not in a way which is meaningful or desirable by any stretch of the imagination. This, I believe, you have mentioned yourself in comment 4 already as well.
The inclusion of the reference and alternate information may lead onlookers who are ill informed or due to lack of information would exhibit similar notions to find a more appropriate solution they would otherwise never come to consider. What you feel to be derailing of a ticket, I consider redirecting to more appropriate concerns. In similar vein, it should probably be resolved as "wontfix" and closed. I am however going to leave this to someone who makes such decisions a bit more often than me.

#10 @peterwilsoncc
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing this off, there's a lack of traction and #36753 reduces the need.

Note: See TracTickets for help on using tickets.