Informacje o ścieżce krytycznej

Krytyczna ścieżka renderowania odnosi się do czynności, które należy wykonać do chwili rozpoczęcia renderowania strony w przeglądarce. Aby renderować strony, przeglądarki potrzebują samego dokumentu HTML oraz wszystkich newralgicznych zasobów niezbędnych do wyrenderowania dokumentu.

Umieszczanie dokumentu HTML w przeglądarce było omówione w poprzednim module ogólnych kwestii związanych z wydajnością HTML. W tym module zajmiemy się jednak tym, co robi przeglądarka po pobraniu dokumentu HTML w celu wyrenderowania strony.

Renderowanie progresywne

Sieć jest rozpowszechniana przez przyrodę. W przeciwieństwie do aplikacji natywnych instalowanych przed użyciem przeglądarki nie mogą polegać na witrynach mających wszystkie zasoby potrzebne do wyrenderowania strony. Dlatego przeglądarki bardzo dobrze radzą z stopniowym renderowaniem stron. Aplikacje natywne zwykle mają etap instalacji, a potem etap trwający. Jednak w przypadku stron internetowych i aplikacji internetowych linie między tymi dwoma etapami są znacznie mniej różne, a przeglądarki zostały zaprojektowane specjalnie z myślą o tym.

Gdy tylko przeglądarka dysponuje zasobami umożliwiającymi wyrenderowanie strony, zwykle zaczyna to robić. W związku z tym zostaje zwiększony wybór kiedy renderowania – kiedy jest za wcześnie?

Jeśli przeglądarka renderuje się tak szybko, jak to możliwe, gdy zawiera tylko fragment kodu HTML, ale bez CSS lub niezbędnego JavaScriptu, strona przez chwilę będzie wyglądać na uszkodzonej i znacznie się zmienić podczas ostatecznego renderowania. To gorsze niż wyświetlanie pustego ekranu przez jakiś czas do chwili, gdy w przeglądarce będzie więcej zasobów potrzebnych do wstępnego renderowania i poprawiania wrażeń użytkowników.

Z drugiej strony, jeśli przeglądarka będzie czekać na dostępność wszystkich zasobów, zamiast wykonywać renderowanie sekwencyjne, użytkownik będzie musiał długo czekać – często jest to niepotrzebne, jeśli strona była dostępna znacznie wcześniej.

Przeglądarka musi znać minimalną liczbę zasobów, na jaką powinna czekać, by uniknąć wyświetlania reklam w oczywisty sposób uszkodzony. Z drugiej strony przeglądarka nie powinna też czekać na wyświetlenie użytkownikowi jakiejś treści dłużej, niż jest to konieczne. Sekwencja czynności, jakie przeglądarka wykonuje przed wykonaniem początkowego renderowania, nazywana jest krytyczną ścieżką renderowania.

Znajomość krytycznej ścieżki renderowania może poprawić wydajność witryny, ponieważ nie blokuje renderowania pierwszej strony bardziej niż jest to konieczne. Jednocześnie ważne jest, aby nie dopuścić do zbyt wczesnego renderowania, usuwając z krytycznej ścieżki renderowania zasoby potrzebne do tego wstępnego renderowania.

(Krytyczną) ścieżkę renderowania

Ścieżka renderowania składa się z tych kroków:

• Tworzenie modelu obiektu dokumentu (DOM) na podstawie kodu HTML.
• Konstrukcja obiektowego modelu CSS (CSSOM) z arkusza CSS.
• zastosowanie kodu JavaScript, który zmienia DOM lub CSSOM.
• Tworzenie drzewa renderowania z metod DOM i CSSOM.
• Wykonuj operacje związane ze stylem i układem na stronie, aby sprawdzić, które elementy pasują do siebie.
• Maluj piksele elementów w pamięci.
• Połącz piksele, jeśli któreś z nich się nakładają.
• Fizycznie narysuj wszystkie wygenerowane piksele na ekranie.

Czy użytkownik zobaczy treść na ekranie dopiero po wykonaniu wszystkich tych czynności.

Ten proces renderowania odbywa się wiele razy. Wstępne renderowanie wywołuje ten proces, ale w miarę pojawiania się kolejnych zasobów wpływających na renderowanie strony przeglądarka ponownie uruchomi ten proces – lub tylko jego fragmenty – aby zaktualizować to, co widzi użytkownik. Krytyczna ścieżka renderowania koncentruje się na procesie opisanym wcześniej na potrzeby wstępnego renderowania i zależy od niezbędnych zasobów krytycznych.

Jakie zasoby znajdują się na krytycznej ścieżce renderowania?

Przeglądarka musi poczekać na pobranie zasobów krytycznych, zanim ukończy pierwsze renderowanie. Znajdziesz tam:

• Część kodu HTML.
• Blokujący renderowanie kod CSS w elemencie <head>.
• Blokujący renderowanie kod JavaScript w elemencie <head>.

Kluczowe jest to, że przeglądarka przetwarza kod HTML w sposób strumieniowy. Gdy tylko przeglądarka pobierze dowolny fragment kodu HTML strony, zacznie ją przetwarzać. Dzięki temu przeglądarka może – i często to zrobić – wyrenderować ją dobrze przed otrzymaniem pozostałego kodu HTML strony.

Co ważne, przy pierwszym renderowaniu przeglądarka zwykle nie będzie czekać na:

• Cały kod HTML.
• Czcionki.
• Obrazy.
• Kod JavaScript nieblokujący renderowania poza elementem <head> (np. elementy <script> umieszczone na końcu kodu HTML).
• Nieblokujący renderowanie kod CSS poza elementem <head> lub CSS z wartością atrybutu media, która nie ma zastosowania do bieżącego widocznego obszaru.

Czcionki i obrazy są często postrzegane przez przeglądarkę jako treści, które mają zostać wypełnione podczas kolejnych renderowania strony, więc nie muszą wstrzymywać wstępnego renderowania. Może to jednak oznaczać, że podczas wstępnego renderowania pozostają puste obszary, a tekst ukryty jest w trakcie oczekiwania na czcionki lub gdy obrazy są dostępne. Co gorsza, jeśli nie ma wystarczającej ilości miejsca na pewne rodzaje treści – zwłaszcza jeśli w kodzie HTML brakuje wymiarów obrazu – układ strony może się zmienić, gdy treść zostanie wczytana w późniejszym czasie. Ten aspekt wygody użytkowników mierzy się za pomocą danych skumulowane przesunięcie układu (CLS).

Element <head> ma kluczowe znaczenie dla przetwarzania krytycznej ścieżki renderowania. Tak dużo, że w następnej sekcji omówimy to bardziej szczegółowo. Optymalizacja treści elementu <head> to kluczowy aspekt wydajności strony. Aby na razie poznać krytyczną ścieżkę renderowania, musisz wiedzieć, że element <head> zawiera metadane dotyczące strony i jej zasobów, ale nie widzi faktycznej treści, którą widzi użytkownik. Widoczna treść jest zawarta w elemencie <body>, który następuje po elemencie <head>. Zanim przeglądarka będzie mogła wyrenderować treść, potrzebuje zarówno treści, jak i metadanych dotyczących sposobu jej renderowania.

Jednak nie wszystkie zasoby, do których odwołuje się element <head>, są niezbędne do początkowego wyrenderowania strony, więc przeglądarka czeka tylko na te, które będą. Aby zidentyfikować zasoby na krytycznej ścieżce renderowania, musisz znać mechanizmy CSS i JavaScript blokujące renderowanie i blokujące parsery.

Zasoby blokujące renderowanie

Niektóre zasoby są uważane za tak ważne, że przeglądarka wstrzymuje renderowanie stron, dopóki się nimi nie zająć. Do tej kategorii należy domyślnie usługa porównywania cen.

Gdy przeglądarka widzi kod CSS (wbudowany w element <style> lub przywoływany zewnętrznie zasób określony przez element <link rel=stylesheet href="...">), unika wyrenderowania dalszych treści do czasu zakończenia pobierania i przetwarzania kodu CSS.

Zablokowanie renderowania nie zawsze oznacza, że przeglądarka nie może wykonywać żadnych innych działań. Przeglądarki starają się pracować możliwie najbardziej wydajnie. Gdy więc zauważy, że musi pobrać zasób CSS, wysyła żądanie i wstrzymuje renderowanie, ale przetwarza pozostałą część kodu HTML i tymczasem szuka innych rzeczy do zrobienia.

Zasoby blokujące renderowanie, np. CSS, służą do blokowania całego renderowania strony w momencie wykrycia. Oznacza to, że to, czy dany kod CSS blokuje renderowanie, lub nie, zależy od tego, czy przeglądarka ją wykryła. Niektóre przeglądarki (Firefox, a teraz także Chrome) blokują renderowanie treści poniżej zasobu blokującego renderowanie. Oznacza to, że w przypadku krytycznej ścieżki blokującego renderowanie jesteśmy zwykle zainteresowani zasobami blokującymi renderowanie w elemencie <head>, ponieważ skutecznie blokują one renderowanie całej strony.

Najnowsza innowacja to atrybut blocking=render, dodany do Chrome 105. Dzięki temu deweloperzy mogą wyraźnie oznaczać element <link>, <script> lub <style> jako blokujący renderowanie, dopóki element nie zostanie przetworzony. Parser może nadal przetwarzać dokument.

Zasoby blokujące parser

Zasoby blokujące parser to takie, które uniemożliwiają przeglądarce wyszukiwanie innych zadań, które mogą być wykonywane przez dalsze analizowanie kodu HTML. JavaScript domyślnie blokuje analizowanie (chyba że jest wyraźnie oznaczony jako asynchroniczny lub odroczony), ponieważ może zmieniać element DOM lub CSSOM podczas wykonywania. Dlatego przeglądarka nie może kontynuować przetwarzania innych zasobów, dopóki nie pozna pełnego wpływu żądanego kodu JavaScript na kod HTML strony. Synchroniczny JavaScript blokuje parser.

Zasoby blokujące parsery także skutecznie blokują renderowanie. Parser nie może kontynuować przetwarzania zasobu blokującego analizowanie, dopóki nie zostanie w pełni przetworzony, dlatego nie może uzyskać dostępu do treści i je wyrenderować po nim. W trakcie oczekiwania przeglądarka może wyrenderować dowolny otrzymany do tej pory kod HTML. Jeśli jednak chodzi o krytyczną ścieżkę renderowania, użycie zasobów blokujących parser przez <head> oznacza, że renderowanie całej zawartości strony jest blokowane.

Zablokowanie parsera może się wiązać z wysokim kosztem wydajności – a nie tylko zablokowaniem renderowania. Z tego powodu przeglądarki będą próbowały ograniczyć te koszty, używając dodatkowego parsera HTML (skanera wstępnego wczytywania) do pobierania nadchodzących zasobów, gdy główny parser HTML jest zablokowany. Chociaż nie jest to tak dobre jak w przypadku faktycznej analizy kodu HTML, pozwala ono jednak funkcjom sieciowym w przeglądarce wyprzedzać zablokowany parser, co oznacza, że ryzyko jego ponownego zablokowania w przyszłości będzie mniejsze.

Identyfikowanie zasobów blokujących

Wiele narzędzi do kontroli wydajności identyfikuje zasoby renderujące i blokujące parser. WebPageTest oznacza zasoby blokujące renderowanie pomarańczowym okręgiem na lewo od adresu URL zasobu:

Wszystkie zasoby blokujące renderowanie muszą zostać pobrane i przetworzone przed rozpoczęciem renderowania, o czym świadczy ciągła ciemnozielona linia w kaskadzie.

Lighthouse wyróżnia też zasoby blokujące renderowanie, ale w bardziej subtelny sposób i tylko wtedy, gdy rzeczywiście opóźniają renderowanie strony. Pomaga to uniknąć fałszywych trafień, gdy w inny sposób ograniczasz blokowanie renderowania. Uruchomienie w Lighthouse tego samego adresu URL strony co w poprzedniej ilustracji w postaci kodu WebPageTest pozwala zidentyfikować tylko 1 z arkuszy stylów jako zasób blokujący renderowanie.

Optymalizacja krytycznej ścieżki renderowania

Optymalizacja krytycznej ścieżki renderowania obejmuje skrócenie czasu potrzebnego na otrzymanie kodu HTML (reprezentowanego przez wskaźnik czasu do pierwszego bajtu (TTFB)) zgodnie z opisem w poprzednim module i zmniejszenie wpływu zasobów blokujących renderowanie. Te koncepcje zostaną omówione w kolejnych modułach.

Krytyczna ścieżka renderowania treści

Przez długi czas krytyczna ścieżka renderowania miała wpływ na początkowe renderowanie. Pojawiły się jednak bardziej zorientowane na użytkownika dane dotyczące wydajności w internecie, które wątpują, czy punkt końcowy krytycznej ścieżki renderowania powinien być pierwszym wyrenderowaniem, czy też jednym z bardziej wyrenderowanych treści później.

Alternatywnym widokiem jest skoncentrowanie się na czasie do momentu największego wyrenderowania treści (LCP) – a nawet pierwszego wyrenderowania treści (FCP) – w ramach ścieżki renderowania treści (lub ścieżki klucza, jak inni mogą to nazywać). W takim przypadku może być konieczne uwzględnienie zasobów, które niekoniecznie blokują – tak jak jest to typowa definicja krytycznej ścieżki renderowania – ale są niezbędne do renderowania treści.

Niezależnie od dokładnej definicji tego, co określasz jako „krytyczne”, ważne jest zrozumienie, co leży na początkowym renderowaniu i jakie są najważniejsze treści. Pierwsze wyrenderowanie oznacza pierwszą możliwą możliwość wyrenderowania czegokolwiek dla użytkownika. Najlepiej, jeśli powinien to być coś wartościowego – nie np. koloru tła – ale nawet jeśli nie jest to treść, warto zaprezentować użytkownikowi coś, co jest argumentem za pomiar krytycznej ścieżki renderowania w standardowej postaci. Jednocześnie ważna jest pomiar tego, kiedy główna treść została wyświetlona użytkownikowi.

Identyfikowanie ścieżki renderowania treści

Wiele narzędzi rozpoznaje elementy LCP i określa, kiedy są renderowane. Oprócz elementu LCP narzędzie Lighthouse pomaga też w identyfikacji faz LCP i czasu poświęcanego na nie, dzięki czemu łatwiej określisz, na czym najlepiej skoncentrować działania optymalizacyjne:

W przypadku bardziej złożonych witryn Lighthouse wyróżnia też łańcuchy żądań o znaczeniu krytycznym podczas osobnego audytu:

Ten audyt Lighthouse obejmuje wszystkie zasoby ładowane z wysokim priorytetem, więc uwzględnia czcionki internetowe i inne treści, które Chrome ustawia jako zasoby o wysokim priorytecie, nawet jeśli w rzeczywistości nie są blokowane.

Sprawdź swoją wiedzę

Następny krok: optymalizacja wczytywania zasobów

W tym module omówiono niektóre z teorii renderowania strony internetowej przez przeglądarkę, a w szczególności tego, co jest potrzebne do wstępnego renderowania strony. W następnym module dowiesz się, jak zoptymalizować wczytywanie zasobów i jak można zoptymalizować tę ścieżkę renderowania.