Už laikrodžio ribų: žiniatinklio našumo API sujungimas su realia vartotojo patirtimi

Skaitmeninėje ekonomikoje greitis yra ne tik funkcija; tai vartotojo patirties pagrindas. Lėta svetainė gali sukelti nusivylusių vartotojų, didesnį atmetimo rodiklį ir tiesioginį poveikį pajamoms. Ilgus metus kūrėjai rėmėsi laiko metrika, pvz., window.onload, norėdami įvertinti našumą. Bet ar greitas įkėlimo laikas iš tikrųjų prilygsta laimingam vartotojui? Atsakymas dažnai yra neigiamas.

Puslapis gali baigti krauti visus techninius išteklius per mažiau nei sekundę, tačiau realiam žmogui, bandančiam su juo bendrauti, gali atrodyti lėtas ir netinkamas naudoti. Šis atjungimas pabrėžia kritinę žiniatinklio kūrimo evoliuciją: perėjimą nuo techninio laiko matavimo prie žmogaus patirties kiekybinio įvertinimo. Šiuolaikinis žiniatinklio našumas yra dviejų perspektyvų pasakojimas: smulkūs, žemo lygio duomenys, kuriuos pateikia žiniatinklio našumo API, ir aukšto lygio, į vartotoją orientuotos metrikos, pvz., „Google“ pagrindiniai žiniatinklio rodikliai.

Šis išsamus vadovas užpildys šią spragą. Mes išnagrinėsime galingą žiniatinklio našumo API rinkinį, kuris veikia kaip mūsų diagnostikos įrankiai. Tada mes gilinsimės į šiuolaikines vartotojo patirties metrikas, kurios parodo, kaip našumas *jaučiasi*. Svarbiausia, kad mes sujungsim taškus ir parodysim, kaip naudoti žemo lygio laiko duomenis, kad diagnozuotumėte ir ištaisytumėte prastos vartotojo patirties jūsų pasaulinei auditorijai priežastis.

Pagrindas: žiniatinklio našumo API supratimas

Žiniatinklio našumo API yra standartizuotų naršyklės sąsajų rinkinys, suteikiantis kūrėjams prieigą prie labai išsamių ir tikslių laiko duomenų, susijusių su žiniatinklio puslapio naršymu ir atvaizdavimu. Jie yra našumo matavimo pagrindas, leidžiantis mums peržengti paprastus chronometrus ir suprasti sudėtingą tinklo užklausų, analizės ir atvaizdavimo šokį.

Naršymo laiko API: Puslapio kelionė

Naršymo laiko API pateikia išsamią informaciją apie laiką, kurio reikia pagrindiniam dokumentui įkelti. Jis fiksuoja etapus nuo to momento, kai vartotojas inicijuoja naršymą (pvz., spustelėjęs nuorodą), iki to momento, kai puslapis yra visiškai įkeltas. Tai yra pirmasis ir svarbiausias mūsų žvilgsnis į puslapio įkėlimo procesą.

Galite pasiekti šiuos duomenis naudodami paprastą „JavaScript“ skambutį:

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

Tai grąžina objektą, pilną laiko žymų. Kai kurios pagrindinės savybės yra šios:

• fetchStart: Kai naršyklė pradeda gauti dokumentą.
• responseStart: Kai naršyklė gauna pirmąjį atsakymo baitą iš serverio. Laikas tarp fetchStart ir responseStart dažnai vadinamas laiku iki pirmojo baito (TTFB).
• domContentLoadedEventEnd: Kai pradinis HTML dokumentas buvo visiškai įkeltas ir išanalizuotas, nelaukiant, kol bus baigtas įkelti stiliaus lapai, paveikslėliai ir subkadrai.
• loadEventEnd: Kai visi puslapio ištekliai (įskaitant paveikslėlius, CSS ir kt.) buvo visiškai įkelti.

Ilgą laiką loadEventEnd buvo auksinis standartas. Tačiau jo apribojimas yra didelis: jis nieko nesako apie tai, kada vartotojas *mato* prasmingą turinį arba kada gali *bendradarbiauti* su puslapiu. Tai techninis etapas, o ne žmogaus etapas.

Išteklių laiko API: komponentų išardymas

Žiniatinklio puslapis retai būna vienas failas. Tai HTML, CSS, JavaScript, paveikslėlių, šriftų ir API skambučių rinkinys. Išteklių laiko API leidžia jums patikrinti tinklo laiką kiekvienam iš šių atskirų išteklių.

Tai neįtikėtinai galinga nustatant kliūtis. Ar didelis, neoptimizuotas didvyrio vaizdas iš turinio pristatymo tinklo (CDN) kitame žemyne lėtina pradinį atvaizdavimą? Ar trečiosios šalies analizės scenarijus blokuoja pagrindinį siūlą? Išteklių laikas padeda atsakyti į šiuos klausimus.

Galite gauti visų išteklių sąrašą taip:

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`); } });

Pagrindinės savybės apima name (ištekliaus URL), initiatorType (kas sukėlė išteklių įkėlimą, pvz., „img“, „script“) ir duration (visas laikas, sugaištas jam gauti).

Vartotojo laiko API: jūsų programos logikos matavimas

Kartais našumo kliūtis slypi ne įkeliant turtą, bet pačiame kliento pusės kode. Kiek laiko užtrunka jūsų vieno puslapio programai (SPA) atvaizduoti sudėtingą komponentą gavus duomenis iš API? Vartotojo laiko API leidžia jums sukurti pasirinktinius, programai būdingus matavimus.

Ji veikia su dviem pagrindiniais metodais:

• performance.mark(name): Sukuria pavadintą laiko žymą našumo buferyje.
• performance.measure(name, startMark, endMark): Apskaičiuoja trukmę tarp dviejų žymų ir sukuria pavadintą matavimą.

Pavyzdys: Produkto sąrašo komponento atvaizdavimo laiko matavimas.

// Kai pradedate gauti duomenis performance.mark('product-list-fetch-start'); fetch('/api/products') .then(response => response.json()) .then(data => { // Po gavimo, prieš atvaizduojant performance.mark('product-list-render-start'); renderProductList(data); // Iškart po to, kai atvaizdavimas bus baigtas performance.mark('product-list-render-end'); // Sukurkite matą performance.measure( 'Product List Render Time', 'product-list-render-start', 'product-list-render-end' ); });

Tai suteikia jums tikslią kontrolę norint išmatuoti tas jūsų programos dalis, kurios yra kritiškiausios vartotojo darbo eigai.

PerformanceObserver: šiuolaikinis, efektyvus požiūris

Nuolatinis „performance.getEntriesByType()“ apklausimas yra neefektyvus. „PerformanceObserver“ API suteikia daug geresnį būdą klausytis našumo įrašų. Jūs užsiprenumeruojate konkrečius įrašų tipus, o naršyklė asinkroniškai praneša jūsų atgalinio ryšio funkcijai, kai jie įrašomi. Tai yra rekomenduojamas būdas rinkti našumo duomenis nepridedant programai papildomų režimo sąnaudų.

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'] });

Šis stebėtojas yra raktas norint rinkti ne tik aukščiau nurodytas tradicines metrikas, bet ir šiuolaikines, į vartotoją orientuotas metrikas, kurias aptarsime toliau.

Perėjimas prie vartotojo orientacijos: pagrindiniai žiniatinklio rodikliai

Žinoti, kad puslapis įkeltas per 2 sekundes, yra naudinga, bet neatsako į esminius klausimus: ar vartotojas spoksojo į tuščią ekraną tas 2 sekundes? Ar jie galėjo bendrauti su puslapiu, ar jis buvo užšaldytas? Ar turinys netikėtai peršoko, kai jie bandė skaityti?

Norėdami tai išspręsti, „Google“ pristatė pagrindinius žiniatinklio rodiklius (CWV) – metrikų rinkinį, skirtą išmatuoti realų vartotojo puslapio patyrimą pagal tris pagrindinius matmenis: įkėlimą, interaktyvumą ir vaizdinį stabilumą.

Didžiausias turinio atvaizdavimas (LCP): suvokiamo įkėlimo matavimas

LCP matuoja didžiausio matomo vaizdo arba teksto bloko atvaizdavimo laiką matymo lauke. Tai puikus atitikmuo tam, kada vartotojas jaučia, kad pagrindinis puslapio turinys įkeltas. Jis tiesiogiai atsako į vartotojo klausimą: „Ar šis puslapis jau naudingas?“

• Gerai: Mažiau nei 2,5 sekundės
• Reikia patobulinti: Nuo 2,5 s iki 4,0 s
• Prastai: Daugiau nei 4,0 sekundės

Skirtingai nei loadEventEnd, LCP daugiausia dėmesio skiria tam, ką vartotojas mato pirmiausia, todėl tai yra daug tikslesnis suvokiamo įkėlimo greičio atspindys.

Sąveika su kitu atvaizdavimu (INP): reagavimo matavimas

INP yra pirmosios įvesties vėlavimo (FID) tęsinys ir 2024 m. kovo mėn. tapo oficialiu pagrindiniu žiniatinklio rodikliu. Nors FID matavo tik *pirmosios* sąveikos vėlavimą, INP matuoja *visų* vartotojo sąveikų (paspaudimų, bakstelėjimų, klavišų paspaudimų) delsą per visą puslapio gyvavimo ciklą. Jame pranešama apie ilgiausią sąveiką, efektyviai nustatant blogiausią reagavimo atvejį, kurį patiria vartotojas.

INP matuoja visą laiką nuo vartotojo įvesties iki kito kadro atvaizdavimo, atspindint vizualų atsiliepimą. Jis atsako į vartotojo klausimą: „Kai spusteliu šį mygtuką, ar puslapis reaguoja greitai?“

• Gerai: Mažiau nei 200 milisekundžių
• Reikia patobulinti: Nuo 200 ms iki 500 ms
• Prastai: Daugiau nei 500 ms

Aukštą INP paprastai sukelia užimtas pagrindinis siūlas, kai ilgai veikiančios „JavaScript“ užduotys neleidžia naršyklei reaguoti į vartotojo įvestį.

Kaupiamasis išdėstymo poslinkis (CLS): vizualinio stabilumo matavimas

CLS matuoja puslapio vaizdinį stabilumą. Jis kiekybiškai įvertina, kiek turinio netikėtai juda ekrane įkėlimo proceso metu. Aukštas CLS rezultatas yra dažnas vartotojo nusivylimo šaltinis, pvz., kai bandote spustelėti mygtuką, bet virš jo įkeliamas skelbimas, stumdamas mygtuką žemyn ir priversdamas spustelėti skelbimą.

CLS atsako į vartotojo klausimą: „Ar galiu naudoti šį puslapį, kad elementai nešokinėtų visur?“

• Gerai: Mažiau nei 0,1
• Reikia patobulinti: Nuo 0,1 iki 0,25
• Prastai: Daugiau nei 0,25

Dažniausios didelio CLS priežastys yra paveikslėliai arba iframe be matmenų, vėlai įkeliami žiniatinklio šriftai arba turinys, dinamiškai įterpiamas į puslapį, neskiriamas jam vietos.

Spragos užpildymas: API naudojimas prastos vartotojo patirties diagnostikai

Čia viskas susilieja. Pagrindiniai žiniatinklio rodikliai nurodo, *ką* patyrė vartotojas (pvz., lėtas LCP). Žiniatinklio našumo API nurodo, *kodėl* tai įvyko. Derindami juos, mes pereiname nuo paprasto našumo stebėjimo prie aktyvaus diagnostikos ir jo taisymo.

Lėto LCP diagnostika

Įsivaizduokite, kad jūsų realaus vartotojo stebėjimo (RUM) įrankis praneša apie prastą LCP – 4,5 sekundės – konkretaus regiono vartotojams. Kaip tai ištaisyti? Jūs turite suskaidyti LCP laiką į jo sudėtines dalis.

1. Laikas iki pirmojo baito (TTFB): Ar serveris lėtai reaguoja? Naudokite Naršymo laiko API. Trukmė „responseStart - requestStart“ suteikia jums tikslų TTFB. Jei tai didelis skaičius, problema kyla jūsų užkulisiuose, serverio konfigūracijoje arba duomenų bazėje, o ne priekiniame gale.
2. Išteklių įkėlimo delsa ir laikas: Ar pats LCP elementas įkeliamas lėtai? Pirmiausia nustatykite LCP elementą (pvz., pagrindinį vaizdą). Galite naudoti „PerformanceObserver“ „largest-contentful-paint“, kad gautumėte patį elementą. Tada naudokite Išteklių laiko API, kad rastumėte to elemento URL įrašą. Išanalizuokite jo laiko juostą: Ar buvo ilgas „connectStart“ iki „connectEnd“ (lėtas tinklas)? Ar „responseStart“ ir „responseEnd“ buvo ilgi (didelis failo dydis)? Ar jo „fetchStart“ buvo atidėtas, nes jį blokavo kiti atvaizdavimą blokuojantys ištekliai, pvz., CSS arba „JavaScript“?
3. Elemento atvaizdavimo delsa: Tai laikas po to, kai išteklius baigia įkelti, kol jis iš tikrųjų nupiešiamas ekrane. Tai gali sukelti pagrindinis siūlas, užimtas kitomis užduotimis, pvz., didelio „JavaScript“ paketo vykdymu.

Naudodami naršymo ir išteklių laiką, galite nustatyti, ar lėtas LCP yra dėl lėto serverio, atvaizdavimą blokuojančio scenarijaus ar didžiulio, neoptimizuoto vaizdo.

Prasto INP tyrimas

Jūsų vartotojai skundžiasi, kad paspaudus mygtuką „Pridėti į krepšelį“ jaučiamas atsilikimas. Jūsų INP metrika yra „Prasta“ diapazone. Tai beveik visada yra pagrindinio siūlo problema.

1. Nustatykite ilgas užduotis: Ilgų užduočių API yra pagrindinis jūsų įrankis. Jis praneša apie bet kurią pagrindinio siūlo užduotį, kuri trunka ilgiau nei 50 ms, nes viskas, kas ilgesnis, gali sukelti pastebimą delsimą vartotojui. Nustatykite „PerformanceObserver“, kad klausytumėtės „longtask“ įrašų.
2. Susiekite su vartotojo veiksmais: Ilga užduotis yra problema tik tuo atveju, jei ji atsiranda, kai vartotojas bando bendrauti. Galite susieti INP įvykio (stebimo per „PerformanceObserver“ „event“ tipo) „startTime“ su visų ilgų užduočių, kurios įvyko maždaug tuo pačiu metu, laikais. Tai tiksliai nurodo, kuri „JavaScript“ funkcija blokavo vartotojo sąveiką.
3. Išmatuokite konkrečius tvarkytuvus: Norėdami gauti dar detalesnę informaciją, naudokite Vartotojo laiko API. Apsukite savo kritinius įvykių tvarkytuvus (pvz., „Pridėti į krepšelį“ „click“ tvarkytuvą) naudodami „performance.mark()“ ir „performance.measure()“. Tai tiksliai parodys, kiek laiko užtrunka jūsų paties kodas ir ar jis yra ilgos užduoties šaltinis.

Didelio CLS įveikimas

Vartotojai praneša, kad tekstas juda, kai jie skaito straipsnį savo mobiliuosiuose įrenginiuose. Jūsų CLS rezultatas yra 0,3.

1. Stebėkite išdėstymo poslinkius: Naudokite „PerformanceObserver“, kad klausytumėtės „layout-shift“ įrašų. Kiekvienas įrašas turės „value“ (jo indėlis į CLS rezultatą) ir „sources“ sąrašą, kuris yra DOM elementai, kurie judėjo. Tai parodo, *kas* judėjo.
2. Raskite kaltininką išteklių: Kitas klausimas yra, *kodėl* jis judėjo. Dažna priežastis yra vėlai įkeliamas išteklius, stumiantis kitą turinį žemyn. Galite susieti „layout-shift“ įrašo „startTime“ su įrašų iš Išteklių laiko API „responseEnd“ laiku. Jei išdėstymo poslinkis įvyksta iškart po to, kai baigia įkelti skelbimo scenarijus arba didelis paveikslėlis, greičiausiai radote savo kaltininką.
3. Aktyvūs sprendimai: Fiksas dažnai apima matmenų pateikimą paveikslėliams ir skelbimams („<img width="1000" height="600">“) arba vietos rezervavimą puslapyje dinaminiam turiniui, kol jis įkeliamas. Išteklių laikas padeda nustatyti, į kuriuos išteklius reikia būti aktyviems.

Praktinis įgyvendinimas: pasaulinės stebėjimo sistemos kūrimas

Šių API supratimas yra vienas dalykas; jų diegimas, norint stebėti jūsų pasaulinės vartotojų bazės patirtį, yra kitas žingsnis. Tai yra Realiojo vartotojo stebėjimo (RUM) sritis.

Viską sudedame su „PerformanceObserver“

Galite sukurti vieną galingą scenarijų, kad surinktumėte visus šiuos svarbius duomenis. Tikslas yra rinkti metriką ir jų kontekstą nepaveikiant našumo, kurį bandote išmatuoti.

Štai koncepcinis patikimo stebėjimo nustatymo fragmentas:

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') { // Tai supaprastintas INP skaičiavimo vaizdas const duration = entry.duration; if (duration > (collectedMetrics.inp || 0)) { collectedMetrics.inp = duration; } } // ... ir taip toliau kitiems įrašų tipams, pvz., 'longtask' } }); observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });

Patikimas duomenų siuntimas

Surinkę duomenis, turite juos nusiųsti į analizės galinį galą saugojimui ir analizei. Svarbu tai padaryti neatidėliojant puslapio iškrovimo ir neprarandant duomenų iš vartotojų, kurie greitai uždaro savo skirtukus.

`navigator.sendBeacon()` API puikiai tinka šiam tikslui. Jis suteikia patikimą, asinchroninį būdą nusiųsti nedidelį duomenų kiekį į serverį, net jei puslapis išsikrauna. Jis nesitiki atsakymo, todėl jis yra lengvas ir neblokuojantis.

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

Pasaulinio vaizdo svarba

Laboratoriniai testavimo įrankiai, pvz., Lighthouse, yra neįkainojami, tačiau jie veikia kontroliuojamoje aplinkoje. RUM duomenys, surinkti iš šių API, pasako jums pagrįstą tiesą apie tai, ką jūsų vartotojai patiria skirtingose šalyse, tinklo sąlygose ir įrenginiuose.

Analizuodami savo duomenis, visada segmentuokite juos. Galite atrasti, kad:

• Jūsų LCP yra puikus Šiaurės Amerikos vartotojams, bet prastas Australijos vartotojams, nes jūsų pagrindinis vaizdo serveris yra JAV.
• Jūsų INP yra didelis vidutinio diapazono „Android“ įrenginiuose, kurie yra populiarūs besivystančiose rinkose, nes jūsų „JavaScript“ yra per daug procesoriaus reikalaujantis jiems.
• Jūsų CLS yra problema tik tam tikruose ekrano dydžiuose, kai CSS medijos užklausa sukelia netinkamą skelbimo dydžio keitimą.

Šis segmentuotas įžvalgos lygis leidžia jums prioritetuoti optimizacijas, kurios turės didžiausią įtaką jūsų esamai vartotojų bazei, kad ir kur jie būtų.

Išvada: nuo matavimo iki meistriškumo

Žiniatinklio našumo pasaulis subrendo. Mes perėjome nuo paprastų techninių laiko matavimų prie sudėtingo vartotojo suvokiamos patirties supratimo. Kelionė apima tris pagrindinius etapus:

1. Išmatuokite patirtį: Naudokite „PerformanceObserver“, kad rinktumėte pagrindinius žiniatinklio rodiklius (LCP, INP, CLS). Tai parodo, *kas* vyksta ir *kaip jaučiasi* vartotojas.
2. Diagnozuokite priežastį: Norėdami gilintis, naudokite pagrindines laiko API (Naršymas, Ištekliai, Vartotojas, Ilgos užduotys). Tai parodo, *kodėl* patirtis yra prasta.
3. Veikite tiksliai: Naudokite kombinuotus duomenis, kad galėtumėte priimti pagrįstus, tikslinius optimizavimus, kurie išspręs problemos priežastį konkretiems vartotojų segmentams.

Įvaldę ir aukšto lygio vartotojų metriką, ir žemo lygio diagnostikos API, galite sukurti holistinę našumo strategiją. Nustojate spėlioti ir pradedate kurti žiniatinklio patirtį, kuri yra ne tik techniškai greita, bet ir jaučiasi greita, reaguojanti ir džiuginanti kiekvieną vartotoją, kiekviename įrenginyje, visame pasaulyje.