Navigation og resource timings — Browserens performance-API
Navigation Timing API måler dokumentnavigation (TTFB, DOMContentLoaded, load). Resource Timing API måler individuelle ressourcers netværkstider. Begge bruges som grundlag for RUM.
Navigation Timing og Resource Timing er del af W3C Performance API — et sæt browser-interfaces der eksponerer detaljerede netværks- og timing-data direkte i JavaScript. De er fundamentet for real user monitoring (RUM) og giver præcise målinger af hvad brugerne faktisk oplever i modsætning til syntetiske tests. For SEO er de relevante fordi de giver adgang til de samme metrics Google bruger som rankingsignaler — TTFB og LCP kan beregnes direkte fra disse APIs.
Navigation Timing — sidens indlæsningsforløb
PerformanceNavigationTiming dækker den primære dokument-navigation og afslører hvert trin:
const nav = performance.getEntriesByType('navigation')[0];
console.log('DNS lookup:', nav.domainLookupEnd - nav.domainLookupStart, 'ms');
console.log('TCP connect:', nav.connectEnd - nav.connectStart, 'ms');
console.log('TTFB:', nav.responseStart - nav.requestStart, 'ms');
console.log('DOM parsing:', nav.domContentLoadedEventEnd - nav.responseEnd, 'ms');
console.log('Samlet load:', nav.loadEventEnd - nav.startTime, 'ms');
Nøgle-properties:
domainLookupStart/End— DNS-opslagconnectStart/End— TCP-forbindelsesetableringsecureConnectionStart— TLS-handshake startrequestStart/responseStart— TTFB-beregningresponseEnd— Hele response modtagetdomContentLoadedEventEnd— DOM klarloadEventEnd— Alle ressourcer indlæst
Resource Timing — individuelle ressourcer
PerformanceResourceTiming giver samme netværkstimer for hver ressource der hentes — scripts, stylesheets, billeder, fonts og API-kald:
const resources = performance.getEntriesByType('resource');
resources.forEach(r => {
const duration = r.responseEnd - r.startTime;
if (duration > 500) {
console.warn(`Langsom ressource: ${r.name} — ${Math.round(duration)}ms`);
}
});
Dette bruges til at identificere flaskehalse: hvilke ressourcer er langsomst? Hvilke serveres uden caching? Hvilke blokerer rendering?
Brug i RUM-implementering
En minimal RUM-beacon kan konstrueres direkte fra Performance API:
window.addEventListener('load', () => {
const nav = performance.getEntriesByType('navigation')[0];
fetch('/analytics', {
method: 'POST',
body: JSON.stringify({
ttfb: Math.round(nav.responseStart - nav.requestStart),
domReady: Math.round(nav.domContentLoadedEventEnd - nav.startTime),
load: Math.round(nav.loadEventEnd - nav.startTime),
url: location.href,
}),
keepalive: true,
});
});
keepalive: true sikrer at beacon-kald gennemføres selv når brugeren navigerer væk fra siden.
Timing-data og Core Web Vitals
Navigation Timing er inputtet til beregning af TTFB — en indikator for server-responsivitet. Resource Timing identificerer render-blocking ressourcer der forsinker LCP. Begge er tilgængelige i PerformanceObserver for live-observering under siden er aktiv.
Google bruger Chrome User Experience Report (CrUX) — ikke direkte Performance API-data — som rankinggrundlag. Men RUM baseret på Performance API er den mest præcise måde at forstå egne brugeres oplevelse på. → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.
Andre artikler i samme emne
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning
Ofte stillede spørgsmål
- Hvad er forskellen på Navigation Timing og Resource Timing?
- Navigation Timing måler den primære sides indlæsningsforløb — DNS, TCP, TTFB, DOM-bygning og load-event. Resource Timing måler de individuelle ressourcer (billeder, scripts, stylesheets) der hentes under indlæsningen. Navigation Timing giver overblik over siden som helhed; Resource Timing giver detaljer om hver enkelt fil.
- Hvordan tilgås timing-data i JavaScript?
- Via Performance API: `performance.getEntriesByType('navigation')` returnerer et PerformanceNavigationTiming-objekt. `performance.getEntriesByType('resource')` returnerer et array af PerformanceResourceTiming-objekter — ét per indlæst ressource. Begge er tilgængelige i alle moderne browsere.
- Kan Navigation Timing bruges til at måle TTFB præcist?
- Ja. TTFB beregnes som `responseStart - requestStart` fra PerformanceNavigationTiming-objektet. Det er den præcise tid fra browseren sender HTTP-request til den modtager det første byte af serverens svar. Denne beregning giver et mere præcist tal end hvad mange tredjeparts-analytics-tools rapporterer.
- Hvad er PerformanceObserver og hvornår bruges det frem for getEntriesByType?
- PerformanceObserver er en event-baseret API der notificerer om nye performance-entries i realtid, mens siden er aktiv. getEntriesByType forespørger efter entries der allerede er sket. Til RUM-implementering er PerformanceObserver bedre fordi den fanger entries løbende — inkl. long tasks, layout shifts og LCP-events der sker efter sideload.
- Er Resource Timing tilgængeligt for ressourcer fra tredjepartsdomæner?
- Delvist. Af sikkerhedshensyn returnerer Resource Timing kun tidsstempeldata (ikke headerinformation) for cross-origin ressourcer medmindre serveren sender Timing-Allow-Origin-headeren. Et CDN eller tredjepart kan tillade adgang ved at sætte Timing-Allow-Origin: * i deres response-headers.
Placering i ordbogen
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning