Progressive Ember - Baseline

A walk through the real effort to transition an enterprise level Ember application to a progressive web application.

Part one: The baseline, aka you can’t improve on what you can’t measure

What this isn’t

This not going to be a step-by-step guide on building a progressive web application (PWA). I suspect that’s largely dependent on your application. Besides, there are already good overviews on just that:

It’s a journey

This will be similar to a talk given by Ivan Vanderbyl at EmberFest. While ember installing a service worker and adding a web manifest will boost your Lighthouse score, there’s a lot more that goes into a PWA.

My application isn’t a simple to-do list or blog post list either; So it’s not as easy to “just remove jQuery” or tack on a service worker. It’s a real business application that is internationalized in 5 languages, has a lot of dependencies, consists of a large design system, etc.


I’ll be using a few tools through this journey that are critical to measuring success.

I want to start with a baseline of what Lighthouse thinks of my application.

Baseline Lighthouse

I’m not that surprised to see Progressive Web App or Accessibility where it is, but Performance is really poor. Notable poor performers are first meaningful paint, at a brutal 9.1 seconds and there’s a lot of main thread work parsing JavaScript. Let’s dive in to just how much JavaScript are we talking about. I’ll run broccoli-concat-analyser on the production build of my application to see where my size comes from exactly:

Here is the result:

Baseline Build

What you’re looking at is a breakdown of where JavaScript size comes from. Ember and jQuery are obvious eye catchers, but there are a lot of surprises in there as well. For example, my application doesn’t use lodash, but it’s included in my vendor build for some reason at a whopping 65 kB. Moment accounts for around 40 kB. Showdown is another huge offender at 21 Kb.

Some other surprising items include:

It’s easy to dismiss these things as trivial. Even if all of your users have high speed internet, every bit of JavaScript not only has to travel over the wire, but then the browser has to interpret it. So even removing 10 kilobytes can have a noticeable impact on a mobile device.

Where to start

Before we starting caching and optimizing assets, adding service workers, etc. Let’s get this build size way down.

Most PWA guides for Ember will tell you to start by removing jQuery. It’s about 20 kB that isn’t necessary any more. My application doesn’t need to support any legacy browsers, but I can’t remove jQuery just yet because I have some design components that depend on it. That’s a much longer play, so I’ll have to skip that for now. So where could I actually start?

Let’s get to work.

Keep reading