Kort fortalt: En service worker er et script browseren registrerer fra din origin, som kører i en anden kontekst end selve siden: den kan leve videre når fanen er i baggrunden, og den kan intercepte netværkskald (fetch) og beslutte om svaret skal komme fra netværk, cache eller en blanding. Det er fundamentet bag mange PWA’er (offline, “installér app”, push - sidstnævnte kræver yderligere API’er).
Hvad kan en service worker konkret?
- Cache strategier: “network first”, “cache first”, “stale-while-revalidate” (ligesom idéen i stale-while-revalidate på HTTP-niveau, men her programmatisk).
- Forudhentning: hente assets i rolige perioder så næste sidevisning bliver hurtigere.
- Offline-fallback: vise en statisk side når netværket er nede.
- Kontrol over opdateringer: versionere cache-lager og invalider ved deploy - hvis du husker det. Glemmer du det, sidder brugere på gammelt indhold.
Hvorfor det betyder noget for performance
Når strategien er veldesignet, kan gentagne besøg og navigation føles markant hurtigere, fordi kritiske skaller (HTML-fragmenter, JS, CSS, billeder) kan serveres fra lokalt lager uden at ramme din origin. Det kan også reducere server- og CDN-last for gentagne requests.
Omvendt kan en dårligt skrevet service worker:
- serve forældet indhold længe efter deploy;
- intercepte for bredt og ødelægge API-kald, login eller betaling;
- køre tung logik og påvirke INP eller batteri på mobil hvis du ikke er disciplineret.
Service worker og HTTP-cache
Cache-Control og browserens HTTP-cache er stadig den primære mekanisme for de fleste statiske assets. Service worker tilføjer et programmatisk lag ovenpå: du kan implementere finmaskede regler, men du betaler i kompleksitet. For mange content-sites er korrekt Cache-Control på versionerede filer + CDN nok; service worker er først interessant når du har offline eller app-lignende krav.
SEO og indeksering
Søgemaskiner forventer stadig serverleveret HTML for indhold der skal indekseres. En service worker ændrer ikke det grundlæggende krav: crawlers skal kunne hente meningsfuldt indhold. Hvis du kun “bygger” indholdet i service worker uden server-render, risikerer du indekseringsproblemer. Brug service worker til performance og cache, ikke som erstatning for synlig HTML fra server.
Relation til bfcache
Back/forward cache og service worker er forskellige lag. bfcache gemmer hele dokumenttilstanden for navigation tilbage/frem; service worker intercepte fetch på tværs af besøg. Nogle headers og livscyklus-valg kan påvirke begge - fx hvis du bruger unload-handlers, kan du skade bfcache uafhængigt af service worker.
Typiske fejl i implementering
- Cache uden versionsnavne - brugere får gammel JS/CSS efter deploy.
- Intercept af alle
fetch- inklusive analytics eller tredjepart du ikke forstår, hvilket giver mærkelige fejl. - Glemme at opdatere når API’er skifter - særligt farligt ved auth.
Relaterede begreber
- JavaScript bundle, hydration - hvor meget logik der alligevel kører på klienten
- Third-party scripts - ofte problematisk at cache/agretere forkert
- Cache-Control, CDN
FAQ
Er service worker det samme som browser-cache?
Nej. HTTP-cache styres af Cache-Control og browserens heuristikker. Service worker er et JavaScript-lag der kan intercepte fetch og implementere egne strategier (fx netværk først, cache først, stale-while-revalidate). De kan sameksistere, men er ikke det samme.
Skal jeg bruge service worker på et almindeligt website?
Kun hvis du har et klart mål: offline, PWA, eller avanceret prefetch. Det øger vedligehold og fejlflade. Mange sites klarer sig med god HTTP-cache og CDN uden service worker.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Fjern eller udsæt tunge tredjeparts scripts uden at ødelægge funktionalitet
Følg en praktisk guide til at finde, vurdere og udsætte tredjeparts scripts, så de ikke ødelægger LCP, INP og den samlede brugeroplevelse.
Sådan finder du lange tasks i DevTools og forbedrer INP
Lær hvordan du bruger DevTools til at finde lange tasks, tunge event handlers og JavaScript der gør siden træg at bruge.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
