Data publikacji: 31 marca 2014 r.
Podstawą każdej solidnej strategii skuteczności jest prawidłowy pomiar i instrumentacja. Nie możesz optymalizować tego, czego nie możesz mierzyć. W tym przewodniku opisujemy różne podejścia do pomiaru skuteczności CRP.
- Lighthouse przeprowadza na stronie serię testów automatycznych, a potem generuje raport o wydajności CRP strony. Dzięki temu możesz szybko testować, ulepszać i zwiększać skuteczność CRP konkretnej strony wczytywanej w przeglądarce.
- Metoda Navigation Timing API rejestruje dane RUM (Real User Monitoring). Jak sama nazwa wskazuje, dane te są rejestrowane na podstawie rzeczywistych interakcji użytkowników z witryną i zapewniają dokładny wgląd w rzeczywistą wydajność CRP z perspektywy użytkowników korzystających z różnych urządzeń i warunków sieciowych.
Zazwyczaj dobrym podejściem jest użycie Lighthouse do zidentyfikowania oczywistych możliwości optymalizacji CRP, a potem użycie interfejsu Navigation Timing API do monitorowania działania aplikacji w rzeczywistych warunkach.
Audytowanie strony za pomocą Lighthouse
Lighthouse to narzędzie do audytu aplikacji internetowych, które przeprowadza serię testów na danej stronie, a potem wyświetla wyniki w skonsolidowanym raporcie. Możesz uruchomić Lighthouse jako rozszerzenie Chrome lub moduł NPM, co jest przydatne do integracji Lighthouse z systemami ciągłej integracji.
Aby rozpocząć, przeczytaj artykuł Auditing Web Apps With Lighthouse (Kontrola aplikacji internetowych w Lighthouse).
Gdy uruchomisz Lighthouse jako rozszerzenie Chrome, wyniki CRP strony będą wyglądać tak jak na zrzucie ekranu poniżej.
Więcej informacji o wynikach tego audytu znajdziesz w sekcji Krytyczne łańcuchy żądań.
Narzędzia w kodzie za pomocą interfejsu Navigation Timing API
Połączenie interfejsu Navigation Timing API i innych zdarzeń w przeglądarce wysyłanych podczas wczytywania strony pozwala rejestrować i rejestrować rzeczywistą wydajność CRP dowolnej strony.
Każda etykieta na poprzednim diagramie odpowiada sygnaturze czasowej o wysokiej rozdzielczości, którą przeglądarka rejestruje dla każdej wczytywanej strony. W tym konkretnym przypadku pokazujemy tylko część wszystkich różnych sygnatur czasowych – na razie pomijamy wszystkie sygnatury czasowe związane z siecią, ale wrócimy do nich w następnej lekcji.
Co oznaczają te sygnatury czasowe?
domLoading
: to jest sygnatura czasowa rozpoczęcia całego procesu, przeglądarka zamierza rozpocząć analizowanie pierwszych otrzymanych bajtów dokumentu HTML.domInteractive
: oznacza moment, w którym przeglądarka zakończyła analizę całego kodu HTML i utworzenie modelu DOM.domContentLoaded
: oznacza punkt, w którym DOM jest gotowy i nie ma żadnych arkuszy stylów blokujących wykonywanie kodu JavaScript. Oznacza to, że możemy teraz (potencjalnie) stworzyć drzewo renderowania.- Wiele frameworków JavaScript czeka na to zdarzenie, zanim zacznie wykonywać własną logikę. Z tego powodu przeglądarka rejestruje sygnatury czasowe
EventStart
iEventEnd
, aby umożliwić nam śledzenie czasu wykonania.
- Wiele frameworków JavaScript czeka na to zdarzenie, zanim zacznie wykonywać własną logikę. Z tego powodu przeglądarka rejestruje sygnatury czasowe
domComplete
: jak sama nazwa wskazuje, oznacza to, że wszystkie zasoby na stronie (np. obrazy) zostały przetworzone i pobrane – innymi słowy, wskaźnik ładowania przestał się obracać.loadEvent
: w ostatnim kroku podczas wczytywania każdej strony przeglądarka wysyła zdarzenieonload
, które może aktywować dodatkową logikę aplikacji.
Specyfikacja HTML określa konkretne warunki dla każdego zdarzenia: kiedy ma ono zostać uruchomione, jakie warunki muszą zostać spełnione i inne ważne kwestie. W naszym przypadku skupimy się na kilku kluczowych etapach związanych z krytyczną ścieżką renderowania:
domInteractive
oznacza, że DOM jest gotowy.domContentLoaded
zwykle oznacza, że DOM i CSSOM są gotowe.- Jeśli nie ma żadnego kodu JavaScript blokującego parser, polecenie
DOMContentLoaded
uruchomi się natychmiast podomInteractive
.
- Jeśli nie ma żadnego kodu JavaScript blokującego parser, polecenie
domComplete
oznacza, że strona i wszystkie jej zasoby podrzędne są gotowe.
<!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>
Poprzedni przykład może na pierwszy rzut oka wydawać się nieco przytłaczający, ale w rzeczywistości jest całkiem prosty. Interfejs Navigation Timing API przechwytuje wszystkie odpowiednie sygnatury czasowe, a nasz kod czeka na uruchomienie zdarzenia onload
(przypomina, że zdarzenie onload
uruchamia się po domInteractive
, domContentLoaded
i domComplete
), a następnie oblicza różnicę między poszczególnymi sygnaturami czasowymi.
Podsumowując, mamy teraz określone kamienie milowe do śledzenia i podstawową funkcję do generowania tych pomiarów. Pamiętaj, że zamiast drukować te dane na stronie, możesz też zmodyfikować kod, by wysyłał je do serwera analitycznego (Google Analytics robi to automatycznie). Dzięki temu możesz obserwować wydajność swoich stron i identyfikować te, które kwalifikują się do optymalizacji.
A co z Narzędziami deweloperskimi?
Chociaż dokumenty te czasami korzystają z panelu Network (Sieć w Narzędziach deweloperskich w Chrome) do ilustrowania koncepcji CRP, Narzędzia deweloperskie nie sprawdzają się w przypadku pomiarów CRP, ponieważ nie mają wbudowanego mechanizmu izolowania kluczowych zasobów. Aby je zidentyfikować, przeprowadź audyt Lighthouse.