Progressive Web App voor webshops — de ROI berekening

Progressive Web App voor webshops — de ROI berekening

Een PWA bouwen kost je tussen de €15.000 en €80.000. De kans dat je die investering terugverdient? Kleiner dan de meeste vendors je vertellen. Dat is niet cynisch — het is rekenwerk.

In dit artikel leg je naast de echte meerwaarde van een Progressive Web App ook de eerlijke kostenpost. Want voor de meeste webshops is het antwoord simpel: optimaliseer eerst je bestaande site. Alleen als die optimalisaties het plafond raken, is een PWA het gesprek waard.

Wat een PWA wel en niet oplost

Een Progressive Web App is geen magische snelheidsboost. Het is een set browser-API's die je site native app-achtig gedrag geeft. Drie concrete voordelen:

Via een Service Worker cache je assets, productpagina's en zelfs checkout-stappen lokaal. Bij een slechte verbinding werkt je site toch. Nuttig voor gebruikers in de trein of een slecht 4G-gebied. Voor de gemiddelde Nederlandse webshop is dit zelden een conversieblokkade.

Gebruikers kunnen je shop installeren op hun homescreen zonder de App Store. Engagement bij geinstalleerde PWA's ligt doorgaans 2-3x hoger dan bij mobile web — maar alleen als je gebruikers ook terugkomen. Voor een shop met veel repeat-buyers (mode, abonnementen, FMCG) is dit relevant. Voor een eenmalige aankoopflow niet.

Native push notifications zonder eigen app. Open rates liggen gemiddeld rond de 10-20%, ver boven e-mail. Dit is het sterkste argument voor PWA als je een loyale klantenbasis wilt activeren.

Wat een PWA niet oplost:

• Trage backend of ongecachede API calls
• Slechte server response times (TTFB boven 600ms)
• Bloated JavaScript bundles die de main thread blokkeren
• Slechte productfeed- of zoekprestaties

Als je Core Web Vitals rood staan door een trage server of zware JavaScript, los dat dan eerst op. Een PWA laag erbovenop lost het onderliggende probleem niet op.

De echte performance-winst: wat zeggen de cijfers?

Google meldt dat elke 100ms verbetering in laadtijd de conversie met 1% verhoogt. Dat klinkt goed, maar de absolute impact hangt af van je startpunt.

Wij zien bij klanten dat een Magento 2-shop op een matige hostingomgeving een TTFB van 1,2–2,0 seconden heeft. Migreren naar een PWA lost dat niet op — de API calls blijven bestaan. Optimaliseer je de server-side caching (Redis, Varnish) en gooi je onnodige JavaScript eruit, dan win je 400–800ms zonder PWA-investering.

Een PWA voegt typisch toe:

De winst zit vooral in herhaalde bezoeken. Voor een shop met hoge klantretentie is dat relevant. Voor een shop met 80% nieuwe bezoekers per sessie nauwelijks.

Implementatieaanpak: drie routes

Route 1: Hyva PWA (Magento 2)

• Bouw voort op bestaande Hyva-theme
• Service Worker via Workbox configureren
• Web App Manifest toevoegen voor A2HS
• Push notifications via een externe service (OneSignal, Firebase FCM)

Reken op 3–6 weken ontwikkeltijd voor een solide implementatie. De basis PWA-features (offline cache, manifest, installability) zijn sneller te realiseren; geavanceerde offline checkout of sync-mechanismen kosten significant meer tijd.

// Voorbeeld: minimale manifest.json voor een Magento/Hyva PWA
{
  "name": "Naam van je webshop",
  "short_name": "Webshop",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0A0A0A",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

Route 2: Shopify Hydrogen (headless PWA)

Shopify's gewone storefront is al goed geoptimaliseerd. Een Service Worker laag erbovenop is technisch mogelijk maar beperkt in wat je kunt cachen vanwege Shopify's CDN-architectuur. Wil je echt een PWA op Shopify, kies dan bewust voor Hydrogen — of accepteer dat je met de standaard storefront al 90% van de performance-winst haalt.

Route 3: Maatwerk Laravel/Headless

Voor Laravel maatwerk-applicaties is een PWA vaak de logischste keuze. Je bouwt toch al een custom frontend — dan is een Service Worker en manifest erbij een relatief kleine extra stap.

Werkwijze:

1. Bouw de frontend als een SPA of SSR-app (React, Vue, of server-side rendered blade)
2. Voeg Workbox toe voor Service Worker management
3. Implementeer push notifications via Laravel Notifications + FCM driver
4. Configureer cache-strategie per route-type (stale-while-revalidate voor productpagina's, network-first voor checkout)

// Laravel: FCM push via laravel-notification-channels/fcm
// composer require laravel-notification-channels/fcm

class OrderShippedNotification extends Notification
{
    public function via($notifiable): array
    {
        return [FcmChannel::class];
    }

    public function toFcm($notifiable): FcmMessage
    {
        return FcmMessage::create()
            ->setNotification(
                FcmNotification::create()
                    ->setTitle('Je bestelling is verzonden')
                    ->setBody('Verwachte levering: morgen voor 17:00')
            )
            ->setData(['order_id' => $this->order->id]);
    }
}

De ROI-rekenstap: eerlijk doorrekenen

Hier wordt het concreet. Trek een PWA-project pas wanneer de verwachte opbrengst de investering overtreft — met een redelijke terugverdientijd.

Reken conservatief. Stel: je webshop maakt €500.000 omzet per jaar. Je mobiele conversieratio is 1,2% en de desktop-ratio is 2,8%.

Een PWA kan realistisch 0,2–0,4 procentpunt toevoegen aan je mobiele conversieratio — maar alleen als de slechte performance nu de bottleneck is, en je veel terugkerende bezoekers hebt.

Voorbeeld:

• Huidig mobiel verkeer: 60.000 sessies/jaar
• Huidig mobiele omzet: 60.000 × 1,2% × €85 gem. orderwaarde = €61.200
• Na PWA (optimistisch): 60.000 × 1,5% × €85 = €76.500
• Winst: €15.300/jaar

Bij een investering van €25.000 duurt het terugverdienen bijna twee jaar. Dat is inclusief nul onderhoud en nul verhoging in bounce rate door bugs.

Wij zien in de praktijk dat shops met een conversieratio boven de 2% op mobiel veel minder te winnen hebben dan shops die onder de 1% zitten. Voor die laatste groep geldt echter eerst: ligt het aan performance, of aan UX, pricing, of vertrouwen?

Bijna altijd. Controleer eerst:

• Core Web Vitals (LCP, INP, CLS) — zijn die groen?
• TTFB onder 600ms?
• JavaScript bundle onder 200KB gzipped?
• Afbeeldingen geoptimaliseerd (WebP, lazy load, juiste formaten)?
• Checkout flow getest op mobiel met echte gebruikers?

Wij zien bij klanten dat een gerichte performance-audit van €3.000–€6.000 meer oplevert dan een volledig PWA-traject. Repareer het fundament voordat je een extra verdieping bouwt.

Wanneer is een PWA WEL de juiste keuze?

Er zijn situaties waarin de rekenstap wél uitkomt:

1. Hoge klantretentie — Fashion, abonnementen, herhaalaankopen. Push notifications en A2HS zijn dan concrete omzetdrivers.
2. Bewezen performance-plafond — Je hebt alles geoptimaliseerd, Core Web Vitals staan groen, en je wilt nog snellere herhaalde navigatie.
3. Doelgroep met wisselende connectiviteit — B2B-apps voor vertegenwoordigers, agrarische sectoren, evenementen-commerce.
4. Maatwerk-applicatie — Je bouwt toch al een custom frontend. Dan kost een PWA relatief weinig extra.
5. App Store-alternatief — Je wilt push notifications en installabiliteit zonder de overhead van een native app (€80.000–€200.000+).

Conclusie: optimaliseer eerst, PWA daarna

Een PWA is een legitiem middel, maar geen wondermiddel. De meeste webshops hebben een groter rendement bij een gerichte performance-optimalisatie dan bij een volledige PWA-implementatie.

Stel jezelf twee vragen:

1. Zijn mijn Core Web Vitals groen en is mijn mobiele conversieratio boven het branchegemiddelde?
2. Heb ik voldoende terugkerende bezoekers om van push notifications en A2HS te profiteren?

Als het antwoord op beide vragen nee is, begin dan niet met een PWA.

Wil je weten waar je nu staat? Neem contact op — wij kijken met je mee naar de cijfers en adviseren zonder verkoopagenda.

Veelgestelde vragen

Een native app staat in de App Store, heeft toegang tot meer device-API's en werkt altijd offline. Een PWA draait in de browser, is sneller te bouwen, en heeft geen App Store-distributie nodig. Voor de meeste webshops biedt een PWA 70–80% van de native app-voordelen tegen 20–30% van de kosten.

Ja, maar beperkt. Safari ondersteunt Service Workers en Web App Manifest, maar push notifications via het web zijn pas beschikbaar vanaf iOS 16.4 — en alleen als de gebruiker de PWA heeft geinstalleerd. Op Android is de ondersteuning vollediger. Reken er dus niet op dat push notifications alle iOS-gebruikers bereiken.

Ja. Met Hyva als frontend is dat de meest pragmatische route. Op een standaard Luma-theme is het technisch mogelijk maar raden wij sterk af — de JavaScript-payload is al te zwaar, een Service Worker erbij maakt het niet beter.

Een basisimplementatie (manifest, Service Worker, A2HS) duurt 3–6 weken. Een volledig uitgerolde PWA met push notifications, offline checkout en achtergrond-sync kost 10–16 weken. De planning hangt sterk af van de complexiteit van je huidige frontend en de integraties die je gebruikt.