En omfattende guide til bruk av Performance Observer API for å overvåke sanntidsytelse, identifisere flaskehalser og optimalisere ytelsen til webapplikasjoner. Lær hvordan du samler inn og analyserer målinger for en smidigere brukeropplevelse.
Performance Observer API: Sanntidsytelsesmålinger og flaskehalsanalyse
I dagens konkurransepregede digitale landskap er ytelsen til nettsteder og webapplikasjoner avgjørende for brukerengasjement og forretningssuksess. Lange lastetider og trege grensesnitt kan føre til frustrerte brukere, avbrutte transaksjoner og til syvende og sist tapte inntekter. Performance Observer API er et kraftig verktøy som lar utviklere overvåke og analysere sanntidsytelsesmålinger, identifisere flaskehalser og optimalisere applikasjonene sine for en smidigere, raskere og mer behagelig brukeropplevelse, uavhengig av brukerens plassering eller enhet.
Hva er Performance Observer API?
Performance Observer API er et JavaScript API som gir en mekanisme for å observere og reagere på ytelsesrelaterte hendelser etter hvert som de skjer i en webapplikasjon. I motsetning til tradisjonelle teknikker for ytelsesovervåkning som baserer seg på periodiske målinger eller manuell instrumentering, tilbyr Performance Observer API en mer effektiv og fleksibel måte å fange opp ytelsesdata i sanntid. Det lar utviklere abonnere på spesifikke typer ytelsesoppføringer og motta varsler når nye oppføringer registreres.
Denne "observer-og-reager"-tilnærmingen muliggjør proaktiv ytelsesovervåkning, som lar utviklere identifisere og løse ytelsesproblemer før de påvirker brukeropplevelsen. API-et er standardisert på tvers av moderne nettlesere, noe som sikrer konsistent oppførsel og kompatibilitet mellom plattformer.
Nøkkelkonsepter og funksjoner
For å kunne utnytte Performance Observer API effektivt, er det viktig å forstå kjernekonseptene og funksjonene:
- PerformanceEntry: Representerer en enkelt ytelsesmåling eller hendelse. Ytelsesoppføringer inneholder informasjon om typen hendelse, start- og sluttidspunkter og andre relevante attributter. Eksempler inkluderer
resource
,mark
,measure
,navigation
,longtask
, ogevent
. - PerformanceObserver: Et objekt som lar deg abonnere på spesifikke typer ytelsesoppføringer og motta varsler når nye oppføringer legges til i nettleserens ytelsestidslinje.
- observe()-metoden: Brukes til å konfigurere PerformanceObserver til å lytte etter spesifikke typer ytelsesoppføringer. Du kan spesifisere hvilke oppføringstyper du vil observere, samt et
buffered
-alternativ for å motta historiske oppføringer. - disconnect()-metoden: Brukes til å stoppe PerformanceObserver fra å lytte etter ytelseshendelser.
- takeRecords()-metoden: Returnerer en matrise med alle ytelsesoppføringer som har blitt observert, men ennå ikke behandlet av observatørens callback-funksjon.
- Callback-funksjon: En funksjon som utføres når nye ytelsesoppføringer observeres. Denne funksjonen mottar et
PerformanceObserverEntryList
-objekt som inneholder de observerte oppføringene.
Støttede typer ytelsesoppføringer
Performance Observer API støtter en rekke typer ytelsesoppføringer, der hver gir spesifikk innsikt i ulike aspekter av en webapplikasjons ytelse. Noen av de mest brukte oppføringstypene inkluderer:
resource
: Gir informasjon om lastingen av individuelle ressurser, som bilder, skript, stilark og fonter. Denne oppføringstypen inkluderer detaljer som ressurs-URL, start- og sluttidspunkter, hentetid og overføringsstørrelse.mark
: Lar deg lage egendefinerte tidsstempler i koden din for å måle varigheten av spesifikke kodeseksjoner. Du kan bruke markeringer for å spore starten og slutten på kritiske operasjoner, som databehandling eller UI-rendring.measure
: Brukes til å beregne varigheten mellom to markeringer. Denne oppføringstypen gir en praktisk måte å måle ytelsen til egendefinerte kodeseksjoner.navigation
: Gir informasjon om navigasjonstimingen for en side, inkludert DNS-oppslagstid, TCP-tilkoblingstid, forespørsels- og responstider, og DOM-behandlingstid.longtask
: Identifiserer oppgaver som blokkerer hovedtråden over en lengre periode (vanligvis lenger enn 50 millisekunder). Lange oppgaver kan forårsake at brukergrensesnittet ikke responderer og hakker (jank).event
: Registrerer tidsinformasjon for spesifikke nettleserhendelser, somclick
,keydown
, ogscroll
.layout-shift
: Sporer uventede layout-endringer på siden. Disse endringene kan være forstyrrende for brukere og påvirke brukeropplevelsen negativt.largest-contentful-paint
: Måler tiden det tar før det største innholdselementet blir synlig på siden.first-input-delay
: Måler tiden det tar for nettleseren å respondere på den første brukerinteraksjonen (f.eks. et klikk eller trykk).element
: Rapporterer tidsinformasjon for rendringen av spesifikke elementer på siden.
Praktiske eksempler og bruksområder
Performance Observer API kan brukes i en rekke scenarioer for å forbedre ytelsen til webapplikasjoner. Her er noen praktiske eksempler:
1. Overvåking av ressursers lastetider
Oppføringstypen resource
lar deg spore lastetidene for individuelle ressurser, som bilder, skript og stilark. Denne informasjonen kan brukes til å identifisere ressurser med lang lastetid som påvirker sidens innlastingstid. For eksempel kan du bruke følgende kode for å overvåke ressursers lastetider:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Resource: ${entry.name}, Duration: ${entry.duration}ms`);
});
});
observer.observe({ entryTypes: ["resource"] });
Denne koden oppretter en PerformanceObserver som lytter etter resource
-oppføringer og logger ressurs-URL og varighet til konsollen. Ved å analysere disse dataene kan du identifisere ressurser med lang lastetid og optimalisere dem ved å komprimere bilder, bruke et innholdsleveringsnettverk (CDN), eller optimalisere serverkonfigurasjonen din.
Globalt perspektiv: Når du overvåker ressursers lastetider, bør du vurdere den geografiske plasseringen til brukerne dine. Brukere i regioner med tregere internettforbindelser kan oppleve betydelig lengre lastetider. Bruk av et CDN med geografisk distribuerte servere kan bidra til å redusere dette problemet.
2. Måling av kjøretid for egendefinert kode
Oppføringstypene mark
og measure
lar deg måle kjøretiden for egendefinerte kodeseksjoner. Dette er nyttig for å identifisere ytelsesflaskehalser i applikasjonslogikken din. For eksempel kan du bruke følgende kode for å måle varigheten av en spesifikk funksjon:
performance.mark("start");
// Code to be measured
for (let i = 0; i < 1000000; i++) {
// Some computationally intensive operation
}
performance.mark("end");
performance.measure("My Function", "start", "end");
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Measurement: ${entry.name}, Duration: ${entry.duration}ms`);
});
});
observer.observe({ entryTypes: ["measure"] });
Denne koden oppretter to markeringer, start
og end
, før og etter kodeseksjonen du vil måle. Deretter bruker den performance.measure()
-metoden for å beregne varigheten mellom de to markeringene. PerformanceObserver lytter etter measure
-oppføringer og logger målingsnavnet og varigheten til konsollen. Ved å analysere disse dataene kan du identifisere kodeseksjoner som yter dårlig og optimalisere dem ved hjelp av teknikker som caching, memoization eller algoritmiske optimaliseringer.
Handlingsrettet innsikt: Identifiser applikasjonens kritiske stier – sekvensene av kode som oftest utføres og har størst innvirkning på ytelsen. Fokuser optimaliseringsinnsatsen på disse kritiske stiene for å oppnå de mest betydelige ytelsesforbedringene.
3. Identifisering av lange oppgaver
Oppføringstypen longtask
identifiserer oppgaver som blokkerer hovedtråden over en lengre periode. Lange oppgaver kan føre til at brukergrensesnittet ikke responderer og hakker, noe som gir en dårlig brukeropplevelse. Du kan bruke følgende kode for å overvåke lange oppgaver:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.warn(`Long Task: ${entry.name}, Duration: ${entry.duration}ms`);
console.warn(`Long Task Attribution: ${JSON.stringify(entry.attribution)}`);
});
});
observer.observe({ entryTypes: ["longtask"] });
Denne koden oppretter en PerformanceObserver som lytter etter longtask
-oppføringer og logger oppgavenavnet og varigheten til konsollen. Ved å analysere disse dataene kan du identifisere langvarige oppgaver og optimalisere dem ved å dele dem opp i mindre biter, bruke asynkrone operasjoner, eller flytte dem til en web worker.
Global skriveretningslinje: Når du forklarer tekniske konsepter, bruk et klart og konsist språk som er tilgjengelig for lesere med varierende teknisk ekspertise. Unngå sjargong og gi kontekst for ukjente begreper.
4. Analyse av navigasjonstiming
Oppføringstypen navigation
gir detaljert informasjon om navigasjonstimingen for en side, inkludert DNS-oppslagstid, TCP-tilkoblingstid, forespørsels- og responstider, og DOM-behandlingstid. Disse dataene kan brukes til å identifisere flaskehalser i sidens lastingsprosess. For eksempel kan du bruke følgende kode for å analysere navigasjonstiming:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Navigation: ${entry.name}`);
console.log(`DNS Lookup Time: ${entry.domainLookupEnd - entry.domainLookupStart}ms`);
console.log(`TCP Connection Time: ${entry.connectEnd - entry.connectStart}ms`);
console.log(`Request Time: ${entry.responseStart - entry.requestStart}ms`);
console.log(`Response Time: ${entry.responseEnd - entry.responseStart}ms`);
console.log(`DOM Processing Time: ${entry.domComplete - entry.domInteractive}ms`);
});
});
observer.observe({ entryTypes: ["navigation"] });
Denne koden oppretter en PerformanceObserver som lytter etter navigation
-oppføringer og logger ulike tidsmålinger til konsollen. Ved å analysere disse dataene kan du identifisere flaskehalser som tregt DNS-oppslag, treg TCP-tilkobling, treg forespørselsbehandling, treg responsbehandling, eller treg DOM-behandling. Du kan deretter iverksette passende tiltak for å løse disse flaskehalsene, som å optimalisere DNS-konfigurasjonen, forbedre serverytelsen, eller optimalisere HTML- og JavaScript-koden din.
SEO-optimalisering: Bruk relevante nøkkelord naturlig gjennom innholdet. I denne seksjonen er nøkkelord som "navigasjonstiming", "DNS-oppslagstid", "TCP-tilkoblingstid" og "sidens lastingsprosess" sømløst integrert.
5. Overvåking av layout-endringer
Oppføringstypen layout-shift
sporer uventede layout-endringer på siden. Disse endringene kan være forstyrrende for brukere og påvirke brukeropplevelsen negativt. De oppstår ofte på grunn av bilder uten dimensjoner, annonser som lastes sent, eller dynamisk injisert innhold. Du kan bruke følgende kode for å overvåke layout-endringer:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.warn(`Layout Shift: ${entry.name}, Value: ${entry.value}`);
console.warn(`Layout Shift Had Recent Input: ${entry.hadRecentInput}`);
console.warn(`Layout Shift Sources: ${JSON.stringify(entry.sources)}`);
});
});
observer.observe({ entryTypes: ["layout-shift"] });
Denne koden oppretter en PerformanceObserver som lytter etter layout-shift
-oppføringer og logger endringsverdien (en poengsum som representerer størrelsen på endringen) til konsollen. En høyere verdi indikerer en mer betydelig endring. Egenskapen hadRecentInput
indikerer om endringen skjedde innen 500ms etter en brukerhandling. Endringer utløst av brukerhandlinger anses generelt som mindre problematiske. Egenskapen sources
gir detaljer om elementene som forårsaket endringen. Ved å analysere disse dataene kan du identifisere og fikse problemer med layout-endringer ved å spesifisere dimensjoner for bilder, reservere plass for annonser og unngå dynamisk injisering av innhold som kan forårsake reflows.
Handlingsrettet innsikt: Bruk verktøy som Googles Lighthouse for å identifisere problemer med layout-endringer og få anbefalinger for å fikse dem. Prioriter å fikse endringer som skjer uten brukerhandling.
6. Måling av Largest Contentful Paint (LCP)
Oppføringstypen largest-contentful-paint
måler tiden det tar før det største innholdselementet blir synlig på siden. LCP er en kjerne-web-vital som reflekterer den oppfattede lastehastigheten til siden. En god LCP-score er 2,5 sekunder eller mindre. Du kan bruke følgende kode for å måle LCP:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Largest Contentful Paint: ${entry.startTime}ms`);
console.log(`LCP Element: ${entry.element}`);
console.log(`LCP URL: ${entry.url}`);
});
});
observer.observe({ entryTypes: ["largest-contentful-paint"] });
Denne koden oppretter en PerformanceObserver som lytter etter largest-contentful-paint
-oppføringer og logger starttid, element og URL til konsollen. Ved å analysere disse dataene kan du identifisere det største innholdselementet og optimalisere lastetiden ved å optimalisere bildestørrelsen, bruke et CDN, eller forhåndslaste ressursen.
Globalt perspektiv: Husk at forskjellige brukere vil ha forskjellige LCP-elementer basert på skjermstørrelse og oppløsning. Design applikasjonen din for å sikre en god LCP-score på tvers av en rekke enheter og skjermstørrelser.
7. Måling av First Input Delay (FID)
Oppføringstypen first-input-delay
måler tiden det tar for nettleseren å respondere på den første brukerinteraksjonen (f.eks. et klikk eller trykk). FID er en annen kjerne-web-vital som reflekterer interaktiviteten til siden. En god FID-score er 100 millisekunder eller mindre. Du kan bruke følgende kode for å måle FID:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`First Input Delay: ${entry.processingStart - entry.startTime}ms`);
console.log(`Event Type: ${entry.name}`);
console.log(`Target Element: ${entry.target}`);
});
});
observer.observe({ type: "first-input", buffered: true });
Denne koden oppretter en PerformanceObserver som lytter etter first-input
-oppføringer og logger forsinkelsen, hendelsestypen og målelementet til konsollen. Ved å analysere disse dataene kan du identifisere årsakene til lange input-forsinkelser og optimalisere JavaScript-koden din for å redusere tiden som brukes på hovedtråden.
Handlingsrettet innsikt: Del opp langvarige oppgaver i mindre biter, bruk web workers for å flytte oppgaver til en bakgrunnstråd, og optimaliser hendelseslytterne dine for å redusere behandlingstiden for brukerinteraksjoner.
Avanserte teknikker og betraktninger
I tillegg til de grunnleggende bruksområdene beskrevet ovenfor, kan Performance Observer API brukes i mer avanserte scenarioer for å få dypere innsikt i webapplikasjoners ytelse. Her er noen avanserte teknikker og betraktninger:
1. Bruk av buffering
Alternativet buffered
i observe()
-metoden lar deg hente historiske ytelsesoppføringer som ble registrert før PerformanceObserver ble opprettet. Dette er nyttig for å fange opp ytelsesdata som oppstår under den første sidelastingen eller før overvåkingskoden din er lastet. For eksempel:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Entry: ${entry.name}, Type: ${entry.entryType}, Duration: ${entry.duration}ms`);
});
});
observer.observe({ entryTypes: ["navigation", "resource"], buffered: true });
Denne koden oppretter en PerformanceObserver som lytter etter navigation
- og resource
-oppføringer og henter alle historiske oppføringer som ble registrert før observatøren ble opprettet.
2. Filtrering av ytelsesoppføringer
Du kan filtrere ytelsesoppføringer basert på spesifikke kriterier for å fokusere på de dataene som er mest relevante for din analyse. For eksempel kan du filtrere ressursoppføringer basert på deres URL eller innholdstype:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
if (entry.entryType === "resource" && entry.name.endsWith(".jpg")) {
console.log(`Image Resource: ${entry.name}, Duration: ${entry.duration}ms`);
}
});
});
observer.observe({ entryTypes: ["resource"] });
Denne koden oppretter en PerformanceObserver som lytter etter resource
-oppføringer og filtrerer dem til å bare inkludere oppføringer for bilderessurser med en .jpg
-endelse.
3. Bruk av Web Workers
For å unngå å påvirke ytelsen til hovedtråden, kan du flytte ytelsesovervåkning og analyse til en web worker. Dette lar deg samle inn og behandle ytelsesdata i bakgrunnen uten å blokkere brukergrensesnittet. For eksempel kan du opprette en web worker som lytter etter ytelseshendelser og sender dataene til hovedtråden for analyse.
Global skriveretningslinje: Bruk eksempler som er relevante for et globalt publikum. Unngå eksempler som er spesifikke for et bestemt land eller en kultur.
4. Integrering med analyseplattformer
Performance Observer API kan integreres med analyseplattformer for å samle inn og analysere ytelsesdata på ett sentralisert sted. Dette lar deg spore ytelsestrender over tid, identifisere ytelsesregresjoner og korrelere ytelsesmålinger med andre brukeratferdsdata. Du kan sende ytelsesoppføringer til analyseplattformen din ved hjelp av dens API eller ved å logge dem til et endepunkt på serversiden.
5. Bruk av polyfills for eldre nettlesere
Selv om Performance Observer API støttes av de fleste moderne nettlesere, er det kanskje ikke tilgjengelig i eldre nettlesere. For å støtte eldre nettlesere kan du bruke en polyfill som gir en fallback-implementering av API-et. Det finnes flere polyfills tilgjengelig på nettet som du kan bruke i applikasjonen din.
Beste praksis for bruk av Performance Observer API
For å kunne utnytte Performance Observer API effektivt og unngå vanlige fallgruver, følg disse beste praksisene:
- Overvåk bare de målingene som er relevante for dine mål. Unngå å samle inn overdreven data som kan påvirke ytelsen.
- Bruk filtrering for å fokusere på de viktigste dataene. Filtrer ytelsesoppføringer basert på spesifikke kriterier for å redusere mengden data du må behandle.
- Flytt ytelsesovervåkning til en web worker. Dette vil forhindre at ytelsesovervåkningen påvirker ytelsen til hovedtråden.
- Integrer med analyseplattformer for å spore ytelsestrender over tid. Dette vil tillate deg å identifisere ytelsesregresjoner og korrelere ytelsesmålinger med andre brukeratferdsdata.
- Bruk polyfills for å støtte eldre nettlesere. Dette vil sikre at ytelsesovervåkningskoden din fungerer på tvers av et bredt spekter av nettlesere.
- Test ytelsesovervåkningskoden din grundig. Pass på at koden din ikke introduserer egne ytelsesproblemer.
- Vær oppmerksom på personvernregler. Sørg for at du ikke samler inn personlig identifiserbar informasjon (PII) uten brukerens samtykke.
SEO-optimalisering: Lag en engasjerende metabeskrivelse. En konsis beskrivelse som oppsummerer blogginnleggets innhold er gitt i JSON-metadataene.
Konklusjon
Performance Observer API er et kraftig verktøy som gjør det mulig for utviklere å overvåke og analysere sanntidsytelsesmålinger, identifisere flaskehalser og optimalisere webapplikasjonene sine for en smidigere, raskere og mer behagelig brukeropplevelse. Ved å forstå API-ets nøkkelkonsepter og funksjoner, og ved å følge beste praksis for bruken, kan du få verdifull innsikt i ytelsen til applikasjonene dine og levere en bedre brukeropplevelse til brukerne dine, uavhengig av deres plassering eller enhet. Etter hvert som webapplikasjoner blir stadig mer komplekse, vil Performance Observer API fortsette å være et essensielt verktøy for å sikre optimal ytelse og brukertilfredshet.
Husk å prioritere brukeropplevelsen over alt annet. Ytelsesoptimalisering bør alltid være drevet av målet om å gi en sømløs og behagelig opplevelse for brukerne dine. Ved å bruke Performance Observer API effektivt, kan du få en dypere forståelse av applikasjonens ytelse og ta informerte beslutninger for å forbedre brukeropplevelsen.
Ved å nøye vurdere de globale implikasjonene av ytelse, kan utviklere lage webapplikasjoner som er raske, responsive og tilgjengelige for brukere over hele verden. Dette krever en helhetlig tilnærming som tar hensyn til faktorer som nettverksforsinkelse, enhetskapasitet og kulturelle preferanser.