Opened 3 years ago
Closed 17 months ago
#44229 closed enhancement (wontfix)
Use CDNs where possible to serve external assets like jQuery
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | General | Keywords: | close |
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 (13)
#1
in reply to:
↑ description
;
follow-up:
↓ 2
@
3 years ago
#2
in reply to:
↑ 1
@
3 years 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.
#3
follow-up:
↓ 5
@
3 years 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:
↓ 6
@
3 years 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
@
3 years 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:
↓ 7
@
3 years 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:
↓ 8
@
3 years 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
@
3 years 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
@
3 years 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.
#10
follow-up:
↓ 11
@
3 years 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
@
3 years 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.
#12
@
17 months ago
- Keywords close added
The performance benefits touted here are no longer relevant - browsers nowadays use separate caches for each domain1, so e.g. 2 different sites loading jQuery from Google would still mean the end user downloading it twice. As such the performance would suffer if anything, particularly if the origin site is using HTTP/2.
Since there is no longer any benefit to making this change - not to mention the concerns raised above - I'd suggest this can be closed.
1 Specific details have been difficult to track down, but as I understand it Firefox and Safari both already do this, and Chrome is working towards it (see e.g. https://www.chromestatus.com/feature/5730772021411840 and https://github.com/whatwg/fetch/issues/904).
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).