Blah before the topic

Web has changed from knowledge based web page assembly to first-class application platform. The Progressive Web App (PWA) has filled the gap of the web app and the native app on mobile. The Single Page Application (SPA) has been embraced by industry and one SPA page often contains HTML, CSS, bunch of images and megabits of Javascript.

The Problem

How “webby” is your application? Does it perform/work well on Cable/ADSL/Slow 3G/Flaky connection/Offline? Maybe you say your web app is sleek and feature rich but only works well on desktop browser using a cable/ADSL connection. If so, to be brutally honest, your app is not a real web app application. It is just a desktop app needs internet. In a mobile dominant world, a web app really must perform well on the mobile internet. To define a performant app, Google released the RAIL model in 2015.

Rail represents major aspects of performance — Response Animation Idle Load

A performant web app complies to the RAIL standard, which in summary, means:

Response: respond to the user action in under 50ms Animation: produce a frame of animation within 10ms Idle: maximize the idle time Load: deliver content and become interactive in under 5 seconds with a slow 3G

Let’s just focus on the last goal here. Performance is a key standard for every application yet it is under-appreciated. Why under 5 seconds? Because with each passing second users lose focus on the tasks they are performing. 5 seconds is a reasonable time window when site loads first time. If you think 3G network is a bit mean, GSMA data shows a stunning 37% of mobile users still using 3G network in Europe, which is considered to be a developed region and globally the figure is 31%. check Can You Afford It? Real-World Web Performance Budgets.

Faced with 3G, become interactive within 5 seconds is still hefty goal for most Australian sites to meet. After turning on slow 3G throttling and mobile emulator in Chrome dev tools, I did an audit for popular Australian websites.

Aussie sites landing pages load under slow 3G in 2018

www.nab.com.au

www.anz.com.au

www.westpac.com.au

www.commonbank.com.au

www.seek.com.au

world wide mobile loading time

Interesting yet embarrassing, most sites are well over the 5 Seconds benchmark to become interactive. And quite a few are over 10 seconds which means many users will abandon mobile web option and start to seek alternative. These sites will become ones you will want to avoid under 3G network conditions. Stay in your room and public central area Australians! Data listed above shows two things:

First – initial page size is critical. If your page size is near 1000k, you are pretty doomed under 3G network.

Second – Javascript is expensive. A few sites are fast on DOM loading but takes a lot longer to be feature ready (DOMContentLoaded > Load >Finished). There is an article stating the cost of Javascript by Addy Osmani. Highly recommended to read.

Lighthouse

Where to start with performance boosting? Rome was not built in one day. Performance improvement is system engineering and Rome can get better one day at a time. To build and maintain a blazing fast web app, the best way is to build it fast from very start and review your changes by performance on every commit. We need a scan tool to evaluate quality of work, especially performance. Performance is big feature yet fragile to changes. Check out article of why performance matters.

Let Google’s lighthouse become your near and dear friend. As web developer you probably may have used lighthouse before.

Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, and more.

lighthouse scan report gives score and advice to improve

Lighthouse gives feasible advice to improve web performance. I assume that most web developers had at least tried lighthouse. They might have done a scan and get a few WOWs “I should do this and do that…” out of it. In many cases they might have picked a couple of low hanging fruits and the remaining of issues reported are probably:

Too hard to change. Like js bundle oversize, which needs considerable effort to tree shake and split into smaller async bundles.

Too late to change. At later stage they found massive forms, framework with performance deficiencies or UI assets delivered by a third party is not performant.

Too hard and too late. Facing such a monster no one wants to touch, you just want patchy-temporary hack to massage a customer pain point.

There’s nothing more permanent than a temporary hack. — Kyle Simpson

How to keep the performance riding high and proud? Just like unit tests and end to end tests you breath with daily, performance an equally important feature of your application and should be measured on a per commit base and monitored closely to prevent decay. What if I knew my performance was impacted during a pull request? On a whim, I did Lighthouse integration demo project and would like to share the way here:

I picked a “hello world” project yet not so “hello”. It is a starred project. It is a 52705 starred github celebrity called create-react-app. It is maintained by Facebook and it is one of the most popular generators to start with a react project. I used it to create this demo project named “webnowtalk”.

In the generated app, there is a full start up manual in README.md file. This is not the point here. Our goal is to integrate Lighthouse scan to every pull request. We will use Travis CI as integration tool. Take a look at the yaml configure file and package.json:

Travis CI is simple and elegant. With two lines npm run build npm run deploy project code is built and deployed to github pages using an npm module called “deploy-to-gh-pages”. The deployed link is https://hurricanew.github.io/webnowtalk/

CI process flow

Ok, process above seems standard. Now is the lighthouse mana time. We use lighthouse CI as integration tool. With npm run lh --websiteurl lighthouse ci will do the scan and use the score to justify build’s success and post a comment. Scan only happens it if the commit is a pull request commit. Hold the line before merging!

pr with lighthouse scan ci successful

updated flow chart for lighthouse-ci integration

Hoola finished. The first step of a thousand miles. And you can see the pull request link here.