Real User Monitoring: Att förstå webbplatsens hastighet i fält och i laboratoriet

Verkliga användare och laboratorietester

Övervakning av verkliga användare (RUM) registrerar hur en webbplats fungerar vid faktiska besök. Ett besök på en äldre smartphone via mobilnätet kan skilja sig avsevärt från ett besök på en stationär dator med snabb anslutning. Även de sidor som besöks och interaktionerna som sker ingår i den bild som observeras.

En Laboratorietest Däremot undersöks ett definierat anrop under kontrollerade förhållanden. Enhetsmodell, nätverksförhållanden och testförlopp kan fastställas inför en undersökning. Detta gör det enklare att återupprepa ett avvikande beteende och att testa eventuella förändringar under jämförbara förhållanden.

De båda synsätten besvarar olika frågor: Fältdata kan visa att mobila produktsidor ofta laddas långsamt. De bevisar dock inte om det till exempel är produktbilden, renderingsvägen eller ett långsamt dokumentsvar som är orsaken. För att hitta orsaken krävs ytterligare diagnostik och verifierbara hypoteser.

PageSpeed Insights kombinerar båda perspektiven: Verktyget jämför tillgängliga fältdata från Chrome User Experience Report med laboratoriediagnoser baserade på Lighthouse. Resultaten behöver inte stämma överens, eftersom verkliga besök omfattar olika förhållanden och användningsmönster, medan laboratoriet utgår från ett fastställt testfall.

RUM ersätter därför inte laboratoriet. Å andra sidan kan ett enskilt laboratorietest inte visa hur ofta ett problem uppstår hos verkliga besökare. Inför en lansering eller på en webbplats med få besökare kan det dessutom saknas tillräckliga fältdata; utan verkliga besök genereras inga egna RUM-mätvärden alls.

Så här beräknas RUM-värdena

En egen mätning kräver tre komponenter: en datainsamling i webbläsaren, en mottagare för de överförda värdena och en utvärdering. Inledningsvis bestämmer du vilka sidor och besökargrupper du vill analysera och hur uppgifterna ska skyddas. Först när enskilda värden sammanställs på ett meningsfullt sätt blir de en grund för beslut.

Webbläsare tillhandahåller olika prestandagränssnitt för detta ändamål. Navigering och tidsmätning beskriver tidpunkter i samband med navigeringen till dokumentet, till exempel svaret på dokumentförfrågan. Resource Timing tillhandahåller tidsinformation om enskilda laddade resurser, till exempel bilder eller skript. På så sätt går det att avgränsa olika delar av en laddningsprocess mer exakt.

En PerformanceObserver övervakar stödda prestandaposter så snart de blir tillgängliga. För Core Web Vitals kan biblioteket web-vitals sköta beräkningen och rapporteringen. Vilka poster och nyckeltal som är tillgängliga beror bland annat på webbläsaren; ett mätskript registrerar därför inte automatiskt varje besök i sin helhet.

Det är inte alla värden som genereras direkt vid laddningen. För INP måste det till exempel ske en lämplig interaktion: den som bara läser en sida och sedan lämnar den bidrar kanske inte med något värde. Ett saknat mätvärde är därför varken noll eller ett bevis på en snabb respons.

En RUM-tjänst kan tillhandahålla insamling, mottagning och utvärdering som ett paket. Om du utvecklar en egen lösning måste du dessutom organisera drift, lagring och kvalitetssäkring. Detta innefattar även att hantera upprepade meddelanden under sidans livscykel på rätt sätt, istället för att räkna varje meddelande som ett separat besök utan att kontrollera det.

Att tolka Core Web Vitals korrekt

Die Core Web Vitals beskriver tre olika aspekter av användarupplevelsen. Largest Contentful Paint (LCP) mäter när det största relevanta innehållselementet blir synligt. På en produktsida kan det till exempel vara en stor produktbild: om den visas sent kan sidan, trots att navigeringen är synlig redan tidigt, fortfarande ge intryck av att inte vara helt laddad.

Interaction to Next Paint (INP) mäter fördröjningen från en interaktion till nästa synliga uppdatering. Om ett produktfilter reagerar märkbart först efter ett klick kan INP peka på detta problem. Cumulative Layout Shift (CLS) beskriver däremot oväntade förskjutningar av synligt innehåll, till exempel när ett element som visas i efterhand förskjuter en knapp.

Vid utvärderingen i PageSpeed Insights anses ett LCP på upp till 2,5 sekunder, ett INP på upp till 200 millisekunder och ett CLS på upp till 0,1 vara bra. CLS är ett värde utan enhet. Tröskelvärdena gäller för respektive nyckeltal och bör inte förväxlas med varaktigheten för ett enskilt sidbesök.

Avgörande för fältbedömningen är 75:e percentilen (s. 75): Minst cirka 75 procent av de beaktade erfarenheterna ligger inte över det aktuella värdet. Ett bra genomsnitt i sig kan däremot dölja att en betydande del av besöken är långsamma. Betrakta mobil och stationär dator separat, så att skillnaderna mellan enhetsgrupperna förblir synliga.

Time to First Byte (TTFB) kompletterar dessa nyckeltal vid sökning efter ett långsamt dokumentsvar. Värdet avser dock inte enbart serverns beräkningstid: även nätverket och andra stationer fram till det att det första svarsbyte anländer påverkar resultatet. Navigation Timing och eventuellt tillgängliga Server Timing-data hjälper till att undersöka de berörda delarna mer ingående.

CrUX, eget RUM och laboratorium

För att komma igång behöver du inte genast driva ett eget mätsystem. PageSpeed Insights sammanställer fältdata från Rapport om användarupplevelsen i Chrome (CrUX) med en Lighthouse-laboratoriediagnos. De båda vyerna besvarar olika frågor: Den ena beskriver insamlade upplevelser, den andra undersöker en sida under kontrollerade förhållanden.

CrUX-fältdata i PageSpeed Insights avser en period på 28 dagar bakåt i tiden. Om det inte finns tillräckligt med data för en specifik URL kan rapporten istället visa data från ursprungswebbplatsen. Dessa omfattar den tillhörande webbplatsens ursprung och ska inte ses som en exakt återspegling av upplevelsen på just den angivna sidan. Var därför uppmärksam på vilken nivå rapporten faktiskt avser.

CrUX tar endast hänsyn till Chrome-användare som uppfyller de respektive kraven; andra webbläsare och icke-berättigade användare ingår inte. På en liten eller icke-offentlig webbplats kan CrUX-data saknas. En egen, juridiskt och tekniskt lämplig datainsamling kan ändå ge insikter där, men är statistiskt begränsad om antalet besök är få.

Syntetisk övervakning upprepar fördefinierade tester, även när ingen besöker webbplatsen just då. Den lämpar sig för att regelbundet övervaka ett förlopp under liknande förhållanden. Frågan om användare med andra enheter eller nätverk upplever samma sak måste besvaras genom fältmätningar; ett enskilt syntetiskt förlopp kan inte ersätta denna insikt.

Vid valet är det därför den fråga du vill besvara som är avgörande: En offentlig rapport är snabbt tillgänglig, medan ett eget system möjliggör en mer målinriktad datainsamling. En tjänst kan avlasta det operativa arbetet, medan laboratorie- och syntetiska tester möjliggör kontrollerade undersökningar. Men även en tjänst kräver ett medvetet urval av data och utvärderingsgrupper.

Förbered din egen mätning på ett säkert sätt

Bestäm först en konkret fråga, till exempel om mobila produktsidor oftare uppvisar ett högt LCP-värde än andra sidtyper. Bestäm sedan vilka sidor och enhetsklasser du vill skilja på, vilka mätvärden som krävs för detta och hur länge du vill samla in data. Först därefter bestämmer du vilka mätskript, mottagare och utvärderingsmetoder som ska användas.

Som ett första tekniskt steg kan du använda biblioteket web-vitals integrera lokalt i ett webbläsarprojekt och granska resultatet i utvecklingsverktygen. Följande JavaScript-kod använder den publicerade paketversionen 6.2.3. Det förutsätter att denna version är installerad i projektet och att byggprocessen hanterar modulimporten. Exemplet skickar inga data till en server och aktiverar ingen separat mätning av mjuknavigering.

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

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

Konsolutmatningen är ett sätt att kontrollera integreringen, inte ett bevis på dina besökares hastighet. Öppna projektsidan och interagera till exempel med ett filter. Ett INP-värde förutsätter en lämplig interaktion och behöver inte visas omedelbart; utan lämplig interaktion kan det utebli helt. Även webbläsarstöd och sidans livscykel påverkar resultatet.

Planera för en senare utvärdering av Sidans livscykel 1: Rapporter kan skickas flera gånger, till exempel när en sida döljs och senare visas igen. Räkna inte dessa rapporter generellt som separata besök. Biblioteket tillhandahåller mät-ID:n som gör det möjligt att koppla rapporter till samma mätvärde.

Även en återställning från Back/Forward-cachen kräver en definierad hantering. Den kan utlösa ett nytt mätvärdesmeddelande, trots att dokumentet hämtas från cachen. Bestäm hur du ska skilja sådana återställningar från vanliga navigeringar i din rapport och granska de specifika biblioteksanvisningarna innan du konfigurerar en produktiv datainsamling.

Analysera mätvärden per segment

Ett sammanlagt värde för webbutiken kan dölja att just produktsidorna på mobilen är långsammare. Dela därför upp mätvärdena åtminstone efter sidtyp och enhetsklass och betrakta varje mätvärde under en fastställd tidsperiod. På så sätt kan du till exempel jämföra produktsidor på mobilen med kategorisidor på mobilen, istället för att oavsiktligt blanda ihop olika användningssituationer.

För varje segment är det 75:e percentilen mer informativt än ett rent medelvärde: Det visar det värde som minst cirka 75 procent av de beaktade erfarenheterna inte överskrider. Ett lågt medelvärde kan däremot dölja att en relevant grupp får vänta länge. Jämför p75 endast inom samma mått och med lämplig enhet.

Antalet giltiga värden ingår direkt i resultatet. Om ett segment endast består av ett fåtal mätningar kan enskilda mätningar ha stor inverkan på percentilen; en förändring behöver då inte nödvändigtvis tyda på ett allmänt problem. Välj vid behov en längre tidsperiod eller slå samman sidor med liknande innehåll utan att förlora jämförbarheten.

Ett saknat INP-värde är inte ett snabbt INP-värde och får inte räknas in som noll i fördelningen. Ange istället antalet giltiga INP-värden separat. Om många besök inte ger någon lämplig interaktion beskriver INP-utvärderingen endast de registrerade interaktionsupplevelserna och inte automatiskt alla sidvisningar.

Sammanställ upprepade rapporter på ett korrekt sätt utifrån metrik-ID:t, istället för att behandla varje återkoppling som en ny, fristående observation. Dokumentera dessutom hur återställningar från back/forward-cachen räknas. På så sätt går det att spåra vilka observationer som faktiskt ingår i p75 och i det angivna antalet.

Från fältproblemet till diagnosen

Om fältdata visar att produktsidorna laddas långsamt på mobila enheter bör du först avgränsa det berörda segmentet: Gäller den dåliga LCP-tiden många produkter eller bara en viss typ av sida? Kontrollera samtidigt tidsperioden och antalet giltiga värden. På så sätt får du en utgångspunkt för undersökningen, men ännu inget bevis för vilket element som orsakar fördröjningen.

Ange sedan i Laboratorietest Skapa så liknande förhållanden som möjligt, till exempel med en mobil enhetskonfiguration och begränsad nätverkshastighet. Undersök vilket element som framträder som LCP och när det laddas och visas. En stor produktbild, en sen bildförfrågan eller en blockerad renderingsväg är möjliga hypoteser som du måste testa utifrån diagnosen.

Om det finns tecken på att bilder överförs kan du undersöka filstorlek, format och tillgänglighet. En Nätverk för innehållsleverans är en möjlig åtgärd, men ingen garanti för ett bättre LCP. Om dokumentets svar däremot tyder på en flaskhals, kan en kompletterande Serverbenchmark för PHP-arbetsbelastningar, att undersöka tillämpningen under fastställda förhållanden.

När det gäller ett fördröjt produktfilter är interaktionen avgörande, inte laddningsprocessen. Simulera ett filterklick och undersök vilka åtgärder som krävs innan uppdateringen blir synlig. Där webbläsaren stöder detta kan Långa animeringsrutor Dessa uppgifter ger en indikation på långa renderingsuppdateringar och vilka skript som är inblandade; de förklarar inte automatiskt varje långsam interaktion.

Genomför en målinriktad förändring och observera sedan samma sidgrupp på nytt i fält. Ett bättre laboratorieresultat visar inledningsvis endast effekten under de valda testförhållandena. Först den efterföljande fältutvärderingen kan visa om även de registrerade erfarenheterna hos verkliga besökare har förändrats.

Datakvalitet och dataskydd i verksamheten

Bestäm innan den produktiva driften inleds vilka mätvärden som krävs för din frågeställning och vem som ska bearbeta dem. Planeringen omfattar säker överföring till mottagaren, åtkomstbegränsningar, en begränsad lagringstid och ett förfarande för radering. Granska frågor om dataskydd och samtycke för den konkreta implementeringen och de gällande reglerna utifrån ett fackmässigt perspektiv, istället för att utgå från ett generellt godkännande.

Med Minimering av data Det är värt att titta på diagnosfält: Fullständiga URL:er kan innehålla känslig information i frågeparametrar; även DOM-selektorer kan avslöja detaljer om sidinnehåll eller inmatningar. Registrera om möjligt en allmän sidtyp och några få noggrant utvalda attribut. Kontrollera även vilka uppgifter en integrerad tjänst dessutom samlar in eller lagrar.

Mätvärdena är inte alltid tillgängliga omedelbart. Biblioteket web-vitals kan skicka återkoppling flera gånger under sidans livscykel; en senare rapport får därför inte automatiskt räknas som ett nytt, fristående besök. Planera hur sammanhängande meddelanden ska bearbetas och hur återställningar från bakåt-/framåt-cachen ska hanteras.

För små diagnostikpaket kan överföringen ske via sendBeacon vid evenemanget visibilitychange vara lämpligt. Detta förbättrar möjligheten att skicka data när en sida döljs, men garanterar inte att meddelandet levereras. Mottagaren måste dessutom ta emot data på ett säkert sätt och bearbeta den så att upprepade meddelanden inte i smyg förvränger utvärderingen.

Tänk slutligen på Brister i registreringen: Blockerade skript, bristande webbläsarstöd eller förlorade överföringar kan leda till att vissa besök saknas. Uppskatta en förlustprocent tillsammans med typen av datainsamling. De återstående mätvärdena beskriver den observerade gruppen och behöver inte nödvändigtvis återspegla alla besökare på samma sätt.

Granska förändringar och välja förfarande

För att göra en jämförelse efter en driftsättning anger du i förväg vilka sidtyper, enhetsklasser och tidsperioder som ska beaktas. Jämför för varje mätvärde den 75:e percentilen och antalet giltiga värden före och efter ändringen. Tidsfönster av ungefär samma längd underlättar tolkningen, men det innebär inte automatiskt att man får tillräckligt jämförbara urval.

Var uppmärksam på förändringar i besökarsammansättningen. Om fler användare med långsamma mobilanslutningar ansluter sig efter en driftsättning kan det totala värdet försämras, även om själva förändringen inte är långsammare. Även säsongsbetonad användning eller andra samtidiga förändringar försvårar tolkningen. Ett tidsmässigt samband är därför en hypotes, inte en Bevis för orsakssamband.

CrUX och en egen RUM behöver inte ge samma resultat: de kan omfatta olika användargrupper, tidsfönster och mätförhållanden. När det gäller CLS tillkommer dessutom att CrUX även tar hänsyn till bidrag från inbäddade ramar till upplevelsen av den överordnade sidan. En JavaScript-mätning i huvuddokumentet registrerar inte alltid dessa bidrag fullständigt. Jämför därför först mätgrunderna innan du betraktar en avvikelse som ett fel.

När det gäller en enkel-sidans applikation bör du bestämma om du vill undersöka dokumentnavigering eller interna ruttbyten. För separat registrering av Mjuk navigering Stöder Web Vitals från version 6 och uppåt, förutsatt att webbläsaren har lämpligt stöd, alternativet reportSoftNavs: true. Den måste anges i respektive mätnings-callback. Det tidigare konsol exemplet utan denna inställning aktiverar ingen separat ruttmätning.

När registrering av mjuk navigering är aktiverad återställs CLS och INP för den nya navigeringen och betraktas separat; värdena från den föregående navigeringen avslutas vid ruttbytet. Du bör inte jämföra sådana värden, som avgränsas tidsmässigt på ett annat sätt, med mätningar som omfattar hela dokumentet utan att först kontrollera dem. Utan lämpligt webbläsarstöd leder alternativet inte till en motsvarande separat ruttmätning.

När du väljer en RUM-tjänst bör du, förutom webbläsartäckningen, kontrollera om de nödvändiga sidgrupperna och enhetsklasserna kan analyseras. Ställ frågor om urvalsmetoder, databehandling, lagring och exportmöjligheter. Lika viktigt är vilken inverkan mätskriptet i sig kan ha på sidan och om dess datainsamling kan begränsas till det som är nödvändigt för din undersökning.