What are Progressive Web Apps and how do they work?

Introduction


What are they?


Picture these scenarios: you’re sitting on the train browsing through your favourite website very
happily, only for you to go through a tunnel and your connection goes down and you frustratingly
lose where you were. Or imagine you’re looking at your mobile and notice all the unnecessary
apps you’ve downloaded when ordering in a pub or restaurant you went to once, but haven’t
visited since. Or picture yourself simply sitting at home with a good broadband connection, but
are still waiting for what seems like an eternity for a website just to load its content.


Q: What can all these annoying scenarios be solved by?


A: Well… Progessvie Web Apps!


So, what exactly are ‘Progressive Web Apps’ or ‘PWAs’? Essentially, they are web applications
that have been developed using progressive enhancement to create a native-app like
experience for the user. Or, in other words, they are web apps that have extra functionality to
make them comparable to native-apps, but offer the same benefits as a traditional web
application. Here’s a nice and succinct description of PWAs by Sam Richard and Pete LePage:


Progressive Web Apps allow what you build to be installed by anyone, anywhere, on
any device with a single codebase.”
(taken from Web Dev: What are PWAs?)

This has a number of benefits, both for the user and the developers. For example, being
written in a single codebase makes updating or debugging the code much easier, less
error-prone and less laborious. This is as opposed to having to build a separate app for
desktop, iOS, and Android for example, which can also save a huge amount of money
in the development process as well.


Some of the many other features of Progressive Web Apps include:


Findability – meaning that unlike a native-app, they can be found via a search
engine just like any other site

Downloadable – unlike most web applications, you can install a PWA onto your
home/ dock screen on mobile or desktop, making it look and feel like a naitve
app


Shareable – unlike a native-app, you can share a PWA via its URL, which is a key
feature for collaborative online applications like Figma


Offline capabilities – unlike most web applications, PWAs can be used offline or
with poor network connection


Progressively enhanced – PWAs degrade gracefully from their highest
functionality and capabilities on the browsers that support it, down to their core
content on older browsers


Responsive – PWAs are responsively designed and can therefore be used on any
sized screen, from mobile to large projectors


Re-engageable – meaning they can send push notifications and other updates,
similar to a native-app


Encrypted – PWAs should run on HTTPS, rather than HTTP due to security
issues. This added layer of encryption makes them more secure

Taken from  Web Dev: What are PWAs? (March 10 2022)

Other benefits of PWAs are that they are usually much lighter than a native app and take up less disk space on your device, saving your precious storage space. The fact they are re-engageable also means that the application can be auto-updated, rather than having to reinstall an app which often is the case with native apps. Site speed is another hugely important aspect when developing a web application; fortunately, Progressive Web Apps can massively improve the speed of sites too. They can do this by caching information to be used when the site next loads, which saves having to request data from the server each time you use the page. 

So, how do they actually work?  

Alongside using HTML, CSS and JavaScript, PWAs also use a type of web worker (a JavaScript file that runs in the background of the page) which sets them apart from a traditional web app. Usually when you execute a script in your HTML, the page will not become responsive again until the script is finished running completely. This is where the web workers have an advantage, as they run in the background independently, so you can continue using the functionality of the site without the web worker getting in the way of things. 


The type of web worker PWAs use is known as a service worker, a script that can control and cache content to be used later on. A service worker is often used alongside the cache API, which can cache the information and store it for later use. Whereas ordinarily the application would send requests directly to the server, the service worker acts as a sort of ‘middleman’, intercepting and saving the information using the cache API. This means that on the users’ next visit, the stored cache can be sent back to the browser from the service worker to increase site speed by preloading information, or makes it usable offline or in poor network conditions.

Image taken from Caching in a PWA: When to use Optimistic vs Pessimistic

(March 10 2022)

Now, you may be thinking: ‘these sound great, how can I build one myself?’ If so, let’s take a look at how you can create your own PWA.

Building a PWA from scratch 

After going through some of the basic information regarding PWA’s functionality, I decided to build one myself using a simple site. Like most people nowadays, I started with some online step-by-step guides and several youtube tutorials. Despite having tons of information available, I failed to make my demo site function by copying and pasting the code they put on it, so I changed my strategy – trying to understand most lines of code I came across and to build one from the beginning. The following section will include more technical aspects of PWA, in hope of helping those who would like to start exploring PWA like me. You can always check out the source code here: https://github.com/C45p4r/ma_web_design/tree/master/pwa-test   

1. Creating a simple file structure


pwa-test\

    index.html            // basic html file

    manifest.json        // specify basic metadata for pwa

    sw.js                // service worker

    src\               // folder with external css and js

        style.css   

        main.js

    images\            // folder with graphics (esp icons)

        …   


Except for the index.html and the style.css file you are all familiar with, there are two files essential for transforming your website into a PWA, namely manifest.json and the sw.js (ServiceWorker.js). The manifest.json file contains all the metadata which states the names, colors, and icons to be used by the operating system, while the sw.js is there to cache and fetch data from the server after main.js checks and confirms the service worker is available on the user’s device. The JavaScript responsible for the service worker should always be placed in the root directory of your intended web application, as the service worker can only cache files that lie on the same directory level or ones that are below it. 

2. Checking the requirement for creating a PWA

        Currently, Chrome is the most reliable browser for creating and testing PWAs as it supports almost all the functionality for popular operating systems (except iOS) and also provides the Lighthouse audit tool for us to keep track of our progress when working with PWAs. 

Screenshot of the Lighthouse tool on Chrome

The requirements for creating a PWA

As you can see from the screenshots above, the Lighthouse tool has listed all the requirements including two essential elements that define a PWA – the web app manifest and the service worker.

3. Manifest.json

The manifest contains all the properties and values describing what and how the web application should be displayed across different operating systems.  I chose to put up some of the basic properties just for the demo purpose.  I specified the scope of the PWA starts from the root directory by setting the start_url value to “.” (line 4), and choosing the “standalone” display method (line 7) to give a more native-app feeling to the PWA.  After completing the manifest, you can link your page to the manifest by using the <link> tag: e.g.<link rel=”manifest” href=”manifest.json”>.

    manifest.json

4. Service Worker

        After satisfying the first requirement, we have to check and run the service worker allowing users to install and cache resources in the background. First, we perform a simple check, ensuring that the service worker is supported by both the browser and the OS, thus registering it. It can be done by the following lines I have included in main.js

    main.js

If the service worker is available on the end-user side, the main.js will take us to the sw.js. The first part of the script (line 1-7) is there to create new cache storage called “static”, then adds all the files specified on line 4 to it. In my case, I have cached the only web page along with the stylesheet and icons. This allows the content of the page to be reachable (after the cache is established) even if the user has lost their network connection. The second part (line 9-16) is an event listener for fetch requests, combining the two pieces, the PWA is ready for users to install like a native app and view cached content without a stable internet.

sw.js

5. Testing stage

        As the webpage had already checked all the boxes on the Lighthouse audit, it is ready to be installed and tested on different devices.  It works perfectly for me on my Windows 10 laptop and Android mobile by using Chrome, the PWA has stimulated a native app experience on both devices and remains usable without internet connection.

Useful tools 

    You can always refer to the application panel of the developer tool from time to time.  First, you can find all the details about the manifest you linked with the webpage.  Second, you can check the status of the service worker (always choose to “skip waiting” after you have made changes to the service worker script).  Third, you can check whether the service worker has cached all the files as intended or not.  You can also check how the PWA performs without any internet connection by changing the network to “offline” in the network panel.

The application panel (developer tool)   

Apart from the panel above, we should also make use of the log method in Javascript to write useful messages to the log.  For example, I have included a console.log method in main.js (line 3,4,7), the first two lines specify messages to be displayed when the service worker is successfully registered and the last one when it doesn’t.  These useful responses from the console are also useful toolkit when dealing with Javascript, the image below show the exact message that came up on the console once my service worker is registered successfully:

Console log record 

The PWA I have built is just based on a simple single-page website without navigation and much content to be cached, so what if we would like to convert a larger website into a PWA?  I have the same question echoing in my mind after completing the demo, and the answer is to do it similarly but search for a more suitable website architecture for your site.  There are currently four approaches to build a PWA, that are service-side rendering (SSR), Client-side rendering (CSR), the “App Shell” approach, and the use of streams API (experimental stage).  In plain english, the way when and how the data would be cached and available to the end-users.  Without causing more confusion for new learners, I have organized some of the main pros and cons of those four methods into a table:

Methods \ PropertiesSSRCSRApp Shell (mixing SSR and CSR)Streams API
Pros– Faster first load
– Works great across different browsers
– Website will be updated almost at the moment when user navigating through different pages– Reliable performance and fast loading speed for re-visit
– Native-like interaction- less data usage
– Grant direct access to developers over data streaming from the server
– provides fine-grained control on data streaming
Cons– Navigating between pages requires downloading new HTML content– Requires more initial download
– Extra time for rendering for the first visit
– more complex
– some browser have limited support
Note– General perceived performance– Separate content from navigation

And there are a few graphics showing how exactly these methods works on devices:

Server-side rendering method

Client-side rendering method

The app shell model

The use of streams API

The app shell model is the most popular practice right now without a doubt, as the method aims to combine SSR and CSR and create a faster and more reliable experience for users.  It will only re-render part of the page with changes, more economical use of network data.   It is often deployed on large-scale websites.  As for the streams API method, it has more use cases on video streaming platforms as the performing operation (e.g. adding a filter to a video) on data and updating it instantly without waiting for all the data to be downloaded.  These concepts are still quite confusing for me sometimes, do look it up online for more in-depth information if you are interested in building a more solid PWA.

My thoughts on PWAs

    I did encounter some difficulties while preparing the demo for the presentation, but overall I think it is quite easy to transform your website to a PWA.  I believe that PWAs are becoming the future of both web and apps as it provides a seamless experience for users with different devices.  The PWA can be accessed by users with just a URL through browsers without taking up internal storage space like traditional native apps, and it also provides app-like features such as offline mode, push notifications, image and video capture, geolocation, etc.  However, the PWA is still not widely supported as much of its functionality is restricted on certain platforms and browsers.

We hope this has given you a better understanding of PWAs and the possibilities that they offer in the future of the web. If you’d like to learn more about PWAs, we’ve linked some useful articles down below:

Progressive Web Apps will replace your Native Apps

Learn All About PWAs

Web Dev: What are PWAs?

Making PWAs work offline with Service Workers

PWAs & Service Workers

Service Workers & the Cache Storage API

Overview of PWAs

Getting Started with Progressive Web Apps

Web Workers

Caching in a PWA: When to use Optimistic vs Pessimistic

Service Workers

Cache API

And some useful tools for testing PWAs: 

Lighthouse

SEO Checker,

SEO Review Checker  

Browserstack

Thanks for reading! If you have any comments at all, please let us know 🙂

Leave a Comment