1

I have always felt the way styles are handled in WordPress is not optimal regarding the web performance optimization (WPO) techniques that are related to css.

From a theme developer point of view, one cannot rely on the users installing and configuring a plugin that combines and minifies the css, so keeping an eye in performance is always desirable.

Let's forget about minification and other optimizations, such as avoiding the load of chunks of code not being used or duplicating selectors. I have been wondering about the best approach to serve a theme's css that satisfies the following assumptions:

  1. The theme serves only one css file with the static and dynamic styles in it.
  2. CSS is not inlined anywhere in the theme, so no calls to wp_add_inline_style are possible.
  3. The styles are easy to maintain.

Which approach is preferable and why? In the case a css file is created during the process, which measures should be taken to deal with that resource intensive generation process? I believe that, instead of doing it every time WordPress is loaded, this can be addressed by regenerating the css file only under certain circumstances. These came to my mind:

  • Theme activation.
  • Changes in the customizer (or wherever the styling options are set).

Are there some other circumstances where flushing the css content is desirable?


I have tried several ways so far:

APPROACH 1

Load a style.php in the head with

wp_register_style( 'my-theme-styles', 'style-generator.php' );
wp_enqueue_style( 'my-theme-styles' );

and then, in the php file, parse the css like this

header("Content-type: text/css");
//The styles themselves

Thoughts:

  • Writing styles in php is... ugly.
  • It's difficult to split the css generation in several php files for maintenance purposes.
  • Browser and server support for this approach is not complete.
  • Styles are generated every time WordPress is loaded unless transients are in use, adding further complexity.
  • I like that no file is written to the server.

APPROACH 2

In a similar way to the previous approach, generate all the css code from a php function but, instead of directly loading the php file, output its content with file_put_contents( 'styles.css' ); which is later loaded with wp_enqueue_style.

Thoughts:

  • Writing styles in php keeps being cumbersome.
  • It's difficult to split the css generation in several php files for maintenance purposes.
  • Writing a file to the theme's folder can create problems with the way some installations are handled regarding folder permissions. Writing it to the uploads folder doesn't seems to be very elegant.

APPROACH 3

Integrate all the styles within the theme in a css preprocessor language and simply pass the dynamic styles to the generator as variables. Then all the css code is merged and written automatically into a single file. I won't post the code of this part since it's quite extense but I have it working too.

Thoughts:

  • It works great: css preprocessors are very convenient, allow the use of file include calls and keep code readable, so it's very easy to maintain the styles.
  • The solution depends on third party libraries which might have errors or become abandonware.
  • It seems a little bit over-engineered to me.
  • Writing a file to the theme's folder can create problems with the way some installations are handled regarding folder permissions. Writing it to the uploads folder doesn't seems to be very elegant.
  • I think your assumptions are quite wrong, which makes the question very difficult to answer without going to a endless discussion. In my opinion, from a web performance optimization point of view, a theme that needs to dinamically generate a very large piece of CSS is bad. So, I assume that a good theme needs to dinamically generate just a few lines of CSS: wellcome to wp_add_inline_style. Integrating a little dynamic CSS in a file is almost worthless. – cybmeta May 4 '16 at 12:05
  • @cybmeta, thanks for the feedback! I understand what and why you say that. For a theme that lets you choose the header's color and the typography, building a whole system like this just seems an overkill. I agree 100%. But suppose the theme lets the user choose between four header layouts and not to have a topbar. Will it be better to also load the css and the assets of the ones not in use? Or to serve the css in 20 http requests? Now that search engines are quite sensitive to loading speed, optimizing things like the speed index or static resources management might be important sometimes. – Luis Sanz May 4 '16 at 12:40
  • In all seriousness, I wouldn't worry about ~20 separate CSS files. Our whole concept of performance is about to change with HTTP/2 – TheDeadMedic May 6 '16 at 8:29
  • @TheDeadMedic, thanks for your thoughts! I wouldn't too... if most hostings support HTTP/2. It's not so widely adopted by now, at least in shared hostings which is where most WP installations lay. It's obviously the trend right now but still is not the standard. All in all, exciting times are coming for WordPress regarding performance, with HTTP/2 and the probable adoption of Calypso (node.js) and a more restful way of doing things in a near future. – Luis Sanz May 6 '16 at 9:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.