Vad är PWA? Mobilapp eller webb?

01Vad betyder Progressive Web App?

Progressive web app är ett arbetssätt som ger en vanlig webbplats appfunktioner. Användaren öppnar sidan i webbläsaren och lägger, om hen gillar den, till den på startskärmen med en enda tryckning. Vid nästa besök startar den som en app, utan adressfält, med egen ikon och startskärm.

Ordet ”progressive” i namnet är viktigt. Appen får så mycket funktionalitet som webbläsaren stöder: i en gammal webbläsare fungerar den som en vanlig webbplats, och i en modern webbläsare aktiveras offlineläge, notiser och installation på startskärmen. Ingen lämnas utanför.

Grunden är webbstandarder, och tekniken är inte bunden till någon särskild plattform eller något ramverk. Varje webbplats skriven med React, Vue eller vanlig JavaScript kan med rätt steg göras om till en PWA.

02Tre delar som gör en webbplats till PWA

Tekniskt sett krävs tre grundläggande komponenter för att en webbplats ska räknas som PWA. Alla tre är standarder och de officiella beskrivningarna finns hos källor som web.dev.

{
  "name": "Exempelbutik",
  "short_name": "Butik",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0b5cff",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

HTTPS

PWA-funktioner fungerar bara över en säker anslutning. På en webbplats utan SSL-certifikat går det inte att registrera en service worker.

Web app manifest

Manifestet är en liten JSON-fil som beskriver appens namn, ikoner, temafärg och hur den ska öppnas. Webbläsaren utgår från den här filen när den föreslår att lägga till på startskärmen.

Service worker

Service worker är en JavaScript-fil som sitter mellan webbläsaren och nätverket. Den cachar sidor och filer, visar sparat innehåll när internet bryts och hanterar notiser på plattformar som stöder det.

03Fördelar med PWA

Den största fördelen märks oftast på kostnadssidan. I stället för två separata mobilappar, två separata underhåll och två separata butiksprocesser hanterar du ett enda webbprojekt. De faktorer som verkligen påverkar budgeten är antalet skärmar, hur komplexa offlinescenarierna är och vilka system som ska kopplas in.

• En kodbas: du behöver inte utveckla separat för iOS, Android och desktop.
• Oberoende av appbutiker: du väntar inte på godkännande för att publicera en uppdatering, utan ändringen når alla direkt.
• Lite friktion vid installation: användaren börjar direkt från en länk, utan att gå till en appbutik.
• Syns i sökmotorer: eftersom innehållet är en webbsida kan Google genomsöka det.
• Lätt: tar oftast mycket mindre plats på telefonen än native-appar.
• Fungerar offline: cachat innehåll öppnas även vid dålig uppkoppling.

04PWA:ns begränsningar

En PWA svarar inte på alla behov, och för en ärlig jämförelse behöver man också känna till begränsningarna.

Stödet i iOS är mer begränsat än i Android. Funktioner som att lägga till på startskärmen och notiser har utvecklats över tid, men en del beteenden skiljer sig fortfarande och installationsförslaget visas inte automatiskt. Användaren måste lägga till appen från delningsmenyn.

Åtkomst till hårdvara är också begränsad. Grundläggande funktioner som kamera, plats och vibration går att använda via webben, men för behov som Bluetooth-enheter, kontinuerlig platsspårning i bakgrunden eller spel med tung grafik ligger native-appar fortfarande före.

Slutligen finns frågan om synlighet i appbutiker. Vissa användare söker bara efter appar i butiken. I Android kan PWA:er listas i Play Store med vissa metoder, medan det i iOS oftast kräver en inbyggd skalapp.

05Mobilapp eller webbplats?

Den här frågan är egentligen ett val mellan tre alternativ: en mobilanpassad webbplats, en PWA och en native mobilapp. Tabellen nedan sammanfattar skillnaderna.

06Vilka företag passar PWA för?

Där PWA glänser mest är i situationer där användaren ofta kommer tillbaka men inte orkar ladda ned en separat app. För en användare vars telefonminne är fullt och som inte vill installera ännu en app är en lätt upplevelse som öppnas från en länk och läggs på startskärmen oftast den kortaste vägen.

• Webbutiker: en snabb butik på startskärmen för kunder som handlar igen.
• Restauranger och kaféer: menyer och beställningsskärmar som öppnas via QR-koden på bordet och används utan att ladda ned en app.
• Bokningar och tidsbokning: snabb ombokning för hotell, kliniker eller frisörer.
• Fältteam: servicetekniker eller säljteam som fyller i formulär på platser med dålig uppkoppling.
• Innehållssajter: ofta lästa innehåll som nyheter, guider och kataloger.

07Vad avgör kostnaden?

Budgeten för ett PWA-projekt formas mer av detaljerna i omfattningen än av frågan ”app eller webbplats”. Det är stor skillnad på att lägga till manifest och cache på en enkel innehållssajt och att bygga en fältapp som tar emot order offline.

Det som påverkar budgeten mest är antalet skärmar och flöden, hur komplexa de offlineoperationer är, notisscenarier, system som ska kopplas in, som betalning, lager eller bokning, och hur unik designen ska vara. Till det kommer behovet av underhåll och uppdateringar efter lansering.

När du jämför med en native-app bör du inte bara titta på den första utvecklingskostnaden. Separat versionshantering för två plattformar, uppdateringar i appbutiker och enhetstester är poster som återkommer varje år. I en PWA samlas en stor del av dessa poster i en enda webbprocess, och det är oftast här den verkliga besparingen uppstår.

08Innan du startar ett PWA-projekt

Koden för en PWA skrivs oftast i JavaScript, och i större projekt föredras TypeScript för typsäkerhetens skull. Undrar du över arbetsfördelningen mellan gränssnitt och server förklarar vår artikel om skillnaden mellan frontend och backend det enkelt. Vill du börja från grunden är artikeln vad är JavaScript en bra ingång.

1. Rätta till mobilupplevelsen: en snabb, läsbar och pekanpassad webbplats är grundkravet.
2. Sätt ett hastighetsmål: gränsvärdena för Core Web Vitals (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1) är ett bra riktmärke.
3. Definiera offlinescenariot: vad ska användaren kunna se och göra utan internet?
4. Bestäm notisstrategin: fråga om tillstånd inte under första sekunden utan efter att du har visat värde.
5. Testa på riktiga enheter: prova installation och startbeteende separat i iOS och Android.