Why You NEED Progressive Web Apps

Why You NEED Progressive Web Apps

The global web is going mobile. At the beginning of 2015, about a third of world wide web traffic came from mobile devices. Halfway through 2017, that number has risen to 52 per cent of all traffic. Half the world is accessing the web through their phone.

At the same time, the web’s complexity has increased. Web applications are bigger and better than ever; they now rival native applications in functionality and power. You can do a lot from your browser — more and more each day.

But as the web evolves as a platform, a certain Catch 22 emerges. Users are accessing the web from a massive variety of conditions, all over the world. Some have blazing fast internet connections and can keep up with bloated JavaScript applications. Others have limited connectivity at best, but still want access to the same functionality.

Imagine a user in the heart of Seoul, South Korea, shopping from her laptop connected to a fibre optic network. Then imagine another user, a few thousand kilometres away in rural India, trying to log onto the same e-commerce site from his phone. Both of these users expect to be able to achieve the same goals. Both users want to avoid the frustration of staring at a blank loading screen, or waiting for an unresponsive site.

How Can a Modern Web App Serve Them Both?

 Progressive Web Apps were originally proposed in 2015 by Google engineer Alex Russell and designer Frances Berriman. Over time, the definition of a PWA has evolved, but the core principles remain the same.

Perhaps the most important principle is the concept of progressive enhancement. This means your application loads the essential content first, as fast as possible. The user gets what they need as soon as it can be delivered. Then, as the network connection allows, the app loads presentational and functional bonuses — the icing on top.

This means the mobile user in India and the desktop user in South Korea both get what they need to use the site in under a second. The difference: the South Korean browser gets a whole lot more in the same time span. In technical terms, the Indian user gets the core HTML with inline styling. The South Korean user will get an externally linked CSS file, as well as JavaScript-powered functionality for a richer experience. The key, however, is that the same core experience is always delivered.

But it doesn’t end there. Experimental web technologies such as service workers have opened up new possibilities. As soon as each user visits a page with a service worker, it becomes available offline. If a user makes a purchase and then shuts of her connection, she can still view her order details by returning to the page — whenever she wants.

Under this model, application performance is no longer reliant on connection speed (though it still improves from better connections), or on connectivity at all. The web becomes easier than ever to access and use.

But Progressive Web Apps aren’t just about delivering a usable web for everyone. They’re about making the web more powerful than ever before.

Bridging the Native Gap

In November of 2016, JavaScript guru Eric Elliott published an article with a provocative title: ‘Native Apps are Doomed’. In it, he explained why he would no longer consider creating native mobile applications—Android and iOS apps as we know them—and focus all his attention on the web.

His argument against the native app hinged on two statistics. First, most web traffic comes from mobile users. More people are browsing the web on their phones than ever before. But they’re not using native apps. Research by Tune showed that users install on average one to three new apps a month.

Given the plethora of options in app stores, those aren’t good odds for your application making the cut. Your users are on the web. That’s where they’re going to find you.

The Web Difference

It’s easy to see why web app adoption rates might be higher than native apps: there’s far less of a barrier to entry. Downloading a native app is a commitment. A user has to give up precious storage and expose themselves to potentially malicious code. All that, before they ever use the application — before they even really see it, aside from a few screenshots.

Web apps can be accessed by anyone with a smartphone and the URL, and the user is able to assess the app’s utility without any real commitment.

That’s the beauty of the web, and why it’s such a powerful platform. That said, once the user commits to a native app, it has clear advantages. Users can receive push notifications. The app has an icon on their home screen, a powerful reminder of its existence (whereas users may forget about a web app altogether). The application boots up quickly, and can work offline.

The evolution of the Progressive Web App hinges on a simple question: why can’t we do all that on the web?

Best of Both Worlds

One of the most exciting pieces of web technology to emerge in recent years is the service worker.

Service workers are a bit of code that sit between your application and the network. That means they can do two cool things: intercept network requests, and run in the background when your web application isn’t open.

Why do service workers matter so much? Because they allow us to emulate all of the native app advantages listed above — on the web.

Push notifications? Check — received and displayed through the service worker, even if the browser isn’t open.

Instant loading? Done — the service worker caches files and intercepts subsequent network requests for those files, serving up the cached version.

Offline capability? Same principle as the above!

The last piece of the native app puzzle is the ability to save the application to the user’s home screen. Thanks to a little file called a web app manifest — essentially a description of your application — this is now possible on both Android and iOS. Better yet, you can prompt the user to ‘Save to Home Screen’ when they’re visiting your application on the web. This prompt currently happens automatically with Progressive Web Apps if the user visits your site twice, with a break of five minutes in between (though this can be configured).

All of a sudden, we’ve solved the biggest problem with native apps — now, users can play around with our application, get a feel for it, and then make a decision of whether they want to save it to their device.

Web Progression

In short, Progressive Web Apps promise to do two things: raise the level of functionality and interactivity of modern web applications through push notifications and installation, while at the same time lowering the barrier to entry by making sites faster and less bulky. That means making the web more powerful and more accessible. That’s progress.

5 Benefits of Progressive Web Apps

PUSH NOTIFICATIONS

Push notifications are a marketer’s dream — instant, targeted access to a user’s attention, anywhere, anytime. But beyond their business value, they’re a huge usability win. What good would your email inbox be if you didn’t know when you received a new email?

It’s about time this core functionality came to the web. As soon as your user visits your app, you can now prompt them to allow notifications. From that point on, your app can alert them to key events. Most importantly, you can do so on any platform — if they’re on their phone or on their laptop, whether they have your app open or not.

For now, web push notifications are not quite as sophisticated as native app notifications — they’re limited to a text-based message, without any actions. But as Progressive Web Apps evolve, so will notifications, opening up a slew of exciting new possibilities.

INSTANT LOADING

Thanks the magic of service workers, you can now cache the static assets of your site, so the page loads instantly on return visits. Progressive Web Apps also put a strong emphasis on performance, so your site loads quickly even without the caching advantage.

A key part of this is something called application shell architecture. In this model, even with a JavaScript-heavy application, you present your user with content as soon as possible, and load the rest in the background. In practical terms, this pattern might mean showing the header and background of the application (the shell) and a loading indicator almost instantly, and then filling in the body as quickly as possible.

Advanced Progressive Web Apps will utilise parts of the PRPL pattern, which emphasises loading the critical route to your application first, pre-caching the remaining routes, and then lazy-loading the remaining routes in the background.

Regardless of the tools and concepts used, the end goal is the same: give your users an interactive application as soon as possible!

OFFLINE CAPABILITY

Since service workers cache key assets of your app, the user can actually visit it while offline. For mobile users skipping between Wi-Fi zones, the convenience factor could be huge, enabling them to quickly check a message or a set of directions. Nor is this solely an advantage for offline users: for users with intermittent or low-quality connections, being able to continue working as the network skips in and out is a big win. Here, a global perspective is especially important: your personal connection may be consistent and fast, but can you say the same for all your users?

HOME SCREEN INSTALLATION

You want users to use your app— preferably daily, preferably all the time. To do so, you need to make sure they are reminded of your app’s existence. The easiest route to this goal, for native apps, was simply the presence of an icon on the user’s home screen.

Thanks to web app manifest technology, that accessibility is now possible for PWAs. Users can be prompted to save the app to their home screen, where it looks and feels exactly like a native app, launching with a splash screen and without the browser’s URL bar.

ACCESSIBLE TO ALL

The mobile web is now the dominant global platform. But internet speeds have yet to catch up. Apps that want to conquer the world need to optimise their page for every user and every network connection.

PWAs emphasise the idea of progressive enhancement — giving users a fast-loading, functional ‘core’, and then adding the extra details as more data loads. Progressive enhancement, combined with offline capability and caching, means your app can be used by anyone, anywhere — exactly as the web is intended to work.

Leave a Reply

Your email address will not be published. Required fields are marked *