[Note: there’s a new theme and other performance-related changes since this was written. A lot here is still relevant but you might also have a look here.]
A while back I noticed this site had cratered from a once-perfect Page Speed Insights score to an embarrassing 59. It took a few hours of work but I got it up to a score of 91 — more importantly, because that’s just a number, I’ve improved the actual page speed as much as I can. The things bogging me down now, and they’re not bogging very much, are out of my control unless I want to stop using Google Analytics or Jetpack for WordPress, both of which are worth a few additional milliseconds of load speed.
The only other issue is server response time. This site is hosted on GoDaddy, so what can I say — it is what it is.
Here’s more-or-less what I did and the plugins that helped:
WP Super Cache and EWWW Image Optimizer don’t require configuration and can just be installed and activated and your performance will improve. The other two can break a site — you should know what you’re doing and be prepared for some effort. Back up your site before trying them.
Everybody knows by now that a website’s speed matters a lot. (In case you don’t, read this: Case study: Mobile pages that are 1 second faster experience up to 27% increase in conversion rate.) Google stays in front of the effort to speed things up, motivating site owners by making page load speed a factor in their search ranking algorithm, most importantly, but also by providing tools and tips for developers, like Page Speed Insights and “mobile friendly” testing — not to mention the performance tools in Chrome’s excellent developer tools.
Accelerated Mobile Pages is one of Google’s newest performance-related initiatives (from early October 2015, here’s the launch announcement), promising a systematic rather than a piecemeal improvement in performance by defining and enforcing a rigid structure for the content with constrained embellishment. The open-source initiative is loose in the wild (here and here), though uncommon. and pages built accordingly are expected to show up on Google SERPs in early 2016. Sitepoint has a good overview of the initiative.
Not surprisingly, because they were one of the initial partners in the initiative, Automattic (the guys behind WordPress.com) has already released a first-cut plugin enabling a WordPress site to produce AMP pages. Called “AMP” (on GitHub) simply enough, it lacks options and features but does take care of business, and is far-enough along and well-enough written that a decent developer can start using it now. It’s implemented on this site — you can view this post in AMP format by visiting http://www.steveclason.com/accelerated-mobile-pages-and-wordpress/amp/ [opens in a new tab]. That’s the default look — I haven’t done a thing, though the plugin has plenty of filters to allow some personal expression. Like the RICG responsive image engine, I expect this will roll into the WordPress core before long.
My guess is that this will get a lot of attention once AMP pages start showing up in Google SERPS. Content providers should think about stealing a march on the competition and implementing this soon. It will mostly benefit content providers and won’t affect SEO — or shouldn’t, in theory.
A while back, last year maybe but it looks like I deleted the post, I spent a considerable amount of time making this site reach perfection (two 100s) on Google’s Page Speed Insights tool. Here’s what it looks like today (18 Oct 2015):
So, what happened?
I changed my caching plugin from “W3 Total Cache” to “WP Super Cache” but it’s hard to believe that would cause much problem. I also installed a plugin to support Accelerated Mobile Pages (which so far seems to do nothing at all but I haven’t poked at it), but I think the real reason for the decline in my score is neglect. The world kept turning but I stopped paying attention to this site. For a freelance developer, that’s a good thing because when we have paying work we tend to ignore our personal sites, but it’s embarrassing for a guy who’s supposed to be Performance Focused.
So, I’ve got some work to do here, don’t I?
I had to do this a couple of weeks ago for a simple “Special Offer” modal window. This is better.
(Yes, I use this blog to remind myself of things — things aren’t always about you, ya know).
A while back I built a small project using Backbone and really liked the way it turned out. A larger project came up, also well-suited to the framework, and I got this book to help me build a more solid knowledge base before beginning the project. It didn’t help at all.
Although Backbone.js provides the core content of the book, my impression (I didn’t read the book carefully, all the way through) was that peripherals take up much more space, and I was reading much more about Bower, Browserify, Requirejs, Grunt, Handlebars, Obscura, Yeoman and so on, than I was about Backbone. There’s nothing wrong with those tools but I use many of them already and I simply could find no use for much of the book’s content within my work flow and I lacked the time (and the inclination) to change my workflow so that I could undertake the tutorial embedded.