The Need For Speed

Tom Cruise may be crazy but as they say, even a broken clock is right twice a day, and even though he was reading from a script, Maverick was onto something out on the tarmac. Speed matters and we’re constantly seeking it. Personally, I get frustrated when I’m stuck behind a slow bus in the bike lane. I don’t like it when a package takes an extra day or two to get to me. And, like many users of the web, I hate waiting for pages to load. This past week, that last one hit a bit too close to home.

We talk about speed with all of our clients. Questions like, “How quickly do I have to get feedback to you?” and “How long do we have to pay you?” are par for the course. What is less common is “How fast is our site going to load?” However, that’s one of the most important questions for any successful site launch and is something that I had neglected to ask while developing our own site. I was really excited when the new site launched. We’ve been working on it longer than I care to mention (again) and it was great to push it live. What wasn’t great was the 5+ second page loads. This could not stand.

We had a good start. Expression Engine makes it quite simple to optimize your database queries and cache template pieces. While looking over our templates, I noticed there were a couple things I had forgotten to circle back on, but for the most part we were good there. Part of the problem was that we were on a shared host with limited resources. Another part of the problem was that, due to the way the site was designed, we had to make a higher-than-usual number of database queries. By mid-week we had patched up everything we missed, but it still wasnt fast enough. Three seconds for the initial request and another .6 seconds to render it all? Nope.

Screenshot of slow page rendering from Chrome's Developer Tools.
Still too slow

On the assets side, we’ve already looked at file size and feel that we’ve struck the right balance between limiting http requests, keeping file size low and supporting hi-dpi screens. There are a few images we can sprite up, but that wasn’t the problem. I had to find the savings somewhere else. Better site caching to the rescue. We’ve used some other third party Expression Engine caching solutions in the past.

  • Template Morsels is one of my favorites, but I’ve been shying away from it lately. I’m not a big fan of how it takes large chunks of the templates out of the templating system. I also don’t like that it won’t automatically regenerate its cache files.
  • People I trust quite a bit more than myself rave constantly about Stash. It’s on my radar but I kept looking because I wasn’t convinced.

In the end, turns out I had an unused license for CE Cache, and decided to try that out. I’m quite glad I did. Let’s let the load time do the talking.

Screenshot of quicker page rendering from Chrome's Developer Tools.
Just right

Both images show the front page loading in a Chrome Incognito window, browser cache disabled and emptied. The numbers speak for themselves. From three seconds to 1/10th of a second for the initial request and from 3.6 seconds to .7 seconds for the full page load. That makes me happy. Where did the speed come from? Glad you asked.

CE Cache has a great feature (as far as I’ve looked, seemingly unique among the Expression Engine caching solutions) where instead of storing cached chunks of templates, it will run your site in static mode, similar to what Moveable Type did so well (perhaps the only thing it did well). When you call a static cache tag in a template, a full, flat html file is saved and stored on your server and sent back each time that page is requested, almost completely bypassing the database and not needing to render anything on the fly. It was quite simple to hook up and roll out across most of the site (took about 15-20 minutes). In the few cases where I needed to make sure there was dynamic info that got updated with every page load, the standard caching mechanisms gave me more than enough control over saving the heavy lifting out as flat files while still keeping dynamic pieces of the page uncached.

Simply put, I’m impressed, and the results speak for themselves. Adding this one to the standard toolkit.

Since this post was published, I’ve rebuilt the website using Middleman to generate static site files and make the site really scream. I’ll be adding an entry to the blog about the techniques we used to speed up the site in the redesign shortly.