Improving Ember app page load times using the App Shell model

Marten Schilstra

Engineering Manager

Marten Schilstra

In the past week I have been experimenting with the App Shell Model to make the website load faster. In this blog post I’ll walk through which changes I made and how I’ve made them. Complete with some benchmarks!

Why improve page load speed?

According to Google, if loading a page takes too long, they’ll just abandon it. This hurts your conversion rates. Key metrics that contribute to better conversion rates are when the browser is able to make its first paint and when the page is fully loaded.

Tools of the trade

In this section I’ll introduce the tools I’ve used to measure the loading performance. Please take a minute to follow the links to the mentioned tools and read how they work and what they are for.

To be able to measure the performance of I have used Lighthouse and the Application, Network and Timeline DevTools from the Google Chrome team to see changes made a positive impact on loading speed.

Lighthouse is the successor of Google’s PageSpeed tool. Lighthouse uses your Chrome DevTool to do a host of automated audits. I.E. it checks if a Service Worker is registered and that a Web App Manifest can be found. The audits I’m most interested in are the page load performance audits. These measure the first meaningful paint, the speed index and time to interactive performance.

What I’m measuring

I’m measuring the page load in two situations. The first situation is as if it’s the very first time I’m visiting the website, this means no assets have been cached yet. The second situation is when I’m loading the website on a repeat visit, which means the browser had a chance to cache the assets. I’ll also measure the same two scenarios using network and CPU throttling to simulate being out and about on a mobile device. Mobile simulation is done on the ‘Regular 3G’ network throttling setting and the ‘Low end device’ cpu throttling setting.

There are three key performance metrics I’m looking for in each test, first I’ll look for when the first meaningful paint happens and second I’ll look for the moment when the Ember.JS app has booted client side and when the Ember.JS app has done its initial render on the client side. The first meaningful paint and the initial render metric are the two metrics that according to Google contribute the most to abandonment rate.

Getting the baseline

Benchmarks have been made on a standard mid 2015 15” MacBook Pro, all tests have been done with a wired 500 megabit up/down internet connection. I have about 90ms latency towards the webserver and about 7ms to the assets server.

To start out, here are the baseline performance metrics of the current website. It is a Ember.js application that is served with FastBoot.

Baseline Lighthouse score

Note: Lighthouse measures without CPU slowdown and a custom network throttling setting

This initial lighthouse score shows that the first meaningful paint comes just before the time to interactive. This does mean that when the page shows up, it’s almost immediately interactive, but you’ll see nothing before that.

Baseline Desktop: Page load with empty cache

  • First paint: 600ms
  • App boot: 1,175ms (the dip in the CPU graph)
  • Initial render: 1,400ms

Baseline Desktop: Page load with warmed cache

  • First paint: 325ms
  • App boot: 750ms
  • Initial render: 950ms

Baseline Mobile: Page load with empty cache

  • First paint: 1,200ms
  • App boot: 8,900ms
  • Initial render: 10,200ms

Baseline Mobile: Page load with warmed cache.

  • First paint: 850ms
  • App boot: 2,850ms
  • Initial render: 4,200ms

The changes I’ve made

First off I’ve added (offline) caching by a Service Worker, using Ember Service Worker with various plugins. This did not, as expected, improve the cold boot scenarios, but did improve the scenarios with warmed cache slightly. Especially the first paint was much earlier. Results of the warmed cache scenarios are:

Service Worker only Desktop: Page load with warmed cache

  • First paint: 125ms
  • App boot: 725ms
  • Initial render: 900ms

Service Worker only Mobile: Page load with warmed cache

  • First paint: 300ms
  • App boot: 2,700ms
  • Initial render: 4,000ms

Next I wrote a small Ember CLI addon that concats both scripts (vendor.js and dockyard.js) that Ember CLI produces together. Then I proceeded to load that single JavaScript file using a `` element in the head that was marked async. This had no significant improvement on the desktop side, but loading on mobile did improve. There is a small downside to this technique though, the two files aren’t cached seperately by the browser anymore, which can increase the amount of data needed to be transferred when deploying new builds often.

Async’ed script Mobile: Page load with empty cache

  • First paint: 750ms
  • App boot: 7,950ms
  • Initial render: 9,000ms

Async’ed script Mobile: Page load with warmed cache

  • First paint: 200ms
  • App boot: 2,350ms
  • Initial render: 3,550ms

Lastly I extracted all the critical CSS for an initial render and inlined it into the `` section. Then proceeded to asynchronously load the remaining CSS using loaddCSS. This made the first paint come slightly earlier in all scenarios, but hurts the initial render by about 150ms on mobile.

Async’ed CSS Desktop: Page load with empty cache

  • First paint: 550ms
  • App boot: 1.100ms
  • Initial render: 1.325ms

Async’ed CSS Desktop: Page load with warmed cache

  • First paint: 125ms
  • App boot: 675ms
  • Initial render: 900ms

Async’ed CSS Mobile: Page load with empty cache

  • First paint: 500ms
  • App boot: 8,100ms
  • Initial render: 9,150ms

Async’ed CSS Mobile: Page load with warmed cache

  • First paint: 125ms
  • App boot: 2,500ms
  • Initial render: 3,700ms

All the stats summed up in a table

Final Lighthouse score

Note: To get the perfect 100/100 score we also added a Web App Manifest.

That’s an impressive 10x speed up in first paint and almost a second and a half in time to interactive. This gives your user much more confidence in that your page is loading.

Browsers without Service Worker

You might ask: “How does this affect page loading in browsers that not yet support Service Workers?”. I’ve tested the before and after with Safari’s timeline tool. The results show no significant speed up in full page load, but actually a slight slowdown. The results do show a significant speed up in first paint time with either empty or warm cache.

After the benchmarks I’ve noticed that loading the service worker registration script plays a big part in the slowdown. I’d need to fiddle some more with loading that script to see if I can get rid of the slowdown.

Below are the timeline graphs for loading in Safari. Notice the big shift of the blue DOMContentLoaded line. That counts as the first paint. The red Load line is the app boot. The last green bar is the initial render.

Baseline: Page load with empty cache

  • First paint: 510ms
  • App boot: 600ms
  • Initial render: 740ms

After improvements: Page load with empty cache

  • First paint: 250ms
  • App boot: 650ms
  • Initial render: 820ms

Baseline: Page load with warm cache

  • First paint: 510ms
  • App boot: 575ms
  • Initial render: 730ms

After improvements: Page load with warm cache

  • First paint: 250ms
  • App boot: 620ms
  • Initial render: 780ms

Safari tests summarized


A Service Worker and a bit of techniques from the App Shell model can boost your page load times. Your app will show up on the screen earlier and be interactive quicker, which in turn can improve the conversion rates of your website.

Please try out these techniques and see for yourself if it improves page load times of your app. In any case let me know how it works out for you.

Closing: don’t forget to compress your images, svg’s and fonts! Those too can impact page load performance by seconds on mobile.


Stay in the Know

Get the latest news and insights on Elixir, Phoenix, machine learning, product strategy, and more—delivered straight to your inbox.

Narwin holding a press release sheet while opening the DockYard brand kit box