Podstawą każdej solidnej strategii zwiększania skuteczności są dobre pomiary i instrumenty. Nie da się zoptymalizować rzeczy, których nie można zmierzyć. Objaśniamy w nim różne metody pomiaru skuteczności CRP.
- Podejście Lighthouse przeprowadza serię automatycznych testów na stronie, a następnie generuje raport o skuteczności CRP strony. Takie podejście zapewnia szybki i łatwy ogólny przegląd skuteczności CRP w przypadku konkretnej strony wczytywanej w przeglądarce, co umożliwia szybkie testowanie i powtarzanie tych działań oraz zwiększanie ich wydajności.
- Interfejs Navigation Timing API rejestruje dane Real User Monitoring (RUM). Jak sama nazwa wskazuje, dane te są rejestrowane na podstawie rzeczywistych interakcji użytkowników z witryną i dają dokładny wgląd w rzeczywistą skuteczność CRP w przypadku użytkowników korzystających z różnych urządzeń i sieci.
Ogólnie rzecz biorąc, dobrym sposobem jest wykorzystanie narzędzia Lighthouse do zidentyfikowania oczywistych możliwości optymalizacji CRP i dostosowanie kodu za pomocą interfejsu Navigation Timing API do monitorowania wydajności aplikacji w terenie.
Audyt strony w Lighthouse
Lighthouse to narzędzie do kontroli aplikacji internetowych, które przeprowadza serię testów na określonej stronie, a potem wyświetla jej wyniki w formie skonsolidowanego raportu. Narzędzie Lighthouse możesz uruchomić jako rozszerzenie do Chrome lub moduł NPM, co przydaje się przy integracji Lighthouse z systemami ciągłej integracji.
Na początek zapoznaj się z artykułem Kontrola aplikacji internetowych za pomocą narzędzia Lighthouse.
Gdy uruchomisz Lighthouse jako rozszerzenie do Chrome, wyniki CRP na Twojej stronie będą wyglądać tak jak na zrzucie ekranu poniżej.
Więcej informacji o wynikach tej kontroli znajdziesz w artykule Łańcuchy żądań krytycznych.
Dostosowywanie kodu za pomocą interfejsu Navigation Timing API
Połączenie interfejsu Navigation Timing API i innych zdarzeń w przeglądarce wysyłanych podczas wczytywania strony umożliwia rejestrowanie i rejestrowanie rzeczywistej wydajności CRP dowolnej strony.
Każda z etykiet na powyższym diagramie odpowiada sygnaturze czasowej w wysokiej rozdzielczości śledzonej przez przeglądarkę dla każdej wczytanej strony. W tym przypadku pokazujemy tylko ułamek sygnatur czasowych – na razie pomijamy wszystkie sygnatury czasowe związane z siecią, ale wrócimy do nich w kolejnej lekcji.
Co oznaczają te sygnatury czasowe?
domLoading
: to sygnatura czasowa całego procesu; przeglądarka zacznie analizować pierwsze odebrane bajty dokumentu HTML.domInteractive
: wskazuje moment, w którym przeglądarka zakończyła analizowanie całej konstrukcji HTML i DOM.domContentLoaded
: wskazuje moment, w którym model DOM jest gotowy i nie ma arkuszy stylów blokujących wykonanie JavaScriptu. Oznacza to, że możemy (potencjalnie) utworzyć drzewo renderowania.- Wiele platform JavaScript czeka na to zdarzenie, zanim zaczną wykonywać własną logikę. Z tego powodu przeglądarka rejestruje sygnatury czasowe
EventStart
iEventEnd
, aby umożliwić nam śledzenie czasu trwania danego wykonania.
- Wiele platform JavaScript czeka na to zdarzenie, zanim zaczną wykonywać własną logikę. Z tego powodu przeglądarka rejestruje sygnatury czasowe
domComplete
: jak sama nazwa wskazuje, przetwarzanie zostało zakończone, a wszystkie zasoby na stronie (obrazy itp.) zostały pobrane. Oznacza to, że wskaźnik ładowania przestał się obracać.loadEvent
: na ostatnim etapie każdego wczytywania strony przeglądarka uruchamia zdarzenieonload
, które może aktywować dodatkową logikę aplikacji.
Specyfikacja HTML określa konkretne warunki dla każdego zdarzenia: kiedy ma być wywołane, jakie warunki należy spełnić itd. Na potrzeby naszych celów skupimy się na kilku kluczowych etapach związanych z krytyczną ścieżką renderowania:
- Gdy DOM jest gotowy, oznacza
domInteractive
. domContentLoaded
zwykle oznacza, gdy DOM i CSSOM są gotowe.- Jeśli nie ma parsera blokującego kod JavaScript,
DOMContentLoaded
uruchomi się natychmiast podomInteractive
.
- Jeśli nie ma parsera blokującego kod JavaScript,
domComplete
oznacza gotowość strony i wszystkich jej zasobów podrzędnych.
<!DOCTYPE html>
<html>
<head>
<title>Critical Path: Measure</title>
<meta name="viewport" content="width=device-width,initial-scale=1" />
<link href="style.css" rel="stylesheet" />
<script>
function measureCRP() {
var t = window.performance.timing,
interactive = t.domInteractive - t.domLoading,
dcl = t.domContentLoadedEventStart - t.domLoading,
complete = t.domComplete - t.domLoading;
var stats = document.createElement('p');
stats.textContent =
'interactive: ' +
interactive +
'ms, ' +
'dcl: ' +
dcl +
'ms, complete: ' +
complete +
'ms';
document.body.appendChild(stats);
}
</script>
</head>
<body onload="measureCRP()">
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg" /></div>
</body>
</html>
Przykład powyżej może na pierwszy rzut oka wydawać się nieco przytłaczający, ale w rzeczywistości jest on dość prosty. Interfejs Navigation Timing API rejestruje wszystkie istotne sygnatury czasowe, a nasz kod po prostu czeka na uruchomienie zdarzenia onload
– pamiętaj, że zdarzenie onload
uruchamia się po domInteractive
, domContentLoaded
i domComplete
– i oblicza różnicę między różnymi sygnaturami czasowymi.
Teraz mamy do śledzenia konkretne etapy i prostą funkcję ich wyświetlania. Pamiętaj, że zamiast drukować dane na stronie, możesz też zmodyfikować kod i wysyłać je na serwer analityczny (Google Analytics robi to automatycznie). To świetny sposób, by monitorować skuteczność stron i wykrywać te, które mogą skorzystać na optymalizacji.
Co z Narzędziami deweloperskimi?
Chociaż niektóre dokumenty korzystają z panelu Network (Sieć) w Chrome DevTools do przedstawienia pojęć związanych z CRP, narzędzia DevTools nie nadają się obecnie do pomiarów CRP, ponieważ nie mają wbudowanego mechanizmu izolowania zasobów krytycznych. Uruchom kontrolę Lighthouse, aby łatwiej zidentyfikować takie zasoby.