WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 8 months ago

#44229 new enhancement

Use CDNs where possible to serve external assets like jQuery

Reported by: jacklenox Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

There has been a long history of WordPress developers switching out the packaged version of jQuery in favour of using one from a CDN, like the one from Google's Hosted Libraries. A particular win when doing this is it means that if the browser has already cached jQuery from a CDN like Google's, it doesn't bother downloading it again when loading a new website that requests it.

Unnecessary HTTP requests resemble a waste of electricity and carry a carbon footprint. That each WordPress site includes its own copy of jQuery could be seen to represent a massive waste of energy. Mozilla's 2018 Internet Health Report highlights the growing – and potentially unsustainable – energy demand of the Internet: https://internethealthreport.org/2018/the-internet-uses-more-electricity-than/

Could we consider making a change to WordPress whereby its first port of call for jQuery (and other JS libraries) is at a centralised location? Either with someone like Google or perhaps hosted on w.org?

As well as representing a vast potential energy saving, this would also make all WordPress sites a little bit quicker.

We could still include the locally packaged copy of jQuery and use it as a fallback where necessary like so:

<script>if ( ! jQuery ) document.write('<script src=jquery.js></script>')</script> (h/t @johnbillion)

Change History (11)

#1 in reply to: ↑ description ; follow-up: @superpoincare
13 months ago

Replying to jacklenox:

I think Wordpress' policy is to self host as much as possible. Google Fonts is an exception in bundled themes because the most optimal way involves doing a lot of user agent detection which is not easy to do and maintain.

Having jQuery load from Google or some other CDN may not be preferable since many people use blockers such as uBlock Origin for which the expert setting is to block third party javascript.

There are plugins available for loading jQuery from CDN and can also be done easily from the child theme.

(Incidentally Chrome doesn't like document.write, so you shouldn't use it).

#2 in reply to: ↑ 1 @jacklenox
13 months ago

Replying to superpoincare:

I think Wordpress' policy is to self host as much as possible. Google Fonts is an exception in bundled themes because the most optimal way involves doing a lot of user agent detection which is not easy to do and maintain.

Yep, I understand. If it is the policy, I'm challenging it. :)

Having jQuery load from Google or some other CDN may not be preferable since many people use blockers such as uBlock Origin for which the expert setting is to block third party javascript.

This is a good point. However, I suspect the vast majority of notable WordPress websites use some form of CDN for their assets, including JavaScript. The sort of person blocking any third party JS is probably also the sort of person who would understand why things might behave in an unusual way.

There are plugins available for loading jQuery from CDN and can also be done easily from the child theme.

Yep, I mention doing it yourself at the top of the ticket. But my focus here is on the seismic shift that would happen if this was implemented at a core level.

(Incidentally Chrome doesn't like document.write, so you shouldn't use it).

Sure, it's just a rudimentary example of a way that you could do a fallback.

Last edited 13 months ago by jacklenox (previous) (diff)

#3 follow-up: @swissspidy
13 months ago

Lots of people stop using or recommending using CDNs nowadays because of GDPR stuff. We have to keep that in mind.

#4 follow-up: @bemdesign
13 months ago

I believe one issue with this is that certain nations block things like CDNs. So users in these nations may get a very sub-par WordPress experience because these resources are blocked and unavailable. Thinking about one of the core missions of WordPress - to democratize publishing - it then makes sense to include all these dependencies inside WordPress rather then rely on external resources which may or may not be available for all users.

#5 in reply to: ↑ 3 @jacklenox
13 months ago

Replying to swissspidy:

Lots of people stop using or recommending using CDNs nowadays because of GDPR stuff. We have to keep that in mind.

This is a good point. Where this is happening, I suspect it's due to FUD. Google are GDPR-compliant as are most major CDN providers. They can't afford not to be. But I agree we should keep it in mind.

#6 in reply to: ↑ 4 ; follow-up: @jacklenox
13 months ago

Replying to bemdesign:

I believe one issue with this is that certain nations block things like CDNs. So users in these nations may get a very sub-par WordPress experience because these resources are blocked and unavailable. Thinking about one of the core missions of WordPress - to democratize publishing - it then makes sense to include all these dependencies inside WordPress rather then rely on external resources which may or may not be available for all users.

As I say in the ticket, we could have a fallback. I don't think such an idea should be implemented without a fallback.

#7 in reply to: ↑ 6 ; follow-up: @SergeyBiryukov
13 months ago

Replying to jacklenox:

As I say in the ticket, we could have a fallback. I don't think such an idea should be implemented without a fallback.

Unless I'm missing something, there will still be an HTTP request to an unavailable resource before switching to fallback, leading to a slower, not faster experience.

#8 in reply to: ↑ 7 @jacklenox
13 months ago

Replying to SergeyBiryukov:

Unless I'm missing something, there will still be an HTTP request to an unavailable resource before switching to fallback, leading to a slower, not faster experience.

Ah I see. Yes, this is a consideration. There are a number of ways this could be mitigated:

  • When the CDN doesn't respond, a cache value could be set to not bother trying it again for a predetermined amount of time, perhaps indefinitely. As soon as the local version of jQuery is loaded, there is no longer a case for trying to provide the client with the CDN version. The cache value could include country data which would prevent future users from the same country experiencing this problem.
  • There could be an option to unset a constant that would allow people to disable the CDN in their wp-config. E.g. something like define( 'WP_USE_CDN', false );

I think in the vast majority of cases, the CDN option would work fine, save a lot of energy and represent an improvement for most users.

#9 @dimadin
9 months ago

FYI, I released a plugin that uses CDN for all assets from core, and plugins and themes hosted by wp.org (in other words: assets that are open source). There are no fallback, though it first checks if identical remote resource exists, caches that for some time, and also includes Subresource Identity Hash of remote resource to prevent loading in case CDN got compromised.

https://wordpress.org/plugins/commonwp/

#10 follow-up: @Otto42
9 months ago

The main issue with this suggestion, other than the above mentions about GDPR-FUD or countries blocking CDNs, is actually quite simple: WordPress is used on lots of sites by users without unrestricted internet access. Local intranets run WordPress too, and those users with browsers on an internal company system may not have outside access, but still need to access internal sites. The site should run properly for such cases as well.

Given how easy it is for plugins to adjust the source of a enqueued item, and thus that CDN enabler plugins can exist, this seems best left in plugin terrority. Tying WordPress core to a specific CDN provider (even if it's one we serve up ourselves like s.w.org) doesn't seem to be a good strategy. It can break in edge cases like intranets and country blocking, and it ties a fairly important piece of the core to some external provider, which can break or go down or just change out from underneath us.

So, nice thought, but not a good idea for core.

-1

#11 in reply to: ↑ 10 @smartyp
8 months ago

Replying to Otto42:

It can break in edge cases like intranets and country blocking, and it ties a fairly important piece of the core to some external provider, which can break or go down or just change out from underneath us.

But doesn't having the fallback (and/or an override option) mitigate all of this?

Seems like an awesome win to me (in terms of stated objectives) for the vast majority of WP powered sites. Leaving it to plugins doesn't achieve the big potential gains.

And core has previously relied on Google for Fonts.

Note: See TracTickets for help on using tickets.