Ārpus pulksteņa: Web veiktspējas API savienošana ar reālu lietotāju pieredzi

Digitālajā ekonomikā ātrums nav tikai funkcija; tas ir lietotāju pieredzes pamats. Lēna vietne var novest pie neapmierinātiem lietotājiem, augstākiem atteikumu rādītājiem un tiešas ietekmes uz ieņēmumiem. Gadiem ilgi izstrādātāji ir paļāvušies uz laika metriku, piemēram, window.onload, lai novērtētu veiktspēju. Bet vai ātrs ielādes laiks patiešām nozīmē laimīgu lietotāju? Atbilde bieži vien ir nē.

Lapa var pabeigt visu savu tehnisko resursu ielādi mazāk nekā sekundē, tomēr justies gausa un nelietojama reālam cilvēkam, kurš mēģina ar to mijiedarboties. Šī atšķirība izgaismo kritisku evolūciju web izstrādē: pāreju no tehnisko laiku mērīšanas uz cilvēku pieredzes kvantificēšanu. Mūsdienu web veiktspēja ir stāsts par divām perspektīvām: detalizētiem, zema līmeņa datiem, ko nodrošina Web veiktspējas API, un augsta līmeņa, uz lietotāju orientētai metrikai, piemēram, Google Core Web Vitals.

Šī visaptverošā rokasgrāmata novērsīs šo plaisu. Mēs izpētīsim jaudīgo Web veiktspējas API komplektu, kas darbojas kā mūsu diagnostikas rīki. Pēc tam mēs iedziļināsimies mūsdienu lietotāju pieredzes metrikā, kas mums stāsta, kā veiktspēja *jūtas*. Vissvarīgākais ir tas, ka mēs savienosim punktus, parādot, kā izmantot zema līmeņa laika datus, lai diagnosticētu un novērstu sliktu lietotāju pieredzes cēloņus jūsu globālajai auditorijai.

Pamats: Web veiktspējas API izpratne

Web veiktspējas API ir standartizētu pārlūkprogrammas saskarņu kopa, kas nodrošina izstrādātājiem piekļuvi ļoti detalizētiem un precīziem laika datiem, kas saistīti ar web lapas navigāciju un renderēšanu. Tie ir veiktspējas mērījumu pamats, kas ļauj mums pāriet ārpus vienkāršiem hronometriem un saprast sarežģīto tīkla pieprasījumu, parsēšanas un renderēšanas deju.

Navigācijas laika API: Lapas ceļojums

Navigācijas laika API nodrošina detalizētu sadalījumu par laiku, kas nepieciešams galvenā dokumenta ielādei. Tas uztver atskaites punktus no brīža, kad lietotājs sāk navigāciju (piemēram, noklikšķinot uz saites), līdz brīdim, kad lapa ir pilnībā ielādēta. Šis ir mūsu pirmais un fundamentālākais skatījums uz lapas ielādes procesu.

Jūs varat piekļūt šiem datiem ar vienkāršu JavaScript zvanu:

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

Tas atgriež objektu, kas pārpilns ar laika zīmogiem. Dažas galvenās īpašības ietver:

• fetchStart: Kad pārlūkprogramma sāk dokumenta iegūšanu.
• responseStart: Kad pārlūkprogramma saņem pirmo atbildes baitu no servera. Laiks starp fetchStart un responseStart bieži tiek dēvēts par Time to First Byte (TTFB).
• domContentLoadedEventEnd: Kad sākotnējais HTML dokuments ir pilnībā ielādēts un parsēts, negaidot, kad tiks pabeigtas stila lapas, attēli un apakšrāmji.
• loadEventEnd: Kad visi lapas resursi (ieskaitot attēlus, CSS utt.) ir pilnībā ielādēti.

Ilgstoši loadEventEnd bija zelta standarts. Tomēr tā ierobežojums ir nopietns: tas neko nesaka par to, kad lietotājs *redz* jēgpilnu saturu vai kad viņi var *mijiedarboties* ar lapu. Tas ir tehnisks atskaites punkts, nevis cilvēcisks.

Resursu laika API: Komponentu dekonstrukcija

Web lapa reti ir viens fails. Tas ir HTML, CSS, JavaScript, attēlu, fontu un API zvanu komplekts. Resursu laika API ļauj pārbaudīt tīkla laiku katram no šiem atsevišķajiem resursiem.

Tas ir neticami spēcīgs, lai identificētu vājās vietas. Vai liels, neoptimizēts hero attēls no satura piegādes tīkla (CDN) citā kontinentā palēnina sākotnējo renderēšanu? Vai trešās puses analītikas skripts bloķē galveno pavedienu? Resursu laiks palīdz jums atbildēt uz šiem jautājumiem.

Jūs varat iegūt visu resursu sarakstu šādi:

const resourceEntries = performance.getEntriesByType('resource'); resourceEntries.forEach(resource => { if (resource.duration > 200) { // Atrodiet resursus, kas aizņēma vairāk nekā 200 ms console.log(`Lēns resurss: ${resource.name}, Ilgums: ${resource.duration}ms`); } });

Galvenās īpašības ietver name (resursa URL), initiatorType (kas izraisīja resursa ielādi, piemēram, 'img', 'script') un duration (kopējais laiks, kas nepieciešams tā iegūšanai).

Lietotāju laika API: Jūsu lietojumprogrammas loģikas mērīšana

Dažreiz veiktspējas vājā vieta nav aktīvu ielādē, bet gan klienta puses kodā. Cik ilgs laiks nepieciešams jūsu vienlapas lietojumprogrammai (SPA), lai renderētu sarežģītu komponentu pēc datu saņemšanas no API? Lietotāju laika API ļauj jums izveidot pielāgotus, lietojumprogrammai specifiskus mērījumus.

Tas darbojas ar divām galvenajām metodēm:

• performance.mark(name): Izveido nosauktu laika zīmogu veiktspējas buferī.
• performance.measure(name, startMark, endMark): Aprēķina ilgumu starp divām atzīmēm un izveido nosauktu mērījumu.

Piemērs: Produkta saraksta komponenta renderēšanas laika mērīšana.

// Kad sākat iegūt datus performance.mark('product-list-fetch-start'); fetch('/api/products') .then(response => response.json()) .then(data => { // Pēc iegūšanas, pirms renderēšanas performance.mark('product-list-render-start'); renderProductList(data); // Uzreiz pēc renderēšanas pabeigšanas performance.mark('product-list-render-end'); // Izveidojiet mērījumu performance.measure( 'Product List Render Time', 'product-list-render-start', 'product-list-render-end' ); });

Tas sniedz jums precīzu kontroli, lai izmērītu tās jūsu lietojumprogrammas daļas, kas ir vissvarīgākās lietotāja darbplūsmai.

PerformanceObserver: Mūsdienīga, efektīva pieeja

Pastāvīgi aptaujāt `performance.getEntriesByType()` ir neefektīvi. `PerformanceObserver` API nodrošina daudz labāku veidu, kā klausīties veiktspējas ierakstus. Jūs abonējat noteiktus ierakstu veidus, un pārlūkprogramma asinhroni paziņo jūsu atzvanīšanas funkcijai, kad tie tiek ierakstīti. Šis ir ieteicamais veids, kā apkopot veiktspējas datus, nepievienojot papildu slodzi jūsu lietojumprogrammai.

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

Šis novērotājs ir atslēga, lai apkopotu ne tikai iepriekš minēto tradicionālo metriku, bet arī mūsdienīgu, uz lietotāju orientētu metriku, ko mēs apspriedīsim tālāk.

Pāreja uz lietotāju orientāciju: Core Web Vitals

Zināt, ka lapa ielādēta 2 sekundēs, ir noderīgi, bet tas neatbild uz būtiskiem jautājumiem: Vai lietotājs šīs 2 sekundes skatījās tukšā ekrānā? Vai viņi varēja mijiedarboties ar lapu, vai tā bija iesaldēta? Vai saturs negaidīti pārvietojās, kad viņi mēģināja lasīt?

Lai to risinātu, Google ieviesa Core Web Vitals (CWV), metriku kopumu, kas paredzēts, lai mērītu lapas reālās pasaules lietotāju pieredzi trīs galvenajās dimensijās: ielāde, interaktivitāte un vizuālā stabilitāte.

Largest Contentful Paint (LCP): Uztvertās ielādes mērīšana

LCP mēra lielākā attēla vai teksta bloka renderēšanas laiku, kas redzams skatlodziņā. Tas ir lielisks aizstājējs, lai noteiktu, kad lietotājs jūt, ka ir ielādēts lapas galvenais saturs. Tas tieši atbild uz lietotāja jautājumu: "Vai šī lapa jau ir noderīga?"

• Labi: Zem 2,5 sekundēm
• Nepieciešams uzlabojums: Starp 2,5 s un 4,0 s
• Slikti: Virs 4,0 sekundēm

Atšķirībā no `loadEventEnd`, LCP koncentrējas uz to, ko lietotājs redz vispirms, padarot to par daudz precīzāku uztvertā ielādes ātruma atspoguļojumu.

Interaction to Next Paint (INP): Atsaucības mērīšana

INP ir First Input Delay (FID) pēctecis un kļuva par oficiālu Core Web Vital 2024. gada martā. Lai gan FID mērīja tikai *pirmās* mijiedarbības aizkavi, INP mēra *visu* lietotāju mijiedarbību (klikšķu, pieskārienu, taustiņu nospiešanas) latentumu visā lapas dzīves ciklā. Tas ziņo par garāko mijiedarbību, efektīvi identificējot sliktāko gadījumu atsaucību, ko lietotājs piedzīvo.

INP mēra visu laiku no lietotāja ievades līdz nākamajam rāmim, kas ir uzzīmēts, atspoguļojot vizuālo atgriezenisko saiti. Tas atbild uz lietotāja jautājumu: "Kad es noklikšķinu uz šīs pogas, vai lapa ātri reaģē?"

• Labi: Zem 200 milisekundēm
• Nepieciešams uzlabojums: Starp 200 ms un 500 ms
• Slikti: Virs 500 ms

Augsts INP parasti rodas aizņemta galvenā pavediena dēļ, kur ilgstoši JavaScript uzdevumi neļauj pārlūkprogrammai reaģēt uz lietotāja ievadi.

Cumulative Layout Shift (CLS): Vizuālās stabilitātes mērīšana

CLS mēra lapas vizuālo stabilitāti. Tas kvantificē, cik daudz satura negaidīti pārvietojas ekrānā ielādes procesa laikā. Augsts CLS rādītājs ir biežs lietotāju neapmierinātības avots, piemēram, kad mēģināt noklikšķināt uz pogas, bet virs tās tiek ielādēta reklāma, nospiežot pogu uz leju un liekot jums noklikšķināt uz reklāmas.

CLS atbild uz lietotāja jautājumu: "Vai es varu izmantot šo lapu, neļaujot elementiem lēkāt pa visu vietu?"

• Labi: Zem 0,1
• Nepieciešams uzlabojums: Starp 0,1 un 0,25
• Slikti: Virs 0,25

Bieži augsta CLS cēloņi ir attēli vai iframe bez izmēriem, web fonti tiek ielādēti vēlu vai saturs tiek dinamiski ievadīts lapā, neatvēlot vietu tam.

Tilta veidošana: API izmantošana, lai diagnosticētu sliktu lietotāju pieredzi

Šeit viss saplūst kopā. Core Web Vitals mums stāsta, *ko* lietotājs piedzīvoja (piemēram, lēnu LCP). Web veiktspējas API mums stāsta, *kāpēc* tas notika. Apvienojot tos, mēs pārvēršamies no vienkāršas veiktspējas novērošanas par tās aktīvu diagnosticēšanu un labošanu.

Lēna LCP diagnosticēšana

Iedomājieties, ka jūsu reāllaika lietotāju uzraudzības (RUM) rīks ziņo par sliktu LCP 4,5 sekundes lietotājiem noteiktā reģionā. Kā to labot? Jums ir jāsadala LCP laiks tā sastāvdaļās.

1. Time to First Byte (TTFB): Vai serveris lēni reaģē? Izmantojiet Navigācijas laika API. Ilgums `responseStart - requestStart` sniedz jums precīzu TTFB. Ja tas ir augsts, problēma ir jūsu aizmugursistēmā, servera konfigurācijā vai datubāzē, nevis priekšpusē.
2. Resursu ielādes aizkave un laiks: Vai pats LCP elements ielādējas lēni? Vispirms identificējiet LCP elementu (piemēram, hero attēlu). Jūs varat izmantot `PerformanceObserver` priekš `'largest-contentful-paint'`, lai iegūtu pašu elementu. Pēc tam izmantojiet Resursu laika API, lai atrastu ierakstu šī elementa URL. Analizējiet tā laika līniju: Vai bija ilgs `connectStart` līdz `connectEnd` (lēns tīkls)? Vai `responseStart` līdz `responseEnd` bija garš (milzīgs faila izmērs)? Vai tā `fetchStart` tika aizkavēts, jo to bloķēja citi renderēšanas bloķēšanas resursi, piemēram, CSS vai JavaScript?
3. Elementu renderēšanas aizkave: Šis ir laiks pēc tam, kad resurss pabeidz ielādi, līdz tas faktiski tiek uzzīmēts ekrānā. To var izraisīt tas, ka galvenais pavediens ir aizņemts ar citiem uzdevumiem, piemēram, liela JavaScript pakotnes izpildi.

Izmantojot navigācijas un resursu laiku, jūs varat precīzi noteikt, vai lēns LCP ir lēna servera, renderēšanas bloķēšanas skripta vai milzīga, neoptimizēta attēla dēļ.

Slikta INP izpēte

Jūsu lietotāji sūdzas, ka klikšķis uz pogas "Pievienot grozam" šķiet lēns. Jūsu INP metrika ir diapazonā "Slikti". Tas gandrīz vienmēr ir galvenā pavediena problēma.

1. Identificējiet ilgus uzdevumus: Ilgstošu uzdevumu API ir jūsu galvenais rīks šeit. Tas ziņo par jebkuru uzdevumu galvenajā pavedienā, kas aizņem vairāk nekā 50 ms, jo jebkas ilgāks var radīt ievērojamu kavēšanos lietotājam. Iestatiet `PerformanceObserver`, lai klausītos `'longtask'` ierakstus.
2. Korelējiet ar lietotāju darbībām: Ilgs uzdevums ir problēma tikai tad, ja tas notiek, kad lietotājs mēģina mijiedarboties. Jūs varat korelēt INP notikuma `startTime` (novērots, izmantojot `PerformanceObserver` tipam `'event'`) ar jebkuru ilgu uzdevumu laiku, kas notika ap to pašu laiku. Tas precīzi pasaka, kura JavaScript funkcija bloķēja lietotāja mijiedarbību.
3. Mēriet specifiskus apstrādātājus: Izmantojiet Lietotāju laika API, lai iegūtu vēl detalizētāku informāciju. Aptiniet savus kritiskos notikumu apstrādātājus (piemēram, pogas "Pievienot grozam" klikšķa apstrādātāju) ar `performance.mark()` un `performance.measure()`. Tas precīzi pateiks, cik ilgs laiks nepieciešams jūsu pašu koda izpildei un vai tas ir ilgā uzdevuma avots.

Augsta CLS risināšana

Lietotāji ziņo, ka teksts lēkā apkārt, lasot rakstu savās mobilajās ierīcēs. Jūsu CLS rādītājs ir 0,3.

1. Novērojiet izkārtojuma pārbīdes: Izmantojiet `PerformanceObserver`, lai klausītos `'layout-shift'` ierakstus. Katram ierakstam būs `value` (tā ieguldījums CLS rādītājā) un `sources` saraksts, kas ir DOM elementi, kas pārvietojās. Tas pasaka *ko* pārvietojās.
2. Atrodiet vainīgo resursu: Nākamais jautājums ir *kāpēc* tas pārvietojās. Biežs iemesls ir resursa ielāde vēlu un cita satura spiešana uz leju. Jūs varat korelēt `startTime` no `layout-shift` ieraksta ar `responseEnd` laiku no ierakstiem no Resursu laika API. Ja izkārtojuma pārbīde notiek tūlīt pēc tam, kad ir pabeigta reklāmas skripta vai liela attēla ielāde, jūs, iespējams, esat atradis savu vainīgo.
3. Proaktīvi risinājumi: Labojums bieži ietver attēlu un reklāmu izmēru nodrošināšanu (``) vai vietas rezervēšanu lapā dinamiskam saturam pirms tā ielādes. Resursu laiks palīdz jums identificēt, par kuriem resursiem jums jābūt proaktīvam.

Praktiska ieviešana: Globālas uzraudzības sistēmas izveide

Izpratne par šīm API ir viena lieta; to izvietošana, lai uzraudzītu jūsu globālās lietotāju bāzes pieredzi, ir nākamais solis. Šī ir reāllaika lietotāju uzraudzības (RUM) joma.

Apvienojot visu ar `PerformanceObserver`

Jūs varat izveidot vienu, jaudīgu skriptu, lai apkopotu visus šos būtiskos datus. Mērķis ir apkopot metriku un to kontekstu, neietekmējot veiktspēju, kuru mēģināt izmērīt.

Šeit ir robusta novērotāja iestatījuma konceptuāls fragments:

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') { // Šis ir vienkāršots INP aprēķina skatījums const duration = entry.duration; if (duration > (collectedMetrics.inp || 0)) { collectedMetrics.inp = duration; } } // ... un tā tālāk citiem ierakstu veidiem, piemēram, 'longtask' } }); observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });

Datu droša sūtīšana

Kad esat apkopojis savus datus, jums tie jānosūta uz analītikas aizmugursistēmu, lai tos uzglabātu un analizētu. Ir svarīgi to darīt, nekavējot lapas izkraušanu vai nezaudējot datus no lietotājiem, kuri ātri aizver savas cilnes.

`navigator.sendBeacon()` API ir lieliski piemērots šim nolūkam. Tas nodrošina uzticamu, asinhronu veidu, kā nosūtīt nelielu datu apjomu uz serveri, pat ja lapa tiek izkrauta. Tas negaida atbildi, padarot to vieglu un nebloķējošu.

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

Globāla skatījuma nozīme

Laboratorijas testēšanas rīki, piemēram, Lighthouse, ir nenovērtējami, bet tie darbojas kontrolētā vidē. RUM dati, kas apkopoti no šīm API, sniedz jums patiesu priekšstatu par to, ko jūsu lietotāji piedzīvo dažādās valstīs, tīkla apstākļos un ierīcēs.

Analizējot savus datus, vienmēr segmentējiet tos. Jūs varat atklāt, ka:

• Jūsu LCP ir lielisks lietotājiem Ziemeļamerikā, bet slikts lietotājiem Austrālijā, jo jūsu primārais attēlu serveris atrodas ASV.
• Jūsu INP ir augsts vidējas klases Android ierīcēs, kas ir populāras jaunattīstības tirgos, jo jūsu JavaScript tām ir pārāk CPU intensīvs.
• Jūsu CLS ir problēma tikai noteiktos ekrāna izmēros, kur CSS multivides vaicājums izraisa reklāmas nepareizu izmēru maiņu.

Šis segmentētā ieskata līmenis ļauj jums noteikt prioritātes optimizācijai, kas visvairāk ietekmēs jūsu faktisko lietotāju bāzi, lai kur viņi atrastos.

Secinājums: No mērījumiem līdz meistarībai

Web veiktspējas pasaule ir nobriedusi. Mēs esam pārgājuši no vienkāršiem tehniskiem laikiem uz sarežģītu izpratni par lietotāja uztverto pieredzi. Ceļojums ietver trīs galvenos soļus:

1. Mēriet pieredzi: Izmantojiet `PerformanceObserver`, lai apkopotu Core Web Vitals (LCP, INP, CLS). Tas jums pasaka, *kas* notiek un *kā tas jūtas* lietotājam.
2. Diagnosticējiet cēloni: Izmantojiet pamata laika API (Navigācija, Resurss, Lietotājs, Ilgi uzdevumi), lai iedziļinātos. Tas jums pasaka, *kāpēc* pieredze ir slikta.
3. Rīkojieties precīzi: Izmantojiet apvienotos datus, lai veiktu apzinātas, mērķtiecīgas optimizācijas, kas risina problēmas cēloni konkrētiem lietotāju segmentiem.

Apgūstot gan augsta līmeņa lietotāju metriku, gan zema līmeņa diagnostikas API, jūs varat izveidot holistisku veiktspējas stratēģiju. Jūs pārtraucat minēt un sākat izstrādāt web pieredzi, kas ir ne tikai tehniski ātra, bet arī tāda, kas jūtas ātra, atsaucīga un patīkama katram lietotājam, katrā ierīcē, visā pasaulē.