Google Lighthouse - przydatne narzędzie do audytu stron internetowych
· maciej
Google Lighthouse to zdobywające coraz większą popularność narzędzie do audytu stron internetowych, które pomaga w podniesieniu ich jakości w niektórych obszarach. Narzędzie jest wbudowane w DevToolsy w Google Chrome (uruchamiane klawiszem F12). Od tego roku dostępne jest także jako wtyczka do Firefoksa. Znajdziemy je również jako moduł do Node.js. Narzędzie umożliwia audyt strony pod kątem:
- wydajności,
- zgodności z PWA (Progressive Web App),
- stosowania dobrych praktyk,
- dostępności (accessibility),
- SEO.
Do wyboru jest audyt zarówno w wersji desktopowej, jak i mobilnej (emulujący urządzenia mobilne). Raport z testowania daje bardzo przydatne wskazówki co do obszarów, które mogą nam umknąć podczas normalnego testowania funkcjonalnego a mają znaczenie w testach niefunkcjonalnych (np. testach dostępności), o których często się zapomina. Nie ważne, czy jesteś testerem, programistą, czy prowadzisz zwykły blog, czy stronę firmową - to narzędzie dostarczy Ci wartościowych informacji o stanie dowolnej strony i cenne wskazówki poprawy.
Lighthouse
Google Lighthouse to narzędzie z otwartym kodem źródłowym, który dostępny jest na Githubie. Używam go dosyć często tuż przed wdrożeniem nowych wersji swoich stron. Pomaga wychwycić pewne niuanse, które możemy przeoczyć podczas webmasteringu a mogą mieć istotną rolę np. w indeksowaniu przez przeglądarki. Warto także przyjrzeć się opcji emulowania urządzeń mobilnych. Często nasza strona może osiągać dobre wyniki przy wybraniu opcji desktop a możemy się niemile zaskoczyć, jeśli wykonamy audyt pod kątem urządzeń mobilnych. Warto o tym pamiętać, bo obecnie dostosowanie strony pod kątem smartfonów i tabletów to podstawa. Dla kogo to narzędzie? W zasadzie dla każdego posiadacza strony internetowej, jak i programisty, testera i innych osób, które troszczą się o jakość.
W przypadku dużych projektów warto zadbać, aby testy odbywały automatycznie w ramach Continuous Integration (CI) - np. w ramach Github Actions.
Użycie
Użycie narzędzia jest bardzo proste, zwłaszcza jeżeli korzystamy z przeglądarki Google Chrome. Wystarczy:
- wcisnąć przycisk F12, który otwiera narzędzia developera (znane wszystkim programistom web),
- przejść do ostatniej zakładki Lighthouse,
- wybrać interesujące nas kategorie audytu,
- wybrać urządzenie (mobile/desktop),
- kliknąć przycisk [Generate report] i czekać na wynik.
W przypadku Lighthouse jako wtyczki do Firefoksa jest to również bardzo proste:
- należy zainstalować wtyczkę dostępną tutaj,
- po zainstalowaniu wybrać ikonkę latarni, która pojawiła się na pasku w przeglądarce,
- kliknąć koło zębate jeżeli chcemy zmienić ustawienia,
- kliknąć przycisk [Generate report] i czekać na wynik.
Wyniki ukazane są w bardzo przystępny i intuicyjny sposób i aż zachęcają, aby je poprawić. Możemy je zapisać, aby mieć porównanie do stanu po wprowadzonych poprawkach. Raport można podejrzeć na stronie https://googlechrome.github.io/lighthouse/viewer/.
Wydajność (Performance)
W Lighthouse 6 w wyznaczaniu metryki performance (przedział 1-100) brane są pod uwagę wartości o poniższych wagach:
Składowa | Opis | Waga |
---|---|---|
First Contentful Paint | Czas od momentu rozpoczęcia ładowania do załadowania pierwszego elementu treści - tekst, obrazek (wliczając obrazek tła), elementy <svg> i niepuste elementy <canvas> | 15% |
Speed Index | Wskaźnik mierzy czas, jak szybko zawartość witryny jest wizualnie wyświetlana podczas ładowania strony. Jest to określane za pomocą mierzenia wizualnej progresji pomiędzy klatkami wideo z ładowania strony. | 15% |
Largest Contentful Paint | Metryka wskazuje czas renderowania największego bloku obrazu lub tekstu widocznego w viewporcie. | 25% |
Time to Interactive | Metryka TTI mierzy czas od momentu rozpoczęcia ładowania strony do momentu załadowania jej głównych zależności i możliwości interakcji z witryną przez użytkownika. | 15% |
Total Blocking Time | Metryka TBT mierzy całkowity czas pomiędzy FCP (First Contentful Paint) a TTI (Time to Interactive), kiedy główny wątek jest zablokowany i nie pozwala na interakcję z witryną. | 25% |
Cumulative Layout Shift | CLS to miara wszystkich indywidualnych zmian układu (layout shift), które występują podczas użytkowania strony. Szczegóły tutaj. | 5% |
Dostępność (Accessibility)
Kategoria accessibility weryfikuje czy strona jest dostosowana do czytników ekranu oraz, czy jej elementy są odpowiednio kontrastowe. Dobór odpowiednich kolorów na stronie pomaga ludziom z zaburzeniami rozpoznawania barw. Te pierwsze to głównie weryfikacja atrybutów ARIA, opisów grafik (znacznik alt), czy np. sprawdzenie uzupełnionego tagu <title>.
Na elementy audytu składają się także sprawdzenia, które nie są wykonywane automatycznie i mogą być wykonane jedynie ręcznie (10 elementów). Ich lista jest dostępna w raporcie, pod kategorią Additional items to manually check.
Dobre praktyki (Best practices)
Poszczególne sprawdzenia weryfikują stosowanie ogólnych dobrych praktyk na stronie. Niektóre z nich to:
- brak deklaracji DOCTYPE w HTML,
- brak wyświetlanych błędów w konsoli przeglądarki,
- brak obrazków z nieodpowiednim ratio,
- nieużywanie HTTP/2,
- nieużywanie HTTPS,
- używanie bibliotek JavaSriptowych ze znanymi podatnościami,
- niewymuszanie podania zgody użytkownika na geolokalizację przy ładowaniu strony.
I inne. Więcej można znaleźć na stronie web.dev.
Search Engine Optimization (SEO)
Na liście dotyczącej SEO jest 15 pozycji, z czego jedna do weryfikacji ręcznej (weryfikacja uporządkowanych danych (structured data). Na liście automatycznych weryfikacji są m.in.:
- obecność tagu <meta name="viewport"> z właściwościami width albo initial-scale.
- istniejący tag <title>
- uzupełnione meta description
- poprawność pliku robots.txt
- indeksowalność linków
W tym wpisie pominąłem jeszcze jedną kategorię - Progressive Web App. Wydaję się, że aplikacje PWA szybko nie staną się standardem.
Źródła:
Dodaj nowy komentarz
@Marcin · 14 lipca 2021 22:20
Zabrakło 1 punktu, żeby lighthouse wybuchło :D :D