Why Progressive Web Apps Are The Future Of Web Development

Why Progressive Web Apps Are The Future Of Web Development

Apps are fast and the mobile websites are slow.

In 2015, this particular problem has been one of the prime conversations in Web and app publishing and development.

Facebook Instant Articles is theoretically predicated on speed. The Accelerated Mobile Pages Project (AMP) spearheaded by Twitter and Google and will launch in early 2016 with thousands of publishers already on board.

To a certain extent, AMP and Instant Articles are a patch on a more systemic problem in that mobile Web applications and websites are just not fundamentally built for smartphones or tablets.

Developers and designers are employing the architecture of the PC and the desktop browser-based Web and hoping to speed it up for mobile. We see this approach in the “wrappers” for native applications, epitomized by the likes of PhoneGap (IE, Apache Cordova) where Web apps and websites are written in HTML and CSS and then “wrapped” with native properties (API hooks into a smartphone operating system and hardware). The industry term for these concoctions are “hybrid” apps. After years of writing about and researching these apps, I now believe that it is the wrong approach to cross-platform development and building the best Web and native app experiences.

App development is ever evolving. And from the seeds and ruins of the last generation come the innovations for the next.

A new architecture is coming that will help bridge the gap between performance of Web and native apps and may finally provide the solution to building apps and websites that are fast and reliable for the mobile age.

The Idea Behind Progressive Web Apps

Progressive Web apps are an idea first espoused by Google engineer Alex Russell in June 2015. In a nut shell, progressive Web apps start out as tabs in Chrome and become progressively more “app” like the more people use them, to the point where they can be pinned on the home screen of a phone or in the app drawer and have access to app-like properties such as notifications and offline use. Progressive Web apps are linkable with an URL, fully responsive and secure.

Russell writes:

These apps aren’t packaged and deployed through stores, they’re just websites that took all the right vitamins. They keep the web’s ask-when-you-need-it permission model and add in new capabilities like being top-level in your task switcher, on your home screen, and in your notification tray. Users don’t have to make a heavyweight choice up-front and don’t implicitly sign up for something dangerous just by clicking on a link. Sites that want to send you notifications or be on your home screen have to earn that right over time as you use them more and more. They progressively become “apps”.

For speed and functionality, progressive Web apps rely on two functions: Application Shell Architecture and Service Workers.

Application Shell Architecture is explained in more detail below. Service Workers are a way to increase Web app performance by helping to cache and deliver content and background functionality (like push notifications). Service workers can make sites work offline or help speed up the content by, “intercepting network requests to deliver programmatic or cached responses.”

What Is Application Shell Architecture?

The interesting aspect of Service Workers is that if it can intercept, store and deliver content from network requests, it can do other things too.

Service Workers are the foundation of Application Shell Architecture. Instead of cache and delivering content, the Service Worker always has the basic interface and design of the Web application stored and ready to deliver almost instantly.

Hence we have the “shell” of the application delivered as soon as a person makes a request from their smartphone.

App Shell

Think of the shell like the frame of a picture in the Harry Potter movies. The frame is always there and always stays the same. What changes is what is inside the picture as the person can move around and (apparently) come and go as they please. The frame is static while the person inside is dynamic.

In Application Shell Architecture, the shell is served up by the Service Worker and then the content is delivered—often cached by the Service Worker—dynamically from its source through API requests. Sites that people visit more often will be able to hold the shell and even the last content the person visited while waiting for the network to dynamically load the latest refresh.

Google’s Addy Osmani and Matt Gaunt described the process on Google’s developer site:

When we talk about an app’s shell, we mean the minimal HTML, CSS and JavaScript powering the user interface. This should load fast, be cached and once loaded, dynamic content can populate your view. It’s the secret to reliably good performance. Think of your app’s shell like the bundle of code you’d publish to an app store if building a native app – it’s the load needed to get off the ground, but might not be the whole story. Keep your UI local and pull in content dynamically through an API.

In tests, the Google developers found that the combination of the Application Shell Architecture and Service Workers drastically reduced the time it took to load sites over cellular connections. Loading a site from first request to meaningful “paint” (the first thing seen on the site) by asking for all the resources over the network at once was 1.2 seconds. The App Shell Architecture and Service Workers, the same request was loaded in 0.5 seconds (to note, the tests were being run on extremely simple websites).

Shell Architecture scheme

The implementation of the Service Workers plus Shell Architecture scheme is still in its early stages. Google used progressive Web apps and progressive enhancement on its Google I/O 2015 Web app and has a couple of other examples, but no website you visit on a regular basis today will be using it. Osmani and Gaunt note that Application Shell Architecture would be best used for sites that have a lot of dynamic content that is updated frequently.

Web developers do not need to wait for an official go ahead from the likes of Google. All of the tools are available now (to varying degrees of maturity). Service Workers are supported by Chrome and Firefox and the creative use of JavaScript, CSS and HTML will help developers build the necessary shell and design elements. APIs can call the content to populate the app. All of it is there, ready to go for developers that want to take the plunge.

Update: This article originally stated that Service Workers are ready for Apple’s Safari browser. That is not the case. Certain aspects of Service Workers are in the plan Safari, but not yet available.

Want to see more like this?
Dan Rowinski
Dan Rowinski
Former ARC Editor-in-Chief at Applause
Reading time: 5 min

3 Challenges for Payment Testing in the Metaverse

Security and regulation around payments, particularly for cryptocurrency, cause headaches in the metaverse

Healthy Health Apps Put Digital Quality First

How health and wellness organizations pass their digital quality check-ups

What Is Regression Testing? Types, Approach and More

Make sure new features don’t break existing functionality

Great Travel and Hospitality Experiences Result From Extensive Testing With Real Users

Read our new report, State of Digital Quality for Travel and Hospitality 2022

4 Ways to Get Maximum Value from Exploratory Testing

Well-planned exploratory testing can uncover critical issues and help dramatically improve the customer experience. See how to guide testers to where exploration can yield the greatest returns.