PWA to aplikacja webowa, która zachowuje się jak natywna: instaluje się na ekranie głównym, działa offline i wysyła powiadomienia push. Nie wymaga sklepu z aplikacjami ani osobnych zespołów dla iOS i Androida. Technologia ma już prawie dekadę, ale dopiero ostatnie lata – z lepszym wsparciem Safari na iOS – zamknęły największe luki. W tym artykule wyjaśniamy, czym jest Progressive Web App, jak ją zbudować i kiedy PWA wygrywa z aplikacją natywną.
PWA – co to jest?
Progressive Web App (PWA) to zwykła strona lub aplikacja webowa, rozbudowana o zestaw standardów przeglądarki. Dzięki nim zyskuje cechy znane z aplikacji mobilnych. Pisana jest w HTML, CSS i JavaScript, a działa w każdej nowoczesnej przeglądarce.
Słowo „progressive” oznacza progresywne ulepszanie. Każdy użytkownik dostaje działającą stronę. jeżeli jego przeglądarka obsługuje więcej funkcji, dostaje też instalację, tryb offline czy powiadomienia. Nic się nie psuje u tych, którzy ich nie mają.
Typowa PWA:
- działa przez HTTPS – to warunek bezpieczeństwa i działania service workerów,
- ma manifest – plik opisujący nazwę, ikony i sposób wyświetlania aplikacji,
- ma service worker – skrypt działający w tle, który kontroluje sieć i cache,
- jest responsywna – dopasowuje się do telefonu, tabletu i desktopu,
- da się zainstalować – uruchamia się we własnym oknie, bez paska adresu.
Skąd wzięło się PWA?
Termin „Progressive Web Apps” wprowadzili w 2015 roku Frances Berriman i Alex Russell z zespołu Google Chrome. Opisali nim aplikacje webowe, które łączą zasięg internetu z jakością doświadczenia aplikacji mobilnych.
Pomysł nie był nowy. Apple już w 2007 roku, przy premierze pierwszego iPhone’a, proponowało developerom budowanie aplikacji w technologiach webowych. Brakowało jednak narzędzi: offline, powiadomień i dostępu do nowoczesnych API. Dopiero Service Workers i Web App Manifest dały to, czego potrzebowały prawdziwe aplikacje.
Przez lata największą barierą był iOS. Przełom przyszedł w marcu 2023 roku. Safari 16.4 dodało Web Push dla aplikacji dodanych do ekranu głównego (WebKit: Web Push for Web Apps on iOS and iPadOS). Od iOS 26 witryna dodana do ekranu głównego domyślnie otwiera się jako aplikacja webowa. Dla produktów, które muszą działać na iPhone’ach, to zmieniło kalkulację.
Trzy filary PWA
1. HTTPS
Service worker przechwytuje ruch sieciowy, więc przeglądarki dopuszczają go tylko w bezpiecznym kontekście. Wyjątkiem jest localhost na czas developmentu. Certyfikat dostaniesz za darmo, np. z Let’s Encrypt albo od hostingu.
2. Web App Manifest
To plik JSON, który mówi przeglądarce, jak ma wyglądać zainstalowana aplikacja. Najważniejsze pola to:
- name i short_name – pełna nazwa i skrót pod ikoną,
- start_url – adres, który otwiera się po uruchomieniu,
- display – tryb wyświetlania (standalone, minimal-ui, fullscreen, browser),
- icons – ikony; Chrome oczekuje wersji 192×192 i 512×512 px,
- theme_color i background_color – kolory paska i ekranu startowego,
- id i scope – tożsamość aplikacji i zakres adresów, które do niej należą.
3. Service worker
Service worker to skrypt JavaScript działający w osobnym wątku, poza stroną. Pośredniczy między aplikacją a siecią. Możesz w nim zdecydować, czy odpowiedź pochodzi z cache, czy z serwera. Obsługuje też push i synchronizację w tle (tam, gdzie przeglądarka je wspiera). Nie ma dostępu do DOM, a cała komunikacja jest asynchroniczna.
Cykl życia service workera ma trzy etapy: rejestracja, instalacja (tu zwykle zapisujesz zasoby do cache) i aktywacja (tu sprzątasz stare wersje cache).
PWA – tutorial: pierwsza aplikacja krok po kroku
Zbudujemy minimalną PWA bez frameworków. Potrzebujesz edytora, Node.js i dowolnego lokalnego serwera, np. npx serve.
Krok 1: struktura projektu
moja-pwa/ ├── index.html ├── offline.html ├── app.js ├── sw.js ├── manifest.webmanifest └── icons/ ├── icon-192.png └── icon-512.pngKrok 2: manifest
Plik manifest.webmanifest:
{ "id": "/", "name": "Moja pierwsza PWA", "short_name": "MojaPWA", "start_url": "/", "scope": "/", "display": "standalone", "background_color": "#ffffff", "theme_color": "#0b5fff", "icons": [ { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }, { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" } ] }Ikona z purpose: maskable pozwala systemowi przyciąć ją do kształtu używanego na danej platformie (koło, zaokrąglony kwadrat).
Krok 3: podpięcie manifestu i rejestracja service workera
W index.html:
<link rel="manifest" href="/manifest.webmanifest"> <meta name="theme-color" content="#0b5fff"> <link rel="apple-touch-icon" href="/icons/icon-192.png">W app.js:
Krok 4: service worker z cache i trybem offline
Plik sw.js:
const CACHE = 'moja-pwa-v1'; const ASSETS = ['/', '/index.html', '/app.js', '/offline.html']; self.addEventListener('install', (event) => { event.waitUntil(caches.open(CACHE).then((cache) => cache.addAll(ASSETS))); self.skipWaiting(); }); self.addEventListener('activate', (event) => { event.waitUntil( caches.keys().then((keys) => Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k))) ) ); self.clients.claim(); }); self.addEventListener('fetch', (event) => { if (event.request.method !== 'GET') return; event.respondWith( caches.match(event.request).then((cached) => cached || fetch(event.request).catch(() => caches.match('/offline.html')) ) ); });Co tu się dzieje? Przy instalacji zapisujemy podstawowe pliki. Przy aktywacji usuwamy stare wersje cache. Przy każdym żądaniu najpierw szukamy odpowiedzi w cache, a gdy jej brak i sieć nie działa, pokazujemy stronę offline.html.
Krok 5: test
Uruchom serwer i otwórz stronę w Chrome. W DevTools wejdź w zakładkę Application. Sprawdzisz tam manifest, status service workera i zawartość cache. Przełącz Offline w zakładce Network i odśwież stronę. jeżeli widzisz aplikację albo offline.html, działa. W pasku adresu Chrome powinna pojawić się ikona instalacji.
Uwaga: Lighthouse usunął osobną kategorię „PWA” w wersji 12 (2024). przez cały czas możesz sprawdzać instalowalność w DevTools i narzędziach takich jak PWABuilder.
Strategie cache’owania: dobierz do typu zasobu
Największy wpływ na jakość PWA ma nie sam service worker, ale strategia cache’owania. Tabela poniżej pokazuje najczęstsze wzorce.
| Strategia | Jak działa | Dobre dla |
| Cache First | Najpierw cache, sieć tylko gdy brak | Fonty, obrazy, pliki z hashem w nazwie |
| Network First | Najpierw sieć, cache jako zapas | Dane, które muszą być aktualne (koszyk, stan konta) |
| Stale While Revalidate | Zwraca cache od razu, w tle odświeża | Listy produktów, awatary, treści często zmieniane |
| Network Only | Zawsze sieć | Płatności, operacje zapisu |
| Cache Only | Zawsze cache | Zasoby zapisane przy instalacji |
Nie pisz tego wszystkiego manualnie w większych projektach. Biblioteka Workbox od Google daje gotowe moduły routingu, strategii i precache’u.
Co potrafi PWA w 2026 roku?
Podstawy to instalacja, offline i push. Dziś lista możliwości jest dużo dłuższa:
- Web Push – powiadomienia także na iOS, ale tylko dla aplikacji dodanych do ekranu głównego,
- Background Sync i Periodic Background Sync – wysyłka danych po odzyskaniu sieci (Chromium),
- Badging API – licznik na ikonie aplikacji,
- Web Share / Web Share Target – udostępnianie do i z aplikacji,
- File System Access API – odczyt i zapis plików na dysku (Chromium na desktopie),
- Web Bluetooth, WebUSB, Web Serial – komunikacja ze sprzętem (Chromium),
- Geolokalizacja, kamera, mikrofon, WebAuthn – szeroko wspierane,
- App Shortcuts – skróty na ikonie aplikacji,
- Window Controls Overlay – własny pasek tytułu w aplikacjach desktopowych.
Uwaga: część tych API to wynik inicjatywy Project Fugu, rozwijanej głównie w Chromium. Safari i Firefox wspierają je wybiórczo. Zanim oprzesz na nich kluczową funkcję produktu, sprawdź aktualny stan na Can I use i w dokumentacji MDN.
Wsparcie platform: Android, iOS, desktop
Android (Chrome, Edge, Samsung Internet). To najlepsze środowisko dla PWA. Chrome tworzy tzw. WebAPK – zainstalowaną aplikację widoczną w systemie i szufladzie aplikacji. Dostajesz pełne wsparcie push, background sync i zdarzenie beforeinstallprompt, które pozwala pokazać własny przycisk „Zainstaluj”.
iOS i iPadOS (Safari). Od lat najczęstszy argument przeciwników PWA. Obraz się poprawia: jest Web Push (od iOS 16.4), Badging API i instalacja z menu „Dodaj do ekranu początkowego”. przez cały czas jednak brakuje beforeinstallprompt, więc użytkownika trzeba poinstruować manualnie. Safari nie wspiera też Web Bluetooth ani Background Sync. Apple ograniczało też przez lata trwałość danych w przeglądarce, ale zainstalowane aplikacje webowe mają od tego łagodniejsze reguły. W Unii Europejskiej w 2024 roku Apple zapowiedziało wycofanie pełnego wsparcia PWA w związku z DMA, po krytyce zrezygnowało z tego planu.
Desktop (Chrome, Edge). Zainstalowana PWA otwiera się w osobnym oknie, ma wpis w menu Start czy Launchpadzie i działa jak program. Edge pozwala też publikować PWA w Microsoft Store. Firefox na desktopie nie obsługuje instalacji PWA (na Androidzie tak).
PWA vs native: porównanie
To pytanie pada najczęściej. Odpowiedź zależy od produktu, budżetu i grupy docelowej, nie od mody.
| Kryterium | PWA | Aplikacja natywna |
| Technologia | HTML, CSS, JS, jedna baza kodu | Swift/Kotlin lub cross-platform (Flutter, React Native) |
| Dystrybucja | Link w przeglądarce, opcjonalnie sklepy | App Store, Google Play |
| Instalacja | Jedno kliknięcie, kilka KB–MB | Pobranie ze sklepu, zwykle dziesiątki MB |
| Aktualizacje | Natychmiast po wdrożeniu | Zależne od sklepu i użytkownika |
| Koszt rozwoju | Niższy – jeden zespół, jeden kod | Wyższy – osobne wersje lub dodatkowa warstwa |
| Prowizje sklepów | Brak przy własnej dystrybucji | Standardowo do 15–30% od płatności cyfrowych w sklepach |
| Dostęp do sprzętu | Ograniczony, zależny od przeglądarki | Pełny |
| Wydajność | Bardzo dobra dla większości aplikacji | Najlepsza, szczególnie w grafice i grach |
| SEO i odkrywalność | Indeksowana przez wyszukiwarki | Tylko wyszukiwarka sklepu |
| Tryb offline | Tak, ale musisz zaprojektować | Tak, pełna kontrola |
Wniosek? PWA wygrywa tam, gdzie liczy się zasięg, koszt i szybkość wdrażania. Natywna aplikacja wygrywa tam, gdzie potrzebujesz głębokiej integracji z systemem.
Przykłady z rynku
Raporty firm technologicznych pokazują, iż PWA potrafi realnie poprawić wyniki. Pamiętaj, iż to dane historyczne z lat 2017–2019. Traktuj je jako ilustrację zjawiska, nie jako aktualny benchmark.
- Twitter Lite – lekka PWA dla wolnych sieci, według zespołu Twittera dała m.in. wzrost liczby stron na sesję o 65% i spadek współczynnika odrzuceń o 20%.
- Starbucks – PWA do zamawiania ma około 233 KB, podczas gdy aplikacja na iOS ma ok. 148 MB. Firma podawała też podwojenie liczby aktywnych użytkowników dziennie.
- Pinterest – po przebudowie mobilnej strony jako PWA firma raportowała m.in. wzrost zaangażowania o 60% i dłuższy czas spędzany w serwisie.
- AliExpress, Flipkart – oba serwisy opisywały wyraźny wzrost konwersji po przejściu na PWA.
Oryginalne studia przypadków znajdziesz w bibliotece web.dev. Zanim zacytujesz liczby w prezentacji dla zarządu, sprawdź je w źródle.
PWA – zastosowania
PWA sprawdza się najlepiej tam, gdzie najważniejsze są zasięg, szybkie wdrożenie i niski próg wejścia. Oto najczęstsze scenariusze:
- E-commerce i marketplace’y – szybkie ładowanie, koszyk dostępny przy słabym zasięgu, push o porzuconym koszyku. Do tego pełne SEO, bo sklep przez cały czas jest stroną.
- Portale newsowe i media – czytanie offline, powiadomienia o najnowszych artykułach, lekki ekran startowy.
- Aplikacje wewnętrzne i B2B – panele, CRM, narzędzia dla sprzedawców i serwisantów. Nie zmuszasz firm do dystrybucji przez sklepy ani MDM, a aktualizacje wdrażasz centralnie.
- Aplikacje terenowe – kontrola jakości, inwentaryzacje, formularze zbierane offline i synchronizowane po odzyskaniu sieci.
- Fintech i usługi lekkie – podgląd salda, wnioski, status zamówień (z zastrzeżeniem regulacji i wymagań bezpieczeństwa).
- Podróże i transport – bilety, rezerwacje i mapy dostępne bez internetu.
- Narzędzia produktywności – edytory, notatniki, listy zadań, aplikacje do designu działające w przeglądarce.
- Startupy i MVP – szybka weryfikacja pomysłu przy ograniczonym budżecie.
- Rynki z drogą transmisją danych i słabym zasięgiem – lekkość PWA to tam przewaga konkurencyjna.
Kiedy PWA to zły wybór?
PWA nie jest uniwersalną odpowiedzią. Rozważ aplikację natywną, gdy:
- budujesz grę 3D lub aplikację wymagającą maksymalnej wydajności grafiki,
- potrzebujesz głębokiej integracji z systemem, np. HealthKit, zaawansowanych funkcji tła, śledzenia lokalizacji w tle czy NFC na iOS,
- Twój model biznesowy opiera się na obecności w sklepie i jego mechanizmach odkrywania,
- kluczowa funkcja zależy od API, które nie działa w Safari, a Twoi użytkownicy to głównie posiadacze iPhone’ów.
Częsty kompromis to hybryda. Zachowujesz PWA jako rdzeń, a do sklepów trafia opakowanie: Trusted Web Activity na Androidzie albo Capacitor. Wtedy zyskujesz obecność w sklepie bez dwukrotnego pisania aplikacji.
Narzędzia i frameworki
Zbudujesz PWA w czystym JavaScripcie, ale w praktyce zwykle sięgasz po gotowe narzędzia:
- Workbox – biblioteka do service workerów i strategii cache’owania,
- vite-plugin-pwa – generuje manifest i service worker dla projektów na Vite (React, Vue, Svelte),
- Angular – komenda ng add @angular/pwa konfiguruje manifest i service worker,
- Next.js – wsparcie dla manifestu w App Routerze oraz biblioteki takie jak Serwist do obsługi service workera,
- Nuxt – moduł @vite-pwa/nuxt,
- PWABuilder – narzędzie Microsoftu do analizy PWA i pakowania do Microsoft Store oraz Google Play.
Najczęstsze błędy przy budowie PWA
- Cache bez strategii aktualizacji. Użytkownik utknie na starej wersji. Wersjonuj cache i pokaż komunikat „Dostępna nowa wersja”.
- Cache’owanie wszystkiego. Nie zapisuj odpowiedzi API z danymi wrażliwymi ani zapytań typu POST.
- Brak ekranu offline. Pusta biała strona to najgorszy możliwy efekt.
- Ignorowanie iOS. Przetestuj instalację na prawdziwym iPhonie. Emulator i DevTools nie pokażą wszystkich ograniczeń.
- Brak własnego przycisku instalacji. Na Androidzie i desktopie obsłuż beforeinstallprompt, na iOS pokaż krótką instrukcję.
- Zbyt wielki bundle. PWA przez cały czas musi się gwałtownie ładować. Mierz Core Web Vitals, nie tylko obecność manifestu.
- Zapominanie o bezpieczeństwie. Service worker ma szeroką kontrolę nad ruchem, więc pilnuj zakresu (scope), nagłówków i polityki CSP.
Podsumowanie
PWA dojrzało. Nie zastępuje każdej aplikacji natywnej, ale dla wielu produktów – sklepów, portali, narzędzi B2B, aplikacji terenowych i MVP – jest najszybszą i najtańszą drogą do użytkownika. Jedna baza kodu, natychmiastowe aktualizacje i brak prowizji sklepów to argumenty, które trudno zignorować.
Największym ograniczeniem pozostają różnice między przeglądarkami, zwłaszcza w Safari. Dlatego zacznij od analizy: jakie funkcje są najważniejsze i na jakich urządzeniach siedzą Twoi użytkownicy? jeżeli wystarczą Ci API szeroko wspierane, PWA to bezpieczny wybór.
