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.
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.
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.
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).
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.
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.