An Alternative to @import in WordPress Child Themes

Using Child Themes in WordPress is a great way to modify an existing theme, however the CSS @import directive is slower than it has to be, so you should try and avoid it. Here’s why.

If it takes 200ms to load the child theme’s stylesheet, and 200ms to load the parent theme’s CSS, a modern web browser should take approximately 200ms to load both of them, because modern browsers load assets in parallel.

Unfortunately this is not true for CSS @import. Let me quote Google:

The browser must download, parse, and execute first.css before it is able to discover that it needs to download second.css.

Which means that instead of 200ms, with @import it’ll take the web browser approximately 400ms to load both stylesheets. Here’s a typical child theme’s CSS:

/**
 * Theme Name: My Child Theme
 * Template: parent-theme
 */
@import url(../parent-theme/style.css);

/* My Child Theme CSS */

We can drop the @import statement, and make good use of functions.php and the wp_enqueue_style() function:

// Faster than @import
add_action( 'wp_enqueue_scripts', 'my_child_theme_scripts' );
function my_child_theme_scripts() {
    wp_enqueue_style( 'parent-theme-css', get_template_directory_uri() . '/style.css' );
}

And we don’t need to re-declare dependencies because the child theme’s functions.php is loaded before the parent theme’s. Unless, of course, the parent theme uses a different action priority, in which case we should just match it.

That’s +1 to our PageSpeed score :)

WordCamp Russia 2014

The second WordCamp in Russia was a success, with almost 200 attendees and a great lineup of 14 speakers from all over Russia and abroad, including Ukraine and even Germany.

WordCamp Russia 2014

I’m not going to go into much planning details like I did last year. Everything was mostly the same, with the exception of having almost twice as many speakers, two tracks, pizza for lunch, a new logo (which everybody thought was a splash), as well as little irritating things that made planning more stressful — like the absence of parking spots close to the venue, problems with shipping anything from the US to Russia, and the fact that we bought about 10x more coffee than we ended up serving.

In any case, the post-WordCamp survey showed a 96% satisfaction rate, which definitely works for me. Now back to reading those new 4.0 commits, and still struggling for inbox zero, even though it’s been over a week now.

Photos from WordCamp Russia 2014 are on Facebook. Slides from my talk about scaling WordPress can be found here, the videos from all the sessions should appear on WordPress.tv in a few weeks.

Introducing Semicolon

Semicolon is a brand new magazine theme for WordPress. It’s simple, clean, and it’s got quite a unique grid layout with support for featured posts.

Semicolon WordPress Theme

Semicolon was initially created for WP Magazine, an online news site about WordPress in Russian. It’s got support for featured posts, a social profiles menu, related posts, author bios, and a few widget areas.

Head over to the demo to take a look around. The latest version is always available for download on WordPress.org (don’t forget to rate it!), and if you ever get stuck, please visit the the FAQ and the support forums.

Semicolon is based on the amazing _s starter theme, and is distributed for free under the GNU GPL. Enjoy!

Idea: Static Templates for WordPress

I was helping out a friend a few days with their fairly complicated WordPress website. Complicated because it had over 40 different page templates, rendered exclusively by PHP.

Each page template had something special about it, like a form and form handler, a JavaScript calculator, a list of registered users, the current user profile and more. Page Templates worked pretty well, and the other “simple” options were shortcodes (bleh!) or page-{slug}.php templates.

Anyway, when this friend of mine was porting the site over from his development environment to production, he had to recreate those 40 pages, make sure their slugs matched, and assign the appropriate page template from that drop-down list of over 40 times. What a nightmare!

Static Templates

I thought there should be an easier way. One that would work similar to page templates, but without that extra database overhead, without the UI and everything else. Obviously this would render a WordPress theme completely useless outside of the original context, but so do 40 page templates.

I drafted up a plugin, a proof of concept, and called it Static Templates. The idea is for a theme to have a static-templates folder, with .php templates named after certain slugs. For example:

/about/           => /themes/foo/static-templates/about.php
/about/contacts/  => /themes/foo/static-templates/about-contacts.php
/foo/bar/baz/     => /themes/foo/static-templates/foo-bar-baz.php

So when /about/ is requested, you don’t need to worry about creating a page in WordPress, creating a new template and assigning it to your page. All you have to worry about is your /static-templates/about.php file.

Obviously if a page with that slug exists in the WordPress database, it’ll be loaded instead, so static templates have a lower priority, and there’s still that little overhead of trying to fetch a non-existent page from the database before a static template is invoked. It also does not (yet) distinguish between /foo/bar/ and /foo-bar/ requests.

Anyway, as I mentioned this is just an idea, and I would absolutely love to hear your thoughts about it.

Debug Bar Slow Actions

If a typical WordPress page load takes more than one second, chances are there’s something terribly wrong with your site, a theme or a plugin is probably doing something it shouldn’t. Obviously you don’t have time to review every single line in your codebase, so Debug Bar Slow Actions might help you out.

Debug Bar Slow Actions is an extension for the popular Debug Bar plugin. It adds a new panel with a list of the top 100 slowest actions (and filters) during the current page request.

Debug Bar Slow Actions

It’s fairly lightweight (as opposed to xdebug and other profiling tools), but I wouldn’t recommend running it on a production environment, or at least not for long. It does hook to each and every action and filter (twice!) to time it, though timing is pretty fast and it’s highly unlikely that it’ll ever become a performance bottleneck.

After you’ve found out which action is the slowest, you can easily lookup the callback functions hooked to that action, perhaps using tools like Query Monitor, or a simple var_dump:

add_action( 'init', 'whats_at_init', 9999 );
function whats_at_init() {
	var_dump( $GLOBALS['wp_filter']['init'] );
}

Update: version 0.8.1 and above will show you the number of callbacks hooked to each action, and it’s also possible to expand the callbacks list.

You can get Debug Bar Slow Actions from WordPress.org or GitHub.

Happy profiling!