JavaScript blokujący renderowanie: atrybuty defer i async oraz kolejność ładowania

Co oznacza zalecenie usunięcia zasobów blokujących renderowanie

Zalecenie to informacja, że na ścieżce do pierwszego wyświetlenia strony stoją pliki, na które przeglądarka musi poczekać. Dopóki ich nie pobierze i nie przetworzy, ekran odwiedzającego pozostaje pusty, nawet jeśli sam dokument HTML dotarł już w całości. Dokumentacja Chrome opisuje te pliki jako żądania sieciowe, które uniemożliwiły pierwsze wyrenderowanie strony i które mogą opóźniać także wyświetlenie największego elementu.

Warto znać dokładne kryteria, bo raport nie wskazuje wszystkich skryptów na stronie, tylko te, które spełniają określone warunki. Zgodnie z opisem audytu Wyeliminuj zasoby blokujące renderowanie Lighthouse oznacza dwa rodzaje adresów. Pierwszy to znacznik skryptu znajdujący się w nagłówku dokumentu, czyli w sekcji head, który nie ma atrybutu defer ani atrybutu async. Drugi to odwołanie do arkusza stylów, które nie ma atrybutu disabled i nie ma atrybutu media dopasowanego do urządzenia użytkownika. Wartość media równa all jest traktowana jako blokująca.

W nowszych wydaniach Lighthouse ten sam wynik znajduje się w części ze statystykami wydajności pod nazwą dotyczącą żądań blokujących renderowanie. W raporcie PageSpeed Insights pozycja ta pojawia się w części diagnostycznej, po rozwinięciu widać listę konkretnych adresów plików. To właśnie ta lista jest punktem wyjścia do dalszej pracy: każdy adres trzeba przypisać do funkcji na stronie, zanim cokolwiek zostanie zmienione.

Gdzie sprawdzić listę plików

Listę plików można odczytać w trzech miejscach. W PageSpeed Insights wystarczy wpisać adres podstrony i po zakończeniu analizy odszukać w diagnostyce pozycję o żądaniach blokujących renderowanie. W przeglądarce Chrome ten sam audyt uruchamia się w Narzędziach deweloperskich, w panelu Lighthouse, po zaznaczeniu kategorii wydajności. Trzecie miejsce to panel Pokrycie, który pokazuje, jaka część każdego pliku została faktycznie użyta podczas wczytywania.

Dokumentacja panelu Pokrycie podaje dwie drogi dojścia. Pierwsza prowadzi przez menu poleceń Narzędzi deweloperskich, w którym po wpisaniu słowa coverage pojawia się polecenie otwierające ten panel. Druga prowadzi przez ikonę z trzema kropkami w prawym górnym rogu, pozycję Więcej narzędzi i pozycję Pokrycie. Po użyciu przycisku ponownego wczytania strony panel rejestruje kod potrzebny do jej załadowania. W tabeli widać adres URL zasobu, jego typ, łączną liczbę bajtów, liczbę bajtów nieużywanych oraz pasek, na którym część szara oznacza kod nieużywany, a zielona używany.

Jak przeglądarka wczytuje skrypt bez żadnych atrybutów

Skrypt bez atrybutów jest pobierany i wykonywany natychmiast, zanim przeglądarka przejdzie do dalszej części dokumentu. Dokumentacja MDN poświęcona elementowi script opisuje to wprost: skrypty bez atrybutów async i defer oraz bez oznaczenia modułu, a także kod wpisany bezpośrednio w dokument, są pobierane i uruchamiane od razu, a dopiero potem przeglądarka kontynuuje analizę strony.

W praktyce oznacza to przestój. Przeglądarka czyta dokument od góry do dołu i buduje z niego strukturę strony. Gdy w nagłówku natrafia na zwykły znacznik skryptu, zatrzymuje czytanie, wysyła żądanie po plik, czeka na odpowiedź serwera, wykonuje kod i dopiero wtedy wraca do pracy. Wszystko, co w dokumencie znajduje się niżej, a więc nagłówek, tekst oferty i zdjęcia, czeka w kolejce. Jeśli takich plików jest kilka i pochodzą z różnych serwerów, przestoje się sumują.

Ta sama dokumentacja zwraca uwagę na rozróżnienie, które bywa pomijane. Zwykły skrypt blokuje przede wszystkim analizę dokumentu, a renderowanie mogą wstrzymać wyłącznie skrypty umieszczone w nagłówku. Istnieje też atrybut blocking z wartością render, którym programista może świadomie zażądać, aby treść nie została pokazana przed wykonaniem danego skryptu. Przydaje się to w rzadkich sytuacjach, gdy kod musi zadziałać przed pierwszym wyświetleniem, a jednocześnie nie powinien wstrzymywać czytania dokumentu.

Dla właściciela firmy istotny jest wniosek praktyczny. Hipotetyczna kancelaria z Krakowa może mieć stronę z lekkim tekstem i jednym zdjęciem, a mimo to odwiedzający przez dłuższą chwilę widzi biały ekran, ponieważ w nagłówku wczytują się po kolei biblioteka do animacji, skrypt mapy, wtyczka czatu i kod pokazu slajdów. Żaden z tych plików nie jest potrzebny do wyświetlenia nazwy kancelarii i numeru telefonu, ale każdy z nich stoi przed treścią w kolejce. Szerzej o plikach pochodzących z obcych serwerów piszemy we wpisie o tym, jak skrypty zewnętrzne spowalniają stronę.

Czym różnią się defer, async i moduły

Wszystkie trzy rozwiązania pozwalają pobierać plik równolegle z czytaniem dokumentu, różnią się natomiast chwilą wykonania kodu i tym, czy zachowana jest kolejność. Atrybut defer odkłada wykonanie do końca analizy dokumentu i pilnuje kolejności. Atrybut async uruchamia kod, gdy tylko plik zostanie pobrany, bez żadnej gwarancji kolejności. Skrypt modułowy zachowuje się domyślnie jak skrypt odroczony.

Atrybut defer

Według dokumentacji MDN atrybut defer informuje przeglądarkę, że skrypt ma zostać wykonany po przeanalizowaniu dokumentu, ale przed zdarzeniem DOMContentLoaded, czyli sygnałem, że struktura strony jest gotowa. Skrypty odroczone wykonują się w kolejności, w jakiej występują w dokumencie, i wstrzymują to zdarzenie do chwili, gdy wszystkie zostaną pobrane i wykonane. Dlatego defer jest bezpiecznym wyborem dla plików zależnych od siebie: biblioteka zapisana wyżej zawsze uruchomi się przed wtyczką zapisaną niżej.

Jest jedno ważne zastrzeżenie. Atrybut defer nie działa na kod wpisany bezpośrednio w dokument, czyli na znacznik bez atrybutu src wskazującego plik. Taki fragment wykona się natychmiast, niezależnie od tego, co programista dopisał w znaczniku.

Atrybut async

Skrypt z atrybutem async jest pobierany równolegle z analizą dokumentu i wykonywany, gdy tylko stanie się dostępny. MDN podkreśla dwie konsekwencje. Po pierwsze, samo pobieranie nie wstrzymuje strony, ale wykonanie kodu już tak, więc ciężki plik asynchroniczny, który dotrze wcześnie, potrafi przerwać budowanie strony w niekorzystnym momencie. Po drugie, nie ma gwarancji kolejności: plik, który dotrze szybciej, uruchomi się pierwszy, nawet jeśli w kodzie stoi niżej. Jeżeli znacznik ma oba atrybuty jednocześnie, przeglądarka zachowuje się tak, jakby podano wyłącznie async.

Skrypty modułowe

Moduł to plik JavaScript oznaczony wartością module w atrybucie type, który może importować inne pliki. Dokumentacja MDN wskazuje, że przetwarzanie takiego skryptu jest odraczane domyślnie, a atrybut defer nie ma na niego wpływu. Dopisanie atrybutu async zmienia zachowanie: moduł wraz z zależnościami jest pobierany równolegle i wykonywany, gdy tylko wszystko będzie gotowe. Moduły pobierane z innej domeny wymagają obsługi protokołu CORS, czyli zgody serwera na udostępnienie pliku innej witrynie. Dla starszych przeglądarek przewidziano atrybut nomodule, którym oznacza się plik zastępczy pomijany przez przeglądarki obsługujące moduły.

<!-- blokuje analizę dokumentu -->
<script src="/js/menu.js"></script>

<!-- wykonanie po analizie dokumentu, kolejność zachowana -->
<script src="/js/biblioteka.js" defer></script>
<script src="/js/slider.js" defer></script>

<!-- wykonanie zaraz po pobraniu, kolejność przypadkowa -->
<script src="/js/statystyki.js" async></script>

<!-- moduł: odroczony domyślnie -->
<script type="module" src="/js/aplikacja.js"></script>
<script nomodule src="/js/wersja-zastepcza.js"></script>

Który atrybut wybrać dla którego skryptu

Dla większości skryptów na stronie firmowej właściwym wyborem jest defer, ponieważ zachowuje kolejność i uruchamia kod wtedy, gdy struktura strony już istnieje. Atrybut async warto zarezerwować dla plików całkowicie niezależnych. Materiał web.dev o efektywnym wczytywaniu kodu JavaScript innej firmy ujmuje to podobnie: async pasuje do skryptów, które powinny zadziałać na wczesnym etapie ładowania, a jako przykład podaje kod analityczny, natomiast defer do zasobów mniej istotnych, takich jak odtwarzacz wideo umieszczony poniżej pierwszego ekranu.

Przegląd dobrze jest zacząć od prostego pytania przy każdym pliku: czy bez niego odwiedzający zobaczy treść widoczną bez przewijania i czy będzie mógł z niej skorzystać. Na tej podstawie pliki dzielą się na trzy grupy.

Pierwszą grupę tworzy kod niezbędny do pierwszego wyświetlenia. Jest go zwykle bardzo mało. Dokumentacja Lighthouse zaleca, aby taki krytyczny fragment przenieść do znacznika wpisanego bezpośrednio w dokument, a resztę pozostawić w pliku z atrybutem async lub defer. Materiał web.dev o optymalizacji LCP stwierdza wręcz, że synchroniczne skrypty w nagłówku są prawie zawsze zbędne.

Drugą grupę tworzą skrypty obsługujące to, co widać na stronie: menu, pokaz slajdów, zakładki, walidację formularza, koszyk. Tu sprawdza się defer, pod warunkiem że wszystkie pliki z jednego łańcucha zależności otrzymają go jednocześnie.

Trzecia grupa to dodatki, które mogą poczekać: okno czatu, mapa w stopce, odtwarzacz filmu na dole strony. Dla nich web.dev zaleca opóźnianie i jednocześnie ostrzega, że jeśli kod odpowiedzialny za późniejsze dociągnięcie zasobu nie zadziała, zasób może nie wczytać się wcale. Zbliżony mechanizm opisujemy we wpisie o leniwym ładowaniu obrazów i ramek.

Pozostaje pytanie, czy plik w ogóle jest potrzebny. Lighthouse wśród zaleceń wymienia także usunięcie nieużywanego kodu. Z naszej praktyki wynika, że na stronach rozwijanych od dawna zostają skrypty po wyłączonych funkcjach i zmienionych wtyczkach, a usunięcie takiego pliku daje więcej niż najlepiej dobrany atrybut.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Kiedy opóźnianie skryptów psuje działanie strony

Opóźnianie psuje stronę wtedy, gdy zmienia kolejność, od której zależy działanie kodu. Skrypty rzadko są samodzielne: wtyczka pokazu slajdów korzysta z biblioteki, formularz z kodu walidacji, a krótki fragment w treści strony uruchamia jedno i drugie. Wystarczy, że jedno ogniwo wykona się w innej chwili niż dotąd, i cały łańcuch przestaje działać.

Kod w treści strony a odroczona biblioteka

Najczęstszy scenariusz wynika wprost z reguł opisanych wyżej. Biblioteka w pliku otrzymuje atrybut defer, więc wykona się dopiero po przeanalizowaniu dokumentu. Kilka linii kodu wpisanych w treść strony, które z niej korzystają, nie podlega odroczeniu, ponieważ defer nie działa na znaczniki bez atrybutu src. Fragment uruchamia się od razu, nie znajduje biblioteki i kończy błędem. Na ekranie wygląda to jak slider, który pokazuje wszystkie zdjęcia jedno pod drugim, albo jak przycisk menu, który nie reaguje na dotknięcie.

<script src="/js/biblioteka-slajdow.js" defer></script>

<script>
  // ten kod wykona się natychmiast, a biblioteka jeszcze nie istnieje
  uruchomSlajdy('.pokaz');
</script>

Rozwiązania są dwa. Fragment można przenieść do osobnego pliku z atrybutem defer, zapisanego poniżej biblioteki, albo opakować go tak, aby czekał na zdarzenie DOMContentLoaded, które zgodnie z dokumentacją następuje dopiero po wykonaniu skryptów odroczonych.

Atrybut async na plikach zależnych od siebie

Drugi scenariusz to nadanie atrybutu async całej grupie plików naraz. Skoro kolejność wykonania zależy od tego, który plik szybciej dotrze, strona raz działa, a raz nie. Na szybkim łączu w biurze wszystko wygląda poprawnie, a problem ujawnia się u klienta korzystającego z telefonu w słabym zasięgu. Hipotetyczny sklep z Poznania mógłby w ten sposób tracić część zamówień z urządzeń mobilnych, nie widząc żadnego błędu na własnym komputerze.

Opóźnianie do pierwszej interakcji

Trzeci scenariusz dotyczy funkcji części wtyczek optymalizacyjnych: wstrzymania skryptów do chwili, gdy odwiedzający poruszy myszą, przewinie stronę albo dotknie ekranu. Nie jest to mechanizm przeglądarki, tylko dodatkowy kod, a poniższe uwagi to obserwacje z praktyki agencji. Metoda bardzo poprawia wynik testu laboratoryjnego, w którym nikt niczego nie klika. Na prawdziwej wizycie pierwsze dotknięcie przycisku menu bywa natomiast zużywane na samo uruchomienie skryptów, więc menu otwiera się dopiero za drugim razem. Ucierpieć może również czas reakcji strony, o którym piszemy we wpisie poświęconym wskaźnikowi INP, a pomiar ruchu uruchamiany po interakcji pomija wizyty, w których interakcji nie było.

Jak ustawić defer i async w WordPressie

W WordPressie sposób ładowania skryptu ustawia się przy jego rejestracji, kluczem strategy w tablicy argumentów funkcji wp_enqueue_script lub wp_register_script. Zgodnie z dokumentacją funkcji wp_enqueue_script klucz przyjmuje wartość defer albo async i jest dostępny od wersji 6.3. Ta sama tablica zawiera klucz in_footer, który przenosi znacznik do stopki.

wp_enqueue_script(
    'pokaz-slajdow',
    get_theme_file_uri( '/js/pokaz-slajdow.js' ),
    array( 'biblioteka-slajdow' ),
    '1.0',
    array(
        'strategy'  => 'defer',
        'in_footer' => true,
    )
);

WordPress nie stosuje wskazanej strategii bezwarunkowo. Ogłoszenie zespołu rozwijającego system, Registering scripts with async and defer attributes in WordPress 6.3, wyjaśnia, że podana wartość jest strategią zamierzoną, a system sprawdza drzewo zależności i wybiera strategię dopuszczalną. Jeśli z odroczonego pliku korzysta inny skrypt zarejestrowany jako blokujący, odroczony plik razem ze swoimi zależnościami także staje się blokujący.

To samo dotyczy fragmentów kodu dołączanych funkcją wp_add_inline_script. Fragment dodany w pozycji przed plikiem niczego nie zmienia. Fragment w pozycji po pliku, która jest ustawieniem domyślnym, powoduje, że plik główny jest traktowany jako blokujący i traci atrybut defer lub async. System sam chroni w ten sposób przed rozerwaną zależnością, ale skutek bywa mylący: programista ustawił odroczenie, a w kodzie strony atrybutu nie ma.

Skrypty można odraczać także wtyczkami optymalizacyjnymi, o których dokumentacja Lighthouse wspomina jako o sposobie na opóźnianie mniej ważnych zasobów w WordPressie. Z naszej praktyki wynika, że niemal zawsze potrzebna jest przy nich lista wyjątków, czyli plików, których nie wolno ruszać. W sklepach opartych na WooCommerce trafiają na nią zwykle skrypty koszyka i płatności.

Jak testować zmiany na menu, sliderach i formularzach

Zmiany w kolejności ładowania testuje się na kopii strony, plik po pliku albo grupa po grupie, sprawdzając po każdej zmianie wszystkie elementy interaktywne na telefonie i na komputerze. Włączenie wszystkich opcji naraz sprawia, że przy awarii nie wiadomo, który plik ją wywołał.

Jeśli środowiska testowego nie ma, pracę należy prowadzić w godzinach najmniejszego ruchu i z możliwością natychmiastowego cofnięcia ustawień. Przed każdym sprawdzeniem trzeba wyczyścić pamięć podręczną strony i otworzyć ją w oknie prywatnym, ponieważ zalogowany administrator często widzi inną wersję niż klient. Warto mieć też otwarty panel Konsola w Narzędziach deweloperskich Chrome. Z naszej praktyki wynika, że rozerwana zależność niemal zawsze zostawia tam czerwony komunikat o niezdefiniowanej funkcji wraz z nazwą pliku i numerem wiersza.

• Menu główne na telefonie: otwarcie i zamknięcie przy pierwszym dotknięciu, rozwijanie podmenu.
• Pokaz slajdów: poprawny układ od pierwszej chwili, działanie strzałek i przesuwania palcem.
• Formularz kontaktowy: komunikaty walidacji, zabezpieczenie przed spamem, faktyczne dotarcie wiadomości na skrzynkę.
• Sklep: dodanie produktu do koszyka, zmiana wariantu, przeliczenie dostawy, przejście przez płatność testową.
• Baner zgody na pliki cookie: wyświetlenie i zapisanie wyboru.
• Pomiar: zarejestrowanie odsłony i konwersji w Google Analytics oraz w Google Ads po testowym wysłaniu formularza.
• Mapa, czat, odtwarzacz wideo, zakładki i listy rozwijane na każdym typie podstrony.

Sprawdzenie samej strony głównej nie wystarcza. Każdy szablon ma własny zestaw skryptów, dlatego listę należy przejść osobno na podstronie usługi, wpisie na blogu, stronie kontaktu, a w sklepie także na karcie produktu, w koszyku i przy składaniu zamówienia. Hipotetyczny hydraulik z Łodzi, którego strona zbiera zgłoszenia przez formularz, o niedziałającym przycisku wysyłki dowiedziałby się dopiero po kilku dniach ciszy w skrzynce, dlatego test wysłania wiadomości należy wykonać od razu po wdrożeniu.

Jak ocenić efekt na FCP i LCP

Efekt ocenia się przez porównanie tych samych podstron przed zmianą i po niej, najpierw w teście laboratoryjnym, a potem w danych od rzeczywistych użytkowników. Odroczenie skryptów wpływa przede wszystkim na FCP, czyli pierwsze wyrenderowanie treści, i na tę część LCP, która wynika z czekania na pliki w nagłówku.

FCP to według definicji web.dev czas od otwarcia strony do chwili, gdy na ekranie pojawia się jakakolwiek część treści. Na liście sposobów poprawy tego wskaźnika usunięcie zasobów blokujących renderowanie stoi na pierwszym miejscu. LCP, czyli największe wyrenderowanie treści, mierzy moment wyświetlenia największego obrazu, bloku tekstu lub filmu widocznego w oknie przeglądarki, co opisuje materiał web.dev o LCP.

Gdzie w LCP widać wpływ skryptów

Materiał web.dev o optymalizacji największego wyrenderowania treści dzieli LCP na cztery części: czas do pierwszego bajtu, opóźnienie ładowania zasobu, czas wczytywania zasobu i opóźnienie renderowania elementu. Skrypty blokujące ujawniają się w ostatniej części. Wśród jej przyczyn dokument wymienia arkusze stylów i synchroniczne skrypty w nagłówku, które wciąż się wczytują, element dodawany do strony dopiero po wykonaniu JavaScriptu oraz długie zadania zajmujące przeglądarkę.

Wynika z tego praktyczna wskazówka. Jeżeli większość czasu zajmuje odpowiedź serwera albo pobieranie dużego zdjęcia, samo odroczenie skryptów niewiele zmieni i pracę trzeba zacząć gdzie indziej. Pomocne będą wtedy wpisy o tym, co opóźnia LCP na stronie, oraz o czasie odpowiedzi serwera. Jeżeli natomiast długie jest opóźnienie renderowania elementu, porządek w kolejności ładowania jest właściwym miejscem na początek.

Pomiar przed zmianą i po niej

Przed wdrożeniem należy zapisać wyniki FCP i LCP dla kilku reprezentatywnych podstron, osobno dla telefonów i komputerów. Pojedynczy test bywa przypadkowy, dlatego warto wykonać kilka pomiarów każdej podstrony. Po wdrożeniu te same testy powtarza się w tych samych warunkach i sprawdza trzy rzeczy: czy pozycja o żądaniach blokujących renderowanie zniknęła lub się skróciła, czy FCP i LCP spadły oraz czy nie pogorszyły się inne wskaźniki, zwłaszcza przesunięcia układu i czas reakcji na kliknięcie.

Test laboratoryjny pokazuje efekt od razu, ale opisuje jedno symulowane urządzenie. O tym, jak stronę odbierają klienci, mówią dane terenowe, które według web.dev pokazują między innymi PageSpeed Insights i raport o podstawowych wskaźnikach internetowych w Search Console. Zalecany cel dla LCP to wynik 2,5 sekundy lub lepszy w co najmniej 75 procentach wizyt. Dane te zbierają się przez dłuższy czas, więc poprawa staje się w nich widoczna z opóźnieniem. Różnice między oboma rodzajami pomiaru wyjaśniamy we wpisie o tym, dlaczego wynik testu różni się od danych od użytkowników.

Typowe pomyłki i sytuacje, w których potrzebna jest pomoc

Najczęstszą pomyłką jest traktowanie zniknięcia ostrzeżenia z raportu jako celu samego w sobie. Celem jest strona, która szybko pokazuje treść i działa poprawnie, a zalecenie to tylko wskazówka, gdzie szukać rezerw.

Częste jest też przekonanie, że async zawsze jest szybszy od defer. Plik asynchroniczny może wykonać się w trakcie budowania strony i ją przerwać, a plik odroczony czeka do końca analizy dokumentu, dlatego dla skryptów obsługujących wygląd i funkcje strony bezpieczniejszy jest defer. Zdarza się również dopisywanie atrybutów do kodu wpisanego w dokument w nadziei, że zostanie odroczony, choć przeglądarka je w takim przypadku pomija.

Kolejna pomyłka dotyczy zakresu pracy. Zalecenie obejmuje nie tylko JavaScript, ale również arkusze stylów. Dokumentacja Lighthouse proponuje wstawienie krytycznych stylów bezpośrednio w nagłówku dokumentu i asynchroniczne wczytanie pozostałych, a opis statystyki o żądaniach blokujących renderowanie zastrzega, że jest to technika zaawansowana, która przy błędnym wdrożeniu powoduje problemy, i że większość witryn osiąga zalecane wartości bez niej. Kroje pisma omawiamy osobno we wpisie o czcionkach internetowych a szybkości strony.

Pomoc specjalisty jest potrzebna wtedy, gdy strona korzysta z wielu wtyczek o niejasnych zależnościach, gdy po włączeniu odroczenia cokolwiek przestało działać i nie wiadomo dlaczego, gdy w grę wchodzi koszyk i płatności albo gdy witryna nie ma środowiska testowego. W takich przypadkach porządkowanie kolejności ładowania wykonujemy w ramach usługi SEO techniczne, a pełny obraz kondycji witryny daje audyt SEO, który pokazuje, czy skrypty są rzeczywiście największym problemem, czy tylko jednym z kilku.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl