Dynamic CSS / JavaScript files are evil – 8 reasons
In the prvious posts we stated that dynamic images are bad and how images (from timthumb) can be statified. Let’s speak today about dynamic CSS / JavaScript files and see what can be done here.
What is dynamic CSS / JavaScript files?
All style sheets and JavaScript calls which has extension not .css or .js (but .php). As an example you an take a look at gdsr.css.php file (which is a part of GD Star Rating plugin) – this one is beter than a common example because it allows client side caching.
So all PHP-based CSS / JavaScript files are dynamic and thus evil. Let’s see why.
Reason 1. PHP execution is expensive
Each ms is valualbe for your website. And dynamic file’ generation costs about 2-3x more expensive that plain (=static) files. This is not very important in comparison to WordPress (or any other CMS) execution time to generate HTML document. But while using strong caching techniques (and creating high performance websites) such costs become valuable.
Reason 2. PHP files are not cached
Usually (note: sometimes it’s not true) dynamic PHP files don’t set proper client side caching headers (both far future and conditional ones). This is very bad because with every page request takes additional time from server to generate this file and additional time from client browser to load it. There is double drawback here.
Reason 3. PHP files has GET parameters
The main reason why sometimes PHP scripts are used to serve CSS or JavaScript content is a feedom to server different content for different initial (GET) parameters. This is very convenient for developers but is not so good for client side performance – because some proxy servers don’t cache files with GET parameters in URL (because they can be dynamic), and this leads to slower website load.
Reason 4. PHP scripts are buggy
Classical example here is Featured Content Gallery which sends CSS files with wrong Content-Type (under certaion conditions). This breaks layout is modern browsers.
Static files (especially on VDS / shared hostings) serving is being tested for years. And all related issues (i.e. Content-Type) were closed long time ago.
Reason 5. PHP scripts are not gzipped
It’s very easy to add gzip to static files (i.e. with static gzip). But if you are going to gzip every dynamic PHP script – you need to alter it manually. And do it with every plugin update (or ask repeatedly authors to add fix for gzip).
Gzip for CSS / JavaScript files can save about 80%, so it’s a huge drawback.
Reason 6. PHP scripts are hardly combined
THe most famous tool – WP-Minify – to combine static CSS / JavaScript files fails on dynamic (PHP) ones. Because they must be executed first and only then merged with the rest content. So there must be applied more advanced merging techniques or you will have to disable textual files merging at all.
Reason 7. PHP files are not minified
Yes, there can be any type of minify applied to the content of PHP files. But it’s implemented very rarely (and almost never right). For example there is no place for comments (client side) in such dynamic files – all they can be left in PHP code.
Reason 8. Inline code isn’t included
It’s a very simple idea – as far as we have dynamic file why do we need to include any piece of additional code into HTML document? We can serve all related chunks of data inside the only dynamic file (due to PHP flexibility) – but actually each plugin includes 2-3 files + a few chunks of data.
There can be some more arguments why developers must think more about performance. And prefer static files (or pre-generated ones) instead of dynamic PHP scripts to serve CSS / JavaScript content. But let’s see how can we fixe this.
Solutions
There can be the only ‘true’ way to avoid such dynamic scripts on your website – just merge them together (or convert) into static files. This is quite painfully but with automated solutions can be like a dream. After this you can simply apply gzip or client side caching.
We reviewed some WordPress plugins to merge scripts and here is the only clear winner – WEBO Site SpeedUp (you can check also performance comparison table). So there are only two ways: to perform all actions manually (to improve your website performance) or prefer an automatic solution. It seems there is no chance to stop using plugins with such dynamic content (or force all authors to use performance optimization best practices).
Conclusion
PHP scripts (for CSS / JavaScript content) have many negative features. So you need to use them or… to fix them manually or automatically.
Lots of this is cool, except #5 – compression has been built into PHP since … well, a long time.
Check out this article I wrote a long time ago about doing just that:
http://newestindustry.org/2006/10/03/compressing-php-output/
smp
@Stephen: compression is cool but must be done with Apache / nginx / LightSpeed / etc ‘on fly’ instead of patching PHP (zlib isn’t supported on all environments).
Why PHP files are not gzipped? Usually the PHP script produces a HTML output in most of the cases, here the case is different and it may produce JavaScript or CSS, but whatever the output is with correct headers it’s still a text. Why than they are not gzipped? I don’t agree!
@stoimen: because PHP is dynamic. There a lot of troubles with gzipping dynamic content (there are links in the articles about it), and in the most of cases we need to fix each PHP script to make its output gzipped. It’s awful.