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

Optimising the Performance of an Ionic Application — Part 1

Brett Uglow
Aug 10, 2017 · 3 min read

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:

Image for post
Image for post
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:

Image for post
Image for post
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:

Image for post
Image for post

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.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store