Progressive Web Apps. Who needs it?!

Progressive Web Apps. Who needs it?!

Some say that this is an unnecessary fairy tale, others that this is the future and take to the implementation. Does PWA even make sense at this point? The fact is that the idea is gaining popularity, and companies that have decided to implement them are very pleased with the results.

PWA are websites that take full advantage of modern browsers. Since humanity has shed the yoke of compatibility with the old ie (the date of the end of support for Windows XP should be some kind of holiday), many beautiful things have happened. For example more and more browsers began to implement W3C standards.

These standards include, for example, the Web App Manifest, which allows you to define metadata associated with a web application, or Service Workers specification, which allow background processing and communication between the worker and the site using events. Slowly, these new browser fictions began to stack up and in 2015 Frances Berriman and Alex Russell created the term Progressive Web Apps to describe web applications that are more similar in behavior and capabilities to native applications than websites.

Today, Google, which leads this trend, quite clearly defines what are the characteristics of PWA. This is an application that:

  • it is progressive-that is, it works for every user (there is an emphasis on displaying the most relevant content in almost any conditions),
  • she’s responsive.,
  • is as network independent as possible (Service worker implementation),
  • recalls the native app experience,
  • can load the latest information from the server efficiently,
  • uses HTTPS,
  • has application manifest,
  • has a notification system,
  • you can install it on your smartphone’s home screen,
  • it works like a normal website-that is, sharing a URL-and shares the same experience with others, without the need for installation.

This list is quite long, but it comes down to the fact that by serving the website, We want to provide an experience similar to that provided by the native app on your phone, and at the same time display exactly the same page also on any other medium.

On the technical side, the requirements are as follows:

  • HTTPS
  • Web App Manifest
  • Service Worker

“And why?”

The most important motivation is that the network usage profile is changing. First-internet users arrive. The fastest growth is observed in developing countries, where communication is often not of the best quality. Secondly, the way we use the internet is changing. Remember the late ‘ 90s? Back then, connecting to the internet was a mission – you had to turn your phone connection to “online” to be able to enjoy the dizzying speed of 56kbps and discover great sites like this in the Altavista search engine:

A lot has changed in the last 20 years. We have unlimited mobile internet, we are entering the world of IoT. Moreover, in 2014 it turned out that more people browse the internet on smartphones and tablets than on desktop computers. The following years brought further news that mobile-only internet users are a larger group than desktop-only. It’s official-we have the mobile era.

With its onset, expectations change. People require fast-acting pages that instantly load for them, for example, on the way to work. They also don’t want to install new apps. On average, an Android user installs 0 apps per month (after rounding). In addition, developing a mobile application and a website at the same time is laborious and costly. iOS + Android + web is a significant amount of work.

Of course, there have been some attempts in history to use web in smartphones. Many of you remember PhoneGap, where you use HTML + CSS + JS to do applications that additionally provide the ability to bind native components. This is the main advantage of this solution. A few years ago, however, the performance of smartphones and browsers was too low to offer a very rich web experience. Especially on Android.

“And who needs it?”

It seems that most of all it is needed by those who order the creation of applications. According to experts replacing native PWA applications is a 10-fold increase in the cost of user acquisition. Users, on the other hand, will benefit when it comes to the overall comfort of using the network. First of all, progressive web apps put an emphasis on site performance and using all available tools to minimize the impact of factors such as poor connectivity on UX. A mobile site that loads 19s on 3G is something unacceptable in the world of PWA (and this was achieved by the average site in 2016).

So the mere focus of developers on the problem of performance is, in my opinion, a very positive phenomenon. Here you can also go crazy and bet on AMP (accelerated mobile pages) in some cases, which will even speed up the loading. However, the right performance is a prelude to the creation of PWA. The essence is Service Workery and Web App Manifest. The primary role of service workers is to manage cached data so that you can view meaningful content in case of network problems. Web App Manifest is just metadata that will make it easy to add such a page to the desktop, and will also cause the PWA to be dressed in robes worthy of a native application.

I have a problem with push notifications. Of course, this is a great thing for publishers, but as a user I do not like them very much. Ot, another thing you have to manually turn offor specify that you do not want to use it. After all, companies that have introduced web notifications are proud of the results – the conversion bars have grown significantly. Immersive app and increased engagement and those things.

The positive aspect is standardization and provision of certain interfaceswhich are very useful in mobile applications. I’m talking about the media API (including image capture and shape recognition!), content sharing, unified payment format, one-click registration or even a browser-level Bluetooth API. Of course, some of them create new security challenges, but keep in mind that they also exist in the world of native applications.

“And who wants to legalize it?”

Okay, I’ve sweetened that a little bit, now it’s time to face reality. Basically most of the components needed to create a really good PWA only work in Chrome. Consider the Service Worker API compatibility table for mobile browsers:

(source: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API)

I was watching a presentation with GDD Europe ’17 when I heard about the Web Share API that allows you to run from a browser native widget for sharing content. I figured I had to have it on the bulldogjob website. So I wrote the necessary code and there was a problem with testing. Firstly, you need https for web share, and secondly, Chrome in version 61-which I couldn’t even download, because Google was slowly introducing it for only two days. I had to download Chrome in dev version and do production test 😎. It’s not best practice, but it’s the only way I could see this functionality in action. By the way, I’ll tell you that it works pretty cool, I introduced the share button under our job offers.

So really Android and Chrome users will have a good experienceand all the rest will mainly benefit from better performance. So will they really feel that they are using progressive web apps? I doubt it.

Let’s look at the history of the development of PWA. The term originated in 2015, Google organized a conference on this topic in the summer of 2016. There are already a lot of features on Chrome and Firefox. Apple has announced that it will implement some specifications. So there is a chance that next year the situation will look much better than now. However, when and whether PWA will become standard-is unknown.

“It will be useful, it is necessary to try everything”

And that’s what I think you should do. take a look at the concepts from the PWA and decide for yourself which are useful to us. Surely web browsers offer more and more and it is a pity to not use this potential. For people who want to learn more specifics about Progressive Web Apps I suggest 3 things:

  • Visit the tutorial from Google
  • Installing yourself Lighthouse (it can also already be integrated in Chrome in the ‘audit’ tab) and check what this tool thinks about your project. It can give very cool tips in the areas of PWA compliance, performance, availability and best practices. However, do not be upset by the low result, because Google’s sites do not have 100/100 ratings either. Rather, draw the appropriate conclusions from the tips received.
  • Watch the following video from GDD Europe, where the general process of transformation of an ordinary page into a PWA is presented.

  • Bonus: if you are using Chrome 61 on Android you can click ” share” in any job offer on Bulldog to see the Web Share API live 🙂

Go to our cases Get a free quote