Category Archives: performance

Autoptimize 2.2 coming your way, care to test?

So work on Autoptimize 2.2 is almost finished and I need your help testing this version before releasing (targeting May, but that depends on you!). The more people I have testing, the faster I might be able to push this thing out and there’s a lot to look forward to;

  • New option: enable/ disable AO for logged in users for all you pagebuilders out there
  • New minification/ caching system, significantly speeding up your site for non-cached pages (previously part of a power-up)
  • Switched to rel=preload + Filamentgroup’s loadCSS for CSS deferring
  • Additional support for HTTP/2 setups (no GUI, you might need to have a look at the API to see/ use all possibilities)
  • Important improvements to the logic of which JS/ CSS can be optimized (getPath function) increasing reliability of the aggregation process
  • Updated to a newer version of the CSS Minification component (albeit not the 3.x one, which seems a tad too fresh and which would require me to drop support for PHP 5.2 which will come but just not yet)
  • API: Lots of extra filters, making AO (even) more flexible.
  • Lots of bugfixes and smaller improvements (see GitHub commit log)

So if you want to help:

  1. Download the zip-file from Github
  2. Overwrite the contents of wp-content/plugins/autoptimize with the contents of autoptimize-master from the zip
  3. Test and if any bug (regression) create an issue in GitHub (if it doesn’t exist already).

Very much looking forward to your feedback!

Autoptimize CSS defer switching to loadCSS (soon)

Historically Autoptimize used its own JS-implementation to defer the loading of the main CSS, hooking into the domContentLoaded event and this has worked fine. I knew about Filament Group’s loadCSS, but saw no urgent reason to implement it as I saw no big advantages vs. my homegrown solution. That changed when criticalcss.com’s Jonas contacted me, pointing out that the best way to load CSS is now using the rel="preload" approach, which as of loadCSS 1.3 is also the way loadCSS works;

<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'">

As rel="preload" currently is only supported by Chrome & Opera (both Blink-based), a JS polyfill is needed for other browsers which uses loadCSS to load the CSS. Hopefully other browsers catch up on rel="preload" because it is a very elegant solution which allows the CSS to load sooner then with the old code while still being non-render blocking. What more could one which for (“Unicorns” my 10yo daughter might say, but what does she know)?

Anyways; I have integrated this new approach in a separate branch on GitHub, you can download the zip-file here to test this and all the other fixes and improvements since 2.1.0. Let me know what you think. Happy preloading!

How to fix CSS media-types impacting Autoptimized CSS order

pixeldima-forum-screenshotAdel of Pixeldima contacted me to look into a problem with some of the styles not being applied after autoptimization on the forum-page in his beautiful OKAB-theme. I had seen similar problems before, but decided to dig in this time to understand the root cause. That root cause turned out to be 2 CSS-files, one overriding the style of the other, having a different media-type, which messed up the load order once autoptimized. This can either be fixed at the theme-level, at AO configuration level or with a couple of lines of code hooking into AO’s API.

The problem

Without Autoptimize (which one can trigger by simply adding ?ao_noptimize=1 to the URL), these 2 relevant files were loaded (among many others obviously):

  • bbpress.css (the default bbpress css-file) was loaded first with media=”screen”
  • okab/bbpress-styles.css (part of the theme) is loaded second with media=”all”, overriding some of the CSS in bbpress.css

Autoptimize honors the media-types, resulting in 2 Autoptimized CSS-files;

  • autoptimize_1a002577cefe349767025a16201f37a9.css with media=”all” is loaded first (because the very first CSS-file encountered in the HTML had media=”all”) which contains okab/bbpress-styles.css
  • autoptimize_8e3c7dac90177214b6583286ddaa141f.css is loaded second with media=”screen”, containing bbpress.css

So due to the mediatype the code in bbpress-styles.css was loaded before the CSS in bbpress.css when Autoptimized, resulting in styles being overwritten the wrong way (bbpress-styles.css is overwritten by bbpress.css instead of the other way around).

The solution(s)

As Adel was the theme developer, he could immediately attack the root issue by enqueuing bbpress-styles.css with media=”screen”. This way both files share the same media-type and go in the same autoptimized CSS-file, resulting in the CSS of bbpress.css getting properly overwritten by the CSS of okab/bbpress-styles.css.

If you’re not the theme developer you’ll probably not want to change the theme’s code (although you could dequeue and re-enqueue in a child-theme’s functions.php), in which case you have two workarounds at your disposal: the easiest workaround being simply excluding the CSS-file that gets overwritten from CSS optimization (i.e. in this case simply adding okab/bbpress-style.css to the list of CSS optimization exclusions). Easy indeed, but on the downside you’ll have one non-optimized CSS-file. That’s why it’s a good thing we have our precious little API, allowing us to override the media-type of the offending file with just a couple of lines of code, like this;

add_filter('autoptimize_filter_css_tagmedia','check_mediatype',10,2);
function check_mediatype($media,$tag) {
  if ( strpos($tag,"okab/bbpress-styles.css") !== false ) {
	$media=array("screen");
  }
  return $media;
}

Conclusion

As Autoptimize honors the original CSS’s media-types, 2 CSS-files that ought to be loaded in a specific order might end up being loaded in the wrong order if their media-type is different. This can be fixed in the theme or worked around by excluding a specific CSS-file or using AO’s API to override the media-type for the offending CSS-file.

Saying goodbye to 2012.FFWD

Earlier today I updated my performance-centric TwentyTwelve child theme to fix a problem with the mobile navigation (due to the fact that TwentyTwelve changed the menu-button from a h3 to a button, which required the navigation JS which 2012.FFWD inlines to be updated as well). You can download the update here.

This update “officially” marks the end-of-life of this child-theme. Although a lot of optimizations can be done on a theme-level, I prefer focusing on tools like my own Autoptimize, which not only optimize code spit out by the theme but also any CSS/ JS introduced by plugins or widgets.

Quick KeyCDN’s Cache Enabler test

cache enablerCache Enabler – WordPress Cache is a new page caching kid on the WordPress plugin block by the Switzerland-based KeyCDN. It’s based in part on Cachify (which has a strong user-base in Germany) but seems less complex/ flexible. What makes it unique though, is it that it allows one to serve pages with WEBP images (which are not supported by Safari, MS IE/ Edge or Firefox) instead of JPEG’s to browsers that support WEBP. To be able to do that, you’ll need to also install Optimus, an image optimization plugin that plugs into a freemium service by KeyCDN (you’ll need a premium account to convert to WEBP though).

I did some tests with Cache Enabler and it works great together with Autoptimize out of the box, especially after the latest release (1.1.0) which also hooks into AO’s autoptimize_action_cachepurged action to clear Cache Enabler’s cache if AO’s get purged (to avoid having pages in cache the refer to deleted autoptimized CSS/ JS-files).

Just not sure I agree with this text on the plugin’s settings page;

Avoid […] concatenation of your assets to benefit from parallelism of HTTP/2.

because based on previous tests by smarter people than me concatenation of assets can still make (a lot of) sense, even when on HTTP/2 :-)

Is the web doomed?

Off course the web is not doomed, but despite the fact that web performance is immensely important (think impact on mobile experience, think impact on search engine ranking, think impact on conversion) the web keeps getting fatter, as witnessed by this graph from mobiforge;

web-page-size-revisited-revised

Yup; your average web page now has the same size as the Doom installer. From the original mobiforge article;

Recall that Doom is a multi-level first person shooter that ships with an advanced 3D rendering engine and multiple levels, each comprised of maps, sprites and sound effects. By comparison, 2016’s web struggles to deliver a page of web content in the same size. If that doesn’t give you pause you’re missing something.

There’s some interesting follow-up remarks & hopeful conclusions in the original article, but still, over 2 Megabyte for a web page? Seriously? Think about what that does that do to your bounce-rate, esp. knowing that Google Analytics systematically underestimates bounce rate on slow pages because people leave before even being seen by your favorite webstats solution?

So, you might want to reconsider if you really should:

  • push high resolution images to all visitors because your CMO says so (“this hero image does not look nice on my iPad”)
  • push custom webfonts just because corporate communications say so (“our corporate identity requires the use of these fonts”)
  • use angular.js (or react.js or any other JS client-side framework for that matter) because the CTO says so (“We need MVC and the modularity and testibility are great for developers”)

Because on the web faster is always better and being slower will always cost you in the end, even if you might not (want to) know.