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:
● 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
● 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?
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
index.html // basic html file
manifest.json // specify basic metadata for pwa
sw.js // service worker
src\ // folder with external css and js
images\ // folder with graphics (esp icons)
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.
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”>.
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.
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.
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.
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)
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 \ Properties||SSR||CSR||App 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:
And some useful tools for testing PWAs:
Thanks for reading! If you have any comments at all, please let us know 🙂