RUM vs. syntetisk monitoring — To syn på web performance

RUM (Real User Monitoring) og syntetisk monitoring er to komplementære tilgange til web performance-overvågning der besvarer fundamentalt forskellige spørgsmål. RUM måler hvad rigtige brugere faktisk oplever på tværs af enheder, netværkshastigheder og geografi. Syntetisk monitoring måler under kontrollerede betingelser for reproducerbarhed og regressionsdetektion. For SEO er skellet kritisk: Google bruger CrUX-data (en form for RUM) som rankinggrundlag — ikke Lighthouse-scores fra syntetisk testing.

Syntetisk monitoring

Syntetisk monitoring kører automatiserede tests med foruddefinerede parametre: specifik enhed, netværkshastighed, geografisk lokation. Testen er reproducerbar — den samme side under de samme betingelser giver (næsten) det samme resultat.

Primære tools:

• Lighthouse (Chrome DevTools, CLI, CI) — giver detaljerede performance-scores og konkrete forbedringssforslag
• WebPageTest — avancerede tests fra globale lokationer med filmstribe-visualisering af indlæsning
• PageSpeed Insights (Lab-data) — Lighthouse kørt på Googles servere mod en specifik URL

Hvornår syntetisk er det rigtige valg:

• Regression testing i CI/CD — fang forringelser inden deployment
• Debugging — reproducerbar test der kan gentages efter ændringer
• Benchmarking mod konkurrenter under kontrollerede forhold

Begrænsninger:

• Afspejler ikke rigtige brugeres enhed, forbindelseshastighed og geografiske lokation
• Cache-tilstand afviger fra rigtige brugeres (typisk cold cache i tests)
• Tredjepartsscripts fra brugerens session mangler

Real User Monitoring (RUM)

RUM indsamler performance-data fra rigtige brugere via browser-APIs og sender dem til en analytics-endpoint. Data repræsenterer den faktiske fordeling af brugeroplevelser.

Implementering med PerformanceObserver:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'largest-contentful-paint') {
      sendBeacon({ lcp: entry.startTime, url: location.href });
    }
  }
});

observer.observe({ type: 'largest-contentful-paint', buffered: true });

Web Vitals library (Google) forenkler RUM-implementering:

import { getLCP, getFID, getCLS, getINP, getTTFB } from 'web-vitals';

getLCP(metric => sendBeacon(metric));
getINP(metric => sendBeacon(metric));
getCLS(metric => sendBeacon(metric));

Hvornår RUM er det rigtige valg:

• Forstå brugeroplevelsen på tværs af devices, netværk og geografi
• Identificere real-world performance-problemer der ikke fanges i lab
• Validere at optimeringer faktisk hjælper rigtige brugere

CrUX og Google ranking

Chrome User Experience Report (CrUX) er Googles aggregerede RUM-dataset baseret på anonymiserede data fra Chrome-brugere der har aktiveret Usage Statistics. Det er det datagrundlag Google bruger til Core Web Vitals som rankingfaktor.

CrUX kræver minimum ca. 1.000 besøg per URL-gruppe for at vise data. Nye sider og sider med lav trafik vises ikke i CrUX — og dermed heller ikke i GSC’s Core Web Vitals-rapport.

Konsekvensen: en side kan have en perfekt Lighthouse-score men dårlige CrUX-data (og dårlig ranking), og omvendt. Optimer altid med CrUX-data som det endelige mål.

Det kombinerede setup

Det mest effektive setup bruger begge:

1. Syntetisk (CI) — Lighthouse CI kører ved hvert deploy og fanger store regressioner inden de rammer brugerne
2. RUM (produktion) — Web Vitals library sender Core Vitals-data til Google Analytics 4 eller en custom endpoint
3. CrUX (Google) — GSC Core Web Vitals-rapport validerer at optimeringer slår igennem for rigtige brugere → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.