New tools to help you be quick

Wednesday, March 25th, 2015
By Daniel Cooper

At Homeflow towers we spend a lot of time and resources making sure that our services respond as quick as possible – so as a developer you can always be sure you’re delivering your clients industry leading server response time.

The server response time is only half the story however – there are some simple changes you can do to your Homeflow theme to make the site feel really snappy on the front end. Today we’re releasing some new tools to help you get your Google page speed in the 90’s and satisfyingly green.

To walk you through these changes we’re going to look at one of our portal sites, Radar Homes. Here’s our starting point.

Not now, Javascript

So what’s going on here?

As a page loads the browser has two jobs. Firstly it has to build a DOM object representing the page. This evaluates to a tree structure, with the <html> element being the root. In order to render the page the browser must walk down this tree structure and paint portions of the screen. To give the impression of a quick load the browser will try to paint as it goes and when external resources are found, like CSS and images, it’ll perform an asynchronous call to those resources and carry on its walk. As those resources come it will repaint the screen based on what those resources contain.

The only problem with this is that JavaScript is render blocking. This means that the browser cannot continue to walk and render the tree until that JavaScript has been loaded. In most websites you’ll see jQuery included in the head – this means that the browser must download and parse an additional ~250KB (if not minified or compressed) of data before the user is able to see any significant portion of the page.

This is what Google is asking us to do – move that blocking JavaScript out of the way so our browser can draw more of the page sooner. The obvious solution is just to move all JavaScript to the end of the page and call it a day. This can be a bit problematic because, for library files especially, it forces us to move our entire JavaScript payload to the end of a page. Consider something like the Ctesius.addConfig() call that every theme uses tens of times – every one of those calls would have to be placed at the very bottom of the page, which would become incredibly clumsy for complex themes which need to set different config on different pages.

So, we’re adding two new partials for your use.

{% include ‘js_templates/async_head’ %}, which should be included somewhere in the head of your layout.


{% include ‘js_templates/async_foot’ %}, which should be included at the very bottom of the page, below your JavaScript includes.

This JavaScript sets up a very small amount of scaffolding for your app – it’ll provide stubs for methods like $().ready() and add each of those calls to a queue. When we have our full JavaScript available we can then run through those queued and call and pass them to our fully loaded JavaScripts.

This is an experimental feature at the moment that we’ve deployed on RadarHomes and we’d encourage you to use it on your themes and let us know how it goes.

N trips are better than N+1

For a couple of years now we’ve provided a two big asset packs. Application.js gets pretty much all the JavaScript you need to deliver to a Ctesius site, including Draw-A-Map, the profile system and search validation. And Application.css provides a bootstrapped skeleton for styling.

There are a couple of problems with these asset packs as they stand. Over the years there have been lots of well intentioned but looking back, slightly questionable, additions to those files. They’re also only ‘core’ assets – meaning the assets that make your theme need to be delivered separately, and we haven’t done a very good job of helping those be quick by default.

We tried to address that with ‘asset packs’, configurable in your config.yml.

And it was a good start –  but it still left us with non-essential code being sent out in the core pack and a separate file for the theme assets. So, we’re also making available single file asset packs. Let’s look at the Radar Homes example.

If we detect a vendor_assets pack defined in the config file then we’ll replace your regular {{ “application” | javascript_include_tag }} with whatever you define to be in those packs. And here are the options:

For JavaScript

  • Ctesius – Gets all mandatory files; jQuery, underscore, leaflet.js, and the Ctesius system built upon them
  • classic_extra – Additional files that at one point or another were recommended. Includes stuff like the NivoSlider and jQuery Cycle. If you’re upgrading an existing theme you may find it’s required – new themes shouldn’t use it.
  • asset_pack – your theme asset pack as defined by your asset_packs yaml


  • Ctesius – Gets all mandatory CSS files – mostly Leaflet and Draw-a-Map changes and CSS to support the base profile
  • classic_extra – Bootstrap 2 and the Nivo slider. The default user system requires this to be styled correctly
  • asset_pack – your theme CSS

The Result?

We’ve fixed some inefficiencies in our JavaScript load times, reduced the amount of asset files required and hopefully removed some unneeded code.