Feature Request - Option to Serve jQuery (and other JS libs) from Google Hosted Libraries / CDNJS

[dbaritchi]

Hi there!

A number of the javascript libraries distributed with WordPress are also hosted on Google's Hosted Libraries project and CDNJS.

It would be awesome to have a checkbox/ option to enable auto URL replacement site-wide for these common JS libraries with calls to Google Hosted Libraries ( https://developers.google.com/speed/libraries/ ) or the Cloudflare-supported CDNJS ( https://cdnjs.com/ ).

Both these sources make these libraries freely accessible so any site can simply use their URL instead of serving their own. That will cust bandwidth cost for all sites using this - and make our sites faster. Google and CloudFlare served JS libs will be faster than any site hosting plan and served at no cost :)

Maybe this shouldn't be enabled by default, but it could be a simple checkbox for each of the major JS libs in settings - to enable replacement of that library site-wide.

This is different from setting up a CDN account for URL replacement of all static content (i.e. with MaxCDN) and from setting up a CloudFlare account for caching of static content - because it could be an instantly enabled feature that makes your site faster and saves you bandwith/money, with no accounts necessary, just check the checkbox and it's on.

Could be a Pro-only feature, or core, whatever works.

FYI there's a Wordpress plugin to do something similar, tho it currently doesn't work seems to no longer be supported. But it could be a great starting point for this feature: https://wordpress.org/plugins/use-google-libraries/

See also: 3 reasons why you should let Google host jQuery for you http://encosia.com/3-reasons-why-you-should-let-google-host-jquery-for-you/

Thanks! Dan

[raamdev]

@dbaritchi Thanks for the feature request. :-)

---

@jaswsinc Any thoughts on this feature? It seems like a nice feature to add to the Lite version (we haven't released many new features in the Lite version and this seems like it would fit well).

My first thought about this was that there might be issues with library versions (i.e., we need to make sure we link to the right version libraries as to not cause problems), but then I realized there should be an easy way to figure out which versions of the libraries WordPress is using and then link to those versions.

The Use Google Libraries plugin linked to above has 90k+ active installs, which shows there's a serious interest in this feature. (That plugin hasn't been updated in 7+ months and people are starting to complain about lack of support for the latest versions of WordPress.)

[dbaritchi]

@raamdev Thanks. Glad you're considering this. I was looking at other possible ways to offload processing from our servers and this idea just seems to fit with a high end caching/performance plugin like ZenCache.

ZenCache is doing great so far in our long term BlogPress evaluation. It has been a far more positive experience for us than a French option proved to be not long before. Even on a very large multisite it's performing great. :)

[KTS915]

That's a very old reference to which @dbaritchi linked! I could find much more recent articles written by developers considered to be WP gurus who would advise strongly that replacing WP jQuery with Google jQuery should not be done.

But I'm not going to do that. My point is that there are strong arguments on both sides, and no one article has the answers.

What does concern me is that Zen Cache should not include a feature that, even if it's not enabled by default, gets users upset because they don't understand its practical implications.

What bothers me specifically about this suggestion is that the default jQuery in WP is loaded in "no conflict" mode. The jQuery loaded from Google is not in no conflict mode. This means that enabling such a feature risks causing all sorts of conflicts on users' sites.

If you can work out a way to avoid this problem, then fine. Otherwise, I'd be very cautious.

[KTS915]

Thinking about this further, the point is to speed up the site on which this is done (and/or reduce server load). It's certainly not about changing a site's configuration.

So you would also need to make sure that the Google version of jQuery being loaded is the same as the one WP is using.

[jaswrks]

@KTS915 writes...

the default jQuery in WP is loaded in "no conflict" mode. The jQuery loaded from Google is not in no conflict mode.

Ah, good point. Yep. That's a tricky thing to work around. We can load jQuery into noConflict mode, even from a CDN, but it requires an additional line of code just after the script is included. https://api.jquery.com/jquery.noconflict/

Hmm. I don't think it's worth us trying to load jQuery into noConflict mode though, because the only conflicts that exist are between JavaScript frameworks. In most cases, if you're running jQuery, you're not running another framework, and it's fine to load jQuery into a mode where $ is associated with jQuery.

We would need to warn site owners about this though, before it is enabled. Definitely.

---

@raamdev writes...

Any thoughts on this feature?

I think it's generally a good idea. We have been doing this for years.

However, given the number jQuery versions in use, the number of CDNs in use, and the fact that many WordPress installations toss a ?ver=xxxx onto the end of the resource URLs anyway—all of that diminishes the intended benefit of doing this, to a point where I just don't bother with this myself anymore.

Keep in mind that the HTML Compressor makes this sort of a moot point whenever it runs, because it consolidates jQuery right along with everything else, so that it can be served locally with as little as a single connection.

The Use Google Libraries plugin linked to above has 90k+ active installs

Wow. That's cool. Well, it's not any big deal for us to add this feature. I'm fine with it.

Having said that, I personally, am more interested in discussing ways that we make ZenCache more HTTP/2 friendly. https://www.nginx.com/resources/webinars/whats-new-in-http2/

Not that's it is not already HTTP/2 friendly, but my feeling is that the next 90K installs are going to come from plugins that put a focus on HTTP/2. FTW!

[dbaritchi]

Hey guys, just came across another Wordpress plugin that has the same functionality for jQuery URL replacement as the one linked above - but it handles both Google Libraries AND CDNJS - so code may be helpful.

Here's the description:

Get the speed benefits of loading jQuery (and jQuery Migrate) from a CDN while providing a fallback to the local version in the event the CDN is down. It also uses the same version as WordPress does - automagically, so you're never out of sync.

Loading jQuery from cdnjs By default, jQuery is loaded from Google with jQuery Migrate being loaded from cdnjs. If you'd like to also load jQuery from cdnjs, add the following to wp-config.php

https://wordpress.org/plugins/wp-jquery-plus/

[dbaritchi]

Ah, good point. Yep. That's a tricky thing to work around. We can load jQuery into noConflict mode, even from a CDN, but it requires an additional line of code just after the script is included. https://api.jquery.com/jquery.noconflict/

Hmm. I don't think it's worth us trying to load jQuery into noConflict mode though, because the only conflicts that exist are between JavaScript frameworks. In most cases, if you're running jQuery, you're not running another framework, and it's fine to load jQuery into a mode where $ is associated with jQuery.

I've been doing some research this morning on the noconflict problem brought up above relating to doing CDN URL replacement for jQuery - and at least to me it seems all the conflicts and problems forlks are running into are specifically due to not loading jQuery in "no conflict" mode like Wordpress does by default.

Is there any reason to not add that no-conflict line as well?

If that extra line of code is really all it takes to have the exact same behavior that Wordpress ships with (loaded in noconflict mode) - then it seems like that's the safer way to go as that's what site owners are getting and expecting. no telling what JS lib conflicts may be caused otherwise. :)

we have a lot of themes and plugins on our multisite, and quite few different JS libraries... the more "like stock Wordpress", the better. :)

Thanks! Dan

[KTS915]

@dbaritchi: Thanks for your latest comments. I agree with your approach.

But have you actually tried WP jQuery Plus with Zen Cache Pro? In the last twenty minutes, I've been testing them together on two sites (one localhost, the other with my paid host). The results were the same on both.

• WP jQuery Plus clearly made the sites faster than running no caching or compression at all.
• Zen Cache made the sites faster than WP jQuery Plus.
• But running them both together not only made the sites slower, it also made them much less consistent.

Of course, this doesn't necessarily make the principle wrong. Maybe it's just this particular implementation. But it does illustrate why I've never been tempted to use Google's CDN.

In fact, I even disable all Google fonts (even the WP defaults) from my sites. I have found that running a site on a decent host produces highly consistent results, whereas relying on Google means being dependent on how much use a particular node (out of my control) is getting at any time. I've seen sites hang for 20+ seconds because Google was so slow in serving a font.

[dbaritchi]

@KTS915 i have not, our network is too "production" to test a plugin in that way, no telling what could conflict on what site lol. I actually only found this one when looking for the "no conflict" issue you mentioned, where i too found the "add the line of no conflict code" as a solution. :)

But I would think it's hard isolate that conclusion from that test. That test tells us the plugin WP jQuery Plus is perhaps poorly written, has a bug, who knows.

i'm sure Zen Cache Pro is far more efficient than a quick plugin like this example one - and Zen Cache Pro already has URL replacement code which i'm sure has been optimize.

A proper caching plugin - i.e. Zen Cache Pro is a must imho especially for a hight traffic site. And CDN URL replacement of common files - i.e. jQuery and other common libs is going to make it faster all things being equal.

the idea for this feature was a quick one-click option to enable the speed and power of CDN URL replacment for common JS libraries without having to purchase and set up a MaxCDN account or to implement URL replacement for everything.

And indeed it's literally to enhance speed and lower server load. For example for us, our Wordpress multisite has thousands of sites on it, many domain mapped, so that means thousands of sites serving up jQuery and other libs on each initial pageview from our server.

Caching static files helps for subsequent views, but first time cold cache requests are expensive - and everything helps. :)

And especially when you're talking multisite with more than one site, and with each site having multiple simultaneous visiotrs, that's a whole different dimension from a single site with few visitors... thus a lot more benefit when offloading even a few fiels network-wide.

Heck this could be a nice feature of the Premium version... "one-click CDN URL replacement of common JS libs - you choose Google Libraries or CDNJS".

Actually i think you can even URL replace the jQuery libraries from the jQuery site direct as an option... powered by MaxCDN. CDNJS (and Google Libraries) give you the option to include other common libraries in your checkboxes of what to replace.

i ran across this quote from this gentleman who is a core developer for Yoast SEO (screenshot attached below).

Thanks! Dan

[KTS915]

@dbaritchi: Yes, I have seen that thread before. And I agree that my tests don't necessarily tell us much about the principle. (In fact, I said as much when I reported them.)

But, interestingly, you've quoted my favorite bit about that thread. Because I don't use a CDN on my sites (which are complex things with 70+ plugins and a lot of content), and yet they score 98% on Yslow and PageSpeed! (And pages load in well under a second, except on first load, where Pingdom says 0.6s and GMetrix says 1.3s) So I find even less reason to take what's said there too seriously.

That's why I like to test things for myself -- and then test more, and test again. In fact, I am now quite convinced that WP jQ+ isn't the answer. I put it on a much "lighter" site that I manage, but whose owner is too stingy to pay for the Pro version of Zen Cache. It made not the slightest difference, even to first load. I have been clearing caches, etc periodically since you posted about it, and I can see absolutely no difference between Zen Cache free alone, and ZC plus WP jQ+.

[dbaritchi]

lol @KTS915 i know, i quoted that post in spite of. ;)

in all seriousness, the only real comparison is doing independent loads of JUST the JS libs from your server compared with the Google Libs served file and CDNJS file or jquery.com file.

Google / CDNJS / even jquery.com will simply deliver that file much faster and compounded by multiple sites with multiple visitors each, that is a good thing.

for the visitor it will be a faster experience regardless because Google Libs / CDNJS (powered by CloudFlare) have edge servers everywhere where the file already lives already close to these first time visitors. so win/win/win. :)

[jaswrks]

@dbaritchi

Hey guys, just came across another Wordpress plugin that has the same functionality for jQuery URL replacement as the one linked above - but it handles both Google Libraries AND CDNJS - so code may be helpful.

Cool. Thanks for relaying that.

[KTS915]

@dbaritchi: :)

"for the visitor it will be a faster experience regardless because Google Libs / CDNJS (powered by CloudFlare) have edge servers everywhere where the file already lives already close to these first time visitors. so win/win/win. :)"

As I said, I don't think that's necessarily true. 98% of the time, probably. The other 2%? That's not a given at all. You are overlooking the fact that such a setup requires a connection to Google. That is dependent not just on Google, but on service providers in between. So you've just introduced numerous new points of failure.

That's actually one of the things that WPjQ+ gets wrong, in my view. Unless you add an extra line of code, it's loading things from not one but two different places (Google and a CDN) so is doubling the chance of problems.

The point is that everything runs at the speed of the slowest component. More points of failure creates greater risk of failure, which creates occasionally very slow sites. And, because users will normally be used to something much faster, they'll think your site is broken.

I've seen this happen a lot. That's why I would never do this. It's much better to get a really good host and minimize the points of failure. You might not get the last hundredth of a second of speed out the site, but it will be consistently fast.

However, I should emphasize that I am not against including this sort of feature in Zen Cache -- it's your site, not mine! -- just so long as @jaswsinc and @raamdev can find a way to do so that doesn't cause new problems, which will put people off using Zen Cache altogether.

[jaswrks]

@dbaritchi writes...

Is there any reason to not add that no-conflict line as well?

Nope. It doesn't hurt anything at all. I agree that the closer to the WordPress way you can get the better, and it's something we could consider carefully when/if we implement this in ZenCache.

However, it just strikes me as seemingly unnecessary. I mean, if you're loading jQuery from a CDN, you're already doing things in a non-WordPress way. So adding the noConflict mode, which is likely not necessary, seems fine to bypass so long as you know about it.

The only issue with noConflict mode has to do with the $ variable. That's what jQuery uses as an easy reference to itself. If you run jQuery and also another framework too, and they both happen to use the same $ (e.g., http://prototypejs.org/), then noConflict is required. Otherwise, it's fine. Ideally, if you are working on micro-optimizations like this, you're not loading more than a single JS framework :-)

[jaswrks]

@KTS915 writes...

As I said, I don't think that's necessarily true. 98% of the time, probably. The other 2%? That's not a given at all. You are overlooking the fact that such a setup requires a connection to Google. That is dependent not just on Google, but on service providers in between. So you've just introduced numerous new points of failure.

That's actually one of the things that WPjQ+ gets wrong, in my view. Unless you add an extra line of code, it's loading things from not one but two different places (Google and a CDN) so is doubling the chance of problems.

I agree on both of those points. There are ups and downs.

• CDN = lower latency across the globe, fewer hits to your site, possible caching to reduce bandwidth for users who visit your site, which improves render time.
• CDN = also equals (as you pointed out) new points of failure, and multiple DNS lookups for a browser. With the forward momentum that HTTP/2 is seeing, this is even more of a concern, because now (in HTTP/2) you want to load everything over a single connection, and introducing a foreign CDN (i.e., another DNS lookup) can actually slow things down in HTTP/2. Most of the micro-optimizations we have all become familiar with are out-the-door whenever your server supports HTTP/2. In fact, they can actually makes things worse.

---

My conclusion: keep everything on your own server (use a CDN, but do a pull zone with your own domain), and then instead of working on these micro-optimizations (that's yesterday), focus on getting your web server upgraded to HTTP2.

See: https://http2.akamai.com/demo ~ for a serious speed increase!

[jaswrks]

@dbaritchi writes...

for the visitor it will be a faster experience regardless because Google Libs / CDNJS (powered by CloudFlare) have edge servers everywhere where the file already lives already close to these first time visitors. so win/win/win. :)

I agree. Definitely. That's a big reason (the only reason that I need) to use a CDN. If you don't run a CDN, then your visitors are losing this important speed boost that only a CDN can provide.

This is something that quick tests will not show you. Geographic response time.

With HTTP/2, it's best to use a CDN like CloudFlare that operates at the DNS level. Or, short of that, use Static CDN Filters in ZenCache to serve your static assets. Most CDNs already support HTTP/2, so not only are you boosting geographic response time (i.e., lowering latency), but you're also upgrading a part of your infrastructure to HTTP/2, even if your own server doesn't support it yet.

With HTTP/2, you just want to watch how many different DNS lookups you require. My tests indicate that it will be slightly faster if you serve jQuery over HTTP/2 and serve it from the same CDN that hosts all of your other static assets.

[dbaritchi]

@jaswsinc been pondering what you said for a day or two... and agreed completely.

Love CloudFlare. We realy heavily on them both for our high traffic content sites, and for our blog hosting service... love CloudFlare. they recently added HTTP/2 and add that to their transparent caching of static assets, it's a great combo.

One problem with our multisite tho... so let's say there are thosands of sites on this domain-based WP multisite. many domain mapped, all domains on CloudFlare.

BUT from what i understand, HTTP/2 is supported in most major browsers, but only over SSL. AND most every website is http. that's not something we can change.

BUT you mention CDN URL replacement... that's great. so what if we used CDN URL replacement network-wide to translate all static assets to our same MaxCDN zone SSL URL. the SSL URL, not the regular one.

Just confirmed with MaxCDN, they're still on SPDY, but they expect to have HTTP/2 rolled out by end of Q1 2016.

Even SPDY tho should be great, right?

Problem for us is... 1.) how can I enable CDN URL replacement to the SSL URL - since in ZenCache URL replacement you put the hostname not the http/https scheme. but doing the SSL URL directly would result in SPDY delivery and then HTTP/2 when enabled, right? should work fine i'd think.

2.) our top level site is an upgraded CloudFlare domain with full optimizations... extensive caching, HTTP/2, etc. so how could we exclude the main top-level domain from the URL replacement?

\ Let me know if you'd prefer i start a new "issue" for this, tho i think it's an evolution of the same convo.

Thanks! Dan

[dbaritchi]

@jaswsinc @raamdev thoughts on the above?

Thanks! Dan

[KTS915]

I had published a new site, just before our exchange above, and decided it would be a good idea to test out the use of a CDN. I tried both the one provided by my host and KeyCDN. I also tried numerous configurations with Zen Cache Pro, and both with and without other plugins that purport to assist (e.g. by using them to minify CSS and/or JS instead of ZCP, or by having them defer JS).

I have now run literally hundreds of tests, using different testing sites, and choosing options that test from all over the globe.

The result? Clearly the best option was to have ZCP do everything (including HTML compression) and not to use a CDN at all.

Unlike many other configurations, this caused no problems with CSS or javascript. But it also made both first page and subsequent loads quicker (at just over a second). (My own perception of the site, on PC/laptop/Android, is that it loads virtually instantly, and I take this as somewhat validating my own experience.) It also made loading times vastly more consistent. Using a CDN introduced significant variations.

The question, then, is why did I get such results when this goes against what so many people advise. Well, I think a lot of it (certainly so far as consistency is concerned) is that it avoids having multiple points of failure.

But I think the other reason is that this site (like all my others) runs exclusively on https. It has been clear to me for some time that using https renders much of what has been written about websites irrelevant or just plain wrong. Indeed, KeyCDN didn't work properly at all because apparently the only way it can cope with https is if you get your SSL certificate through them!

My host is currently testing http/2 on its servers. Once that is activated, I think there'll be even less reason for me to use a CDN.

[jaswrks]

@dbaritchi writes...

BUT from what i understand, HTTP/2 is supported in most major browsers, but only over SSL. AND most every website is http. that's not something we can change.

Yep. Serving everything over SSL is what I would recommended. That's a part of the move to HTTP/2. Google is even going to start scoring sites lower if they are not serving everything over SSL. Referencing: https://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html

So I would suggest trying to move into a direction that serves every page on your site over https://. It sounds like @KTS915 has already done this also. Though it does sound like it could be a bit more challenging for you, since you are hosting multiple sub-sites.

BUT you mention CDN URL replacement... that's great. so what if we used CDN URL replacement network-wide to translate all static assets to our same MaxCDN zone SSL URL. the SSL URL, not the regular one.

Yes, that sounds like a fine idea to me, and ZenCache Static CDN Filters can certainly help you with this. ZenCache supports multisite networks for this feature also, so you should be able to exploit that functionality. See: https://zencache.com/kb-article/static-cdn-filters-for-wordpress-multisite-networks/

Even SPDY tho should be great, right?

It is better, yes. However, see: http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html

1.) how can I enable CDN URL replacement to the SSL URL - since in ZenCache URL replacement you put the hostname not the http/https scheme. but doing the SSL URL directly would result in SPDY delivery and then HTTP/2 when enabled, right? should work fine i'd think.

If you tell ZenCache that your CDN supports and is configured to run SSL, then ZenCache will convert the URLs to a scheme which matches the current request. So they need to match; i.e., the only way to get https:// in the CDN URLs is to serve the page itself over SSL also. That is recommended anyway if you're moving into the direction of HTTP/2 or SPDY.

2.) our top level site is an upgraded CloudFlare domain with full optimizations... extensive caching, HTTP/2, etc. so how could we exclude the main top-level domain from the URL replacement?

You can simply exclude that domain from your multisite configuration for Static CDN Filters. See: https://zencache.com/kb-article/static-cdn-filters-for-wordpress-multisite-networks/#toc-8a1cfcbb

[jaswrks]

@KTS915 writes...

My host is currently testing http/2 on its servers.

Cool! :-)

Once that is activated, I think there'll be even less reason for me to use a CDN.

I see. If most of your visitors are in the U.S. and you prefer to reduce the number of dependencies your site has, I can't argue. You also ran your own tests, and I can certainly respect that choice.

Just keep in mind that a CDN is also about location; i.e., reducing latency in various geographic areas. So aside from HTTP/2 or domain sharding, I see a CDN being valuable for these two primary reasons.

1. Reducing latency for visitors that hit my site from a location that might be much further away from where my server is actually running. For instance, if a visitor hits my site from Australia, a CDN can deliver them my content from Australia, instead of my server doing it from Texas, USA.

   Most of the HTTP connections that a visitor needs to make after the initial HTML file is loaded, are for several static assets. So delivering those from a geographic location that is closer to them reduces latency. That's the primary purpose of a CDN; i.e., a strategic geographic network of servers.

2. It reduces the amount of work that your own server needs to do. It's true that you're adding another point of failure, but most CDNs have huge networks that are far more tolerant than anything that any of us will run independently. By letting them cache and serve your static assets, you are freeing resources on your own server that are needed to serve non-static assets. This is because your server is not spending time serving JS/CSS or images. The CDN handles that.

   So this allows your server to deliver non-static files on your site; i.e., those that do require a connection to your own server, much faster. Also making a high-traffic site slightly more affordable for you; i.e., you don't need as much RAM or CPU if you outsource some responsibility to a CDN.

[KTS915]

@jaswsinc,

Thanks for this. https really make a big difference with Google.

As you surmised, my sites are only directed at people in North America, and the server is in Chicago, so a CDN is likely to offer fewer benefits than if I were interested in attracting readers from elsewhere. (I did run some tests from Australia, though, and found it made no difference. That might, of course, simply mean that there's a gap in coverage with that particular CDN, which is why I would like to have been able to test with KeyCDN too, but I couldn't.)

Now that I have discovered what was using the silly heartbeat API so often, I also have plenty of leeway on the server, so it's not likely to get overworked.

What I have found makes the most difference is using SVGs where possible (and compressing graphics where it isn't) and compressing the fonts. WOFF2 can make a huge difference compared to WOFF or other font types, and it's now supported by almost all important browsers.

Perhaps I should add that I haven't been able to test my membership sites (because, obviously, I can't point the tests to a protected page) so I am just starting a real-life A/B test. This could be different because, as you recently explained to me, using HTML compression for logged-in members is not a good idea.

[dbaritchi]

@jaswsinc lol feeling slow this morning - i'm looking at that help article and NOT seeing how to implement that domain filter you mention. can you please clarify. :)

Thanks!! Dan

[dbaritchi]

@jaswsinc Writes...

2.) our top level site is an upgraded CloudFlare domain with full optimizations... extensive caching, HTTP/2, etc. so how could we exclude the main top-level domain from the URL replacement? You can simply exclude that domain from your multisite configuration for Static CDN Filters. See: https://zencache.com/kb-article/static-cdn-filters-for-wordpress-multisite-networks/#toc-8a1cfcbb

So what I'm hoping to do is exclude only the top-level domain, i.e. my-top-domain.com from the URL replacement - i guess with the Static CDN filters? sounds great.

but the other thousands of sites on the multisite network - be they subdomains (i.e. blog1.my-top-domain.com) or mapped domains (totally-different-domain.com) should all still get the URL replacement. :)

Thanks! Dan

[dbaritchi]

@jaswsinc I'm looking at that help article you mentioned but not seeing how to implement that domain filter you mention. can you please clarify. :)

the goal being to apply the CDN delivery ONLY to all the sub-sites on our network, NOT to the main top -level site.

Thanks!

[jaswrks]

@dbaritchi Configure multiple CDN Host Names as discussed in that article, and simply do not include a mapping for the Main Site, which in this example would be just mysite.com.

---

Note the absense of mysite.com =; i.e., I only map sub-domains.

[dbaritchi]

Oh, ok... problem is we have thousands of sub-sites and adding more daily so would not be able to specify them individually, initially or ongoing.

How can I say "all sites EXCEPT top-level mysite.com"

Also some are just sub-domains like myblog.mysite.com but many are domain-mapped like myblog.com.

Thanks!

[jaswrks]

I see. Well, you could try using a filter for this.

Create: /wp-content/mu-plugins/comet-cache.php

<?php
add_filter('comet_cache_options', function($options) {
    if(is_main_site()) {
        $options['cdn_enable'] = '0';
    }
    return $options;
});

Referencing: https://github.com/websharks/comet-cache-pro/blob/160227/src/includes/closures/Plugin/OptionUtils.php#L22

[dbaritchi]

Thanks @jaswsinc - for some reason i'm having trouble enabling CDN URL Replacement (CDN Static Filters) for our multisite... i turn it on, click Save, when the page refreshes it's off again.

I'll open a separate ticket with details on that. Thanks.

[jaswrks]

click Save, when the page refreshes it's off again.

Hmmm. Interesting. I can't seem to reproduce this myself. Just to confirm, that is Comet Cache Pro you're running, right? Did you try it in a test WordPress installation without anything else as a possible conflict?

[dbaritchi]

@jaswsinc sorry about that - i created the new ticket since the issue seemed off topic but forgot to reference it here.

[raamdev]

Option to Serve jQuery (and other JS libs) from Google Hosted Libraries / CDNJS

I'm not seeing this as something that should be part of Comet Cache, as it would be better suited as a separate plugin.