Written by Ramón Saquete
Google coined the term ‘Progressive Web App’ (PWA) in late 2015, to name web applications, which are indistinguishable from mobile applications. Besides promoting and encouraging their development, they also established at the same time the specifications a website had to fulfil in order to qualify as a progressive web app.
Google is strongly invested into these technologies, because the company has seen how users are increasingly becoming more loyal to mobile apps than to websites, and the Web Applications 1.0 standard was conceived as the best way to turn the tables. However, this isn’t something new, and as a matter of fact, this idea started developing back in 2005, when the Web Applications 1.0 standard was conceived within newly-created WHATWG, a standard that later became HTML5.
Each time, users are increasingly more loyal to mobile apps than to websites.
‘Progressive’ from Progressive Web Apps was taken from the progressive enhancement development strategy. It is used to deal with functionalities that aren’t available on all browsers, so functionalities are added starting from the most basic ones, to ensure that a website is still accessible even if its more advanced features aren’t enabled.
Google has elaborated a long series of checkpoints a website must fulfil to be classified as a PWA, and you can see this checklist at the following link: https://developers.google.com/web/progressive-web-apps/checklist. As you can see, some checkpoints are there to provide computer engineers with something that us, developers, call functional requirements. They dictate what an app can do. Other checkpoints are non-functional requirements, for example, a good user experience, performance, security, etc. This means that a PWA can offer not only a mobile app’s features, but it also must be perfectly implemented.
Google provides us with the Lighthouse tool, to guide developers through tons of requirements that a website must fulfil to be considered 100% PWA. This tool can be used as a Chrome extension, or it can also be found in the Audits tab of the Chrome DevTools console. Another way to use it is through a command line, by installing it from the Node.js development framework’s package manager.
Let’s see a summary of some of some of these requirements.
The most noteworthy characteristics a Progressive Web App must fulfil
- It must be responsive: the design must be able to adapt automatically to any screen resolution.
- It must have Push notifications: if you don’t know what they are, I recommend you to read my post called Push notifications to increase your conversion and recurring visitors, as this is one of the most interesting features of PWAs. Besides being a new functionality that can bring added value to a user, it is also a new online advertising technique.
- Improved connectivity to work offline or with a bad Internet connection. In the past I’ve talked about a technology called Application Cache, but this solution ended up being rejected, because it caused many problems for correct management of updates. Now we should use service workers, which stand out as a solution allowing any cache strategy implementation we could possibly imagine (on top of being used for push notifications). They are small JavaScript programs that remain installed on a user’s browser, allowing to intercept requests to decide how we want to manage them. The most common cache strategies are cache-first and network-first: with the first one we check the cache, and launch a request to the network; and with the second one, the other way around. Within each strategy we can have different functionalities, such as indicating users when they are browsing offline, or when there’s a new update available.
To store URLs in cache API Cache is used (it uses Cache Storage), and for other data, IndexedDB. Web Storage (Local Storage and Session Storage) aren’t used, and neither are any other storage APIs, because they aren’t accessible from service workers. The accepted space depends on the browser and available storage space. Big amounts of information are only allowed prior permission request.
- They encourage recurring sessions thanks to the possibility of being added as a shortcut to the home screen, just as a regular mobile app, from the browser configuration (at the moment only available on Google Chrome, Firefox and Opera). To enable this feature we need to create a manifest.json file, where we will specify how we want our app to be displayed: name, icons in all necessary sizes, user interface buttons, home URL, etc. After that, we will have to link this file from the HTML code, by adding the following code to the tag and uploading manifest.json file to the root:
<link rel="manifest" href="/manifest.json" />
Additionally, if certain requirements are met, Chrome will display a banner suggesting the installation of the web app (Opera has already announced it will also provide this option). Currently, these requirements are: your website must be visited by a user twice, with at least 5 minutes in between each session; registration of a service worker and a manifest.json file with several mandatory parameters (name, short name, icons of at least 144px, and home URL).
The developer may capture the moment in which the browser starts displaying the banner to launch it at a more appropriate time, because this way there will be more chance that a user will choose to add the application. It can be done, for example, when a user has completed a purchase or a booking, or we can simply place a prominent button on our website’s interface, so that they can add our app whenever they want.
The following link provides an example of a PWA generator by Microsoft, which creates the manifest.json file for our website by entering the parameters:
https://preview.pwabuilder.com/generator
- The website must be fast: we need to use all kinds of WPO techniques for an instant load, to make sure that the screen doesn’t jump from one place to another when loading, and we must provide an immediate interface response, among others.
Some recommended WPO techniques are AJAX, or API Fetch, as it is called now. Google recommends to initially display the app’s shell, modifying its main content during browsing with API Fetch. In the future I will talk about the indexability issues this poses, and SPA (Single Page Applications) frameworks, which are useful when we use this structure, and if they are not implemented correctly, we will have non-indexable pages.
- Security: your progressive web app must have HTTPS. It’s also necessary to be able to install service workers on the user’s device, because it is the best way to ensure that a service worker’s JavaScript is coming from the domain that is launching the request, unadulterated by hackers.
- Indexability and linkability: PWAs must be indexable, in order to be discovered by search engines. And not only that, but you should also know that the Windows store is going to begin including indexed PWAs by the end of the year, to increase its app catalogue.
We do not know yet whether in the future we will see PWAs in other stores, such as Google Play or Apple’s App Store. However, if it does happen, Google Play is a more likely candidate, given that they are actively promoting PWAs and integrating them to Android, whilst Apple isn’t too big on free apps.
PWA intrinsic technological characteristics
- These apps are multi-platform, which means they can be ran on any device, whether it’s on Android, iOS, Windows Phone, or any other browser, which saves the cost of developing a website, plus an app for each operating system.
- Progressive Web Apps aren’t as fast for video games and other apps with a high computational cost (virtual reality, augmented reality, photo and video editing, etc.) as native apps are, but with the WebAssembly technology –currently in development– the difference won’t be as noticeable, because it will allow to run C or C++ compiled code client-side. In the following link you can see on Google Chrome a tank game made with WebAssembly and WebGL: Tank game made with WebAssembly
- They are apps, which, beside providing content, also have features we can see on any mobile application or even a desktop one. They can access the camera, mic, GPS, accelerometer, etc.
And finally, keep in mind that your website doesn’t need to get 100% on Lighthouse. To reach such a level of excellence is hard. Nevertheless, by just implementing some requirements from Google’s checklist we will already be able to notice an improvement in traffic; for example, through Push notifications, the possibility to add a shortcut to the home screen, and especially, functionalities concerning our website’s speed and user experience. With respect to the latter, it’s necessary to point out aspects concerning cache download with service workers and browsing with API Fetch or AJAX.
