Do we need Progressive Web Apps?

Some people would think that PWAs are useless. Other claim that this is the future and get to developing. This idea is surely gaining momentum and companies that build PWA are very happy with the results.

PWAs are websites fully utilizing modern browsers’ features. We have lots of new, cool W3C standards now. Among them are Web App Manifest allowing you to define metadata for a web app and Service Workers to introduce background processing and event based communication between frontend and service worker.

All the new features put together create a bigger picture. They are web apps that are just like native apps when it comes to behaviour and capabilities, and in 2015 Frances Berriman and Alex Russell coined a term to describe them: Progressive Web Apps.

Today PWA attributes are quite exactly defined thanks to Google, a leader in this trend. A Progressive Web Application:

  • is progressive, so it works for every user (it’s focused on displaying the most important content in most conditions),
  • is responsive - as network independent as possible (Service Worker implementation),
  • has a native-like feel to it,
  • has a Web App Manifest,
  • seamlessly loads updates from the server,
  • uses HTTPS,
  • uses push notifications,
  • can be added to a home screen,
  • is linkable - a link to a resource is all we need to share the experience with other people.

This list is pretty long, but it comes down to serving a website that creates experience like a native app and can be displayed on any medium.

From the technical standpoint, it requires:

  • Web App Manifest
  • Service Worker

But why?

The way we are using the internet is changing. First of all - the number of internet users is growing rapidly. The fastest grow is recorded in developing countries, where connectivity is usually worse than 4G. Secondly, we are using internet on mobile more than ever before. Do you remember the 90’s? Back then connecting to the internet was like a ritual. You had to switch your telephone line to “online” mode to experience stunning speed of 56kbps and to find in the Altavista search engine gems like this:

(source: easynett)

During the last 20 years a lot have changed. We have unlimited internet on our smartphones and we are just entering the IoT world. In 2014 it turned out that more people are browsing internet on smartphones and tablets than on PCs. In the next years the number of mobile-only internet users outgrew desktop-only users. It’s official - the mobile era is here.

(source: SmartInsights)

As this era started, expectations changed. People want fast websites that load instantly (e.g. when they are commuting). They don’t want to install new apps. On average, an Android user installs 0 apps per month. In addition, simultaneously developing a mobile app and a website is time consuming and expensive. Covering iOS + Android + Web means massive work.

Of course, in the history we’ve had some attempts to use web on smartphones. Some of you remember PhoneGap where you use HTML, CSS and JS to create an app that can bind native events and components. This is the main selling point of PhoneGap. A few years back handheld devices performance as well as browser performance was just not quite there to offer rich user experience on websites. That was true especially for Android.

Who needs it anyway?

It seems that PWA will mostly benefit publishers. According to experts, replacing a native app with a PWA saves up to 90% of the average customer acquisition cost. Users are benefiting from higher internet browsing comfort because of Progressive Web Apps’ emphasis on performance and minimizing poor connectivity effects on UX. Mobile website that loads in 19s on 3G is unacceptable in the PWA world. Still, 19s is the average website load time at the moment.

Bringing performance problems to developers’ attention is a good idea. In this department you can go even further with AMP (Accelerated Mobile Pages). Anyway - great performance is just an intro to creating a PWA. Its essence are Service Workers and App Manifest. Service Worker’s basic role is caching data and assets so in the case of connectivity problems page would render with valid content. App Manifest is just metadata that allows you to bring your app closer to a native one.

Personally, I have a problem with push notifications. Of course it’s great for publishers, but as a user I really don’t like them. It’s just another annoying thing to turn off. But companies that are using push notifications are very proud of the results - conversion poles are higher than ever. Immersive and engaging app and that sort of stuff.

There are at least two pluses: standardisation and making available some really cool interfaces that come handy in mobile apps. I mean Media API (which includes image capturing and shape recognition), content sharing, unified Payment Form, one-click sign up or even Bluetooth API available from browser level! Of course some of those create new challenges regarding security, but those are already present in the mobile app world.

Quick reality check

Ok, it’s time to do it. Most components that you would use to create a really good PWA are available only in Chrome. Let’s take a look at Service Worker API compatibility matrix:


I was watching GDD Europe ‘17 talk when I heard about Web Share API. It allows you to open native share widget from JS. I thought I need it on Bulldogjob website. So I wrote some code and… a problem occured. I couldn’t test it. Web Share needs HTTPS and it works only on Chrome 61+ - which I couldn’t even download at the time, because Google just started rolling this update out to the users. I had to download Chrome dev and test it on production 😎. It’s not the best practice, but only this way I could make sure it works. By the way: it works pretty well. I’ve introduced this button in our job offers.

So it’s only Chrome on Android users who’ll have a great experience, while all the others can benefit from better performance. Will they feel like they are using a Progressive Web App? I don’t think so.

We should also take a look at PWA development history. Term was coined in 2015, Google organized dedicated conference on the topic in the summer of 2016. Right now most of the APIs are functional on Chrome and Firefox, Apple announced that they will implement some specifications. Chances are that next year the overall situation will be much better. But we can’t be sure whether PWA will become a standard or not.

It might be useful after all

I think it’s best to get a closer look at PWA concepts and decide yourself if they’re useful for your. Modern internet browsers are very powerful and it would be a shame to waste this potential.

If you feel like learning more about this stuff, I suggest the following steps:

  • Visit this tutorial (by Google)
  • Install Lighthouse (it can be already integrated in the ‘Audit’ tab if you are using Chrome) and generate a report for your project. It can generate great insights on PWA compatibility, performance, accessibility and usage of best practices. Remember that the score isn’t everything, most Google sites don’t have 100/100 ratings. Try drawing conclusions from the report instead.
  • Watch this GDD talk. It goes through rough process of transforming “normal” website to PWA.
  • Bonus: If you are using Chrome on Android you can click “Share” button on any article or job offer to see Web Share API in action.