Wat is een Progressive Web App (PWA)?

Een Progressive Web App, afgekort PWA, is een website die zich gedraagt als een app. Je kunt hem op je beginscherm zetten, hij opent zonder adresbalk, en hij werkt deels zonder internet.

Er komt geen app-winkel aan te pas. Het is dezelfde site, met een paar toevoegingen die de browser herkent. De term komt uit 2015 en beschreef toen een nieuwe mogelijkheid: een site die zich kon gedragen als een app zonder er een te zijn.

Wat het technisch is

Drie onderdelen maken een website tot een PWA.

Een manifest. Een klein tekstbestand met de naam, het pictogram, de kleuren en het startadres. Daarin staat ook of de app zonder adresbalk moet openen en welk deel van je site erbij hoort. Lever je pictogrammen aan in 192 en 512 pixels, plus een versie die het besturingssysteem zelf mag bijsnijden. Doe je dat niet, dan krijg je een wit vierkantje op het beginscherm.

Een service worker. Een stukje JavaScript dat tussen je site en het netwerk zit. Elk verzoek van je pagina gaat er eerst langs. Die code kan bestanden bewaren en later opnieuw uitserveren, zodat de site ook laadt zonder verbinding.

Een beveiligde verbinding. Https is verplicht, want een service worker die verzoeken kan onderscheppen wil je niet over een open lijn. Zonder geldig certificaat registreert de browser hem simpelweg niet.

Meer is het niet. Een bestaande site kun je hiermee uitbreiden zonder hem opnieuw te bouwen. Bezoekers die er niets van merken, houden gewoon een website.

Hoe iemand hem op zijn scherm krijgt

Op Android doet Chrome zelf een voorstel zodra je site aan de voorwaarden voldoet en iemand er een paar keer is geweest. Ga je akkoord, dan wordt er een echt installatiepakket gebouwd en verschijnt je site tussen de andere apps, met een eigen venster en een eigen plek in het overzicht van geopende apps.

Op de desktop werkt het vergelijkbaar in Chrome en Edge: een pictogram in de adresbalk waarmee je de site als los venster installeert.

Op iOS gaat het anders en dat is het grootste struikelblok. Safari doet geen voorstel. De bezoeker moet zelf op het deelpictogram tikken en daar "Zet op beginscherm" kiezen. Dat weet vrijwel niemand uit zichzelf.

Verwacht je iets van een PWA op iPhones, dan moet je dat op de pagina zelf uitleggen, met een afbeelding van de knop erbij. Zonder die uitleg installeert niemand hem. Toon hem alleen op iOS; op Android is hij verwarrend.

Wat het oplevert

• Sneller na het eerste bezoek. Bestanden komen uit het geheugen van het apparaat in plaats van van de server. Dit is voor de meeste sites de grootste winst.
• Werkt bij een slechte verbinding. In plaats van de foutmelding van de browser krijgt de bezoeker de pagina die al was opgeslagen, of een eigen pagina met uitleg.
• Op het beginscherm. Een pictogram tussen de andere apps, zonder installatie via een winkel en zonder de drempel van honderden megabytes.
• Eén versie onderhouden. Geen aparte app voor iOS en Android naast je website, en geen goedkeuringsprocedure bij elke wijziging.
• Gewoon vindbaar. Het blijft een website, dus zoekmachines kunnen erbij en je kunt naar elke pagina linken. Bij een echte app kan dat niet.

Wat je erbij moet bedenken: de eerste twee punten haal je ook met een site die gewoon goed is opgezet. De unieke winst van een PWA zit in het pictogram op het scherm en in wat je zonder verbinding kunt blijven doen.

Waarin het verschilt van een echte app

Op Android is het verschil klein geworden. Op iOS is het dat niet.

Apple ondersteunt PWA's beperkt en met horten en stoten. Service workers werken er sinds 2018. Pushberichten werken er pas sinds iOS 16.4, uitgebracht in het voorjaar van 2023, en alleen als de gebruiker de site eerst op zijn beginscherm heeft gezet.

Verder mis je wat een echte app wel kan: achtergrondprocessen die doorlopen als de app dicht is, diepe toegang tot sensoren, en aanwezigheid in de app-winkel. Dat laatste is voor sommige bedrijven de hoofdreden om een app te willen, los van wat de app doet.

Je kunt een PWA overigens alsnog in de Play Store krijgen door hem in een schil te verpakken; daar bestaat gereedschap voor. Bij Apple lukt dat zelden, want een app die weinig meer doet dan een website tonen wordt bij de beoordeling geweigerd.

Wat wel en niet kan per apparaat

De lijst met dingen die een website mag verandert per browser en per jaar. Grofweg ziet het er zo uit.

Overal beschikbaar: locatie, camera en microfoon na toestemming, het deelvenster van het besturingssysteem, betalen via de betaalinterface van de telefoon, en inloggen met vingerafdruk of gezichtsherkenning via passkeys. Dat laatste is voor een ledenportaal vaak het onderdeel dat een app overbodig maakt.

Alleen in browsers op basis van Chromium: bestanden op de schijf lezen en schrijven, een teller op het pictogram, verzoeken die later worden verstuurd zodra er weer verbinding is, en verbindingen met bluetooth, usb of seriële apparaten.

Op iOS niet beschikbaar: bluetooth, nfc, achtergrondtaken en toegang tot contacten. Wie een app wil bouwen die een pinapparaat of een sensor moet aansturen, komt op iPhones niet ver met een PWA.

Kijk bij een plan dus eerst welke van deze onderdelen je echt nodig hebt, en of ze op de telefoons van jouw doelgroep bestaan. Dat is een halfuur uitzoekwerk dat een verkeerd project voorkomt.

Wanneer het loont

Als je bezoekers vaak terugkomen. Een PWA is vooral waardevol bij herhaald gebruik: een bestelsysteem, een ledenportaal, een planningsoverzicht, een dienstrooster.

Als je publiek matige verbindingen heeft. Buitendienstmedewerkers, monteurs in kruipruimtes, evenementen met tienduizend telefoons op één mast, of gebieden met slechte dekking.

Als je een app wilt maar het budget en het onderhoud niet hebt. Een echte app bouwen en bijhouden voor twee besturingssystemen is een structurele kostenpost die veel bedrijven onderschatten, met elk jaar nieuwe versies van iOS en Android die iets breken.

Bereik weegt hier bovendien zwaarder dan diepte. Een PWA werkt vanaf de eerste klik, zonder dat iemand eerst iets installeert. Elke stap die je weghaalt, scheelt mensen die anders afhaken.

Wanneer het niet loont

Bij een gewone bedrijfssite die mensen één keer bezoeken. Niemand zet de site van zijn loodgieter op zijn beginscherm, hoe goed die site ook is.

Als je de winst ook op een andere manier kunt halen. Voor snelheid zijn goede caching op de server, gecomprimeerde afbeeldingen en minder scripts effectiever en eenvoudiger. Begin daar, en lees het artikel over mobiele optimalisatie voordat je aan een PWA denkt.

En bij toepassingen die echt de hardware in moeten. Een app die achtergrondlocatie bijhoudt of met apparatuur praat, hoort een echte app te zijn.

Hoe je er een bouwt

De volgorde is eigenlijk altijd dezelfde.

Begin bij het doel. Wat moet er werken zonder verbinding, en voor wie. "Offline werken" is geen doel; "de monteur kan zijn werkbon invullen in een kelder" wel. Die ene zin bepaalt de rest van het werk.

Zorg daarna dat je site zonder PWA al goed is. Responsive opmaak, snel, met een fatsoenlijke navigatie. Een PWA maakt een trage site niet snel; hij bewaart alleen wat er is.

Voeg dan het manifest toe en registreer een service worker. Voor een bestaande site is dat vaak een middag werk. Bij WordPress bestaan plugins die het manifest en een eenvoudige service worker voor je regelen; dat is genoeg voor het pictogram op het beginscherm en een offlinepagina.

Bouw je een webapplicatie, dan zit het in je framework. React, Vue en de bijbehorende bouwgereedschappen leveren dit standaard mee, meestal via een bibliotheek van Google die de cachestrategieën al bevat. Zelf een service worker schrijven is leerzaam en zelden verstandig.

Zet het geheel eerst op een testadres. Een service worker die eenmaal bij echte bezoekers draait, bepaalt mede wat zij te zien krijgen, en dat wil je niet uitproberen op je eigen klanten.

De service worker is het lastige deel

Hier gaat het mis, en het gaat op een manier mis die je niet ziet als je zelf test.

Een service worker heeft drie momenten: installeren, actief worden, en daarna elk netwerkverzoek afhandelen. Bij dat laatste kies je een strategie. Eerst uit de cache en anders van het netwerk is snel en riskant. Eerst het netwerk en anders de cache is veilig en langzamer. Eerst de cache tonen en op de achtergrond verversen zit ertussenin en is voor de meeste sites de juiste keuze.

Het klassieke probleem: een nieuwe versie van je service worker wordt wel opgehaald, maar wordt pas actief als alle tabbladen van je site gesloten zijn. Iemand die je site altijd open heeft staan, blijft dus wekenlang de oude versie zien. Dat is bij ontwerp zo bedoeld en het verklaart bijna alle meldingen dat een wijziging "niet doorkomt".

Los dat op door je bezoeker te vertellen dat er een nieuwe versie is, met een knop om te herladen. Wees voorzichtig met een instelling die de nieuwe versie meteen doordrukt, want dan kan iemand halverwege een handeling ineens met twee versies tegelijk te maken krijgen.

Zorg daarnaast dat je weet hoe je alles opruimt: in de ontwikkelaarshulpmiddelen van je browser kun je de service worker uitschrijven en het opgeslagen geheugen wissen. Weet dat voordat je live gaat, niet daarna.

Vindbaarheid in zoekmachines

Een PWA is een website, dus alle gewone regels gelden. Elke pagina heeft een eigen adres, een eigen titel en een eigen omschrijving nodig, precies zoals bij indexering door zoekmachines hoort.

Wat je moet weten: de zoekrobot van Google voert je service worker niet uit. Hij haalt elke pagina op alsof hij er voor het eerst komt. Alles wat je alleen in de cache zet, of alleen na een tweede bezoek toont, bestaat voor Google niet.

Het grotere risico zit bij applicaties die hun inhoud volledig met JavaScript opbouwen. Wordt er in de eerste reactie van de server alleen een leeg vak teruggegeven, dan is de kans groot dat je pagina's slecht of laat worden opgenomen. De oplossing is de pagina op de server opbouwen of vooraf klaarzetten.

Controleer dit door in Search Console te kijken hoe Google je pagina rendert. Dat is de enige manier om zeker te weten dat er tekst staat waar jij tekst verwacht.

Pushberichten

Pushberichten zijn voor veel bedrijven de reden om een PWA te overwegen, en ze zijn tegelijk de snelste manier om bezoekers kwijt te raken.

Technisch heb je toestemming van de browser nodig. Vraag die op het moment dat het logisch is, bijvoorbeeld nadat iemand een bestelling heeft geplaatst, en niet drie seconden na binnenkomst. Weigert iemand, dan kun je het niet nog een keer vragen; die keuze blijft staan.

Op iPhones bereik je alleen de mensen die de site op hun beginscherm hebben gezet. Een flink deel van je publiek blijft dus buiten bereik.

Inhoudelijk gelden dezelfde afwegingen als bij andere directe berichten: alleen sturen wat de ontvanger wil hebben, en een eenvoudige manier bieden om ermee te stoppen. Wat er verder bij komt kijken staat in het artikel over pushnotificaties.

Waar bedrijven het inzetten

In de detailhandel voor bestellen en sparen. Een klantenkaart in je beginscherm die ook werkt als de winkel geen bereik heeft, is nuttiger dan een app die niemand installeert.

Bij opleidingen en cursussen om lesmateriaal beschikbaar te houden in de trein. Video's zijn daar de uitzondering: die bewaar je niet zomaar in de cache, want dan loopt de opslag van het toestel vol.

In transport en logistiek voor ritinformatie en het aftekenen van leveringen, precies op de plekken waar dekking wegvalt. Dit is de toepassing waar de offline-mogelijkheid echt geld oplevert.

Bij financiële diensten voor het inzien van gegevens. Betalen en identificeren gaat er meestal alsnog via een echte app, omdat de eisen aan beveiliging en aan de opslag van sleutels daar strenger zijn.

Voor een bedrijf met vijf man is de meest voorkomende zinnige toepassing een intern hulpmiddel: een uren- of werkbonformulier dat je collega's op hun scherm zetten. Geen app-winkel, geen beheer van toestellen, en je past het aan wanneer je wilt.

Testen en meten

Open de ontwikkelaarshulpmiddelen van Chrome en ga naar het tabblad voor applicaties. Daar zie je of je manifest wordt gelezen, of je service worker draait, en wat er in de cache staat. Je kunt er ook de offlinemodus aanzetten om te controleren wat er gebeurt zonder verbinding.

Lighthouse had jarenlang een aparte categorie die controleerde of je aan de voorwaarden voldeed. Google heeft die in 2024 verwijderd. Kom je een handleiding tegen die naar de PWA-score in Lighthouse verwijst, dan is die verouderd.

Wat je in plaats daarvan meet: laadt je site sneller voor terugkerende bezoekers, hoeveel mensen installeren hem daadwerkelijk, en komen die vaker terug dan de rest. Dat laatste is het enige cijfer dat de investering rechtvaardigt.

Test verder op een echte iPhone en een echte Android-telefoon, en het liefst op een toestel dat niet je nieuwste is. Wat op Android soepel werkt kan op iOS anders uitpakken.

Waar het misgaat

Een oude versie die blijft hangen. Verreweg de meest voorkomende klacht, en bijna altijd een verkeerd ingestelde service worker. Zorg dat je bezoeker een nieuwe versie krijgt aangeboden.

Te vroeg om installatie vragen. Een melding die na drie seconden vraagt of je de app wilt toevoegen is even irritant als een nieuwsbriefvenster. Wacht tot iemand iets heeft gedaan.

Gevoelige gegevens in de cache. Wat je opslaat staat op het toestel en blijft daar staan, ook op een gedeelde telefoon. Zet er niets in dat je niet op een gevonden toestel zou willen aantreffen, en ruim op bij uitloggen.

Te veel bewaren. Een service worker die alle afbeeldingen opslaat, vult de opslag van het toestel. Stel een maximum in en gooi het oudste weg.

Rekenen op offline zonder plan. Wat gebeurt er met een formulier dat iemand zonder verbinding verstuurt? Zonder antwoord op die vraag verliest je gebruiker zijn werk, en dat is erger dan een foutmelding vooraf.

Vergeten dat Safari opruimt. Bezoekt iemand een site een tijd niet, dan kan Safari opgeslagen gegevens weggooien. Bewaar er dus geen dingen in die alleen daar bestaan.

Wat er de laatste jaren veranderd is

De grootste verandering kwam in 2023, toen pushberichten op iOS eindelijk mogelijk werden voor sites op het beginscherm. Daarmee verdween het argument dat een PWA op iPhones nutteloos was.

Begin 2024 kondigde Apple aan dat het in de Europese Unie zou stoppen met web-apps op het beginscherm, als gevolg van de nieuwe Europese regels voor grote platformen. Na kritiek uit de sector en vragen vanuit Brussel draaide Apple dat binnen enkele weken terug. Het laat wel zien hoe afhankelijk deze techniek is van één leverancier.

In diezelfde Europese regels zit dat Apple sinds 2024 andere browsermotoren op iPhones moet toelaten. Daar is in de praktijk nog weinig van terechtgekomen, dus reken voorlopig op wat Safari kan.

En het web zelf kan meer dan een paar jaar geleden: inloggen met passkeys, betalen via de telefoon en bestanden bewerken zijn erbij gekomen. De kloof met een echte app is smaller geworden, en op iOS blijft hij bestaan.

Veelgestelde vragen over Progressive Web Apps

Wat is het verschil tussen een PWA en een gewone website?

Een PWA is een gewone website met drie toevoegingen: een manifest met de naam en het pictogram, een service worker die bestanden kan bewaren, en een beveiligde verbinding. Daardoor kun je hem installeren op je beginscherm en werkt hij deels zonder internet. Voor bezoekers die dat niet gebruiken is het gewoon je website.

Werkt een PWA op iPhone?

Ja, met beperkingen. Installeren kan alleen handmatig via het deelvenster in Safari, en pushberichten werken pas sinds iOS 16.4 en alleen als de site op het beginscherm staat. Bluetooth, nfc en achtergrondtaken zijn er niet beschikbaar.

Heb ik https nodig voor een PWA?

Ja, dat is een harde voorwaarde. Zonder geldig certificaat registreert de browser de service worker niet en werkt er niets van de PWA-functies. Bij vrijwel elke hostingpartij zit een gratis certificaat inbegrepen.

Kan ik een PWA in de App Store of Play Store zetten?

In de Play Store lukt dat door je PWA in een schil te verpakken; daar bestaat gereedschap voor van Google. Bij Apple wordt een app die weinig meer doet dan een website tonen doorgaans geweigerd bij de beoordeling. Reken er dus niet op.

Wat kost het om een PWA te maken?

Als aanvulling op een bestaande site is het manifest plus een eenvoudige service worker meestal een middag werk. Wil je echt offline kunnen werken met formulieren die later worden verstuurd, dan is het een project van weken, want dan moet je bedenken wat er met gegevens gebeurt die nog niet zijn aangekomen.

Is een PWA beter dan een native app?

Niet beter, wel goedkoper en sneller aan te passen. Een echte app wint zodra je diep in de hardware moet of achtergrondtaken nodig hebt. Een PWA wint zodra bereik, onderhoud en kosten zwaarder wegen dan die laatste procenten aan mogelijkheden.

Waarom ziet mijn bezoeker een oude versie van mijn site?

Omdat de service worker die versie heeft bewaard. Een nieuwe service worker wordt pas actief als alle tabbladen van je site gesloten zijn. Bouw daarom een melding in die vertelt dat er een nieuwe versie klaarstaat, met een knop om te herladen.

Is een PWA goed voor SEO?

Hij is niet beter of slechter dan een gewone website, met één aandachtspunt: de zoekrobot voert je service worker niet uit. Alles wat alleen uit de cache komt of pas bij een tweede bezoek verschijnt, ziet Google niet. Bouw je de pagina volledig met JavaScript op, laat hem dan op de server opbouwen.

Hoeveel gegevens kan een PWA offline bewaren?

Dat verschilt per browser en per apparaat en hangt af van de vrije ruimte. Ga uit van tientallen megabytes als veilige ondergrens en bouw je app zo dat hij blijft werken als er minder beschikbaar is. Grote video's zijn hier geen goed idee.

Kan een PWA pushberichten sturen?

Ja, na toestemming van de gebruiker. Op Android en op de desktop werkt dat al jaren, op iOS sinds 2023 en alleen voor sites die op het beginscherm staan. Vraag die toestemming op een logisch moment, want een weigering kun je niet ongedaan maken.

Werkt een PWA ook op een computer?

Ja. In Chrome en Edge kun je een site installeren als los venster zonder adresbalk, met een eigen pictogram in je taakbalk. Voor interne hulpmiddelen is dat prettig, want collega's hoeven dan geen adres meer in te typen.

Welk framework heb ik nodig voor een PWA?

Geen. Een manifest en een service worker kun je aan elke site toevoegen, ook aan een WordPress-site via een plugin. Bouw je een webapplicatie, dan leveren React, Vue en vergelijkbare frameworks het standaard mee via een bibliotheek die de cachestrategieën al bevat.

Hoe weet ik of mijn bezoekers de PWA installeren?

De browser stuurt een gebeurtenis bij een installatie die je kunt meten in je statistiekenpakket. Meet daarnaast hoeveel bezoek er binnenkomt in de vorm zonder adresbalk, want dat zijn de mensen die hem vanaf hun beginscherm openen. Zijn dat er nauwelijks, dan is de installatie te goed verstopt of het aanbod niet aantrekkelijk genoeg.

Vervangt een PWA mijn website?

Nee, hij is je website. Er is geen aparte versie en geen aparte inhoud: dezelfde pagina's zijn zowel via een zoekmachine bereikbaar als vanaf het beginscherm. Dat is precies waarom het onderhoud goedkoper is dan bij een app naast een site, en waarom je aan de gebruikerservaring maar één keer hoeft te werken.