WordPress.org

Make WordPress Core

Opened 4 weeks ago

Last modified 4 weeks 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 (8)

#1 in reply to: ↑ description ; follow-up: @superpoincare
4 weeks 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
4 weeks 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 4 weeks ago by jacklenox (previous) (diff)

#3 follow-up: @swissspidy
4 weeks 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
4 weeks 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
4 weeks 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
4 weeks 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
4 weeks 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
4 weeks 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.

Note: See TracTickets for help on using tickets.