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

Gdy brakuje sieci zawsze można pograć w dino 🙂

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.

PWA pozwala na dodanie ikony na pulpicie i wyświetlenie splash-screen

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.

Aplikacja w trybie display-standalone i odwiedzona w przeglądarce

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.