Author: Mikołaj Smoleński
Free live lesson
How can we tell if our app is working as a progressive web app? Is there something we can improve on? Or our app is already good enough?
In today's article, we are going to learn about an auditing tool which helps us determine if our app qualifies as a PWA.
Lighthouse is an open source tool introduced by Google. At first, it was created to measure the performance of PWA, but now its functionality covers much more. It verifies the quality of your application in five categories:
- Progressive Web App
- Best Practices
In the report, you will get a score between 0 and 100 points, where 100 is the highest. Your score may vary between tests - it may happen because of changing network conditions, different processes running in the background on your computer and so forth. It is worth to run a few tests and take the average of the results.
Moreover, the report gives you a set of recommendations - that, when implemented, improve your website performance and visibilitzy to the search engines. It's always a good idea to measure your site against Google's set of criteria - the suggestions help one to become a better developer.
Lighthouse is available as a Chrome extension for Chrome 52 and later, and since lately, Firefox, too!
How to run the audit?
To run the audit open your app in a browser (Chromium / Chrome / Firefox). Auditing tools can be found in the Audits tab.
Open the tab, adjust the settings to your needs or run as a default. After a brief moment, you will see the report.
As you can see, there is some room for improvement! By clicking on categories or by scrolling down, we can examine the test results in detail.
There are at least few things we could do to make our app more Progressive. Let's start from the bottom.
Content is not sized correctly to the viewport
The issue is that at some point, while Lighthouse has been checking how does our app behave on different viewport
outerWidth properties of the
have been different. To ensure the best mobile user experience, the test is effectively checking whether the
content does not overflow horizontally, leading to an unexpected scroll time. The number of pixels in the hint
indicates at what width the problem appears - by narrowing the browser window, you can simulate it to see
the problem from up close.
The culprit is right there - when the horizontal space is getting scarce, the two main columns of our app stay
side by side, resulting in the text being pushed out the right border. How to solve it? Well, for one, we could
add a scoped
<style> tag to our
./src/App.vue file and include there a CSS
overflow-x: hidden; rule targetting the main
The solution would allow us to pass the test by hiding away the problem's effects, but let's face it - it would not allow us to regain what we're currently loosing, namely the control over the flow of the content on narrow viewports. We are good devs with genuine intent, so let's utilize the MDB customizability instead. After all, why hide the leaking content, if we could have it beautifully displayed using the library?
Let's have the layout as it is, but with a minor detail change - in case there is no space to have the main
columns side-by-side, may the content flow down. We'll achieve it using the MDBVue's grid system through
The way it is now, we are describing the columns' widths as
3 for all the screen
sizes. As we know from the docs, though, that we
can overwrite these using dedicated props for given sizes and up.
Ideally, we would like to keep the current columns' proportion for all the screen sizes wider than
sm(all), where the columns should go one beneath the other, taking up all the available horizontal
space, which, in case of our grid, means full
To achieve it, identify the two root columns in the app. We must fiddle with their props - assign maximum width
for default (the smallest) screens, and overwrite it with the current proportions for all the viewport widths
beyond smartphone ones using the
<template> <mdb-container> <Notification :status="status" /> <mdb-row> <mdb-col col="12" sm="9"> <!-- first column's contents... --> </mdb-col> <mdb-col col="12" sm="3"> <!-- second column's contents... --> </mdb-col> </mdb-row> </mdb-container> </template>
Try it out now - the content should gracefully flow down on mobile, while the Lighthouse PWA width test should pass as well!
Does not set a theme color for the address bar
Lighthouse audit considers the lack of the
theme-color meta tag a failure. But didn't we declare it
at the very end of our
manifest.json (although spelled with an underscore,
It turns out we should always specify the color using the tag. Browsers do acknowledge the manifest, but only once the user has added the page to their home screen. Otherwise, the tag overwrites the value from the manifest, allowing for a bit more customization (to have different theme color for different subpages). Let's add the tag, then!
<!--...somewhere in the head tag... --> <meta name="theme-color" content="#4DBA87">
Yup, it is all there is to it!
Does not redirect HTTP traffic to HTTPS
We want to have communication to be secure(r) with
https - and we want it with no exceptions. In
practice it means configuring the server to redirect all the
http traffic back to safety. For our
development environment we could use
webpack-dev-middleware to add a little middleware listening to requests starting with
http or with the
request.secure flag being set to
false and then
redirecting to the same place, only over the
The effort would guarantee passing of the test, but we'd miss the bigger picture. The test is about the way our
server is handling insecure requests from our users, and us bending our development environment for particular
redirects would not change anything for them. If we really want to ensure safety and privacy for our audience through
https, it is the
production server we should worry about. In general, exact ways to
fulfill the requirement depend on the server architecture and configuration.
We're in luck - many platforms for hosting our project, like
are secure by default - their servers redirect traffic from
out-of-the-box. Deploy the project, head to the given URL and run the audit again to see what I mean.
If you are looking at the production build audit, you may recognize the redirects test passes - and many other followed. Our results got boosted up across the board!
Page load is not fast enough on mobile networks
This here is another issue that got solved by building our project. Why? By building we mean undertaking
optimizarions not possible nor desired for development. Our webpack production setup
code (meaning both minifying and obscuring it), strips it of the comments, whitespaces (and quotation marks for
./build/webpack.prod.conf.js file for the details!
All that adds up to the app's much better performance, bolstered up with the extra fast Firebase CDN. With hard work and some infrastucture help, we made our app fully progressive!
Question of performance, though, should be never taken lightly! It is always worth exploring, whether we could
have our app deliver content even faster - after all, it would constitute the experience that would have people
return. Enhance the caching policy to include necessary resources and experiment with preloading and deffering
scripts using the
defer attribute to speed up the load times.
As we've learnt in the article, Lighthouse Audit is a powerful benchmarking tool aimed to provide guildelines for mobile - first web developers. It certainly helps to get our apps straight in terms of PWA support and performance, but don't aim to satisfy the only the test itself - oftentimes, it's the test's wider context what is worth considering. All in all, considering these guidelines is a great way to learn best practices.
Something doesn't work for you? Check the code for this lesson on our repository
Previous lesson Download Live preview
Spread the word: