Sky High Performance — Marc (CC BY-NC-ND 4.0)

Optimising the Performance of an Ionic Application — Part 1

How we improved the Odecee Tech Radar.


ThoughtWorks produces a “technology radar” (TechRadar) every quarter. Bryce Johnson took this idea (which is encouraged by ThoughtWorks) but wanted to create a tool to allow our team to create their own Tech Radars. And eventually, to make the tool public so that anyone to create any kind of radar they wanted.

After 12 months of development by two separate graduate & junior development teams (plus some DevOps engineers), the Odecee Tech Radar app was released as a beta:

A radar from as at June 2017

The application uses Ionic as we plan on releasing it as a native app as well as a desktop app. It has some great features, in-built help videos and works on all browsers.

However, the application had not undergone *any* performance tuning. This article walks through the first steps that we took to improve the performance of the app.

Initial State

Before we started any optimisation, this is what the Google DevTools network panel looked like:

The horror…

The 16 of resources took 5.5s to render (on wifi) and is 6.5MB in size — just for the login page. That’s pretty hefty.

A quick Google DevTools Audit reported 3 areas to address:

  • Enabling GZip
  • Enabling Browser caching
  • Combining resources (not a major issue in this case)

Step 1 — Enabling GZip on the server

The biggest bang-for-buck appeared to be enabling Gzip on the web server (ngnix in this case). A quick google search showed this tip on how to turn on gzip compression for ngnix:

So after enabling GZip, the new site stats were:

Performance after GZip

app.bundle.js, 5.3MB → 1.3MB (75% reduction)
vendor.bundle.js, 225KB → 59.3KB (73% reduction), 601KB → 80.4KB (87% reduction!)

Step 2 — Enabling Browser caching

Next step was to enable browser caching for the static assets:

This will add correct cache-expiry headers for the static assets. Even if we eventually add service-worker support, we should still do this (because Safari still hasn’t implemented this API. But it is working on it — yay!).

Step 3 — Make that radar smaller

radar.png was 202kB. Checking the HTML revealed why:

While the image was presented at 250 x 183 pixels, it was actually a 748 x 724 pixel image (34,960 pixels rendered vs 555,016 pixels in the raw image)!

So we had a couple of options:

  1. Resize the PNG to match the intended render size.
  2. Use an SVG format instead, which should be smaller yet still look good on different devices (as a vector image).

Thanks to my colleague Ari, the image was converted to an SVG. The new size? 1.6KB. Gotta love vector graphics :)


After making these changes, here was a typical result (over a WiFi network):

  • Bytes downloaded is now 1.5MB instead of 6.5MB
  • The document loads in under 2s, instead of 5.5s

So what else could we do to improve performance? Quite a few things actually, which you can read about in Part 2.