Sitecheck Din hjemmeside, fuldt dækket
All terms
Glossary · Web performance

Web performance: levering, caching og uptime

Hvordan bytes når frem til browseren: komprimering, CDN, HTTP/2 og HTTP/3, lazy loading og uptime-overvågning — med den konfiguration, der får hver del til at virke.

Sitecheck Team

Core Web Vitals fortæller dig, at en side er langsom. Denne side dækker det leveringslag, der som regel forklarer hvorfor: hvordan svar komprimeres, hvor de leveres fra, hvilken protokol der bærer dem, hvad der udskydes, og om sitet overhovedet var oppe, da forespørgslen kom.

Det er overvejende konfiguration frem for kodeændringer, hvilket gør det til det billigste performance-arbejde, der findes.

Komprimering — Brotli og Gzip

HTTP-komprimering pakker tekstsvar — HTML, CSS, JavaScript, JSON, SVG — sammen før afsendelse, og browseren pakker ud ved modtagelse. To algoritmer er relevante: Gzip (understøttet overalt, RFC 1952) og Brotli (RFC 7932), som typisk opnår 15-25% bedre ratio end Gzip ved sammenlignelig hastighed på statisk tekst.

Mindre svar betyder færre bytes over linjen, hurtigere TTFB og tidligere LCP — især på mobil og forbindelser med høj latency. CPU-omkostningen er ubetydelig på moderne servere, fordi komprimerede statiske filer kan caches.

  • Aktivér Brotli med Gzip som fallback. Klienter annoncerer support via Accept-Encoding.
  • Præ-komprimér statiske filer ved build (.br- og .gz-søskendefiler), så serveren aldrig komprimerer på den varme sti.
  • Spring allerede komprimerede formater over. JPEG, PNG, WebP, AVIF, MP4 og WOFF2 vinder intet og spilder bare CPU.
  • Verificér ved at kigge efter Content-Encoding: br eller gzip i DevTools.
  • Bekræft at dit CDN respekterer encoding på cachede svar og varierer cache-nøglen på Accept-Encoding — en cache, der leverer Brotli til en klient, som ikke kan læse det, producerer volapyk.

CDN — Content Delivery Network

Et CDN er et distribueret netværk af edge-servere, der cacher og leverer ressourcer fra et sted tæt på den besøgende. Statiske filer, HTML, API-svar og i stigende grad edge compute leveres fra den node, der er nærmest.

Ved at terminere forbindelser på edge reducerer et CDN TTFB og forkorter TLS-handshakes, hvilket forbedrer Core Web Vitals for et globalt publikum. CDN'er absorberer også trafikspidser og DDoS-støj. For SEO betyder det direkte noget: crawlere oplever samme hastighed og stabilitet som dine brugere.

  • Sæt lange Cache-Control-levetider (public, max-age=31536000, immutable) på hashede, indholdsadresserede filer.
  • Brug kortere TTL'er plus stale-while-revalidate til HTML, der skal være frisk men robust.
  • Hav en klar purge- eller surrogate-key-strategi, så deploys invaliderer præcis de rigtige URL'er.
  • Videresend kun de headers og cookies, der faktisk påvirker svaret — hver ekstra varieret header fragmenterer cachen og sænker hit-raten.

HTTP/2 og HTTP/3

HTTP/2 (RFC 7540) multiplexer mange forespørgsler over én TCP-forbindelse, komprimerer headers med HPACK og understøtter stream-prioritering. Det fjerner HTTP/1.1's flaskehals per forbindelse, hvilket især betyder noget på sider med mange små ressourcer — fonte, ikoner, scripts, thumbnails.

HTTP/3 (RFC 9114) erstatter TCP med QUIC, en UDP-baseret transport (RFC 9000), der samler transport, kryptering og multiplexing i ét handshake. Afgørende er, at QUIC fjerner den head-of-line blocking, der stadig begrænser HTTP/2: én tabt pakke stopper ikke længere alle andre forespørgsler på forbindelsen.

HTTP/3 gør mest forskel på ustabile netværk med høj latency — mobilbrugere på svingende 4G, wi-fi-roaming, besøgende langt fra dit origin. Connection migration holder desuden sessioner i live, når en enhed skifter netværk.

  • Tjek forhandlingen med curl -I --http2 https://example.com eller Protocol-kolonnen i DevTools.
  • HTTP/2 forhandles ikke over plaintext i browsere, så HTTPS er en hård forudsætning.
  • Til HTTP/3: bekræft TLS 1.3, åbn UDP/443 i firewallen, og kig efter Alt-Svc: h3=":443" i svaret.
  • Behold HTTP/2 som fallback; klienter uden QUIC forhandler automatisk ned.
  • Genovervej din bundling-strategi. Under HTTP/2 vil du typisk have mindre, granulære filer — ikke de store sprite-sheets, HTTP/1.1 belønnede.

Lazy loading

Lazy loading udskyder ressourcer uden for skærmen, til brugeren scroller i nærheden af dem. Native support er loading="lazy" på <img> og <iframe>. JavaScript kan udskydes med dynamisk import() og route-level code splitting, og IntersectionObserver kan udskyde stort set alt andet.

Billeder og indlejrede medier er som regel de tungeste elementer på en side. At hente dem alle på forhånd spilder båndbredde på indhold, brugeren måske aldrig ser, og konkurrerer med de forespørgsler, der faktisk driver LCP.

  • Tilføj loading="lazy" til billeder og iframes under folden.
  • Lazy-load aldrig hero- eller LCP-billedet. Forsinkelsen lander direkte i dit LCP. Brug fetchpriority="high" i stedet. Det er den klart mest udbredte lazy-loading-fejl.
  • Sæt eksplicit width og height på alle billeder for at reservere plads og undgå CLS.
  • I single-page apps: split route-bundles, så ubesøgte routes ikke sendes med ved første load.

Uptime-overvågning

Uptime-overvågning kører automatiske tjek — typisk HTTP-forespørgsler, nogle gange DNS- eller TCP-probes — med fast interval og alarmerer, når et tjek fejler eller returnerer en uventet status. Syntetiske tjek supplerer field data, der kun udløses, når der tilfældigvis er rigtige besøgende.

Uopdaget nedetid koster omsætning, placeringer og tillid. Crawlere, der rammer gentagne 5xx-svar, nedprioriterer URL'en, indtil den svarer rent igen. En "99,9% uptime"-SLA tillader stadig omkring 8,7 timers nedetid om året, og det meste af det budget bruges i en håndfuld lange hændelser — så at opdage et nedbrud i det første minut er forskellen på en note på statussiden og en postmortem.

  • Prob fra flere regioner, så ét ISP-problem ikke vækker alle.
  • Validér svarets indhold, ikke kun statuskoden. En vedligeholdelsesside returnerer ofte et pænt 200, og en overvågning, der kun ser på statuskoder, vil glad rapportere et nedbrud som sundt.
  • Følg TTFB på de samme tjek. Snigende latency er et tidligt varsel før hårde fejl.
  • Overvåg DNS-opslag og TLS-certifikatudløb separat — de fejler anderledes end origin-problemer, og et udløbet certifikat tager sitet ned lige så hårdt.
  • Kræv 2-af-3 bekræftelser, før en person alarmeres, så alarmtræthed undgås.

Sitecheck indeholder uptime-overvågning med probes fra flere regioner og indholdsvalidering, så tjekkene kører løbende i stedet for at blive sat op én gang og glemt.

Se også