An Introduction to Progressive Web Apps

When the World Wide Web took off thirty years ago, websites were no more than simple, hypertext markup documents, without all the dynamic features we are used to these days.

Today, most of the website visitors use mobile devices. The web landscape has changed. One of WordPress’s main selling points in recent years has been its REST API, which has changed the way we consume content today.

Web and mobile applications have all but replaced HTML pages.

Introduction

While mobile apps have become one of the main ways to distribute content, mobile stores for Android or iPhone are proprietary marketplaces, which set their own rules for apps rankings and visibility.

Mobile Applications are Everywhere.

The entire functionality and processing can be local and applications generally do not require a constant internet connection. Mobile apps can store data on a user’s device. Additionally, they are not constrained by the browser environment and can offer a much more complete experience, both visually and in performance.

Mobile apps also make ongoing interactions with the user easier – once a browser is shut down, any web app opened in the browser will usually be “dead”, but a mobile app can keep running in the background, update its content with online requests for data, and alert the user as needed. In my opinion, mobile apps have a greater advantage because of the wide range of hardware and software level API from components such as NFC sensors, movement sensors, compass, Bluetooth, camera, haptic feedback notifications.

So far, the attempts to combine the advantages of both the worlds have resulted in hybrid mobile apps, with frameworks like Cordova, Adobe’s Phonegap SaaS building service, React Native by Facebook, and recently Flutter developed by Google.

Mobile devices have become more powerful than desktop PC-s from just a couple of years ago. One of the technologies that bring the performance of web applications close to the native apps is WebAssembly or Wasm.

WebAssembly makes it possible to compile languages like Go, Rust, C to be executed in visitors’ browsers.

Browsers have advanced to the point where web apps have access to several API and performance enhancements that open up the door or a new generation of applications.

What Are Progressive Web Apps?

Progressive Web Applications or PWA are web applications that blur the line between the web and mobile and native apps. They take advantage of the operating system API and can be used without internet connectivity.

Browsers have become application platforms in the last decade, giving PWA access to camera, geolocation, support for background jobs, and push notifications. HTML5 further opened up access to APIs such as localStorage and sessionStorage.

Web app manifests, a standard supported by most browsers, makes it possible to install PWA on mobile device home screens and enable fullscreen and standalone UI, removing all traces of the browser’s interface from these apps. These apps can be “pinned” to the taskbars similar to the native desktop programs.

Service workers make it possible to receive push messages from a server when the app is not active. If the users have permitted the app, the results can be displayed as push notifications. Also, these workers can cache files and data asynchronously, and the bulk of the app content available offline.

There has been an ongoing debate about what makes a web app “progressive”, and the origin of the definition of PWA. At the minimum, a web app must offer the following to be qualified as a PWA:

Web Manifest – A JSON file specifying the app name, author, version, list of resources, installation icons, description, and other details.

Service Worker – A javascript file that updates the app in the background and acts as an asynchronous HTTP proxy. Service workers can only work over encrypted connections, this brings us to the final requirement;

HTTPS Connection – the app needs to be served over an encrypted connection.

These are the “baseline requirements” and the list of popular PWA features includes:

Progressive Enhancement means that PWA works even in the browsers that don’t support the newest API. The application core content and features are made available and the advanced functionality is progressively added depending on the browser and connectivity. This creates a seamless user experience.

Responsiveness – The application renders and displays content, as intended regardless of the target device specifications.

Speed – As the introduction by Google states, PWA must be “reliably fast”, or, as another article puts it, they need to “start fast and stay fast”.

Shareability – They can be shared and installed via a link.

Installability – PWA can be installed like native applications. They can be packaged and added to app stores.

PWA needs to be discoverable – They are SEO friendly and can be scanned by search engines.

PWA (re)engage users – The apps use push notifications even when the app and the browser are closed (with proper user permission.

Self-Updating – PWA can seamlessly update both the content and application shell, without the user having to carry out any actions.

What are the Benefits of Progressive Web Applications?

While a progressive web application (PWA) is a very recent concept, its comprehensive capabilities have already been capitalized on by a growing number of companies. They combine website and mobile app capabilities that allow you to create an engaging user experience and increase user engagement and conversion rate.

Research demonstrates that PWAs provide numerous advantages to companies, such as:

• 68% of mobile traffic has been increased
• 15x improvement of load and installation speed
• 25x use of device storage reduced
• 52% average conversion-rate increased
• 78% average session time increased
• 137% engagement-rate increased
• 42.86% bounce rate reduced as compared to mobile websites
• 133.67% increased in page views

Cheaper than iOS and Android Apps

Since content has to be created only once, it saves time and money compared to producing content for iOS, Android, and a website separately. PWAs also don’t need to be updated (some find this feature especially cool). Users are not expected to download any new material. If a PWA works then you don’t have to think about its growth anymore. This makes PWAs a financially appealing option, as is the case with Flutter.

Boost for SEO

The contents in a PWA are included in the search results and thus contribute to the SEO improvement. Checking how your PWA performs in the search results can be achieved — with Google Tools. Protection (do you use https?) and the loading time of a PWA are significant considerations here. Add to that the content must be unique and appropriate, as is often the case with SEO. Now that many services and products are being found online, SEO is becoming ever more important.

Improved Page-Speed

When upgrading to a PWA you have to offer a full overhaul of your website. This ensures that you don’t just get the advantages of caching service workers you can remove scare tissue that slows down your site

The purpose is to be responsive to any computer and network form within 3 seconds. Without caring for the impact on user interface and speed, all applications slow down over time as features are clamped on.

You can make your website a speed demon by updating to best practices, thereby giving you a strong edge over your competition. And when the visitor returns your cached assets reduce latencies in the network, boosting your average time to the first byte, making loading of your pages smoother.

Low Storage Usage

There is a fight going on for a spot on the devices. It’s also becoming increasingly hard for native apps to secure a place in users’ lives. Hence, it is an advantage that PWAs do not have a high threshold for use. First of all, the threshold is very low as there is no need to download any new app. Thus your target audience is free to test the app. They can also use the app offline. Which makes validating your business model the ideal solution for an MVP. It also takes up less memory than native apps, which is a primary consideration for a user at times.

Offline Operations

The ability to function offline or in compromised networks makes PWAs much more convenient than websites that require a proper connection to the Internet. Built-in service workers automatically archive essential features and information from the progressive web applications, removing the need to download it and allowing users to use it without an internet connection.

It is based, for example, on the saving of information that users have previously viewed pages. If they’re trying to open those they haven’t been to online, an app will view a custom offline tab. This functionality is important for retailers as it helps consumers to stop leaving their catalogs and increases customer retention.

Independent of App Stores

You will find PWAs over a search engine and other sites. You may also be able to offer a PWA via a social media site, home page, or another element of your ecosystem. You’re not reliant on app stores anymore. Yet app stores have the advantage of being able to hit a large audience in one go.

Successful Use-Case of Progressive Web Apps

Let’s try to answer this by a case study of one of the most popular progressive web apps:

Twitter

In 2017, Twitter came up with its Progressive Web Application – Twitter Lite. Twitter Lite is a packaged version of Twitter’s PWA, available at mobile app stores. ln addition, the web (desktop) version of Twitter is progressive. When audited with the Lighthouse tool, Twitter appears to hit all the PWA requirements:

Twitter’s PWA can be installed either from app stores such as Google Play Store or directly from the web. When users visit Twitter via a web browser, the menu in the upper right corner has the option of installing Twitter.

Similarly, in the mobile version, there is a prompt to install the Twitter app.

So, what did Twitter achieve with it’s PWA?

Smaller size:

During the first time app load or “installation” the PWA simply needs to download the web app “shell”, a process often equivalent to a website load. In Twitter’s case, Twitter Lite takes up almost twenty times less space on a mobile device than the native application (1.1MB vs 19MB).

Memory Footprint

The idea behind Twitter Lite is to make Twitter accessible to devices with a 2G connection and 1GB of RAM. As a result, one of the goals of Twitter PWA is to have a very small memory footprint.

Twitter Lite initially lacked features such as draft updates, but it has been quickly catching up with the native app (adding the dark mode, and multiple accounts feature). Despite this, the application has a snappy feel. Patrick Traughber, in his post announcing Twitter Lite, claimed: “up to 30% faster launch times as well as quicker navigation throughout Twitter”.

Data Usage

In addition to a small installation footprint and optimized media files, Twitter Lite also has a data saver mode, in which the user has control over when to download media files. Scrolling through the timeline can use as much as 70% less data compared to the native app.

Optimized loading with Service Workers

Service Workers for the Twitter Lite PWA load and cache static resources of the app shell, but also cache current content.

In the background, service workers preload resources for navigating to other screens. This way, when visitors navigate to other screens, it is seemingly instant. After the initial load, the app only needs to request for new updates, simply consuming JSON from the server.

Simplified Installation

PWA can be installed from the browser’s “Add To Homescreen” prompt. There is no need to separately visit the app store, or even to have an app store account. It has been proven that the number of steps involved in installing an app directly reflects on conversions.

User Engagement

“Add to Homescreen” prompt and push notifications have significantly increased user engagement. According to estimates, Twitter Lite delivers around 10M notifications a month and sees 250Kunique users launch the app four times a day.

All the advantages of Twitter’s PWA app translate to 65% more pages per session, 75% more Tweets sent, and 20% decreased bounce rate.

Since 2017 (when Twitter Lite was first published), PWA has become the standard for the mobile web. Since implementing it is not difficult or restricted to just big players like Twitter, almost anyone can build a PWA for their project.

What do You Need to Build a Progressive Web Application?

The three baseline requirements that determine whether a website or web app is a PWA are:

• a web manifest,
• a service worker
• a safe connection.

HTTPS Connection

Progressive Web Application needs to be secure – browsers don’t tolerate unsecured HTTP anymore and will warn website visitors that the connection is “unsafe”. Further, an encrypted connection is a prerequisite for functioning service workers, and for HTTP/2 – a performance-enhancing HTTP standard. HTTPS assures visitors that there has been no domain spoofing or MITM (man-in-the-middle) attack. There is no PWA without HTTPS encryption.

Many hosting providers these days offer support for both free and paid SSL certificates. In the Cloudways dashboard, setting up an SSL certificate takes only minutes, after which users can set up domain records with the domain registrar/service provider.

Web Manifest Specs

Web Manifest specifics can be found in the W3C working draft. It is a JSON document with details of the PWA, such as

• application name,
• author,
• icons for installed PWA,
• description
• display (fullscreen, standalone, or with minimal UI, etc)
• Service worker (the path to JavaScript file)
• orientation
• start_url

Mozilla website contains detailed documentation about every possible key.

To create a web manifest, go to PWABuilder, fill in the website URL and related fields, and the generator will create a web manifest.

Copy the code into a JSON file, add it to the website root and add a link tag to the <head> section of the website.

Role of the Service Worker

Service workers perform several tasks that add to the performance of the PWA.

In particular, these workers preload website resources in the background. This includes other pages on the website and the assets required to render these pages. Service workers can then cache these assets so they don’t need to be fetched on subsequent visits.

Service workers can define the offline user experience – from a custom “splash” page to pages with content or functionality.

They can intercept requests for certain static resources and provide another version – from providing a cached version of content or files when there is no connectivity, to replacing requests for regular images with alternative, smaller image sizes or file formats.

Mozilla published a Service Worker Cookbook that provides detailed recipes on caching strategies, push notifications, offline fallback, etc. Also, to create an ideal application, one must look for app developers for hire.

Service workers are a version of web (JavaScript) workers – they work in a background browser thread, without blocking the rendering of the web page. They don’t slow down the visitor’s experience.

The flip side of this is that service workers do not have direct access to the web page and they communicate with the website via messages.

Workbox is an open-source project that provides a set of javascript tools and libraries to help with adding service-workers to web pages. This tool is made by Google’s Chrome team and is used by Forbes, Tinder, Pinterest, Wired, and others.

One open-source project – a set of javascript tools and libraries to help with adding service-workers to web pages is.

To use Workbox locally, install it with npm:

npm install -g workbox-cli

PWAbuilder is another tool that can help you with web manifest, service workers, and related areas. I prefer the online version, but it can be installed via npm.

Stop Wasting Time on Servers

Cloudways handle server management for you so you can focus on creating great apps and keeping your clients happy.

Start Free

Bootstrapping the PWA

For this guide, I will implement PWA on a generic Laravel v6.0 application.

I will clone the application using Rsync to a local machine, using application credentials:

rsync -avzh username@ip-address:~/public_html/ ./

(I will use the bash shell, either through WSL or natively in Linux or macOS). I can, optionally, set up the app on GitHub and set up git deployment for a smoother workflow. I will need to set up the domain, point the A records to the Cloudways server IP.

All this should result in a standard Laravel splash screen, depending on the domain changes propagation:

Installing an SSL certificate

Encryption is one of the prerequisites of PWA, so I need a valid SSL certificate. Cloudways makes this easy by automating the process of installing a LetsEncrypt free SSL certificate or adding a paid SSL certificate.

Next, I will go to PWAbuilder to audit the website and create a web manifest and service worker.

Provided that the SSL certificate was installed correctly, the results should look something like this:

Web Manifest

Click the View Generated Manifest link in the first box and edit the values such as name, description, URL, start_url, display, and other settings. I will also generate icons for the PWA. The manifest.json would look something like:

{
    "dir": "ltr",
    "lang": "en",
    "name": "Laravel",
    "scope": "/",
    "display": "standalone",
    "start_url": "https://my-website.xyz/",
    "short_name": "Laravel",
    "theme_color": "transparent",
    "description": "Laravel PWA starter",
    "orientation": "any",
    "background_color": "transparent",
    "related_applications": [],
    "prefer_related_applications": false,
    "icons": [
        {
            "src": "/pwa-icons/68c2974a-df22-c19c-03f4-e17b57e291b3.webPlatform.png",
            "sizes": "44x44",
            "type": "image/png"
        },
   
        {
            "src": "/pwa-icons/a0691dfd-df30-98f1-49d0-3acb4016239b.webPlatform.png",
            "sizes": "76x76",
            "type": "image/png"
        }
    ],
    "url": "https://my-website.xyz/",
    "screenshots": []
}

As you can see, the application is named Laravel (but it could be anything you like). Also, note that the icons array only has two entries; however, the actual files could contain multiple files. The directory for icons has been changed to /PWA-icons.

Following the PWAbuilder instructions, I will add the following snippet to include web manifest and polyfill in the HTML:

<link rel='manifest' href='/manifest.json'>
<script src="/manup.js"></script>

Normally I would add this to an actual layout template, in the <head> section, but for the sake of brevity, I have put it in the head of the default Laravel start screen template, welcome.blade.php in the app root /resources/views/ directory.

Service Worker

Click the Choose a Service Worker link for the service worker generator. I can pick the type of service worker required and PWAbuilder will generate the code. I will then save the code in the pwabuilder-sw.js file in the website root.

PWAbuilder will also generate the registration/initialization code for the service worker, which I will put inside the <script type=”module”> tag before the closing <body> tag.

This approach relies on Workbox for the entire service worker’s lifecycle. You can find more details on all the ways you can use

Workbox to create more advanced workers here. If you want to keep things simple and create your workers from scratch, start with this tutorial.

Deploying the PWA to Cloudways Managed Servers

With more complex Laravel applications, I can use Laravel Mix to compile and organize the static assets, but for the sake of this project, I have put the static resources directly into the root /public/ directory, so that the directory content looks something like this:

├── css
│   └── app.css
├── favicon.ico
├── index.php
├── js
│   └── app.js
├── manifest.json
├── manup.js
├── pwabuilder-sw.js
├── pwa-icons
│   ├── 02bc8afd-4fd5-83ba-e085-93093e10cb59.webPlatform.png
│   └── edfdf472-be1b-f0b7-c89b-a69971941a20.webPlatform.png
├── robots.txt
└── web.config

Once done, I would commit and push the app to GitHub, and deploy it to the server through the Deployment Via Git option in the Cloudways dashboard:

If everything goes well, I could see a working (although minimal looking) PWA live.

Testing And Diagnostics

When it comes to testing and diagnosing issues with PWA, I can use several tools to make the process easier. The most popular tool is Google Chrome’s devtools.

Open the tool and switch to the Applications tab that offers more insights into the web manifest and service workers.

I can stop, start, unregister or update service workers, see their current state, and test sending push messages:

The Applications tab also offers further PWA-specific details, from the cache to localStorage and sessionStorage, and push messages. Chrome offers a host of tools that provide deeper insights into website encryption and the validity of the certificates.

The Security tab in the Chrome devtools provides information about website encryption:

Finally, Lighthouse, a browser plugin from Google simplifies the ability to audit website performance, including all the PWA standards/requirements:

The PWA Experience

If the installation was successful and the application passed all the tests, I should be able to load the website/PWA in a mobile browser and see the app in action.

I will be prompted to install the app on the phone.

When I open the installed application, it will load the splash screen (even when the phone is offline). The app will take the fullscreen without any browser bezels and the address bar.

In other words, the result will be a user experience very much like a native app:

In this guide, I used a minimal, proof-of-concept service worker; however, service workers can do a lot more. Workbox offers a list of common service workers that carry out caching of static resources, caching content from different origins, or restricting caches from specific origins, caching based on the resource type. There are more advanced uses, like offering custom static pages for a range of scenarios, with prompt to users to reload their app. I can warm user cache with different resources; provide fallback page versions for offline situations, with sophisticated fallback scenarios; I can cache audio and video media assets.

I can even enable offline Google Analytics. Workbox offers several packages that get all of the above and more done.

Summary

In this article, I introduced Progressive Web Applications, explaining the three minimal technical requirements, and then went over all the advantages gained by making the website, or the web application, progressive.

I started with a generic Cloudways Laravel application and implemented all three PWA requirements. The process was simplified with the help of tools such as PWAbuilder and Workbox.

Once implemented, the PWA was tested using Chrome’s devtools, and Lighthouse, a Chrome extension that audits website PWA elements, such as web manifest, service workers, and its features, etc.

There is much more that you can do with PWA, and I hope this guide will help readers implement more PWA features in their apps.

Do you have anything to add to this guide? Let us know in the comments.