Zasoby blokujące renderowanie

Zasoby blokujące renderowanie to pliki, które przeglądarka musi pobrać i przetworzyć, zanim będzie mogła wyświetlić jakąkolwiek treść. Są to głównie arkusze stylów, do których odwołuje się nagłówek dokumentu, oraz skrypty synchroniczne napotykane podczas parsowania. To one są najczęstszym powodem, dla którego strona internetowa wyświetla się dłużej, niż uzasadnia to jej zawartość.

Blokada arkuszy stylów ma uzasadniony powód. Wyświetlanie treści przed udostępnieniem stylów powodowałoby pojawienie się niestylizowanej treści, a następnie irytujące przeformatowanie, więc przeglądarki czekają. Problem nie polega na blokowaniu arkuszy stylów, ale na tym, że strony zazwyczaj ładują znacznie więcej stylów, niż wymaga początkowy widok, w tym style dla komponentów znajdujących się dalej na stronie, dla innych szablonów i dla funkcji, z których użytkownik może nigdy nie skorzystać – a wszystkie te elementy muszą pojawić się, zanim cokolwiek zostanie wyświetlone.

Skrypty blokują się, ponieważ skrypt napotkany podczas parsowania może zmodyfikować dokument, więc parser zatrzymuje się do momentu jego wykonania. Większość skryptów nie wymaga tego zachowania: narzędzia analityczne, widżety czatu, narzędzia personalizacji i większość kodu aplikacji mogą być wykonywane po przeanalizowaniu dokumentu bez utraty poprawności. Dodanie atrybutu defer pozwala na kontynuację parsowania i późniejsze wykonywanie skryptów w kolejności, podczas gdy asynchroniczne wykonywanie skryptów następuje natychmiast po ich otrzymaniu, bez konieczności gwarantowania kolejności.

Standardowym rozwiązaniem w przypadku arkuszy stylów jest oddzielenie stylów wymaganych dla początkowego widoku od reszty. Część krytyczna jest wstawiana bezpośrednio do dokumentu, więc nie jest wymagane żadne żądanie, a pozostała część jest ładowana w sposób, który nie powoduje blokowania. Jest to skuteczne, ale zwiększa złożoność kompilacji, ponieważ zestaw krytyczny musi być generowany ponownie przy każdej zmianie stylów, a nieaktualny, krytyczny kod CSS powoduje widoczne defekty.

Zasoby zewnętrzne często wnoszą największy wkład i są najtrudniejsze do kontrolowania. Menedżerowie tagów, platformy do obsługi zgód, dostawcy czcionek, narzędzia do czatów i frameworki testowe są zazwyczaj dodawane do nagłówka dokumentu z zachowaniem blokowania, a każde z nich wymaga połączenia z oddzielnym źródłem. Łączne opóźnienie jest znaczne, a ponieważ każdy z nich został dodany przez inny zespół z uzasadnionego powodu, nikt nie ponosi odpowiedzialności za całość. Audyt całkowitego kosztu i przypisanie go do funkcji żądającej jest tym, co uwidacznia kompromis.

Czcionki wymagają szczególnego traktowania, ponieważ blokują renderowanie tekstu, a nie strukturę strony. W zależności od strategii wyświetlania, tekst może być niewidoczny podczas pobierania czcionki, co oznacza, że ​​treść, która została już w pełni pobrana, jest celowo wstrzymywana. Wybór strategii, która natychmiast wyświetla tekst zastępczy i zamienia go po pobraniu czcionki, oraz wstępne ładowanie czcionek używanych powyżej linii zagięcia, zapobiega sytuacji, w której strona jest technicznie renderowana i wygląda na pustą.

Pomiar rzeczywistych kosztów wymaga ostrożności, ponieważ usunięcie zasobu blokującego nie zawsze przynosi przewidywane oszczędności. Zasoby są pobierane równolegle, więc wyeliminowanie jednego może po prostu sprawić, że inny stanie się ograniczeniem, a zaobserwowana poprawa jest często mniejsza niż suma poszczególnych szacunków. Weryfikacja poprzez pomiar po każdej zmianie, zamiast polegania na prognozowanych sumach, pozwala zachować dokładność oczekiwań.

Identyfikacja tego, co faktycznie blokuje, jest prosta dzięki standardowym narzędziom, które raportują zasoby blokujące i szacują oszczędności wynikające z usunięcia każdego z nich. Szacunki należy traktować jako orientacyjne, a nie precyzyjne, ponieważ usunięcie jednego zasobu blokującego często ujawnia, że ​​innym było rzeczywiste ograniczenie, a usprawnienia najlepiej weryfikować pomiarami, a nie na podstawie samych danych z raportu.

Ponieważ zaangażowane zasoby są zazwyczaj dodawane przez kilka zespołów w miarę upływu czasu, naprawa wymaga zarówno zarządzania, jak i inżynierii. W praktyce audyt i priorytetyzacja leżą w wydajność sieci praca, zmiany kompilacji są wdrażane poprzez rozwój produktów, a decyzje dotyczące tego, które narzędzia firm trzecich uzasadniają koszt blokowania, wymagają porozumienia z zespołami, które o nie poprosiły, co w przypadku większości witryn oznacza dział marketingu cyfrowego.