Enam kui kell: Veebi jõudluse API-de ühendamine reaalse kasutuskogemusega

Digitaalses majanduses pole kiirus lihtsalt funktsioon; see on kasutuskogemuse alus. Aeglane veebisait võib viia pettunud kasutajateni, kõrgema põrkemäärani ja otsese mõjuni tuludele. Aastaid on arendajad jõudluse hindamiseks tuginenud ajastusmõõdikutele nagu window.onload. Aga kas kiire laadimisaeg võrdub tõeliselt õnneliku kasutajaga? Vastus on sageli ei.

Leht võib lõpetada kõigi oma tehniliste ressursside laadimise vähem kui sekundiga, kuid tunduda reaalsele inimesele, kes üritab sellega suhelda, aeglane ja kasutamiskõlbmatu. See lahknevus toob esile veebiarenduse kriitilise arengu: ülemineku tehniliste ajastuste mõõtmiselt inimkogemuse kvantifitseerimisele. Kaasaegne veebi jõudlus on lugu kahest vaatenurgast: veebi jõudluse API-de pakutavad detailsed, madala taseme andmed ja kõrgetasemelised, kasutajakesksed mõõdikud nagu Google'i Core Web Vitals.

See põhjalik juhend ületab selle lõhe. Me uurime võimsat veebi jõudluse API-de komplekti, mis toimivad meie diagnostiliste tööriistadena. Seejärel süveneme kaasaegsetesse kasutuskogemuse mõõdikutesse, mis ütlevad meile, kuidas jõudlus *tundub*. Kõige tähtsam on, et me ühendame punktid, näidates teile, kuidas kasutada madala taseme ajastusandmeid, et diagnoosida ja parandada oma globaalse vaatajaskonna kehva kasutuskogemuse algpõhjuseid.

Alus: Veebi jõudluse API-de mõistmine

Veebi jõudluse API-d on standardiseeritud brauseriliideste komplekt, mis annab arendajatele juurdepääsu väga detailsetele ja täpsetele ajastusandmetele, mis on seotud veebilehe navigeerimise ja renderdamisega. Need on jõudluse mõõtmise aluseks, võimaldades meil liikuda lihtsatest stopperitest kaugemale ja mõista võrgupäringute, parsingu ja renderdamise keerukat tantsu.

Navigeerimise ajastuse API: Lehe teekond

Navigeerimise ajastuse API pakub detailset jaotust aja kohta, mis kulub põhifaili laadimiseks. See jäädvustab verstaposte hetkest, kui kasutaja algatab navigeerimise (nagu lingile klõpsamine) kuni hetkeni, kui leht on täielikult laaditud. See on meie esimene ja kõige olulisem vaade lehe laadimisprotsessile.

Saate nendele andmetele juurde pääseda lihtsa JavaScripti kõnega:

const navigationEntry = performance.getEntriesByType('navigation')[0]; console.log(navigationEntry.toJSON());

See tagastab ajatemplitega tulvil objekti. Mõned peamised omadused on järgmised:

• fetchStart: Millal brauser alustab dokumendi toomist.
• responseStart: Millal brauser saab serverilt vastuse esimese baidi. Aeg fetchStart ja responseStart vahel viitab sageli esimese baidi ajale (TTFB).
• domContentLoadedEventEnd: Millal on esialgne HTML-dokument täielikult laaditud ja parseldatud, ootamata stiililehtede, piltide ja alamkaadrite laadimise lõpetamist.
• loadEventEnd: Millal on kõik lehe ressursid (sh pildid, CSS jne) täielikult laaditud.

Pikka aega oli loadEventEnd kuldstandard. Selle piirang on aga tõsine: see ei ütle midagi selle kohta, millal kasutaja *näeb* tähendusrikast sisu või millal ta saab lehega *suhelda*. See on tehniline verstapost, mitte inimlik.

Ressursi ajastuse API: Komponentide dekonstrueerimine

Veebileht on harva üksik fail. See on HTML-i, CSS-i, JavaScripti, piltide, fontide ja API-de kutsete komplekt. Ressursi ajastuse API võimaldab teil kontrollida igaüks nende üksikute ressursside võrguajastust.

See on väga võimas kitsaskohtade tuvastamiseks. Kas suur, optimeerimata kangelaspilt teiselt mandrilt pärit sisuedastusvõrgust (CDN) aeglustab esialgset renderdamist? Kas kolmanda osapoole analüüsiskript blokeerib põhivoogu? Ressursi ajastus aitab teil nendele küsimustele vastata.

Saate kõigi ressursside loendi järgmiselt:

const resourceEntries = performance.getEntriesByType('resource'); resourceEntries.forEach(resource => { if (resource.duration > 200) { // Find resources that took longer than 200ms console.log(`Slow resource: ${resource.name}, Duration: ${resource.duration}ms`); } });

Peamised omadused on name (ressursi URL), initiatorType (mis põhjustas ressursi laadimise, nt 'img', 'script') ja duration (koguaeg, mis kulus selle toomiseks).

Kasutaja ajastuse API: Rakenduse loogika mõõtmine

Mõnikord pole jõudluse kitsaskoht varade laadimises, vaid kliendipoolses koodis endas. Kui kaua võtab teie ühe lehe rakendusel (SPA) aega keeruka komponendi renderdamiseks pärast API-lt andmete saamist? Kasutaja ajastuse API võimaldab teil luua kohandatud rakendusespetsiifilisi mõõtmisi.

See töötab kahe peamise meetodiga:

• performance.mark(name): Loob jõudluse puhvris nimega ajatempli.
• performance.measure(name, startMark, endMark): Arvutab kestuse kahe märgi vahel ja loob nimega mõõtmise.

Näide: Tooteloendi komponendi renderdamisaja mõõtmine.

// When you start fetching data performance.mark('product-list-fetch-start'); fetch('/api/products') .then(response => response.json()) .then(data => { // After fetching, before rendering performance.mark('product-list-render-start'); renderProductList(data); // Immediately after rendering is complete performance.mark('product-list-render-end'); // Create a measure performance.measure( 'Product List Render Time', 'product-list-render-start', 'product-list-render-end' ); });

See annab teile täpse kontrolli, et mõõta neid rakenduse osi, mis on kasutaja töövoo jaoks kõige olulisemad.

PerformanceObserver: Kaasaegne, tõhus lähenemine

Pidev küsitlus `performance.getEntriesByType()` on ebaefektiivne. `PerformanceObserver` API pakub palju paremat viisi jõudluse kirjeid kuulata. Te tellite konkreetseid kirjetüüpe ja brauser teavitab teie tagasikutsumisfunktsiooni asünkroonselt nende salvestamisel. See on soovitatav viis jõudlusandmete kogumiseks, ilma et see teie rakendusele lisakoormust lisaks.

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log(`Entry Type: ${entry.entryType}, Name: ${entry.name}`); } }); observer.observe({ entryTypes: ['resource', 'navigation', 'mark', 'measure'] });

See vaatleja on võti mitte ainult ülaltoodud traditsiooniliste mõõdikute kogumiseks, vaid ka kaasaegsete kasutajakesksete mõõdikute kogumiseks, mida me järgmisena arutame.

Üleminek kasutajakesksusele: Core Web Vitals

Teades, et leht laaditi 2 sekundiga, on kasulik, kuid see ei vasta olulistele küsimustele: Kas kasutaja vahtis need 2 sekundit tühja ekraani? Kas nad said lehega suhelda või oli see külmunud? Kas sisu hüppas ootamatult ringi, kui nad üritasid lugeda?

Sellega tegelemiseks tutvustas Google Core Web Vitalsi (CWV), mõõdikute komplekti, mis on loodud lehe reaalse kasutuskogemuse mõõtmiseks kolmes peamises dimensioonis: laadimine, interaktiivsus ja visuaalne stabiilsus.

Suurima sisuelemendi renderdusaeg (LCP): tajutava laadimise mõõtmine

LCP mõõdab suurima pildi või tekstiploki renderdamise aega, mis on vaateväljas nähtav. See on suurepärane puhver sellele, millal kasutaja tunneb, et lehe peamine sisu on laaditud. See vastab otse kasutaja küsimusele: "Kas see leht on juba kasulik?"

• Hea: Alla 2,5 sekundi
• Vajab parandamist: 2,5 s ja 4,0 s vahel
• Kehv: Üle 4,0 sekundi

Erinevalt `loadEventEndist` keskendub LCP sellele, mida kasutaja esimesena näeb, muutes selle tajutava laadimiskiiruse palju täpsemaks peegelduseks.

Interaktsioon järgmise värvimiseni (INP): Reageerimisvõime mõõtmine

INP on First Input Delay (FID) järeltulija ja sai ametlikuks Core Web Vitaliks 2024. aasta märtsis. Kuigi FID mõõtis ainult *esimese* interaktsiooni viivitust, mõõdab INP *kõigi* kasutajainteraktsioonide (klõpsud, puudutused, klahvivajutused) latentsust kogu lehe elutsükli jooksul. See teatab pikimast interaktsioonist, tuvastades tegelikult halvima reageerimisvõime, mida kasutaja kogeb.

INP mõõdab kogu aega kasutaja sisendist kuni järgmise kaadri värvimiseni, kajastades visuaalset tagasisidet. See vastab kasutaja küsimusele: "Kui ma sellel nupul klõpsan, kas leht reageerib kiiresti?"

• Hea: Alla 200 millisekundi
• Vajab parandamist: 200 ms ja 500 ms vahel
• Kehv: Üle 500 ms

Kõrge INP on tavaliselt põhjustatud hõivatud põhivoost, kus pikaajalised JavaScripti ülesanded takistavad brauseril kasutaja sisendile reageerimist.

Kumulatiivne paigutuse nihkumine (CLS): Visuaalse stabiilsuse mõõtmine

CLS mõõdab lehe visuaalset stabiilsust. See kvantifitseerib, kui palju sisu laadimisprotsessi ajal ootamatult ekraanil ringi liigub. Kõrge CLS-i skoor on tavaline kasutajate frustratsiooni allikas, näiteks kui proovite klõpsata nupul, kuid reklaam laaditakse selle kohale, lükates nuppu alla ja põhjustades reklaamil klõpsamist.

CLS vastab kasutaja küsimusele: "Kas ma saan seda lehte kasutada ilma, et elemendid kõikjal ringi hüppaksid?"

• Hea: Alla 0,1
• Vajab parandamist: 0,1 ja 0,25 vahel
• Kehv: Üle 0,25

Kõrge CLS-i tavalised põhjused on pildid või iframes ilma mõõtmeteta, hilja laaditavad veebifondid või sisu, mis süstitakse dünaamiliselt lehele, ilma et selle jaoks ruumi reserveeritaks.

Lõhe ületamine: API-de kasutamine kehva kasutuskogemuse diagnoosimiseks

Siin saab kõik kokku. Core Web Vitals ütleb meile, *mida* kasutaja koges (nt aeglane LCP). Veebi jõudluse API-d ütlevad meile, *miks* see juhtus. Neid kombineerides muutume lihtsalt jõudluse vaatlemisest selle aktiivseks diagnoosimiseks ja parandamiseks.

Aeglase LCP diagnoosimine

Kujutage ette, et teie reaalajas kasutajaseire (RUM) tööriist teatab kehvast LCP-st 4,5 sekundit konkreetse piirkonna kasutajate jaoks. Kuidas seda parandada? Peate LCP-aja jagama selle koostisosadeks.

1. Aeg esimese baidini (TTFB): Kas server reageerib aeglaselt? Kasutage Navigeerimise ajastuse API-t. Kestus `responseStart - requestStart` annab teile täpse TTFB. Kui see on kõrge, on probleem teie taustaprogrammis, serveri konfiguratsioonis või andmebaasis, mitte esiotsas.
2. Ressursi laadimise viivitus ja aeg: Kas LCP-element ise laaditakse aeglaselt? Esmalt tuvastage LCP-element (nt kangelaspilt). Elemendi enda saamiseks saate kasutada `PerformanceObserverit` `'largest-contentful-paint'` jaoks. Seejärel kasutage Ressursi ajastuse API-t, et leida selle elemendi URL-i kirje. Analüüsige selle ajaskaalat: Kas oli pikk `connectStart` kuni `connectEnd` (aeglane võrk)? Kas `responseStart` kuni `responseEnd` oli pikk (hiiglaslik failimaht)? Kas selle `fetchStart` viibis, sest seda blokeerisid muud renderdamist blokeerivad ressursid nagu CSS või JavaScript?
3. Elemendi renderdamise viivitus: See on aeg pärast ressursi laadimise lõpetamist kuni selle tegeliku ekraanile värvimiseni. Selle põhjuseks võib olla põhivoo hõivatus muude ülesannetega, näiteks suure JavaScripti komplekti käivitamine.

Navigeerimise ja ressursi ajastuse abil saate kindlaks teha, kas aeglane LCP on tingitud aeglasest serverist, renderdamist blokeerivast skriptist või massiivsest optimeerimata pildist.

Kehv INP uurimine

Teie kasutajad kurdavad, et nupule "Lisa ostukorvi" klõpsamine tundub aeglane. Teie INP mõõdik on vahemikus "Kehv". See on peaaegu alati põhivoo probleem.

1. Tuvastage pikad ülesanded: Pikkade ülesannete API on siin teie peamine tööriist. See teatab kõigist põhivoo ülesannetest, mis võtavad kauem kui 50 ms, kuna mis tahes pikem aeg seab ohtu kasutaja jaoks märgatava viivituse. Seadistage `PerformanceObserver`, et kuulata `'longtask'` kirjeid.
2. Korrelatsioon kasutaja toimingutega: Pikk ülesanne on probleem ainult siis, kui see toimub siis, kui kasutaja üritab suhelda. Saate korreleerida INP sündmuse `startTime` (vaadelduna `PerformanceObserveri` kaudu `'event'` tüübis) mis tahes pikkade ülesannete ajastusega, mis toimusid umbes samal ajal. See ütleb teile täpselt, milline JavaScripti funktsioon blokeeris kasutaja interaktsiooni.
3. Mõõtke konkreetseid käitlejaid: Kasutage Kasutaja ajastuse API-t, et saada veelgi detailsust. Mähkige oma kriitilised sündmuse käitlejad (nagu nupu "Lisa ostukorvi" klõpsukäitleja) funktsioonidega `performance.mark()` ja `performance.measure()`. See ütleb teile täpselt, kui kaua teie enda koodi käivitamine aega võtab ja kas see on pika ülesande allikas.

Kõrge CLS lahendamine

Kasutajad teatavad, et tekst hüppab ringi, kui nad loevad oma mobiilseadmetes artiklit. Teie CLS-i skoor on 0,3.

1. Jälgige paigutuse nihkeid: Kasutage `PerformanceObserverit`, et kuulata `'layout-shift'` kirjeid. Igal kirjel on `value` (selle panus CLS-i skoori) ja `sources` loend, mis on DOM-i elemendid, mis liikusid. See ütleb teile, *mis* liikus.
2. Leidke süüdlane ressurss: Järgmine küsimus on *miks* see liikus. Tavaline põhjus on hilja laaditav ressurss, mis lükkab muu sisu alla. Saate korreleerida `layout-shift` kirje `startTime` Ressursi ajastuse API kirjete `responseEnd` ajaga. Kui paigutuse nihe juhtub kohe pärast reklaamiskripti või suure pildi laadimise lõpetamist, olete tõenäoliselt leidnud oma süüdlase.
3. Ennetavad lahendused: Parandus hõlmab sageli piltidele ja reklaamidele mõõtmete esitamist (``) või dünaamilise sisu jaoks lehel ruumi reserveerimist enne selle laadimist. Ressursi ajastus aitab teil tuvastada, milliste ressursside suhtes peate olema ennetav.

Praktiline rakendamine: Globaalse seiresüsteemi ehitamine

Nende API-de mõistmine on üks asi; nende juurutamine oma globaalse kasutajabaasi kogemuse jälgimiseks on järgmine samm. See on reaalajas kasutajaseire (RUM) valdkond.

Kõige kokkupanek funktsiooniga `PerformanceObserver`

Saate luua ühe võimsa skripti, et koguda kõik need olulised andmed. Eesmärk on koguda mõõdikud ja nende kontekst, mõjutamata jõudlust, mida proovite mõõta.

Siin on tugeva vaatleja seadistuse kontseptuaalne katkend:

const collectedMetrics = {}; const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.entryType === 'largest-contentful-paint') { collectedMetrics.lcp = entry.startTime; } else if (entry.entryType === 'layout-shift') { collectedMetrics.cls = (collectedMetrics.cls || 0) + entry.value; } else if (entry.entryType === 'event') { // This is a simplified view of INP calculation const duration = entry.duration; if (duration > (collectedMetrics.inp || 0)) { collectedMetrics.inp = duration; } } // ... and so on for other entry types like 'longtask' } }); observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });

Andmete usaldusväärne saatmine

Kui olete oma andmed kogunud, peate need saatma analüütika taustaprogrammile salvestamiseks ja analüüsimiseks. On ülioluline teha seda ilma lehe laadimise tühistamist viivitamata või kaotamata andmeid kasutajatelt, kes oma vahekaardid kiiresti sulgevad.

`navigator.sendBeacon()` API on selleks ideaalne. See pakub usaldusväärset asünkroonset viisi väikese andmehulga serverisse saatmiseks, isegi kui leht on laadimas. See ei oota vastust, muutes selle kergeks ja blokeerimatuks.

window.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') { const payload = JSON.stringify(collectedMetrics); navigator.sendBeacon('/api/performance-analytics', payload); } });

Globaalse vaate tähtsus

Laboritestimise tööriistad nagu Lighthouse on hindamatud, kuid need töötavad kontrollitud keskkonnas. Nende API-de abil kogutud RUM-andmed ütlevad teile, milline on teie kasutajate tegelik kogemus erinevates riikides, võrgutingimustes ja seadmetes.

Andmete analüüsimisel segmenteerige need alati. Võite avastada, et:

• Teie LCP on Põhja-Ameerika kasutajate jaoks suurepärane, kuid Austraalia kasutajate jaoks kehv, sest teie peamine pildiserver asub USAs.
• Teie INP on kõrge keskmise taseme Androidi seadmetes, mis on populaarsed arenevatel turgudel, sest teie JavaScript on nende jaoks liiga CPU-mahukas.
• Teie CLS on probleem ainult konkreetsetes ekraanisuurustes, kus CSS-i meediapäring põhjustab reklaami vale suuruse muutmise.

See segmenteeritud ülevaate tase võimaldab teil seada prioriteediks optimeerimised, millel on kõige olulisem mõju teie tegelikule kasutajabaasile, kus iganes nad ka poleks.

Järeldus: Mõõtmisest meisterlikkuseni

Veebi jõudluse maailm on küpsenud. Oleme liikunud lihtsatest tehnilistest ajastustest kasutaja tajutava kogemuse keerukama mõistmiseni. Teekond hõlmab kolme peamist sammu:

1. Mõõtke kogemust: Kasutage `PerformanceObserverit`, et koguda Core Web Vitalid (LCP, INP, CLS). See ütleb teile, *mis* toimub ja *kuidas see tundub* kasutajale.
2. Diagnoosige põhjus: Kasutage põhjalikke ajastus API-sid (navigeerimine, ressurss, kasutaja, pikad ülesanded), et sügavamale kaevata. See ütleb teile, *miks* kogemus on kehv.
3. Tegutsege täpselt: Kasutage kombineeritud andmeid, et teha teadlikke, suunatud optimeerimisi, mis lahendavad probleemi algpõhjuse konkreetsete kasutajasegmentide jaoks.

Valdades nii kõrgetasemelisi kasutajamõõdikuid kui ka madala taseme diagnostika API-sid, saate luua tervikliku jõudlusstrateegia. Te lõpetate oletamise ja alustate veebikogemuse kujundamist, mis pole mitte ainult tehniliselt kiire, vaid ka tundub kiire, reageeriv ja meeldiv igale kasutajale, igas seadmes, kõikjal maailmas.