Cel samouczka
Z tego samouczka dowiesz się, jak używać Narzędzi deweloperskich w Chrome, aby przyspieszyć wczytywanie stron.
Przeczytaj lub obejrzyj wersję wideo tego samouczka:
Wymagania wstępne
Musisz mieć podstawowe doświadczenie w tworzeniu stron internetowych podobne do tych opisanych w tym zajęciu dotyczącym tworzenia stron internetowych.
Nie musisz nic wiedzieć na temat wydajności wczytywania.
Wstęp
Jestem Tony. Tony jest bardzo znany w kocim społeczeństwie. Stworzył witrynę, w której fani mogą dowiedzieć się, jakie są jego ulubione potrawy. Jego fani uwielbiają stronę, ale Tomek wciąż narzeka, że strona wczytuje się wolno. Tomek poprosił Cię o pomoc w przyspieszeniu strony.
Krok 1. Sprawdź witrynę
Jeśli chcesz poprawić szybkość ładowania strony, zawsze zacznij od kontroli. Kontrola ma 2 ważne funkcje:
- Tworzony jest punkt odniesienia, na podstawie którego możesz mierzyć kolejne zmiany.
- Znajdziesz w nim praktyczne wskazówki dotyczące zmian, które mogą przynieść najlepsze efekty.
Skonfiguruj
Najpierw musisz skonfigurować nowe środowisko pracy dla witryny Tony'ego, by móc później wprowadzić w niej zmiany:
Zremiksuj projekt witryny w Glitch. Nowy projekt otworzy się w karcie. Ta karta będzie nazywana kartą edytora.
Nazwa projektu zmienia się z tony na nazwę wygenerowaną losowo. Masz teraz własną, edytowalną kopię kodu. Później wprowadzisz zmiany w tym kodzie.
U dołu karty edytora kliknij Podgląd > Podgląd w nowym oknie. Wersja demonstracyjna otworzy się w nowej karcie. Ta karta będzie nazywana kartą demonstracyjną. Ładowanie witryny może trochę potrwać.
Otwórz Narzędzia deweloperskie obok wersji demonstracyjnej.
Określ punkt odniesienia
Punkt odniesienia 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 na zrzucie ekranu. Oto wyjaśnienie poszczególnych opcji:
- Wyczyść pamięć wewnętrzną. Zaznaczenie tego pola wyboru powoduje wyczyszczenie całego miejsca na dane powiązane ze stroną przed każdą kontrolą. Zostaw to ustawienie włączone, jeśli chcesz sprawdzić, jak odbierają Twoją witrynę po raz pierwszy. Wyłącz to ustawienie, jeśli chcesz wielokrotnie odwiedzać tę firmę.
- Symulowane ograniczanie (domyślnie): . Ta opcja symuluje typowe warunki przeglądania na urządzeniu mobilnym. Nazywa się „symulowaną”, ponieważ Lighthouse nie reguluje szybkości podczas procesu kontroli. Zamiast tego szacuje czas wczytywania strony na urządzeniu mobilnym. Z kolei ustawienie Ograniczanie w Narzędziach deweloperskich (zaawansowane) faktycznie ogranicza działanie procesora i sieci, co nie wpływa na dłuższy proces kontroli.
- Tryb > Trzy tryby. Nawigacja (domyślny). Ten tryb analizuje pojedyncze wczytanie strony. Tego właśnie potrzebujemy w tym samouczku. Więcej informacji znajdziesz w sekcji
- Urządzenie > Urządzenie mobilne. Opcja mobilna zmienia ciąg znaków klienta użytkownika i symuluje widoczny obszar mobilny. Opcja dla komputerów wyłącza głównie zmiany na urządzeniach mobilnych.
- Kategorie > Skuteczność. Pojedyncza włączona kategoria sprawia, że Lighthouse generuje raport tylko z odpowiednim zestawem audytów. Jeśli chcesz zobaczyć typy rekomendacji, jakie zapewniają, możesz pozostawić włączone inne kategorie. Wyłączenie nietrafnych kategorii nieco przyspiesza proces kontroli.
Kliknij Analizuj wczytanie strony. Po 10–30 sekundach w panelu Lighthouse pojawi się raport dotyczący wydajności witryny.
Obsługa błędów w raportach
Jeśli w raporcie Lighthouse pojawi się błąd, uruchom kartę demonstracyjną w oknie incognito bez otwartych innych kart. Dzięki temu uruchamiasz Chrome w czystym stanie. Zwłaszcza rozszerzenia do Chrome mogą zakłócać proces kontroli.
Interpretowanie raportu
Liczba u góry raportu to ogólny wynik skuteczności witryny. Po wprowadzeniu zmian w kodzie ta liczba powinna wzrosnąć. Wyższy wynik oznacza wyższą skuteczność.
Wskaźniki
Przewiń w dół do sekcji Wskaźniki i kliknij Rozwiń widok. Aby zapoznać się z dokumentacją danych, kliknij Więcej informacji...
W tej sekcji możesz mierzyć skuteczność witryny w ujęciu ilościowym. Każdy rodzaj danych zapewnia wgląd w inny aspekt skuteczności. Na przykład Pierwsze wyrenderowanie treści informuje o tym, kiedy treść jest wyświetlana na ekranie po raz pierwszy, co jest ważnym etapem postrzegania przez użytkownika wczytywania strony, a Czas do pełnej interaktywności oznacza punkt, w którym strona staje się gotowa na interakcję z użytkownikiem.
Zrzuty ekranu
Dalej znajdziesz zbiór zrzutów ekranu, które pokazują, jak strona wyglądała po wczytaniu.
Możliwości
W dalszej części znajdziesz sekcję Możliwości, która zawiera konkretne wskazówki na temat poprawy szybkości wczytywania danej 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 konkretne zalecenia, które pomogą Ci ją poprawić.
Diagnostyka
Sekcja Diagnostyka zawiera więcej informacji o czynnikach, które mają wpływ na czas wczytywania strony.
Zaliczone audyty
Sekcja Zaliczone audyty zawiera informacje o tym, co witryna działa prawidłowo. Kliknij tę sekcję, aby ją rozwinąć.
Krok 2: Eksperyment
Sekcja Możliwości w raporcie Lighthouse zawiera wskazówki, jak poprawić wydajność strony. W tej sekcji wdrożysz zalecane zmiany w bazie kodu i sprawdzisz witrynę po każdej zmianie, aby zmierzyć, jak wpływa ona na szybkość witryny.
Włącz kompresję tekstu
Z Twojego raportu wynika, że włączenie kompresji tekstu to jedna z najważniejszych możliwości poprawy wydajności strony.
Kompresja tekstu polega na zmniejszaniu lub skompresowaniu rozmiaru pliku tekstowego przed przesłaniem go do sieci. To coś w rodzaju skompresowania folderu przed wysłaniem go e-mailem, by zmniejszyć jego rozmiar.
Zanim włączysz kompresję, wypróbuj te sposoby, aby ręcznie sprawdzić, czy zasoby tekstowe są kompresowane.
Otwórz panel Sieć i zaznacz Użyj dużych wierszy żądań.
Ustawienia >Każda komórka Rozmiar zawiera 2 wartości. Wartość górna to rozmiar pobranego zasobu. Najniższa wartość to rozmiar nieskompresowanego zasobu. Jeśli te 2 wartości są takie same, oznacza to, że zasób nie jest kompresowany podczas przesyłania przez sieć. W tym przykładzie górna i dolna wartość parametru 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 widzisz żadnej wartości, co oznacza, że parametrbundle.js
nie został skompresowany. Gdy zasób jest skompresowany, nagłówek ten ma zwykle wartośćgzip
,deflate
lubbr
. Objaśnienie tych wartości znajdziesz w sekcji Dyrektywy.
Dosyć tych wyjaśnień. Czas wprowadzić pewne zmiany! Włącz kompresję tekstu, dodając kilka wierszy kodu:
Na karcie edytora otwórz
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')); ...
Pamiętaj, aby umieścić
app.use(compression())
przedapp.use(express.static('build'))
.Poczekaj, aż Glitch wdroży nową kompilację witryny. Wesoły emotikon w lewym dolnym rogu oznacza pomyślne wdrożenie.
Korzystając z poznanych wcześniej przepływów pracy, ręcznie sprawdź, czy kompresja działa:
Wróć na kartę demonstracyjną i załaduj ponownie stronę.
Kolumna Rozmiar powinna teraz pokazywać 2 różne wartości dla zasobów tekstowych, takich jak
bundle.js
. Górna wartość269 KB
w przypadkubundle.js
to rozmiar pliku wysłanego przez sieć, a dolna wartość1.4 MB
to rozmiar nieskompresowanego pliku.Sekcja Nagłówki odpowiedzi dla zasobu
bundle.js
powinna teraz zawierać nagłówekcontent-encoding: gzip
.
Ponownie uruchom raport Lighthouse na stronie, aby zmierzyć wpływ kompresji tekstu na szybkość wczytywania strony:
Otwórz panel Lighthouse i na pasku działań u góry kliknij Przeprowadź audyt....
Pozostaw ustawienia bez zmian i kliknij Analizuj wczytanie strony.
Super! To chyba postęp. Ogólny wynik powinien wzrosnąć, co oznacza, że strona działa szybciej.
Kompresja tekstu w świecie rzeczywistym
Większość serwerów ma naprawdę proste poprawki, które umożliwiają kompresję. Sprawdź, jak skonfigurować serwer używany do kompresowania tekstu.
Zmienianie rozmiaru obrazów
Z nowego raportu wynika, że prawidłowe rozmiary obrazów to kolejna duża szansa.
Zmiana rozmiaru obrazów pozwala skrócić czas ich wczytywania dzięki zmniejszeniu rozmiaru ich pliku. Jeśli użytkownik ogląda Twoje obrazy na ekranie urządzenia mobilnego o szerokości 500 pikseli, wysyłanie obrazu o szerokości 1500 pikseli w ogóle nie ma sensu. Najlepiej przesłać zdjęcie o szerokości maksymalnie 500 pikseli.
W raporcie kliknij Obrazy o prawidłowym rozmiarze, by sprawdzić, które obrazy należy zmienić. Wygląda na to, że wszystkie 4 obrazy są za duże.
Na karcie edytora otwórz
src/model.js
.Zamień
const dir = 'big'
naconst 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 szybkość ładowania.
Wygląda na to, że ta zmiana ma tylko niewielki wpływ na ogólny wynik skuteczności. Jedną z rzeczy, które nie są jasno podane, jest ilość danych przesyłanych przez użytkowników w sieci. Całkowity rozmiar starych zdjęć wynosił około 6,1 MB, a obecnie to tylko 633 KB. Możesz to sprawdzić na pasku stanu u dołu panelu Sieć.
Zmienianie rozmiaru obrazów w świecie rzeczywistym
W przypadku małej aplikacji wystarczy jednorazowa zmiana rozmiaru. W przypadku dużych aplikacji oczywiście nie jest to skalowalne. Oto kilka strategii zarządzania obrazami w dużych aplikacjach:
- Zmieniaj rozmiar obrazów podczas tworzenia.
- W trakcie procesu kompilacji utwórz kilka rozmiarów każdego obrazu i użyj atrybutu
srcset
w kodzie. W czasie działania przeglądarki przeglądarka wybiera rozmiar najlepiej pasujący do urządzenia. Zobacz Obrazy w względnym rozmiarze. - Użyj sieci CDN na potrzeby obrazów, która umożliwia dynamiczne zmienianie rozmiaru obrazu na żądanie.
- Postaraj się zoptymalizować każdy obraz. Często przynosi to ogromne oszczędności. Optymalizacja polega na tym, że wykonujesz obraz za pomocą specjalnego programu, który zmniejsza rozmiar jego pliku. Więcej wskazówek znajdziesz w artykule Niezbędna optymalizacja obrazu.
Wyeliminuj zasoby blokujące renderowanie
Z najnowszego raportu wynika, że obecnie największą szansą jest wyeliminowanie zasobów blokujących renderowanie.
Zasób blokujący renderowanie to zewnętrzny plik JavaScript lub CSS, który przeglądarka musi pobrać, przeanalizować i wykonać, zanim będzie mogła wyświetlić stronę. Chodzi o uruchamianie tylko podstawowego kodu CSS i JavaScript, który jest wymagany do prawidłowego wyświetlania strony.
Pierwszym zadaniem jest 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
.W zależności od systemu operacyjnego naciśnij te klawisze, aby otworzyć menu poleceń:
- Mac: Command + Shift + P
- W systemie Windows, Linux lub ChromeOS, naciśnij Control + Shift + P
Zacznij wpisywać
Coverage
i wybierz Pokaż pokrycie.Kliknij Załaduj ponownie. Na karcie Stan możesz sprawdzić, jaka część kodu w aplikacjach
bundle.js
,jquery.js
ilodash.js
jest wykonywana podczas wczytywania strony.Zrzut ekranu pokazuje, że około 74% i 30% plików jQuery i Lodash nie jest używanych odpowiednio.
Kliknij wiersz jquery.js. Narzędzia deweloperskie otworzy plik w panelu Źródła. Wiersz kodu został wykonany, jeśli obok niego wyświetla się zielony pasek. Czerwony pasek obok wiersza kodu oznacza, że kod nie został wykonany i z pewnością nie jest wymagany podczas wczytywania strony.
Przewiń nieco do kodu jQuery. Niektóre wiersze, które są „wykonywane”, to tak naprawdę tylko komentarze. Innym sposobem zmniejszenia rozmiaru pliku jest uruchomienie go za pomocą narzędzia do minifikacji, które usuwa komentarze.
Krótko mówiąc, gdy pracujesz nad własnym kodem, karta Stan może pomóc Ci w analizowaniu kodu w poszczególnych wierszach i wysyłaniu tylko tego kodu, który jest potrzebny do wczytania strony.
Czy pliki jquery.js
i lodash.js
są w ogóle potrzebne do wczytania strony? Na karcie Blokowanie żądań możesz zobaczyć, co się dzieje, gdy zasoby są niedostępne.
- Kliknij kartę Sieć i ponownie otwórz menu poleceń.
Zacznij pisać
blocking
, a następnie wybierz Pokaż blokowanie żądań. Otworzy się karta Request Blokowanie (Blokowanie żądań).Kliknij Dodaj wzór, wpisz
/libs/*
w polu tekstowym i naciśnij Enter, aby potwierdzić.Odśwież stronę. Żądania jQuery i Lodash mają kolor czerwony, 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.
Kliknij Usuń wszystkie wzorce, aby usunąć wzorzec blokowania
/libs/*
.
Ogólnie rzecz biorąc, karta Blokowanie żądań przydaje się do symulowania działania strony, gdy dany zasób jest niedostępny.
Teraz usuń z kodu odwołania do tych plików i ponownie sprawdź stronę:
- Na karcie edytora 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 na ponowne skompilowanie i wdrożenie witryny.
Ponownie sprawdź stronę w panelu Lighthouse. Twój ogólny wynik powinien ponownie się poprawić.
Optymalizacja krytycznej ścieżki renderowania w świecie rzeczywistym
Krytyczna ścieżka renderowania odnosi się do kodu potrzebnego do wczytania strony. Ogólnie możesz przyspieszyć wczytywanie strony, przesyłając tylko krytyczny kod podczas jej wczytywania, a potem leniwe ładowanie wszystkich pozostałych elementów.
- Raczej nie znajdziesz skryptów, które będzie można usunąć od razu, ale często okazuje się, że żądania wielu skryptów nie muszą być żądane podczas wczytywania strony. Można je zażądać asynchronicznie. Więcej informacji znajdziesz w sekcji Korzystanie z asynchronicznego lub odroczenia.
- Jeśli używasz platformy, sprawdź, czy ma ona tryb produkcyjny. Ten tryb może korzystać z funkcji takich jak potrząsanie drzewem, aby wyeliminować niepotrzebne fragmenty kodu blokującego renderowanie o znaczeniu krytycznym.
Mniej pracy z wątkiem głównym
Najnowszy raport pokazuje pewne potencjalne oszczędności w sekcji Możliwości, ale po przewinięciu w dół do sekcji Diagnostyka wygląda na to, że największym wąskim gardłem jest zbyt duża aktywność w wątkach głównych.
Wątek główny to miejsce, w którym przeglądarka wykonuje większość czynności niezbędnych do wyświetlenia strony, np. analizuje i uruchamia kod HTML, CSS i JavaScript.
Celem jest wykorzystanie panelu Wydajność do analizowania działań wykonywanego przez wątek główny podczas wczytywania strony i znalezienia sposobów na odroczenie lub usunięcie niepotrzebnej pracy.
Otwórz Wydajność > Ustawienia przechwytywania i ustaw opcję Sieć na Powolne 3G, a Procesor na 6-krotne spowolnienie.
Urządzenia mobilne mają zwykle większe ograniczenia sprzętowe niż laptopy i komputery, więc te ustawienia pozwalają korzystać z wczytywania strony tak, jakby były używane na mniej wydajnym urządzeniu.
Kliknij Załaduj ponownie. W Narzędziach deweloperskich ponownie załaduje stronę, a potem wygeneruje wizualizację wszystkich czynności, jakie musiały wykonać, aby wczytać stronę. Ta wizualizacja jest nazywana trace.
Ślad pokazuje aktywność chronologicznie od lewej do prawej. Wykresy FPS, CPU i NET u góry zawierają przegląd liczby klatek na sekundę, aktywności procesora i aktywności sieci.
Żółta ściana widoczna w sekcji Przegląd oznacza, że procesor był całkowicie zajęty wykonywaniem skryptów. Jest to wskazówka, że możesz przyspieszyć wczytywanie strony, wykonując mniej pracy z użyciem JavaScriptu.
Zbadaj śledzenie, aby znaleźć sposoby na zmniejszenie pracy JavaScriptu:
Kliknij sekcję Czas, aby ją rozwinąć.
W React dostępnych jest kilka pomiarów czasu działań użytkownika. Wygląda na to, że aplikacja Tony'ego używa trybu deweloperskiego React. Przejście na tryb produkcyjny React zapewne ułatwi poprawę wydajności.
Ponownie kliknij Czas, aby zwinąć tę sekcję.
Przejrzyj sekcję Główna. Ta sekcja zawiera chronologiczny zapis aktywności w wątku głównym, od lewej do prawej. Oś Y (od góry do dołu) pokazuje przyczyny wystąpienia zdarzeń.
W tym przykładzie zdarzenie
Evaluate Script
spowodowało wykonanie funkcji(anonymous)
, co spowodowało wykonanie__webpack__require__
, a tym samym wykonanie./src/index.jsx
itd.Przewiń na sam dół sekcji Główna. Gdy używasz platformy, większość górnych działań jest spowodowana przez platformę, na którą zwykle nie masz wpływu. Informacje o aktywności spowodowanej przez aplikację są zwykle widoczne u dołu.
W tej aplikacji wygląda na to, że funkcja
App
powoduje wiele wywołań funkcjimineBitcoin
. Wygląda na to, że Tony używa urządzeń swoich fanów do wydobywania kryptowaluty...Otwórz kartę Od dołu do góry. Na tej karcie znajdziesz listę działań, które zajmowały najwięcej czasu. Jeśli nie widzisz żadnych pozycji w sekcji Od dołu, kliknij etykietę sekcji Główna.
W sekcji Od dołu widać tylko informacje o wybranych aktywnościach lub grupach aktywności. Jeśli na przykład klikniesz jedno z działań
mineBitcoin
, w sekcji Od dołu pojawią się tylko informacje na temat tej aktywności.Kolumna Czas samodzielny pokazuje czas spędzony bezpośrednio w danej aktywności. W tym przypadku około 82% czasu w wątku głównym spędziliśmy na funkcji
mineBitcoin
.
Czas sprawdzić, czy użycie trybu produkcyjnego i ograniczenie aktywności JavaScriptu przyspieszy wczytywanie strony. Zacznij od trybu produkcyjnego:
- Na karcie edytora otwórz
webpack.config.js
. - Zmień
"mode":"development"
na"mode":"production"
. - Poczekaj na wdrożenie nowej kompilacji.
Ponownie sprawdź stronę.
Ogranicz aktywność JavaScript, usuwając wywołanie mineBitcoin
:
- Na karcie edytora otwórz
src/App.jsx
. - Skomentuj połączenie do:
this.mineBitcoin(1500)
w:constructor
. - Poczekaj na wdrożenie nowej kompilacji.
- Ponownie sprawdź stronę.
Nadal mamy zadania do wykonania, na przykład zmniejsz wartości Największe wyrenderowanie treści i Skumulowane przesunięcie układu.
Mniej pracy z wątkami głównymi w świecie rzeczywistym
Ogólnie rzecz biorąc, panel Wydajność to najpowszechniejszy sposób sprawdzania aktywności związanej z wczytywaniem witryny i znajdowanie sposobów usuwania zbędnej aktywności.
Jeśli wolisz metodę bardziej zbliżoną do console.log()
, interfejs API User Timing umożliwia dowolne oznaczenie niektórych faz cyklu życia aplikacji i śledzenie ich czasu.
Podsumowanie
- Decydując się na optymalizację wydajności ładowania witryny, zawsze zacznij od kontroli. Kontrola ta wyznacza punkt odniesienia i podpowiada, co można poprawić.
- Wprowadzaj zmiany pojedynczo i po każdej z nich sprawdzaj stronę, aby sprawdzać, jak wyizolowana zmiana wpływa na skuteczność.
Dalsze kroki
Przeprowadź audyty w swojej witrynie. Jeśli potrzebujesz pomocy przy interpretowaniu raportu lub w poszukiwaniu sposobów na poprawę wydajności ładowania, zapoznaj się ze wszystkimi sposobami uzyskiwania pomocy od społeczności DevTools:
- Błędy w tym dokumencie zgłoś w repozytorium developer.chrome.com.
- Raporty o błędach w Narzędziach deweloperskich możesz zgłaszać na stronie Błędy Chromium.
- Omów funkcje i zmiany na liście adresowej. Nie używaj listy adresowej do zadawania pytań do zespołu pomocy. Zamiast tego użyj Stack Overflow.
- Uzyskaj ogólną pomoc dotyczącą korzystania z Narzędzi deweloperskich na stronie Stack Overflow. Zgłoszenia o błędach zgłaszaj zawsze w usłudze Chromium Bugs.
- Napisz nam na Twitterze: @ChromeDevTools.