Znajdowanie możliwości poprawy wrażeń użytkownika za pomocą narzędzi internetowych Chrome.
Opublikowano: 11 maja 2021 r.
Dzisiaj omówimy nowe funkcje narzędzi Lighthouse, PageSpeed i Narzędzia deweloperskie, które pomogą Ci określić, jak możesz poprawić wyniki witryny w Web Vitals.
Przypominamy, że Lighthouse to zautomatyzowane narzędzie typu open source służące do poprawy jakości stron internetowych. Znajdziesz je w pakiecie narzędzi do debugowania Narzędzia deweloperskie w Chrome. Możesz go użyć na dowolnej stronie internetowej, publicznej lub wymagającej uwierzytelnienia. Lighthouse znajdziesz też w PageSpeed Insights, CI i WebPageTest.
Lighthouse 7.x zawiera nowe funkcje, takie jak zrzuty ekranu elementów, które ułatwiają wizualną kontrolę części interfejsu użytkownika wpływających na dane dotyczące wrażeń użytkownika (np. które węzły przyczyniają się do przesunięcia układu).
Wprowadziliśmy też obsługę zrzutów ekranu elementów w PageSpeed Insights, co ułatwia wykrywanie problemów podczas jednorazowych testów wydajności stron.
Pomiar Core Web Vitals
Lighthouse może syntetycznie mierzyć podstawowe wskaźniki internetowe, w tym największe wyrenderowanie treści, skumulowane przesunięcie układu i łączny czas blokowania (laboratoryjny odpowiednik opóźnienia przy pierwszym działaniu). Te dane odzwierciedlają wczytywanie, stabilność układu i gotowość do interakcji. Są tam też inne dane, takie jak pierwsze wyrenderowanie treści, które zostały wyróżnione w Core Web Vitals.
Sekcja „Dane” w raporcie Lighthouse zawiera wersje laboratoryjne tych danych. Możesz go używać jako podsumowania aspektów wygody użytkowników, które wymagają Twojej uwagi.
Dane z pól, takie jak te, które można znaleźć w Raporcie na temat użytkowania Chrome lub RUM, nie mają tego ograniczenia i stanowią cenne uzupełnienie danych laboratoryjnych, ponieważ odzwierciedlają wrażenia rzeczywistych użytkowników. Dane zgromadzone w środowisku produkcyjnym nie zawierają informacji diagnostycznych, które można uzyskać w laboratorium, dlatego te 2 rodzaje danych się uzupełniają.
Identyfikowanie obszarów, w których można poprawić wskaźniki Web Vitals
Określanie elementu największego wyrenderowania treści
LCP to pomiar postrzeganej szybkości wczytywania. Oznacza moment podczas wczytywania strony, w którym główna, czyli „największa”, treść została wczytana i jest widoczna dla użytkownika.
Lighthouse ma kontrolę „Największy wyrenderowany element treści”, która określa, który element był największym wyrenderowanym elementem treści. Najedź kursorem na element, aby wyróżnić go w głównym oknie przeglądarki.
Jeśli ten element jest obrazem, ta informacja jest przydatną wskazówką, że warto zoptymalizować wczytywanie tego obrazu. Lighthouse zawiera szereg kontroli optymalizacji obrazów, które pomogą Ci zrozumieć, czy obrazy można lepiej skompresować, zmienić ich rozmiar lub dostarczyć w bardziej optymalnym, nowoczesnym formacie pliku graficznego.
Możesz też użyć skryptozakładki LCP autorstwa Annie Sullivan, aby szybko zidentyfikować element LCP za pomocą czerwonego prostokąta jednym kliknięciem.
Wstępnie wczytuj obrazy wykryte później, aby poprawić LCP
Aby poprawić największe wyrenderowanie treści, wstępnie wczytaj najważniejsze banery powitalne, jeśli przeglądarka wykrywa je z opóźnieniem. Późne wykrycie może nastąpić, jeśli przed wykryciem obrazu konieczne jest załadowanie pakietu JavaScriptu.
Istnieje kilka często zadawanych pytań dotyczących wstępnego wczytywania obrazów LCP, które warto krótko omówić.
Czy można wstępnie wczytywać obrazy elastyczne? Tak.
Załóżmy, że mamy elastyczny baner powitalny określony za pomocą tagów srcset i sizes, jak poniżej:
<img src="lighthouse.jpg"
srcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">
Dzięki atrybutom imagesrcset i imagesizes dodanym do atrybutu link możemy wstępnie wczytać obraz elastyczny, korzystając z tej samej logiki wyboru obrazu, która jest używana przez srcset i sizes:
<link rel="preload" as="image" href="lighthouse.jpg"
imagesrcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w"
imagesizes="50vw">
Czy kontrola będzie też wskazywać możliwości wstępnego wczytywania, jeśli obraz LCP jest zdefiniowany za pomocą tła CSS? Tak.
Każdy obraz oznaczony jako obraz LCP, czy to za pomocą tła CSS, czy <img>, jest kandydatem, jeśli zostanie wykryty na głębokości wodospadu równej 3 lub większej.
Leniwe ładowanie obrazów poza ekranem i unikanie tego w przypadku LCP
Obrazy poza ekranem, które nie są kluczowe dla początkowych wrażeń użytkownika, można ładować leniwie. Jest to technika, która opóźnia pobieranie obrazu, dopóki użytkownik nie przewinie strony w jego pobliże. Może to zmniejszyć obciążenie sieci w przypadku kluczowych zasobów, a w niektórych przypadkach poprawić LCP. W tym przypadku może pomóc kontrola „Opóźnij wyświetlanie obrazów poza ekranem”:
Krytyczne obrazy w części strony widocznej na ekranie, takie jak obraz największego wyrenderowania treści, nie powinny być ładowane leniwie. Może to opóźnić wczytywanie obrazu LCP. Lighthouse wyróżni obraz LCP, który jest nieprawidłowo ładowany w trybie leniwego ładowania, za pomocą kontroli „Obraz największego wyrenderowania treści został załadowany w trybie leniwego ładowania”:
Identyfikowanie czynników wpływających na CLS
Skumulowane przesunięcie układu to miara stabilności wizualnej. Określa, jak bardzo treść strony przesuwa się wizualnie. Lighthouse ma audyt do debugowania CLS o nazwie „Unikaj dużych przesunięć układu”.
Ta kontrola wskazuje elementy DOM, które mają największy wpływ na przesunięcia strony. W kolumnie Element po lewej stronie zobaczysz listę tych elementów DOM, a po prawej ich ogólny wpływ na CLS.
Dzięki nowej funkcji zrzutów ekranu elementów w Lighthouse możemy zobaczyć podgląd wizualny kluczowych elementów odnotowanych w audycie, a także kliknąć, aby powiększyć i uzyskać wyraźniejszy widok:
W przypadku CLS po wczytaniu warto stale wizualizować za pomocą prostokątów, które elementy miały największy wpływ na CLS. Tę funkcję znajdziesz w narzędziach innych firm, takich jak panel podstawowych wskaźników internetowych firmy SpeedCurve. Ja chętnie korzystam z narzędzia Layout Shift GIF Generator firmy Defaced:
Aby uzyskać widok problemów z przesunięciem układu w całej witrynie, korzystam z raportu Podstawowe wskaźniki internetowe w Search Console. Dzięki temu mogę zobaczyć, jakie strony w mojej witrynie mają wysoki wskaźnik CLS (w tym przypadku pomaga to określić, na których częściach szablonu muszę się skupić):
Identyfikowanie CLS na podstawie obrazów bez wymiarów
Aby ograniczyć skumulowane przesunięcie układu spowodowane przez obrazy bez wymiarów, dodaj do elementów graficznych i wideo atrybuty szerokości i wysokości. Dzięki temu przeglądarka może przydzielić odpowiednią ilość miejsca w dokumencie podczas wczytywania obrazu.
Więcej informacji o tym, dlaczego warto zwracać uwagę na wymiary i format obrazu, znajdziesz w artykule Setting Height And Width On Images Is Important Again (w języku angielskim).
Identyfikowanie CLS z reklam
Publisher Ads for Lighthouse pozwala znaleźć możliwości poprawy ładowania reklam na stronie, w tym przesunięcia układu i długie zadania, które mogą opóźnić moment, w którym użytkownicy mogą zacząć korzystać ze strony. W Lighthouse możesz to włączyć za pomocą wtyczek społeczności.
Pamiętaj, że reklamy są jednym z największych czynników wpływających na przesunięcia układu w internecie. Ważne jest, aby:
- Zachowaj ostrożność podczas umieszczania reklam nieprzyklejonych w pobliżu górnej krawędzi widocznego obszaru
- Wyeliminuj przesunięcia, rezerwując największy możliwy rozmiar boksu reklamowego.
Unikaj nieskomponowanych animacji
Nieskomponowane animacje mogą działać nieprawidłowo na urządzeniach niższej klasy, jeśli ciężkie zadania JavaScriptu obciążają główny wątek. Takie animacje mogą powodować przesunięcia układu.
Jeśli Chrome wykryje, że animacji nie można skomponować, zgłasza to w śladzie Narzędzi deweloperskich, który Lighthouse odczytuje, co pozwala mu wyświetlić listę elementów z animacjami, które nie zostały skomponowane, i podać przyczynę. Możesz je znaleźć w audycie Unikaj nieskomponowanych animacji.
Debugowanie opóźnienia przy pierwszym działaniu / łącznego czasu blokowania / długich zadań
Opóźnienie przy pierwszym działaniu to czas, jaki minął od pierwszej interakcji użytkownika ze stroną (np. kliknięcia linku lub przycisku albo użycia niestandardowego elementu sterującego opartego na JavaScript) do momentu, w którym przeglądarka może faktycznie rozpocząć przetwarzanie modułów obsługi zdarzeń w odpowiedzi na tę interakcję. Długie zadania JavaScriptu mogą wpływać na te dane i na ich przybliżoną wartość, czyli łączny czas blokowania.
Lighthouse zawiera kontrolę Unikaj długich zadań w głównym wątku, która wyświetla najdłuższe zadania w głównym wątku. Może to być przydatne do identyfikowania czynników, które mają największy wpływ na opóźnienia działania. W lewej kolumnie widać adresy URL skryptów odpowiedzialnych za długie zadania w głównym wątku.
Po prawej stronie widać czas trwania tych zadań. Przypominamy, że długie zadania to zadania, które wykonują się dłużej niż 50 milisekund. Uważa się, że blokuje to wątek główny na tyle długo, że wpływa na liczbę klatek lub opóźnienie danych wejściowych.
Jeśli rozważasz korzystanie z usług innych firm do monitorowania, polecam też oś czasu wykonywania w głównym wątku, którą Calibre udostępnia do wizualizacji tych kosztów. Wyróżnia ona zarówno zadania nadrzędne, jak i podrzędne, które przyczyniają się do długich zadań wpływających na interaktywność.
Blokowanie żądań sieciowych, aby zobaczyć wpływ przed i po w Lighthouse
Narzędzia deweloperskie w Chrome obsługują blokowanie żądań sieciowych, co pozwala sprawdzić, jaki wpływ ma usunięcie lub niedostępność poszczególnych zasobów. Może to być przydatne do zrozumienia wpływu poszczególnych skryptów (np.elementów osadzonych lub modułów śledzących innych firm) na dane takie jak łączny czas blokowania (TBT) i czas do pełnej interaktywności.
Blokowanie żądań sieciowych działa też z Lighthouse. Przyjrzyjmy się raportowi Lighthouse dla witryny. Wynik wydajności to 63/100, a TBT wynosi 400 ms. Analizując kod, odkrywamy, że ta witryna wczytuje w Chrome polyfill Intersection Observer, co nie jest konieczne. Zablokujmy go!
Możemy kliknąć prawym przyciskiem myszy skrypt w panelu Sieć w Narzędziach deweloperskich i kliknąć Block Request URL, aby go zablokować. W tym przypadku zrobimy to dla kodu polyfill Intersection Observer.
Następnie możemy ponownie uruchomić Lighthouse. Tym razem widzimy, że wynik wydajności się poprawił (70/100), podobnie jak łączny czas blokowania (400 ms => 300 ms).
Zastąp kosztowne elementy osadzone z innych witryn komponentem fasadowym
Zasoby innych firm są często używane do umieszczania na stronach filmów, postów w mediach społecznościowych lub widżetów. Domyślnie większość elementów osadzonych wczytuje się od razu i może zawierać duże ładunki, które negatywnie wpływają na wrażenia użytkownika. Jest to nieefektywne, jeśli zasób zewnętrzny nie jest kluczowy (np. jeśli użytkownik musi przewinąć stronę, aby go zobaczyć).
Jednym ze sposobów na poprawę wydajności takich widżetów jest leniwe ładowanie ich po interakcji użytkownika. Można to zrobić, renderując lekki podgląd widżetu (fasadę) i wczytując pełną wersję tylko wtedy, gdy użytkownik wejdzie z nim w interakcję. Lighthouse przeprowadza kontrolę, która poleca zasoby innych firm, które można załadować leniwie za pomocą fasady, np. filmy na YouTube.
Przypominamy, że Lighthouse wyróżnia kod innych firm, który blokuje główny wątek na ponad 250 ms. Może to ujawnić różne skrypty innych firm (w tym te utworzone przez Google), które warto odroczyć lub zastosować leniwe ładowanie, jeśli to, co renderują, wymaga przewijania.
Poza Core Web Vitals
Oprócz wyróżniania podstawowych wskaźników internetowych najnowsze wersje Lighthouse i PageSpeed Insights zawierają też konkretne wskazówki, jak przyspieszyć wczytywanie aplikacji internetowych z dużą ilością kodu JavaScript, jeśli masz włączone mapy źródeł.
Obejmują one coraz większą kolekcję kontroli, które pozwalają zmniejszyć koszt JavaScriptu na stronie, np. przez ograniczenie polegania na polyfillach i duplikatach, które mogą nie być potrzebne do zapewnienia wygody użytkowników.
Więcej informacji o narzędziach Core Web Vitals znajdziesz na koncie na Twitterze zespołu Lighthouse i w artykule What's new in DevTools (Co nowego w Narzędziach deweloperskich).