PWA audit


PWA audit

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

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:

  • Performance
  • Progressive Web App
  • Accessibility
  • Best Practices
  • SEO

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.

Lighthouse audit

Open the tab, adjust the settings to your needs or run as a default. After a brief moment, you will see the report.

Lighthouse 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.

detailed PWA report

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 widths, the innerWidth and outerWidth properties of the window interface 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.

Content is leaking to the right

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 .container.

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 <mdb-col> props.

The way it is now, we are describing the columns' widths as 9 and 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 12.

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 sm prop.


        <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, theme_color)?

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 https.

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 Firebase or GitHub Pages, are secure by default - their servers redirect traffic from http to https out-of-the-box. Deploy the project, head to the given URL and run the audit again to see what I mean.

yarn deploy

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!

PWA report on Firebase

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 uglifies the code (meaning both minifying and obscuring it), strips it of the comments, whitespaces (and quotation marks for HTML attributes), splits the JavaScript into chunks, and compresses media - be sure to check out ./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:
Do you need help? Use our support forum

About the author