Pół roku temu rozpoczęliśmy przygodę z technologią PWA. Oto czego się nauczyliśmy.
PWA (Progressive Web Apps) to rozwinięcie stron internetowych o takie funkcje, że przyjmują charakter aplikacji, zamiast jedynie dokumentów wyświetlanych kolejno przez przeglądarkę. Można je zainstalować, mogą zapisywać dane lokalnie, otrzymywać powiadomienia w tle i mieć dostęp do sensorów urządzenia. Jednym słowem mają zdolności analogiczne do aplikacji natywnych.
Porównanie dotychczasowej strony GdziePoLek i aplikacji PWA
Strona główna GdziePoLek vs ekran początkowy aplikacji (apteki w Warszawie) oraz ekran wyszukiwania
Aplikację PWA można wstawić do sklepu takiego jak Google Play albo Windows Store, ale nie jest to konieczne. W przeglądarce Chrome wystarczy, że użytkownik potwierdzi chęć instalacji i aplikacja może od razu trafić na pulpit telefonu, bez wizyty w sklepie.Z tego powodu liczba osób podejmujących się instalacji może być wyższa niż w przypadku aplikacji natywnych - tak przynajmniej się uważa.
Dlaczego teraz?
Ponieważ lubimy technologie webowe, PWA podobało nam się od dawna.
Do tej pory jednak problemem był fakt ograniczonego wsparcia na urządzeniach Apple. W praktyce stworzenie aplikacji PWA oznaczałoby dobre pokrycie wyłącznie bazy użytkowników Android. Jeśli jednak efektem ma być aplikacja dobrze działająca tylko na jednej platformie, Android, to lepszym rozwiązaniem jest stworzenie aplikacji natywnej, która zawsze będzie najlepiej zintegrowana z systemem. Dlatego wcześniej nie zdecydowaliśmy się w ogóle na tworzenie aplikacji mobilnej.
Sytuacja zmieniła się w ciągu ostatniego roku, gdy Apple dodał w końcu podstawowe wsparcie dla PWA na systemie iOS. Nie jest jeszcze idealne, o czym za chwilę, ale nie są to już dyskwalifikujące problemy.Wśród pionierów
Ponieważ rozwój PWA wcześniej nie był zbyt atrakcyjny, praktycznie wszyscy duzi gracze przyjęli tę samą strategię: osobny rozwój strony internetowej oraz aplikacji natywnych w obu głównych technologiach (iOS i Android).
Aplikacje mobilne wybranych graczy: PWA, natywne iOS i Android
Dla potrzeb ilustracji liczyliśmy tylko techniczną dostępność PWA. Czy aplikacja wnosi natomiast wartość, czy jest tylko opakowaniem strony internetowej w wersję możliwą do zainstalowania, to inna kwestia. Na przykład po odłączeniu od sieci tylko aplikacja Onetu zachowała minimalną funkcjonalność (widoczna pierwsza strona), w pozostałych pojawiał się albo statyczny komunikat o braku połączenia (DOZ), albo błąd przeglądarki (WP, ABC Zdrowie).
Dla kogoś w sytuacji takiej jak nasza, kto nie zainwestował wcześniej w stworzenie aplikacji natywnych, pójście ścieżką PWA pozwala na potencjalnie duże oszczędności. Można rozwijać jedną aplikację zamiast kilku i gromadzić kompetencje w jednym obszarze technologicznym zamiast trzech.
Czy PWA są rzeczywiście chętniej instalowane?
Często powtarzana jest hipoteza, że użytkownicy chętniej instalują PWA, które nie wymaga odwiedzania sklepów z aplikacjami. Czy to prawda? Nasze wyniki poniżej.
W tej chwili dochodzimy do 50 instalacji dziennie, lub około 1000 miesięcznie, przy czym w maju widzimy, że będzie to już raczej ponad 1200 (edycja 31.05: ostateczny wynik to 1350).
Rośnie też liczba wejść z aplikacji, znowu z mocnym wzrostem w maju. Ciągle nie stanowią jednak znaczącego udziału w ruchu na całym GdziePoLek, który, od momentu wypuszczenia aplikacji w grudniu 2018 r., wzrósł około dwukrotnie.
Trendy instalacji i wizyt aplikacji PWA
Źródło: Google Analytics. Jako "instalację" mierzymy pierwsze uruchomienie zainstalowanej aplikacji, a nie tylko zgodę na instalację. Nie uwzględniamy więc porzuconych procesów instalacji lub aplikacji zainstalowanych, ale nigdy nieuruchomionych.
Niedawno dodaliśmy aplikację do Google Play, a wcześniej trafiła także do Windows Store.
Google Play stanowi teraz około 7% instalacji, co być może nie jest złym wynikiem, biorąc pod uwagę fakt, że nie zamieściliśmy nawet o tym informacji na stronie.
Nasza aplikacja nie jest szczególnie promowana. Celem jej stworzenia było zapewnienie atrakcyjnej opcji dla naszych stałych użytkowników. Korzyścią dla nas jest bliższe związanie ich z nami poprzez bezpośredni skrót na najbardziej osobistym urządzeniu, jakim jest telefon, oraz, w długim terminie, zredukowanie uzależnienia od ruchu z Google.
Podstawowym silnikiem "sprzedażowym" aplikacji pozostaje nasza własna strona, która bez dodatkowych kosztów stanowi źródło większości instalacji.
Niemal wszystkie instalacje to jednak Android, dlaczego tak się dzieje?
Struktura instalacji aplikacji i koszty pozyskania jej użytkowników
Źródło: Google Analytics, Google Play
Różnicę na korzyść Android tłumaczy lepsze wsparcie dla instalacji PWA na systemach Google, w szczególności użytkowników korzystających z przeglądarki Chrome.
W przypadku Chrome to przeglądarka wykrywa automatycznie, że dostępna do instalacji jest PWA i generuje zdarzenie, które przechwycić może nasz kod Javascript. W takim wypadku wyświetlamy baner z pytaniem, czy użytkownik chciałby dodać aplikację do swojego urządzenia. Po wybraniu pozytywnej odpowiedzi, aplikacja jest bez dalszych formalności instalowana. Nota bene, ponieważ sami nie znosimy wyskakujących banerów lub agresywnego nagabywania o instalację aplikacji mobilnej, negatywna odpowiedź spowoduje zablokowanie kolejnego wyświetlania baneru na kilka tygodni.
Oprócz banera, który kontroluje nasza strona, Chrome na Android wyświetla także własny pasek o instalacji ("mini-infobar"), którego nie da się zablokować. Po odrzuceniu propozycji instalacji nie pojawia się on na szczęście przez kolejne 3 miesiące.
Oferta instalacji wyświetlana jest dziennie zaledwie niewiele ponad tysiąc razy na kilkadziesiąt tysięcy wszystkich odwiedzin. Prawie 4% osób zgadza się jednak zainstalować aplikację.
Wydaje się to dobrym wynikiem w zestawieniu ze standardowym poziomem konwersji z e-commerce. Niemniej z braku własnych aplikacji natywnych nie mamy porównania, jaka jest zwykle skuteczność banerów zachęcających do ich instalacji.
Porównanie wsparcia dla instalacji PWA na Android/Chrome i iOS
Źródło: GdziePoLek
Zupełnie inna sytuacja jest po stronie użytkowników z iOS. Ponieważ system nie wspiera instalacji PWA, użytkownik musi sam znaleźć aplikację w stopce strony i ręcznie ją zainstalować (informacja o tym, jak to zrobić, jest ukryta w wysuwanej szufladzie aplikacji). Jak widać ze statystyk, niewielu osobom udaje się odkryć tę możliwość.
Rozwiązaniem byłoby opakowanie aplikacji w specjalny "wrapper" (np. Cordova) i dodanie jej do App Store, co przy okazji rozwiązałoby kilka problemów technicznych na iOS. Użytkownicy iOS stanowią u nas około 1/6 liczby użytkowników Android, więc znacząco zwiększyłoby to bazę potencjalnych użytkowników aplikacji. Do tej pory jednak jeszcze tego nie zrobiliśmy i na pewno poczekamy na konferencję dla developerów Apple (WWDC, 3 czerwca), by zobaczyć, czy Apple nie ogłosi ważnych zmian.
Sposób używania PWA jest odmienny od strony www
Naturalne jest myślenie, aby rozwijać wyłącznie PWA jako jedyną platformę dla użytkowników. W końcu, z punktu widzenia technicznego, PWA może pełnić zarówno funkcje zwykłej strony, otwartej w przeglądarce na laptopie, jak i aplikacji zainstalowanej na telefonie.
Wiele funkcji, z których jesteśmy zadowoleni w przypadku PWA, nie nadaje się jednak do przeniesienia bezpośrednio na główną stronę.
Wyszukiwanie aptek. Dzięki bazie lokalizacji przechowywanej lokalnie, przesunięcie mapy aktualizuje widoczne apteki bez żadnych opóźnień. Jest to jedna z funkcji, której teraz zazdrościmy PWA i chcielibyśmy ją mieć na stronie głównej.
Z drugiej strony, wymaga to załadowania wszystkich lokalizacji przed wyświetleniem czegokolwiek. Scenariusz wyszukiwania samą mapą jest też naturalnie uzupełniony możliwością automatycznego zlokalizowania swojego położenia. Dostęp do lokalizacji urządzenia jest naturalny w przypadku aplikacji na telefonie, ale mniej oczywisty dla użytkowników desktopowych.
Historia wyszukań i rezerwacji. Podczas gdy nasza główna strona nie zapamiętuje nic poza wyszukiwaną lokalizacją i ewentualnie danymi kontaktowymi, aplikacja oferuje historię rezerwacji, pytań zadanych farmaceutom i wyszukań.
Przykład wykorzystania danych zapisanych lokalnie
Ostatnie wyszukiwania, historia rezerwacji z możliwością na przykład anulacji z poziomu PWA.
Tutaj także nie jesteśmy pewni, czy to dobra funkcja dla strony www, mimo że implementacja nie byłaby trudna technicznie. Dlaczego? Traktujemy PWA jako aplikację instalowaną na urządzeniu osobistym użytkownika (telefonie). Można oczekiwać, że skoro została zainstalowana, właściciel zna już dobrze nasz serwis i nie jest przypadkowym odwiedzającym z Google. Dlatego wydaje się naturalne, aby aplikacja przechowywała jego dane.
Natomiast strona internetowa, która może być otwarta na komputerze używanym potencjalnie przez więcej osób, nie wydaje się dobrym miejscem do automatycznego zapamiętywania potencjalnie wrażliwych informacji.
Skanowanie kodów kreskowych i matryc danych. Tutaj PWA ma zdecydowaną przewagę nad zwykłą stroną. Znowu nie z powodu tego, że strona internetowa nie może skorzystać z tych samych bibliotek Javascript, ale dlatego, że aplikacja praktycznie zawsze jest instalowana na telefonie. Telefony mają dobre kamery i skaner działa sprawnie. Komputery, nawet jeśli mają kamery, to nie zapewniają one wystarczającej ostrości obiektu w bliskiej odległości, aby łatwo zeskanować kod kreskowy.
Słabe punkty PWA
Chociaż w prezentacjach promujących PWA powtarzają się te same bullet pointy z ich sztandarowymi zaletami (szybkość instalacji, praca offline), to jednak w praktyce trzeba liczyć się także z wieloma wyzwaniami.
Brakujące funkcje na urządzeniach Apple. Mimo, że wsparcie PWA na iPhonach polepszyło się, pozostaje wiele słabych punktów. Dla nas najbardziej irytujące jest ładowanie aplikacji od nowa po każdym przełączeniu na inne okno.
Uruchomianie aplikacji na iPhone, przejście na pulpit i powrót do aplikacji
Wyjście z okna aplikacji powoduje, że następnym razem pojawia się ekran ładowania, gdyż jest włączana od nowa (iOS 12.1). W nowszej wersji iOS (12.2) system przechowuje przez jakiś czas kontekst Javascript, dzięki czemu przywrócenie aplikacji jest szybsze, ale ciągle nie natychmiastowe, jak w aplikacjach natywnych.
Ponieważ startowy widok naszej aplikacji używa mapy, której inicjalizacja chwilę trwa, jest to uciążliwe. Mimo ostatnich poprawek wprowadzonych przez Apple w iOS 12.2, które mają przyspieszać przywrócenie PWA, aplikacje natywne mają tu przewagę.
Inny przykład braków po stronie Apple ujawnił się przy tworzeniu wspomnianego skanera kodów kreskowych. Działa on bez problemu na iOS, gdy aplikacja jest otwarta w przeglądarce, ale... przestaje działać po instalacji. Wynika to z faktu, że wersja zainstalowana PWA nie ma dostępu do strumienia wideo telefonu.
Inne braki po stronie Apple mogą być istotne dla innych aplikacji, mimo że dla naszej akurat nie są problemem. Do takich rzeczy zaliczają się ograniczona wielkość i okres przechowywania przez przeglądarkę danych lokalnych (gdy aplikacja nie jest używana) lub brak dostępu do systemowych notyfikacji.
Kłopotliwy model uprawnień aplikacji. W przypadku aplikacji natywnych uprawnienia są intuicyjne - dana aplikacja ma jakieś uprawnienie albo nie ma. Aplikacja PWA działa jednak w przeglądarce, więc to jej uprawnienia są decydujące. Gdy aplikacja nie ma uprawnień na przykład do pozyskania lokalizacji telefonu, użytkownik często nie wie, gdzie można je znaleźć, bo PWA nie jest wymienione oddzielnie na liście aplikacji.
Zdradliwy Service Worker. Service Worker to specjalny skrypt Javascript, który może przejmować żądania do serwera generowane przez stronę i na przykład zwrócić dany materiał z zapisanej lokalnie kopii, rezygnując w ogóle z kontaktu z zewnętrznym źródłem. Dzięki niemu aplikacja może funkcjonować offline, zamiast wyświetlać komunikat o braku połączenia z internetem, co miałoby miejsce w przypadku zwykłej strony. Konfiguracja strategii lokalnego cache może jednak wiązać się z wieloma pułapkami - na przykład, gdy część kodu aplikacji z powodu interwencji cache będzie pochodzić ze starszej, a część z nowszej wersji. W najgorszym wypadku aplikacja użytkownika może znaleźć się w stanie, w którym w ogóle nie będzie się jej dało uruchomić.
Jak wyglądało tworzenie aplikacji
Od momentu pomysłu na stworzenie akurat teraz PWA do pierwszej funkcjonalnej wersji aplikacji (z wyszukiwaniem aptek i leków) minęły 4 tygodnie. Po dalszych 2 tygodniach i dodaniu istotnej dla nas funkcji (rezerwacje online) aplikacja po raz pierwszy była udostępniona dla użytkowników.
Jeśli chodzi o podstawowy szkielet dla aplikacji, wybieraliśmy pomiędzy React, Angular i Vue.js. Ponieważ mieliśmy już doświadczenie z React, od razu mogliśmy wyeliminować Angular, który jest z nim zestawiany jako bezpośrednia alternatywa (niezależnie od zastrzeżeń, że Angular to bardziej pełny szkielet w stosunku do samego React). Vue.js to nowsze rozwiązanie, którego zamysłem było stworzeniem "lżejszej" alternatywy do Angular. To atrakcyjny pomysł, ale uznaliśmy, że przy PWA wielkość szkieletu nie jest aż tak istotna jak w przypadku zwykłych stron, więc znowu przeważył React.
Tworząc PWA na bazie React można oprzeć się na pakiecie create-react-app, który narzuca od razu standardowe podejście do różnych ważnych procesów, na przykład "kompilacji" aplikacji w pakiet produkcyjny.
Zdecydowaliśmy się też na wykorzystanie biblioteki material-ui, który implementuje w React elementy interfejsu użytkownika zgodne z wytycznymi Material Design od Google. Co ciekawe, ta popularna implementacja Material jest niezależna od Google, który rozwija własną (Material Design Components for web).
Material-ui podnosi trochę krzywą uczenia z powodu wykorzystania nowych rozwiązań, takich jak definiowanie stylów css bezpośrednio w Javascript. Integracja wszystkiego w kodzie unika konfliktów klas css, ogranicza problem narastania nieużywanych reguł styli i ułatwia wielokrotne użycie komponentów w różnych miejscach.
Zarządzenie stanem aplikacji jest trochę bardziej zaawansowane niż w standardowym React, dzięki użyciu centralnego stanu aplikacji i jego trwałego zapisu (redux i redux-persist).
W przeciwieństwie do głównej strony, w PWA postawiliśmy wyłącznie na mapy wektorowe, co ma wiele zalet, ale może być wyzwaniem dla starszych urządzeń. Mimo, że biblioteka obsługująca mapy (mapbox-gl.js) nie jest komponentem React, jej integracja nie jest trudna.
U nas wszystko jest PWA, Chrome
Z punktu widzenia technicznego PWA rozwijana jest jako osobny projekt. Dla użytkownika funkcjonuje na głównej domenie gdziepolek.pl, ale pod ścieżką "/app", podczas gdy istniejąca strona działa bez zmian.
Jest to dobre rozwiązanie poza jednym szczegółem, mianowicie chcieliśmy, aby użytkownik nawigujący po naszej zwykłej stronie mógł otrzymać od Chrome opisane powyżej sugestie instalacji aplikacji, mimo że rezyduje ona w /app.
Chrome ocenia dostępność aplikacji PWA dla danego adresu strony na podstawie kilku warunków, takich jak istnienie skryptu Service Workera (pośredniczy w pobieraniu przez aplikację danych i umożliwia jej działanie offline) oraz manifestu ze specyfikacją aplikacji. Jeśli te zasoby istnieją tylko w folderze /app a nie na poziomie głównej ścieżki /, to Chrome nie uznałby całej strony za możliwą do instalacji jako PWA.
Poglądowa konfiguracja serwera webowego oraz obu aplikacji: .NET MVC i PWA
Źródło: GdziePoLek
Konfiguracja serwera webowego do ukrytego kierowania żądań o potrzebne pliki do aplikacji PWA rozwiązała jednak problem. W praktyce użycie funkcji reverse proxy do tego celu okazało się niemożliwe, z powodu błędu w tej funkcjonalności po stronie serwera IIS, ale poradziliśmy sobie przy pomocy innego rozwiązania.
Złoty graal, czyli tylko PWA
Jak wspomnieliśmy wcześniej, proste użycie takich samych rozwiązań dla użytkowników korzystających z PWA jako zwykłej strony internetowej, jak i zainstalowanej aplikacji, nie wydaje nam się stosowne, ze względu na inny charakter relacji z użytkownikiem oraz jego oczekiwania wobec aplikacji i strony www.
Do tego dochodzą istotne dla nas kwestie SEO. Inaczej powinna wyglądać strona docelowa, na którą użytkownik trafia prosto z Google i nie ma w związku z tym orientacji w całym serwisie. Widoczny powinien być więc tytuł, ścieżka nawigacyjna i tak dalej. Aby użytkownik nie musiał zgadywać, jak ma poruszać się w strukturze informacji, sprawdza się rozwiązanie znane wszystkim internautom, czyli pionowe przewijanie strony. Jeśli natomiast użytkownik nawiguje od początku w aplikacji, na ekranach może znajdować się minimum informacji nawigacyjnych i możliwe jest użycie alternatywnych w stosunku do przewijania rozwiązań.
Do tego dochodzi kwestia szybkości. W przypadku wejścia użytkownika na przykład z wyników wyszukiwania Google, chcemy, aby strona otworzyła się w ułamek sekundy, aby nie zniechęcić nowej osoby do skorzystania z serwisu. W tym kierunku zoptymalizowana jest nasza główna strona. W przypadku aplikacji PWA można zaakceptować kilka sekund na instalację i załadowanie wszystkich potrzebnych danych, po czym aplikacja działa już szybko.
Niezależnie od tego, gdybyśmy teraz startowali z GdziePoLek, prawdopodobnie staralibyśmy się stworzyć uniwersalną aplikację PWA, dostosowaną do wszystkich scenariuszy użycia.
Rozwiązaniem problemu szybkości pierwszego załadowania byłaby prawdopodobnie generacja kodu html przez React już po stronie serwera, po czym na urządzeniu klienta kontrolę nad html przejmuje lokalny React, gdy już załaduje się ("rehydracja").
Mając popularną istniejącą stronę będziemy jednak spokojnie rozwijać PWA równolegle, przenosząc najlepsze funkcje tam, gdzie to możliwe, ale nie zmuszając użytkowników do korzystania z aplikacji, jeśli lubią zwykłą stronę.
Przyszłość
Strategicznie patrząc, przyszłość PWA wydaje się być obiecująca.
Ze względu na brak własnej platformy mobilnej, wykorzystanie PWA bardzo promuje Microsoft. Firma zrezygnowała nawet z rozwoju własnego silnika przeglądarki Edge, stawiając na silnik Chromium, identyczny jak w Google Chrome. Oznacza to, że z listy wyzwań przy tworzeniu aplikacji PWA niemal zniknie problem niestandardowych zachowań różnych przeglądarek, które wymagają każdorazowo dodatkowych testów.
Motywację do lepszego wsparcia może mieć Apple, który ostatnio musi bronić się przed zarzutem monopolu Apple Store na dystrybucję aplikacji. Istnienie dobrego wsparcia PWA pozwoliłoby twierdzić, że deweloperzy nie są skazani na monopol sklepu Apple.
Ostatni konflikt USA z Huawei, które straciło nagle dostęp do Google Play, również może nasuwać w różnych miejscach świata myśl, że aplikacje dystrybuowane niezależnie od jednej korporacji mogą być dobrym rozwiązaniem.
Podsumowując, podczas gdy najwięcej szumu jest wokół w praktyce marginalnie użytecznego blockchain, to na front-endzie, z powodu rozwoju technologii Progressive Web Apps, mogą dziać się najciekawsze dla strategii wielu startupów rzeczy.Licencja: dozwolone skopiowanie ilustracji na własną stronę, pod warunkiem umieszczenia aktywnego linku do źródła. Niedozwolone kopiowanie całości lub większej części artykułu.