Frontend Performance Observer Custom Metrics: Applikationsspecifik Måling

I webudviklingens verden er det altafgørende at sikre optimal frontend-ydeevne. Selvom browsere tilbyder en række ydeevnemålinger, kommer de ofte til kort, når det gælder om at fange applikationsspecifik adfærd. Det er her, Frontend Performance Observer API og muligheden for at definere brugerdefinerede målinger bliver uvurderlige. Denne artikel vil guide dig gennem processen med at udnytte Performance Observer til at spore skræddersyede målinger, hvilket giver et skræddersyet overblik over din applikations ydeevnelandskab.

Forståelsen af behovet for brugerdefinerede målinger

Standard ydeevnemålinger i browsere, såsom First Contentful Paint (FCP), Largest Contentful Paint (LCP) og Time to Interactive (TTI), giver et generelt overblik over sideindlæsning og responsivitet. Disse målinger afspejler dog ofte ikke nøjagtigt brugeroplevelsen i din specifikke applikation. Overvej disse scenarier:

• E-handelsapplikation: Tiden det tager at tilføje en vare til indkøbskurven eller gennemføre en betalingsproces.
• Social medieplatform: Latensen ved indlæsning af brugerfeeds eller opslag af opdateringer.
• Finansielt dashboard: Tiden det kræver at beregne og vise komplekse finansielle data.
• Kortapplikation: Forsinkelsen ved indlæsning af kortfliser eller gengivelse af geografiske data.

Disse applikationsspecifikke handlinger er kritiske for brugeroplevelsen, men fanges ikke direkte af standard ydeevnemålinger. Brugerdefinerede målinger bygger bro over dette hul, så du kan overvåge ydeevnen af kritiske funktioner og få en dybere forståelse af brugeradfærd.

Introduktion til Performance Observer API

Performance Observer API giver en mekanisme til at observere og indsamle ydeevnemålinger, efterhånden som de opstår i browseren. Det giver dig mulighed for at abonnere på specifikke typer af ydeevneposter, såsom `paint`, `resource`, `navigation`, og vigtigst af alt, `measure` og `mark`. Denne hændelsesdrevne tilgang gør det muligt for dig at reagere på ydeevnehændelser i realtid og indsamle data til analyse.

Kernekomponenterne i Performance Observer API er:

• `PerformanceObserver` constructor: Opretter en ny PerformanceObserver-instans.
• `observe()`-metoden: Specificerer, hvilke typer af ydeevneposter der skal observeres.
• `disconnect()`-metoden: Stopper observatøren i at lytte efter ydeevneposter.
• `takeRecords()`-metoden: Returnerer alle ydeevneposter, der er blevet bufferet siden det sidste kald.

Definering af brugerdefinerede målinger ved hjælp af `mark` og `measure`

`mark`- og `measure`-API'erne er fundamentale for at skabe brugerdefinerede ydeevnemålinger. Sådan fungerer de:

• `performance.mark(markName)`: Opretter en tidsstemplet markør i browserens ydeevnetidslinje. Du bruger `mark` til at angive starten og slutningen af en specifik hændelse, du vil måle.
• `performance.measure(measureName, startMark, endMark)`: Beregner varigheden mellem to markører og opretter en ydeevnepost af typen `measure`. `measureName` er en unik identifikator for din brugerdefinerede måling.

Lad os illustrere dette med et eksempel. Antag, at du vil måle den tid, det tager for en specifik komponent at blive gengivet efter en brugerinteraktion.

            
// Start måling af gengivelsesprocessen
performance.mark('componentRenderStart');

// ... (Logik for komponentgengivelse her) ...

// Afslut måling af gengivelsesprocessen
performance.mark('componentRenderEnd');

// Opret en måling for at beregne varigheden
performance.measure('componentRenderTime', 'componentRenderStart', 'componentRenderEnd');

            

              
                Copy
              
            
          

Implementering af en Performance Observer for brugerdefinerede målinger

Lad os nu oprette en Performance Observer for at lytte efter `measure`-poster og behandle de brugerdefinerede målingsdata.

            
const observer = new PerformanceObserver((list) => {
  list.getEntriesByType('measure').forEach((entry) => {
    console.log(`Brugerdefineret måling: ${entry.name} - Varighed: ${entry.duration}ms`);
    // I et virkeligt scenarie ville du sende disse data til din analyseplatform
    // Eksempel:
    // trackCustomMetric(entry.name, entry.duration);
  });
});

observer.observe({ entryTypes: ['measure'] });

            

              
                Copy
              
            
          

Dette kodestykke opretter en Performance Observer, der lytter efter `measure`-poster. Når en `measure`-post oprettes (via `performance.measure`), udføres observatørens callback-funktion. Callback-funktionen itererer gennem de indsamlede poster, logger målingens navn og varighed til konsollen og sender ideelt set dataene til en analyseplatform for yderligere analyse.

Praktiske eksempler: Brugerdefinerede målinger i aktion

Lad os udforske flere praktiske eksempler på, hvordan du kan bruge brugerdefinerede målinger til at overvåge specifikke aspekter af din applikations ydeevne.

1. Måling af API-svartid

At spore den tid, det tager at modtage svar fra dine backend-API'er, er afgørende for at identificere potentielle flaskehalse. Sådan kan du måle API-svartid:

            
async function fetchData() {
  performance.mark('apiCallStart');
  const response = await fetch('/api/data');
  performance.mark('apiCallEnd');
  performance.measure('apiResponseTime', 'apiCallStart', 'apiCallEnd');
  return response.json();
}

            

              
                Copy
              
            
          

Dette kodestykke måler den tid, det tager at hente data fra `/api/data`-endepunktet. Målingen `apiResponseTime` fanger hele varigheden af API-kaldet, fra starten af anmodningen til modtagelsen af svaret.

2. Sporing af billedindlæsningstid

Billeder er ofte en betydelig faktor i sideindlæsningsydelsen. Måling af den tid, det tager for billeder at indlæse, kan hjælpe dig med at identificere for store billeder eller langsomme CDN'er.

            
const image = new Image();
image.onload = () => {
  performance.mark('imageLoadEnd');
  performance.measure('imageLoadTime', 'imageLoadStart', 'imageLoadEnd');
};
performance.mark('imageLoadStart');
image.src = 'https://example.com/image.jpg';

            

              
                Copy
              
            
          

Dette kodestykke måler den tid, det tager for et billede at indlæse fra den angivne URL. Målingen `imageLoadTime` fanger varigheden fra starten af billedanmodningen til afslutningen af billedindlæsningen.

3. Overvågning af eksekveringstid for tredjepartsscripts

Tredjepartsscripts kan ofte have en betydelig indvirkning på frontend-ydeevnen. Måling af deres eksekveringstid kan hjælpe dig med at identificere problematiske scripts og optimere deres indlæsning eller eksekvering.

            
// Antager, at tredjepartsscriptet har en global funktion kaldet 'thirdPartyScript'

performance.mark('thirdPartyScriptStart');
thirdPartyScript();
performance.mark('thirdPartyScriptEnd');
performance.measure('thirdPartyScriptExecutionTime', 'thirdPartyScriptStart', 'thirdPartyScriptEnd');

            

              
                Copy
              
            
          

Dette kodestykke måler eksekveringstiden for et hypotetisk tredjepartsscript. Målingen `thirdPartyScriptExecutionTime` fanger varigheden af scriptets eksekvering.

4. Måling af Time to Interactive (TTI) for specifikke komponenter

Selvom TTI er en standardmåling, kan du tilpasse den til at måle den tid, det tager for specifikke komponenter at blive interaktive. Dette giver dig mulighed for at finde ud af, hvilke komponenter der bidrager mest til den samlede TTI.

            
// Efter din komponent er fuldt gengivet og interaktiv
performance.mark('componentInteractive');
performance.measure('componentTTI', 'componentRenderStart', 'componentInteractive');

            

              
                Copy
              
            
          

Dette eksempel antager, at `componentRenderStart` blev defineret tidligere. Det måler tiden fra komponenten begyndte at blive gengivet, til den er fuldt interaktiv.

Avancerede teknikker og overvejelser

Ud over det grundlæggende er her nogle avancerede teknikker og overvejelser for effektiv brug af Performance Observer og brugerdefinerede målinger:

1. Brug af User Timing API til komplekse scenarier

For mere komplekse scenarier kan det være nødvendigt at oprette flere markeringer og målinger for at spore forskellige faser af en hændelse. User Timing API giver en fleksibel måde at håndtere disse markører og beregninger på.

2. Udnyttelse af Long Tasks API

Long Tasks API kan hjælpe med at identificere opgaver, der blokerer hovedtråden i længere perioder, hvilket fører til en dårlig brugeroplevelse. Du kan kombinere dette med brugerdefinerede målinger for at korrelere lange opgaver med specifikke applikationshandlinger.

3. `buffered`-flag og sent indlæste observatører

Hvis du initialiserer din Performance Observer, efter at nogle ydeevnehændelser allerede er opstået, kan du bruge `buffered`-flaget til at hente disse hændelser. For eksempel:

            
const observer = new PerformanceObserver((list) => { /* ... */ });
observer.observe({ entryTypes: ['measure'], buffered: true });

            

              
                Copy
              
            
          

4. Throttling og Debouncing

I scenarier med høj frekvens bør du overveje at anvende throttling eller debouncing på din målingsindsamling for at undgå performance-overhead. Hvis du for eksempel sporer musebevægelser, indsamler du måske kun data hvert 100. ms.

5. Dataaggregering og analyse

De rå ydeevnedata, der indsamles af Performance Observer, skal aggregeres og analyseres for at give meningsfuld indsigt. Dette involverer typisk at sende dataene til en analyseplatform, såsom Google Analytics, New Relic eller en specialbygget løsning. Sørg for, at din analyseplatform kan håndtere brugerdefinerede målinger og levere de nødvendige rapporteringsmuligheder.

6. Real User Monitoring (RUM)

For at få et sandt billede af din applikations ydeevne skal du implementere Real User Monitoring (RUM). RUM indsamler ydeevnedata fra rigtige brugere under virkelige forhold, hvilket giver værdifuld indsigt i, hvordan din applikation performer for forskellige brugere og enheder. Brugerdefinerede målinger er en væsentlig del af en omfattende RUM-strategi.

7. Sikkerhedsovervejelser

Vær opmærksom på sikkerheden, når du indsamler og transmitterer ydeevnedata. Undgå at indsamle følsomme brugeroplysninger og sørg for, at data overføres sikkert (f.eks. ved hjælp af HTTPS).

Eksempel: Måling af Time to First Byte (TTFB) ved hjælp af Resource Timing API

TTFB er den tid, det tager for browseren at modtage den første byte data fra serveren. Selvom det ikke strengt taget er en brugerdefineret måling defineret med `mark` og `measure`, er det en værdifuld ydeevneindikator og kan tilgås via Resource Timing API og observeres med en Performance Observer.

            
const ttfbObserver = new PerformanceObserver((list) => {
  list.getEntriesByType('resource').forEach((entry) => {
    if (entry.name === window.location.href) { // Tjek om det er hoveddokumentet
      const ttfb = entry.responseStart - entry.startTime;
      console.log(`TTFB: ${ttfb}ms`);
      // Send ttfb til din analyseplatform
    }
  });
});

ttfbObserver.observe({ type: 'resource', buffered: true });

            

              
                Copy
              
            
          

Cross-Browser-kompatibilitet

Performance Observer API er bredt understøttet på tværs af moderne browsere. Det er dog altid en god praksis at tjekke for browserkompatibilitet og tilbyde fallback-mekanismer for ældre browsere. Du kan bruge en polyfill eller en enklere måleteknik for browsere, der ikke understøtter Performance Observer API.

            
if ('PerformanceObserver' in window) {
  // Brug Performance Observer API
  const observer = new PerformanceObserver((list) => { /* ... */ });
  observer.observe({ entryTypes: ['measure'] });
} else {
  // Brug en fallback-mekanisme (f.eks. Date.now() for simple tidsmålinger)
  console.warn('PerformanceObserver API understøttes ikke i denne browser.');
}

            

              
                Copy
              
            
          

Bedste praksis for brug af brugerdefinerede målinger

• Definér klare mål: Hvilke specifikke ydeevneaspekter vil du overvåge?
• Vælg meningsfulde målingsnavne: Brug beskrivende og konsistente navne til dine brugerdefinerede målinger.
• Dokumentér dine målinger: Dokumentér klart formålet med og beregningen af hver brugerdefineret måling.
• Sæt ydeevnebudgetter: Definer acceptable ydeevnetærskler for dine brugerdefinerede målinger.
• Automatiser dataindsamling og analyse: Integrer indsamling af brugerdefinerede målinger i din byggeproces og analyse-pipeline.
• Gennemgå og finpuds regelmæssigt dine målinger: Efterhånden som din applikation udvikler sig, kan dine behov for ydeevneovervågning ændre sig.

Konklusion

Frontend-ydeevne er en kontinuerlig rejse, ikke en destination. Ved at udnytte Frontend Performance Observer API og definere brugerdefinerede målinger kan du få en dybere forståelse af din applikations ydeevne og identificere områder for forbedring. Denne skræddersyede tilgang til ydeevneovervågning giver dig mulighed for at optimere brugeroplevelsen og levere en hurtigere, mere responsiv webapplikation. Husk at konsekvent overvåge, analysere og finpudse dine målinger for at være på forkant og sikre, at din applikation performer optimalt for alle brugere, uanset deres placering eller enhed.

Denne artikel gav et omfattende overblik over brugerdefinerede målinger ved hjælp af Performance Observer API. Det er afgørende at tilpasse disse teknikker til dine specifikke applikationsbehov og løbende overvåge og analysere dataene for at træffe informerede beslutninger om ydeevneoptimering.

Yderligere læsning:

• PerformanceObserver API - MDN Web Docs
• performance.mark() - MDN Web Docs
• performance.measure() - MDN Web Docs