Overvågning af reelle brugere: At forstå webstedets hastighed i praksis og under laboratorieforhold

Rigtige brugere og laboratorietests

Overvågning af reelle brugere (RUM) registrerer, hvordan et websted fungerer ved faktiske besøg. Et besøg på en ældre smartphone via mobilnetværket kan adskille sig markant fra et besøg på en desktop med en hurtig forbindelse. Også de besøgte sider og interaktioner indgår i det observerede billede.

En Laboratorietest undersøger derimod et defineret opkald under kontrollerede forhold. Enhedstype, netværksforhold og testforløb kan fastlægges til en undersøgelse. Det gør det lettere at genskabe en afvigelse og undersøge eventuelle ændringer under sammenlignelige forhold.

De to perspektiver besvarer forskellige spørgsmål: Feltdata kan vise, at mobile produktsider ofte indlæses langsomt. De beviser dog ikke, om det f.eks. er produktbilledet, renderingsforløbet eller et langsomt dokumentsvar, der er årsagen. For at finde årsagen er der brug for yderligere diagnostik og verificerbare hypoteser.

PageSpeed Insights kombinerer begge perspektiver: Det sammenligner tilgængelige feltdata fra Chrome User Experience Report med laboratoriediagnoser baseret på Lighthouse. Resultaterne behøver ikke at stemme overens, da reelle besøg omfatter forskellige forhold og brugermønstre, mens laboratoriet undersøger et fastlagt testscenarie.

RUM kan derfor ikke erstatte laboratoriet. Omvendt kan en enkelt laboratorietest ikke vise, hvor ofte et problem opstår hos reelle besøgende. Før en lancering eller på et websted med meget få besøgende mangler der desuden muligvis tilstrækkelige feltdata; uden reelle besøg genereres der slet ingen egne RUM-måleværdier.

Sådan opstår RUM-måleværdier

En egen måling kræver tre komponenter: en registrering i browseren, en modtager til de overførte værdier og en analyse. Først skal du fastlægge, hvilke sider og besøgsgrupper du ønsker at se på, og hvordan dataene skal beskyttes. Først når de enkelte værdier er samlet på en meningsfuld måde, danner de et grundlag for beslutninger.

Browsere stiller forskellige ydeevne-grænseflader til rådighed til dette formål. Navigations-timing beskriver tidspunkter i forbindelse med navigationen til dokumentet, f.eks. svaret på dokumentforespørgslen. Resource Timing leverer tidsoplysninger om de enkelte indlæste ressourcer, f.eks. billeder eller scripts. På den måde kan man afgrænse de forskellige faser af en indlæsningsproces mere præcist.

En PerformanceObserver overvåger understøttede Performance-poster, så snart de bliver tilgængelige. For Core Web Vitals kan biblioteket web-vitals står for beregningen og indberetningen. Hvilke oplysninger og nøgletal der er tilgængelige, afhænger blandt andet af browseren; et måleskript registrerer derfor ikke automatisk hvert besøg fuldt ud.

Ikke alle værdier genereres direkte under indlæsningen. For INP skal der for eksempel finde en passende interaktion sted: Den, der blot læser en side og derefter forlader den igen, bidrager muligvis ikke med nogen værdi. En manglende måleværdi er derfor hverken nul eller et bevis på en hurtig reaktion.

En RUM-tjeneste kan levere registrering, modtagelse og analyse som en samlet pakke. Hvis du udvikler løsningen selv, skal du desuden sørge for drift, lagring og kvalitetssikring. Det indebærer også, at gentagne meddelelser i sidens livscyklus skal håndteres korrekt, i stedet for at tælle hver meddelelse som et uafhængigt besøg uden at kontrollere den.

Læs Core Web Vitals korrekt

Die Core Web Vitals beskriver tre forskellige aspekter af brugeroplevelsen. Largest Contentful Paint (LCP) måler, hvornår det største relevante indholdselement bliver synligt. På en produktside kan det f.eks. være et stort produktbillede: Hvis det vises sent, kan siden muligvis stadig virke som om den ikke er færdig med at indlæse, selvom navigationselementerne er synlige allerede tidligt.

Interaction to Next Paint (INP) måler forsinkelsen fra en interaktion til den næste synlige opdatering. Hvis et produktfilter først reagerer mærkbart efter et klik, kan INP påpege dette problem. Cumulative Layout Shift (CLS) beskriver derimod uventede forskydninger af synligt indhold, f.eks. når et element, der vises efterfølgende, forskydes en knap.

I vurderingen i PageSpeed Insights betragtes en LCP på op til og med 2,5 sekunder, en INP på op til og med 200 millisekunder og en CLS på op til og med 0,1 som gode værdier. CLS er en enhedsløs værdi. Tærskelværdierne gælder for den pågældende nøgletal og bør ikke forveksles med varigheden af et enkelt sidebesøg.

Det afgørende for feltvurderingen er 75. percentil (s. 75): Mindst ca. 75 procent af de medregnede oplevelser ligger ikke over den pågældende værdi. Et godt gennemsnit alene kan derimod skjule, at en betydelig del af besøgene er langsomme. Betragt mobil og desktop hver for sig, så forskellene mellem enhedsgrupperne forbliver synlige.

Time to First Byte (TTFB) supplerer disse nøgletal i forbindelse med søgning efter et langsomt svar på et dokument. Værdien er dog ikke udelukkende serverens beregningstid: Også netværket og andre stationer indtil ankomsten af det første svarbyte spiller en rolle. Navigation Timing og eventuelt tilgængelige Server Timing-data hjælper med at undersøge de involverede sektioner mere nøjagtigt.

CrUX, eget RUM og laboratorium

For at komme i gang behøver du ikke straks at drive dit eget målesystem. PageSpeed Insights kombinerer feltdata fra Chrome-rapport om brugeroplevelsen (CrUX) med en Lighthouse-laboratoriediagnose. De to oversigter besvarer forskellige spørgsmål: Den ene beskriver indsamlede erfaringer, den anden undersøger en side under kontrollerede forhold.

CrUX-feltdataene i PageSpeed Insights dækker en periode på de seneste 28 dage. Hvis der ikke er tilstrækkelige data for en bestemt URL, kan rapporten i stedet vise data fra oprindelsessiden. Disse data omfatter den tilhørende webstedsoprindelse og kan ikke sidestilles med oplevelserne på netop den indtastede side. Vær derfor opmærksom på, hvilket niveau rapporten rent faktisk viser.

CrUX tager kun højde for Chrome-brugere, der opfylder de relevante betingelser; andre browsere og ikke-berettigede brugere er ikke medtaget. På en lille eller ikke-offentlig hjemmeside kan CrUX-data mangle. En egen, juridisk og teknisk hensigtsmæssig dataindsamling kan dog stadig give indsigt, men er statistisk begrænset, hvis der kun er få besøg.

Syntetisk overvågning gentager definerede test, selv når der ikke er nogen, der besøger hjemmesiden. Den er velegnet til regelmæssigt at overvåge et forløb under ensartede forhold. Om brugere oplever det samme på andre enheder eller netværk, må en feltmåling afklare; et enkelt syntetisk forløb kan ikke erstatte dette perspektiv.

Valget afhænger derfor af, hvilket spørgsmål du ønsker at besvare: En offentlig rapport er hurtigt tilgængelig, mens et eget system giver mulighed for en mere målrettet dataindsamling. En tjeneste kan aflaste driftsarbejdet, mens laboratorie- og syntetiske tests muliggør kontrollerede undersøgelser. Men også en tjeneste kræver et bevidst valg af data og analysegrupper.

Forbered din egen måling på en sikker måde

Fastlæg først et konkret spørgsmål, f.eks. om mobile produktsider oftere har en høj LCP end andre sidetyper. Bestem derefter, hvilke sider og enhedsklasser du vil skelne mellem, hvilke måleparametre der er nødvendige til dette, og hvor længe du vil indsamle data. Først derefter træffer du beslutning om måleskript, modtager og analyse.

Som et første teknisk skridt kan du bruge biblioteket web-vitals integrere det lokalt i et browserprojekt og se resultatet i udviklerværktøjerne. Følgende JavaScript bruger den udgivne pakkeversion 6.2.3. Det forudsætter, at denne version er installeret i projektet, og at buildet håndterer modulimporten. Eksemplet sender ingen data til en server og aktiverer ingen separat måling af soft navigation.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

Konsoludskriften er en måde at kontrollere integrationen på, ikke et bevis på dine besøgendes hastighed. Åbn projektsiden og interagér f.eks. med et filter. En INP-værdi forudsætter en passende interaktion og vises ikke nødvendigvis med det samme; uden en passende interaktion kan den helt udblive. Også browserunderstøttelse og sidens livscyklus påvirker udskriften.

Planlæg med henblik på en senere evaluering af Sidens livscyklus 1: Der kan forekomme flere registreringer, f.eks. hvis en side skjules og senere vises igen. Disse registreringer skal ikke generelt tælles som uafhængige besøg. Biblioteket stiller metrik-ID’er til rådighed, som kan bruges til at knytte registreringer til den samme metrik.

Også en gendannelse fra Back/Forward-cachen kræver en defineret håndtering. Den kan udløse en ny metrikmeddelelse, selvom dokumentet hentes fra cachen. Fastlæg, hvordan du i din rapport skelner mellem sådanne genindlæsninger og almindelige navigationer, og gennemgå de konkrete biblioteksanvisninger, inden du konfigurerer en produktiv registrering.

Analysere måleværdier efter segmenter

En samlet værdi for webshoppen kan skjule, at netop produktsider på mobilen er langsommere. Opdel derfor målingerne som minimum efter sidetype og enhedsklasse, og se på en bestemt periode for hver enkelt måleparameter. På den måde kan du for eksempel sammenligne produktsider på mobilen med kategorisider på mobilen, i stedet for ubevidst at blande forskellige brugssituationer sammen.

For hvert segment er det 75. percentil mere sigende end et simpelt gennemsnit: Det viser den værdi, som mindst ca. 75 procent af de medregnede erfaringer ikke overstiger. Et lavt gennemsnit kan derimod skjule, at en relevant gruppe venter længe. Sammenlign kun p75 for den samme måleparameter og med den relevante enhed.

Antallet af gyldige værdier indgår direkte i resultatet. Hvis et segment kun består af få målinger, kan enkelte målinger have stor indflydelse på percentilen; en ændring behøver derfor ikke at være tegn på et generelt problem. Vælg om nødvendigt en længere periode, eller saml fagligt beslægtede sider, uden at det går ud over sammenligneligheden.

En manglende INP er ikke en hurtig INP og må ikke indgå i fordelingen som nul. Angiv i stedet antallet af gyldige INP-værdier separat. Hvis mange sidevisninger ikke leverer en passende interaktion, beskriver INP-analysen kun de registrerede interaktionsoplevelser og ikke automatisk alle sidevisninger.

Saml gentagne rapporter korrekt ud fra metrik-ID’et i stedet for at behandle hver tilbagemelding som en ny, uafhængig observation. Dokumenter desuden, hvordan gendannelser fra back/forward-cachen tælles. På den måde forbliver det overskueligt, hvilke observationer der faktisk er inkluderet i p75 og i det angivne antal.

Fra feltproblemet til diagnosen

Hvis feltdataene viser langsomme produktsider på mobilen, skal du først afgrænse det berørte segment: Gælder den dårlige LCP mange produkter eller kun én sidetype? Tjek samtidig tidsperioden og antallet af gyldige værdier. På den måde får du et udgangspunkt for undersøgelsen, men endnu ikke noget bevis for, hvilket element der forårsager forsinkelsen.

Indsæt derefter i Laboratorietest Genskab så lignende betingelser som muligt, f.eks. med en mobil enhedskonfiguration og begrænset netværkshastighed. Undersøg, hvilket element der vises som LCP, og hvornår det indlæses og vises. Et stort produktbillede, en forsinket billedanmodning eller en blokeret renderingssti er mulige hypoteser, som du skal undersøge på baggrund af diagnosen.

Hvis der er tegn på, at der overføres billeder, kan du undersøge filstørrelse, formater og tilgængelighed. En Indholdsleveringsnetværk er en mulig foranstaltning, men ingen garanti for en bedre LCP. Hvis dokumentresponsen derimod tyder på en flaskehals, kan en supplerende Server-benchmark for PHP-arbejdsbelastninger, at undersøge anvendelsen under fastlagte betingelser.

Ved et forsinket produktfilter er interaktionen afgørende i stedet for indlæsningsprocessen. Gengiv et filterklik, og undersøg, hvilket arbejde der skal udføres, indtil opdateringen bliver synlig. Hvor browseren understøtter det, kan Lange animationsrammer Disse oplysninger giver en indikation af lange rendering-opdateringer og de involverede scripts; de forklarer ikke automatisk alle tilfælde af langsom interaktion.

Gennemfør en målrettet ændring og observer derefter den samme sidegruppe igen i praksis. Et bedre laboratorieresultat viser i første omgang kun effekten under de valgte testbetingelser. Først den efterfølgende evaluering i praksis kan vise, om de registrerede erfaringer fra reelle besøgende også har ændret sig.

Datakvalitet og databeskyttelse i driften

Før den produktive anvendelse skal du fastlægge, hvilke måleværdier der er nødvendige for dit problemstilling, og hvem der skal behandle dem. Planlægningen skal omfatte sikker overførsel til modtageren, adgangsbegrænsninger, en begrænset opbevaringsperiode og en sletningsprocedure. Undersøg spørgsmål vedrørende databeskyttelse og samtykke i forbindelse med den konkrete implementering og de gældende regler ud fra et fagligt perspektiv, i stedet for at antage en generel godkendelse.

Med den Minimering af data Det er værd at kigge på diagnosefelterne: Fulde URL’er kan indeholde følsomme oplysninger i query-parametre; også DOM-selektorer kan afsløre detaljer om sideindhold eller indtastninger. Registrer om muligt en generel sidetype og nogle få, målrettet udvalgte attributter. Kontroller ligeledes, hvilke oplysninger en integreret tjeneste yderligere indsamler eller gemmer.

Måleværdier er ikke altid tilgængelige med det samme. Biblioteket web-vitals kan udsende tilbagemeldinger flere gange i løbet af en sides livscyklus; en senere meddelelse må derfor ikke uden videre tælle som et nyt, uafhængigt besøg. Planlæg, hvordan sammenhængende meddelelser skal behandles, og hvordan gendannelser fra Back/Forward-cachen skal håndteres.

For små diagnosepakker kan overførslen ske via sendBeacon ved begivenheden visibilitychange være egnet. Dette forbedrer muligheden for at udløse data, når en side skjules, men garanterer ikke levering. Modtageren skal desuden modtage dataene på en sikker måde og behandle dem således, at gentagne meddelelser ikke ubemærket forvrider analysen.

Til sidst skal du tage højde for Mangler i registreringen: Blokerede scripts, manglende browserunderstøttelse eller tabte dataoverførsler kan medføre, at visse besøg mangler. Vurder en anslået tabsprocent sammen med indsamlingsmetoden. De resterende måleværdier beskriver den observerede gruppe og afspejler ikke nødvendigvis alle besøgende i samme grad.

Vurdere ændringer og vælge fremgangsmåde

For at kunne foretage en sammenligning efter en implementering skal du på forhånd fastlægge, hvilke sidetyper, enhedsklasser og tidsperioder der skal tages i betragtning. Sammenlign for hver måleparameter det 75. percentil og antallet af gyldige værdier før og efter ændringen. Tidsvinduer af tilsvarende længde hjælper med at sætte ændringen i perspektiv; det betyder dog ikke, at der automatisk opstår tilstrækkeligt sammenlignelige stikprøver.

Vær opmærksom på ændringer i besøgsfordelingen. Hvis der efter en implementering kommer flere brugere med langsomme mobilforbindelser, kan den samlede værdi blive forringet, selvom ændringen i sig selv ikke er langsommere. Også sæsonbestemt brug eller andre samtidige ændringer gør det vanskeligt at fastslå årsagssammenhængen. En tidsmæssig sammenhæng er derfor en hypotese, ikke en Bevis for årsagssammenhæng.

CrUX og egen RUM behøver ikke at give de samme resultater: De kan dække forskellige brugergrupper, tidsvinduer og målebetingelser. Hos CLS kommer der desuden til, at CrUX også tager højde for bidrag fra indlejrede rammer til oplevelsen af den overordnede side. En JavaScript-måling i hoveddokumentet registrerer ikke altid disse bidrag fuldt ud. Sammenlign derfor først målegrundlagene, før du vurderer en afvigelse som en fejl.

I en single-page-applikation bør du afgøre, om du vil undersøge dokumentnavigation eller interne ruteskift. Til separat registrering af Blød navigation Understøtter Web Vitals fra version 6, forudsat at browseren understøtter det, følgende indstilling: reportSoftNavs: true. Den skal angives i de respektive metrik-callbacks. Det foregående konsol-eksempel uden denne indstilling aktiverer ikke en separat rutemåling.

Når registrering af soft-navigation er aktiveret, nulstilles CLS og INP for den nye navigation og betragtes separat; værdierne fra den forrige navigation afsluttes ved ruteskiftet. Du bør ikke uden nærmere kontrol sammenligne sådanne tidsmæssigt anderledes afgrænsede værdier med målinger på dokumentniveau. Uden passende browserunderstøttelse fører denne indstilling ikke til en tilsvarende separat rutemåling.

Når du skal vælge en RUM-tjeneste, skal du ud over browserdækningen også kontrollere, om de nødvendige sidegrupper og enhedsklasser kan analyseres. Spørg ind til stikprøveprocedurer, databehandling, opbevaring og eksportmuligheder. Det er ligeledes vigtigt at undersøge, hvilken indvirkning selve måleskriptet kan have på siden, og om dets dataindsamling kan begrænses til det, der er nødvendigt for din problemstilling.