En omfattende guide til brug af Performance Observer API til overvågning af runtime-performance, identifikation af flaskehalse og optimering af webapplikationer. Lær hvordan du indsamler og analyserer målinger for en bedre brugeroplevelse.
Performance Observer API: Måling af runtime-performance og analyse af flaskehalse
I dagens konkurrenceprægede digitale landskab er ydeevnen af websites og webapplikationer afgørende for brugerengagement og forretningssucces. Langsomme indlæsningstider og sløve brugerflader kan føre til frustrerede brugere, afbrudte transaktioner og i sidste ende tabt omsætning. Performance Observer API er et stærkt værktøj, der giver udviklere mulighed for at overvåge og analysere runtime-performancemålinger, identificere flaskehalse og optimere deres applikationer for en mere jævn, hurtigere og mere behagelig brugeroplevelse, uanset brugerens placering eller enhed.
Hvad er Performance Observer API?
Performance Observer API er et JavaScript API, der giver en mekanisme til at observere og reagere på performancerelaterede hændelser, mens de sker i en webapplikation. I modsætning til traditionelle teknikker til performanceovervågning, der er baseret på periodisk sampling eller manuel instrumentering, tilbyder Performance Observer API en mere effektiv og fleksibel måde at indsamle performancedata i realtid. Det giver udviklere mulighed for at abonnere på specifikke performance entry-typer og modtage notifikationer, når nye poster registreres.
Denne "observer-og-reager"-tilgang muliggør proaktiv performanceovervågning, hvilket giver udviklere mulighed for at identificere og løse performanceproblemer, før de påvirker brugeroplevelsen. API'et er standardiseret på tværs af moderne browsere, hvilket sikrer konsistent adfærd og kompatibilitet på tværs af platforme.
Nøglebegreber og funktioner
For effektivt at kunne bruge Performance Observer API er det vigtigt at forstå dets kernebegreber og funktioner:
- PerformanceEntry: Repræsenterer en enkelt performancemåling eller hændelse. Performance entries indeholder information om hændelsestypen, dens start- og sluttider og andre relevante attributter. Eksempler inkluderer
resource
,mark
,measure
,navigation
,longtask
ogevent
. - PerformanceObserver: Et objekt, der giver dig mulighed for at abonnere på specifikke performance entry-typer og modtage notifikationer, når nye poster tilføjes til browserens performance-tidslinje.
- observe() metoden: Bruges til at konfigurere PerformanceObserver til at lytte efter specifikke performance entry-typer. Du kan specificere de entry-typer, du vil observere, samt en
buffered
-option for at modtage historiske poster. - disconnect() metoden: Bruges til at stoppe PerformanceObserver i at lytte efter performancehændelser.
- takeRecords() metoden: Returnerer et array af alle performance entries, der er blevet observeret, men endnu ikke behandlet af observatørens callback-funktion.
- Callback-funktion: En funktion, der udføres, når nye performance entries observeres. Denne funktion modtager et
PerformanceObserverEntryList
-objekt, der indeholder de observerede poster.
Understøttede Performance Entry-typer
Performance Observer API understøtter en række forskellige performance entry-typer, som hver især giver specifik indsigt i forskellige aspekter af en webapplikations ydeevne. Nogle af de mest almindeligt anvendte entry-typer inkluderer:
resource
: Giver information om indlæsningen af individuelle ressourcer, såsom billeder, scripts, stylesheets og skrifttyper. Denne entry-type indeholder detaljer som ressourcens URL, start- og sluttider, hentningens varighed og overførselsstørrelse.mark
: Giver dig mulighed for at oprette brugerdefinerede tidsstempler i din kode for at måle varigheden af specifikke kodeafsnit. Du kan bruge marks til at spore starten og slutningen af kritiske operationer, såsom databehandling eller UI-rendering.measure
: Bruges til at beregne varigheden mellem to marks. Denne entry-type giver en praktisk måde at måle ydeevnen af brugerdefinerede kodeafsnit.navigation
: Giver information om en sides navigation timing, herunder DNS-opslagstid, TCP-forbindelsestid, request- og response-tider samt DOM-behandlingstid.longtask
: Identificerer opgaver, der blokerer hovedtråden i en længere periode (typisk længere end 50 millisekunder). Lange opgaver kan forårsage, at brugerfladen ikke reagerer og opleves som hakkende (jank).event
: Registrerer timing-information for specifikke browserhændelser, såsomclick
,keydown
ogscroll
.layout-shift
: Sporer uventede layoutskift på siden. Disse skift kan være forstyrrende for brugerne og påvirke brugeroplevelsen negativt.largest-contentful-paint
: Måler den tid, det tager for det største indholdselement at blive synligt på siden.first-input-delay
: Måler den tid, det tager for browseren at reagere på den første brugerinteraktion (f.eks. et klik eller tryk).element
: Rapporterer timing-information for renderingen af specifikke elementer på siden.
Praktiske eksempler og use cases
Performance Observer API kan bruges i en lang række scenarier til at forbedre webapplikationers ydeevne. Her er et par praktiske eksempler:
1. Overvågning af ressourceindlæsningstider
resource
entry-typen giver dig mulighed for at spore indlæsningstiderne for individuelle ressourcer, såsom billeder, scripts og stylesheets. Denne information kan bruges til at identificere langsomt indlæsende ressourcer, der påvirker sidens indlæsningstid. For eksempel kan du bruge følgende kode til at overvåge ressourceindlæsningstider:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Ressource: ${entry.name}, Varighed: ${entry.duration}ms`);
});
});
observer.observe({ entryTypes: ["resource"] });
Denne kode opretter en PerformanceObserver, der lytter efter resource
-poster og logger ressourcens URL og varighed til konsollen. Ved at analysere disse data kan du identificere langsomt indlæsende ressourcer og optimere dem ved at komprimere billeder, bruge et Content Delivery Network (CDN) eller optimere din serverkonfiguration.
Globalt perspektiv: Når du overvåger ressourceindlæsningstider, skal du tage hensyn til dine brugeres geografiske placering. Brugere i regioner med langsommere internetforbindelser kan opleve betydeligt længere indlæsningstider. Brug af et CDN med geografisk distribuerede servere kan hjælpe med at afbøde dette problem.
2. Måling af eksekveringstid for brugerdefineret kode
mark
- og measure
-entry-typerne giver dig mulighed for at måle eksekveringstiden for brugerdefinerede kodeafsnit. Dette er nyttigt til at identificere performance-flaskehalse i din applikationslogik. For eksempel kan du bruge følgende kode til at måle varigheden af en specifik funktion:
performance.mark("start");
// Kode, der skal måles
for (let i = 0; i < 1000000; i++) {
// En beregningsmæssigt intensiv operation
}
performance.mark("end");
performance.measure("Min Funktion", "start", "end");
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Måling: ${entry.name}, Varighed: ${entry.duration}ms`);
});
});
observer.observe({ entryTypes: ["measure"] });
Denne kode opretter to marks, start
og end
, før og efter det kodeafsnit, du vil måle. Derefter bruger den performance.measure()
-metoden til at beregne varigheden mellem de to marks. PerformanceObserver lytter efter measure
-poster og logger målingens navn og varighed til konsollen. Ved at analysere disse data kan du identificere kodeafsnit med lav ydeevne og optimere dem ved hjælp af teknikker som caching, memoization eller algoritmisk optimering.
Handlingsorienteret indsigt: Identificer din applikations kritiske stier – de sekvenser af kode, der oftest udføres og har størst indflydelse på ydeevnen. Fokuser dine optimeringsbestræbelser på disse kritiske stier for at opnå de mest betydelige performanceforbedringer.
3. Identifikation af lange opgaver
longtask
-entry-typen identificerer opgaver, der blokerer hovedtråden i en længere periode. Lange opgaver kan forårsage, at brugerfladen ikke reagerer og opleves som hakkende, hvilket fører til en dårlig brugeroplevelse. Du kan bruge følgende kode til at overvåge lange opgaver:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.warn(`Lang opgave: ${entry.name}, Varighed: ${entry.duration}ms`);
console.warn(`Lang opgave-attribution: ${JSON.stringify(entry.attribution)}`);
});
});
observer.observe({ entryTypes: ["longtask"] });
Denne kode opretter en PerformanceObserver, der lytter efter longtask
-poster og logger opgavens navn og varighed til konsollen. Ved at analysere disse data kan du identificere langvarige opgaver og optimere dem ved at opdele dem i mindre bidder, bruge asynkrone operationer eller flytte dem til en web worker.
Global retningslinje for skrivning: Når du forklarer tekniske koncepter, skal du bruge et klart og præcist sprog, der er tilgængeligt for læsere med forskellige niveauer af teknisk ekspertise. Undgå jargon og giv kontekst for ukendte termer.
4. Analyse af navigation timing
navigation
-entry-typen giver detaljeret information om en sides navigation timing, herunder DNS-opslagstid, TCP-forbindelsestid, request- og response-tider samt DOM-behandlingstid. Disse data kan bruges til at identificere flaskehalse i sidens indlæsningsproces. For eksempel kan du bruge følgende kode til at analysere navigation timing:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Navigation: ${entry.name}`);
console.log(`DNS-opslagstid: ${entry.domainLookupEnd - entry.domainLookupStart}ms`);
console.log(`TCP-forbindelsestid: ${entry.connectEnd - entry.connectStart}ms`);
console.log(`Request-tid: ${entry.responseStart - entry.requestStart}ms`);
console.log(`Response-tid: ${entry.responseEnd - entry.responseStart}ms`);
console.log(`DOM-behandlingstid: ${entry.domComplete - entry.domInteractive}ms`);
});
});
observer.observe({ entryTypes: ["navigation"] });
Denne kode opretter en PerformanceObserver, der lytter efter navigation
-poster og logger forskellige timing-målinger til konsollen. Ved at analysere disse data kan du identificere flaskehalse som langsomt DNS-opslag, langsom TCP-forbindelse, langsom request-behandling, langsom response-behandling eller langsom DOM-behandling. Du kan derefter træffe passende foranstaltninger for at løse disse flaskehalse, såsom at optimere din DNS-konfiguration, forbedre din server-performance eller optimere din HTML- og JavaScript-kode.
SEO-optimering: Brug relevante søgeord naturligt i hele indholdet. I dette afsnit er søgeord som "navigation timing", "DNS-opslagstid", "TCP-forbindelsestid" og "sidens indlæsningsproces" integreret problemfrit.
5. Overvågning af layoutskift
layout-shift
-entry-typen sporer uventede layoutskift på siden. Disse skift kan være forstyrrende for brugerne og påvirke brugeroplevelsen negativt. De opstår ofte på grund af billeder uden dimensioner, annoncer der indlæses sent, eller dynamisk indsat indhold. Du kan bruge følgende kode til at overvåge layoutskift:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.warn(`Layoutskift: ${entry.name}, Værdi: ${entry.value}`);
console.warn(`Layoutskift havde nyligt input: ${entry.hadRecentInput}`);
console.warn(`Layoutskift-kilder: ${JSON.stringify(entry.sources)}`);
});
});
observer.observe({ entryTypes: ["layout-shift"] });
Denne kode opretter en PerformanceObserver, der lytter efter layout-shift
-poster og logger skiftets værdi (en score, der repræsenterer skiftets omfang) til konsollen. En højere værdi indikerer et mere markant skift. Egenskaben hadRecentInput
angiver, om skiftet fandt sted inden for 500 ms efter en brugerinput. Skift udløst af brugerinput betragtes generelt som mindre problematiske. Egenskaben sources
giver detaljer om de elementer, der forårsagede skiftet. Ved at analysere disse data kan du identificere og rette problemer med layoutskift ved at specificere dimensioner for billeder, reservere plads til annoncer og undgå dynamisk at indsætte indhold, der kan forårsage reflows.
Handlingsorienteret indsigt: Brug værktøjer som Googles Lighthouse til at identificere problemer med layoutskift og få anbefalinger til at rette dem. Prioriter at rette skift, der sker uden brugerinput.
6. Måling af Largest Contentful Paint (LCP)
largest-contentful-paint
-entry-typen måler den tid, det tager for det største indholdselement at blive synligt på siden. LCP er en "core web vital", der afspejler den opfattede indlæsningshastighed af siden. En god LCP-score er 2,5 sekunder eller mindre. Du kan bruge følgende kode til at 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 kode opretter en PerformanceObserver, der lytter efter largest-contentful-paint
-poster og logger starttidspunktet, elementet og URL'en til konsollen. Ved at analysere disse data kan du identificere det største indholdselement og optimere dets indlæsningstid ved at optimere billedstørrelsen, bruge et CDN eller forudindlæse ressourcen.
Globalt perspektiv: Husk, at forskellige brugere vil have forskellige LCP-elementer baseret på deres skærmstørrelse og opløsning. Design din applikation, så den sikrer en god LCP-score på tværs af en række forskellige enheder og skærmstørrelser.
7. Måling af First Input Delay (FID)
first-input-delay
-entry-typen måler den tid, det tager for browseren at reagere på den første brugerinteraktion (f.eks. et klik eller tryk). FID er en anden "core web vital", der afspejler sidens interaktivitet. En god FID-score er 100 millisekunder eller mindre. Du kan bruge følgende kode til at måle FID:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`First Input Delay: ${entry.processingStart - entry.startTime}ms`);
console.log(`Hændelsestype: ${entry.name}`);
console.log(`Målelement: ${entry.target}`);
});
});
observer.observe({ type: "first-input", buffered: true });
Denne kode opretter en PerformanceObserver, der lytter efter first-input
-poster og logger forsinkelsen, hændelsestypen og målelementet til konsollen. Ved at analysere disse data kan du identificere årsagerne til lange inputforsinkelser og optimere din JavaScript-kode for at reducere den tid, der bruges på hovedtråden.
Handlingsorienteret indsigt: Opdel langvarige opgaver i mindre bidder, brug web workers til at flytte opgaver til en baggrundstråd, og optimer dine event listeners for at reducere behandlingstiden for brugerinteraktioner.
Avancerede teknikker og overvejelser
Ud over de grundlæggende use cases beskrevet ovenfor kan Performance Observer API bruges i mere avancerede scenarier for at få dybere indsigt i en webapplikations ydeevne. Her er et par avancerede teknikker og overvejelser:
1. Brug af buffering
buffered
-optionen i observe()
-metoden giver dig mulighed for at hente historiske performance-poster, der blev registreret, før PerformanceObserver blev oprettet. Dette er nyttigt til at indsamle performancedata, der opstår under den indledende sideindlæsning, eller før din overvågningskode er indlæst. For eksempel:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(`Post: ${entry.name}, Type: ${entry.entryType}, Varighed: ${entry.duration}ms`);
});
});
observer.observe({ entryTypes: ["navigation", "resource"], buffered: true });
Denne kode opretter en PerformanceObserver, der lytter efter navigation
- og resource
-poster og henter alle historiske poster, der blev registreret, før observatøren blev oprettet.
2. Filtrering af performance-poster
Du kan filtrere performance-poster baseret på specifikke kriterier for at fokusere på de data, der er mest relevante for din analyse. For eksempel kan du filtrere ressource-poster baseret på deres URL eller indholdstype:
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
if (entry.entryType === "resource" && entry.name.endsWith(".jpg")) {
console.log(`Billedressource: ${entry.name}, Varighed: ${entry.duration}ms`);
}
});
});
observer.observe({ entryTypes: ["resource"] });
Denne kode opretter en PerformanceObserver, der lytter efter resource
-poster og filtrerer dem, så den kun inkluderer poster for billedressourcer med filtypenavnet .jpg
.
3. Brug af Web Workers
For at undgå at påvirke ydeevnen på hovedtråden kan du flytte performanceovervågning og -analyse til en web worker. Dette giver dig mulighed for at indsamle og behandle performancedata i baggrunden uden at blokere UI'en. For eksempel kan du oprette en web worker, der lytter efter performancehændelser og sender dataene til hovedtråden til analyse.
Global retningslinje for skrivning: Brug eksempler, der er relevante for et globalt publikum. Undgå eksempler, der er specifikke for et bestemt land eller en bestemt kultur.
4. Integration med analyseplatforme
Performance Observer API kan integreres med analyseplatforme for at indsamle og analysere performancedata på en centraliseret placering. Dette giver dig mulighed for at spore performancetrends over tid, identificere performanceregresssioner og korrelere performancemålinger med andre brugeradfærdsdata. Du kan sende performance-poster til din analyseplatform ved hjælp af dens API eller ved at logge dem til et server-side-endepunkt.
5. Brug af polyfills til ældre browsere
Selvom Performance Observer API understøttes af de fleste moderne browsere, er det muligvis ikke tilgængeligt i ældre browsere. For at understøtte ældre browsere kan du bruge en polyfill, der giver en fallback-implementering af API'et. Der findes flere polyfills online, som du kan bruge i din applikation.
Bedste praksis for brug af Performance Observer API
For effektivt at kunne bruge Performance Observer API og undgå almindelige faldgruber, skal du følge disse bedste praksisser:
- Overvåg kun de målinger, der er relevante for dine mål. Undgå at indsamle for store mængder data, der kan påvirke ydeevnen.
- Brug filtrering til at fokusere på de vigtigste data. Filtrer performance-poster baseret på specifikke kriterier for at reducere mængden af data, du skal behandle.
- Flyt performanceovervågning til en web worker. Dette forhindrer overvågningen i at påvirke ydeevnen på hovedtråden.
- Integrer med analyseplatforme for at spore performancetrends over tid. Dette giver dig mulighed for at identificere performanceregresssioner og korrelere performancemålinger med andre brugeradfærdsdata.
- Brug polyfills til at understøtte ældre browsere. Dette sikrer, at din performanceovervågningskode fungerer på tværs af en bred vifte af browsere.
- Test din performanceovervågningskode grundigt. Sørg for, at din kode ikke selv introducerer performanceproblemer.
- Vær opmærksom på databeskyttelsesregler. Sørg for, at du ikke indsamler personligt identificerbare oplysninger (PII) uden brugerens samtykke.
SEO-optimering: Opret en engagerende metabeskrivelse. En kortfattet beskrivelse, der opsummerer blogindlæggets indhold, er angivet i JSON-metadataene.
Konklusion
Performance Observer API er et stærkt værktøj, der gør det muligt for udviklere at overvåge og analysere runtime-performancemålinger, identificere flaskehalse og optimere deres webapplikationer for en mere jævn, hurtigere og mere behagelig brugeroplevelse. Ved at forstå API'ets nøglebegreber og funktioner og ved at følge bedste praksis for brugen af det, kan du få værdifuld indsigt i dine applikationers ydeevne og levere en bedre brugeroplevelse til dine brugere, uanset deres placering eller enhed. I takt med at webapplikationer bliver stadig mere komplekse, vil Performance Observer API fortsat være et essentielt værktøj til at sikre optimal ydeevne og brugertilfredshed.
Husk at prioritere brugeroplevelsen over alt andet. Performanceoptimering bør altid være drevet af målet om at give dine brugere en problemfri og behagelig oplevelse. Ved at bruge Performance Observer API effektivt kan du få en dybere forståelse af din applikations ydeevne og træffe informerede beslutninger for at forbedre brugeroplevelsen.
Ved omhyggeligt at overveje de globale implikationer af ydeevne kan udviklere skabe webapplikationer, der er hurtige, responsive og tilgængelige for brugere over hele verden. Dette kræver en holistisk tilgang, der tager højde for faktorer som netværkslatens, enhedskapaciteter og kulturelle præferencer.