How to test a Progressive Web App
Introduction: A progressive web application (PWA) is a type of application software delivered through the web, built using common web technologies including HTML, CSS and JavaScript. It is intended to work on any platform that uses a standards-compliant browser. Functionality includes working offline, push notifications, and device hardware access, enabling creating user experiences similar to native applications on desktop and mobile devices. Since a progressive web app is a type of webpage or website known as a web application, there is no requirement for developers or users to install the web apps via digital distribution systems like Apple App Store or Google Play.
While web applications have been available for mobile devices from the start, they have generally been slower, have had fewer features, and been less used than native apps. But with the ability to work offline, previously only available to native apps, PWAs running on mobile devices can perform much faster and provide more features, closing the gap with native apps, in addition to being portable across both desktop and mobile platforms. PWAs do not require separate bundling or distribution. Publication of a progressive web app is as it would be for any other web page. PWAs work in any browser, but “app-like” features such as being independent of connectivity, install to home screen, and push messaging depend on browser support.
Characteristics: Progressive web apps are designed to work on any browser that is compliant with the appropriate web standards. As with other cross-platform solutions, the goal is to help developers build cross-platform apps more easily than they would with native apps.
According to Google Developers,the characteristics of a PWA are:
Progressive – Works for every user, regardless of browser choice, using progressive enhancement principles.
Responsive – Fits any form factor: desktop, mobile, tablet, or forms yet to emerge.
Faster after initial loading – After the initial loading has finished, the same content and page elements do not have to be re-downloaded each time. Ordinary websites often already made use of the browser cache to avoid re-downloading the same data redundantly.But on progressive web applications, the same elements do not need to be re-rendered again.
Connectivity independent – Service workers allow offline uses, or on low quality networks.
App-like – Feels like an app to the user with app-style interactions and navigation.
Fresh – Always up-to-date due to the service worker update process.
Safe – Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
Discoverable – Identifiable as an “application” by manifest.json[14] and service worker registration, and discoverable by search engines.
Re-engageable – Ability to use push notifications to maintain engagement with the user.
Installable – Provides home screen icons without the use of an App Store.
Linkable – Can easily be shared via a URL, and does not require complex installation. The technical baseline criteria for a site to be considered a progressive web app by browsers were described by Russell in a follow-up post:
PWAs should support offline connectivity
Originate from a secure origin. Served over TLS and green padlock displays (no active mixed content).
Load while offline (even if only a custom offline page). By implication, this means that progressive web apps require service workers.
Reference a web app manifest with at least the four key properties: name, short_name, start_url, and display (with a value of standalone or fullscreen)
An icon at least 144×144 large in PNG format.
Use of vector graphics that are indefinitely scalable and require smaller file sizes. Some progressive web apps use an architectural approach called the App Shell Model. In this model, service workers store the Basic User Interface or “shell” of the responsive web design web application in the browser’s offline cache. This model allows for PWAs to maintain native-like use with or without web connectivity. This can improve loading time, by providing an initial static frame, a layout or architecture into which content can be loaded progressively as well as dynamically.
PWAs should support offline connectivity
Technical Components of PWA: There are two main technical components of a progressive web application: manifest file and a service worker
Web App Manifest file: Essentially a manifest file is a JSON file through which developer can control how the app is displayed to the user.
Service Worker: It is a Javascript file which handles the user’s interaction with the app. It runs independently from a webpage or app. It supports the main features of PWA’s like push notifications, offline work mode and background synchronization
Key Points to keep in mind while testing PWA: { "short_name": "Weather", "name": "Weather: Do I need an umbrella?", "description": "Weather forecast information", "icons": [ { "src": "/images/icons-192.png", "type": "image/png", "sizes": "192x192" }, { "src": "/images/icons-512.png", "type": "image/png", "sizes": "512x512" } ], "start_url": "/?source=pwa", "background_color": "#3367D6", "display": "standalone", "scope": "/", "theme_color": "#3367D6", "shortcuts": [ { "name": "How's weather today?", "short_name": "Today", "description": "View weather information for today", "url": "/today?source=pwa", "icons": [{ "src": "/images/today.png", "sizes": "192x192" }] }, { "name": "How's weather tomorrow?", "short_name": "Tomorrow", "description": "View weather information for tomorrow", "url": "/tomorrow?source=pwa", "icons": [{ "src": "/images/tomorrow.png", "sizes": "192x192" }] } ] } An example of how a manifest file actually looks like
Validate PWA manifest: A manifest file is must for the progressive-webapp. A tester should look for the following in the manifest file: It has a name or short_name property It has short_url property WebApp Manifest has a icon property which should include a 192px and 512px sized icons
standalone display property
Minimaldisplay property
Display property should be set to standalone, fullscreen and minimal-UI
Validate the service worker: Service worker registered with the fetch event handler The webapp should be served fully via HTTPS: Safety is the major concern in the world of PWA and a tester should always make sure that site is served via HTTPS. To test this, You can use Lighthouse by Google Developers, Jitbit, SeoSiteCheckup, DigiCert, SSL shopper, SSL labs, etc to test if your website is served over HTTPS or not. Webpages are responsive: Make sure that your web application shows responsive behavior across all mobile and desktop devices. Offline Loading: All of the web pages or at least some critical pages should work offline. As a tester, you need to make sure that your web app responds with a 200 when it is offline. Lighthouse, Wiremock tool can be used to test this Metadata for ‘Add to Homescreen’: You need to test if the web app provides a metadata for ‘Add to Homescreen’. Page transitions: Transitions should be smooth and should not be snappy even on slow networks. Each page must have a URL: Every page on your web app must have a URL and all the URLs must be unique.Test it by checking that every page is linkable by a URL and it is unique to be shared on social media or other platforms. The URLs can also be opened directly in new browsers. Functionality: This is the most essential part of any testing. Functional testing covers the aspects of the app with respect to the functionality defined in the requirement document. A tester can do it both manually or through automation.
Tools available to test a PWA: There are a variety of tools available to test a PWA, but here we have focused on Lighthouse which is readily available in Google Chrome browser. 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, SEO and more. You can run Lighthouse in Chrome DevTools, from the command line, or as a Node module. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did. From there, use the failing audits as indicators on how to improve the page. Each audit has a reference doc explaining why the audit is important, as well as how to fix it.
Run Lighthouse in Chrome DevTools Lighthouse powers the Audits panel of Chrome DevTools. To run a report:
Download Google Chrome for Desktop.
In Google Chrome, go to the URL you want to audit. You can audit any URL on the web.
Open Chrome DevTools.
Click the Audits tab.
To the left is the viewport of the page that will be audited. To the right is the Audits panel of Chrome DevTools, which is now powered by Lighthouse
5. Click Perform an audit. DevTools shows you a list of audit categories. Leave them all enabled. 6. Click Run audit. After 30 to 60 seconds, Lighthouse gives you a report on the page.
A Lighthouse report in Chrome DevTools
These details and reports come in handy for developers as they get more insight on the issues their application is facing.
Looking forward to publishing new details and ways of testing the PWAs.
On a serious note, please stay at home and safe. Practice good hygiene and help fight against the pandemic that is currently raging throughout the world.