Å bryte Ned Ytelsen API

0
69

JavaScript-Ytelsen API er forsvarlig, fordi det hender over verktøy for å måle ytelsen til Web-sider, som på tross av å være utført siden lenge før, aldri egentlig ble enkelt-eller presis nok.

Som sagt, det er ikke så lett å komme i gang med API som det er å faktisk bruke den. Selv om jeg har sett utvidelser av det som dekkes her og der i andre innlegg, det store bildet som knytter alt sammen er vanskelig å finne.

En titt på et hvilket som helst dokument som forklarer den globale ytelse interface (tilgangspunktet for Ytelsen API), og du vil bli bombardert med en slew av andre spesifikasjoner, inkludert Høy Oppløsning Tid API, Ytelse Tidslinjen API og Navigasjon API blant det som føles som mange, mange andre. Det er nok til å gjøre det overordnede konseptet mer enn litt forvirrende hva API er å måle, men, enda viktigere, gjør det lett å overse den spesifikke godbiter at vi får med det.

Her er en illustrasjon av hvordan alle disse bitene til å passe sammen. Dette kan være super forvirrende, så det å ha en visuell kan bidra til å klargjøre hva vi snakker om.

Ytelsen API inkluderer den Ytelse Tidslinjen API, og sammen utgjør de et bredt spekter av metoder som henter nyttig beregninger på Web-siden ytelse.

La oss grave i, skal vi?

Høy Oppløsning i Tid API

Ytelsen grensesnitt er en del av den Høye Oppløsningen Tid API.

“Hva er Høy Oppløsning Tid?” spør du kanskje. Det er et kjernebegrep vi ikke kan overse.

En gang basert på den Dato som er korrekt til millisekund. En høy oppløsning tid, på den annen side, er nøyaktig opp til fraksjoner av millisekunder. Det er ganske darn presis, noe som gjør det mer ideelt for å gir nøyaktige målinger av tid.

Det er verdt å peke på at en høy oppløsning tid målt ved User Agenten (UA) ikke endrer seg med endringer i systemet tid fordi det er tatt fra en global, stadig monotonic klokke som er opprettet av UA. Den gang alltid øker, og kan ikke bli tvunget til å redusere. Det blir en nyttig begrensning for å måle tid.

Hver gang måling målt i Ytelse API er en høy oppløsning i tid. Ikke bare gjør det at det er en super nøyaktig måte å måle ytelse, men det er også det som gjør API-en del av den Høye Oppløsningen Tid API og hvorfor ser vi de to ofte nevnt sammen.

Ytelse Tidslinjen API

Ytelsen Tidslinjen API er en forlengelse av Ytelse API. Det betyr at der hvor Ytelsen API er en del av den Høye Oppløsningen Tid API, Ytelse Tidslinjen API er en del av Ytelsen API.

Eller, for å si det mer konsist:

Høy Oppløsning i Tid API
À── ytelse API
À── ytelse Tidslinjen API

Ytelse Tidslinjen API gir oss tilgang til nesten alle av de mål og verdier vi kan muligens få fra hele Ytelsen API seg selv. Det er mye informasjon på fingertuppene med et enkelt API og hvorfor diagrammet i begynnelsen av denne artikkelen viser dem nesten på samme plan som en annen.

Det er mange utvidelser av Ytelse API. Hver og en går tilbake performance-relaterte oppføringer og alle av dem kan åpnes og selv filtrert gjennom Ytelse Tidslinjen, noe som gjør dette til et must-lære API for alle som ønsker å komme i gang med ytelse målinger. De er så nært beslektet og utfyller hverandre at det er fornuftig å være kjent med begge deler.

Følgende er tre metoder for Ytelsen Tidslinjen API som er inkludert i ytelse grensesnitt:

  • getEntries()
  • getEntriesByName()
  • getEntriesByType()

Hver metode returnerer en liste over (eventuelt filtrert) ytelse oppføringer som er samlet inn fra alle de andre utvidelser av Ytelse API og vi vil bli mer kjent med dem mens vi går.

En annen tast grensesnitt inkludert i API-er PerformanceObserver. Det klokker for en ny oppføring i en gitt liste over ytelse oppføringer, og varsler om det samme. Ganske hendig for sanntids overvåking!

Ytelsen Oppføringer

De tingene vi kan måle med Ytelse API er referert til som “oppføringer”, og de alle tilbyr en rekke innsikt i Web ytelse.

Nysgjerrig på hva de er? MDN har en full liste, som sannsynligvis kommer til å bli oppdatert når nye elementer er lansert, men dette er det vi i dag har:

Oppføringen
Hva du kan måle
Foreldre API
ramme Tiltak rammer, som representerer en løkke av den mengden arbeid som en nettleseren trenger å gjøre for å behandle ting som DOM hendelser, endre størrelse, rulling og CSS-animasjoner. Rammen Timing API
merke Skaper et tidsstempel i ytelse tidslinje som gir verdier for et navn, start tid og varighet. Brukertid API
måle Lignende for å markere at de er punkter på tidslinjen, men de er oppkalt etter deg og plassert mellom merkene. I utgangspunktet, de er et midtpunkt mellom merkene med ingen custom name (tilpasset navn verdi. Brukertid API
navigasjon Gir kontekst for lasteoperasjonen, for eksempel hvilke typer hendelser som oppstår. Navigation Timing API
maling Rapporter øyeblikk når punkter gjengis på skjermen, slik som den første maling, første maling med innhold, start-tid og total varighet. Maling, Tidspunktet API
ressurs Tiltak ventetid av avhengigheter for gjengivelse av skjermen, som for eksempel bilder, skript og stilark. Dette er hvor caching gjør en forskjell! Ressurs Timing API

La oss se på noen eksempler som illustrerer hvordan hver API ser ut i bruk. For å lære mer i dybden om dem, kan du sjekke ut den spesifikasjoner knyttet opp i tabellen over. Rammen Timing API-er fortsatt i verk.

Maling, Tidspunktet API, bekvemt, har allerede blitt dekket grundig på CSS-Triks, men her er et eksempel på å trekke tidsstempelet for når maleriet begynner:

// Klokkeslett når siden begynte å gjengi
– konsollen.logg(ytelse.getEntriesByType(‘male’)[0].startTime)

Den brukertid API kan måle ytelsen for fremkaller-skript. For eksempel, si du har kode som validerer en opplastet fil. Vi kan måle hvor lang tid det tar å utføre:

// Klokkeslett for å konsoll-print “hei”
// Vi kan også gjøre bruk av “ytelse.mål()” til å måle tid
// i stedet for å beregne forskjellen mellom merkene i siste linje.
ytelse.mark(“)
– konsollen.logg(‘hei’)
ytelse.mark(“)
var markerer = ytelse.getEntriesByType(‘mark’)
console.info (“Time tok det å si hei ${merker[1].startTime – merker[0].startTime}`)

Den Navigation Timing API viser beregninger for å legge til gjeldende side, beregninger selv fra når lossing på forrige side fant sted. Vi kan måle med massevis av presisjon for nøyaktig hvor lenge en gjeldende side tar å laste inn:

// Klokkeslett for å fullføre DOM innhold som er lagt event
var navEntry = ytelse.getEntriesByType(‘navigasjon’)[0]
– konsollen.logg(navEntry.domContentLoadedEventEnd – navEntry.domContentLoadedEventStart)

Den Ressurs Timing API er lik Navigation Timing API i at den måler legg ganger, bortsett fra den måler alle beregninger for å legge i den forespurte ressurser av en gjeldende side, snarere enn gjeldende på selve siden. For eksempel, kan vi måle hvor lang tid det tar et bilde som er lagret på en annen server, for eksempel en CDN, kan du laste ned på siden:

// Responstid av ressurser
ytelse.getEntriesByType(‘ressurs’).forEach((r) => {
– konsollen.logg(`responstid for ${r.navn}: ${r.responseEnd – r.responseStart}`);
});

Navigasjon-Anomali

Vil du høre en interessant godbit om Navigation Timing API?

Det ble unnfanget før Forestilling Tidslinjen API. Det er derfor, selv om du kan få tilgang til noen navigering beregninger ved hjelp av Ytelse Tidslinjen API (ved filtrering navigasjon oppføringstype), Navigation Timing API selv har to grensesnitt som er direkte utvidet fra Ytelse API:

  • ytelse.timing
  • ytelse.navigasjon

Alle beregningene som er gitt av prestasjoner.navigasjon kan bli gitt av navigasjon oppføringer av Ytelse Tidslinjen API. Som for beregningene som du henter fra ytelse.timing, men bare noen er tilgjengelig fra Ytelse Tidslinjen API.

Som et resultat, vi bruker ytelse.timing å få navigering til statistikk for den aktuelle siden i stedet for å bruke Ytelsen Tidslinjen API via ytelse.getEntriesByType(“navigasjon”):

// Gang fra start av navigasjonen til den gjeldende siden til slutten av lasten sin event
addEventListener(‘load’, () => {
med(ytelse.timing)
– konsollen.logg(navigationStart – loadEventEnd);
})

La oss Bryte Dette Opp

Jeg vil si det beste alternativet for å komme i gang med Ytelse API er å begynne med å bli kjent med alle ytelse oppføringstyper og deres attributter. Dette vil få deg raskt kjent med utfallet av alle Api—og power-dette API gir for måling av ytelse.

Som et annet kurs av handlingen, få vite hvordan Ytelse Tidslinjen API går inn i alle de tilgjengelige beregninger. Som vi dekket, de to er nært beslektet og samspillet mellom de to kan åpne opp interessante og nyttige metoder for måling.

På dette punktet, kan du gjøre et trekk mot å mestre den fine kunsten å sette den andre utvidet Api for å bruke. Det er der alt kommer sammen og du endelig få se hele bildet av hvordan alle disse Api-er, – metoder og-oppføringer forbundet med hverandre.