# Så bygger du en webbapp som fungerar utan internet

> De flesta webbappar visar en vit skärm i flygplansläge. Så här gör en service worker att din app fortfarande laddar och går att använda offline – och vilka delar som faktiskt inte kan fungera utan uppkoppling.

Source: https://northerngo.com/sv/guider/offline-appar-med-pwa/
Language: sv
Updated: 2026-08-15

---
**En publicerad NorthernGo-app installerar en service worker vid första besöket med uppkoppling, och därefter öppnas den i flygplansläge med layout, formgivning och redan visade bilder intakta i stället för en vit skärm. Det som inte kan fungera offline är allt som är levande: databasläsningar, skrivningar, inloggning, e-post och moln-AI går rakt till nätet och misslyckas rent.**

### Varför de flesta webbappar dör offline

Öppna nästan vilken webbapp som helst i flygplansläge så möts du av en vit skärm. Orsaken är enkel: webbläsaren har ingenting sparat lokalt, så när nätverksanropet för sidan misslyckas finns det inget att falla tillbaka på. En Progressive Web App löser det bara om den levererar en service worker som faktiskt cachar appen – att kunna installeras på hemskärmen är inte samma sak som att fungera offline.

### Publiceringen är det som ger appen en service worker

Appar som publiceras på en NorthernGo-subdomän eller egen domän serveras med en service worker på `/sw.js` och ett manifest på `/manifest.json`. Publicera via **Mina Projekt** och öppna sedan appen en gång medan du fortfarande har uppkoppling. Det första besöket är det som installerar service workern och fyller cachen – det går inte att komma runt, eftersom filerna måste laddas ner minst en gång.

### Adressen du publicerar på avgör om något av det här alls gäller

Den här delen är värd att vara rakt på sak med, eftersom den är den absolut vanligaste orsaken till att någon följer en offline-guide och inte får något resultat.

Service workern och manifestet serveras bara på appens egen värd. Det finns tre vägar att nå en NorthernGo-app, och de beter sig inte likadant:

- **En egen domän** (Pro). Appen är hela webbplatsen på den adressen, så `/sw.js` och `/manifest.json` svarar och offline-cachen fungerar.
- **`<subdomän>.northerngo.com`** (Premium och Pro). Samma sak – subdomänen serverar appen som toppdokument, med manifestet länkat i head och service workern registrerad vid laddning.
- **Delningslänken `https://northerngo.com/?app=<projektId>`.** Den får ingen service worker och inget manifest, eftersom de sökvägarna på huvuddomänen tillhör webbplatsen och inte din app. Projekt på gratisplanen använder den här reservvägen, vilket betyder att en app på gratisplanen inte har någon offline-funktion alls.

Den praktiska förutsättningen för allt nedan är alltså en betald plan och en egen adress. Använd **Skapa PWA** på projektkortet för att ta en subdomän, eller [koppla en egen domän med SSL](/sv/guider/connect-custom-domain-ssl/) om du har Pro.

### Vad som cachas

Tre saker sparas på enheten vid det första besöket:

1. **Appskalet** – själva HTML-sidan, så att navigering offline serverar den cachade kopian i stället för att misslyckas.
2. **Design- och ikonresurser** – den Tailwind- och ikon-CSS appen hämtar från ett CDN, så att den renderas snyggt i stället för som oformaterad text.
3. **Bilder appen redan visat** – det som inte finns cachat ersätts av en neutral platshållare i stället för en trasig bildikon.

### Så hanteras varje typ av anrop i praktiken

De fyra reglerna nedan är hela cachningspolicyn, och känner du dem vet du exakt vad användaren ser när uppkopplingen försvinner.

- **Sidnavigering hämtas från cachen först.** Finns en cachad kopia av sidan serveras den direkt utan att nätet ens frågas. Det är detta som tar bort den vita skärmen, och det har ett pris – se avvägningen längre ner.
- **Bilder hämtas från nätet först, sedan cachen, sist en platshållare.** En färsk bild vinner när det finns uppkoppling; offline kommer en tidigare visad bild från cachen; en bild enheten aldrig laddat ersätts av en enkel grå SVG som säger att bilden inte är tillgänglig offline.
- **Övriga statiska resurser använder stale-while-revalidate.** Stilmallar, typsnitt och CDN-skript serveras direkt ur cachen och uppdateras tyst i bakgrunden, så att appen renderas snabbt offline och håller sig aktuell online.
- **Allt som ser ut som ett API-anrop cachas aldrig.** Anrop till `/api/`-sökvägar och till databas- och plattformsvärdarna går helt förbi cachen. Bara `GET`-anrop kan cachas överhuvudtaget, så varje `POST` din app gör går rakt till nätet.

### Vet vad som inte kan fungera offline

Här är ärlighet viktigare än marknadsföring. Inloggning, e-post, betalning och moln-AI går fortfarande rakt till nätet och misslyckas när det saknas. Service workern cachar inte de svaren.

Databas-`save()` och `delete()` på en publicerad PWA (subdomän eller egen domän) är annorlunda: SDK:n köar dem i `localStorage` och spelar upp kön när appen är online igen. `get()` returnerar senast lyckade lista plus väntande poster, märkta `_pending: true`. `window.NorthernGo.offlineStatus()` rapporterar `{ online, pending }`. Login och register köas aldrig.

Den praktiska följden: bygg appen så att gränssnittet ritas direkt och sedan anropar `get()`. En app byggd så öppnas offline, visar senast kända data, och bara inloggning, betalning, e-post och AI meddelar att uppkoppling behövs. Bygg inte en andra skrivkö i appkoden.

### Att designa en app som har två tillstånd

Det pålitliga mönstret är att behandla "uppkopplad" som en funktion snarare än ett antagande. Tre vanor täcker det mesta.

Rendera innan du hämtar. Måla upp layouten, navigeringen och allt statiskt innehåll direkt, och läs sedan in datan i det. En app som väntar på ett databassvar innan den målar något är en app som visar ingenting offline, service worker eller inte.

Berätta vilket tillstånd du är i. `navigator.onLine` plus händelserna `online` och `offline` räcker för att sätta en ärlig banner högst upp. Användare tolererar "ingen uppkoppling – visar din senast sparade vy" oändligt mycket bättre än en snurra som aldrig blir klar.

Låt fel gälla per funktion, inte per app. Ett misslyckat anrop ska släcka en panel, inte hela sidan.

```javascript
async function laddaUppgifter() {
  const uppgifter = await window.NorthernGoDB.get('uppgifter');
  rendera(uppgifter || []);
  const status = window.NorthernGo.offlineStatus ? window.NorthernGo.offlineStatus() : {};
  if (!status.online) sattBanner('Ingen uppkoppling – visar din senast sparade vy.');
  else if (status.pending) sattBanner(status.pending + ' ändring(ar) väntar på synk.');
  else sattBanner(null);
}

window.addEventListener('online', laddaUppgifter);
window.addEventListener('offline', () => sattBanner('Du är offline.'));
window.addEventListener('ng-offline-queue', laddaUppgifter);
```

### Avvägningen bakom att aldrig visa en vit skärm

Eftersom sidnavigering hämtas ur cachen först vinner en cachad sida över en nyare. Det är precis vad du vill ha i flygplansläge och precis vad du inte vill ha tio minuter efter att du publicerat om appen: en återvändande besökare kan fortsätta se den förra versionen tills den cachade posten byts ut.

Den ärliga lösningen är en hård omladdning, eller att rensa webbplatsdatan för den värden, vilket de flesta inte kommer att tänka på. Itererar du snabbt på en live-app: testa i ett privat fönster så att du inte luras av din egen cache, och säg till tidiga användare att ladda om en gång efter varje ändring. Det här är en verklig begränsning snarare än ett fel: varje cache-först-strategi byter färskhet mot garantin att appen alltid öppnas.

### Ikoner och installerbarhet

Manifestet genereras per projekt, utifrån appens namn och antingen en ikon du laddat upp eller en genererad kvadrat med appens första bokstav. Det sätter `display: standalone`, så när appen väl är installerad öppnas den utan webbläsarens ramverk och ser ut som en native-app i appväxlaren.

En genererad bokstavsikon duger för test och syns tydligt på en riktig hemskärm. Ska appen framför någon annan: [gör ordentliga appikoner](/sv/guider/create-pwa-app-icons/) och ladda upp en – det är den billigaste kvalitetssignal en PWA har.

### Den exporterade ZIP-filen bär inte samma service worker

Värt att veta innan du planerar utifrån det. Exporten via **Ladda ner ZIP** är ett Capacitor-format projekt: din app som `www/index.html`, ett manifest, en konfigurationsfil och en `package.json`. Den innehåller en `www/sw.js`, men det är en minimal variant som bara skickar anrop vidare till nätet och returnerar ett kort offline-meddelande när det misslyckas. Den förcachar ingenting.

Offline-beteendet som beskrivs på den här sidan tillhör alltså den hostade versionen, inte exporten. Tar du ZIP-filen och [paketerar den som en native-app för iOS eller Android](/sv/guider/export-native-ios-android-capacitor/) ligger appskalet lokalt ändå och service workern spelar mycket mindre roll. Tar du ZIP-filen till egen webbhosting får du räkna med att skriva en cachande service worker själv.

### Testa ordentligt

Öppna appen online en gång. Slå sedan på flygplansläge och ladda om. Appen ska renderas som vanligt, inte visa en vit skärm. På datorn gör du samma sak i Chrome DevTools med Network satt till Offline, där du också kan bekräfta under Application → Service Workers att en är registrerad och aktiv.

Två extra kontroller är värda minuten de tar. Under Application → Cache Storage ser du exakt vilka URL:er som sparades, vilket direkt förklarar en ostylad rendering. Och Application → Manifest berättar om ikonen och namnet gick fram, vilket är den vanliga orsaken till att installationsförfrågan aldrig dyker upp.

### Felsökning

**Appen renderas som oformaterad text offline.** CDN-stilmallarna låg inte i cachen när uppkopplingen försvann. De förcachas vid installationen, men ett CDN-fel under det första besöket får passera tyst så att installationen ändå lyckas. Ladda appen online en gång till och kontrollera Cache Storage.

**Ingenting är cachat och det finns ingen service worker.** Nästan alltid öppnas appen via `?app=`-delningslänken i stället för via sin egen subdomän eller domän. Kontrollera adressfältet först.

**Ändringar syns inte efter att du publicerat om.** Cache-först-navigeringen serverar den gamla sidan. Ladda om hårt, eller rensa webbplatsdatan för den värden.

**Appen öppnas offline men visar ingen data.** Det fungerar som det ska. Databasanrop kräver uppkoppling. Är skärmen tom snarare än avskalad väntar renderingen på data i stället för att måla först och fylla i efteråt.

## Vanliga frågor

### Fungerar appen offline allra första gången den öppnas?

Nej. Appen måste öppnas en gång med uppkoppling så att service workern kan installeras och cacha filerna. Efter det första besöket öppnas den offline. Det är en begränsning i hur webbläsare fungerar, inte i någon särskild plattform.

### Kan databasen också fungera offline?

Nej. Data som ligger i en molndatabas kräver uppkoppling, och att servera cachade databassvar skulle visa användaren gammal data utan förvarning. Designa appen så att den renderar från lokala standardvärden och synkar i bakgrunden, så påverkas bara de delar som kräver livedata när uppkopplingen försvinner.

### Är en installerbar PWA samma sak som en offline-app?

Nej, och det är något många går bet på. En manifest-fil gör appen installerbar på hemskärmen, men offline-beteendet avgörs helt av service workern och vad den cachar. Många installerbara PWA:er visar fortfarande en vit skärm utan uppkoppling.

### Fungerar offline-cachen på gratisplanens delningslänk?

Nej. Service workern och manifestet serveras bara på appens egen värd, det vill säga en subdomän under northerngo.com på Premium eller Pro, eller en egen domän på Pro. Delningslänken northerngo.com/?app= som projekt på gratisplanen använder får ingen av dem, så de apparna har inget offline-beteende alls.

### Varför visar min publicerade app den gamla versionen efter att jag uppdaterat den?

Eftersom sidnavigering hämtas ur cachen innan nätet ens frågas. Det är det som förhindrar en vit skärm offline, men det innebär också att en återvändande besökare behåller den tidigare cachade sidan tills den byts ut. En hård omladdning eller rensad webbplatsdata för adressen löser det, och att testa i ett privat fönster gör att du inte luras under utvecklingen.

---

## Related

- [Så gör du en AI-byggd app till en installerbar PWA med egen ikon](https://northerngo.com/sv/guider/skapa-appikoner-for-pwa/)
- [Så lagrar du data i en AI-byggd app med Supabase](https://northerngo.com/sv/guider/lagra-data-med-supabase/)
- [Så kopplar du en egen domän till en AI-byggd app](https://northerngo.com/sv/guider/koppla-egen-doman-och-ssl/)
- [Så exporterar du en AI-byggd app till ett nativt iOS- och Android-projekt med Capacitor](https://northerngo.com/sv/guider/exportera-till-ios-och-android/)

---

NorthernGo är en AI-driven plattform för att bygga produktionsklara webbappar utan kod. Lokal AI-generering via WebGPU är obegränsad och gratis, och du äger all genererad källkod. https://northerngo.com/