Monthly Archives: December 2015

Thom Yorke playing new Radiohead songs in Paris

Thom Yorke played a solo-gig (well, Flea joined, so not entirely solo, but still) in the context of the climate-conference in Paris. He didn’t play the could-have-been Spectre title-song, but instead 3 other new songs were on the playlist, along with older material from both Radiohead and Atoms for Peace;

Thom Yorke live en Paris (Full) 4 de Diciembre, 2015

Watch this video on YouTube.

Have a blast guys & girls!

HTTP/2 & JS/CSS optimization: eBay’s approach

Quick follow-up to my previous post about HTTP/2 and Autoptimize; I just read an “Packaging for Performance”, an interesting article on Performance Calendar by eBay’s Senthil Padmanabhan. Well worth the read, but the summary; their research confirms bundling of JS/CSS still has clear performance benefits, but they did stop bluntly aggregating all in one file to improve cache-ability. This leaves them with;

  • one optimized JS and one optimized CSS file for the core libraries, used throughout eBay, high cache-ratio & payload
  • one optimized JS and one optimized CSS file for the “domain constants”, used on specific eBay segments, medium cache-ratio & payload
  • one optimized JS and one optimized CSS file for the “domain variables” containing fast changing code for specific segments, having lowest cache-ratio and payload

So yeah, I see a bright future for Autoptimization in the coming age of HTTP/2! :–)

Making Autoptimize faster

One of the big changes in Autoptimize 2.0 (estimated released between Christmas & New Year) is a significant improvement in the minification speed (30% faster should be no exception). As a quick reminder, this is what Autoptimize did until now;

  1. extract code from HTML & remove original references
  2. aggregate all code into one string
  3. check if a minified version of that string exists in cache
  4. if not in cache;
    1. minify that string
    2. store the result in cache
  5. inject reference to cached autoptimized code in HTML

It is the actual minification in step (4) which can slow Autoptimize down (hence the importance of making sure your cached files are reusable). In Autoptimize 2.0 above logic was changed to improve performance;

  1. extract code from HTML & remove original references
  2. aggregate all unminified code into one string, but only put a reference to already minified files (*min.css and *min.js)
  3. check if a minified version of that string exists in cache
  4. if not in cache;
    1. minify that string
    2. replace references to minified files with (slightly optimized) contents
    3. store the result in cache
  5. inject reference to cached autoptimized code in HTML

As the to-be-minified string is smaller, the JS- & CSS-minifiers have less code to optimize, indeed speeding up the process significantly. Additionally this also reduces the chances of problems with the re-minification of already minified code (e.g. p. So nothing but advantages, right?

Now this was tested rather thoroughly and all known kinks have been ironed out, but If this “injected minified code late”-approach does not work in your context, you can simply disable it by hooking into the API and setting the autoptimize_filter_js_inject_min_late and/ or autoptimize_filter_css_inject_min_late filters to false (use code snippets rather then adding it to your functions.php);

add_filter('autoptimize_filter_js_inject_min_late','no_late_inject');
add_filter('autoptimize_filter_css_inject_min_late','no_late_inject');
function no_late_inject() {
	return false;
}

HTTP/2, CSS/JS concatenation and Autoptimize

The web performance world is abuzz with HTTP/2, which should (among other improvements) do away with the latency that each separate HTTP-request introduces, thus rendering aggregation of e.g. CSS & JS an anti-pattern. But there’s at least one in depth facts and figures based article that is not ready to dismiss “packaging” just yet. So: testing, testing, testing!

Autoptimize will in the not too distant future very likely have a “don’t aggregate, just minimize”-option, but the proof of the pudding will always be in the eating testing; sometimes it will be better to aggregate and minify as we do now, sometimes only minifying will be the better approach. And maybe (often?) a combination of those will make most sense: suppose you have a site on which 90% of pages share 90% of JS code. In that case it will likely (testing, testing, testing!) help performance to aggregate & minify the 90% of JS while excluding all other JS from aggregation (and minifying that). Sounds like the new whitelist-filters in Autoptimize’s API will come in handy no? ;-)

Firefox OS dead or just resting?

So Peter-Paul Koch (Quirksmode) declares Firefox OS dead. I’m afraid he’s right. A pity really, as I loved the idea of an entirely open web-based mobile OS. Mozillians don’t agree, saying they’re just not going offer Firefox OS phones through carriers any more.

Or maybe It’s just resting?

Customer: I wish to complain about this here fox what I purchased not half an hour ago from this very boutique.
Shopkeeper: Oh yes, uh, Firefox OS …What’s,uh…What’s wrong with it?
Customer: I’ll tell you what’s wrong with it, my lad. It’s dead, that’s what’s wrong with it!
Shopkeeper: No, no, ‘e’s uh,…it’s resting.
Customer: Look, matey, I know a dead fox when I see one, and I’m looking at one right now.
Shopkeeper: No no it’s not dead, it’s restin’! Remarkable software, Firefox OS, idn’it, ay? Beautiful openness!