Kort fortalt: Når du bygger custom RUM, læser du ofte performance.getEntriesByType('navigation'). Det knytter sig til TTFB, FCP og tid til DOM-ready – altså hele dokumentets livscyklus, ikke enkelte filer (dem dækker Resource Timing API).
Hvis du er ny på området
Navigation Timing er ét objekt pr. sideindlæsning (i klassiske multi-page apps) med tidsstempler for DNS, connect, respons og DOM-events. Det er «film over hele turen», hvor Resource Timing er «hvert enkelt klip» (hver fil). Uden den forskel blander folk ofte langsom server sammen med langsom JavaScript efter HTML er kommet.
Hvad du kan udlede
TTFB-lignende segmenter, redirect-tid, og hvor lang tid før DOM er klar. Kombinér med Resource Timing API for enkelt-ressourcer.
Navigationens tidslinje i browseren
performance.getEntriesByType('navigation') (eller PerformanceNavigationTiming) giver tidsstempler for DNS, connect, request/response, domInteractive, load event m.fl. Det er grundlaget for at forstå oplevet hastighed på dokumentniveau.
Brug det til at splitte TTFB fra DOM-arbejde: hvis TTFB er høj, er problemet server/netværk; hvis DOM er langsom, er problemet ofte HTML-kompleksitet og scripts.
SPA og soft navigations
Klassisk Navigation Timing dækker fuld side-load. I SPA’er skal I supplere med web-vitals biblioteket og route-change måling - ellers ser alt «hurtigt» ud fordi hard reload sjældent sker.
Sammenlign ikke apples og pærer mellem MPA og SPA uden at dokumentere metoden.
Privatliv og sampling i RUM
Send ikke fuld URL med personhenførbare querystrings til tredjeparts RUM. Aggreger og anonymisér i overensstemmelse med politik.
Sample på realistisk trafik - mål ikke kun loggede power users.
Videre på sitet
- Resource Timing API – per fil og tredjepart.
- CrUX og Lighthouse vs. CrUX – felt vs. lab.
- Sådan læser du et waterfall – kobl API-felter til visuel kæde.
FAQ
Er Navigation Timing nok?
Det dækker navigation - supplér med Long Tasks og element timing for LCP.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering
Hvis LCP bliver en tilfældig paragraf i stedet for hero, får du både dårligere tal og en måling der ikke matcher brugerens første indtryk. Her er en konkret metode til at få hero (H1/billede) til at blive LCP – uden at snyde.
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.
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.
Hvordan du spotter render delay (uden at stirre på score)
Render delay er ofte grunden til at LCP bliver 1–2 sekunder for sent, selv når TTFB ser fin ud. Her er metoden til at finde årsagen hurtigt – og vælge den rigtige type fix.
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.
