
„Google Lighthouse“ savo standartiniuose bandymuose nenaudoja „Interaction to Next Paint“ (INP) metrikos, nepaisant to, kad INP yra vienas iš pagrindinių žiniatinklio elementų.
Barry Pollardas, žiniatinklio našumo kūrėjų advokatas „Google Chrome“, paaiškino to priežastis ir pateikė įžvalgų apie INP matavimą.
Švyturys matuoja puslapio apkrovą, o ne sąveiką
Švyturys matuoja paprastą puslapio įkėlimą ir to proceso metu užfiksuoja įvairias charakteristikas.
Jis gali įvertinti didžiausią turinio dažymą (LCP) ir kaupiamąjį išdėstymo poslinkį (CLS) konkrečiomis apkrovos sąlygomis, nustatyti problemas ir patarti, kaip pagerinti šiuos rodiklius.
Tačiau INP skiriasi, nes priklauso nuo vartotojo sąveikos.
Pollard paaiškino:
„Problema ta, kad „Lighthouse“, kaip ir daugelis žiniatinklio tobulinimo įrankių, paprastai tiesiog įkelia puslapį ir su juo nesąveikauja. Nėra sąveikos = nėra INP, kurį būtų galima išmatuoti!
Pasirinktiniai naudotojų srautai įgalina INP matavimą
Nors „Lighthouse“ negali išmatuoti INP, žinant įprastas naudotojų keliones, galite naudoti „naudotojų srautus“ INP matuoti.
Pollard pridūrė:
„Jei jūs, kaip svetainės savininkas, žinote savo įprastas naudotojų keliones, galite jas išmatuoti „Lighthouse“ naudodami „naudotojų srautus“, kurie BŪS INP matuoti.
Šios įprastos naudotojų kelionės gali būti automatizuotos nuolatinėje integravimo aplinkoje, leidžiančios kūrėjams išbandyti INP kiekvieno įsipareigojimo metu ir pastebėti galimas regresijas.
Bendras blokavimo laikas kaip INP tarpinis serveris
Nors „Lighthouse“ negali išmatuoti INP be sąveikos, jis gali įvertinti galimas priežastis, ypač ilgas, blokuojančias „JavaScript“ užduotis.
Čia pradedama naudoti viso blokavimo laiko (TBT) metrika.
Pasak Polardo:
„TBT (bendras blokavimo laikas) matuoja visų užduočių, ilgesnių nei 50 ms, suminį laiką. Teorija tokia:
- Daug ilgų, blokuojančių užduočių = didelė INP rizika!
- Keletas ilgų, blokuojančių užduočių = maža INP rizika!
TBT, kaip INP pakaitalo, apribojimai
TBT kaip INP pakaitalas turi apribojimų.
Pollard pažymėjo:
„Jei nebendraujate atlikdami ilgas užduotis, galite neturėti jokių INP problemų. Be to, sąveika gali įkelti DAUGIAU „JavaScript“, kurios neįvertina „Lighthouse“.
Jis priduria:
„Taigi tai yra užuomina, bet ne pakaitalas faktiniam INP matavimui.
„Lighthouse“ balų optimizavimas, palyginti su naudotojo patirtimi
Kai kurie kūrėjai optimizuoja „Lighthouse“ balus neatsižvelgdami į poveikį vartotojui.
Pollardas įspėja apie tai, sakydamas:
„Įprastas modelis, kurį matau, yra atidėti VISUS JS, kol vartotojas sąveikauja su puslapiu: puikiai tinka „Lighthouse“ balams! Dažnai baisu vartotojams 😢:
- Kartais niekas neįkeliama tol, kol nepajudini pelės.
- Dažnai jūsų pirmoji sąveika vėluoja ilgiau.
Visas Polardo pranešimas
Kodėl tai svarbu
Norint optimizuoti vartotojo patirtį, būtina suprasti Švyturio, INP ir TBT ryšius.
INP matavimo apribojimų pripažinimas padeda išvengti klaidingo optimizavimo.
Pollardo patarimas matuojant INP yra sutelkti dėmesį į realią vartotojo sąveiką, kad būtų užtikrintas našumo patobulinimas, pagerinantis UX.
Kadangi INP išlieka pagrindiniu interneto gyvybiniu elementu, norint išlaikyti jį priimtinos ribos, būtina suvokti jo niuansus.
Praktiniai pritaikymai
Norėdami stebėti svetainės našumą ir INP:
- Naudokite „Lighthouse“ „vartotojų srautus“ INP matavimui įprastose kelionėse.
- Automatizuokite vartotojų srautus CI, kad galėtumėte stebėti INP ir užfiksuoti regresijas.
- Naudokite TBT kaip INP tarpinį serverį, tačiau supraskite jo apribojimus.
- Suteikite pirmenybę lauko matavimams, kad gautumėte tikslius INP duomenis.
- Subalansuokite našumo optimizavimą atsižvelgiant į UX.
Teminis vaizdas: Ye Liew / Shutterstock