Žiniatinklio našumo atrakinimas: išsami analizė apie Performance Observer API

Šiandieniniame sparčiai besivystančiame skaitmeniniame pasaulyje žiniatinklio našumas nėra prabanga; tai būtinybė. Lėtas arba nereaguojantis tinklalapis gali sukelti naudotojų nusivylimą, didesnius atmetimo rodiklius ir tiesioginį neigiamą poveikį verslo tikslams, nesvarbu, ar tai būtų pardavimai, pajamos iš reklamos ar naudotojų įsitraukimas. Daugelį metų kūrėjai rėmėsi įrankiais, kurie matuoja našumą vienu laiko momentu, paprastai pradinio puslapio įkėlimo metu. Nors tai naudinga, šis metodas praleidžia svarbią istorijos dalį: visą naudotojo patirtį jam sąveikaujant su puslapiu. Čia įsijungia našumo stebėjimas vykdymo metu, o galingiausias jo įrankis yra Performance Observer API.

Tradiciniai metodai dažnai apima našumo duomenų apklausą naudojant tokias funkcijas kaip performance.getEntries(). Tai gali būti neefektyvu, linkę praleisti svarbius įvykius, kurie įvyksta tarp apklausų, ir netgi gali padidinti našumo sąnaudas, kurias bandoma išmatuoti. Performance Observer API iš esmės keičia šį procesą, suteikdama asinchroninį, mažų sąnaudų mechanizmą prenumeruoti našumo įvykius jiems vykstant. Šis vadovas nuves jus į išsamią šios esminės API analizę, parodys, kaip panaudoti jos galią stebėti pagrindinius žiniatinklio gyvybingumo rodiklius, nustatyti kliūtis ir galiausiai sukurti greitesnes, malonesnes žiniatinklio patirtis globaliai auditorijai.

Kas yra Performance Observer API?

Iš esmės Performance Observer API yra sąsaja, kuri suteikia būdą stebėti ir rinkti našumo matavimo įvykius, žinomus kaip našumo įrašai. Pagalvokite apie tai kaip apie specialų klausytoją su našumu susijusiai veiklai naršyklėje. Užuot aktyviai klausę naršyklės: "Ar jau kas nors įvyko?", naršyklė aktyviai jums sako: "Ką tik įvyko naujas našumo įvykis! Štai detalės."

Tai pasiekiama per stebėtojo šabloną. Jūs sukuriate stebėtojo egzempliorių, pasakote jam, kokio tipo našumo įvykiais domitės (pvz., dideli dažymai, naudotojo įvestis, išdėstymo poslinkiai) ir pateikiate atgalinio iškvietimo funkciją. Kai tik naujas nurodyto tipo įvykis įrašomas naršyklės našumo laiko juostoje, jūsų atgalinio iškvietimo funkcija iškviečiama su naujų įrašų sąrašu. Šis asinchroninis, stūmimo modelis yra daug efektyvesnis ir patikimesnis nei senesnis traukimo modelis, kai pakartotinai kviečiamas performance.getEntries().

Senasis būdas prieš naująjį būdą

Norėdami įvertinti Performance Observer naujovę, palyginkime du metodus:

• Senasis būdas (apklausa): Galite naudoti setTimeout arba requestAnimationFrame, kad periodiškai kviestumėte performance.getEntriesByName('my-metric') ir patikrintumėte, ar jūsų metrika buvo įrašyta. Tai problematiška, nes galite patikrinti per vėlai ir praleisti įvykį arba patikrinti per dažnai ir eikvoti CPU ciklus. Taip pat rizikuojate užpildyti naršyklės našumo buferį, jei reguliariai nevalysite įrašų.
• Naujasis būdas (stebėjimas): Jūs vieną kartą nustatote PerformanceObserver. Jis tyliai veikia fone, naudodamas minimalius išteklius. Kai tik įrašomas atitinkamas našumo įrašas – ar tai būtų viena milisekundė po puslapio įkėlimo, ar dešimt minučių naudotojo sesijos metu – jūsų kodas iškart informuojamas. Tai užtikrina, kad niekada nepraleisite įvykio, o jūsų stebėjimo kodas bus kuo efektyvesnis.

Kodėl turėtumėte naudoti Performance Observer

Performance Observer API integravimas į jūsų kūrimo darbo eigą siūlo daugybę privalumų, kurie yra labai svarbūs šiuolaikinėms žiniatinklio programoms, siekiančioms pasiekti globalią aprėptį.

• Neįkyrus stebėjimas: Stebėtojo atgalinis iškvietimas paprastai vykdomas neveikimo laikotarpiais, užtikrinant, kad jūsų našumo stebėjimo kodas netrukdytų naudotojo patirčiai arba neužblokuotų pagrindinės gijos. Jis sukurtas taip, kad būtų lengvas ir turėtų nereikšmingą našumo pėdsaką.
• Išsamūs vykdymo laiko duomenys: Žiniatinklis yra dinamiškas. Našumo problemos ne tik atsiranda įkėlimo metu. Naudotojas gali suaktyvinti sudėtingą animaciją, įkelti daugiau turinio slinkdamas arba sąveikauti su sunkiu komponentu praėjus ilgam laikui po pradinio puslapio nusistovėjimo. Performance Observer fiksuoja šiuos vykdymo laiko įvykius, suteikdamas jums išsamų visos naudotojo sesijos vaizdą.
• Ateities įrodymas ir standartizuotas: Tai yra W3C rekomenduojamas standartas našumo duomenų rinkimui. Naujos našumo metrikos ir API yra sukurtos integruoti su juo, todėl tai yra tvarus ir į ateitį orientuotas pasirinkimas jūsų projektams.
• Realaus naudotojo stebėjimo (RUM) pagrindas: Norėdami tikrai suprasti, kaip jūsų svetainė veikia naudotojams skirtingose šalyse, įrenginiuose ir tinklo sąlygomis, jums reikia duomenų iš realių sesijų. Performance Observer yra idealus įrankis kuriant patikimą RUM sprendimą, leidžiantį rinkti gyvybiškai svarbias metrikas ir siųsti jas į analizės tarnybą agregavimui ir analizei.
• Pašalina lenktynių sąlygas: Atliekant apklausą, galite bandyti pasiekti našumo įrašą prieš jį įrašant. Stebėtojo modelis visiškai pašalina šią lenktynių sąlygą, nes jūsų kodas paleidžiamas tik tada, kai įrašas yra prieinamas.

Darbo pradžia: Performance Observer pagrindai

Naudoti API yra paprasta. Procesas apima tris pagrindinius veiksmus: stebėtojo sukūrimą, atgalinio iškvietimo apibrėžimą ir pasakymą stebėtojui, ko ieškoti.

1. Stebėtojo sukūrimas su atgaliniu iškvietimu

Pirmiausia jūs sukuriate PerformanceObserver objektą, perduodami jam atgalinio iškvietimo funkciją. Ši funkcija bus vykdoma, kai tik bus aptikti nauji įrašai.

const observer = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log('Entry Type:', entry.entryType); console.log('Entry Name:', entry.name); console.log('Start Time:', entry.startTime); console.log('Duration:', entry.duration); } });

Atgalinis iškvietimas gauna PerformanceObserverEntryList objektą. Galite iškviesti getEntries() metodą šiame sąraše, kad gautumėte visų naujai stebėtų našumo įrašų masyvą.

2. Konkrečių įrašų tipų stebėjimas

Stebėtojas nieko nedaro, kol nepasakote jam, ką stebėti. Tai darote naudodami .observe() metodą. Šis metodas priima objektą su entryTypes savybe (arba kai kuriais šiuolaikiniais atvejais tik type vienam tipui), kuri yra eilučių masyvas, atspindintis našumo įrašo tipus, kuriais domitės.

// Pradėkite stebėti du įrašų tipus observer.observe({ entryTypes: ['mark', 'measure'] });

Kai kurie iš dažniausiai pasitaikančių įrašų tipų yra:

• 'resource': Išsami informacija apie tinklo užklausas, skirtas tokiems ištekliams kaip scenarijai, vaizdai ir stilių lapai.
• 'paint': Pirmojo dažymo ir pirmojo turinio dažymo laikas.
• 'largest-contentful-paint': Pagrindinė žiniatinklio gyvybingumo metrika, skirta suvokiamam įkėlimo greičiui.
• 'layout-shift': Pagrindinė žiniatinklio gyvybingumo metrika, skirta vaizdo stabilumui.
• 'first-input': Informacija apie pirmąją naudotojo sąveiką, naudojama pirmojo įvesties uždelsimo (First Input Delay) pagrindinei žiniatinklio gyvybingumo metrikai.
• 'longtask': Identifikuoja užduotis pagrindinėje gijoje, kurios trunka ilgiau nei 50 milisekundžių, o tai gali sukelti nereagavimą.
• 'mark' & 'measure': Pasirinktiniai žymekliai ir matavimai, kuriuos apibrėžiate savo kode naudodami User Timing API.

3. Stebėtojo sustabdymas

Kai jums nebereikia rinkti duomenų, yra gera praktika atjungti stebėtoją, kad atlaisvintumėte išteklius.

observer.disconnect();

Praktiniai naudojimo atvejai: pagrindinių žiniatinklio gyvybingumo rodiklių stebėjimas

Pagrindiniai žiniatinklio gyvybingumo rodikliai yra tam tikrų veiksnių rinkinys, kurį Google laiko svarbiu bendrai tinklalapio naudotojo patirčiai. Jų stebėjimas yra viena iš galingiausių Performance Observer API programų. Pažiūrėkime, kaip išmatuoti kiekvieną iš jų.

Didžiausio turinio elemento (LCP) stebėjimas

LCP matuoja įkėlimo našumą. Jis pažymi tašką puslapio įkėlimo laiko juostoje, kai pagrindinis turinys greičiausiai buvo įkeltas. Geras LCP rezultatas yra 2,5 sekundės ar mažiau.

LCP elementas gali keistis, kai puslapis įkeliamas. Iš pradžių antraštė gali būti LCP elementas, bet vėliau gali būti įkeltas didesnis vaizdas ir tapti nauju LCP elementu. Štai kodėl Performance Observer yra tobulas – jis praneša jums apie kiekvieną potencialų LCP kandidatą, kai jis atvaizduojamas.

// Stebėkite LCP ir įrašykite galutinę vertę let lcpValue = 0; const lcpObserver = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); // Paskutinis įrašas yra naujausias LCP kandidatas const lastEntry = entries[entries.length - 1]; lcpValue = lastEntry.startTime; console.log(`LCP updated: ${lcpValue.toFixed(2)}ms`, lastEntry.element); }); lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true }); // Gera praktika atjungti stebėtoją po to, kai naudotojas sąveikauja, // nes sąveika gali sustabdyti naujų LCP kandidatų išsiuntimą. // window.addEventListener('beforeunload', () => lcpObserver.disconnect());

Atkreipkite dėmesį į buffered: true naudojimą. Tai yra labai svarbi parinktis, kuri nurodo stebėtojui įtraukti įrašus, kurie buvo įrašyti *prieš* iškviečiant observe() metodą. Tai apsaugo jus nuo ankstyvo LCP įvykio praleidimo.

Pirmojo įvesties uždelsimo (FID) ir sąveikos su kitu dažymu (INP) stebėjimas

Šios metrikos matuoja interaktyvumą. Jie kiekybiškai įvertina naudotojo patirtį, kai jie pirmą kartą bando sąveikauti su puslapiu.

Pirmojo įvesties uždelsimas (FID) matuoja laiką nuo tada, kai naudotojas pirmą kartą sąveikauja su puslapiu (pvz., spusteli mygtuką), iki tada, kai naršyklė iš tikrųjų gali pradėti apdoroti įvykių tvarkykles reaguodama į tą sąveiką. Geras FID yra 100 milisekundžių ar mažiau.

Sąveika su kitu dažymu (INP) yra naujesnė, išsamesnė metrika, kuri pakeitė FID kaip pagrindinę žiniatinklio gyvybingumo metriką 2024 m. kovą. Nors FID matuoja tik *pirmosios* sąveikos *uždelsimą*, INP įvertina *visą latentinį laiką* *visų* naudotojo sąveikų per visą puslapio gyvavimo ciklą, pranešdama apie blogiausią. Tai suteikia geresnį bendro reagavimo vaizdą. Geras INP yra 200 milisekundžių ar mažiau.

Galite stebėti FID naudodami įrašo tipą "first-input":

// Stebėkite FID const fidObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { const fid = entry.processingStart - entry.startTime; console.log(`FID: ${fid.toFixed(2)}ms`); // Atjunkite po to, kai pranešama apie pirmąjį įvestį fidObserver.disconnect(); } }); fidObserver.observe({ type: 'first-input', buffered: true });

INP stebėjimas yra šiek tiek sudėtingesnis, nes jis žiūri į visą įvykio trukmę. Jūs stebite įvykio tipą "event" ir apskaičiuojate trukmę, stebėdami ilgiausią.

// Supaprastintas INP stebėjimo pavyzdys let worstInp = 0; const inpObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // INP yra įvykio trukmė const inp = entry.duration; // Mums rūpi tik sąveikos, ilgesnės už dabartinę blogiausią if (inp > worstInp) { worstInp = inp; console.log(`New worst INP: ${worstInp.toFixed(2)}ms`); } } }); inpObserver.observe({ type: 'event', durationThreshold: 16, buffered: true }); // durationThreshold padeda filtruoti labai trumpus, greičiausiai nereikšmingus įvykius.

Kumuliacinio išdėstymo poslinkio (CLS) stebėjimas

CLS matuoja vaizdo stabilumą. Jis padeda kiekybiškai įvertinti, kaip dažnai naudotojai patiria netikėtų išdėstymo poslinkių – varginančią patirtį, kai turinys puslapyje juda be įspėjimo. Geras CLS rezultatas yra 0,1 ar mažiau.

Rezultatas yra visų atskirų išdėstymo poslinkio rezultatų agregavimas. Performance Observer čia yra būtinas, nes jis praneša apie kiekvieną poslinkį, kai jis įvyksta.

// Stebėkite ir apskaičiuokite bendrą CLS rezultatą let clsScore = 0; const clsObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // Nenorime skaičiuoti poslinkių, kuriuos sukėlė naudotojo įvestis if (!entry.hadRecentInput) { clsScore += entry.value; console.log(`Current CLS score: ${clsScore.toFixed(4)}`); } } }); clsObserver.observe({ type: 'layout-shift', buffered: true });

hadRecentInput savybė yra svarbi. Ji padeda filtruoti teisėtus išdėstymo poslinkius, kurie įvyksta reaguojant į naudotojo veiksmą (pvz., spustelėjus mygtuką, kuris išplečia meniu), kuris neturėtų būti įskaičiuojamas į CLS rezultatą.

Be pagrindinių žiniatinklio gyvybingumo rodiklių: kiti galingi įrašų tipai

Nors pagrindiniai žiniatinklio gyvybingumo rodikliai yra puikus atspirties taškas, Performance Observer gali stebėti daug daugiau. Štai keletas kitų neįtikėtinai naudingų įrašų tipų.

Ilgų užduočių sekimas (`longtask`)

Long Tasks API atskleidžia užduotis, kurios užima pagrindinę giją 50 milisekundžių ar ilgiau. Tai yra problematiška, nes kol pagrindinė gija yra užimta, puslapis negali reaguoti į naudotojo įvestį, todėl patirtis yra lėta arba užšąla. Šių užduočių identifikavimas yra raktas į INP gerinimą.

// Stebėkite ilgas užduotis const longTaskObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log(`Long Task Detected: ${entry.duration.toFixed(2)}ms`); // Savybė "attribution" kartais gali pasakyti, kas sukėlė ilgą užduotį console.log('Attribution:', entry.attribution); } }); longTaskObserver.observe({ type: 'longtask', buffered: true });

Išteklių laiko analizė (`resource`)

Supratimas, kaip įkeliami jūsų ištekliai, yra esminis našumo derinimo dalykas. Įrašo tipas "resource" suteikia jums išsamius tinklo laiko duomenis kiekvienam jūsų puslapio ištekliui, įskaitant DNS paiešką, TCP ryšį ir turinio atsisiuntimo laiką.

// Stebėkite išteklių laiką const resourceObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // Raskime lėtai įkeliamus vaizdus if (entry.initiatorType === 'img' && entry.duration > 500) { console.warn(`Slow image detected: ${entry.name}`, `Duration: ${entry.duration.toFixed(2)}ms`); } } }); // Naudoti "buffered: true" beveik visada būtina išteklių laikui // kad būtų galima sugauti išteklius, kurie buvo įkelti prieš paleidžiant šį scenarijų. resourceObserver.observe({ type: 'resource', buffered: true });

Pasirinktinių našumo žymių matavimas (`mark` ir `measure`)

Kartais reikia išmatuoti programai būdingos logikos našumą. User Timing API leidžia jums sukurti pasirinktinius laiko žymėjimus ir išmatuoti trukmę tarp jų.

• performance.mark('start-operation'): Sukuria laiko žymą pavadinimu "start-operation".
• performance.mark('end-operation'): Sukuria kitą laiko žymą.
• performance.measure('my-operation', 'start-operation', 'end-operation'): Sukuria matavimą tarp dviejų žymių.

Performance Observer gali klausytis šių pasirinktinių įrašų "mark" ir "measure", kurie puikiai tinka rinkti laiko duomenis apie tokius dalykus kaip komponentų atvaizdavimo laikas JavaScript sistemoje arba kritinio API iškvietimo ir vėlesnio duomenų apdorojimo trukmė.

// Jūsų programos kode: performance.mark('start-data-processing'); // ... kai kuris sudėtingas duomenų apdorojimas ... performance.mark('end-data-processing'); performance.measure('data-processing-duration', 'start-data-processing', 'end-data-processing'); // Jūsų stebėjimo scenarijuje: const customObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntriesByName('data-processing-duration')) { console.log(`Custom Measurement '${entry.name}': ${entry.duration.toFixed(2)}ms`); } }); customObserver.observe({ entryTypes: ['measure'] });

Išplėstinės sąvokos ir geriausia praktika

Norėdami efektyviai naudoti Performance Observer API profesionalioje gamybos aplinkoje, apsvarstykite šias geriausias praktikas.

• Visada apsvarstykite `buffered: true`: Įrašų tipams, kurie gali įvykti anksti puslapio įkėlimo metu (pvz., "resource", "paint" arba "largest-contentful-paint"), naudoti buferinę vėliavėlę būtina, kad jų nepraleistumėte.
• Patikrinkite naršyklės palaikymą: Nors plačiai palaikomas šiuolaikinėse naršyklėse, visada protinga patikrinti, ar jis egzistuoja, prieš jį naudojant. Taip pat galite patikrinti, kurie įrašų tipai palaikomi konkrečios naršyklės.
• if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes.includes('longtask')) { // Saugu naudoti PerformanceObserver ilgoms užduotims }
• Siųskite duomenis į analizės tarnybą: Duomenų įrašymas į konsolę yra puikus dalykas kūrimui, tačiau realiame pasaulyje stebėjimui turite sujungti šiuos duomenis. Geriausias būdas siųsti šią telemetriją iš kliento yra naudoti navigator.sendBeacon() API. Tai neblokuojantis mechanizmas, skirtas siųsti nedidelius duomenų kiekius į serverį, ir jis patikimai veikia net tada, kai puslapis iškraunamas.
• Grupuokite stebėtojus pagal rūpestį: Nors galite naudoti vieną stebėtoją keliems įrašų tipams, dažnai yra švariau sukurti atskirus stebėtojus skirtingiems rūpesčiams (pvz., vieną pagrindiniams žiniatinklio gyvybingumo rodikliams, vieną išteklių laikui, vieną pasirinktinėms metrikoms). Tai pagerina kodo skaitomumą ir prižiūrimumą.
• Supraskite našumo sąnaudas: API sukurtas taip, kad būtų labai mažos sąnaudos. Tačiau labai sudėtinga atgalinio iškvietimo funkcija, atliekanti sunkius skaičiavimus, gali turėti įtakos našumui. Laikykite savo stebėtojo atgalinius iškvietimus paprastus ir efektyvius. Atidėkite bet kokį sunkų apdorojimą žiniatinklio darbuotojui arba nusiųskite neapdorotus duomenis į savo galinę dalį apdorojimui ten.

Išvada: našumu pagrįstos kultūros kūrimas

Performance Observer API yra daugiau nei tik dar vienas įrankis; tai esminis poslinkis tame, kaip mes žiūrime į žiniatinklio našumą. Jis perkelia mus nuo reaktyvių, vienkartinių matavimų prie aktyvaus, nuolatinio stebėjimo, kuris atspindi tikrą, dinamišką mūsų naudotojų patirtį visame pasaulyje. Suteikdamas patikimą ir efektyvų būdą fiksuoti pagrindinius žiniatinklio gyvybingumo rodiklius, ilgas užduotis, išteklių laiką ir pasirinktines metrikas, jis suteikia kūrėjams galimybę identifikuoti ir išspręsti našumo kliūtis, kol jos paveiks didelį naudotojų skaičių.

Performance Observer API priėmimas yra esminis žingsnis kuriant našumu pagrįstą kultūrą bet kurioje kūrimo komandoje. Kai galite išmatuoti tai, kas svarbu, galite patobulinti tai, kas svarbu. Pradėkite integruoti šiuos stebėtojus į savo projektus šiandien. Jūsų naudotojai – kad ir kur jie būtų pasaulyje – padėkos jums už greitesnę, sklandesnę ir malonesnę patirtį.