Originally, the Web was used to host documents and organized in pages. A very large number of sites still meet this paradigm. Since the early 2000s, many sites have been enriched with JavaScript interactions to provide their visitors with usages that are closer to desktop application than editorial content. These web applications (or Web Apps) suffered from several defects related to the (lack of) possibilities offered by web browsers until then. Innovation, browsers publishers dynamism and Web dynamism in general could not keep this up … And that’s how and why the Progressive Web Apps were born.
The term Progressive Web App (abbreviated as PWA) is a term that has recently emerged in the field of Front End development. It defines a set of technologies and best practices that allow to adapt a provided web service to the user. To do so, it makes it accessible beyond the traditional limits of the browser and, particularly, but not only, under sub-optimal access conditions to the network (including off-line).
These innovations have the potential to completely change the way users take the Web and mobile applications up.
Here are some examples of Progressive Web Apps fromhttps://pwa.rocks/ :
- Wiki Offline (Jake Archibald) : an example of extending Wikipedia application with offline mode ;
- The Washington Post PWA : the PWA replatforming of the famous American newspaper, for more performance to serve a better reading experience ;
- Devdocs.io : resources and documentation for developers, accessible offline ;
- Pokedex.org : 650+ Pokémon repository, accessible offline.
Soon (we will talk about this later), the user will be able to install a PWA on his home screen, in the same way as an application (with data packaging, presence in the application list , Information about memory and battery consumption, etc.). These innovations have the potential to completely change the way users take the Web and mobile applications up.
It’s worth to take a look at it.
HOW IS IT POSSIBLE ?
PWAs are based on a set of things on which Web Apps are already based on :
- Responsive Web Design (RWD), of course, to adapt interfaces to all screens ;
- Web Services and Web Sockets provided by servers and which allow access to information or actions implementation via web actions ;
- Some API provided by browsers, which allow to take full advantage of the context (for example, we would have access to different APIs depending on the capabilities of the consulting hardware : audio, video, acceleration, geolocation, transcription, vibration, etc.).
However, they are distinguished by two recent technical components :
- Service Workers : this is a browser capability to provide an intermediate layer between the Web App and the network, which runs in the background (even when the application is closed). This “network” layer is capable of listening and sending requests, notifications or even capturing connectivity changes ;
- The Web Workers are also background capabilities but they are rather dedicated to calculations and “services” oriented development.
Progressive Web Apps are experiences that combine the best of the web with the best of apps.
“Your First Progressive Web App”, Google Developers Code Labs
HOW TO MAKE YOUR PROGRESSIVE WEB APPS A SUCCESS
There are a few key points to consider when you’re developing a progressive web application.
Instant loading
The application must be able to load quickly, regardless of network status. The network availability then becomes a progressive improvement :
- In very high-speed navigation : the web application displays a total and instantaneous synchronization with the server ;
- In low-speed navigation : the updating of external resources must not interfere with navigation ;
- In offline mode : the application must be accessible at least on the home page.
Speed
The application must work extremely smoothly, ideally as much as a desktop application interface. To this end, developers can rely on hardware acceleration in CSS, the requestAnimationFrame in JavaScript, resource optimization … and of course on the RWD if we want the PWA to display optimally on all terminals.
Security
HTTPS is mandatory in your PWAs to secure all exchanges between the browser and the server, and to allow the use of Service Workers. Unlike a native application where the user has no idea about securing data, it’s here the browser, a trusted component, that displays a green padlock, which is reassuring for the user.
The use of best practices
Best practices are more useful than ever. The OpQuast repository, which is not specific to the PWA, is an excellent working basis. Other tools will allow to specifically audit the PWAs context, such as Google Lighthouse.
Key considerations
Be careful to SEO and accessibility !
PWAs will be able to display data retrieved via the browser in JavaScript only if the browser is available. If this availability is not assured, an isomorphic code – that is to say, designed to be rendered on the server – will immediately display to the user a page already generated and will then improve it once JavaScript available. This solution is possible thanks to different technologies ; the most popular in the case of an isomorphic code is ReactJS[^react].
IDENTIFYING UPSTREAM CONSTRAINTS
Upstream, it’s important to consider three main constraints before starting.
PROPOSING THE PWA ON THE HOME SCREEN OF MOBILE DEVICES
It’s not easy to inform the user that the site is available as a PWA. Native mechanisms exist like Chrome for Android, for example. However, the browser will only propose to add the PWA on the homepage to the second visit of the user (five minutes must elapse between the two sessions). It will therefore be necessary to find other methods to warn the user of this possibility and make him want to use it.
A good way is to use push notifications that are accessible within the browser via an API. Be careful to stay subtle, because if you insist too much and send many notifications and emails, it won’t be efficient to retain the users. You should rather highlight the service provided by the PWA to convince them.
The heterogeneous support depending on the browsers
Safari under iOS does not support Services Workers because Apple defends its policy of promoting applications. This very important constraint can eliminate a number of PWA use cases. Safari will not propose the user to add the PWA to the home screen, but it is possible to “cheat”. To do so, it’ll detect the client-side browser and display how adding it to the iOS home screen. However, you need to be careful to detect any potential PWA installation in order to avoid proposing this procedure to a user who would have already followed it !
JavaScript APIs are not supported equally by all browsers. Luckily, with the dynamics initiated by the development of Firefox OS, the Mozilla browser has implemented a lot of APIs and Microsoft Edge is trying to [catch up with the competition] (https://developer.microsoft.com/en-us/microsoft-edge/platform/status/). As is so often the case, the site http://caniuse.com/ will remain a standard during the development, but we can also highlight [the good monitoring work of Jake Archibald] (https://jakearchibald.github.io/isserviceworkerready/ “Is Service Worker Ready ?”) on the subject.
Here are the support statuses of some functionalities depending on the implementation context :
| API | Google Chrome | Mozilla Firefox | Safari | Microsoft Edge | Internet explorer |
| Push API | yes | yes | no | no | no |
| Service Worker | yes | yes | no | no | no |
| File API | yes | yes | yes | yes | yes |
| Web Storage | yes | yes | yes | yes | yes |
| Geolocalisation | yes | yes | yes | yes | yes |
| Stream API | yes | yes | no | yes | no |
| Offline | yes | yes | yes | yes | yes |
### Storage constraints
The local storage space is limited, in different proportions depending on the browser concerned. If storage is a key component of your application, it may be necessary to consider other technical solutions.
WHAT’S THE GOOD TIME TO TAKE THE PLUNGE ?
The PWAs emergence is recent but the technological inputs are mature enough to deserve our interest :
- During a reflection around a mobile presence, against other types of developments (native, hybrid, etc.) ;
- As part of a policy of continuous improvement where the PWA can provide additional services to Web users who have browsers which can support it.
The service provided by your PWA will be determined according to your economic model, to the intended target and to the integration possibilities with your current platform. These services can do much more than the off-line availability which is today the simplest feature to put forward.
We embrace technological innovation at The Post, and any technology that allows us to offer a superior experience to our readers is a priority
Shailesh Prakash, Chief Product and Technology Officer for The Washington Post
The exemple of eCommerce
Let us take the case of an e-merchant. A PWA could enable him to offer new services to his customers. For example, it can allow to :
- Fill an offline basket. When the user finds a connection, the browser synchronizes this basket with the server by checking whether the products are available or not. The user is notified of this synchronization status and payment is then proposed to him.
- Consult at any time past orders, including invoices and remaining warranty periods for each product.
- On complex products : offer an off-line configurator, which can save a quotation request if necessary.
- Propose to a user who wanted a sold out product to notify him when it’s available again.
- Suggest to a user interested in a specific product to warn him during a promotion…
This list can be very long and many uses still have to be invented ! What services ideas would you have for your PWA ? Let’s talk about it !