First Steps to mastering PWA (Progressive Web App)

You might have seen the acronym PWA (Progressive Web App) popping up all over the place at conferences related to web and mobile technologies for the last few years. Especially at events organized by Google. What is PWA? What are its benefits and disadvantages? Read on to find out the answers to these questions.

 

5B

There are around 5 billion devices connected to the internet all around the world, of which a large chunk is mobile devices. Mobile-first is a trend everyone should know these days. Research shows that when using a smartphone, 3 times more users browse websites rather than native applications. The same study shows an opposite trend when it comes to time spent in the application – native apps are a definite favorite here. Why is that the case? The best answer to this questions lies in something called "native-like experience."

 

Native-like experience

It's much easier to open your favorite application by clicking on an icon, rather than to enter the address in a mobile browser. Trouble begins when our device doesn't have internet access at the moment. The browser usually tries to help users pass the time by serving a gray screen with a dinosaur. In turn, native applications continuously display their UI and often include information that downloaded during the last visit when the user's device had internet access. In short, users can still access data they might be interested.  

You can always play dino when unable to access the internet

 

Push notifications are the icing on the cake. We like to receive notifications even if we don't keep the application open. We're always happy to see a new cat photo or get our comment answered. We are more involved in the experience. And it's that involvement that creators and publishers of apps care about most. Until recently, all the functionalities mentioned above were available only in native applications. Everything changed with the PWA model – the Progressive Web Application.  

PWA. What is it and who needs it?

PWA is nothing else than a regular web application (HTML + CSS + JS) enriched with a few extras that allow achieving the native-like experience. Your application must meet the following requirements (this is the PWA checklist):
  • It's served by HTTPS for data security.
  • RWD (responsive web design) is essential that your app looks good on both desktop and mobile platforms.
  • It works even when you're not connected to the internet (it doesn't need to be the full functionality, but at least a screen indicating that there's no connection).
  • It has a file 'manifest.json' describing the app, thanks to which we can add a shortcut to the start screen.
  • It loads quickly even with slow 3G connections.
  • Is Reactive (we're not talking here about the React library, but the word Responsive is already taken by WFD) – the main point is that the application responds to user actions quickly (for example, switching screens).
All of these criteria can be performed iteratively. If we already have a web application that renders well on mobile devices, we need to implement the code to ensure offline operation and add a small manifest.json file. In the next steps, we can focus just on performance issues, i.e. on the loading speed of the application and its responsiveness (speed in action).

 

Offline-first & Service Worker FTW

One of the most important aspects of PWA is offline operation. We can implement it in several ways. In the minimal version, we can display our screen with information about the lack of network availability. In subsequent stages, we can save data on the memory of our device that we were able to download during the last visit. The last level is downloading data in the background. How to do it all? The Service Worker API comes in handy. We'd need another blog post here to determine precisely how a Service Worker works. In a nutshell - thanks to SW, we can define which resources should be saved to the cache, and for which ones we want to reach deeper into the depths of the internet. We save what's most important for later, so next time you launch the application, you don't have to wait for the files to download from our server. In addition to manageable caching, Service Worker also allows the implementation of Push-Notifications and Background Sync.

 

Show me manifest.json, and I'll tell you who you are

The manifest.json file is used to describe the application. We provide here information about the name of the app, icons, and the starting address. A sample file might look like this:  
{
    "name": "Sunscrapers PWA",
    "short_name": "Sun PWA", 
    "icons": [{ 
      "src": "/android-chrome-192x192.png", 
      "sizes": "192x192", 
      "type": "image/png" 
    }, { 
      "src": "/android-chrome-512x512.png", 
      "sizes": "512x512", 
      "type": "image/png" 
    }], 
    "theme_color": "#ffffff", 
    "background_color": "#ffffff", 
    "display": "standalone" 
}
  The name of our application - name - will be displayed on the so-called splash-screen, while the short name - short_name - will be displayed under the icon on the device's desktop, for example.  

PWA allows adding an icon to your desktop and displays a splash-screen

  We can also set the background color for splash-screen (background_color) and the color to be used by the browser and phone interface when the application is launched (theme_color). The last item - display - allows specifying the mode in which the application should be launched. Standalone mode hides the browser interface, giving the impression of a native app.  

Application in display-standalone mode and visited in the browser

 

It all sounds great – but is it worth it?

For developers, the common code-base is a significant advantage. With PWA, we're actually creating one application that runs on all platforms (Desktop, iOS, Android etc.). The same can't be said about other technologies like React Native, Ionic, and Cordova. In these cases, we write one code-base, but only for mobile platforms. It often happens that architectural differences between platforms don't allow sharing of code. In the case of PWA, we can talk about one WEB platform - under which we write one shared code. For publishers, the advantage of Progressive Web App is frequent updates. To launch a new version of a mobile application, you usually have to work hard (depending on the platform). The application goes to the store, passes the review... The user receives a notification and accepts the update – and only then the application is updated. In the case of PWA, the only thing we need to do is upload new files to our server. That's all! The next time the application is launched, the user will get the latest version of the code. Simple, right? For business stakeholders, PWA will prove cost-effective. Since everything can be written using web technologies, why hire Android and iOS developers? PWA is not fully ready yet to replace native applications, so developers can sleep peacefully without worrying about their fate. Users, on the other hand, will benefit from the responsiveness of the application and the fact that they can run it on any platform. Microsoft recently announced that the search engine implemented in the Windows Store would also search for Progressive Web Apps and allow installing in the system. That will give users an even more native-like experience.

 

Too beautiful to be true - where's the catch?

As they say: All that glitters is not gold. I mentioned Google in the introduction to this article for a reason. Google actively and intensely promotes Progressive Web Apps. Apple doesn't mention it, probably fearing a drop in activity on the App Store. Why would users enter the store if they can type the address in the browser and add the application directly to their start screen? Exactly. Research shows that at every installation step, we lose as many as 20% of users (and that's an optimistic view). In addition, not all phone functionalities are available through the WEB API. Although their number increases every year, not every browser provider implements them at the same time. You can check what your phone offers through WEB API here: https://whatwebcando.today/. That doesn't mean, however, that PWA doesn't pay off for iOS. On the contrary – as shown by various use cases, the Progressive Web App allows increasing the conversion rate by up to 75%. By implementing the Progressive Web App , Forbes has improved the time users stay in the application by 43%. Housing.com reduced their bounce rate by 40% (the number of people leaving the application after viewing only one page).

 

Quo vadis PWA

To sum up - Progressive Web App is a great model that helps developers make web applications more attractive. We can transform an application into PWA in small steps and gain a lot in productivity, time, common code for many platforms – and user satisfaction.

PWA (Progressive Web App) – pierwsze kroki

Skrót PWA (Progressive Web App) od roku 2015 pojawia się coraz częściej na konferencjach związanych z technologiami web i mobile. Szczególnie na tych organizowanych przez Google’a. Czym jest PWA? Jakie korzyści i pułapki są z nim związane? Na te pytania postaram się odpowiedzieć w tym wpisie.

5B

Na świecie jest ok 5 bilionów urządzeń podłączonych do sieci, z czego bardzo dużą część odgrywają tu urządzenia mobilne. Dlatego w dzisiejszych czasach termin “mobile-first” nie powinien być nikomu obcy. Badania pokazują, że podczas korzystania ze smartfona 3 razy więcej osób korzysta z witryn webowych niż z natywnych aplikacji. Niestety te same badania pokazują zupełnie odwrotny trend jeśli chodzi o czas spędzony w aplikacji. W tym wypadku native-apps są zdecydowanym faworytem. Dlaczego tak się dzieje? Na to pytanie można odpowiedzieć jednym stwierdzeniem “native like experience”.

Native like experience

Prawda, że wygodniej jest otworzyć ulubioną aplikację poprzez kliknięcie w ikonę na ekranie startowym, niż wklepać adres w przeglądarce ? Problem zaczyna się, gdy w danym momencie nie mamy dostępu do sieci. Przeglądarka dla zabicia czasu serwuje nam szary ekran z dinozaurem. Z kolei aplikacje natywne cały czas wyświetlają swój UI oraz bardzo często informacje, które udało się pobrać podczas ostatniej wizyty. Dzięki temu nadal mamy dostęp do danych, które mogą nas interesować. [caption id="attachment_278" align="aligncenter" width="840"] Gdy brakuje sieci zawsze można pograć w dino :)[/caption] Wisienką na torcie są oczywiście push-notifications. Lubimy dostawać powiadomienia, nawet jeżeli nie mamy otwartej aplikacji. Zawsze cieszymy się na nowe zdjęcie kota lub odpowiedź na nasz komentarz. Jesteśmy wtedy bardziej zaangażowani. I o to zaangażowanie chodzi wszystkim twórcom i wydawcom aplikacji. Do pewnego czasu wszystkie wyżej wymienione funkcjonalności dostępne były tylko w natywnych aplikacjach. Wszystko zmieniło się w momencie zaprezentowania podejścia PWA - czyli Progressive Web Application.

PWA. A co to? A komu to potrzebne?

PWA jest niczym innym jak “zwykłą” aplikacją webową (HTML + CSS + JS) wzbogaconą o kilka szmerów-bajerów, które pozwalają osiągnąć wyżej opisany “native experience”. Aplikacja musi spełniać następujące wymogi (pwa checklist):
    • Jest serwowana przez HTTPS dla zachowania bezpieczeństwa danych.
    • RWD - czyli responsive web design - krótko mówiąc musi dobrze wyglądać zarówno na Desktop’ie, jak i na platformach mobilnych.
    • Działa nawet wtedy, gdy nie jesteśmy podłączeni do sieci (nie musi to być cała funkcjonalność, ale przynajmniej ekran informujący o braku połączenia).
    • Posiada plik ‘manifest.json’ opisujący apkę, dzięki któremu możemy dodać skrót do ekranu startowego.
    • Ładuje się szybko nawet przy wolnych połączeniach typu 3G.
  • Jest Reactive (i nie chodzi tu wcale o bibliotekę React, a o to, że słowo Responsive było już zajęte przez RDW) :) - głównie chodzi o to, że aplikacja reaguje szybko na akcje użytkownika np. przełączanie ekranów.
Wszystkie te kryteria możemy spełniać iteracyjnie. Jeśli mamy już aplikację webową, która dobrze wyświetla się na urządzeniach mobilnych to zostaje nam do zaimplementowania kod zapewniający działanie w trybie offline i dołożenie małego pliku manifest.json. W następnych krokach możemy skupić się na sprawach czysto wydajnościowych, czyli na szybkości ładowania aplikacji i na jej responsywności (szybkości w działaniu).

Offline-first & Service Worker FTW

Jednym z najważniejszych aspektów PWA jest działanie w trybie offline. Możemy to zaimplementować na kilka sposobów. W minimalnej wersji możemy wyświetlać nasz własny ekran, z informacją o braku dostępności sieci. W kolejnych etapach możemy zapisywać w pamięci urządzenia dane, które udało nam się pobrać podczas ostatniej wizyty. Ostatnim stopniem wtajemniczenia jest pobieranie danych w tle. Jak tego wszystkiego dokonać ? Z pomocą przychodzi Service Worker API. O tym jak dokładnie działa Service Worker potrzebny byłby osobny post. W wielkim skrócie - dzięki SW możemy określić, które zasoby powinny zostać zapisane do cache’a, a po które chcemy sięgnąć w głąb internetowych czeluści. To, co najważniejsze zapisujemy na później, tak, aby przy kolejnym odpaleniu aplikacji użytkownik nie musiał czekać aż pliki zostaną ściągnięte z naszego serwera. Oprócz zarządzalnego cache’owania Service Worker pozwala także na implementację Push-Notifications i Background Sync.

Pokaż mi manifest.json a powiem ci kim jesteś

Plik manifest.json służy do opisu aplikacji. Zamieszczamy w nim informacje na temat nazwy apki, ikon i adresu początkowego. Przykładowy plik może wyglądać tak:
{
    "name": "Sunscrapers PWA",
    "short_name": "Sun PWA", 
    "icons": [{ 
      "src": "/android-chrome-192x192.png", 
      "sizes": "192x192", 
      "type": "image/png" 
    }, { 
      "src": "/android-chrome-512x512.png", 
      "sizes": "512x512", 
      "type": "image/png" 
    }], 
    "theme_color": "#ffffff", 
    "background_color": "#ffffff", 
    "display": "standalone" 
}
Nazwa naszej aplikacji - name - wyświetlana będzie na tzw. splash-screen’ie, natomiast skrócona nazwa - short_name - wyświetlana będzie np. pod ikoną na pulpicie urządzenia. [caption id="attachment_286" align="aligncenter" width="840"] PWA pozwala na dodanie ikony na pulpicie i wyświetlenie splash-screen[/caption] Możemy też ustawić kolor tła dla splash-screen’u (background_color) oraz kolor jaki ma przyjmować interfejs przeglądarki i telefonu w momencie odpalenia aplikacji (theme_color). Ostatnia pozycja - display - pozwala nam na określenie w jakim trybie ma zostać uruchomiona aplikacja. Tryb standalone ukrywa interfejs przeglądarki sprawiając wrażenie aplikacji natywnej. [caption id="attachment_285" align="aligncenter" width="840"] Aplikacja w trybie display-standalone i odwiedzona w przeglądarce[/caption]

Wszystko super - tylko co ja z tego będę miał?

Dla programistów niewątpliwym plusem będzie wspólny code-base. Przy PWA tworzymy rzeczywiście jedną aplikację, która uruchamia się na wszystkich platformach (Desktop, iOS, Android etc.) Czego nie można jednak powiedzieć o innych technologiach jak React Native, Ionic czy Cordova. Tam owszem piszemy jeden code-base, ale na platformy mobilne. Często bywa też tak, że różnice architektoniczne pomiędzy platformami nie pozwalają na współdzielenie kodu. W przypadku PWA możemy mówić o jednej platformie jakiej jest WEB - pod nią piszemy jeden, współdzielony kod. Dla wydawców aplikacji zaletą Progressive Web App są aktualizacje. Żeby wypuścić na rynek nową wersję aplikacji mobilnej trzeba się zwykle nieźle natrudzić, oczywiście w zależności od platformy. Zgłoszenie do sklepu, przejście review... Następnie użytkownik po otrzymaniu notyfikacji oraz zaakceptowaniu aktualizacji musi zaktualizować aplikację W przypadku PWA jedyne co musimy zrobić to wgrać nowe pliki na nasz serwer. To wszystko! Przy kolejnym uruchomieniu aplikacji użytkownik dostanie najnowszą wersję kodu. Proste, prawda? :) Dla biznesu PWA będzie zapewne źródłem oszczędności. Skoro wszystko można napisać przy pomocy technologii webowych, to po co zatrudniać Android i iOS developerów? ;) PWA nie jest jeszcze jednak w pełni gotowe zastąpić aplikacje natywne, zatem developerzy mogą spać spokojnie, nie martwiąc się o swój dalszy los. Z kolei użytkownicy skorzystają z szybkości reakcji aplikacji, jej responsywności i z tego, że będą mogli ją uruchomić na każdej platformie. Microsoft ogłosił niedawno, że ich wyszukiwarka zaimplementowana w Windows Store, będzie wyszukiwała również Progressive Web Apps i będzie pozwalała na ich zainstalowanie w systemie. To sprawi, że użytkownicy jeszcze bardziej odczują “native-like-experience”.

Zbyt piękne żeby było prawdziwe - gdzie tkwi haczyk?

Jak to mówią: każdy kij ma dwa końce i nie wszystko złoto co się świeci. Nie bez powodu we wstępie wspomniałem o Google’u. To właśnie Google bardzo aktywnie i intensywnie promuje Progressive Web Apps. Apple raczej o tym nie wspomina, obawiając się prawdopodobnie spadku aktywności w App Store. Po co użytkownicy mieliby wchodzić do sklepu, skoro mogą odpalić znany dobrze adres w przeglądarce i dodać aplikację bezpośrednio do ekranu startowego ? No właśnie. Badania pokazują, że na każdym kroku instalacyjnym w optymistycznym wypadku tracimy aż 20% użytkowników. Poza tym, nie wszystkie funkcjonalności telefonu dostępne są przez WEB API. Chociaż ich liczba z każdym rokiem wzrasta, to nie każdy dostawca przeglądarki implementuje je w tym samym czasie. To co oferuje nasz telefon poprzez WEB API, możemy sprawdzić za pomocą strony https://whatwebcando.today/. Dodatkowym technicznym problemem jest niestety brak implementacji Service Worker API w przeglądarce Safari. W takim wypadku musimy szukać innych rozwiązań cache’owania plików, chociaż sami twórcy Safari umieścili implementację Service Worker API na ich liście 5-years-plan. Nie oznacza to jednak, że PWA na iOS się nie opłaca. Wręcz przeciwnie. Jak pokazują use-casy zastosowanie Progressive Web App pozwala na zwiększenie convertion-rate nawet o 75%. Forbes poprzez implementację Progressive Web App o 43% zwiększył czas przebywania użytkowników w aplikacji. Housing.com o 40% zmniejszył bounce-rate, czyli liczbę osób opuszczających aplikację po obejrzeniu zaledwie jednej strony.

Quo vadis PWA

Podsumowując - Progressive Web App to doskonały sposób na uatrakcyjnienie aplikacji webowej. Małymi krokami możemy przekształcić ją w PWA i zyskać na wydajności, czasie, wspólnym kodzie dla wielu platform i zadowoleniu użytkowników.

Join our newsletter.