Lighthouse: optymalizacja szybkości strony

Cel samouczka

Z tego samouczka dowiesz się, jak korzystać z Narzędzi deweloperskich w Chrome, aby przyspieszyć wczytywanie stron internetowych.

Przeczytaj ten samouczek lub obejrzyj jego wersję wideo:

Wymagania wstępne

Musisz mieć podstawowe doświadczenie w programowaniu stron internetowych podobne do tych omówionych na zajęciach Wprowadzenie do programowania stron internetowych.

Nie musisz wiedzieć nic o wydajności wczytywania.

Wstęp

Tu Tony. Tony jest bardzo znany w kociem społeczeństwie. Stworzył stronę internetową, na której fani mogą znaleźć ulubione potrawy. Jego fani uwielbiają tę stronę, ale Tomek słyszy skargi, że strona wczytuje się wolno. Tomek poprosił Cię o pomoc w przyspieszeniu strony.

Krok 1. Sprawdź witrynę

Jeśli chcesz poprawić szybkość wczytywania strony, zawsze zaczynaj od kontroli. Kontrola ma 2 ważne funkcje:

• Stanowi podstawową wartość bazową, która pozwala mierzyć kolejne zmiany.
• Daje ono dostęp do praktycznych wskazówek dotyczących tego, jakie zmiany przyniosą największe korzyści.

Skonfiguruj

Najpierw musisz skonfigurować nowe środowisko pracy dla witryny Tomka, aby móc wprowadzić w nim zmiany później:

1. Zremiksuj projekt witryny w Glitch. Nowy projekt otworzy się na karcie. Ta karta będzie nazywana kartą edytora.

   

   Nazwa projektu zmieni się z tony na losowo wygenerowaną nazwę. Masz teraz własną edytowalną kopię kodu. Później możesz wprowadzić w nim zmiany.

2. 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ą. Wczytanie strony może trochę potrwać.

   

3. Otwórz Narzędzia deweloperskie obok wersji demonstracyjnej.

   

Określ punkt odniesienia

Wartość bazowa to zapis skuteczności witryny przed wprowadzeniem jakichkolwiek ulepszeń.

1. Otwórz panel Lighthouse. Może być ukryty za double_arrow Więcej paneli.

   

2. Dopasuj ustawienia konfiguracji raportu Lighthouse do tych na zrzucie ekranu. Oto omówienie różnych opcji:

   • check_box Wyczyść pamięć. Zaznaczenie tego pola wyboru spowoduje wyczyszczenie miejsca na dane powiązanego ze stroną przed każdą kontrolą. Pozostaw to ustawienie włączone, jeśli chcesz kontrolować sposób, w jaki użytkownicy odwiedzają Twoją witrynę po raz pierwszy. Wyłącz to ustawienie, jeśli chcesz korzystać z witryny po raz kolejny.
   • check_box Włącz próbkowanie JS. Ta opcja jest domyślnie wyłączona. Gdy ta opcja jest włączona, dodaje do zrzutu wydajności szczegółowe stosy wywołań JavaScriptu, ale może spowalniać generowanie raportów. Śledzenie jest dostępne w more_vert menu Narzędzia > View Unthrottled Trace (Wyświetl Unthrottled Trace) po wygenerowaniu raportu Lighthouse.
   • Symulowane ograniczanie (domyślnie) arrow_drop_down. Ta opcja symuluje typowe warunki przeglądania na urządzeniu mobilnym. Nazywa się to „symulowanym”, ponieważ Lighthouse w rzeczywistości nie ogranicza przepustowości podczas procesu kontroli. Zamiast tego ekstrapoluje czas wczytywania strony na urządzeniach mobilnych. Ustawienie Ograniczanie wykorzystania przy użyciu narzędzi deweloperskich (zaawansowane) powoduje natomiast ograniczenie wydajności procesora i sieci, co skutkuje dłuższym procesem kontroli.
   • Tryb > radio_button_checked Nawigacja (domyślny). Ten tryb analizuje pojedyncze wczytanie strony, a tego właśnie potrzebujemy w tym samouczku. Więcej informacji znajdziesz w artykule Trzy tryby.
   • Urządzenie > radio_button_checked Urządzenie mobilne. Opcja na urządzeniach mobilnych zmienia ciąg znaków klienta użytkownika i symuluje widoczny obszar na urządzenia mobilne. Opcja na komputery wyłącza w zasadzie tylko zmiany wprowadzane na urządzeniach mobilnych.
   • Kategorie > check_box Skuteczność. Jedna włączona kategoria sprawia, że Lighthouse generuje raport tylko z odpowiednim zestawem kontroli. Inne kategorie możesz pozostawić włączone, jeśli chcesz zobaczyć, jakie typy rekomendacji się pojawiają. Wyłączenie nietrafnych kategorii nieznacznie przyspiesza proces kontroli.

3. Kliknij Analizuj wczytanie strony. Po 10–30 sekundach w panelu Lighthouse wyświetli się raport skuteczności witryny.

   

Postępowanie w przypadku błędów w raportach

Jeśli w raporcie Lighthouse wystąpi błąd, uruchom kartę demonstracyjną w oknie incognito bez otwartych kart. Dzięki temu Chrome będzie działać z czystym dźwiękiem. Zwłaszcza rozszerzenia do Chrome mogą zakłócać proces kontroli.

Interpretowanie raportu

Liczba u góry raportu to ogólny wynik skuteczności witryny. Później, po wprowadzeniu zmian w kodzie, ta liczba powinna wzrosnąć. Wyższy wynik oznacza większą skuteczność.

Wskaźniki

Przewiń w dół do sekcji Dane i kliknij Rozwiń widok. Aby zapoznać się z dokumentacją danych, kliknij Więcej informacji...

W tej sekcji znajdziesz dane liczbowe dotyczące skuteczności witryny. 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 po raz pierwszy wyrenderowana na ekranie. Jest to ważny etap postrzegania przez użytkownika wczytywania strony, a Czas do pełnej interaktywności wskazuje punkt, w którym strona wydaje się wystarczająco gotowa do obsługi interakcji z użytkownikiem.

Zrzuty ekranu

Następny jest zbiór zrzutów ekranu, który pokazuje, jak strona wyglądała po załadowaniu.

Możliwości

Następna jest sekcja Możliwości, która zawiera konkretne wskazówki, jak zwiększyć wydajność 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 możliwość jest ważna, i konkretne zalecenia, jak rozwiązać problem.

Diagnostyka

Sekcja Diagnostyka zawiera więcej informacji o czynnikach, które wpływają na czas wczytywania strony.

Zaliczone audyty

Sekcja Zaliczone audyty pokazuje, co witryna robi prawidłowo. Kliknij, aby ją rozwinąć.

Krok 2. Eksperyment

Sekcja Możliwości w raporcie Lighthouse zawiera wskazówki dotyczące zwiększania wydajności strony. W tej sekcji wdrożysz zalecane zmiany w bazie kodu, sprawdzając po każdej zmianie witrynę, aby zmierzyć, jak wpływają one na szybkość.

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 zmniejszeniu lub skompresowaniu pliku tekstowego przed przesłaniem go przez sieć. To tak jak można skompresować folder przed wysłaniem go e-mailem, aby zmniejszyć jego rozmiar.

Zanim włączysz kompresję, masz kilka sposobów, by ręcznie sprawdzić, czy zasoby tekstowe są kompresowane.

Otwórz panel Sieć i zaznacz settings Ustawienia > check_box Używaj dużych wierszy żądań.

W każdej komórce Rozmiar znajdują się 2 wartości. Wartość górna to rozmiar pobranego zasobu. Dolna wartość to rozmiar nieskompresowanego zasobu. Jeśli obie wartości są takie same, zasób nie jest kompresowany podczas przesyłania przez sieć. W tym przykładzie zarówno górna, jak i dolna wartość w polu bundle.js to 1.4 MB.

Możesz też sprawdzić stopień kompresji, sprawdzając nagłówki HTTP zasobu:

1. Kliknij bundle.js i otwórz kartę Nagłówki.

   

2. W sekcji Nagłówki odpowiedzi poszukaj nagłówka content-encoding. Nie powinna być widoczna, co oznacza, że plik bundle.js nie został skompresowany. Gdy zasób jest skompresowany, nagłówek jest zwykle ustawiony na gzip, deflate lub br. Wyjaśnienie tych wartości znajdziesz w sekcji Dyrektywy.

Dość już wyjaśnień. Czas wprowadzić zmiany. Włącz kompresję tekstu, dodając kilka wierszy kodu:

1. 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'));
   ...
   

2. Pamiętaj, by umieścić app.use(compression()) przed app.use(express.static('build')).

   

3. Poczekaj, aż Glitch wdroży nową kompilację witryny. Wesoły emotikon w lewym dolnym rogu oznacza udane wdrożenie.

Skorzystaj z poznanych wcześniej przepływów pracy, aby ręcznie sprawdzić, czy kompresja działa:

1. Wróć na kartę demonstracyjną i załaduj ponownie stronę.

   Kolumna Rozmiar powinna teraz zawierać dwie różne wartości zasobów tekstowych, takich jak bundle.js. Górna wartość 269 KB w przypadku bundle.js to rozmiar pliku, który został wysłany przez sieć, a dolna wartość 1.4 MB to rozmiar pliku nieskompresowanego.

   

2. Sekcja Nagłówki odpowiedzi bundle.js powinna teraz zawierać nagłówek content-encoding: gzip.

   

Ponownie uruchom na stronie raport Lighthouse, aby zmierzyć wpływ kompresji tekstu na szybkość wczytywania strony:

1. Otwórz panel Lighthouse i na pasku działań u góry kliknij Przeprowadź kontrolę....

   

2. Pozostaw ustawienia bez zmian i kliknij Analizuj wczytywanie strony.

   

Super! To chyba postęp. Ogólny wynik skuteczności powinien wzrosnąć, co oznacza, że strona działa szybciej.

Kompresja tekstu w świecie rzeczywistym

Większość serwerów ma naprawdę proste rozwiązania umożliwiające kompresję. Poszukaj informacji o konfiguracji serwera, którego używasz do kompresji tekstu.

Zmień rozmiar obrazów

Z nowego raportu wynika, że prawidłowe wymiary zdjęć to jeszcze większa szansa.

Zmiana rozmiaru obrazów skraca czas wczytywania dzięki zmniejszeniu rozmiaru plików z obrazami. Jeśli użytkownik wyświetla zdjęcia na ekranie urządzenia mobilnego o szerokości 500 pikseli, nie ma sensu wysyłać obrazów o szerokości 1500 pikseli. Najlepiej jest wysłać zdjęcie o szerokości maksymalnie 500 pikseli.

1. W raporcie kliknij Odpowiedni rozmiar obrazów, aby sprawdzić, których rozmiarów obrazy należy zmienić. Wygląda na to, że wszystkie 4 obrazy są za duże.

   

2. Wróć na kartę edytora, otwórz src/model.js.

3. Zamień const dir = 'big' na const dir = 'small'. Ten katalog zawiera kopie tych samych obrazów, których rozmiar został zmieniony.

4. Sprawdź stronę ponownie, aby zobaczyć, jak ta zmiana wpływa na wydajność wczytywania.

   

Wygląda na to, że zmiana ma tylko niewielki wpływ na ogólny wynik skuteczności. Nie widać jednak wyraźnie, ile danych sieciowych oszczędzasz użytkownikom. Całkowity rozmiar starych zdjęć wynosił około 6,1 MB, a obecnie tylko 633 kB. Możesz to sprawdzić na pasku stanu u dołu panelu Sieć.

Zmiana rozmiaru obrazów w świecie rzeczywistym

W przypadku małych aplikacji wystarczy jednorazowa zmiana rozmiaru. Przy dużej aplikacji to oczywiście nie skalowalne. Oto kilka strategii zarządzania obrazami w dużych aplikacjach:

• Zmieniaj rozmiar obrazów podczas kompilacji.
• W procesie kompilacji utwórz różne rozmiary każdego obrazu, a potem użyj w kodzie pliku srcset. Podczas działania przeglądarka wybiera rozmiar najlepiej odpowiadający urządzeniu, na którym ma działać. Zobacz Obrazy o zbliżonych rozmiarach.
• Używaj sieci CDN związanej z obrazami, która umożliwia dynamiczne zmienianie rozmiaru obrazu w razie potrzeby.
• A najlepiej zoptymalizuj każdy obraz. Często przynosi to ogromne oszczędności. Optymalizacja polega na uruchomieniu obrazu za pomocą specjalnego programu, który zmniejsza rozmiar pliku graficznego. Więcej wskazówek znajdziesz w artykule Najważniejsze wskazówki dotyczące optymalizacji obrazów.

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 wyświetli stronę. Celem jest uruchomienie tylko podstawowego kodu CSS i JavaScript, który jest wymagany do prawidłowego wyświetlania strony.

Pierwszą rzeczą jest znalezienie kodu, który nie musi być wykonywany podczas wczytywania strony.

1. Kliknij Wyeliminuj zasoby blokujące renderowanie, aby zobaczyć te zasoby: lodash.js i jquery.js.

   

2. W zależności od używanego systemu operacyjnego naciśnij następujące klawisze, aby otworzyć menu poleceń:

   • Mac: Command + Shift + P.
   • W systemach Windows, Linux i ChromeOS: Control + Shift + P

3. Zacznij pisać Coverage i kliknij Pokaż zasięg.

   

   W panelu otworzy się karta Stan.

   

4. Kliknij odśwież Załaduj ponownie. Na karcie Pokrycie znajdziesz informacje o tym, jaka część kodu w językach bundle.js, jquery.js i lodash.js jest wykonywana podczas wczytywania strony.

   

   Na tym zrzucie ekranu widać, że nie jest używanych odpowiednio około 74% i 30% plików jQuery i Lodash.

5. Kliknij wiersz jquery.js. Narzędzia deweloperskie otworzy plik w panelu Źródła. Jeśli obok wiersza znajduje się zielony pasek, został on wykonany. Czerwony pasek obok wiersza kodu oznacza, że nie został on wykonany i na pewno nie jest potrzebny podczas wczytywania strony.

   

6. Przewiń trochę kod jQuery. Niektóre z wierszy, które są „wykonane”, to w rzeczywistości tylko komentarze. Kolejnym sposobem zmniejszenia rozmiaru pliku jest uruchomienie kodu za pomocą minifikatora, który usuwa komentarze.

Krótko mówiąc, jeśli pracujesz z własnym kodem, na karcie Stan możesz analizować kod według wiersza i wysyłać tylko kod potrzebny do wczytania strony.

Czy pliki jquery.js i lodash.js w ogóle są potrzebne do wczytania strony? Na karcie Blokowanie żądań możesz sprawdzić, co się dzieje, gdy zasoby są niedostępne.

1. Kliknij kartę Sieć i ponownie otwórz menu poleceń.

2. Zacznij pisać blocking i wybierz Pokaż blokowanie żądań. Otworzy się karta Request Block (Blokowanie żądań).

   

3. Kliknij Dodaj wzór, wpisz /libs/* w polu tekstowym i naciśnij Enter, by potwierdzić.

   

4. 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 są w ogóle niepotrzebne.

   

5. Kliknij Usuń wszystkie wzorce, aby usunąć wzorzec blokowania /libs/*.

Ogólnie rzecz biorąc, karta Request Blokowanie (Blokowanie żądań) przydaje się do symulowania zachowania strony w sytuacji, gdy nie ma dostępnych zasobów.

Teraz usuń z kodu odwołania do tych plików i ponownie sprawdź stronę:

1. Wróć na kartę edytora, otwórz template.html.

2. 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>
   

3. Poczekaj, aż witryna zostanie skompilowana i wdrożona ponownie.

4. Sprawdź stronę jeszcze raz w panelu Lighthouse. Twój ogólny wynik powinien być znowu lepszy.

   

Optymalizacja krytycznej ścieżki renderowania w rzeczywistości

Krytyczna ścieżka renderowania odnosi się do kodu potrzebnego do wczytania strony. Aby przyspieszyć ładowanie strony, wystarczy przesłać tylko krytyczny kod podczas jej wczytywania, a pozostałe ładować leniwie.

• Jest mało prawdopodobne, że znajdziesz skrypty, które da się usunąć od razu, ale okazuje się, że wiele skryptów nie trzeba żądać podczas wczytywania strony, a tylko żądania asynchroniczne. Zapoznaj się z sekcją Używanie asynchronicznego i opóźniania.
• Jeśli używasz platformy, sprawdź, czy ma ona tryb produkcyjny. Ten tryb może korzystać z funkcji takich jak trząsanie drzewem w celu wyeliminowania niepotrzebnego kodu, który blokuje newralgiczne renderowanie.

Mniej pracy z wątkiem głównym

Najnowszy raport pokazuje pewne niewielkie potencjalne oszczędności w sekcji Możliwości, ale jeśli przewiniesz stronę w dół do sekcji Diagnostyka, wygląda na to, że największym wąskim gardłem jest zbyt duża część głównej aktywności wątku.

Wątek główny to miejsce, w którym przeglądarka wykonuje większość działań niezbędnych do wyświetlenia strony, np. analizuje i wykonuje kod HTML, CSS i JavaScript.

Celem jest użycie panelu Skuteczność do przeanalizowania działań, jakie wykonuje wątek główny podczas wczytywania strony, i znalezienia sposobów na odłożenie w czasie niepotrzebnej pracy lub usunięcie z niej niepotrzebnej pracy.

1. Otwórz Wydajność > Ustawienia przechwytywania i w sekcji Sieć ustaw Wolne 3G, a dla opcji CPU na 6x spowolnienie.

   

   Urządzenia mobilne mają zwykle większe ograniczenia sprzętowe niż laptopy czy komputery stacjonarne, więc te ustawienia umożliwiają wczytywanie strony tak, jakby użytkownik korzystał z mniej wydajnego urządzenia.

2. Kliknij odśwież Załaduj ponownie. Narzędzia deweloperskie ponownie ładują stronę, a następnie wyświetlają wizualizację wszystkiego, co trzeba zrobić, aby załadować stronę. Ta wizualizacja będzie nazywana trace.

   

Śledzenie pokazuje aktywność w kolejności chronologicznej, od lewej do prawej. Wykresy FPS, CPU i NET u góry przedstawiają przegląd klatek na sekundę oraz aktywności procesora i sieci.

Żółta ściana widoczna w sekcji Przegląd oznacza, że procesor był całkowicie zajęty wykonywaniem skryptów. To wskazówka, że możesz przyśpieszyć ładowanie strony, wykonując mniej pracy w języku JavaScript.

Zbadaj log czasu, aby znaleźć sposoby na ograniczenie pracy w języku JavaScript:

1. Kliknij sekcję Czasy, aby ją rozwinąć.

   

   W React jest sporo czasów działań użytkownika. Wygląda na to, że aplikacja Tony’ego korzysta z trybu programistycznego React. Przejście na tryb produkcyjny React powinno najprawdopodobniej przynieść kilka korzyści w zakresie wydajności.

2. Ponownie kliknij Czas, aby zwinąć tę sekcję.

3. Przejrzyj sekcję Główne. Ta sekcja zawiera chronologiczny dziennik aktywności w głównym wątku (od lewej do prawej). Oś Y (od góry do dołu) pokazuje przyczynę wystąpienia zdarzeń.

   

   W tym przykładzie zdarzenie Evaluate Script spowodowało wykonanie funkcji (anonymous), co spowodowało wykonanie polecenia __webpack__require__, wykonanie polecenia ./src/index.jsx itd.

4. Przewiń na sam dół sekcji Main (Główne). Gdy korzystasz z platformy, większość głównych działań jest spowodowana przez nią, na co zwykle nie masz wpływu. Aktywność spowodowana przez aplikację znajduje się zwykle na dole strony.

   

   Wygląda na to, że w tej aplikacji funkcja App powoduje wiele wywołań funkcji mineBitcoin. Wygląda na to, że Tomek może używać urządzeń swoich fanów do wydobywania kryptowalut...

5. Otwórz kartę Od dołu do góry u dołu. Na tej karcie można znaleźć informacje o działaniach, które trwały najdłużej. Jeśli nie widzisz nic w sekcji Od dołu do góry, kliknij etykietę sekcji Główne.

   

   Sekcja Od dołu zawiera tylko informacje o aktualnie wybranym działaniu lub grupie aktywności. Jeśli na przykład klikniesz jedną z aktywności mineBitcoin, w sekcji Od dołu zobaczysz tylko informacje o jednym z nich.

   Kolumna Czas własny pokazuje, ile czasu poświęcono bezpośrednio na poszczególne działania. W tym przypadku funkcja mineBitcoin poświęciła około 82% czasu głównego wątku.

Czas sprawdzić, czy użycie trybu produkcyjnego i zmniejszenie liczby działań JavaScript przyspiesza wczytywanie strony. Uruchom tryb produkcyjny:

1. Na karcie edytora otwórz webpack.config.js.
2. Zmień "mode":"development" na "mode":"production".
3. Poczekaj na wdrożenie nowej kompilacji.

4. Ponownie sprawdź stronę.

   

Ogranicz aktywność JavaScript, usuwając wywołanie funkcji mineBitcoin:

1. Na karcie edytora otwórz src/App.jsx.
2. Skomentuj wywołanie funkcji this.mineBitcoin(1500) w: constructor.
3. Poczekaj na wdrożenie nowej kompilacji.
4. Ponownie sprawdź stronę.

Jak zawsze, możesz na przykład zmniejszyć wartości Największe wyrenderowanie treści i Skumulowane przesunięcie układu.

Zmniejszenie głównego wątku w świecie rzeczywistym

Ogólnie rzecz biorąc, panel Skuteczność dostarcza najczęściej informacji o działaniach podejmowanych w trakcie wczytywania witryny i sposobów na usunięcie zbędnych aktywności.

Jeśli wolisz sposób console.log(), interfejs API User Timing API umożliwia dowolne oznaczenie określonych faz cyklu życia aplikacji w celu śledzenia czasu ich trwania.

Podsumowanie

• Zanim zdecydujesz się na optymalizację pod kątem wydajności wczytywania witryny, zawsze zaczynaj od kontroli. Audyt stanowi punkt odniesienia i wskazuje, co można poprawić.
• Wprowadzaj jedną zmianę naraz i sprawdzaj stronę po każdej zmianie, aby zobaczyć, jak wpływa ona na skuteczność.

Dalsze kroki

Przeprowadzaj audyty w swojej witrynie. Jeśli potrzebujesz pomocy z interpretacją raportu lub znalezienia sposobów na poprawę wydajności wczytywania, skorzystaj z tych sposobów na uzyskanie pomocy od społeczności Narzędzi deweloperskich:

• Zgłoś błędy w tym dokumencie w repozytorium developer.chrome.com.
• Raporty o błędach możesz zgłaszać w Narzędziach deweloperskich na stronie Błędy w Chromium.
• Omów funkcje i zmiany na liście adresowej. Nie używaj listy adresowej, aby zadawać pytania do zespołu pomocy. Zamiast tego użyj Stack Overflow.
• Ogólną pomoc dotyczącą korzystania z Narzędzi deweloperskich znajdziesz na stronie Stack Overflow. Żeby zgłosić błędy, zawsze używaj narzędzia Błędy w Chromium.
• Napisz do nas na tweeta przez @ChromeDevTools.