Czym jest progresywna aplikacja webowa (PWA) i czy warto ją mieć?

Progresywna aplikacja webowa, w skrócie PWA, to strona internetowa zbudowana tak, by po kilku wizytach zachowywała się jak zainstalowana aplikacja. Można ją dodać do ekranu głównego telefonu, może działać offline lub przy słabym połączeniu i może wysyłać powiadomienia push – wszystko to bez pośrednictwa sklepu z aplikacjami. Pod spodem to wciąż strona internetowa. Różnicę robi kilka funkcji przeglądarki nałożonych na wierzch: service worker, który buforuje zasoby i obsługuje logikę offline, manifest aplikacji webowej, który mówi przeglądarce, jak wyświetlić ikonę i ekran powitalny, oraz HTTPS, którego to wszystko domyślnie wymaga.

Co faktycznie zyskujecie

Realne, praktyczne korzyści z przekształcenia strony w PWA sprowadzają się do trzech rzeczy.

• Niezawodność przy słabej sieci. Service worker może serwować z pamięci podręcznej strony i zasoby, gdy sieć zawiedzie, więc aplikacja nie robi się pusta w chwili utraty zasięgu. W przypadku treści, które nie zmieniają się co sekundę, już samo to bywa warte zachodu.
• Instalacja bez instalowania. Stronę można dodać do ekranu głównego dwoma dotknięciami – bez weryfikacji w sklepie z aplikacjami, bez harmonogramu publikowania aktualizacji i bez oczekiwania na zatwierdzenie, które stoi między poprawką a osobą korzystającą z aplikacji.
• Powiadomienia push, które kiedyś były zarezerwowane dla aplikacji, a dziś (za zgodą użytkownika) działają bezpośrednio z przeglądarki na większości platform.

Czego PWA nie zastąpi

PWA nie w każdym przypadku zastąpi aplikację natywną i warto uczciwie powiedzieć, gdzie ma braki. Głęboka integracja z systemem operacyjnym – Bluetooth, śledzenie lokalizacji w tle, rozbudowany dostęp do aparatu czy NFC, złożona synchronizacja danych offline – wciąż działa lepiej, a czasem jest w ogóle możliwa tylko w aplikacji natywnej. Obsługa funkcji PWA na iOS historycznie pozostawała w tyle za Androidem, więc jeśli wasi użytkownicy korzystają głównie z iPhone'ów, a potrzebujecie powiadomień push w tle lub zaawansowanego działania offline, przetestujcie konkretne funkcje, zanim zdecydujecie się na PWA – zamiast zakładać, że wszystko zadziała tak samo jak na Androidzie.

PWA domyślnie nie pojawi się też w App Store ani w Google Play, co ma znaczenie, jeśli optymalizacja pod sklepy z aplikacjami (ASO) i wyszukiwanie w sklepach mają być jednym z waszych kanałów pozyskiwania użytkowników.

Czy potrzebujecie PWA?

Pytanie, które naprawdę ma znaczenie, nie brzmi „czy PWA to coś fajnego”, tylko „czy główny scenariusz użycia mojego produktu wymaga czegoś, czego strona z service workerem nie jest w stanie zapewnić”. Serwis z treściami, sklep internetowy, narzędzie do rezerwacji, wewnętrzny panel, aplikacja z ogłoszeniami na marketplace – to zwykle mocni kandydaci na PWA, bo ich wartość tkwi w szybkim dostępie do informacji i kilku jasno określonych akcjach, a nie w głębokiej integracji ze sprzętem.

Kilka uczciwych sygnałów, że PWA to dobry wybór:

• Użytkownicy odwiedzają stronę na tyle często, że opcja „dodaj do ekranu głównego” rzeczywiście będzie używana, a nie ignorowana.
• Słaba łączność to realny, powtarzający się problem dla znaczącej części waszych użytkowników – serwis w terenie, dostawy, obszary wiejskie lub rynki, na których dominuje internet mobilny.
• Chcecie wdrażać poprawki i nowe funkcje we własnym tempie, a nie zgodnie z cyklem weryfikacji w sklepie z aplikacjami.
• Nie potrzebujecie przetwarzania w tle, głębokiej integracji z systemem ani obecności w sklepach z aplikacjami jako głównego kanału pozyskiwania użytkowników.

Jeśli większość tych punktów was nie dotyczy albo aplikacja jest z natury mobile-first i intensywnie korzysta z aparatu, lokalizacji w tle czy sprzętu, lepszą inwestycją będzie zwykle aplikacja natywna lub wieloplatformowa – a PWA zawsze można później zbudować jako lekkie uzupełnienie.

Co obejmuje budowa PWA

Nie jest to już żadna egzotyczna technologia – service workery i manifesty aplikacji webowych są obsługiwane przez wszystkie główne nowoczesne przeglądarki – ale dobre wykonanie wymaga czegoś więcej niż dorzucenia pliku manifestu. Kluczowa jest strategia buforowania: zbyt agresywne buforowanie sprawi, że po wdrożeniu użytkownicy będą widzieć nieaktualne treści, a zbyt oszczędne – że stracicie korzyści z trybu offline. Ikony i ekrany powitalne trzeba wygenerować w odpowiednich rozmiarach dla każdej platformy. A całość należy przetestować na prawdziwych urządzeniach, nie tylko w emulatorze narzędzi deweloperskich na komputerze, bo monity instalacji i działanie offline wyraźnie różnią się między Androidem a iOS.

Tym właśnie zajmujemy się w Burncode w ramach projektów webowych: od początku poprawnie wbudowujemy w stronę logikę buforowania i działania offline, zamiast doklejać plik manifestu na sam koniec – tak, by aplikacja po dodaniu do ekranu głównego naprawdę działała tak, jak ludzie tego oczekują.