Pomiar krytycznej ścieżki renderowania

Ilya Grigorik

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 i w prosty sposób sprawdzić skuteczność CRP na konkretnej stronie wczytywanej w przeglądarce, a także szybko testować, poprawiać i ulepszać jej skuteczność.
  • Interfejs Navigation Timing API rejestruje dane Real User Monitoring (RUM). Jak wskazuje ich nazwa, są one rejestrowane na podstawie interakcji rzeczywistych użytkowników z Twoją witryną i pozwalają uzyskać dokładny obraz rzeczywistej wydajności CRP w warunkach korzystania z witryny przez użytkowników na różnych urządzeniach i w różnych warunkach 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ł Audyt aplikacji internetowych za pomocą Lighthouse.

Gdy uruchomisz Lighthouse jako rozszerzenie Chrome, wyniki CRP strony będą wyglądać tak jak na zrzucie ekranu poniżej.

CRP w Lighthouse

Więcej informacji o wynikach tego audytu znajdziesz w sekcji Krytyczne łańcuchy żądań.

Połączenie interfejsu API dotyczącego czasu nawigacji z innymi zdarzeniami przeglądarki emitowanymi podczas wczytywania strony umożliwia rejestrowanie rzeczywistej wydajności CRP w dowolnej witrynie.

Navigation Timing

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 i EventEnd, aby umożliwić nam śledzenie czasu wykonania.
  • 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 zdarzenie onload, 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 parsowania blokującego JavaScript, funkcja DOMContentLoaded zostanie wywołana bezpośrednio po funkcji domInteractive.
  • 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>

Wypróbuj

Poprzedni przykład może na pierwszy rzut oka wydawać się nieco przytłaczający, ale w rzeczywistości jest całkiem prosty. Interfejs API Czas trwania nawigacji rejestruje wszystkie odpowiednie sygnatury czasowe, a nasz kod czeka na wywołanie zdarzenia onload (pamiętaj, że zdarzenie onload jest wywoływane po zdarzeniach domInteractive, domContentLoaded i domComplete) i oblicza różnicę między różnymi sygnaturami czasowymi.

Demo funkcji NavTiming

Podsumowując, mamy teraz określone kamienie milowe do śledzenia i podstawową funkcję do generowania tych pomiarów. Pamiętaj, że zamiast drukowania tych danych na stronie możesz zmodyfikować kod, aby wysyłać je na serwer analityki (Google Analytics robi to automatycznie). To świetny sposób na śledzenie skuteczności stron i identyfikowanie stron, które mogą wymagać optymalizacji.

A co z Narzędziami deweloperskimi?

Chociaż w tych dokumentach czasami używamy panelu Sieć w Narzędziach dla programistów w Chrome, aby zilustrować pojęcia związane z zabezpieczeniami na potrzeby ochrony zasobów, to narzędzia DevTools nie nadają się do pomiarów związanych z zabezpieczeniami na potrzeby ochrony zasobów, ponieważ nie mają wbudowanego mechanizmu izolowania zasobów krytycznych. Aby je zidentyfikować, przeprowadź audyt Lighthouse.

Prześlij opinię