Omówienie
Użyj panelu Lighthouse, aby przeprowadzić kompleksowy audyt swojej witryny. Panel Lighthouse generuje raport, który zawiera te informacje o Twojej witrynie:
- Wyniki
- Ułatwienia dostępu
- Sprawdzone metody
- SEO
... i wiele innych danych.
Ten samouczek pomoże Ci zacząć korzystać z Lighthouse w Narzędziach deweloperskich w Chrome.
Więcej informacji o tym, jak Lighthouse może poprawiać jakość witryny, znajdziesz w dokumentacji Lighthouse.
Cel samouczka
W tym samouczku dowiesz się, jak za pomocą Narzędzi programistycznych Chrome znaleźć sposoby na przyspieszenie wczytywania stron.
Czytaj dalej lub obejrzyj film z tego samouczka:
Wymagania wstępne
Musisz mieć podstawowe doświadczenie w programowaniu stron internetowych, podobne do tego, które jest przekazywane w tym kursie Wprowadzenie do programowania stron internetowych.
Nie musisz znać szczegółów dotyczących wydajności wczytywania.
Wprowadzenie
Tu Tony. Tony jest bardzo znany w kociej społeczności. Utworzył witrynę, aby jego fani mogli dowiedzieć się, jakie są jego ulubione potrawy. Jego fani uwielbiają tę stronę, ale Tony wciąż słyszy skargi na jej wolne wczytywanie. Tony prosi Cię o pomoc w przyspieszeniu działania witryny.
Krok 1. Przeprowadź audyt witryny
Gdy chcesz poprawić szybkość wczytywania witryny, zacznij od audytu. Kontrola ma 2 ważne funkcje:
- Tworzy wartość bazową, na której podstawie możesz porównywać kolejne zmiany.
- Znajdziesz w nim wskazania, jak działać, aby wprowadzić zmiany, które przyniosą największe korzyści.
Skonfiguruj
Najpierw musisz skonfigurować nowe środowisko robocze dla witryny Tony's website, aby móc później wprowadzić w niej zmiany:
Zmodyfikuj projekt witryny na Glitchu. Nowy projekt otworzy się w karcie. Ta karta będzie nazywana kartą edytora.
Nazwa projektu zmienia się z tony na losową nazwę. Masz teraz swoją własną kopię kodu, którą możesz edytować. Później wprowadzisz zmiany w tym kodzie.
U dołu karty edytora kliknij Podgląd > Podgląd w nowym oknie. Demonstracja otworzy się w nowej karcie. Ta karta będzie nazywana kartą demonstracyjną. Załadowanie witryny może trochę potrwać.
Otwórz Narzędzia deweloperskie i przetestuj demo.
Ustal wartość odniesienia
Dane podstawowe to zapis skuteczności witryny przed wprowadzeniem jakichkolwiek ulepszeń.
Otwórz panel Lighthouse. Może być ukryty za
więcej paneli.Dopasuj ustawienia konfiguracji raportu Lighthouse do tych widocznych na zrzucie ekranu. Oto wyjaśnienie różnych opcji:
- Wyczyść pamięć wewnętrzną. Zaznaczenie tego pola powoduje wyczyszczenie całej pamięci powiązanej ze stroną przed każdym audytem. Pozostaw to ustawienie włączone, jeśli chcesz sprawdzić, jak Twoja witryna jest odbierana przez użytkowników odwiedzających ją po raz pierwszy. Wyłącz to ustawienie, jeśli chcesz, aby użytkownicy mogli powtarzać wizyty.
- Włącz próbkowanie JS. Ta opcja jest domyślnie wyłączona. Gdy ta opcja jest włączona, do śledzenia wydajności dodawane są szczegółowe stosy wywołań JavaScriptu, co może spowolnić generowanie raportu. Ślad jest dostępny w
- Symulowane ograniczanie (domyślnie) . Ta opcja symuluje typowe warunki przeglądania na urządzeniu mobilnym. Nazywamy go „symulowanym”, ponieważ Lighthouse nie ogranicza przepustowości podczas procesu sprawdzania. Zamiast tego po prostu ekstrapoluje, ile czasu zajmie wczytanie strony na urządzeniu mobilnym. Z drugiej strony ustawienie Ograniczanie (zaawansowane) w Narzędziach deweloperskich powoduje ograniczenie działania procesora i sieci, co przekłada się na dłuższy proces sprawdzania.
- Tryb > 3 tryby. Nawigacja (domyślnie). Ten tryb analizuje wczytanie pojedynczej strony, a tego właśnie potrzebujemy w tym samouczku. Więcej informacji znajdziesz w artykule
- Urządzenie > Mobile. Opcja mobilna zmienia ciąg znaków klienta użytkownika i symuluje widok mobilny. Opcja komputera wyłącza zmiany wprowadzone na urządzeniach mobilnych.
- Kategorie > Wydajność. Jeśli włączysz tylko jedną kategorię, Lighthouse wygeneruje raport tylko z odpowiednim zestawem audytów. Jeśli chcesz zobaczyć typy rekomendacji, które zapewniają inne kategorie, możesz je pozostawić włączone. Wyłączenie nieistotnych kategorii nieco przyspieszy proces sprawdzania.
Kliknij Analyze page load (Analizuj wczytywanie strony). Po 10–30 sekundach w panelu Lighthouse pojawi się raport o wydajności witryny.
Obsługa błędów raportów
Jeśli w raporcie Lighthouse pojawi się błąd, otwórz kartę demonstracyjną w oknie incognito bez żadnych innych otwartych kart. Dzięki temu będziesz mieć pewność, że Chrome działa w czystym stanie. W szczególności rozszerzenia do Chrome mogą zakłócać proces sprawdzania.
Interpretowanie raportu
Liczba u góry raportu to ogólny wynik skuteczności witryny. Gdy później wprowadzisz zmiany w kodzie, liczba ta powinna wzrosnąć. Wyższy wynik oznacza lepszą skuteczność.
Dane
Przewiń w dół do sekcji Dane i kliknij Rozwiń widok. Aby przeczytać dokumentację dotyczącą wskaźnika, kliknij Więcej informacji.
Ta sekcja zawiera ilościowe pomiary skuteczności witryny. Każdy rodzaj danych dostarcza informacji o innym aspekcie skuteczności. Na przykład pierwsze wyrenderowanie treści informuje, kiedy treści są po raz pierwszy wyświetlane na ekranie. Jest to ważny etap w postrzeganiu przez użytkownika wczytywania strony, podczas gdy czas do interakcji oznacza moment, w którym strona jest na tyle gotowa, że może obsługiwać interakcje użytkownika.
Zrzuty ekranu
Poniżej znajdziesz zbiór zrzutów ekranu pokazujących, jak wyglądała strona w momencie wczytania.
Możliwości
Następnie jest sekcja Możliwości, która zawiera konkretne wskazówki dotyczące poprawy szybkości wczytywania tej konkretnej strony.
Kliknij możliwość, aby dowiedzieć się o niej więcej.
Kliknij Więcej informacji, aby wyświetlić dokumentację wyjaśniającą, dlaczego dana możliwość jest ważna, oraz szczegółowe rekomendacje dotyczące jej rozwiązania.
Diagnostyka
Sekcja Diagnostyka zawiera więcej informacji o czynnikach wpływających na czas wczytywania strony.
Zdawane audyty
W sekcji Przeszedł audyt widać, co w witrynie działa prawidłowo. Kliknij, aby rozwinąć tę sekcję.
Krok 2. Eksperyment
W sekcji Możliwości raportu Lighthouse znajdziesz wskazówki dotyczące poprawy skuteczności strony. W tej sekcji wdrożysz zalecane zmiany w kodzie źródłowym, a po każdej zmianie sprawdzisz, jak wpływa ona na szybkość witryny.
Włącz kompresję tekstu
Z raportu wynika, że włączenie kompresji tekstu to jeden z najlepszych sposobów na poprawę skuteczności strony.
Kompresja tekstu polega na zmniejszeniu rozmiaru pliku tekstowego przed wysłaniem go przez sieć. Jest to trochę jak spakowanie folderu przed wysłaniem, aby zmniejszyć jego rozmiar.
Zanim włączysz kompresję, możesz ręcznie sprawdzić, czy zasoby tekstowe są skompresowane.
Otwórz panel Sieć i kliknij Użyj dużych wierszy żądań.
Ustawienia >Każda komórka Size zawiera 2 wartości. Najwyższa wartość to rozmiar pobranego zasobu. Wartość dolna to rozmiar nieskompresowanego zasobu. Jeśli obie wartości są takie same, zasób nie jest kompresowany podczas wysyłania przez sieć. W tym przykładzie wartości górna i dolna dla bundle.js
to 1.4 MB
.
Kompresję możesz też sprawdzić, sprawdzając nagłówki HTTP zasobu:
Kliknij bundle.js i otwórz kartę Nagłówki.
W sekcji Nagłówki odpowiedzi wyszukaj nagłówek
content-encoding
. Nie powinieneś/nie powinnaś go widzieć, co oznacza, żebundle.js
nie został skompresowany. Gdy zasób jest skompresowany, ten nagłówek jest zwykle ustawiony nagzip
,deflate
lubbr
. Wyjaśnienie tych wartości znajdziesz w dyrektywach.
Wystarczy z tego tłumaczenia. Czas na wprowadzenie zmian. Aby włączyć kompresję tekstu, dodaj kilka linii kodu:
Na karcie Edytor otwórz plik
server.js
i dodaj te 2 wyróżnione wiersze:... const fs = require('fs'); const compression = require('compression'); app.use(compression()); app.use(express.static('build')); ...
Upewnij się, że
app.use(compression())
jest umieszczone przedapp.use(express.static('build'))
.Zaczekaj, aż Glitch wdroży nową wersję witryny. W lewym dolnym rogu pojawi się uśmiechnięty emotikon, co oznacza, że wdrożenie zostało zakończone.
Aby ręcznie sprawdzić, czy kompresja działa, użyj przepływów pracy, które poznaliśmy wcześniej:
Wróć do karty wersji demonstracyjnej i załaduj ponownie stronę.
Kolumna Rozmiar powinna teraz zawierać 2 różne wartości dla zasobów tekstowych, takich jak
bundle.js
. Górna wartość269 KB
dlabundle.js
to rozmiar pliku wysłanego przez sieć, a dolna wartość1.4 MB
to rozmiar pliku nieskompresowanego.Sekcja Nagłówki odpowiedzi w przypadku
bundle.js
powinna zawierać nagłówekcontent-encoding: gzip
.
Aby sprawdzić wpływ kompresji tekstu na wydajność wczytywania strony, ponownie uruchom raport Lighthouse:
Otwórz panel Lighthouse i na górze na pasku czynności kliknij Wykonaj audyt….
Pozostaw ustawienia bez zmian i kliknij Analizuj wczytywanie strony.
Super! To wygląda na postęp. Ogólna ocena wydajności powinna wzrosnąć, co oznacza, że witryna staje się szybsza.
Kompresja tekstu w rzeczywistych warunkach
Większość serwerów ma proste rozwiązania umożliwiające włączenie kompresji. Wystarczy, że wyszukasz, jak skonfigurować serwer, którego używasz do kompresji tekstu.
Zmienianie rozmiaru obrazów
Z Twojego nowego raportu wynika, że prawidłowe dopasowywanie rozmiaru obrazów to kolejna ważna kwestia.
Zmiana rozmiaru obrazów pomaga skrócić czas wczytywania, ponieważ zmniejsza rozmiar plików. Jeśli użytkownik ogląda obrazy na ekranie urządzenia mobilnego o szerokości 500 pikseli, nie ma sensu wysyłać obrazu o szerokości 1500 pikseli. W idealnej sytuacji obraz powinien mieć maksymalnie 500 pikseli szerokości.
W raporcie kliknij Obrazy o odpowiednim rozmiarze, aby sprawdzić, które obrazy należy zmienić. Wygląda na to, że wszystkie 4 obrazy są większe niż to konieczne.
Wróć do karty Edytor i otwórz
src/model.js
.Zawartość komórki
const dir = 'big'
zastąp komórkąconst dir = 'small'
. Ten katalog zawiera kopie tych samych obrazów, których rozmiar został zmieniony.Ponownie sprawdź stronę, aby zobaczyć, jak ta zmiana wpływa na czas wczytywania.
Wygląda na to, że ta zmiana ma niewielki wpływ na ogólny wynik skuteczności. Jednak ocena nie pokazuje wyraźnie, ile danych sieciowych oszczędzasz użytkownikom. Łączny rozmiar starych zdjęć wynosił około 6,1 MB, a teraz to tylko około 633 kB. Możesz to sprawdzić na pasku stanu u dołu panelu Sieć.
Zmienianie rozmiaru obrazów w rzeczywistym świecie
W przypadku małej aplikacji jednorazowe zmienić rozmiar może być wystarczające. W przypadku dużej aplikacji nie da się tego jednak zastosować. Oto kilka strategii zarządzania obrazami w dużych aplikacjach:
- Zmieniaj rozmiar obrazów podczas procesu kompilacji.
- Utwórz wiele rozmiarów każdego obrazu podczas procesu kompilacji, a potem użyj w kodzie elementu
srcset
. Podczas działania przeglądarka sama wybiera rozmiar, który najlepiej pasuje do urządzenia, na którym jest uruchomiona. Zobacz obrazy o względnych rozmiarach. - Użyj CDN obrazów, który umożliwia dynamiczną zmianę rozmiaru obrazu po jego przesłaniu.
- Zoptymalizuj co najmniej każdy obraz. Może to przynieść ogromne oszczędności. Optymalizacja polega na przepuszczeniu obrazu przez specjalny program, który zmniejsza rozmiar pliku. Więcej wskazówek znajdziesz w artykule Najważniejsze informacje o optymalizacji obrazów.
Wyeliminuj zasoby blokujące renderowanie
Z ostatniego raportu wynika, że wyeliminowanie zasobów blokujących renderowanie to obecnie największa szansa na poprawę.
Zasób blokujący renderowanie to zewnętrzny plik JavaScript lub CSS, który musi zostać pobrany, przeanalizowany i wykonany przez przeglądarkę, zanim będzie można wyświetlić stronę. Celem jest uruchomienie tylko kodu CSS i JavaScript, który jest niezbędny do prawidłowego wyświetlenia strony.
Pierwszym zadaniem jest więc znalezienie kodu, który nie musi być wykonywany podczas wczytywania strony.
Kliknij Wyeliminuj zasoby blokujące renderowanie, aby zobaczyć zasoby, które blokują:
lodash.js
ijquery.js
.Aby otworzyć menu poleceń, w zależności od systemu operacyjnego naciśnij:
- Na Macu: Command + Shift + P
- W systemach Windows, Linux i ChromeOS: Control + Shift + P.
Zacznij pisać
Coverage
i kliknij Pokaż zasięg.Karta Pokrycie otworzy się w panelu.
Kliknij
Odśwież. Karta Pokrycie zawiera przegląd tego, ile kodu w elementachbundle.js
,jquery.js
ilodash.js
jest wykonywane podczas wczytywania strony.Na tym zrzucie ekranu widać, że około 74% i 30% plików jQuery i Lodash nie jest używanych.
Kliknij wiersz jquery.js. Narzędzia dla programistów otwierają plik w panelu Źródła. Linia kodu została wykonana, jeśli obok niej znajduje się zielony pasek. Czerwony pasek obok linii kodu oznacza, że nie został on wykonany i nie jest potrzebny podczas wczytywania strony.
Przewiń kod jQuery. Niektóre wiersze, które są „wykonywane”, są w istocie tylko komentarzami. Przesłanie tego kodu przez narzędzie do kompresji, które usuwa komentarze, to kolejny sposób na zmniejszenie rozmiaru pliku.
Krótko mówiąc, gdy pracujesz z własnym kodem, karta Pokrycie może Ci pomóc przeanalizować kod wiersz po wierszu i przesłać tylko kod potrzebny do wczytania strony.
Czy do wczytania strony potrzebne są pliki jquery.js
i lodash.js
? Karta Blokowanie żądań pokazuje, co się dzieje, gdy zasoby są niedostępne.
- Kliknij kartę Sieć i ponownie otwórz Menu poleceń.
Zacznij pisać
blocking
, a potem wybierz Pokaż blokowanie żądań. Otworzy się karta Blokowanie żądań.Kliknij Dodaj wzór, wpisz
/libs/*
w polu tekstowym i naciśnij Enter, aby potwierdzić.Odśwież stronę. Żądania jQuery i Lodash są zaznaczone na czerwono, co oznacza, że zostały zablokowane. Strona nadal się wczytuje i jest interaktywna, więc wygląda na to, że te zasoby nie są w ogóle potrzebne.
Aby usunąć wzór blokowania
/libs/*
, kliknij Usuń wszystkie wzorce.
Karta Blokowanie żądań służy do symulowania zachowania strony, gdy dany zasób jest niedostępny.
Teraz usuń z kodu odwołania do tych plików i ponownie zweryfikuj stronę:
- Wróć do karty Edytor i otwórz
template.html
. Usuń odpowiednie tagi
<script>
:<head> ... <meta name="viewport" content="width=device-width, initial-scale=1"> <script src="/libs/lodash.js"></script> <script src="/libs/jquery.js"></script> <title>Tony's Favorite Foods</title> </head>
Poczekaj, aż strona zostanie ponownie skompilowana i wdrożona.
Ponownie sprawdź stronę w panelu Lighthouse. Twój ogólny wynik powinien się poprawić.
Optymalizacja ścieżki renderowania w rzeczywistych warunkach
Krytyczna ścieżka renderowania to kod potrzebny do załadowania strony. Ogólnie mówiąc, możesz przyspieszyć wczytywanie strony, przesyłając tylko kod krytyczny podczas wczytywania strony, a potem stosując wczytywanie opóźnione dla wszystkich pozostałych elementów.
- Nie jest prawdopodobne, że znajdziesz skrypty, które możesz usunąć od razu, ale często okaże się, że wielu skryptów nie trzeba wczytywać podczas wczytywania strony, a zamiast tego można je wczytywać asynchronicznie. Zobacz Używanie asynchroniczności lub opóźnienia.
- Jeśli używasz frameworka, sprawdź, czy ma tryb produkcyjny. Ten tryb może używać funkcji takiej jak tree shaking, aby wyeliminować niepotrzebny kod, który blokuje renderowanie krytyczne.
Ogranicz pracę w wątku głównym
Najnowszy raport pokazuje niewielkie potencjalne oszczędności w sekcji Możliwości, ale jeśli przewiniesz do sekcji Diagnostyka, okaże się, że największym wąskim gardłem jest nadmierna aktywność głównego wątku.
Wątek główny to miejsce, w którym przeglądarka wykonuje większość zadań związanych z wyświetlaniem strony, takich jak analizowanie i wykonywanie kodu HTML, CSS i JavaScript.
Celem jest użycie panelu Wydajność do przeanalizowania, jakie zadania wykonuje wątek główny podczas wczytywania strony, oraz znalezienie sposobów odroczenia lub usunięcia niepotrzebnych działań.
Otwórz Wydajność > Ustawienia nagrywania i ustaw Sieć na Wolna sieć 3G, a Procesor na 6-krotne spowolnienie.
Urządzenia mobilne mają zwykle więcej ograniczeń sprzętowych niż laptopy czy komputery stacjonarne, więc te ustawienia pozwalają na wczytywanie strony tak, jakbyś używał mniej wydajnego urządzenia.
Kliknij
Odśwież. Narzędzie deweloperskie ponownie wczytuje stronę, a potem generuje wizualizację wszystkich działań, które musiało wykonać, aby ją załadować. Ta wizualizacja będzie nazywana śladem.
Ślad pokazuje aktywność w kolejności chronologicznej, od lewej do prawej. Wykresy FPS, CPU i NET u góry ekranu zawierają przegląd liczby klatek na sekundę, aktywności procesora i aktywności sieci.
Żółta barwa w sekcji Przegląd oznacza, że procesor był całkowicie zajęty wykonywaniem skryptu. To wskazówka, że możesz przyspieszyć wczytywanie strony, zmniejszając ilość kodu JavaScript.
Przeanalizuj ślad, aby znaleźć sposoby na zmniejszenie obciążenia JavaScriptem:
Kliknij sekcję Czas trwania, aby ją rozwinąć.
W pliku znajdują się liczne pomiary Czasu użytkownika z React. Wygląda na to, że aplikacja Tony'ego używa trybu programowania w React. Przejście na tryb produkcyjny w React prawdopodobnie przyniesie łatwe korzyści w zakresie wydajności.
Aby zwinąć tę sekcję, ponownie kliknij Czas trwania.
Przejrzyj sekcję Główna. Ta sekcja zawiera chronologiczny dziennik aktywności wątku głównego, od lewej do prawej. Oś y (od góry do dołu) pokazuje, dlaczego wystąpiły zdarzenia.
W tym przykładzie zdarzenie
Evaluate Script
spowodowało wykonanie funkcji(anonymous)
, która z kolei spowodowała wykonanie funkcji__webpack__require__
, która z kolei spowodowała wykonanie funkcji./src/index.jsx
itd.Przewiń w dół do końca sekcji Główna. Jeśli używasz frameworku, większość aktywności na najwyższym poziomie jest spowodowana przez ten framework i zwykle nie masz na nią wpływu. Aktywność spowodowana przez Twoją aplikację znajduje się zwykle na dole.
Wygląda na to, że w tej aplikacji funkcja
App
powoduje wiele wywołań funkcjimineBitcoin
. Wygląda na to, że Tony używa urządzeń swoich fanów do wydobywania kryptowaluty.U dołu otwórz kartę Od dołu do góry. Na tej karcie znajdziesz podział, który pokazuje, które aktywności zajęły najwięcej czasu. Jeśli w sekcji Od dołu nie widzisz nic, kliknij etykietę sekcji Główna.
Sekcja Od dołu zawiera informacje tylko o wybranej aktywności lub grupie aktywności. Jeśli np. klikniesz jedną z aktywności
mineBitcoin
, w sekcji Od dołu będą widoczne tylko informacje o tej aktywności.Kolumna Czas samodzielny wskazuje, ile czasu zajęło wykonanie każdej aktywności. W tym przypadku około 82% czasu wątku głównego zostało poświęcone funkcji
mineBitcoin
.
Czas sprawdzić, czy korzystanie z trybu produkcyjnego i ograniczenie aktywności JavaScript przyspiesza wczytywanie strony. Zacznij od trybu produkcyjnego:
- Na karcie Edytor otwórz
webpack.config.js
. - Zmień
"mode":"development"
na"mode":"production"
. - Poczekaj na wdrożenie nowej kompilacji.
Ponownie zweryfikuj stronę.
Zmniejsz aktywność JavaScriptu, usuwając wywołanie mineBitcoin
:
- Na karcie Edytor otwórz
src/App.jsx
. - Wykomentuj wywołanie funkcji
this.mineBitcoin(1500)
w funkcjiconstructor
. - Poczekaj na wdrożenie nowej kompilacji.
- Ponownie zweryfikuj stronę.
Jak zawsze, nadal trzeba coś zrobić, np. zmniejszyć wartości największego wyrenderowania treści i skumulowanego przesunięcia układu.
Wykonywanie mniejszej ilości pracy w głównym wątku w świecie rzeczywistym
Ogólnie panel Skuteczność to najczęstszy sposób na poznanie aktywności witryny podczas jej wczytywania oraz sposobów na usunięcie niepotrzebnej aktywności.
Jeśli wolisz podejście podobne do console.log()
, interfejs API User Timing umożliwia dowolne oznaczanie niektórych faz cyklu życia aplikacji w celu śledzenia, ile czasu zajmuje każda z nich.
Podsumowanie
- Gdy chcesz zoptymalizować czas ładowania witryny, zawsze zacznij od audytu. Audyt ustala punkt odniesienia i zawiera wskazówki dotyczące poprawy.
- Wprowadzaj po jednej zmianie naraz i sprawdzaj stronę po każdej z nich, aby zobaczyć, jak poszczególne zmiany wpływają na skuteczność.
Dalsze kroki
Wykonuj audyty w swojej witrynie. Jeśli potrzebujesz pomocy przy interpretacji raportu lub szukaniu sposobów na poprawę wydajności wczytywania, sprawdź wszystkie sposoby na uzyskanie pomocy od społeczności DevTools:
- Zgłaszaj błędy w tym dokumencie w repozytorium developer.chrome.com.
- Zgłaszaj błędy w Narzędziach deweloperskich na stronie Błędy w Chromium.
- Dyskutuj o funkcjach i zmianach na liście mailingowej. Nie używaj listy mailingowej do zadawania pytań dotyczących pomocy. Zamiast tego skorzystaj z Stack Overflow.
- Ogólne informacje o używaniu Narzędzi deweloperskich znajdziesz na stronie Stack Overflow. Aby przesłać prośbę o poprawkę, zawsze korzystaj z błędów Chromium.
- Napisz do nas na Twitterze: @ChromeDevTools.