What is a Progressive Web App (PWA)? A Starting Guide

Even if you haven't heard about PWAs or do not know what a PWA is this, this article should provide a thorough introduction. By the end you will know how you can upgrade your existing sites and how to sell the concept to your team and stakeholders.

These apps aren't packaged and deployed through stores, they're just websites that took all the right vitamins... They progressively become ‘apps'.

Alex Russell>

With this statement Alex Russell created a movement that provides a name to web user experience best practices and a new round of platform features delivered by browsers.

Alex is the guy who created the term progressive web app and works for the Google Chrome team. He and others are working hard to build the specifications and infrastructure so we can create great web based user experiences.

So what are progressive web apps? What do you need to know and implement to be a progressive web app?

Any web site can implement these requirements in a matter of minutes.

I can add a free SSL certificate to my sites in less than 30 seconds today, thanks to AWS. There are many free and easy ways to add HTTPS to sites today, like Let's Encrypt.

If I don't feel like coding a web manifest file and creating the application icons set I just visit my PWA Starter. In less than a minute I can scaffold a manifest file, application images and a starter service worker.

I can implement all these enhancements without affecting anything on an existing site. This means any site could be upgraded to a PWA in a matter of minutes.

As consumers have abandoned the desktop for mobile the demands on user experience have changed. Devices are not as powerful, screens are smaller and bandwidth is unreliable.

According to Luke Wroblewski we passed the mobile moment sometime in 2011. This is where more active users are mobile than desktops. At that moment the game changed for developers.

We had to stop trying to deliver great desktop experiences and start delivering great experiences for any device and any connectivity scenario. Yet the best practices were not designed for these constraints.

And here's the thing....mobile first requires a very different approach than the desktop first approach we cultivated over the web's first 20 years.

Twitter is not alone. Starbucks, Uber, Lyft, Forbes, Trivago and thousands of other well known brands, worldwide are adopting progressive web applications. Each one reporting improved user engagement numbers. More time on site, increased sales and all testify their site speed has improved.

The reason why is progressive web applications provide better user experiences.

Everything you learn about PWAs should lead you to a higher level of user experience. This is because Google, Microsoft, Mozilla, Samsung and other platform vendors all know the way to win in the digital world is to provide better user experience.

Progressive web app is more a marketing term than a single technology. PWA is a term created by the Google Chrome team to describe websites that meet three key technical criteria and a collection of somewhat arbitrary levels of good user experience implementation.

What are the technical criteria?

A site must be HTTPS or secure. The site must have a valid web manifest file. The web site also needs a service worker.

Each of these three requirements are simple to implement and can be added to any existing web site without disrupting the current user experience or technology stack.

But that is just the minimum, technical requirements. To truly be a progressive web application you must be fast, reliable, integrated and engaging. Each of these concepts is relative.

I like to say it this way: be fast, make the network optional and provide real value your customers need.

As engineers, progressive web application philosophy pushes us to a better state of user experience. This means your customers are happier and more likely to engage and buy from your business. Internally it means your co-workers will be more productive and happy.

Not Limited to a Single Browser

Even though the Chrome engineers are credited with birthing the concept of progressive web applications, PWAs are not limited to Chrome or Android. I have already covered how Microsoft is pushing progressive web apps, but so are other browsers.

FireFox recently shipped their first 'add to homescreen' experience. They have expressed enthusiasm for several years. Speaking at several Google conferences and providing reference code. They shipped service worker support several versions back and have since added support for more features. They should soon land background sync support.

Opera and Samsung Internet have also been very active in the PWA community. Samsung has a very popular browser due to the popularity of their phones. To demonstrate their enthusiasm they have created a highly active developer advocate program that regularly shares progressive web application resources.

Recently the Apple released an update to Safari supporting service workers on iPhones and iPads. This release was important because it enabled progressive web apps available to the vast iOS community.

At the moment, the Windows RedStone 4 update is about to become available to the general consumer and enterprises. Edge 17 is the most current version, and has service worker support on by default, including native push notifications.

This means every major browser vendor is promoting progressive web application technology.

You may ask why?

They all want the same thing. For the web to win. When the web wins, they win and so do you.

They know what makes the web win, great user experience. And believe me, they have the data to know what works online. They use this knowledge to offer best practices. Progressive web apps are the codified product of those best practices for you to follow.

Key User Experience Factors

There are three key user experience factors you need to understand about progressive web apps.

First, they are fast. I cannot emphasize enough how much speed matters to customers. They vote with their fingers by leaving slow sites. This affects your overall brand quality, search engine rankings and other important key performance indicators.

Let's be frank. Human psychology tells there is less than one second before the mind disengages from a sluggish experience. At that point we drift to the next thing. By 3 seconds half the visitors to a page have left.

Factor in slow 3G connectivity and we, developers and devops, have our work cut out for us. It is more than just the initial HTML loading in the browser, it is the combination of everything that makes web performance a feature or the end of your brand.

If your development team does not embrace fundamental principle of front-end performance they are costing your company profits.

Love2Dev is passionate about about web performance. We have dedicated the past decade building high-performance websites. We know how to architect sites to load and react fast to user expectations.

Performance is more than the initial load time. That initial load time, or time to first byte typically accounts for less than 10% of your time to first interaction, a more meaningful performance metric.

The 90-95% after the initial content is loaded is due to poor front-end architecture. There are literally thousands of big and small items you could audit for performance improvements.

Start with eliminating unused scripts and CSS. These account for the majority of performance bottlenecks.

Use a server that supports HTTP/2. This serves content faster and more efficiently than HTTP/1. Most content delivery networks now support HTTP/2.

Use a CDN to get your content closer to the customer. They have become a cheap commodity that every site can afford.

Optimize images for responsive design and mobile networks.

After these high level tasks start identifying where your pages produce jank and hesitations due to CPU overloads.

Finally, add a service worker to your site and cache your server resources on the client device. This eliminates network traffic and enables your site to work reliably offline.

Reliably Working When the Network Fails

Progressive web apps need to be reliable. A common problem the web has suffered is the perception it is not reliable. A big part of that mis-perception comes from the ability to work off-line.

Progressive web apps can start faster and work even if there is no internet connection when you use a service worker with a proper caching strategy. This can be advantageous because you can eliminate network requests and of course the need for a connection when you application needs to run.

Today the majority of traffic originates on mobile devices, or smart phones. Much of that traffic uses cellular or GPRS connections. Despite modern connectivity advancements, cellular networks are notoriously unreliable.

This puts web sites, and native apps, in a precarious position. You need to maintain a good user experience at all times. Native apps have enjoyed a slight advantage because they are installed on the device.

While we have been able to make the web work offline for about a decade, it has not been pretty. AppCache was the first attempt at a standardized way to enable offline web experiences. Thankfully this specification is heading for the trash bin in the cloud.

Service worker caching is a brand new way to manage assets locally to provide a rich offline experience. Unlike its predecessor, you have detailed control over how your site's assets are persisted. You can also better control how the sites works when offline or when the network is unreliable.

This does not mean your entire website can or should be cached in the browser. Many sites can because they are small. But many sites are still dynamic.

This means the content is rendered at run-time or when the URL is requested. Take the Twitter Lite example.

Tweets are submitted non-stop, which means your tweet stream needs to update constantly. If your device is not connected you won't get the latest tweets. Instead your tweet stream becomes static, until the network is reachable.

However, a large e-commerce site like Amazon is different. Each product page uses roughly the same layout or template to render content. In this scenario, product content could be persisted for a period of time after the user has loaded the product information.

If the customer goes offline the previously loaded content could be rendered, quickly no matter the network connectivity. For new product pages a placeholder could be served, informing the user of their connectivity state.

There are roughly two dozen caching patterns we have identified over the past decade. I teach those patterns in our new course, Progressive Web Apps: Beginner to Expert. I cover basic to advanced caching patterns and how to apply them in a 'real-world' application.

Advances in browser caching technology changes this story. Now you can architect your web site to provide a great offline experience. Progressive Web Apps take advantage of this caching mechanism to provide a rich offline experience.

Its not just about making your web site work offline its about making sure your web site works reliably. When you can minimize dependence on something notoriously unreliable your user experience gets better. When your UX improves your customers are happier and your business improves.

Taking User Engagement to the Next Level

PWAs need to be engaging. This means they need to have deep user experience engagement features. Once you implement these deep engagement features you can earn on place the users home screen.

One of these features is native push notifications. Push notifications have been nearly impossible to execute via the browser.

Push is one of the top feature requests clients have made over the years we simply could not deliver. This story is changing as different browsers are delivering native push notification support.

Integrating native push notifications can now be done from different browsers across different platforms. You just need to stand up a push server or use a standards compliant push service.

Research shows that while push notifications are considered annoying, they work. Customers engage with brands at alarming rates to compared to brands that don't use push.

The Web is Discoverable

App stores are deeply tied to the platform; iOS, Android or Windows. More over the search or discover-ability of these stores is poor. Often the case for viral growth is 'knowing someone on the inside'.

There are no pay per click programs or good SEO patterns to follow. It is mostly luck and of course advertising to your app's web page.

The web does not suffer from these issues. Today we have strong search engines; Google, YouTube, Bing, Alibaba, etc.

A whole class of marketing services thrives helping businesses gain exposure in these engines.

Much of search engine exposure comes down to creating good content and user experience. The rest takes care of itself.

This is much harder with native apps.

Like I mentioned before I can drive traffic to these blog posts for as little as $0.005 per visitor. From there a well crafted funnel can create the relationship I want with you, the reader.

Being Secure Be Default

The typical website does not implement SSL. Today that story is changing. As browsers increase the pressure for sites to be secure by default, HTTPS implementations are on the rise.

Pages served via HTTP now have visuals meant to warn consumers the page may put them at risk.

Search engines include HTTPS as a ranking signal.

Why? Consumers trust sites using HTTPS more than sites that don't.

Event if they are not submitting credit card or personal data, knowing the connection is secure makes them feel safer.

In the past, there have been numerous barriers keeping the average site from using SSL. That has changed in recent years as costs and technical requirements have been removed.

To qualify as a PWA you need to be HTTPS. This stands for stands for hypertext transport secure. Your site needs an TLS (SSL) certificate installed on your web server.

Transport layer security stops man-in-the-middle attacks. This means third parties cannot see what you are transporting between the browser and the server. bad guys cannot tamper with or intercept the requests or responses. This means both sides of the conversation reliably know the data is good.

Obtaining a certificate also means you must expose your identity to a trusted certificate authority. Once you meet the identity threshold you can obtain your certificate.

There are three primary certificate types. Domain, organizational and extended validated. Each one requires progressively more identity proof to obtain.

For most sites a simple domain validated certificate works. These are typically free, easy to obtain and install. The AWS certificates I use are domain authenticated certificates. If Love2Dev was a larger entity and dealt with more sensitive data I would upgrade to a higher level.

Many modern web APIs, like service workers and HTTP/2, require HTTPS before they are enabled. Additionally, browsers are starting to gate existing APIs behind HTTPS, like Geo-Location. Finally, search engines are using HTTPS as a key ranking factor.

Don't just implement HTTPS to qualify as a progressive web app. Implement HTTPS because it is the right thing to do for you and your customers.

Describe Your Site Using a Web Manifest File

Progressive web apps have a web manifest file. This is a simple JSON, or JavaScript Object Notation, composed of meta data to describe your website.

{ "name": "Fast Furniture", "short_name": "Furniture", "icons": [ { "src": "meta/fast-furniture-64x64.png", "sizes": "64x64", "type": "image/png" }, ... ], "description": "Fast Furniture is a Progressive Web Application Demonstration Site", "orientation": "portrait-primary", "start_url": "/?utm_source=homescreen", "display": "fullscreen", "background_color": "#F99D36", "theme_color": "#55B4F6", "scope": "/" } 

The file describes your site to the browser and platform. The manifest includes properties like site name, theme or colors and the brand icons. The best icon is selected when the user adds your site to their home screen.

The manifest file can also designate a special URL to load each time the user opens your progressive web app from the home screen.

In short, the manifest file is a way to control user experience and branding on the platform. While the manifest format is a specification, how browsers use these properties varies.

This is how you create your brand's add to homescreen experience. Take advantage of this meta feature to theme your experience so customers recognize your brand.

The Service Worker Superpower

Maybe the most exciting requirement is registering a service worker. Service workers are technical, but unlock many new and emerging browser capabilities.

Registering a service worker is simple.

Create a service worker script. This script should be located in your site's root folder. Remember this script is not executed as part of your page, but does need to be registered via your regular, client-side JavaScript.

Verify service worker support in your page's JavaScript , then call the ServiceWorkers.register method.

if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(reg => { // do stuff here }); }

From here you can start doing more advanced features.

Browsers are rapidly rolling out service worker support. Currently Chrome, Opera and FireFox are leading the way. Edge is working on their implementation at the moment. And finally Safari is joining the crowd.

Service workers use a background thread, which eliminates any affects they may have on the real-time user experience. Because they run ‘behind the scenes' they can accomplish work even when the web site is not open.

This background capability creates new opportunities for browsers to add new functionality. Native push notification support is the first major background feature to ship.

Push notifications unlocks a new avenue for you and your brand managers to connect with potential customers. Your devops team can take advantage of push technology to seamlessly upgrade and update your application in the background.

Get Started Today

Get started adding an SSL key to your web site. Next create and reference a web manifest that describes your web site. Finally, create a simple service worker and register it in your web site's code.

Applying these three technical requirements can be done in as little as 10 minutes. From there start exploring the new features and how you might apply them to your web site presence or application. Before you know, your website is an app.