Wdrożenie defer w WordPressie najbezpieczniej przeprowadzić za pomocą wtyczki optymalizacyjnej, po wykonaniu kopii zapasowej i testach na środowisku staging. Atrybut defer pozwala pobierać skrypty JavaScript bez zatrzymywania parsowania HTML, ale nie powinien być bez sprawdzenia stosowany do każdego pliku.
Dlaczego defer poprawia wydajność WordPressa?
JavaScript umieszczony w sekcji <head> może blokować parsowanie HTML. Przeglądarka zatrzymuje wtedy budowanie strony, pobiera skrypt i wykonuje go, zanim przejdzie do kolejnych elementów dokumentu. Takie pliki określa się jako render-blocking JavaScript.
Atrybut defer pozwala przeglądarce kontynuować odczytywanie HTML podczas pobierania pliku. Skrypt zostanie wykonany dopiero po sparsowaniu dokumentu. Może to skrócić czas pojawienia się pierwszej treści, czyli FCP, i ograniczyć opóźnienia wpływające na LCP oraz pozostałe wskaźniki Core Web Vitals.
Defer nie jest tym samym co delay. Defer uruchamia skrypt po sparsowaniu HTML, natomiast delay może wstrzymać jego wykonanie aż do interakcji użytkownika, na przykład kliknięcia, przewinięcia strony lub ruchu kursora. Delay bywa bardziej agresywny i wymaga szerszych testów.
Defer, async czy standardowe ładowanie?
Różnica między tymi metodami dotyczy momentu pobrania i wykonania skryptu oraz zachowania kolejności plików:
| Metoda | Ładowanie | Parsowanie HTML | Kolejność wykonania |
|---|---|---|---|
| Standardowa | Skrypt jest pobierany podczas odczytu dokumentu | Blokuje parsowanie | Zachowana |
| Async | Pobierany równolegle | Nie blokuje do momentu pobrania, ale wykonanie może zatrzymać odczyt | Brak gwarancji |
| Defer | Pobierany równolegle | Nie blokuje parsowania | Zachowana |
W praktyce async pasuje głównie do niezależnych skryptów, które nie muszą czekać na inne pliki. Defer jest bezpieczniejszym wyborem dla wielu skryptów motywu i wtyczek, ponieważ zachowuje kolejność ich wykonywania. Jeśli jeden plik zależy od drugiego, ta właściwość ma znaczenie.
Jak wdrożyć defer w WordPressie?
Dla większości użytkowników WordPressa najwygodniejsza będzie wtyczka do optymalizacji, na przykład WP Rocket, LiteSpeed Cache albo Perfmatters. Nazwy zakładek mogą się różnić zależnie od wersji, ale schemat pracy pozostaje podobny.
Przed zmianami przygotuj podstawowe zabezpieczenia:
- Kopia zapasowa plików i bazy danych.
- Środowisko staging, na którym można sprawdzić konfigurację bez wpływu na użytkowników.
- Lista funkcji wymagających testu, takich jak menu, formularze, logowanie, wyszukiwarka i koszyk.
- Podstawowe wyniki z PageSpeed Insights dla strony głównej i kilku ważnych podstron.
Następnie przeprowadź wdrożenie w tej kolejności:
- Wybierz narzędzie do optymalizacji. Jeśli serwer korzysta z LiteSpeed, naturalnym wyborem może być LiteSpeed Cache. Na innych konfiguracjach możesz użyć WP Rocket lub Perfmatters. Nie instaluj kilku wtyczek wykonujących dokładnie te same optymalizacje.
- Wyczyść cache. Usuń pamięć podręczną WordPressa, serwera, CDN i przeglądarki, jeśli jest używana. Dzięki temu test nie będzie oparty na starych plikach.
- Znajdź ustawienie defer. Szukaj opcji określanej jako „Load JavaScript deferred”, „Defer JavaScript” albo podobnie. Włącz ją bez aktywowania od razu wszystkich dodatkowych funkcji, takich jak delay, łączenie plików czy agresywna minifikacja.
- Zapisz ustawienia i wyczyść cache. Przy CDN wykonaj także jego purge, aby nowa wersja skryptów trafiła do użytkowników.
- Sprawdź najważniejsze podstrony. Otwórz stronę główną, wpis, formularz kontaktowy, ekran logowania oraz – w przypadku sklepu – produkt, koszyk i kasę.
- Porównaj wyniki. Uruchom PageSpeed Insights w trybie mobilnym i desktopowym. Analizuj nie tylko wynik punktowy, ale także FCP, LCP, INP i zgłoszenia dotyczące blokowania renderowania.
Nie włączaj defer dla wszystkich skryptów bez testu. Szczególnej uwagi wymaga jQuery oraz pliki, które korzystają z jQuery. Problem może pojawić się także w starych motywach, sliderach, formularzach i elementach menu. Jeśli strona działa na WooCommerce, ostrożnie testuj koszyk, kasę i konto użytkownika.
Co zrobić, gdy po włączeniu defer strona się psuje?
Najczęstsze objawy konfliktu to niedziałające menu, brak reakcji przycisków, zatrzymany slider, niewysyłające się formularze albo błędy w koszyku. Najpierw otwórz narzędzia deweloperskie przeglądarki, przejdź do zakładki Console i odśwież stronę. Błąd często wskazuje nazwę pliku lub bibliotekę, która została uruchomiona w złej kolejności.
Problem można zwykle naprawić przez dodanie konkretnego pliku do listy wykluczeń. Wtyczki używają nazw takich jak „Exclude scripts”, „Defer exclusions”, „Excluded JavaScript” albo „Script Manager”. Wykluczaj pojedyncze zasoby, zapisuj zmianę i ponownie testuj stronę. Nie wyłączaj całej funkcji tylko dlatego, że jeden skrypt wymaga wyjątku.
Po wdrożeniu sprawdź przede wszystkim te elementy:
- Czy menu desktopowe i mobilne otwiera się oraz reaguje na kliknięcia.
- Czy formularze wyświetlają walidację i pozwalają wysłać dane.
- Czy slidery, galerie i rozwijane sekcje działają poprawnie.
- Czy w konsoli przeglądarki nie pojawiają się nowe błędy JavaScript.
- Czy koszyk, kasa, logowanie i płatności działają na urządzeniu mobilnym.
Jeśli nie potrafisz ustalić, który plik powoduje konflikt, wyłącz defer, przywróć działającą wersję z kopii zapasowej lub stagingu i wprowadzaj zmiany ponownie, pojedynczo. Przy rozbudowanej stronie pomoc dewelopera może być tańsza niż naprawianie nieprzetestowanej konfiguracji na produkcji.
Defer nie rozwiązuje wszystkich problemów z JavaScriptem
Odłożenie wykonania skryptów ogranicza blokowanie renderowania, ale nie zastępuje optymalizacji obrazów, cache, poprawnej konfiguracji serwera ani usunięcia niepotrzebnych wtyczek. Nie każdy skrypt powinien być opóźniany, a delay wymaga osobnej oceny, ponieważ może zmienić moment uruchamiania funkcji widocznych dla użytkownika.
Po każdej większej aktualizacji WordPressa, motywu lub wtyczki powtórz testy. Zależności między skryptami mogą się zmienić, dlatego lista wykluczeń wymaga okresowego przeglądu.
Najbezpieczniejszy schemat to: wykonaj backup, włącz defer na stagingu, przetestuj funkcje, dodaj wyjątki dla problematycznych plików i dopiero wtedy przenieś konfigurację na produkcję.
