Nitya Narasimhan, Ph.DWelcome to Day 2 of #30DaysOfPWA! New to the series? Three things you can do to catch up:
- Read the kickoff post below for context.
- Watch the GitHub Repository for updates.
- Bookmark #30DaysOfPWA Blog for resources.
This is a shortened version of this canonical post for the #30DaysOfPWA.
What We'll Cover Today
Today we'll deconstruct a PWA and look at the open web technologies that power it, and understand:
- What are the building blocks of a PWA?
- How does each contribute desired PWA behaviors?
- How can I check if my PWA models good practices?
We'll end each day with an exercise that you can do on your own, to help solidify what you learned. Ready? Let's go!
What are the Building Blocks of a PWA?
In our last post, we talked about how progressive enhancement was the key to scalable PWA experiences, and how open web technologies were the key to developing good PWA.
Today, let's dive into those technologies, starting with the three core building blocks for PWA development:
- HTTPS - makes your PWA secure.
- Service Workers - makes your PWA reliable and network-independent.
- Web App Manifest - makes your PWA installable.
Before we jump into details, let's do a couple of activities to set the stage. In our last exercise, we picked a sample PWA to use as a reference when exploring concepts. Open that in your browser now and have it ready. I'm using DevTools Tips as my sample PWA.
Task 1: Inspect your PWA!
Open the PWA in a browser and inspect it using your browser's Developer Tools - e.g., here is the guide for Microsoft Edge. Here's what I see when I inspect the DevTools Tips homepage:
This is a runtime dashboard for your PWA, with debugging and profiling tools you'll learn more in Week 3 when we discuss Developer Tools.
For now, familiarize yourself with these sidebar elements and keep this tab open in your browser:
- Application - with Manifest, Service Workers and Storage
- Storage - options including Local Storage, Session Storage, Indexed DB
- Cache - representing Cache Storage in browser
- Background Services - profiling panel to view/debug these activities.
Task 2: Audit your PWA!
Visit the PWABuilder site. Look for the Enter the URL to your PWA prompt, type in your PWA's URL (e.g., https://devtoolstips.org) and hit Start. In a few minutes, it should generate a report card that looks something like this:
This is an audit report for your PWA. It tells you how well your PWA meets "desirable characteristics" with a checklist of required (must-have), recommended (nice-to-have) and optional features. Our PWA has an excellent score!! We'll revisit this in Week 3 as well - for now, keep the tab open and let's move on.
Time to learn about: HTTPS, Service Workers and Web App Manifest!
1. HTTPS
HTTPS or HyperText Transfer Protocol Secure is a secure version of the HTTP protocol, encrypting end-to-end communications between client and server endpoints in your web app by default.
Progressive Web Apps must be served from an HTTPS endpoint to ensure secure communications, provide user privacy safeguards and guarantee content authenticity. HTTPS is mandatory for Service Workers - the core PWA technology required for reliable, offline-friendly operation.
Want to audit your PWA for security? Look at the _Security tab on the PWABuilder report. Here's what that looks like for the sample PWA:
Getting a good Security score is the simplest requirement to meet. Just publish your PWA to an HTTPS-enabled endpoint. You have two options:
- Use a hosting service that supports HTTPS by default. Cloud Providers like Azure offer options like Azure App Service that can help.
- Use your own hosting provider and create the required certificates using free services like Let's Encrypt.
Note that browsers, such as Microsoft Edge, will let you use http://localhost (non-HTTPS) to preview and test your PWA locally for debugging purposes only.
2. Service Workers
Service Workers are a special type of Web Worker, a JavaScript task that can run in the background (for asynchronous or long-running operations) without impacting the performance of the page.
Service Workers make your PWA reliable and network-independent, ensuring that it provides a usable experience under flaky network conditions or when device is offline (ex: Flight Mode). It achieves this with two key capabilities:
- Fetch API. Service Workers can intercept, modify and respond to all network requests from the application dynamically. They can listen for events indicating network changes, adapting their fetch responses based on the runtime conditions and app context.
- Cache API. Service Workers can access client-side Cache as well as asynchronous storage options (like IndexedDB) to proactively store resources for offline access or performance efficiency.
Let's see Service Workers in action with our sample PWA
Take a look at the Inspect tab that we opened in Task 1 - and click on the Service Workers tab.
- Check the Offline button, taking the browser offline.
- Revisit the DevTools Tips home page. You should be able to view it even though you are offline.
- Click an article. What happens? You may get the "You Are Offline" message if you have not visited it before.
- Uncheck the Offline button. Revisit the article (it loads) then check Offline again. You should be able to move between Home and Article pages and see them both offline.
That's the power of Fetch (interception) and Cache (storage) delivering a native-like experience (works offline) for the PWA!
Want to audit your PWA for Service Worker support? Look for the tab in the PWA Builder report. Here's what that looks like for DevTools Tips.
We see it meets the basic requirements (has a service worker) and implements some recommended and optional behaviors (works offline, uses periodic sync, uses background sync) for a better PWA experience.
We'll talk about Service Worker operations (scope, lifecycle) and caching strategies (for offline and performance needs) in a later post.
3. Web App Manifest
So we've made the PWA secure and ensured reliable, network-independent operation. But how do we make it installable like a native app?
That's where the Web Application Manifest comes in. It's a W3C Specification defining a JSON-based file format that provides developers with a centralized place to put metadata associated with apps.
From a PWA developer perspective, it's a 2-step process:
- Create your manifest.json file and associate it with your PWA by referencing it in the
headof your HTML page (see below). - Populate the file with required properties (for minimal PWA) and other recommended or optional properties (for a best-in class PWA experience).
<link rel="manifest" href="/manifest.json">
Let's see this in action with our sample PWA
Go back to the Inspect tab we opened in Task 1.
- Scan the
Elementstab - do you see the link in<head>? - Scan the
ApplicationsorNetworktab - do you see themanifest.jsonfile?
Here's what that looks like for DevTools Tips. Note that the dashboard also shows you currently populated Manifest properties grouped into categories (Identity, Presentation, Icons etc.) for convenience. We'll dive into the details in a future post.
Want to audit your PWA for Manifest support?
Look at your PWABuilder report from Task 2. Here's what that looks like for DevTools Tips:
The tool groups properties into Required, Recommended and Optional categories. Use it to prioritize and fix missing properties interactively to generate an updated manifest.json. Watch for Week 3: DevTools for more insights into this tool.
How does Web App Manifest support Installability?
It governs how the PWA looks and behaves when installed on your target device platform. It is used by the browser to determine that a website is an installable PWA - and to provide the relevant install experience to users. It also supports direct installs from app stores when you publish your PWA.
Summary
That was a lot to cover, but here are the core takeaways:
- PWAs use open web technologies to implement progressive-enhancement techniques in a cross-brower compatible way.
- Use HTTPS to ensure secure PWA operation. It is also mandatory for using Service Workers that provide reliable, offline experiences.
- Use Service Workers to intercept fetch requests and manage local cache and storage resources, enabling reliable PWA usage even when offline.
- Use Web App Manifest to describe relevant PWA properties for installability, enabling PWA to look and feel like native apps on devices.
- Use Developer Tools (e.g., Inspect) to explore runtime operation of a PWA and see how these technologies are used.
- Use Auditing Tools (e.g., PWABuilder) to validate PWA characteristics, and get actionable recommendations to make relevant fixes.
In our next post, we'll unpack the details of the Web App Manifest - but for now, try this exercise.
Exercise: Inspect & Audit your PWA
In the previous exercise, you selected a sample PWA and installed it in your local device (desktop or mobile). Today you'll open the app in a browser instead (I am using Microsoft Edge) and do the following tasks:
-
Inspect your PWA - e.g., using Microsoft Edge DevTools.
- Review the various Application tabs and sidebar sections.
- Interact with the app while inspecting it - what changes?
-
Audit your PWA - e.g., using PWA Builder.
- Review the report and recommendations.
- What differences did you see in this PWA's score & features?
- What incremental fix can you make to improve that score?
-
Reflect on your PWA
- What unique experiences does this app unlock by being a PWA?
- How does installed PWA experience differ from in-browser one?
Want to read more content from Microsoft technologists? Don't forget to follow Azure right here on dev.to:
