Frontend Performance API Resource Timing-aggregering: Analyse af indlæsningsydelse

I bestræbelserne på at levere exceptionelle brugeroplevelser er optimering af frontend-ydelse altafgørende. Et kritisk aspekt af denne optimering ligger i at forstå, hvordan ressourcer indlæses på din hjemmeside eller applikation. Resource Timing API'et, en del af den bredere Performance API-suite, giver detaljeret indsigt i timingen for hver ressource, der hentes af browseren. Denne information er uvurderlig til at identificere flaskehalse og forbedre den overordnede indlæsningsydelse. Denne omfattende guide udforsker, hvordan man udnytter Resource Timing API'et, aggregerer dets data og bruger det til analyse af indlæsningsydelse.

Forståelse af Resource Timing API'et

Resource Timing API'et giver detaljerede timingoplysninger for ressourcer, der indlæses af en webside, såsom billeder, scripts, stylesheets og andre aktiver. Dette inkluderer målinger som:

• Initiator Type: Typen af element, der startede anmodningen (f.eks. 'img', 'script', 'link').
• Name: URL'en til ressourcen.
• Start Time: Tidsstemplet for, hvornår browseren begynder at hente ressourcen.
• Fetch Start: Tidsstemplet umiddelbart før browseren begynder at hente ressourcen fra disk-cachen eller netværket.
• Domain Lookup Start/End: Tidsstemplerne, der angiver, hvornår DNS-opslagsprocessen starter og slutter.
• Connect Start/End: Tidsstemplerne, der angiver, hvornår TCP-forbindelsen til serveren starter og slutter.
• Request Start/End: Tidsstemplerne, der angiver, hvornår HTTP-anmodningen starter og slutter.
• Response Start/End: Tidsstemplerne, der angiver, hvornår HTTP-svaret starter og slutter.
• Transfer Size: Størrelsen på den overførte ressource i bytes.
• Encoded Body Size: Størrelsen på den kodede (f.eks. GZIP-komprimerede) ressource-body.
• Decoded Body Size: Størrelsen på den dekodede ressource-body.
• Duration: Samlet tid brugt på at hente ressourcen (responseEnd - startTime).

Disse målinger giver udviklere mulighed for at udpege specifikke områder, hvor ydelsesforbedringer kan foretages. For eksempel kan lange DNS-opslagstider tyde på, at man bør skifte til en hurtigere DNS-udbyder eller udnytte et CDN. Langsomme forbindelsestider kan indikere netværksbelastning eller problemer på serversiden. Store overførselsstørrelser kan fremhæve muligheder for billedoptimering eller kodeminificering.

Adgang til Resource Timing-data

Resource Timing API'et tilgås via performance-objektet i JavaScript:

            const resourceTimingEntries = performance.getEntriesByType("resource");

resourceTimingEntries.forEach(entry => {
  console.log(entry.name, entry.duration);
});

            

              
                Copy
              
            
          

Dette kodestykke henter alle ressourcetiming-poster og logger navnet og varigheden af hver ressource til konsollen. Bemærk, at browsere af sikkerhedsmæssige årsager kan begrænse detaljeringsgraden fra Resource Timing API'et. Dette styres ofte af timingAllowOrigin-headeren, som tillader cross-origin-ressourcer at eksponere deres timingoplysninger.

Aggregering af Resource Timing-data

Rå ressourcetiming-data er nyttige, men for at opnå handlingsorienteret indsigt skal de aggregeres og analyseres. Aggregering involverer gruppering og opsummering af data for at identificere tendenser og mønstre. Dette kan gøres på flere måder:

Efter ressourcetype

Ved at gruppere ressourcer efter type (f.eks. billeder, scripts, stylesheets) kan du sammenligne de gennemsnitlige indlæsningstider for hver kategori. Dette kan afsløre, om visse typer ressourcer konsekvent er langsommere end andre.

            const resourceTypes = {};

resourceTimingEntries.forEach(entry => {
  const initiatorType = entry.initiatorType;
  if (!resourceTypes[initiatorType]) {
    resourceTypes[initiatorType] = {
      count: 0,
      totalDuration: 0,
      averageDuration: 0
    };
  }
  resourceTypes[initiatorType].count++;
  resourceTypes[initiatorType].totalDuration += entry.duration;
});

for (const type in resourceTypes) {
  resourceTypes[type].averageDuration = resourceTypes[type].totalDuration / resourceTypes[type].count;
  console.log(type, resourceTypes[type].averageDuration);
}

            

              
                Copy
              
            
          

Denne kode beregner den gennemsnitlige indlæsningstid for hver ressourcetype og logger den til konsollen. For eksempel kan du opdage, at billeder har en markant højere gennemsnitlig indlæsningstid end scripts, hvilket indikerer et behov for billedoptimering.

Efter domæne

Ved at gruppere ressourcer efter domæne kan du vurdere ydeevnen af forskellige content delivery networks (CDN'er) eller tredjepartstjenester. Dette kan hjælpe dig med at identificere langsomme domæner og overveje alternative udbydere.

            const resourceDomains = {};

resourceTimingEntries.forEach(entry => {
  const domain = new URL(entry.name).hostname;
  if (!resourceDomains[domain]) {
    resourceDomains[domain] = {
      count: 0,
      totalDuration: 0,
      averageDuration: 0
    };
  }
  resourceDomains[domain].count++;
  resourceDomains[domain].totalDuration += entry.duration;
});

for (const domain in resourceDomains) {
  resourceDomains[domain].averageDuration = resourceDomains[domain].totalDuration / resourceDomains[domain].count;
  console.log(domain, resourceDomains[domain].averageDuration);
}

            

              
                Copy
              
            
          

Denne kode beregner den gennemsnitlige indlæsningstid for hvert domæne og logger den til konsollen. Hvis du bemærker, at et bestemt CDN er konsekvent langsomt, kan det være en god idé at undersøge dets ydeevne eller skifte til en anden udbyder. Overvej for eksempel et scenarie, hvor du bruger både Cloudflare og Akamai. Denne aggregering ville give dig mulighed for direkte at sammenligne deres ydeevne i din specifikke kontekst.

Efter side

Aggregering af data efter side (eller rute) giver dig mulighed for at identificere sider med særligt dårlig ydeevne. Dette kan hjælpe dig med at prioritere optimeringsindsatsen og fokusere på de sider, der har den største indvirkning på brugeroplevelsen.

Dette kræver ofte integration med din applikations routing-system. Du skal knytte hver ressourcetiming-post til den aktuelle sides URL eller rute. Implementeringen vil variere afhængigt af det framework, du bruger (f.eks. React, Angular, Vue.js).

Oprettelse af brugerdefinerede målinger

Udover de standardmålinger, som Resource Timing API'et leverer, kan du oprette brugerdefinerede målinger for at spore specifikke aspekter af din applikations ydeevne. For eksempel vil du måske måle den tid, det tager at indlæse en bestemt komponent eller rendere et specifikt element.

Dette kan opnås ved hjælp af metoderne performance.mark() og performance.measure():

            performance.mark('component-start');

// Load the component

performance.mark('component-end');

performance.measure('component-load', 'component-start', 'component-end');

const componentLoadTime = performance.getEntriesByName('component-load')[0].duration;

console.log('Component load time:', componentLoadTime);

            

              
                Copy
              
            
          

Dette kodestykke måler den tid, det tager at indlæse en komponent, og logger den til konsollen. Du kan derefter aggregere disse brugerdefinerede målinger på samme måde som de standardiserede Resource Timing API-målinger.

Analyse af Resource Timing-data for ydelsesindsigt

Når du har aggregeret ressourcetiming-data, kan du bruge dem til at identificere specifikke områder for ydelsesforbedring. Her er nogle almindelige scenarier og potentielle løsninger:

Lange DNS-opslagstider

• Årsag: Langsom DNS-server, fjerntliggende DNS-server, sjældne DNS-opslag.
• Løsning: Skift til en hurtigere DNS-udbyder (f.eks. Cloudflare, Google Public DNS), udnyt et CDN til at cache DNS-records tættere på brugerne, implementer DNS-prefetching.
• Eksempel: En hjemmeside rettet mod globale brugere oplevede langsomme indlæsningstider i visse regioner. Analyse af ressourcetiming-data afslørede lange DNS-opslagstider i disse regioner. Et skift til et CDN med globale DNS-servere reducerede DNS-opslagstiderne markant og forbedrede den samlede ydeevne.

Langsomme forbindelsestider

• Årsag: Netværksbelastning, problemer på serversiden, firewall-interferens.
• Løsning: Optimer serverinfrastruktur, brug et CDN til at distribuere indhold tættere på brugerne, konfigurer firewalls til at tillade effektiv kommunikation.
• Eksempel: En e-handels-hjemmeside oplevede langsomme forbindelsestider i spidsbelastningsperioder. Analyse af ressourcetiming-data pegede på serveroverbelastning som den primære årsag. Opgradering af serverhardware og optimering af databaseforespørgsler forbedrede forbindelsestiderne og forhindrede ydelsesforringelse under spidsbelastning.

Store overførselsstørrelser

• Årsag: Uoptimerede billeder, uminificeret kode, unødvendige aktiver.
• Løsning: Optimer billeder (f.eks. komprimer, tilpas størrelse, brug moderne formater som WebP), minificer JavaScript- og CSS-kode, fjern ubrugt kode og aktiver, aktiver GZIP- eller Brotli-komprimering.
• Eksempel: En nyhedshjemmeside brugte store, uoptimerede billeder, der markant øgede sidens indlæsningstider. Optimering af billeder med værktøjer som ImageOptim og implementering af lazy loading reducerede billedoverførselsstørrelserne og forbedrede sidens indlæsningsydelse.
• Internationaliseringsovervejelse: Sørg for, at billedoptimering tager højde for forskellige skærmstørrelser og opløsninger, der er almindelige i forskellige regioner.

Langsomme serversvartider

• Årsag: Ineffektiv server-side-kode, databaseflaskehalse, netværkslatens.
• Løsning: Optimer server-side-kode, forbedr databaseydelse, brug et CDN til at cache indhold tættere på brugerne, implementer HTTP-caching.
• Eksempel: En social medie-platform oplevede langsomme serversvartider på grund af ineffektive databaseforespørgsler. Optimering af databaseforespørgsler og implementering af caching-mekanismer reducerede serversvartiderne markant og forbedrede den samlede ydeevne.

Render-blokerende ressourcer

• Årsag: Synkron JavaScript og CSS, der blokerer renderingen af siden.
• Løsning: Udskyd indlæsning af ikke-kritisk JavaScript, inline kritisk CSS, brug asynkron indlæsning for scripts, fjern ubrugt CSS.
• Eksempel: En blog-hjemmeside brugte en stor, render-blokerende CSS-fil, der forsinkede den indledende rendering af siden. Ved at inline kritisk CSS og udskyde indlæsningen af ikke-kritisk CSS forbedredes den opfattede ydeevne af hjemmesiden.

Integrering af Resource Timing-data i værktøjer til ydelsesovervågning

Manuel indsamling og analyse af ressourcetiming-data kan være tidskrævende. Heldigvis kan flere værktøjer til ydelsesovervågning automatisere denne proces og give realtidsindsigt i din hjemmesides ydeevne. Disse værktøjer indsamler typisk ressourcetiming-data i baggrunden og præsenterer dem i et brugervenligt dashboard.

Populære værktøjer til ydelsesovervågning, der understøtter ressourcetiming-data, inkluderer:

• Google PageSpeed Insights: Giver anbefalinger til forbedring af sidehastighed baseret på forskellige ydelsesmålinger, herunder ressourcetiming-data.
• WebPageTest: Giver dig mulighed for at teste din hjemmesides ydeevne fra forskellige steder og browsere og giver detaljerede ressourcetiming-oplysninger.
• New Relic: Tilbyder omfattende ydelsesovervågningsfunktioner, herunder realtids-ressourcetiming-data og visualiseringer.
• Datadog: Giver detaljerede ressourcetiming-målinger sammen med bredere infrastruktur- og applikationsovervågning, hvilket giver et holistisk syn på ydeevnen.
• Sentry: Primært fokuseret på fejlsporing, men Sentry tilbyder også ydelsesovervågningsfunktioner, herunder ressourcetiming-data til at korrelere ydelsesproblemer med specifikke fejl.
• Lighthouse: Et open-source, automatiseret værktøj til at forbedre kvaliteten af websider. Det har revisioner for ydeevne, tilgængelighed, progressive web-apps, SEO og mere. Kan køres fra Chrome DevTools, fra kommandolinjen eller som et Node-modul.

Ved at integrere ressourcetiming-data i disse værktøjer kan du få en dybere forståelse af din hjemmesides ydeevne og identificere forbedringsområder mere effektivt.

Etiske overvejelser og brugerbeskyttelse

Når du indsamler og analyserer ressourcetiming-data, er det afgørende at overveje etiske implikationer og brugerbeskyttelse. Vær gennemsigtig over for brugerne om de data, du indsamler, og hvordan de bruges. Sørg for, at du overholder relevante databeskyttelsesregler, såsom GDPR og CCPA.

Undgå at indsamle personligt identificerbare oplysninger (PII) og anonymiser eller pseudonymiser data, hvor det er muligt. Implementer passende sikkerhedsforanstaltninger for at beskytte data mod uautoriseret adgang eller videregivelse. Overvej at give brugerne mulighed for at fravælge ydelsesovervågning.

Avancerede teknikker og fremtidige tendenser

Resource Timing API'et udvikler sig konstant, og nye funktioner og teknikker dukker op for yderligere at forbedre analyse af frontend-ydelse. Her er nogle avancerede teknikker og fremtidige tendenser, du skal holde øje med:

Server Timing API

Server Timing API'et giver servere mulighed for at eksponere timingoplysninger om deres behandlingstid for en anmodning. Disse oplysninger kan kombineres med ressourcetiming-data for at give et mere komplet billede af end-to-end-ydeevnen.

Long Tasks API

Long Tasks API'et identificerer opgaver, der blokerer hovedtråden i længere perioder, hvilket forårsager UI-hak og reaktivitetsproblemer. Disse oplysninger kan bruges til at optimere JavaScript-kode og forbedre brugeroplevelsen.

WebAssembly (Wasm)

WebAssembly er et binært instruktionsformat for virtuelle maskiner, der tillader næsten-native ydeevne i browseren. Brug af Wasm til ydelseskritiske opgaver kan markant forbedre indlæsningstider og den samlede ydeevne.

HTTP/3

HTTP/3 er den seneste version af HTTP-protokollen, som bruger QUIC-transportprotokollen til at give forbedret ydeevne og pålidelighed. HTTP/3 tilbyder flere fordele i forhold til HTTP/2, herunder reduceret latenstid og forbedret forbindelsesstyring.

Konklusion

Resource Timing API'et er et kraftfuldt værktøj til at forstå og optimere frontend-ydelse. Ved at aggregere og analysere ressourcetiming-data kan du identificere flaskehalse, forbedre indlæsningstider og levere en bedre brugeroplevelse. Uanset om du er en erfaren frontend-udvikler eller lige er startet, er det essentielt at mestre Resource Timing API'et for at bygge højtydende webapplikationer. Omfavn kraften i datadrevet optimering og frigør det fulde potentiale af din hjemmeside eller applikation. Husk at prioritere brugerbeskyttelse og etiske overvejelser, når du indsamler og analyserer ydelsesdata. Ved at holde dig informeret om de seneste tendenser og teknikker kan du sikre, at din hjemmeside forbliver hurtig, responsiv og brugervenlig i de kommende år. Udnyttelse af disse teknikker og værktøjer vil bidrage til et mere højtydende og globalt tilgængeligt web.

Handlingsorienteret indsigt: Start med at implementere grundlæggende ressourcetiming-aggregering efter ressourcetype og domæne. Dette giver øjeblikkelig indsigt i, hvor dine ydelsesflaskehalse er. Integrer derefter med et værktøj til ydelsesovervågning som Google PageSpeed Insights eller WebPageTest for at automatisere dataindsamling og -analyse.