[wp-hackers] Adding A CSS Loader

Jamie Holly hovercrafter at earthlink.net
Tue Apr 24 14:05:30 GMT 2007


> the current javascript loader is a better model; CSS files can also
> depend on each other (the loading order is important).
> 
> Combining the files, while it doesn't lower the server load*, it can
> reduce load times a lot; if you have Firebug installed, load a page
> that
> has several CSS and Javascript files and go to the net tab to see what
> I
> mean: the stuff in the <head> section of the page is not multi-
> threaded,
> they are loaded in sequence, and nothing else is loaded before the
> <head> is done; lots of CSS and JS files to load means lots of HTTP
> requests, and while pipelining in the browser can help reduce the
> delays, you still get a lot of communication overhead.

Every request to a server is an increased load. It's not a huge amount, but it increases the load none the less. 

I also understand the CSS load order, but this suggestion would not change that. The add_css would basically follow the same syntax as the current add_action routine. We would keep a priority on it to address the CSS load order, with the main theme CSS loading first. The only difference is all the CSS would be contained within 1 file, as opposed to a bunch of files. 

> 
> yeah, as long as the themes run wp_head after they load their stuff; it
> wouldn't hurt to strongly advise theme (and plugin) authors to use the
> provided loaders in the future (perhaps release them as a (default)
> plugin for 2.0.x), since it would make life a lot easier for plugin
> authors (some themes load prototype/jQuery/mootools/whatever, a plugin
> shouldn't load the corresponding library a second time; plugin CSS is
> usually better loaded after the theme CSS, but there may be exceptions,
> etc).

The exact same scenario applies as everything is today. The "master" CSS file would be added at the same point the current CSS files are loaded via the wp_head call. 


> my .02€
> 
> * as someone noted, you have a script call + a bunch of filesystem
> hits;
> caching would reduce the filesystem accesses to two, but you still have
> the script execution overhead

The script execution would be minimum. This proposal would create a static CSS file whenever the CSS has changed (plugin additions/updates, them update, or perhaps every X hours just to be sure everything is up to date). We could even (and probably should) add a check every X number of hits/minute(hours) that compares the filemtime for each CSS to the master and if a CSS has been modified since then, a new one is created. The overall factor is the output - which would be a single static file.

We could go a similar route as wp_cache and create user dependent CSS files. One master css for anonymous users, and then css_(md5 hash of user name).css for each logged in user (in the case of some plugins that might have different CSS rules for different users). That would prevent problems of certain CSS loading for certain users. True if that is the case, the plugin authors would still have the means to bypass the new loading method by still calling utilizing the current method of the wp_head action. 

Jamie Holly
http://www.intoxination.net



More information about the wp-hackers mailing list