“Why are they called Progressive Web Apps? Because they become apps progressively.”
The Web may have achieved a fulcrum moment that will fundamentally alter how websites are built in the future.
It is called Progressive Web Apps, a culmination of years of work trying to make the mobile Web as fast and as useful as native apps for iOS and Android. The developers at Google who are responsible for creating Progressive Web Apps believe that it is the “AJAX moment” for the mobile Web.
“Progressive Web Apps are that same fundamental shift for the mobile Web,” said Google’s Rahul Row-Chowdhury on stage at Google I/O 2016.
“To me it is just so exciting to see. It reminds me a lot of what AJAX was like on the desktop. Back before AJAX, websites kind of sucked,” said Alex Komoroske, group product manager for Chrome at Google, in an interview with ARC at Google I/O.
The comparison of Progressive Web Apps to AJAX is apt. AJAX was not a technology, but rather a framework of technologies that allowed websites to dynamically load. Progressive Web Apps are also a set of technologies—notably Application Shell Architecture and Service Workers—that greatly reduce the time it takes for a mobile website to reach first “paint” and then become interactive.
“That moment that you see … like when I first played with Google Maps … you go ‘oh.’ Instantly, every other mapping app built before was completely outdated. And I think we are on the same level here with Progressive Web Apps because it turns out that on mobile there really were some capabilities that the Web didn’t have that were necessary,” Komoroske said.
Alex Russell is the software engineer at Google leading the charge in building Progressive Web Apps. The concept was first introduced in June 2015 and the ideas of Application Shell Architecture and Service Workers started spreading through Web development communities in November 2015.
“Why are they called Progressive Web Apps? Because they become apps progressively,” said Russell onstage during a session at Google I/O 2016. “They blur the line between Web content and apps, but they keep the strengths of the Web.”
Progressive Web Apps are designed to help websites load on mobile with flaky or almost non-existent data conditions. If you really want to see the power of Progressive Web Apps, see what The Washington Post has built with Service Workers, Application Shell Architecture and AMP (the Accelerated Mobile Pages Project from Google and Twitter) on a smartphone at wapo.com/pwa.
A False Choice Between The Web And Native Apps
Since about 2009, brands, companies and developers have been asking the same question over and over:
Should I build a website or a native app?
This question has always been rather ignorant. The notion of “mobile first” has never truly implied “mobile only.” Most companies that are based on apps also have websites that provide similar functionality (dating and payment apps like Tinder or Android Pay being the exception). At the same time, companies need to figure out where and when to apply their resources. The question of “should I build a website or an app” should be answered with “yes.” But the question of what to prioritize still remains.
“At Google we have a long history of trying to make developers accessible in whatever platforms they have chosen to work with,” Komoroske said. “That is why we have invested in native apps, making sure those are as capable as possible. And Web apps. I think, in what we see in talking to a lot of businesses—and ultimately every business should make this decision for themselves—often the answer is both in many cases.”
In September 2015, research firm comScore released some extraordinarily edifying data about how people actually use websites and apps. The gist? From an engagement perspective, the Web is a mile wide and an inch deep. Apps are the opposite, an inch wide and a mile deep.
The Web reaches wider audiences than apps. But apps dominate in time spent. Think of the Web as the net that helps you catch a fish and apps as the way to eat it.
With Progressive Web Apps, Google has seen engagement levels of websites approach nearly that of native apps. Google shows off the example of how Flipkart (India’s largest ecommerce site) tripled time-on-site with Progressive Web Apps.
“But looking at it and seeing where their users are coming in from and how engaged are they,” Kokoroske said. “And a lot of businesses that we talk to, very, very consistent, they look at their normal traffic and go ‘oh my gosh, the vast majority of my visitors are coming in on mobile Web.’ At that point if you have a really bad experience on mobile Web, they are bouncing, they are not engaging. Why would you not invest in mobile Web?”
RAIL And The Renaissance Of The Web
When it comes to speed of the Web, Google has an interesting metric intended to serve users as fast as possible: RAIL.
RAIL stands for Respond, Animation, Idle, Load. Each word corresponds to a metric in how a website should load:
- Respond: When a user clicks or taps, the response should come in under 100 milliseconds.
- Animation: People notice “jank” … the jumpy scrolling of sites that do not animate well. Natural scrolling occurs at about 60 frames per second. Russell says that frames need to render in 8 milliseconds for smooth performance.
- Idle: One of the concepts of AJAX and now Progressive Web Apps is to let data load asynchronously in idle moments. Google says that idle time should be used to complete deferred work (stuff that is not immediately necessary to load or respond to user input). Idle time work should be broken into 50 millisecond chunks to optimize performance.
- Load: 1,000 milliseconds (1 second) to become interactive.
“You don’t have to load everything in under 1 second to produce the perception of a complete load. Enable progressive rendering and do some work in the background. Defer non-essential loads to periods of idle time,” writes Meggin Kearney on Google’s developer website.
Google believes that the best practices to achieve RAIL are to use the combination of AMP, Service Workers and Application Shell Architecture to create Progressive Web Apps.
“Speed is the killer feature,” said Roy-Chowdhury.
The combination that creates Progressive Web Apps is the result of much trial and error by Web developers over the last 20 years. Google genuinely believes that the Service Workers model with Application Shell Architecture will become part of the best practices to how all Web development is done.
Over time people found out that this is the right way to build something. And then Service Worker comes in and it is so powerful and so different that even though it doesn’t change any of the things you could have done before, by adding new possibilities it sort of opens up entirely new patterns.
App Shell Architecture is a new pattern. It is early, so it may not be the pattern that everyone uses. But it seems to be a pretty good one that we recommend people to build their websites. So that they can get meaningful pixels on screen even in really flaky or totally offline scenarios.