Hva er PWA? Mobilapp eller nett?

01Hva betyr Progressive Web App?

En progressive web app er en tilnærming som gir en vanlig nettside appfunksjoner. Brukeren åpner siden i nettleseren, og hvis hen liker den, legger den til på startskjermen med ett trykk. Ved senere åpninger starter den som en app, uten adressefelt og med eget ikon og startskjerm.

Ordet «progressive» i navnet er viktig. Appen får så mange funksjoner som nettleseren støtter: i en gammel nettleser fungerer den som en vanlig nettside, mens i en moderne nettleser kommer offline-modus, varsler og installasjon på startskjermen inn. Ingen blir stående utenfor.

Tilnærmingen bygger på webstandarder og er ikke bundet til en bestemt plattform eller et bestemt rammeverk. Alle nettsider skrevet med React, Vue eller ren JavaScript kan gjøres om til PWA med de riktige trinnene.

02De tre delene som gjør en nettside til PWA

Teknisk sett trengs tre grunnkomponenter for at en nettside skal regnes som PWA. Alle tre er standarder, og de offisielle beskrivelsene finnes i kilder som web.dev.

{
  "name": "Eksempelbutikk",
  "short_name": "Butikk",
  "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-funksjoner virker bare over en sikker tilkobling. På en nettside uten SSL-sertifikat kan ikke en service worker registreres.

Web app manifest

Manifestet er en liten JSON-fil som beskriver appens navn, ikoner, temafarge og hvordan den skal åpnes. Nettleseren bruker denne filen når den foreslår å legge appen til på startskjermen.

Service worker

Service worker er en JavaScript-fil som står mellom nettleseren og nettverket. Den bufrer sider og filer, viser lagret innhold når internett faller bort, og håndterer varsler på plattformer som støtter det.

03Fordeler med PWA

Den største av disse fordelene merkes oftest på kostnadssiden. I stedet for to separate mobilapper, to separate vedlikehold og to separate prosesser i appbutikkene, styrer du ett enkelt webprosjekt. Det som virkelig påvirker budsjettet, er antall skjermer, hvor komplekse offline-scenarioene er og hvilke systemer som skal kobles til.

• Én kodebase: du trenger ikke separat utvikling for iOS, Android og skrivebord.
• Uavhengig av appbutikk: du venter ikke på godkjenning for å publisere en oppdatering, og endringen når alle umiddelbart.
• Lav installasjonsterskel: brukeren starter rett fra en lenke uten å gå til appbutikken.
• Synlig i søkemotorer: innholdet er en nettside og kan indekseres av Google.
• Lett: tar vanligvis mye mindre plass på telefonen enn native apper.
• Fungerer offline: bufret innhold åpnes selv med dårlig tilkobling.

04Begrensninger ved PWA

PWA svarer ikke på alle behov. For en ærlig sammenligning må du også kjenne begrensningene.

iOS-støtten er mer begrenset enn på Android. Funksjoner som å legge til på startskjermen og varsler har utviklet seg over tid, men noe oppfører seg fortsatt annerledes, og installasjonsforslaget dukker ikke opp automatisk. Brukeren må legge den til fra delingsmenyen.

Tilgang til maskinvare er også begrenset. Grunnfunksjoner som kamera, posisjon og vibrasjon kan brukes via nettet, men for behov som Bluetooth-enheter, kontinuerlig posisjonssporing i bakgrunnen eller spill med tung grafikk ligger native apper fortsatt foran.

Til slutt kommer synlighet i appbutikken. Noen brukere leter bare etter appen i butikken. På Android kan PWA-er med visse metoder listes i Play Store, mens på iOS krever denne veien vanligvis en native skallapp.

05Mobilapp eller nettside?

Dette er egentlig et valg mellom tre alternativer: en mobiltilpasset nettside, en PWA og en native mobilapp. Tabellen nedenfor oppsummerer forskjellene.

06Hvilke virksomheter passer PWA for?

PWA kommer best til sin rett i scenarioer der brukeren kommer ofte tilbake, men ikke gidder å laste ned en egen app. For en bruker med full telefon som ikke vil installere nye apper, er en lett opplevelse som åpnes fra en lenke og legges til på startskjermen ofte den korteste veien.

• Nettbutikker: en butikk som åpnes raskt og ligger på startskjermen for kunder som handler igjen.
• Restauranter og kafeer: meny- og bestillingsskjermer som åpnes fra QR-koden på bordet og brukes uten å laste ned en app.
• Reservasjon og timebestilling: rask ny booking for hotell, klinikk eller frisør.
• Feltteam: serviceteknikere eller salgsteam som fyller ut skjemaer der tilkoblingen er dårlig.
• Innholdssider: innhold som leses ofte, som nyheter, guider og kataloger.

07Hva bestemmer kostnaden?

Budsjettet for et PWA-prosjekt formes mindre av spørsmålet «app eller nettside» og mer av detaljene i omfanget. Det er stor forskjell på å legge til manifest og buffer på en enkel innholdsside og å bygge en feltapp som tar imot bestillinger offline.

Postene som påvirker budsjettet mest, er: antall skjermer og flyter, kompleksiteten i operasjonene som skal fungere offline, varselscenarioer, systemer som skal kobles til, som betaling, lager eller reservasjon, og hvor unikt designet skal være. Dertil kommer behovet for vedlikehold og oppdateringer etter lansering.

Når du sammenligner med en native app, bør du ikke bare se på den første utviklingskostnaden. Separat versjonsoppfølging for to plattformer, oppdateringer i appbutikkene og enhetstesting er poster som kommer igjen hvert år. Med PWA samles en stor del av dem i én enkelt webprosess, og det er som regel her den virkelige besparelsen oppstår.

08Før du starter et PWA-prosjekt

Kodesiden til en PWA skrives for det meste i JavaScript, og i store prosjekter foretrekkes TypeScript for typesikkerhet. Lurer du på arbeidsfordelingen mellom grensesnitt og server, forklarer artikkelen vår om forskjellen på frontend og backend temaet enkelt. For deg som vil starte med grunnleggende ting, er artikkelen Hva er JavaScript et godt utgangspunkt.

1. Fiks mobilopplevelsen: en rask, lesbar og trykkvennlig nettside er en grunnleggende forutsetning.
2. Sett et hastighetsmål: terskelverdiene i Core Web Vitals (LCP ≤ 2,5 sek, INP ≤ 200 ms, CLS ≤ 0,1) er et godt utgangspunkt.
3. Definer offline-scenarioet: hva skal brukeren kunne se og gjøre uten internett?
4. Bestem varselstrategien: be om tillatelse ikke i første sekund, men etter at du har vist verdi.
5. Test på ekte enheter: prøv særlig installasjon og oppstart på iOS og Android hver for seg.