Egendefinerte Metrikker med Frontend Performance Observer: Applikasjonsspesifikk Måling

I webutviklingens verden er det avgjørende å sikre optimal frontend-ytelse. Selv om nettlesere tilbyr en rekke ytelsesmetrikker, kommer de ofte til kort når det gjelder å fange opp applikasjonsspesifikk atferd. Det er her Frontend Performance Observer API og muligheten til å definere egendefinerte metrikker blir uvurderlig. Denne artikkelen vil guide deg gjennom prosessen med å utnytte Performance Observer til å spore skreddersydde metrikker, noe som gir et tilpasset bilde av applikasjonens ytelseslandskap.

Forstå Behovet for Egendefinerte Metrikker

Standard ytelsesmetrikker i nettlesere, som First Contentful Paint (FCP), Largest Contentful Paint (LCP) og Time to Interactive (TTI), gir en generell oversikt over sidelasting og responsivitet. Disse metrikkene reflekterer imidlertid ofte ikke brukeropplevelsen i din spesifikke applikasjon. Vurder disse scenariene:

• E-handelsapplikasjon: Tiden det tar å legge en vare i handlekurven eller fullføre en betalingsprosess.
• Sosial Medieplattform: Forsinkelsen ved lasting av brukerfeeder eller publisering av oppdateringer.
• Finansielt Dashboard: Tiden som kreves for å beregne og vise komplekse finansielle data.
• Kartapplikasjon: Forsinkelsen i lasting av kartfliser eller rendring av geografiske data.

Disse applikasjonsspesifikke handlingene er kritiske for brukeropplevelsen, men fanges ikke direkte opp av standard ytelsesmetrikker. Egendefinerte metrikker bygger bro over dette gapet, slik at du kan overvåke ytelsen til kritiske funksjoner og få en dypere forståelse av brukeratferd.

Introduksjon til Performance Observer API

Performance Observer API gir en mekanisme for å observere og samle inn ytelsesmetrikker mens de oppstår i nettleseren. Det lar deg abonnere på spesifikke ytelsesoppføringstyper, som `paint`, `resource`, `navigation`, og viktigst av alt, `measure` og `mark`. Denne hendelsesdrevne tilnærmingen gjør at du kan reagere på ytelseshendelser i sanntid og samle inn data for analyse.

Kjernekomponentene i Performance Observer API er:

• `PerformanceObserver`-konstruktør: Oppretter en ny PerformanceObserver-instans.
• `observe()`-metoden: Spesifiserer hvilke ytelsesoppføringstyper som skal observeres.
• `disconnect()`-metoden: Stopper observatøren fra å lytte etter ytelsesoppføringer.
• `takeRecords()`-metoden: Returnerer alle ytelsesoppføringer som har blitt bufret siden siste kall.

Definere Egendefinerte Metrikker med `mark` og `measure`

`mark`- og `measure`-API-ene er fundamentale for å lage egendefinerte ytelsesmetrikker. Slik fungerer de:

• `performance.mark(markName)`: Oppretter en tidsstemplet markør i nettleserens ytelsestidslinje. Du bruker `mark` for å indikere starten og slutten på en spesifikk hendelse du vil måle.
• `performance.measure(measureName, startMark, endMark)`: Beregner varigheten mellom to markører og oppretter en ytelsesoppføring av typen `measure`. `measureName` er en unik identifikator for din egendefinerte metrikk.

La oss illustrere dette med et eksempel. Anta at du vil måle tiden det tar for en spesifikk komponent å rendre etter en brukerinteraksjon.

            
// Start måling av rendringsprosessen
performance.mark('componentRenderStart');

// ... (Komponentens rendringslogikk her) ...

// Avslutt måling av rendringsprosessen
performance.mark('componentRenderEnd');

// Opprett en måling for å beregne varigheten
performance.measure('componentRenderTime', 'componentRenderStart', 'componentRenderEnd');

            

              
                Copy
              
            
          

Implementere en Performance Observer for Egendefinerte Metrikker

La oss nå opprette en Performance Observer for å lytte etter `measure`-oppføringer og behandle de egendefinerte metriske dataene.

            
const observer = new PerformanceObserver((list) => {
  list.getEntriesByType('measure').forEach((entry) => {
    console.log(`Egendefinert metrikk: ${entry.name} - Varighet: ${entry.duration}ms`);
    // I et reelt scenario ville du sendt disse dataene til din analyseplattform
    // Eksempel:
    // trackCustomMetric(entry.name, entry.duration);
  });
});

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

            

              
                Copy
              
            
          

Dette kodeutdraget oppretter en Performance Observer som lytter etter `measure`-oppføringer. Når en `measure`-oppføring opprettes (via `performance.measure`), utføres observatørens tilbakekallingsfunksjon. Tilbakekallingsfunksjonen itererer gjennom de innsamlede oppføringene, logger metrikkens navn og varighet til konsollen, og ideelt sett sender dataene til en analyseplattform for videre analyse.

Praktiske Eksempler: Egendefinerte Metrikker i Praksis

La oss utforske flere praktiske eksempler på hvordan du kan bruke egendefinerte metrikker for å overvåke spesifikke aspekter av applikasjonens ytelse.

1. Måle API-responstid

Å spore tiden det tar å motta svar fra backend-API-ene dine er avgjørende for å identifisere potensielle flaskehalser. Slik kan du måle API-responstid:

            
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 kodeutdraget måler tiden det tar å hente data fra `/api/data`-endepunktet. Metrikken `apiResponseTime` fanger opp hele varigheten av API-kallet, fra starten av forespørselen til mottak av responsen.

2. Spore Lastetid for Bilder

Bilder er ofte en betydelig faktor i sidelastingsytelse. Å måle tiden det tar for bilder å laste, kan hjelpe deg med å identifisere overdimensjonerte bilder eller trege 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 kodeutdraget måler tiden det tar for et bilde å laste fra den angitte URL-en. Metrikken `imageLoadTime` fanger opp varigheten fra starten av bildeforespørselen til fullføringen av bildelasten.

3. Overvåke Kjøretid for Tredjepartsskript

Tredjepartsskript kan ofte ha en betydelig innvirkning på frontend-ytelsen. Å måle kjøretiden deres kan hjelpe deg med å identifisere problematiske skript og optimalisere lasting eller kjøring av dem.

            
// Antar at tredjepartsskriptet har en global funksjon kalt 'thirdPartyScript'

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

            

              
                Copy
              
            
          

Dette kodeutdraget måler kjøretiden til et hypotetisk tredjepartsskript. Metrikken `thirdPartyScriptExecutionTime` fanger opp varigheten av skriptets kjøring.

4. Måle Time to Interactive (TTI) for Spesifikke Komponenter

Selv om TTI er en standardmetrikk, kan du tilpasse den for å måle tiden det tar for spesifikke komponenter å bli interaktive. Dette lar deg finne ut hvilke komponenter som bidrar mest til den totale TTI-en.

            
// Etter at komponenten er fullstendig rendret og interaktiv
performance.mark('componentInteractive');
performance.measure('componentTTI', 'componentRenderStart', 'componentInteractive');

            

              
                Copy
              
            
          

Dette eksemplet forutsetter at `componentRenderStart` ble definert tidligere. Det måler tiden fra komponenten begynte å rendre til den er fullt interaktiv.

Avanserte Teknikker og Vurderinger

Utover det grunnleggende, er her noen avanserte teknikker og vurderinger for å bruke Performance Observer og egendefinerte metrikker effektivt:

1. Bruke User Timing API for Komplekse Scenarier

For mer komplekse scenarier kan det hende du må opprette flere markeringer og målinger for å spore forskjellige faser av en hendelse. User Timing API gir en fleksibel måte å håndtere disse markørene og beregningene på.

2. Utnytte Long Tasks API

Long Tasks API kan hjelpe til med å identifisere oppgaver som blokkerer hovedtråden i lengre perioder, noe som fører til dårlig brukeropplevelse. Du kan kombinere dette med egendefinerte metrikker for å korrelere lange oppgaver med spesifikke applikasjonshandlinger.

3. `buffered`-flagget og Sent Lastede Observers

Hvis du initialiserer din Performance Observer etter at noen ytelseshendelser allerede har skjedd, kan du bruke `buffered`-flagget for å hente disse hendelsene. For eksempel:

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

            

              
                Copy
              
            
          

4. Throttling og Debouncing

I scenarier med høy frekvens, bør du vurdere å bruke throttling eller debouncing på innsamlingen av metrikker for å unngå ytelsesomkostninger. For eksempel, hvis du sporer musebevegelser, kan du samle inn data bare hvert 100. ms.

5. Datainnsamling og Analyse

De rå ytelsesdataene som samles inn av Performance Observer, må aggregeres og analyseres for å gi meningsfull innsikt. Dette innebærer vanligvis å sende dataene til en analyseplattform, som Google Analytics, New Relic, eller en spesialbygd løsning. Sørg for at analyseplattformen din kan håndtere egendefinerte metrikker og tilby de nødvendige rapporteringsmulighetene.

6. Real User Monitoring (RUM)

For å få et sant bilde av applikasjonens ytelse, implementer Real User Monitoring (RUM). RUM samler inn ytelsesdata fra virkelige brukere under reelle forhold, og gir verdifull innsikt i hvordan applikasjonen din presterer for forskjellige brukere og enheter. Egendefinerte metrikker er en viktig del av en omfattende RUM-strategi.

7. Sikkerhetshensyn

Vær oppmerksom på sikkerhet når du samler inn og overfører ytelsesdata. Unngå å samle inn sensitiv brukerinformasjon og sørg for at data overføres sikkert (f.eks. ved hjelp av HTTPS).

Eksempel: Måle Time to First Byte (TTFB) ved hjelp av Resource Timing API

TTFB er tiden det tar for nettleseren å motta den første byten med data fra serveren. Selv om det ikke strengt tatt er en egendefinert metrikk definert med `mark` og `measure`, er det en verdifull ytelsesindikator som kan aksesseres 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) { // Sjekk om det er hoveddokumentet
      const ttfb = entry.responseStart - entry.startTime;
      console.log(`TTFB: ${ttfb}ms`);
      // Send ttfb til din analyseplattform
    }
  });
});

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

            

              
                Copy
              
            
          

Kompatibilitet på tvers av Nettlesere

Performance Observer API støttes bredt på tvers av moderne nettlesere. Det er imidlertid alltid god praksis å sjekke nettleserkompatibilitet og tilby reservemekanismer for eldre nettlesere. Du kan bruke en polyfill eller en enklere måleteknikk for nettlesere som ikke støtter Performance Observer API.

            
if ('PerformanceObserver' in window) {
  // Bruk Performance Observer API
  const observer = new PerformanceObserver((list) => { /* ... */ });
  observer.observe({ entryTypes: ['measure'] });
} else {
  // Bruk en reservemekanisme (f.eks. Date.now() for enkle tidsmålinger)
  console.warn('PerformanceObserver API støttes ikke i denne nettleseren.');
}

            

              
                Copy
              
            
          

Beste Praksis for Bruk av Egendefinerte Metrikker

• Definer klare mål: Hvilke spesifikke ytelsesaspekter ønsker du å overvåke?
• Velg meningsfulle metrikknavn: Bruk beskrivende og konsistente navn på dine egendefinerte metrikker.
• Dokumenter metrikkene dine: Dokumenter formålet og beregningen av hver egendefinert metrikk tydelig.
• Sett ytelsesbudsjetter: Definer akseptable ytelsesterskler for dine egendefinerte metrikker.
• Automatiser datainnsamling og analyse: Integrer innsamling av egendefinerte metrikker i byggeprosessen og analyse-pipelinen din.
• Gjennomgå og finjuster metrikkene dine jevnlig: Etter hvert som applikasjonen din utvikler seg, kan behovene for ytelsesovervåking endres.

Konklusjon

Frontend-ytelse er en kontinuerlig reise, ikke en destinasjon. Ved å utnytte Frontend Performance Observer API og definere egendefinerte metrikker, kan du få en dypere forståelse av applikasjonens ytelse og identifisere områder for forbedring. Denne skreddersydde tilnærmingen til ytelsesovervåking gir deg muligheten til å optimalisere brukeropplevelsen og levere en raskere, mer responsiv webapplikasjon. Husk å konsekvent overvåke, analysere og finjustere metrikkene dine for å ligge i forkant og sikre at applikasjonen din presterer optimalt for alle brukere, uavhengig av deres plassering eller enhet.

Denne artikkelen ga en omfattende oversikt over egendefinerte metrikker ved hjelp av Performance Observer API. Det er avgjørende å tilpasse disse teknikkene til dine spesifikke applikasjonsbehov og kontinuerlig overvåke og analysere dataene for å ta informerte beslutninger om ytelsesoptimalisering.

Videre Lesing:

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