En progressiv web-app (PWA) er en webapplikation, der bruger moderne browserfunktioner – primært service workers og et web-app-manifest – til at opføre sig som en installeret, indfødt app. Du trykker på et link, og det, der åbner, ligner en app, fungerer offline og placerer sig efterfølgende på din hjemmeskærm, uden at du nogensinde har besøgt en app-butik eller godkendt en installation. Tænk på en indfødt app som en butik, der beder dig udfylde en medlemsformular ved døren. En PWA er den samme butik, hvor døren allerede står åben.
Men det er ikke altid den rette løsning. Apples understøttelse af installerede web-apps halter efter Googles, adgangen til hardware er mere begrænset end ved indfødte apps, og ingen af app-butikkerne lister som standard en PWA. Spørgsmålet er derfor ikke, om PWAs virker, men hvornår en PWA er det rigtige valg for din virksomhed. Det er netop det, resten af denne guide dækker: hvad en PWA gør, hvad den koster, hvor dens begrænsninger ligger, og hvordan du træffer beslutningen.
Webplatformens syn på, hvad en PWA er, og de standarder, der ligger bag, er dokumenteret af MDN Web Docs og Googles web.dev PWA-læringsforløb.
Mobilapps er vigtige, fordi de giver dig mulighed for at skabe noget, der er mere praktisk og personligt, end en webside normalt kan tilbyde. Der er tre overordnede måder at bygge en app på.
Native apps er bygget til en specifik platform. De kører i platformens eget sprog, iOS i Swift og Android i Kotlin, og de har adgang til alle platformens funktioner. To platforme betyder to kodebaser.
Hybrid-apps kombinerer native kode med webkode, så én kodebase kan leveres til flere platforme i en native skal. Afhængigt af frameworket og de tilgængelige plugins er det ikke sikkert, at hybrid-apps kan tilgå alle platformsspecifikke funktioner, så tjek push-beskeder og hardwareadgang som GPS eller kamera i forhold til dine krav, før du beslutter dig.
Progressive web apps er hjemmesider bygget med moderne webteknologier, som brugere kan installere på deres startskærm og bruge offline. De er ikke lige så kraftfulde som native apps. De leverer dog mange af de samme fordele fra én kodebase og én udrulningspipeline.
Læs mere om Native app vs. Hybrid-app vs. PWA: fordele og ulemper. Hvis du vil have det store overblik først, så dækker vores ultimative guide til udvikling af webapps det grundlag, som denne artikel bygger videre på.
En webapplikation, eller web-app, er software, som du tilgår via en browser som Chrome, Safari eller Firefox. Webapplikationer vinder mere og mere terræn fra traditionel desktop-software af tre jordnære årsager: De kræver ingen installation, de opdateres centralt, og de kører overalt, hvor der er en browser.
En progressiv web-app tager det et skridt videre. Den bruger browser-API'er til at sikre en brugbar oplevelse, selv når forbindelsen er langsom eller helt væk, og den tilpasser sig den enhed, den åbnes på, i stedet for at forudsætte en hurtig telefon på et hurtigt netværk. Én version fungerer på alle platforme, så dine funktioner skal ikke udvikles separat til hvert styresystem.
PWA'er låner også funktioner fra mobilapps: push-beskeder, hvor platformen tillader det, offline-funktionalitet og installation på hjemmeskærmen. Og fordi appen leveres via nettet frem for at skulle downloades, får brugerne altid den nyeste version, så snart de åbner den. Ingen opdateringer i en app store, der skal godkendes, og ingen brugere, der hænger fast i sidste kvartals version.
I bund og grund består en PWA af HTML, CSS og JavaScript, hvilket betyder, at den drager fordel af hele web-økosystemet: biblioteker, værktøjer, adgang til udviklere og en udrulningsproces, som dit team allerede bruger. Det er den praktiske årsag til, at en PWA bliver hurtigere klar end en tilsvarende native app. Det er ikke magi. Det er infrastruktur, du allerede har.
Kravene til kvaliteten sættes dog af native apps. Så hvad kræver en god PWA egentlig?
Der er seks ting, der adskiller en PWA fra et mobilvenligt website, og hver eneste af dem er et aktivt valg frem for en indstilling.
Minimumskravene for installerbarhed, en HTTPS-oprindelse og et gyldigt manifest, er beskrevet i MDN's Making PWAs installable guide. Understøttelse af service workers på tværs af browsere kan følges på caniuse.
Mindre end du tror. Tre af kravene er tekniske, to er et spørgsmål om vurdering.
HTTPS, fordi service workers kræver det. Dit site skal serveres via HTTPS. Det beskytter brugerdata under transport, og browsere vil ikke registrere en service worker på en usikker oprindelse, så uden det er der ingen PWA. Det er ikke til forhandling.
En service worker til offline-brug og caching. En service worker er et baggrundsscript, som browseren kører uafhængigt af din side. Den understøtter offline-brug, cacher aktiver og data, håndterer baggrundsopgaver og kan færdiggøre arbejde, selv når din PWA ikke er åben, hvilket er det, der gør push-beskeder og baggrundssynkronisering muligt.
Et web app manifest. Denne JSON-fil fortæller browseren, hvordan din PWA skal se ud og opføre sig, når den er installeret: navn, kort navn, beskrivelse, ikoner, tema- og baggrundsfarver, visningstilstand og start-URL. Det er det, der forvandler en fane til en app. MDN har en komplet reference over manifest-medlemmer, og web.dev har en praktisk gennemgang af web app manifest.
Frameworks og værktøjer. Ethvert moderne JavaScript-framework kan bruges, og de fleste har nu en dokumenteret PWA-vej: React, Angular, Vue, Svelte og meta-frameworks som Next.js, Nuxt og SvelteKit. Til selve service workeren vælger de fleste teams Workbox frem for at skrive caching-strategier fra bunden. Ældre vejledninger, der nævner AngularJS eller Polymer, er forældede, og begge er pensionerede, så betragt enhver tutorial, der stadig anbefaler dem, som en advarsel om resten af dens råd.
En første indlæsning, der er værd at vente på. Den første skærm er det, brugerne dømmer dig på, så mål den i stedet for at gætte. Lighthouse, Googles open-source værktøj til auditering, rapporterer om ydeevne, tilgængelighed, SEO og installerbarhed, og det kører i Chrome DevTools mod enhver URL.
En vigtig bemærkning før vi ser på tallene, da det har betydning for deres vægtning. Hvert resultat herunder stammer fra virksomhedernes egne tekniske rapporter, indsamlet i web.devs case-bibliotek, og de fleste blev publiceret omkring 2016 og 2017.
Det var en periode, hvor PWA'er var nye, og de mobile websites, de erstattede, ofte var af dårlig kvalitet. Læs dem derfor som bevis på, at metoden kan betale sig, snarere end som en prognose for dit eget projekt. Googles opsummering af, hvad brugere forventer af en mobiloplevelse, stammer fra det samme arbejde: FIRE-akronymet – fast (hurtig), installable (installérbar), reliable (pålidelig) og engaging (engagerende).
Forretningsmæssig succes ser forskellig ud alt efter, hvad du sælger, så vælg det målepunkt, der passer til din forretningsmodel. Tid på siden, afvisningsprocent, konverteringsrate eller tilbagevendende besøgende. Og da en PWA udvikles trinvist, kan du lancere de funktioner, der skaber mest værdi først, og tilføje resten senere.
Pinterest genopbyggede sin mobile weboplevelse som en PWA for at understøtte international vækst. Kun 1 % af mobilbrugerne konverterede til tilmeldinger, logins eller app-installationer, og dårlig mobil performance var årsagen, så teamet startede helt forfra.
Genopbygningen gav tre resultater ifølge Pinterests egen tekniske rapport: tiden brugt på det mobile web steg med 40 % i forhold til den tidligere version, kerneinteraktioner steg med 60 %, og der var en stigning på 44 % i annonceindtægter fra brugergenereret indhold, hvilket er Pinterests primære indtægtskilde i feedet.
Da over 80 % af brugerne kom fra mobilen, ønskede Twitter en mobil weboplevelse, der var hurtigere, mere pålidelig og brugte mindre data. Twitter Lite blev standarden for alle brugere globalt, bygget op omkring øjeblikkelig indlæsning, engagement og datareduktion.
Twitters tekniske team rapporterede 65 % flere sider pr. session, 75 % flere sendte tweets og 20 % færre afvisninger. Twitter Lite indlæste på under tre sekunder, selv på langsomme forbindelser.
Uber genopbyggede sin web-app som en PWA for at tilbyde en bookingoplevelse på niveau med den native app, mens virksomheden ekspanderede til nye markeder. PWA'en gør det muligt at booke på 2G-netværk og kører i alle moderne browsere, hvilket når ud til brugere med ældre enheder, der slet ikke kan køre den native Uber-app.
Ifølge Ubers tekniske rapport resulterede det i en letvægts web-app, der indlæser på tre sekunder på 2G, uanset lokation, netværkshastighed eller enhed.
Starbucks byggede en PWA af sit bestillingssystem for at matche oplevelsen fra deres native app. Kunder kan gennemse menuen, tilpasse ordrer og lægge varer i kurven uden en stabil forbindelse, for derefter at se lokationsspecifikke priser og gennemføre ordren, når de er online igen.
Da en stor del af appen fungerer offline, passer den perfekt til kunder, der bevæger sig ind og ud af dækning i løbet af dagen. Appen fylder under 0,15 MB, og Starbucks rapporterede, at de siden lanceringen har fordoblet antallet af daglige aktive brugere, hvor ordrer fra desktop ligger tæt på niveauet for mobilbrowsere.
Trivago, en af de største hotelsøgemaskiner, investerede i en PWA for at sikre en mere stabil mobiloplevelse. Teamet prioriterede offline-adgang, push-beskeder og "føj til hjemmeskærm", da de vurderede, at disse funktioner var mest værdifulde for deres brugere.
Trivagos rapporterede tal: "føj til hjemmeskærm"-handlinger steg med 150 %, og der var en stigning på 97 % i klik-ud – de klik, der sender brugeren videre til hotellets eget tilbud, og som genererer indtægter til Trivago. Brugere, der mister forbindelsen, kan fortsætte med at søge, og 67 % gør netop det, når de er online igen.
De oprindelige tal for disse fem cases stammer fra hver virksomheds tekniske rapporter, indsamlet i Googles web.dev casestudie-bibliotek. Betragt dem som historiske vidnesbyrd snarere end aktuelle benchmarks.
Når man skræller markedsføringen væk, er der tre fordele, der gør hele arbejdet.
Én kodebase, flere platforme. En PWA kører på enhver web-aktiveret enhed og browser, så du skal kun bygge og vedligeholde én ting i stedet for en web-app plus en iOS-app plus en Android-app. Det er her, besparelsen ligger, og den akkumuleres: hver funktion, hver rettelse og hver sikkerhedsopdatering skal kun udrulles én gang.
App-funktionalitet uden omveje. Offline-adgang, push-beskeder hvor platformen understøtter det, lavt dataforbrug og installation på hjemmeskærmen er nu alt sammen tilgængeligt for en web-app. Twitter Lites fald i afvisningsprocent på 20 % og Trivagos stigning i installationer på 150 % er den samme fordel målt på to måder. Folk, der aldrig ville have udfyldt medlemsformularen, ender alligevel med at fastgøre shoppen til deres hjemmeskærm.
Hurtigere at lancere, billigere at vedligeholde. Web-API'er og eksisterende værktøjer gør det muligt for et team at lancere en kundevendt tjeneste uden at skulle bygge separate mobil- og desktop-applikationer, og der er kun én udrulningsvej i stedet for to køer til godkendelse i app-stores. Vedligeholdelsen er lettere af samme strukturelle årsag: færre kodebaser, færre pipelines og ingen versionsfragmentering på tværs af brugere, der aldrig har opdateret.
Der er dog ét forbehold ved alle tre punkter. En PWA er velegnet, når dine krav ligger inden for, hvad browseren kan håndtere, og når de ikke gør, kan intet af ovenstående redde projektet.
Engagement-procenterne ovenfor er den nemme del af business casen. De næste fire spørgsmål udgør resten, og det er dem, der er værd at tage med i beslutningsprocessen.
Udviklingsomkostninger. Det ærlige svar er et spænd frem for et fast beløb, og det afhænger mere af omfanget end af teknologien. Det strukturelle punkt er enkelt: En PWA er én kodebase, hvor native kræver to. Du sammenligner altså én udviklingsproces med to, oveni det design- og backend-arbejde, du alligevel skal betale for. Få et estimat baseret på omfanget, før du lægger planer ud fra et bestemt tal.
Tid til første release. En PWA går live, så snart du deployer den. Ingen indsendelse til app stores, ingen godkendelseskø, hvilket fjerner både ventetiden før lancering og forsinkelser ved hver efterfølgende opdatering. For et team, der releaser ugentligt, er det ofte argument nok i sig selv.
Vedligeholdelse. Én kodebase, én pipeline, én version ude hos brugerne. Native betyder to kodebaser, der skal følge to styresystemers egne release-planer, plus en lang hale af brugere på gamle builds, som du stadig skal supportere. En PWA er dog ikke gratis at vedligeholde: Browserunderstøttelse ændrer sig, og caching-logik skal revideres, efterhånden som appen udvikler sig.
Risiko, først vedrørende platformen. Apples understøttelse af installerede web-apps har historisk set haltet efter Googles, og de har tidligere vaklet: I starten af 2024 fjernede Apple kortvarigt web-apps på hjemmeskærmen for EU-brugere for at overholde Digital Markets Act, men omgjorde beslutningen få uger senere efter massiv kritik. Den episode er overstået nu, og udviklingen er siden gået støt fremad. Push-beskeder har virket på installerede PWA'er siden iOS 16.4, og fra og med iOS 26 åbner alle sider, der tilføjes til hjemmeskærmen, som en web-app som standard, hvilket fjerner et trin, brugerne før skulle kende til. Det, der ikke har ændret sig, er de mere komplekse ting. Adgang til hardware og styresystem er stadig mere begrænset end ved native, så Bluetooth, baggrundssynkronisering, dyb integration i styresystemet og visse sensorer kan være uden for rækkevidde, og iOS kan slette en PWA's cachede data efter længere tids inaktivitet. Hvis en stor del af dine brugere er på iOS, bør du teste dine kritiske funktioner i den aktuelle version af Safari, før du beslutter dig.
Risiko, derefter vedrørende distribution og exit. Ingen af app-butikkerne lister som udgangspunkt en PWA, så hvis tilstedeværelse i en app store er en del af din anskaffelsesplan, skal du finde en alternativ vej dertil. Og hvis du senere finder ud af, at du alligevel har brug for native, ender du med at finansiere en ekstra udviklingsproces i stedet for at bygge videre på den første.
Apple dokumenterer den nuværende status for web-apps på hjemmeskærmen i EU i deres DMA og apps i EU Q&A for udviklere, og introduktionen af web-push til iOS er beskrevet på WebKit-bloggen.
Vi stiller de samme fire spørgsmål til ethvert projekt, hvor en PWA er på tale. De løser de fleste af disse beslutninger i løbet af en enkelt samtale.
Hvor kommer dine brugere fra? Hvis det er via søgning, annoncer eller et delt link, holder en PWA hele brugerrejsen på nettet uden behov for installation. Hvis de ankommer via app-butikkerne, forsvinder det argument.
Hvad skal appen bruge fra enheden? Lav en liste over de hardware- og OS-funktioner, du ikke kan undvære, og tjek derefter hver enkelt mod browserunderstøttelsen på de platforme, dine brugere rent faktisk benytter. Et enkelt uundgåeligt hul afgør sagen med det samme.
Hvad skal offline-funktionaliteten kunne? "Fungerer offline" dækker alt fra visning af cachelagret indhold til kø af transaktioner til senere. Jo mere komplekst dit svar er, desto mere af udviklingsarbejdet vil ligge i service worker-delen.
Hvad sker der om 18 måneder? Hvis køreplanen peger mod funktioner, som kun native kan levere, kan det stadig være rigtigt at bygge PWA'en først, så længe du vælger at betale for begge dele frem for at opdage det senere. Nogle gange er native ganske enkelt det ærlige svar fra dag ét. Da vi byggede Jinga Life, en digital familie-sundhedsplatform, pegede kravene mod iOS fra starten, så det var det, vi byggede, frem for at tvinge en web-app til at udføre en opgave, den ikke var egnet til. Formålet med de fire spørgsmål er ikke at overtale dig til en PWA. Det er at fortælle dig, hvilken af de to du rent faktisk har brug for.
Besvar de fire spørgsmål, og valget giver som regel sig selv. Hvor det reelt ikke gør, er den delte vej legitim: lancér PWA'en, lær af den faktiske brug, og gå native senere for de dele, der kræver det.
Tre ting adskiller en PWA, der holder i virkeligheden, fra en, der kun fungerer på dit skrivebord.
Ja, og bedre end rygtet antyder. Safari understøtter service workers, offline-caching og "føj til hjemmeskærm", så kernen i en PWA virker på iPhone og iPad. Push-beskeder har været tilgængelige for installerede PWA'er siden iOS 16.4, og fra iOS 17.4 åbner et websted, der er gemt på hjemmeskærmen, som standard som sin egen app i stedet for som en browsergenvej.
Forbeholdene handler om dybde, ikke om hvorvidt det overhovedet kører. Der er stadig ingen automatisk installationsanmodning på iOS, som man kender det fra Android, så brugeren skal trykke på Del og derefter Føj til hjemmeskærm. Det kan derfor betale sig at designe en opfordring til dette frem for at antage, at folk selv finder ud af det. Push-beskeder sendes kun, når appen er installeret, og der er givet tilladelse, så det kan ikke genaktivere en bruger, der aldrig har installeret appen. Desuden er baggrundssynkronisering, det meste Bluetooth- og sensorarbejde samt vedvarende lagring i stor skala enten fraværende eller upålidelige. Hvis en væsentlig del af dine brugere er på iOS, bør du teste dine specifikke must-have-funktioner i den aktuelle Safari-version, før du planlægger ud fra dem. Apples udvikler-Q&A om EU-apps er stedet, hvor du kan bekræfte den nyeste status.
Forskellen ligger i antallet af kodebaser, ikke i teknologien. En PWA er ét build, der betjener alle platforme, hvorimod en tilsvarende native løsning kræver en iOS-app og en Android-app, hver med sin egen release-cyklus og vedligeholdelse. Design- og back-end-arbejde koster nogenlunde det samme uanset hvad. Bed om et afgrænset estimat baseret på din egen funktionsliste i stedet for at tage udgangspunkt i et generelt gennemsnit.
Ikke som standard. En PWA distribueres via nettet, så brugerne finder den via søgning, links eller annoncer frem for ved at gennemse en butik. Hvis tilstedeværelse i en app-butik er vigtig for dig, kan du pakke appen ind til udgivelse: på Android via en Trusted Web Activity, som er Googles mekanisme til at levere en PWA inde i en let native-pakke, og på iOS via en native wrapper – en minimal native app, hvis eneste opgave er at vise din web-app. Begge metoder tilføjer et build- og godkendelsesforløb, som du ellers ikke ville have haft.
Ja. De underliggende teknologier – service workers, web app manifest og installationsanmodningen – er nu standarddele af platformen frem for et eksperiment, og de frameworks, som de fleste teams allerede bruger, understøtter dem direkte. Det, der har ændret sig, er rammesætningen. En PWA er ikke længere en separat produktkategori; det er et sæt funktioner, du aktiverer for en web-app, når de giver mening.
Alt, der kræver dyb adgang til enheden eller operativsystemet. Baggrundsplacering, det meste Bluetooth- og sensorarbejde, tæt integration med systemfunktioner og alt, der kræver en baggrundsproces, der altid kører, er enten utilgængeligt eller understøttes ujævnt. Tilgængeligheden varierer alt efter browser og platform, så tag beslutningen ud fra din egen liste over krav, og tjek hver enkelt op mod MDN's PWA-reference, fremfor et generelt svar.
Det afhænger af omfanget, men to ting gør processen markant hurtigere end ved native apps: kun én kodebase at vedligeholde, og ingen godkendelsesproces i app-butikker før udgivelse. Hvis du allerede har en velfungerende webapp, er tilføjelsen af en service worker, et manifest og en offline-strategi en overskuelig opgave frem for en total genopbygning. Hvis selve den eksisterende app er problemet, som det var tilfældet for Pinterest, står du over for en genopbygning, og tidsplanen vil da følge genopbygningens omfang.
Her er det hele kort fortalt. En progressiv web-app er det rigtige valg, når dine krav matcher browserens muligheder, dine brugere kommer fra nettet, og du foretrækker at vedligeholde én kodebase frem for to. Det er det forkerte valg, hvis en funktion, du ikke kan undvære, kræver adgang til styresystemet, eller hvis app stores er din primære distributionskanal. Hold døren åben, når du kan. Vælg den lukkede løsning, når du er nødt til det.
Vi har bygget begge dele, lige fra web-apps, der kan installeres på hjemmeskærmen, til native-produkter som Jinga Life, så den anbefaling, du får, er den, dit projekt har brug for. Se nærmere på, hvordan vi griber webudvikling og mobiludviklingan, eller tag kontakt , så gennemgår vi dine krav ud fra de fire spørgsmål ovenfor.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
Inês Silva er projektleder med mere end fire års erfaring med at skrive om softwarelevering, agile metoder og tech-ledelse. Da hun startede sin karriere som udvikler, bidrager Inês med en ægte, dybdegående teknisk forståelse til ledelsessiden. Hun elsker at bygge bro mellem den overordnede forretningsstrategi og den daglige tekniske udførelse, og hun brænder for at dele praktiske tips, der hjælper teams med at samarbejde bedre og levere fremragende produkter.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
