Lås upp webbprestanda: En djupdykning i Performance Observer API

I dagens snabba digitala värld är webbprestanda inte en lyx; det är en nödvändighet. En långsam eller oresponsiv webbplats kan leda till användarfrustration, högre avvisningsfrekvens och en direkt negativ inverkan på affärsmål, oavsett om det är försäljning, annonsintäkter eller användarengagemang. I åratal har utvecklare förlitat sig på verktyg som mäter prestanda vid en enda tidpunkt, vanligtvis under den första sidinläsningen. Även om detta är användbart, missar detta tillvägagångssätt en kritisk del av historien: användarens hela upplevelse när de interagerar med sidan. Det är här övervakning av körprestanda kommer in, och dess mest kraftfulla verktyg är Performance Observer API.

Traditionella metoder involverar ofta polling av prestandadata med funktioner som performance.getEntries(). Detta kan vara ineffektivt, benäget att missa viktiga händelser som händer mellan pollingar och kan till och med bidra till de prestandakostnader det försöker mäta. Performance Observer API revolutionerar denna process genom att tillhandahålla en asynkron mekanism med låga omkostnader för att prenumerera på prestandahändelser när de inträffar. Den här guiden tar dig med på en djupdykning i detta viktiga API och visar dig hur du utnyttjar dess kraft för att övervaka Core Web Vitals, identifiera flaskhalsar och i slutändan bygga snabbare, roligare webbupplevelser för en global publik.

Vad är Performance Observer API?

I grunden är Performance Observer API ett gränssnitt som ger ett sätt att observera och samla in prestandamätningshändelser, så kallade prestandaposter. Tänk på det som en dedikerad lyssnare för prestandarelaterade aktiviteter i webbläsaren. Istället för att du aktivt frågar webbläsaren: "Har något hänt än?", talar webbläsaren proaktivt om för dig: "En ny prestandahändelse har precis inträffat! Här är detaljerna."

Detta uppnås genom ett observatörmönster. Du skapar en observatörsinstans, talar om för den vilka typer av prestandahändelser du är intresserad av (t.ex. stora färger, användarinmatningar, layoutförskjutningar) och tillhandahåller en callback-funktion. När en ny händelse av en specificerad typ registreras i webbläsarens prestandatidslinje, anropas din callback-funktion med en lista över de nya posterna. Denna asynkrona, push-baserade modell är mycket effektivare och mer tillförlitlig än den äldre pull-baserade modellen med upprepade anrop av performance.getEntries().

Det gamla sättet vs. Det nya sättet

För att uppskatta innovationen i Performance Observer, låt oss kontrastera de två tillvägagångssätten:

• Det gamla sättet (Polling): Du kan använda setTimeout eller requestAnimationFrame för att periodvis anropa performance.getEntriesByName('my-metric') för att se om ditt värde har registrerats. Detta är problematiskt eftersom du kan kontrollera för sent och missa händelsen, eller kontrollera för ofta och slösa CPU-cykler. Du riskerar också att fylla webbläsarens prestandabuffert om du inte rensar poster regelbundet.
• Det nya sättet (Observera): Du ställer in en PerformanceObserver en gång. Den sitter tyst i bakgrunden och förbrukar minimala resurser. Så snart en relevant prestandapost registreras – oavsett om det är en millisekund efter sidinläsning eller tio minuter in i en användares session – meddelas din kod omedelbart. Detta säkerställer att du aldrig missar en händelse och att din övervakningskod är så effektiv som möjligt.

Varför du bör använda Performance Observer

Att integrera Performance Observer API i ditt utvecklingsflöde erbjuder en mängd fördelar som är avgörande för moderna webbapplikationer som siktar på en global räckvidd.

• Icke-påträngande övervakning: Observatörens callback körs vanligtvis under inaktiva perioder, vilket säkerställer att din prestandaövervakningskod inte stör användarupplevelsen eller blockerar huvudtråden. Den är utformad för att vara lätt och ha ett försumbart prestandaavtryck.
• Omfattande kördata: Webben är dynamisk. Prestandaproblem händer inte bara vid inläsningstid. En användare kan utlösa en komplex animation, ladda mer innehåll genom att scrolla eller interagera med en tung komponent långt efter att den första sidan har stabiliserats. Performance Observer fångar dessa körhändelser, vilket ger dig en fullständig bild av hela användarsessionen.
• Framtidssäkert och standardiserat: Det är W3C:s rekommenderade standard för att samla in prestandadata. Nya prestandamätvärden och API:er är utformade för att integreras med det, vilket gör det till ett hållbart och framåtblickande val för dina projekt.
• Grunden för Real User Monitoring (RUM): För att verkligen förstå hur din webbplats fungerar för användare i olika länder, enheter och nätverksförhållanden behöver du data från verkliga sessioner. Performance Observer är det idealiska verktyget för att bygga en robust RUM-lösning, som gör att du kan samla in viktiga mätvärden och skicka dem till en analystjänst för aggregering och analys.
• Eliminerar Race Conditions: Med polling kan du försöka komma åt en prestandapost innan den har registrerats. Observatörmodellen eliminerar detta race condition helt, eftersom din kod bara körs efter att posten är tillgänglig.

Komma igång: Grunderna i Performance Observer

Att använda API:et är enkelt. Processen består av tre huvudsteg: att skapa en observatör, definiera en callback och tala om för observatören vad den ska hålla utkik efter.

1. Skapa en observatör med en callback

Först instansierar du ett PerformanceObserver-objekt och skickar det en callback-funktion. Denna funktion kommer att köras när nya poster upptäcks.

const observer = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log('Entry Type:', entry.entryType); console.log('Entry Name:', entry.name); console.log('Start Time:', entry.startTime); console.log('Duration:', entry.duration); } });

Callbacken tar emot ett PerformanceObserverEntryList-objekt. Du kan anropa metoden getEntries() på den här listan för att få en array med alla nyligen observerade prestandaposter.

2. Observera specifika posttyper

En observatör gör ingenting förrän du talar om för den vad den ska övervaka. Du gör detta med metoden .observe(). Denna metod tar ett objekt med en egenskap entryTypes (eller i vissa moderna fall bara type för en enskild typ), som är en array med strängar som representerar de prestandaposttyper du är intresserad av.

// Börja observera två typer av poster observer.observe({ entryTypes: ['mark', 'measure'] });

Några av de vanligaste posttyperna inkluderar:

• 'resource': Detaljer om nätverksförfrågningar för tillgångar som skript, bilder och formatmallar.
• 'paint': Tidsinställning för first-paint och first-contentful-paint.
• 'largest-contentful-paint': Core Web Vital-mätvärdet för upplevd laddningshastighet.
• 'layout-shift': Core Web Vital-mätvärdet för visuell stabilitet.
• 'first-input': Information om den första användarinteraktionen, som används för First Input Delay Core Web Vital.
• 'longtask': Identifierar uppgifter i huvudtråden som tar längre tid än 50 millisekunder, vilket kan orsaka oresponsivitet.
• 'mark' & 'measure': Anpassade markörer och mätningar som du definierar i din egen kod med User Timing API.

3. Stoppa observatören

När du inte längre behöver samla in data är det bra att koppla bort observatören för att frigöra resurser.

observer.disconnect();

Praktiska användningsfall: Övervakning av Core Web Vitals

Core Web Vitals är en uppsättning specifika faktorer som Google anser vara viktiga i en webbsidas övergripande användarupplevelse. Att övervaka dem är en av de mest kraftfulla tillämpningarna av Performance Observer API. Låt oss se hur man mäter var och en.

Övervakning av Largest Contentful Paint (LCP)

LCP mäter laddningsprestanda. Den markerar tidpunkten i sidans laddningstidslinje när huvudinnehållet troligen har laddats. En bra LCP-poäng är 2,5 sekunder eller mindre.

LCP-elementet kan ändras när sidan laddas. Inledningsvis kan en rubrik vara LCP-elementet, men senare kan en större bild laddas och bli det nya LCP-elementet. Det är därför en Performance Observer är perfekt – den meddelar dig om varje potentiell LCP-kandidat när den renderas.

// Observera LCP och logga det slutliga värdet let lcpValue = 0; const lcpObserver = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); // Den sista posten är den mest uppdaterade LCP-kandidaten const lastEntry = entries[entries.length - 1]; lcpValue = lastEntry.startTime; console.log(`LCP uppdaterad: ${lcpValue.toFixed(2)}ms`, lastEntry.element); }); lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true }); // Det är bra att koppla bort observatören efter att användaren interagerar, // eftersom interaktioner kan hindra nya LCP-kandidater från att skickas. // window.addEventListener('beforeunload', () => lcpObserver.disconnect());

Observera användningen av buffered: true. Detta är ett avgörande alternativ som instruerar observatören att inkludera poster som registrerades *innan* metoden observe() anropades. Detta hindrar dig från att missa en tidig LCP-händelse.

Övervakning av First Input Delay (FID) och Interaction to Next Paint (INP)

Dessa mätvärden mäter interaktivitet. De kvantifierar användarens upplevelse när de först försöker interagera med sidan.

First Input Delay (FID) mäter tiden från det att en användare först interagerar med en sida (t.ex. klickar på en knapp) till den tidpunkt då webbläsaren faktiskt kan börja behandla händelsehanterare som svar på den interaktionen. En bra FID är 100 millisekunder eller mindre.

Interaction to Next Paint (INP) är ett nyare, mer omfattande mätvärde som har ersatt FID som en Core Web Vital i mars 2024. Medan FID endast mäter *fördröjningen* av den *första* interaktionen, bedömer INP den *totala latensen* för *alla* användarinteraktioner under sidans livscykel och rapporterar den sämsta. Detta ger en bättre bild av den totala responsiviteten. En bra INP är 200 millisekunder eller mindre.

Du kan övervaka FID med posttypen "first-input":

// Observera FID const fidObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { const fid = entry.processingStart - entry.startTime; console.log(`FID: ${fid.toFixed(2)}ms`); // Koppla bort efter att den första inmatningen har rapporterats fidObserver.disconnect(); } }); fidObserver.observe({ type: 'first-input', buffered: true });

Att övervaka INP är lite mer komplicerat eftersom det tittar på hela varaktigheten av en händelse. Du observerar posttypen "event" och beräknar varaktigheten och håller reda på den längsta.

// Förenklat INP-övervakningsexempel let worstInp = 0; const inpObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // INP är händelsens varaktighet const inp = entry.duration; // Vi bryr oss bara om interaktioner som är längre än den nuvarande värsta if (inp > worstInp) { worstInp = inp; console.log(`Ny värsta INP: ${worstInp.toFixed(2)}ms`); } } }); inpObserver.observe({ type: 'event', durationThreshold: 16, buffered: true }); // durationThreshold hjälper till att filtrera bort mycket korta, troligen obetydliga händelser.

Övervakning av Cumulative Layout Shift (CLS)

CLS mäter visuell stabilitet. Det hjälper till att kvantifiera hur ofta användare upplever oväntade layoutförskjutningar – en frustrerande upplevelse där innehåll flyttas på sidan utan varning. En bra CLS-poäng är 0,1 eller mindre.

Poängen är en aggregering av alla individuella layoutförskjutningspoäng. En Performance Observer är avgörande här, eftersom den rapporterar varje förskjutning när den inträffar.

// Observera och beräkna den totala CLS-poängen let clsScore = 0; const clsObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // Vi vill inte räkna förskjutningar som orsakats av användarinmatning if (!entry.hadRecentInput) { clsScore += entry.value; console.log(`Aktuell CLS-poäng: ${clsScore.toFixed(4)}`); } } }); clsObserver.observe({ type: 'layout-shift', buffered: true });

Egenskapen hadRecentInput är viktig. Det hjälper dig att filtrera bort legitima layoutförskjutningar som inträffar som svar på en användares åtgärd (som att klicka på en knapp som expanderar en meny), vilket inte ska räknas med i CLS-poängen.

Utöver Core Web Vitals: Andra kraftfulla posttyper

Även om Core Web Vitals är en bra utgångspunkt kan Performance Observer övervaka mycket mer. Här är några andra otroligt användbara posttyper.

Spåra långa uppgifter (`longtask`)

Long Tasks API exponerar uppgifter som upptar huvudtråden i 50 millisekunder eller längre. Dessa är problematiska eftersom sidan inte kan svara på användarinmatning medan huvudtråden är upptagen, vilket leder till en trög eller frusen upplevelse. Att identifiera dessa uppgifter är nyckeln till att förbättra INP.

// Observera långa uppgifter const longTaskObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log(`Lång uppgift upptäckt: ${entry.duration.toFixed(2)}ms`); // Egenskapen 'attribution' kan ibland tala om för dig vad som orsakade den långa uppgiften console.log('Attribution:', entry.attribution); } }); longTaskObserver.observe({ type: 'longtask', buffered: true });

Analysera resurstidsinställningar (`resource`)

Att förstå hur dina tillgångar laddas är grundläggande för prestandajustering. Posttypen "resource" ger dig detaljerade nätverkstidsdata för varje resurs på din sida, inklusive DNS-uppslagning, TCP-anslutning och nedladdningstider för innehåll.

// Observera resurstidsinställningar const resourceObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // Låt oss hitta långsamt laddande bilder if (entry.initiatorType === 'img' && entry.duration > 500) { console.warn(`Långsam bild upptäckt: ${entry.name}`, `Duration: ${entry.duration.toFixed(2)}ms`); } } }); // Att använda 'buffered: true' är nästan alltid nödvändigt för resurstidsinställningar // för att fånga tillgångar som laddades innan detta skript kördes. resourceObserver.observe({ type: 'resource', buffered: true });

Mät anpassade prestandamarkeringar (`mark` och `measure`)

Ibland måste du mäta prestandan för applikationsspecifik logik. User Timing API gör att du kan skapa anpassade tidsstämplar och mäta varaktigheten mellan dem.

• performance.mark('start-operation'): Skapar en tidsstämpel med namnet 'start-operation'.
• performance.mark('end-operation'): Skapar en annan tidsstämpel.
• performance.measure('my-operation', 'start-operation', 'end-operation'): Skapar en mätning mellan de två markeringarna.

Performance Observer kan lyssna efter dessa anpassade poster 'mark' och 'measure', vilket är perfekt för att samla in tidsdata om saker som komponentrenderingstider i ett JavaScript-ramverk eller varaktigheten för ett kritiskt API-anrop och efterföljande databehandling.

// I din applikationskod: performance.mark('start-data-processing'); // ... någon komplex databehandling ... performance.mark('end-data-processing'); performance.measure('data-processing-duration', 'start-data-processing', 'end-data-processing'); // I ditt övervakningsskript: const customObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntriesByName('data-processing-duration')) { console.log(`Anpassad mätning '${entry.name}': ${entry.duration.toFixed(2)}ms`); } }); customObserver.observe({ entryTypes: ['measure'] });

Avancerade koncept och bästa praxis

För att använda Performance Observer API effektivt i en professionell produktionsmiljö bör du tänka på dessa bästa praxis.

• Tänk alltid på `buffered: true`: För posttyper som kan inträffa tidigt i sidinläsningen (som 'resource', 'paint' eller 'largest-contentful-paint') är det viktigt att använda den buffrade flaggan för att undvika att missa dem.
• Kontrollera webbläsarstöd: Även om det stöds brett i moderna webbläsare är det alltid klokt att kontrollera om det finns innan du använder det. Du kan också kontrollera vilka posttyper som stöds av en specifik webbläsare.
• if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes.includes('longtask')) { // Säkert att använda PerformanceObserver för långa uppgifter }
• Skicka data till en analystjänst: Att logga data till konsolen är bra för utveckling, men för verklig övervakning måste du aggregera dessa data. Det bästa sättet att skicka denna telemetri från klienten är att använda API:et navigator.sendBeacon(). Det är en icke-blockerande mekanism utformad för att skicka små mängder data till en server, och den fungerar tillförlitligt även när en sida håller på att avlastas.
• Gruppera observatörer efter ämne: Även om du kan använda en enda observatör för flera posttyper är det ofta renare att skapa separata observatörer för olika ämnen (t.ex. en för Core Web Vitals, en för resurstidsinställningar, en för anpassade mätvärden). Detta förbättrar kodens läsbarhet och underhållbarhet.
• Förstå prestandakostnaderna: API:et är utformat för att vara mycket låga omkostnader. En mycket komplex callback-funktion som utför tunga beräkningar kan dock potentiellt påverka prestandan. Håll dina observatörs-callbacks slimmade och effektiva. Skjut upp all tung bearbetning till en webbarbetare eller skicka rådata till din backend för bearbetning där.

Slutsats: Bygga en prestanda-först-kultur

Performance Observer API är mer än bara ett annat verktyg; det är en grundläggande förändring i hur vi närmar oss webbprestanda. Det flyttar oss från reaktiva, engångsmätningar till proaktiv, kontinuerlig övervakning som återspeglar den verkliga, dynamiska upplevelsen av våra användare över hela världen. Genom att tillhandahålla ett tillförlitligt och effektivt sätt att fånga Core Web Vitals, långa uppgifter, resurstidsinställningar och anpassade mätvärden, ger det utvecklare möjlighet att identifiera och lösa prestandaflaskhalsar innan de påverkar ett betydande antal användare.

Att anta Performance Observer API är ett avgörande steg mot att bygga en prestanda-först-kultur i alla utvecklingsteam. När du kan mäta det som är viktigt kan du förbättra det som är viktigt. Börja integrera dessa observatörer i dina projekt idag. Dina användare – var de än befinner sig i världen – kommer att tacka dig för den snabbare, smidigare och roligare upplevelsen.