Esiliidese Jõudluse Vabastamine: Põhjalik Sukeldumine Resource Timing API-sse

Veebiarenduse maailmas ei ole kiirus lihtsalt omadus; see on positiivse kasutajakogemuse fundamentaalne nõue. Aeglaselt laadiv veebisait võib kaasa tuua kõrgemaid põrkemäärasid, madalamat kasutajate kaasatust ja lõppkokkuvõttes negatiivset mõju ärieesmärkidele. Kuigi tööriistad nagu Lighthouse ja WebPageTest pakuvad hindamatut kõrgetasemelist diagnostikat, esindavad need sageli ühteainsat sünteetilist testi. Et tõeliselt mõista ja optimeerida jõudlust globaalsele publikule, peame mõõtma tegelike kasutajate kogemust nende seadmetes ja nende võrkudes. Siin tulebki mängu reaalajas kasutajate monitooring (RUM) ja üks selle võimsamaid tööriistu on Resource Timing API.

See põhjalik juhend viib teid sügavale Resource Timing API maailma. Uurime, mis see on, kuidas seda kasutada ja kuidas muuta selle granulaarsed andmed rakendatavateks teadmisteks, mis võivad teie rakenduse laadimisjõudlust dramaatiliselt parandada. Olenemata sellest, kas olete kogenud esiliidese insener või alles alustate oma jõudluse optimeerimise teekonda, varustab see artikkel teid teadmistega, et lahti harutada ja mõista iga teie lehel oleva ressursi võrgu jõudlust.

Mis on Resource Timing API?

Resource Timing API on brauseripõhine JavaScripti API, mis pakub üksikasjalikke võrgu ajastuse andmeid iga ressursi kohta, mida veebileht alla laadib. Mõelge sellest kui mikroskoopilisest läätsest oma lehe võrgutegevuse jaoks. Iga pildi, skripti, stiililehe, fondi ja API-kutse (läbi `fetch` või `XMLHttpRequest`) jaoks salvestab see API kõrge resolutsiooniga ajatempli iga võrgupäringu etapi kohta.

See on osa suuremast Jõudluse API-de komplektist, mis töötavad koos, et pakkuda terviklikku vaadet teie rakenduse jõudlusest. Kui Navigation Timing API keskendub peadokumendi elutsüklile, siis Resource Timing API suumib sisse kõikidele sõltuvatele ressurssidele, mida peadokument nõuab.

Miks see nii oluline on?

• Granulaarsus: See liigub kaugemale ühestainsast "lehe laadimisaja" mõõdikust. Näete täpselt, kui kaua kestis DNS-päring, TCP-ühendus ja sisu allalaadimine konkreetse kolmanda osapoole skripti või olulise kangelaspildi jaoks.
• Päris kasutajate andmed: Erinevalt laboripõhistest tööriistadest töötab see API teie kasutajate brauserites. See võimaldab teil koguda jõudlusandmeid erinevatest võrgutingimustest, seadmetest ja geograafilistest asukohtadest, andes teile tõese pildi teie globaalsest kasutajakogemusest.
• Rakendatavad teadmised: Neid andmeid analüüsides saate tuvastada konkreetsed kitsaskohad. Kas kolmanda osapoole analüütikaskript ühendub aeglaselt? Kas teie CDN toimib teatud piirkonnas alajõudlusega? Kas teie pildid on liiga suured? Resource Timing API pakub tõendeid, mis on vajalikud nendele küsimustele enesekindlalt vastamiseks.

Ressursi Laadimise Anatoomia: Ajajoone Lahtiharutamine

Resource Timing API tuum on `PerformanceResourceTiming` objekt. Iga laaditud ressursi jaoks loob brauser ühe sellise objekti, mis sisaldab rikkalikult ajastus- ja suurusteavet. Nende objektide mõistmiseks on abiks laadimisprotsessi visualiseerimine waterfall-diagrammina, kus iga samm järgneb eelmisele.

Vaatame lähemalt `PerformanceResourceTiming` objekti peamisi omadusi. Kõik ajaväärtused on kõrge resolutsiooniga ajatemplid, mõõdetuna millisekundites lehe navigeerimise algusest (`performance.timeOrigin`).

startTime -> fetchStart -> domainLookupStart -> domainLookupEnd -> connectStart -> connectEnd -> requestStart -> responseStart -> responseEnd

Peamised Ajastuse Omadused

• name: Ressursi URL. See on teie peamine identifikaator.
• entryType: Sõne, mis näitab jõudluskirje tüüpi. Meie eesmärkidel on see alati "resource".
• initiatorType: See on silumisel uskumatult kasulik. See ütleb teile, kuidas ressurssi nõuti. Levinumad väärtused on 'img', 'link' (CSS-i jaoks), 'script', 'css' (ressurssidele, mis laaditakse CSS-i seest, nt `@import`), 'fetch' ja 'xmlhttprequest'.
• duration: Ressursi jaoks kulunud koguaeg, arvutatud kui responseEnd - startTime. See on ühe ressursi tipptaseme mõõdik.
• startTime: Ajatempel vahetult enne ressursi toomise algust.
• fetchStart: Ajatempel vahetult enne, kui brauser hakkab ressurssi tooma. Enne võrku pöördumist võib see kontrollida vahemälusid (HTTP vahemälu, Service Worker vahemälu). Kui ressurss serveeritakse vahemälust, on paljud järgnevad ajastusväärtused null.
• domainLookupStart & domainLookupEnd: Need märgivad DNS-i (domeeninimede süsteemi) päringu algust ja lõppu. Kestus (domainLookupEnd - domainLookupStart) on aeg, mis kulus domeeninime IP-aadressiks lahendamiseks. Kõrge väärtus siin võib viidata aeglasele DNS-pakkujale.
• connectStart & connectEnd: Need märgivad serveriga ühenduse loomise algust ja lõppu. HTTP puhul on see TCP kolmesuunaline kätlus. Kestus (connectEnd - connectStart) on teie TCP-ühenduse aeg.
• secureConnectionStart: Kui ressurss laaditakse üle HTTPS-i, märgib see ajatempel SSL/TLS kätluse algust. Kestus (connectEnd - secureConnectionStart) näitab, kui kaua krüpteerimisläbirääkimised aega võtsid. Aeglased TLS kätlused võivad olla märk serveri valest konfiguratsioonist või võrgu latentsusest.
• requestStart: Ajatempel vahetult enne, kui brauser saadab tegeliku HTTP-päringu ressursi saamiseks serverile. Aega connectEnd ja requestStart vahel nimetatakse sageli "päringu järjekorra" ajaks, mil brauser ootab vaba ühendust.
• responseStart: Ajatempel, mil brauser saab serverilt vastuse kõige esimese baidi. Kestus (responseStart - requestStart) on kuulus Time to First Byte (TTFB). Kõrge TTFB on peaaegu alati märk aeglasest taustaprotsessist või serveripoolsest latentsusest.
• responseEnd: Ajatempel, mil ressursi viimane bait on kätte saadud, sulgedes päringu edukalt. Kestus (responseEnd - responseStart) esindab sisu allalaadimisaega.

Ressursi Suuruse Omadused

Ressursi suuruse mõistmine on sama oluline kui ajastuse mõistmine. API pakub kolme peamist mõõdikut:

• transferSize: Võrgu kaudu edastatud ressursi suurus baitides, sealhulgas päised ja tihendatud vastuse keha. Kui ressurss serveeriti vahemälust, on see sageli 0. See on number, mis mõjutab otseselt kasutaja andmesideplaani ja võrguaega.
• encodedBodySize: Andmekoorma keha suurus baitides *pärast* tihendamist (nt Gzip või Brotli), kuid *enne* lahtipakkimist. See aitab teil mõista andmekoorma enda suurust, eraldi päistest.
• decodedBodySize: Andmekoorma keha suurus baitides selle tihendamata, algsel kujul. Selle võrdlemine encodedBodySize-ga näitab teie tihendamisstrateegia tõhusust. Kui need kaks numbrit on tekstipõhise ressursi (nagu JS, CSS või HTML) puhul väga lähedased, ei tööta teie tihendamine tõenäoliselt korrektselt.

Serveri Ajastus

Üks võimsamaid integratsioone Resource Timing API-ga on `serverTiming` omadus. Teie taustsüsteem saab saata jõudlusmõõdikuid spetsiaalses HTTP-päises (`Server-Timing`) ja need mõõdikud ilmuvad vastava `PerformanceResourceTiming` objekti `serverTiming` massiivi. See sildab lõhe esiliidese ja taustsüsteemi jõudluse monitooringu vahel, võimaldades teil näha andmebaasipäringute aegu või API töötlemise viivitusi otse oma esiliidese andmetes.

Näiteks võib taustsüsteem saata sellise päise:

Server-Timing: db;dur=53, api;dur=47.2, cache;desc="HIT"

Need andmed oleksid saadaval `serverTiming` omaduses, võimaldades teil seostada kõrge TTFB konkreetse aeglase protsessiga taustsüsteemis.

Kuidas Pääseda LigResource Timing Andmetele JavaScriptis

Nüüd, kui mõistame saadaolevaid andmeid, vaatame praktilisi viise nende kogumiseks JavaScripti abil. On kaks peamist meetodit.

Meetod 1: `performance.getEntriesByType('resource')`

See on kõige lihtsam viis alustamiseks. See meetod tagastab massiivi kõikidest `PerformanceResourceTiming` objektidest ressurssidele, mis on kutse tegemise hetkel lehel juba laadimise lõpetanud.

            
// Oodake lehe laadimist, et tagada enamiku ressursside püüdmine
window.addEventListener('load', () => {
  const resources = performance.getEntriesByType('resource');

  resources.forEach((resource) => {
    console.log(`Ressurss laaditud: ${resource.name}`);
    console.log(` - Kogu aeg: ${resource.duration.toFixed(2)}ms`);
    console.log(` - Algataja: ${resource.initiatorType}`);
    console.log(` - Ülekande suurus: ${resource.transferSize} baiti`);
  });
});

            

              
                Copy
              
            
          

Piirang: See meetod on hetktõmmis ajas. Kui kutsute selle välja liiga vara, jäävad teil laadimata ressursid märkamata. Kui teie rakendus laadib ressursse dünaamiliselt kaua pärast esialgset lehe laadimist, peaksite seda meetodit korduvalt küsitlema, mis on ebaefektiivne.

Meetod 2: `PerformanceObserver` (Soovitatav Lähenemine)

PerformanceObserver on kaasaegsem, robustsem ja jõudsam viis jõudluskirjete kogumiseks. Selle asemel, et teie andmeid küsitleksite, lükkab brauser uued kirjed teie vaatleja tagasikutse funktsioonile kohe, kui need muutuvad kättesaadavaks.

Siin on, miks see on parem:

• Asünkroonne: See ei blokeeri põhilõime.
• Põhjalik: See suudab püüda kirjeid alates lehe laadimise algusest, vältides võidujooksu tingimusi, kus skript käivitub pärast ressursi juba laadimist.
• Efektiivne: See väldib vajadust küsitleda `setTimeout` või `setInterval` abil.

Siin on standardne implementatsioon:

            
try {
  const observer = new PerformanceObserver((list) => {
    list.getEntries().forEach((entry) => {
      // Töötle iga ressursi kirjet selle saabumisel
      if (entry.entryType === 'resource') {
        console.log(`Vaadeldud ressurss: ${entry.name}`);
        console.log(` - Aeg esimese baidini (TTFB): ${(entry.responseStart - entry.requestStart).toFixed(2)}ms`);
      }
    });
  });

  // Alusta 'resource' kirjete jälgimist.
  // 'buffered' lipp tagab, et saame kätte kirjed, mis laaditi enne meie vaatleja loomist.
  observer.observe({ type: 'resource', buffered: true });

  // Vajadusel saate hiljem jälgimise peatada
  // observer.disconnect();
} catch (e) {
  console.error('PerformanceObserver ei ole selles brauseris toetatud.');
}

            

              
                Copy
              
            
          

buffered: true valik on kriitilise tähtsusega. See käsib vaatlejal kohe edastada kõik `resource` kirjed, mis on juba brauseri jõudluskirjete puhvris, tagades, et saate täieliku nimekirja algusest peale.

Jõudluse Puhvri Haldamine

Brauseritel on vaikimisi piirang, kui palju ressursi ajastuse kirjeid nad salvestavad (tavaliselt 150). Väga keerulistel lehtedel võib see puhver täis saada. Kui see juhtub, käivitab brauser `resourcetimingbufferfull` sündmuse ja uusi kirjeid ei lisata.

Saate seda hallata järgmiselt:

1. Puhvri suuruse suurendamine: Kasutage `performance.setResourceTimingBufferSize(limit)`, et määrata kõrgem limiit, näiteks 300.
2. Puhvri tühjendamine: Kasutage `performance.clearResourceTimings()` pärast kirjete töötlemist, et teha ruumi uutele.

            
performance.addEventListener('resourcetimingbufferfull', () => {
  console.warn('Ressursi ajastuse puhver on täis. Tühjendan...');
  // Kõigepealt töödelge olemasolevad kirjed oma vaatlejast
  // Seejärel tühjendage puhver
  performance.clearResourceTimings();
  // Kui see juhtub sageli, peate võib-olla puhvri suurust uuesti kohandama
  // performance.setResourceTimingBufferSize(500);
});

            

              
                Copy
              
            
          

Praktilised Kasutusjuhud ja Rakendatavad Teadmised

Andmete kogumine on alles esimene samm. Tõeline väärtus seisneb nende andmete muutmisel rakendatavateks parendusteks. Uurime mõningaid levinud jõudlusprobleeme ja seda, kuidas Resource Timing API aitab teil neid lahendada.

Kasutusjuht 1: Aeglaste Kolmandate Osapoolte Skriptide Tuvastamine

Probleem: Kolmandate osapoolte skriptid analüütika, reklaami, klienditoe vidinate ja A/B testimise jaoks on kurikuulsad jõudluse tapjad. Need võivad olla aeglased laadima, blokeerida renderdamist ja isegi põhjustada ebastabiilsust.

Lahendus: Kasutage Resource Timing API-d, et eraldada ja mõõta nende skriptide mõju teie tegelikele kasutajatele.

            
const observer = new PerformanceObserver((list) => {
  const thirdPartyScripts = list.getEntries().filter(entry => 
    entry.initiatorType === 'script' && 
    !entry.name.startsWith(window.location.origin)
  );

  thirdPartyScripts.forEach(script => {
    if (script.duration > 200) { // Määra lävi, nt 200ms
      console.warn(`Tuvastati aeglane kolmanda osapoole skript: ${script.name}`, {
        duration: `${script.duration.toFixed(2)}ms`,
        transferSize: `${script.transferSize} baiti`
      });
      // Tõelises RUM-tööriistas saadaksite need andmed oma analüütika taustsüsteemi.
    }
  });
});

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

            

              
                Copy
              
            
          

Rakendatavad teadmised:

• Kõrge kestus: Kui skriptil on pidevalt pikk kestus, kaaluge, kas see on tõesti vajalik. Kas selle funktsionaalsust saab asendada jõudsama alternatiiviga?
• Laadimisstrateegia: Kas skripti laaditakse sünkroonselt? Kasutage `async` või `defer` atribuute `<script>` sildil, et vältida lehe renderdamise blokeerimist.
• Valikuline hostimine: Kas skripti saab laadida tingimuslikult, ainult nendel lehtedel, kus see on absoluutselt vajalik?

Kasutusjuht 2: Piltide Edastamise Optimeerimine

Probleem: Suured, optimeerimata pildid on üks levinumaid aeglaste lehelaadimiste põhjuseid, eriti piiratud ribalaiusega mobiilseadmetes.

Lahendus: Filtreerige ressursikirjeid `initiatorType: 'img'` järgi ja analüüsige nende suurust ja laadimisaegu.

            
// ... PerformanceObserver tagasikutse funktsiooni sees ...
list.getEntries()
  .filter(entry => entry.initiatorType === 'img')
  .forEach(image => {
    const downloadTime = image.responseEnd - image.responseStart;
    // Suurel pildil võib olla pikk allalaadimisaeg ja suur transferSize
    if (downloadTime > 500 || image.transferSize > 100000) { // 500ms või 100KB
      console.log(`Potentsiaalne suure pildi probleem: ${image.name}`, {
          downloadTime: `${downloadTime.toFixed(2)}ms`,
          transferSize: `${(image.transferSize / 1024).toFixed(2)} KB`
      });
    }
  });

            

              
                Copy
              
            
          

Rakendatavad teadmised:

• Kõrge `transferSize` ja `downloadTime`: See on selge märk, et pilt on liiga suur. Optimeerige seda, kasutades kaasaegseid formaate nagu WebP või AVIF, tihendades seda sobivalt ja muutes selle suurust vastavalt kuvatavatele mõõtmetele.
• Kasutage `srcset`: Rakendage reageerivaid pilte, kasutades `srcset` atribuuti, et serveerida erineva suurusega pilte vastavalt kasutaja vaateaknale.
• Laisk laadimine: Nn "below the fold" piltide jaoks kasutage `loading="lazy"`, et lükata nende laadimine edasi, kuni kasutaja need vaatesse kerib.

Kasutusjuht 3: Võrgu Kitsaskohtade Diagnoosimine

Probleem: Mõnikord ei ole probleemiks ressurss ise, vaid võrgutee selleni. Aeglane DNS, latentsed ühendused või ülekoormatud serverid võivad kõik jõudlust halvendada.

Lahendus: Jaotage `duration` selle koostisosadeks, et tuvastada viivituse allikas.

            
function analyzeNetworkPhases(resource) {
  const dnsTime = resource.domainLookupEnd - resource.domainLookupStart;
  const tcpTime = resource.connectEnd - resource.connectStart;
  const ttfb = resource.responseStart - resource.requestStart;
  const downloadTime = resource.responseEnd - resource.responseStart;

  console.log(`Analüüs ressursile ${resource.name}`);
  if (dnsTime > 50) console.warn(` - Kõrge DNS-aeg: ${dnsTime.toFixed(2)}ms`);
  if (tcpTime > 100) console.warn(` - Kõrge TCP-ühenduse aeg: ${tcpTime.toFixed(2)}ms`);
  if (ttfb > 300) console.warn(` - Kõrge TTFB (aeglane server): ${ttfb.toFixed(2)}ms`);
  if (downloadTime > 500) console.warn(` - Aeglane sisu allalaadimine: ${downloadTime.toFixed(2)}ms`);
}

// ... kutsuge analyzeNetworkPhases(entry) oma vaatleja sees ...

            

              
                Copy
              
            
          

Rakendatavad teadmised:

• Kõrge DNS-aeg: Teie DNS-pakkuja võib olla aeglane. Kaaluge üleminekut kiiremale globaalsele pakkujale. Võite kasutada ka ``, et lahendada kriitiliste kolmandate osapoolte domeenide DNS enne tähtaega.
• Kõrge TCP-aeg: See viitab latentsusele ühenduse loomisel. Sisuedastusvõrk (CDN) võib seda vähendada, serveerides varasid kasutajale geograafiliselt lähemalt asukohast. Kasutades `` saab varakult teha nii DNS-päringu kui ka TCP-kätluse.
• Kõrge TTFB: See viitab aeglasele taustsüsteemile. Tehke koostööd oma taustsüsteemi meeskonnaga, et optimeerida andmebaasipäringuid, parandada serveripoolset vahemälu või uuendada serveri riistvara. `Server-Timing` päis on siin teie parim sõber.
• Kõrge allalaadimisaeg: See on ressursi suuruse ja võrgu ribalaiuse funktsioon. Optimeerige vara (tihendage, minimeerige) või kasutage CDN-i läbilaskevõime parandamiseks.

Piirangud ja Kaalutlused

Kuigi uskumatult võimas, on Resource Timing API-l mõned olulised piirangud, millest tuleb teadlik olla.

Päritoluülesed Ressursid ja `Timing-Allow-Origin` Päis

Turvalisuse kaalutlustel piiravad brauserid ajastusandmete kättesaadavust ressurssidele, mis on laaditud teisest päritolust (domeen, protokoll või port) kui teie põhileht. Vaikimisi on päritoluülese ressursi puhul enamik ajastusomadusi nagu `redirectStart`, `domainLookupStart`, `connectStart`, `requestStart`, `responseStart` ja suurusomadused nagu `transferSize` nullid.

Nende üksikasjade paljastamiseks peab ressurssi majutav server lisama HTTP-päise `Timing-Allow-Origin` (TAO). Näiteks:

Timing-Allow-Origin: * (Lubab igal päritolul ajastusandmeid näha)

Timing-Allow-Origin: https://www.your-website.com (Lubab ainult teie veebisaidil)

See on ülioluline, kui töötate oma CDN-ide või API-dega erinevatel alamdomeenidel. Veenduge, et need on konfigureeritud saatma TAO päist, et saaksite täieliku jõudluse nähtavuse.

Brauseri Tugi

Resource Timing API, sealhulgas `PerformanceObserver`, on laialdaselt toetatud kõigis kaasaegsetes brauserites (Chrome, Firefox, Safari, Edge). Vanemates brauserites ei pruugi see aga saadaval olla. Mähkige oma kood alati `try...catch` plokki või kontrollige `window.PerformanceObserver` olemasolu enne selle kasutamist, et vältida vigu vanematel klientidel.

Kokkuvõte: Andmetest Otsusteni

Resource Timing API on kaasaegse veebiarendaja tööriistakomplekti oluline instrument. See demüstifitseerib võrgu waterfall'i, pakkudes tooreid, granulaarseid andmeid, mis on vajalikud, et liikuda ebamäärastest kaebustest "sait on aeglane" täpsete, andmepõhiste diagnoosideni nagu "meie kolmanda osapoole vestlusvidinal on Kagu-Aasia kasutajate jaoks 400 ms TTFB."

Kasutades `PerformanceObserver`'it reaalsete kasutajate andmete kogumiseks ja analüüsides iga ressursi täielikku elutsüklit, saate:

• Nõuda kolmandate osapoolte pakkujatelt vastutust nende jõudluse eest.
• Valideerida oma CDN-i ja vahemälustrateegiate tõhusust üle maailma.
• Leida ja parandada ülemõõdulisi pilte ja optimeerimata varasid.
• Seostada esiliidese viivitusi taustsüsteemi töötlemisaegadega.

Teekond kiirema veebi poole on pidev. Alustage juba täna. Avage oma brauseri arendajakonsool, käivitage selle artikli koodilõigud oma saidil ja alustage rikkalike jõudlusandmete uurimist, mis on teid kogu aeg oodanud. Mõõtes seda, mis on oluline, saate luua kiiremaid, vastupidavamaid ja nauditavamaid kogemusi kõigile oma kasutajatele, kus iganes nad maailmas ka ei asuks.