Eiti prie turinio 
Interaktyvumo laikas (TTI) parodo, kada puslapis iš tikrųjų yra tinkamas naudoti, ir papildo TTFB, "Web Performance", "Lighthouse", "WebPageTest", "Hosting" ir "WordPress Performance" sąveikos perspektyvą. Naudoju jį norėdamas įvertinti, ar naudotojai gali spustelėti, rašyti ir slinkti iš karto, o ne laukti, kol užblokuos "JavaScript".
Centriniai taškai
Prieš pradėdamas išsamiau, trumpai apibendrinsiu svarbiausius aspektus.
- Pirmenybė teikiama TTI: Interaktyvumas pranoksta gryną serverio atsako laiką.
- Patikslinti matavimą: Tinkamai naudokite "Lighthouse" ir "WebPageTest".
- Patikrinkite "JavaScript": Atlaisvinkite pagrindinę giją.
- Pasirinkite prieglobą: Spartinančioji atmintinė, HTTP/3 ir galingi procesoriai.
- "Harden WordPress": plonas temas, talpyklą, vaizdų formatus.
Interaktyvumo laikas (TTI) paaiškintas paprastai
Tinklalapiui Vartotojai skaičiuoja, kada puslapis reaguoja į įvestį. TTI matuoju kaip laiką nuo puslapio iškvietimo iki to momento, kai sąsaja gali būti spustelėjama be vėlavimo. Įkrovimo rodikliai padeda tik ribotai, nes pastebimi vėlavimai po atvaizdavimo vargina. Ilgos "JavaScript" užduotys, blokuojantys šriftai ar sekimas dažnai stabdo interaktyvumą. Aiškumą sukuriu vertindamas interaktyvumą per visą struktūrą, o ne tik per pirmąjį atsakymą iš serverio.
Kaip teisingai išmatuoti TTI
Aš naudoju Švyturys naršyklėje ir "WebPageTest", kad būtų galima atkurti matavimus su aiškiais profiliais. Abu įrankiai rodo, kada pagrindinis srautas tampa laisvas ir įvestys eina tiesiai per jį. Kad galėčiau palyginti, nustatau vienodus įrenginio profilius, tinklo sąlygas ir talpyklos būsenas ir taip atpažįstu įtikinamas tendencijas. Matavimus atlieku kelis kartus, kad išlyginčiau nukrypimus. Šiame kompaktiškame palyginime greitai apžvelgiu metrinius skirtumus: Švyturys vs PageSpeed.
TTI ir TTFB: kas iš tikrųjų svarbu?
TTFB rodo, kaip greitai iš duomenų centro atkeliauja pirmasis baitas. Tai atspindi serverio artumą, spartųjį spartinimą ir galinės duomenų bazės greitį, tačiau neatsako į klausimą, ar naudotojai gali veikti iš karto. TTI atspindi realų naudojimą: ar mygtukai paspaudžiami, formos laukai reaguoja ir meniu reaguoja? Svetainė gali būti pradėta kurti su labai geru TTFB, tačiau gali nepavykti dėl per didelio JavaScript ir blokuojančių užduočių skaičiaus. Todėl pirmenybę teikiu TTI, neignoruodamas TTFB, nes abu kartu sudaro išsamų vaizdą.
| Metrika | Reikšmė | Tipinės tikslinės vertės | Pagrindinis vairuotojas |
|---|---|---|---|
| TTFB | Pirmasis baitas naršyklėje | < 200-500 ms | Serveris, talpykla, tinklas |
| TTI | Puslapis yra interaktyvus | mobilusis telefonas: 3-5 s, stalinis kompiuteris: trumpiau | JS įkėlimas, pagrindinė gija, ištekliai |
| TBT | Blokavimo laikas iki sąveikos | < 200 ms | Ilgos užduotys, scenarijų kiekis |
| LCP | Didžiausias matomas elementas | < 2,5 s | Vaizdai, CSS, Serveris |
Kodėl TTI atspindi tikrąjį panaudojimą
Dažnai susiduriu su tuo, kad naudotojai mato puslapį, bet dar negali nieko paleisti - tai aiškus požymis, kad Užsikimšimai. Šiame etape parduotuvės praranda pirkinių krepšelius ir leidėjų sąveiką. TTI sujungia atvaizdavimą, scenarijaus įkėlimą ir įvesties atsaką į vertę, kuri turi tiesioginį poveikį pardavimams. Net nedideli vėlavimai po pradinio atvaizdavimo mažina pasitikėjimą. Todėl remiuosi priemonėmis, kurios nuosekliai trumpina laiką iki pirmosios stabilios sąveikos.
Laboratorijos ir lauko duomenys, INP ir realus panaudojimas
Laboratorijoje matuoju TTI, kad rasčiau atkuriamas priežastis. Dėl sprendimų remiuosi Lauko duomenys tikri įrenginiai, tikri tinklai, tikri naudotojai. INP (Interaction to Next Paint) ir TBT analizuoju kartu, nes abu rodikliai rodo, kaip greitai apdorojamos sąveikos. INP suteikia perspektyvą bet kuriuo metu reakcija per visą sesiją, TBT rodo mane kaip techniką, kur pagrindinis siūlas yra užblokuotas. Tai leidžia man atpažinti, ar geras TTI palaiko visą patirtį, ar vėlesnės sąveikos stabdo. Nustatau sau aiškius profilius (pvz., vidutinės klasės "Android" pagal 4G) ir tikrinu kintamumą per keletą paleidimų, kad galėčiau padaryti patikimas išvadas.
Priimantieji veiksniai, kurie sulėtina arba pagreitina TTI
Geras Serveris ne tik sutrumpina TTFB, bet ir pagreitina dinaminius procesus, duomenų bazės užklausas ir PHP-FPM. Atkreipiu dėmesį į modernius procesorius, daug operatyviosios atminties, "NVMe" saugyklą ir greitą ryšį su HTTP/2 arba HTTP/3. Didelio našumo puslapių ir objektų spartinančioji atmintinė sumažina pradinės duomenų bazės apkrovą ir užtikrina, kad pasikartojančios užklausos būtų trumpos. Brotli suspaudimas, TLS 1.3 ir tinkamai nustatytos talpyklos antraštės sutaupo dar daugiau sekundės dalių. Išsami atsako laiko analizė aiškiai parodo man kliūtis: TTI ir TTFB patikrinimas.
"WordPress" našumas: greitas interaktyvumas praktikoje
Pradedu nuo plono TemaSumažinkite įskiepių skaičių iki būtiniausių ir atnaujinkite jų versijas. Našumo įskiepiai rūpinasi puslapio talpykla, objektų talpykla ir vaizdų optimizavimu naudojant WebP arba AVIF. Skriptus įkraunu naudodamas "defer" arba "async" ir atidedu trečiųjų šalių komponentus iki pirmojo naudotojo veiksmo. Svarbiausius CSS įrašau į eilutę, o likusius įkeliu po atvaizdavimo. Kalbant apie šriftus, remiuosi subdetalizavimu, moderniu formatu ir rodymo strategija, pagal kurią tekstas rodomas iš karto.
Teisingai išmatuokite TTFB ir išvenkite tipinių matavimo paklaidų
Tikrinu TTFB atskirai HTML, API galutiniams taškams ir svarbiausiems ištekliams. Matavimai atliekami naudojant tuščią talpyklą, nustatytą tinklo delsą ir aiškius vietos profilius. CDN "Edge" ir "Origin" interpretuoju atskirai, nes jie abu aptarnauja skirtingus kelius. Trečiųjų šalių skriptai lengvai iškreipia suvokimą, todėl pirmiausia išskiriu dokumento TTFB. Čia turiu naudingą matavimo paklaidų apžvalgą: Teisingas TTFB aiškinimas.
Tvarus matavimo, stebėsenos ir tikslinių verčių įtvirtinimas
Aš seku TTITBT, LCP ir INP ir nuolat stebėkite pokyčius. Tam naudoju automatines ataskaitas, ribines vertes ir regresijos pranešimus. Kiekvieną optimizavimą įvedu atskirai, kad galėčiau aiškiai matyti jo poveikį. Mobiliuosius įrenginius testuoju naudodamas 4G profilius ir tikrus įrenginius, ne tik kūrėjo nešiojamąjį kompiuterį. Nenustatau tikslinių verčių, kol duomenys nėra stabilūs - tada nustatau konkrečias ribas komandoms ir versijoms.
Protingai mažinkite "JavaScript" apkrovą
Pradedu nuo Auditas ir pašalinkite nenaudojamas bibliotekas bei besidubliuojančias funkcijas. Kodo skaidymas suskirsto paketus į prasmingas dalis, kad pagrindinė gija ilgai neužsiblokuotų. Ilgas užduotis suskaidau į mažesnius darbo paketus, kurių trukmė neviršija 50 milisekundžių. Nekritinius valdiklius, pokalbių įrankius ar socialinių tinklų įterpinius įkeliu tik po sąveikos. Jei įmanoma, skaičiavimams imlias užduotis perkeliu į žiniatinklio darbininkus, o naudotojo sąsają palieku laisvą.
Vaizdai, šriftai ir CSS be balasto
Optimizuoju Vaizdai su šiuolaikiniais formatais ir nustatykite švarias dydžio specifikacijas, kad išnyktų išdėstymo šuoliai. Atspindintys variantai atitinkamam įrenginiui pateikia tik reikiamą raišką. Kritiniai CSS užtikrina greitą pirmąjį dažymą, o likę stiliai įkeliami iš naujo. Sistemingai šalinu nenaudojamas taisykles, kad CSS būtų mažas. Šriftams sutrumpinu įkėlimo kelius naudodamas išankstinį įkėlimą ir užtikrinu iškart įskaitomą tekstą, naudodamas tinkamą rodymo strategiją.
SPA, drėkinimas ir salų architektūra
Vieno puslapio programose dažnai naudojama daug "JavaScript", todėl TTI vėluoja. Tai pagerinu naudodamas Atvaizdavimas serverio pusėje ir hidratuoti tik ten, kur būtina sąveika. Su dalinis arba laipsniškas drėkinimas salos aktyvuojamos nepriklausomai - navigacijai, herojaus užuominai ir pirkinių krepšeliui nereikia tuo pačiu metu analizuoti JavaScript. Srautiniu būdu perduodu HTML, kad naršyklė galėtų anksti atvaizduoti ir kontroliuoti drėkinimo įvykius (neveikimą, matomumą, naudotojo veiksmą), kad pagrindinė gija liktų laisva per pirmąsias kelias sekundes. Taip puslapis išlieka greitas naudoti, o sudėtingos funkcijos atsiranda vėliau.
Išteklių prioritetų nustatymas ir tinklo optimizavimas
Leidžiu naršyklei žinoti, kas yra svarbu. Išankstinė apkrova užtikrina kritinės svarbos CSS ir raštus, išankstinis prijungimas sutrumpina prisijungimus prie neišvengiamų trečiųjų šalių domenų. Su Prioritetinės užuominos (fetchpriority) Nurodau, kurie ištekliai bus naudojami pirmiausia. Naudojant HTTP/3, puslapiui suteikiama daugiau naudos dėl stabilesnio vėlavimo, o naudojant Nuosekli spartinančioji atmintinė Taupykite keliones į abi puses. Reguliuoju lygiagrečių užklausų skaičių ir gabalų dydžius, kad analizatorius galėtų dirbti tolygiai, o ne blokuoti bangomis. Tikslas išlieka: mažesnė konkurencija pagrindiniame sraute ir trumpesni laiko langai iki sąveikos.
Trečiųjų šalių scenarijai ir sutikimų valdymas
Išoriniai scenarijai yra TTI žudikai, jei jie įkeliami nekontroliuojami. Aš paleidžiu Trečiųjų šalių inventorius per: Jei yra lengvesnė alternatyva. Aš tik įkelti minimalų per dieną vadybininkas į po pirmojo naudotojo veiksmo arba tik gavus sutikimą. Neblokuojanti integracija, mažesnės integracijos (pvz., pikseliai vietoj ištisų bibliotekų) ir serverio pusės įgaliotieji serverio serveriai, skirti sunkiems galutiniams taškams, išlaiko pagrindinį srautą laisvą. Nustatau griežtus biudžetus: ne daugiau kaip X scenarijų iš pradžių, Y kB "JavaScript" prieš sąveiką - viskas, kas viršija šią ribą, atidedama.
"WordPress" galinės dalies ir duomenų bazės derinimas
Interaktyvumas nukenčia, kai galinė dalis delsia su kiekviena sąveika. Aš nuolat PHP atnaujinti, įjungti "OPcache" ir įsitikinti, kad turite pakankamai PHP-FPM-Darbuotojas. A Objektų talpykla (pvz., "Redis") buferyje talpina dažnas užklausas, supaprastinamos laikinosios parinktys. Duomenų bazės pusėje optimizuojami indeksai, sumažinamos automatinio įkėlimo parinktys ir sutvarkomos "cron" užduotys. "WooCommerce" atveju atskiriu skaitymo ir rašymo apkrovas, agresyviai talpinu į talpyklą produktų ir kategorijų puslapius ir prioritetizuoju API galinius taškus. Dėl to sąveikos išlieka jautrios net ir esant apkrovai.
"Service Worker", "App Shell" ir neprisijungus prie interneto strategijos
Tinkamai naudojamos jos pagreitina Paslaugų darbuotojas Pastebima sąveika. Programos apvalkalą ir kritinius maršrutus talpinu į talpyklą, kad pirmoji sąveika būtų pateikta iš talpyklos. Tinklo užklausos vykdomos "stale-while-revalidate", todėl suvokimas ir realus savalaikiškumas susilieja. Svarbu: registracija ir diegimas neturi blokuoti pagrindinio srauto - inicializuoju darbininkus į pirmąją sąveiką arba neveikimo langą ir išlaikyti paprastą strategiją, kad būtų išvengta klaidų ir laukimo laiko.
Klaidų vaizdai, gadinantys TTI, ir kaip aš juos randu
- Ilgos užduotys > 50 ms: Naudoju "Performance Profiler" ir "Long Tasks API", suskirsčiau užduotis ir perkėliau skaičiavimus į darbininkus.
- Atvaizdavimą blokuojantys CSS / šriftai: Ištraukite svarbiausius CSS, likusią dalį įkelkite asinchroniškai, pateikite šriftus su protinga rodymo strategija.
- Išpūsti daugialypės terpės ir (arba) paketų: Modernizuokite taikinių nustatymą, įkelkite tik reikiamus polipinius papildinius, išardykite paketus.
- DOM- / išdėstymo trynimas: Venkite pakartotinių srautų, paketų matavimų, ilgų sąrašų virtualizavimo.
- Įvykių klausytojo potvynis: Naudokite delegavimą, pasyvius slinkimo / palietimo klausytojus, pašalinkite nereikalingus klausytojus.
Veiklos biudžetai, CI/CD ir komandos procesai
Nuolatinis TTI pagerėjimas atsiranda dėl Drausmė. Nustatau biudžetus (pvz., didžiausią JS KB, LCP/INP/TTI ribas) ir inkarinius patikrinimus CI. Kiekviena "pull request" užklausa sukelia našumo testus; jei biudžetas viršijamas, sustabdau sujungimą. Iš prietaisų skydelių matomos tendencijos, o pakeitimų žurnale kiekvienas optimizavimas susiejamas su poveikiu skaičiais. Tai reiškia, kad interaktyvumas yra ne vienkartinis projektas, o kūrimo ciklo dalis.
30 dienų geresnio sąveikumo planas
Pirmąją savaitę daugiausia dėmesio skiriu Analizė: Nustatykite matavimo pagrindą, sukurkite bazinį lygį "Lighthouse" ir "WebPageTest" programose, užfiksuokite kliūtis. Antroji savaitė skirta "JavaScript" išvalymui ir nekritinių komponentų atskyrimui. Trečioji savaitė skirta prieglobos optimizavimui, pavyzdžiui, spartinančiosios atminties strategijoms, HTTP/3, "Brotli" ir duomenų bazių derinimui. Ketvirtąją savaitę koreguoju paveikslėlius, šriftus ir svarbiausius CSS bei nustatau stebėsenos taisykles. Po 30 dienų turiu patikimas "prieš" ir "po" vertes, kurias naudoju kitam plėtros etapui.
Į planą įtraukiu konkrečius pristatymo objektus: - 1 savaitė: testų profiliai, scenarijų ir išteklių aprašas, biudžeto projektas, trečiųjų šalių rizikos sąrašas. - 2 savaitė: moduliais ir maršrutais pagrįstas kodo skaidymas, atidėtas ne itin svarbių valdiklių įkėlimas, drėkinimo strategija. - 3 savaitė: objektų talpyklos veikimas, duomenų bazės indekso peržiūra, PHP/FPM derinimas, talpyklos antraštės ir CDN politika. - 4 savaitė: vaizdų vamzdynas (WebP/AVIF), šriftų subdetalizavimas, kritinės reikšmės CSS generavimas, CI patikrinimai ir įspėjimai. Pabaigoje pateikiami aiškūs pagrindiniai skaičiai, kuriuos ateityje diegsiu.
Santrauka: Kam teikiu pirmenybę
Geriau Interaktyvumas Aš matuoju švariai, atleidžiu pagrindinę giją ir pasikliauju greita priegloba su aiškia spartinančiosios talpyklos koncepcija. Nuosekliai mažinu "JavaScript", vėliau įkraunu trečiąsias šalis ir laikau mažus svarbiausius išteklius. "WordPress" naudą teikia taupios temos, atnaujinti įskiepiai ir stiprus talpyklos stekas. Atskirai tikrinu TTFB, kad galėčiau atpažinti vėlavimų kilmę. Dėl to svetainė atrodo greita, patikimai reaguoja ir pasiekia apčiuopiamai daugiau sąveikų.
