Split jQuery off the rest of the javascript #1769

wants to merge 5 commits into


None yet

6 participants


See #1766 for the rationale to do so. A bunch of arguments can also be found in 61537d4

Things to discuss:

  • what should the default of the CDN option be. I would argue to enable it by default. Objections?
  • currently the code.jquery.com CDN is hardcoded. Would adding other CDNs (eg. google) be beneficial?
  • I only split off the JS part. JQuery UI also has some CSS and sprites, however I'm not sure if their size would be worth the effort/additional http requests. The same is true for jquery-cookie

Note: this is implemented on top of #1768

added some commits Nov 26, 2016
@splitbrain use external version file for jquery updates
this also removes the non inified versions and incorporates some updates
the jquery CDN just pushed for jquery-ui
@splitbrain split off jquery from other JS and add CDN option #1766
jQuery (and UI and Migrate) are now loaded separately from the rest of
the JavaScript. This adds at least one HTTP request more but has some

* browsers can cache it independently
* the cache is only invalidated when versions update
* we do not apply any transformations (replacements, minimizing, etc) on
  this code anymore which makes our dispatcher faster for the other JS
* browsers seem to load (not execut) both (jquery and other) parallel,
  which might increase download speed a bit

This split allowed for the introduction of a new config: jquerycdn. When
enabled the 3 jquery files are loaded from jQueries CDN. This adds
another two HTTP requests but:

* since it's another host those files do not apply to the 4 request per
  host limit and can be loaded (not executed) in paralell which might
  increase download speeds a bit
* the CDN is distributed worldwide which means files are requested from
  the closest location, increasing the download speeds
* since these files/CDN are very popular, chances are high that people
  already have them cached in their browsers, reducing the download time
  to 0 and effectiely halving the javascript needed to download

The option currently defaults to 'off', but I would argue 'on' would be
the better default.
@splitbrain load jquery via https always
Celti commented Nov 26, 2016

I highly recommend adding other CDNs; would it be terribly difficult to simply add the list of CDNs tested by CDNperf? I think that trusting their list might be the best way to avoid arguments about prejudice and NIH.

Another option would be to simply provide a CDN URL configuration, where people simply enter whichever CDN they prefer.

polyzen commented Nov 27, 2016



Thanks for the feedback. Some thoughts:

  • while speed is good to have for a CDN, popularity is also important. the more popular a CDN is the more probable it is that users will not need to download anything because they already have the library in their browser cache
  • some CDNs are slow to update the libraries they host. when ever we decide to upgrade to the newest release of jQuery we need to make sure it's available at the CDNs used. code.jquery.com is always up to date by definition
  • we have three URLs that not necessarily follow the same schema (at least true for code.jquery.com) so if we would want to make it configurable, we would need to have three config values

So if we go for multiple CDNs I would like to keep the number small and maybe have two or three popular CDNs only.

Celti commented Dec 18, 2016

The URLs not following the schema could be handled by simply allowing users to input a URL pointing directly at the necessary file(s) on the CDN. If code.jquery.com was used as the default, that would satisfy conditions both for defaults and for allowing the user the necessary control if, e.g., dokuwiki is being used on an intranet and there is a local server being used to host shared units like jQuery ­— or dokuwiki is being used as part of a related array of sites that already use a single CDN for other content (my particular use-case).

This might make upgrades that bump the jQuery version questionable, but I imagine the dokuwiki upgrade extension could be made to bump code.jquery.com URLs, and a message about jQuery being out-of-date for alternative CDN urls could use the same mechanism as the ones for dokuwiki being out of date.

gamma commented Dec 19, 2016

I think that it is great to split up the javascript especially for the jQuery stuff. Still, I wonder why it is not generalised more. Sure, the implementation of the jQuery delivery is straight forward with minimal code effort. Anyway: I'd suggest a more generic way to define bits and pieces of the Javascript to be delivered in separate requests. You would not need another *.php in inc, could trigger stuff via plugins or have templates decide when to deliver what.

I do think of at least two scenarios that could be implemented:

  • admin js only for admins / edit js only for editors (e.g. media manager - read-only users do not need it)
  • plugin JS that is specific to a page and quite huge could be stripped from the general JS request

There sure are more use cases here ...


I did some research on CDN popularity: https://www.splitbrain.org/blog/2016-12/21-javascript_cdn_by_the_numbers

@splitbrain allow selecting the preferred CDN and add event
We now have two CDNs available. code.jquery.com which is the more
popular one and CDNjs which is the faster one. Plugin authors can use a
plugin hook to easily implement their own preferred CDN. Authors might
even use this event to conditionally load additional JavaScript files.

I updated the code.

  • users now can pick between jQuery (popular) and CDNjs (fast)
  • plugin authors can use an event to change the used CDN or even add their own additional JS sources
  • we can't use Google (most popular) because it doesn't have jquery-migrate
  • we can't use jsdelivr (they would give us multiple libs in a single request) because their libs are outdated

One question remains: should we enable a CDN by default? And which one?

I think I would prefer to enable it by default, because it increases the chance people have the right libs cached from visiting another DokuWiki before. In that case, code.jquery.com is probably the right choice.

mprins commented Dec 21, 2016 edited

One question remains: should we enable a CDN by default?

I would prefer not changing current (off-the-grid, portable) behaviour and by default use the files of the installed version

gamma commented Dec 21, 2016

Could/should the bis set at installation time?

@michitux michitux Restore smoothness.css using update.sh
The file had 0 bytes before (starting from
5928c8e) - probably something went
wrong while executing update.sh.
@splitbrain splitbrain modified the milestone: Frusterick Manners Jan 18, 2017

@gamma I wouldn't want to put this into the installation dialog. The installer should be simple and not overwhelm people with options.

I also think many people installing DokuWiki will not know what this option does and will never change it from the default.

@mprins portability and offline capability is a good point actually. running a local DokuWiki on a laptop that's disconnected from the internet from time to time is actually a reasonable usecase. So I think keeping the local version as default is sensible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment