Kaip skaityti Lighthouse ataskaitą nepanikuojant

Pirma taisyklė: jūsų balas nėra jūsų svetainė

Pirmą kartą atsidarius Lighthouse ataskaitą, jus pasitinka skaičių siena, spalvomis pažymėti langeliai ir įspėjimai apie dalykus, apie kuriuos niekada negirdėjote. Natūrali reakcija — panika. Balas raudonas. Septyniolika auditų nepavyko. Vadinasi, svetainė sugedusi?

Greičiausiai ne. Lighthouse yra diagnostikos įrankis, o ne pažymių knygelė. Balas yra sintetinis etaloninis testas, vykdomas laboratorinėmis sąlygomis — dažnai su dirbtinai apribotu ryšiu, imituojant vidutinės klasės 2017 m. telefoną. Jis parodo, kaip jūsų svetainė veikia būtent tokiame scenarijuje, o ne kaip ją realiame pasaulyje patiria tikri naudotojai.

Tai svarbu, nes dauguma komandų užsifiksuoja ties balu ir praleidžia kontekstą. 65 balai gali būti visiškai priimtini sudėtingai žiniatinklio programai su realiojo laiko duomenimis. 95 balai vis tiek gali reikšti prastą patirtį, jei optimizuoti ne tie dalykai. Balas yra tyrimo pradžios taškas, o ne sėkmės metrika.

Ką skaityti pirmiausia: Core Web Vitals

Praleiskite bendrą našumo balą. Slinkite žemyn iki skilties Metrics ir pažiūrėkite į tris skaičius: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) ir Interaction to Next Paint (INP). Tai yra Core Web Vitals, ir tai vienintelės našumo metrikos, kurias Google naudoja kaip reitingavimo signalą.

• LCP matuoja, kiek laiko užtrunka atvaizduoti didžiausią matomą elementą. Tikslas: mažiau nei 2,5 sekundės. Jei viršijate 4 sekundes, naudotojai per ilgai laukia, kol pamatys prasmingą turinį.
• CLS matuoja vizualinį stabilumą — kiek puslapis šokinėja kraunantis. Tikslas: mažiau nei 0,1. Jei viršijate 0,25, naudotojai netyčia spaudžia ne ten, nes mygtukai pajudėjo.
• INP matuoja reagavimą — kaip greitai puslapis reaguoja į paspaudimus, bakstelėjimus ir klavišų įvedimą. Tikslas: mažiau nei 200 ms. Jei viršijate 500 ms, svetainė jaučiasi vangi.

Šios trys metrikos koreliuoja su tikru naudotojų susierzinimu. Tvarkykite jas prieš rūpindamiesi kuo nors kitu.

Opportunities ir Diagnostics: žinokite skirtumą

Lighthouse savo išvadas skirsto į dvi kategorijas: Opportunities ir Diagnostics. Opportunities rikiuojamos pagal apskaičiuotą sutaupomą laiką. Diagnostics yra papildomas kontekstas — dalykai, kurie gali būti problemos, o gali ir nebūti.

Pradėkite nuo Opportunities. Jei Lighthouse sako, kad „Eliminate render-blocking resources“ galėtų sutaupyti 1,2 sekundės, tai konkretus laimėjimas. Jei sako, kad „Reduce unused JavaScript“ galėtų sutaupyti 0,1 sekundės, veikiausiai dėl to neverta imtis refaktoringo.

Su Diagnostics sudėtingiau. „Avoid an excessive DOM size“ skamba blogai, bet jei jūsų CLS geras, o INP greitas, didelis DOM galbūt niekam nekenkia. Diagnostics yra užuominos, o ne privalomi nurodymai. Tirkite tas, kurios dera su jūsų faktinėmis metrikomis.

Auditai, kuriuos paprastai galite ignoruoti

Kai kurie Lighthouse įspėjimai yra pasenę arba pernelyg agresyvūs. Štai tie, kurie dažniausiai sukelia nereikalingą paniką:

• „Does not use passive listeners to improve scrolling performance“ — Tai mikrooptimizacija, kuri retai turi apčiuopiamą poveikį. Jei neturite įrodymų, kad slinkimas trūkčioja, praleiskite.
• „Image elements do not have explicit width and height“ — Tai svarbu CLS, bet tik tada, jei vaizdai sukelia išdėstymo poslinkius. Jei jūsų CLS jau geras, nereikia refaktoringo vien dėl audito.
• „Serve images in next-gen formats“ — Taip, WebP ir AVIF yra mažesni. Bet jei jūsų vaizdai jau optimizuoti, o LCP greitas, tai malonus patobulinimas, ne krizė.
• „Avoid enormous network payloads“ — Lighthouse pažymi viską, kas viršija 1,6 MB. Tačiau 2 MB puslapis, kuris kraunasi greitai, yra geriau nei 500 KB puslapis, blokuojantis atvaizdavimą. Sutelkite dėmesį į tai, kaip baitai pristatomi, o ne vien į bendrą kiekį.

Ką daryti, kai viskas raudona

Jei jūsų Lighthouse balas mažesnis nei 50 ir dauguma auditų nepavyksta, greičiausiai susiduriate su viena iš trijų pagrindinių priežasčių:

1. Neoptimizuoti šriftai. Web fonts vis dar yra lengviausias našumo laimėjimas daugumoje svetainių. Patikrinkite, ar nekraunate šešių šrifto storių, kai naudojate tik du, arba ar nesiunčiate WOFF failų vietoje WOFF2.
2. Atvaizdavimą blokuojantys CSS ir JavaScript. Jei jūsų First Contentful Paint (FCP) viršija 3 sekundes, kažkas trukdo naršyklei piešti puslapį. Ieškokite didelių CSS failų arba sinchroninių skriptų <head> dalyje.
3. Per dideli vaizdai. Jei jūsų LCP elementas yra vaizdas ir jis sveria 4 MB, tai ir yra problema. Suspauskite jį, žemiau pirmo ekrano esančius vaizdus įkelkite tingiai ir naudokite adaptyvių vaizdų sintaksę.

Ištaisykite vieną iš šių dalykų ir paleiskite Lighthouse iš naujo. Dažnai pamatysite 20–30 punktų šuolį. Tada imkitės kito.

Laboratoriniai duomenys ir realių naudotojų duomenys: tikrovės patikra

Lighthouse veikia laboratorijoje. Jis imituoja lėtą ryšį ir lėtą įrenginį, bet negali imituoti tikro naudotojų elgesio — kaip žmonės slenka, ką spaudžia, ar jie naudoja nestabilų Wi-Fi.

Tikrovės patikrai palyginkite savo Lighthouse rezultatus su field data iš Chrome User Experience Report (CrUX). CrUX rodo, kaip tikri Chrome naudotojai patyrė jūsų svetainę per pastarąsias 28 dienas. Jei Lighthouse sako, kad jūsų LCP yra 4 sekundės, bet CrUX rodo 2 sekundes, pasitikėkite CrUX. Jei abu rodikliai prasti, turite tikrą problemą.

CrUX duomenis galite rasti PageSpeed Insights (žiniatinklio Lighthouse versijoje) arba Google Search Console skiltyje „Core Web Vitals“. Jei yra neatitikimas, išsiaiškinkite kodėl. Gal jūsų tikri naudotojai naudoja greitesnius tinklus. Gal Lighthouse testuoja neoptimizuotą kūrimo versiją.

Kada paleisti Lighthouse iš naujo

Lighthouse yra triukšmingas. Paleiskite jį tris kartus iš eilės ir gausite tris skirtingus balus, net tame pačiame puslapyje. Taip yra todėl, kad našumas kinta — foniniai procesai, tinklo svyravimai ir naršyklės heuristikos veikia rezultatą.

Kad gautumėte stabilesnį atskaitos tašką, paleiskite Lighthouse inkognito režimu su išjungtais visais plėtiniais arba naudokite CLI su --preset=desktop vėliavėle, kad rezultatai būtų nuoseklesni. Paleiskite tris kartus ir išveskite balų vidurkį. Jei matote didelius svyravimus (daugiau nei 10 punktų), kažkas negerai kitur — gal serveris lėtas, o gal puslapis kiekvieną kartą krauna skirtingus išteklius.

Paleiskite Lighthouse iš naujo po kiekvieno reikšmingo pakeitimo. Įdiegėte naują šriftų strategiją? Patikrinkite LCP. Įjungėte tingų vaizdų įkėlimą? Patikrinkite CLS. Pridėjote trečiosios šalies skriptą? Patikrinkite INP. Našumas nėra vienkartinis pataisymas; tai biudžetas, kurį saugote.

Įrankiai, padedantys veikti pagal Lighthouse išvadas

Lighthouse pasako, kas lėta. Jis ne visada pasako, kaip tai pataisyti. Tam reikia papildomų įrankių:

• WebPageTest pateikia kadrų juostos vaizdą, kaip puslapis kraunasi, kadras po kadro. Būtina diagnozuojant LCP ir CLS problemas.
• Chrome DevTools Performance panel tiksliai parodo, kuris JavaScript blokuoja pagrindinę giją. Naudokite jį blogo INP balo šaltiniui rasti.
• Vaizdų glaudinimo įrankiai leidžia optimizuoti vaizdus tiesiai naršyklėje — tai greičiau ir privatumui palankiau nei įkėlimas į trečiosios šalies paslaugą. Vaizdų apdorojimas kliento pusėje yra privatumo laimėjimas, nes jūsų vaizdai niekada nepalieka jūsų kompiuterio.

Lighthouse yra pradžios taškas. Šie įrankiai padeda užbaigti darbą.

Pagrindinės išvados

• Jūsų Lighthouse balas yra laboratorinis etalonas, o ne realaus pasaulio naudotojo patirties matas. Prieš panikuodami palyginkite jį su CrUX field data.
• Pirmiausia sutelkite dėmesį į Core Web Vitals (LCP, CLS, INP). Tai metrikos, kurios koreliuoja su naudotojų susierzinimu ir SEO poveikiu.
• Opportunities prioritetizuokite pagal apskaičiuotą sutaupomą laiką. Ignoruokite Diagnostics, kurios nesutampa su jūsų faktinėmis našumo problemomis.
• Kai kurie auditai — pavyzdžiui, pasyvūs klausytojai ar naujos kartos vaizdų formatai — yra mikrooptimizacijos. Pirmiausia taisykite didelius dalykus.
• Paleiskite Lighthouse tris kartus ir išveskite rezultatų vidurkį. Našumas kinta, todėl vienas paleidimas gali klaidinti.

FAQ

Q: Kodėl mano Lighthouse balas keičiasi kiekvieną kartą, kai jį paleidžiu?
A: Lighthouse matuoja našumą kintančiomis sąlygomis — tinklo greitis, CPU apkrova ir naršyklės heuristikos veikia rezultatą. Paleiskite jį tris kartus inkognito režimu ir išveskite balų vidurkį, kad gautumėte stabilesnį atskaitos tašką.

Q: Ar pirmiausia optimizuoti mobiliesiems, ar darbalaukiui?
A: Mobiliesiems. Lighthouse pagal numatymą naudoja mobiliojo įrenginio simuliaciją, nes didžioji dalis žiniatinklio srauto yra mobili, o mobilieji įrenginiai lėtesni. Jei jūsų mobilusis balas geras, darbalaukio balas paprastai taip pat bus geras.

Q: Mano Lighthouse balas yra 95, bet svetainė vis tiek atrodo lėta. Kas negerai?
A: Lighthouse matuoja puslapio įkėlimą, o ne interaktyvumą po įkėlimo. Patikrinkite INP balą ir naudokite Chrome DevTools Performance panel, kad profiliuotumėte, kas vyksta naudotojams spaudžiant ar slenkant. Gali būti, kad turite JavaScript problemą, kurios Lighthouse nepagauna.

Q: Ar man reikia tobulo 100 balų rezultato?
A: Ne. 90+ balų yra puikus rezultatas. 100 vaikymasis dažnai reiškia dalykų, kurie naudotojams nesvarbūs, optimizavimą. Susitelkite į tikras metrikas — LCP, CLS, INP — ir ignoruokite balą.

Q: Ar galiu pasitikėti Lighthouse, jei naudoju daug trečiųjų šalių skriptų?
A: Lighthouse pažymės trečiųjų šalių skriptus kaip problemą, bet ne visada gali atskirti būtinus nuo nebūtinų. Naudokite „Avoid enormous network payloads“ ir „Reduce JavaScript execution time“ auditus, kad nustatytumėte didžiausius kaltininkus, tada nuspręskite, ar verta juos palikti.

Šaltiniai

• „Lighthouse performance scoring“ — Google Developers
• „Core Web Vitals“ — web.dev
• „Chrome User Experience Report“ — Google Developers
• „WebPageTest Documentation“ — WebPageTest.org