Optimizing Performance

It's pretty much a given that website performance is critical, which is why eCSStender does everything it can to minimize its memory footprint and maximize its code efficiency. And it's getting better all the time.

Unfortunately, eCSStender is currently forced to rely on XHR in order to retrieve accurate CSS information (most browsers don't expose properties and selectors they don't understand via traditional DOM methods), so that's a performance hit we have to deal with (at least for now). Thankfully, however, there are a myriad other ways in which eCSStender optimizes its own performance and allows you to further optimize the performance of it on your site. The following is a brief run-down. If you have ideas for other ways we can optimize eCSStender, please drop a note on the mailing list.

Smart Caching

In an effort to speed things up, eCSStender makes use of whatever browser-based caching mechanisms available to it. In most modern browsers, this means window.localStorage, but eCSStender also supports IE's proprietary UserData cache. eCSStender caches information about the stylesheets it encountered, which extensions ran against those stylesheets, and what results it received from calls to eCSStender.isSupported() in order to to hit the ground running when the page loads.

Currently, the cache is private to eCSStender, but if developers express an interest in being able to read and write to the cache from within extensions, we may expose that functionality as well.

Notes:

  1. You can disable browser caching using eCSStender.disableCache().
  2. When operating on a local file, eCSStender's caching is turned off.

Ignorance is Bliss

eCSStender offers a mechanism for ignoring specific CSS files: eCSStender.ignore(). You simply supply a string with the file name (or an array of strings) and eCSStender does the rest. You don't even need to give it a full path, the filename itself is enough. eCSStender also follows the same origin policy and does not read in CSS linked to on a different domain, meaning you don't need to include those CSS files in your ignore list.

isSupported() is Optimized

As a critical piece of the extension-authors toolbox, eCSStender.isSupported() gets called frequently, and often with the same arguments. To speed things up, eCSStender keeps a log of the results of these queries and returns the stored result if its available instead of running the test again. As mentioned previously, this information is also cached in the browser, meaning tests will only be run once per session (or longer, depending on the implementation) if the browser supports caching.

Delayed Writing

Often, extensions will want to inject CSS into the head of the document using eCSStender.embedCSS(). In order to minimize reflows and repaints, eCSStender will write all CSS to the head of the document at once (rather than piecemeal). Individual extension authors have the ability to override the default behavior when calling this method, but are discouraged from doing so.

“Lazy” Functions

In a further effort to optimize the core of eCSStender, any functions that branch based on browser capabilities make use of the lazy function definition pattern. That means the branching only happens on the first call, at which point the function is re-defined so that it is optimized for the environment.

Optimization Ends at Extensions

We work very diligently to optimize the eCSStender core, but even with an optimized core, a slow extension can bog everything down. If you are seeing a performance issue, try turning off individual extensions, you may find the culprit there.