Jedni mówią, że to zbędny bajer, inni, że to przyszłość i zabierają się do implementacji. Czy PWA w ogóle ma sens w tym momencie? Fakt jest taki, że idea zyskuje na popularności, a firmy, które zdecydowały się na wprowadzenie ich w życie są bardzo zadowolone z rezultatów.
PWA to strony internetowe, które wykorzystują w pełni możliwości nowoczesnych przeglądarek. Od czasu gdy ludzkość zrzuciła z siebie jarzmo kompatybilności ze starymi IE (data końca wsparcia dla Windowsa XP powinna być jakimś świętem) stało się wiele pięknych rzeczy. Przykładowo coraz więcej przeglądarek zaczęło implementować standardy W3C.
Wśród tych standardów jest np. Web App Manifest, który pozwala na zdefiniowanie metadanych związanych z aplikacją internetową, albo specyfikacja Service Workerów, które pozwalają na przetwarzanie w tle oraz komunikację między workerem a stroną za pomocą eventów. Powoli te nowe ficzery przeglądarek zaczęły układać się w większą całość i w 2015 roku Frances Berriman i Alex Russell stworzyli termin Progressive Web Apps by opisać aplikacje internetowe, które zachowaniem i możliwościami bardziej przypominają aplikacje natywne niż strony internetowe.
Dziś Google, które przewodzi temu trendowi, dość wyraźnie określa jakie są cechy PWA. To aplikacja, która:
- jest progresywna - czyli działa dla każdego użytkownika (jest tu nacisk na wyświetlanie najbardziej istotnej treści w niemal każdych warunkach),
- jest responsywna,
- jest możliwie niezależna od sieci (implementacja Service Workerów),
- przypomina doświadczenie aplikacji natywnej,
- potrafi załadować sprawnie najnowsze informacje z serwera,
- używa HTTPS,
- ma manifest aplikacji,
- ma system notyfikacji,
- można ją zainstalować na ekranie domowym smartfonu,
- działa jak normalna strona - czyli udostępnienie URL-a udostępnia to samo doświadczenie innym, bez konieczności instalacji.
Ta lista jest dość długa, ale sprowadza się do tego, że serwując stronę internetową chcemy zapewnić doświadczenia podobne do tych, które zapewnia aplikacja natywna na telefonie, a przy tym dokładnie tę samą stronę wyświetlić również na każdym innym medium.
Z technicznej strony wymagania są następujące:
- HTTPS
- Web App Manifest
- Service Worker
“A dlaczego?”
Najważniejszą motywacją jest to, że profil korzystania z sieci się zmienia. Po pierwsze - użytkowników internetu przybywa. Najszybszy wzrost odnotowuje się w krajach rozwijających się, tam często łączność nie jest najlepszej jakości. Po drugie zmienia się to jak korzystamy z internetu. Pamiętacie końcówkę lat 90? Wtedy łączenie się z internetem to była misja - trzeba było przełączyć łącze telefoniczne w stan “online”, żeby móc się rozkoszować zawrotną prędkością 56kbps i w wyszukiwarce Altavista odkrywać super stronki takie jak ta:
(źródło: easynett)
Przez te 20 lat sporo się zmieniło. Mamy nieograniczony internet w komórkach, wchodzimy w świat IoT. Co więcej w 2014 okazało się, że więcej osób przegląda internet na smartfonach i tabletach niż na komputerach stacjonarnych. Kolejne lata przyniosły kolejne wiadomości o tym, że użytkownicy internetu mobile-only to większa grupa niż desktop-only. To oficjalne - mamy erę mobile.
(źródło: SmartInsights)
Wraz z jej nastaniem zmieniają się oczekiwania. Ludzie wymagają szybko działających stron, które błyskawicznie załadują im się np. w drodze do pracy. Nie chcą też instalować nowych aplikacji. Średnio w miesiącu użytkownik Androida instaluje 0 aplikacji (po zaokrągleniu). Dodatkowo jednoczesne rozwijanie aplikacji mobilnej i strony internetowej jest pracochłonne i kosztowne. iOS + Android + Web to znaczne nakłady pracy.
Oczywiście w historii było parę prób wykorzystywania weba w smartfonach. Wielu z Was pamięta PhoneGapa, gdzie używa się HTML + CSS + JS by robić aplikacje, które dodatkowo stwarzają możliwość bindowania natywnych komponentów. To jest główna zaleta tego rozwiązania. Kilka lat temu wydajność smartfonów i przeglądarek była jednak za niska by oferować bardzo bogate doświadczenie w formie strony internetowej. Szczególnie na Androidzie.
“A komu to potrzebne?”
Wydaje się, że najbardziej to jest potrzebne tym, którzy zlecają tworzenie aplikacji. Według ekspertów zastąpienie aplikacji natywnych PWA to 10-krotna oczędność jeżeli chodzi o koszt pozyskania użytkownika. Użytkownicy natomiast zyskają gdy chodzi o ogólny komfort użytkowania sieci. Przede wszystkim Progressive Web Apps kładą nacisk na wydajność stron i używanie wszelkich dostępnych narzędzi, by minimalizować wpływ czynników takich jak słaba łączność na UX. Strona mobilna, która ładuje się 19s na 3G to coś nieakceptowalnego w świecie PWA (a taki wynik osiągała przeciętna strona w 2016).
Tak więc samo kierowanie uwagi developerów na problem wydajności jest w mojej ocenie bardzo pozytywnym zjawiskiem. Tutaj można też zaszaleć i postawić na AMP (Accelerated Mobile Pages) w pewnych przypadkach, co jeszcze przyspieszy ładowanie. Jednak odpowiednia wydajność to preludium do tworzenia PWA. Istotą są Service Workery i Web App Manifest. Podstawową rolą Service Workerów jest zarządzanie danymi w pamięci podręcznej tak, by w razie kłopotów z siecią można było wyświetlić sensowną treść. Web App Manifest to tylko metadane, które sprawią, że można łatwo dodać taką stronę na pulpit, a także spowodują, że PWA będzie ubrane w szaty godne aplikacji natywnej.
Pewien problem mam z notyfikacjami push. Oczywiście to super sprawa dla wydawców, ale jako użytkownik bardzo ich nie lubię. Ot, kolejna rzecz, którą trzeba ręcznie wyłączyć, albo sprecyzować, że nie chce się tego używać. Mimo wszystko firmy, które wprowadziły webowe notyfikacje są dumne z rezultatów - słupki konwersji urosły znacząco. Immersive app and increased engagement i te sprawy.
Pozytywnym aspektem jest standaryzacja i udostępnienie pewnych interfejsów, które są bardzo przydatne w aplikacjach mobilnych. Mówię tu o API do mediów (w tym do przechwytywania obrazu i rozpoznawaniu kształtów!), share’owania treści, zunifikowanej formatce do płatności, rejestracji jednym kliknięciem czy nawet API do obsługi bluetootha na poziomie przeglądarki. Oczywiście część z nich tworzy nowe wyzwania dla bezpieczeństwa, ale należy pamiętać, że istnieją one również w świecie aplikacji natywnych.
“A kto to chce zalegalizować?”
Ok, to już nieco posłodziłem, to teraz czas na zderzenie z rzeczywistością. W zasadzie większość z komponentów potrzebnych do stworzenia naprawdę dobrego PWA działa tylko w Chrome’ie. Weźmy tabelkę kompatybilności Service Worker API dla przeglądarek mobilnych:
Oglądałem sobie prezentację z GDD Europe ’17 gdy usłyszałem o Web Share API, które pozwala uruchomić z przeglądarki natywny widget do dzielenia się treścią. Stwierdziłem, że muszę to mieć na stronie Bulldogjob. Napisałem więc potrzebny kod i pojawił się problem z testowaniem. Po pierwsze do Web Share’a trzeba HTTPS, po drugie Chrome w wersji 61 - której to nawet nie mogłem ściągnąć, bo Google powoli ją wtedy wprowadzał od zaledwie dwóch dni. Musiałem ściągnąć Chrome w wersji dev i robić test na produkcji ?. Nie jest to najlepsza praktyka, ale tylko tak mogłem zobaczyć tę funkcjonalność w akcji. Tak na marginesie, to powiem Wam, że działa to całkiem spoko, wprowadziłem przycisk share pod naszymi ofertami pracy.
Tak więc naprawdę dobre doświadczenie będą mieć użytkownicy Androida i przeglądarki Chrome, a cała reszta będzie korzystać głównie z lepszej wydajności. Czy więc naprawdę będą czuć, że używają Progressive Web Apps? Wątpię.
Popatrzmy na historię rozwoju PWA. Termin powstał w 2015, Google zorganizowało konfę na ten temat latem 2016. Już teraz na Chrome’ie i Firefoxie działa sporo udogodnień. Apple zapowiedziało, że wdroży u siebie niektóre specyfikacje. Tak więc jest szansa, że za rok sytuacja będzie wyglądać o wiele lepiej niż teraz. Jednak kiedy i czy PWA stanie się standardem - nie wiadomo.
“To przyda się, konieczne jest wszystkiego spróbować”
I właśnie tak uważam, należy samemu przyjrzeć się konceptom z PWA i samodzielnie zdecydować, które są dla nas przydatne. Na pewno przeglądarki internetowe oferują coraz więcej i szkoda tego potencjału nie wykorzystać. Dla osób, które chcą się dowiedzieć więcej konkretów na temat Progressive Web Apps sugeruję 3 rzeczy:
- Odwiedzenie tutoriala od Google’a
- Zainstalowanie sobie Lighthouse(może być też już zintegrowany w Chrome’ie w zakładce ‘Audit’) i sprawdzenie co to narzędzie sądzi o Twoim projekcie. Potrafi dać bardzo fajne wskazówki w obszarach zgodności z PWA, wydajności, dostępności i najlepszych praktyk. Nie załamuj się jednak niskim wynikiem, bo strony Google’a też nie mają ratingów 100/100. Wyciągnij raczej odpowiednie wnioski z otrzymanych wskazówek.
- Obejrzenie poniższego filmiku z GDD Europe, gdzie przedstawiony jest ogólny proces transformacji zwykłej strony do PWA.
- Bonus: Jeżeli korzystasz z Chrome 61 na Androidzie możesz kliknąć “Udostępnij” w dowolnej ofercie pracy na Bulldogu by zobaczyć Web Share API na żywo :)