Siedem na dziesięć stron, które nie przechodzą PageSpeed Insights, zwalnia przez cudzy JavaScript. Skrypty zewnętrzne, analityka, sieci reklamowe, czaty, czcionki, banery cookie blokują renderowanie i opóźniają First Contentful Paint o sekundy. A wyłączyć ich nie można: analityka zasila marketing, czat dostarcza leady, bez banera cookie strona nie przejdzie audytu.

Jest rozwiązanie: ładowanie odroczone. Skrypt ładuje się dopiero wtedy, gdy główna treść jest już widoczna dla użytkownika. Przeglądarka nie czeka, wskaźniki Core Web Vitals trafiają do zielonej strefy, a funkcjonalność strony nie cierpi.

Zebraliśmy wszystkie działające sposoby, od wbudowanych atrybutów HTML po techniki programowe i wtyczki do WordPressa. Z przykładami kodu, które można skopiować i zastosować już dziś.

💡 Szybki przegląd:

• Proszę poznać defer i async: tabela wyraźnie pokaże różnicę między atrybutami
• Proszę opanować programowe ładowanie na zdarzenie load: nowoczesna wersja metody Patricka Sextona
• Proszę skonfigurować Intersection Observer dla skryptów poniżej linii zagięcia: czaty, mapy, komentarze
• Proszę zoptymalizować WordPress bez edycji kodu: wtyczki Flying Scripts i Asset CleanUp

Jak skrypty zewnętrzne spowalniają ładowanie

Przeglądarka parsuje HTML od góry do dołu. Gdy napotka <script src="..."> bez atrybutów, parsowanie zostaje wstrzymane: przeglądarka pobiera skrypt, wykonuje go i dopiero potem kontynuuje analizę strony. To właśnie jest render-blocking, czyli blokowanie renderowania.

Dla użytkownika rezultatem jest biały ekran. Wskaźnik First Contentful Paint (FCP), czyli czas do pierwszego wyrenderowania treści, zależy bezpośrednio od tego, jak szybko przeglądarka przebrnie przez wszystkie blokujące skrypty. FCP wchodzi w skład Core Web Vitals i bezpośrednio wpływa na pozycję w wyszukiwarce.

Skrypty zewnętrzne bolą bardziej niż własne: znajdują się na cudzych serwerach i nie kontrolują Państwo ani szybkości ich dostarczania, ani dostępności. Zapytanie DNS, uzgadnianie TCP, handshake TLS, pobieranie, każdy etap dodaje dziesiątki i setki milisekund. Według danych HTTP Archive za rok 2024 mediana strony na urządzeniach mobilnych ładuje 21 zewnętrznych skryptów, z czego trzy są blokujące.

Rozwiązaniem jest danie przeglądarce jasnej instrukcji: „pobierz skrypt w tle, a wykonaj później". Właśnie do tego służą atrybuty defer i async.

Defer i async: dwa wbudowane mechanizmy

Oba atrybuty umieszcza się w tagu <script> i zmieniają one zachowanie ładowania. W zasadniczo różny sposób.

Defer: odroczone wykonanie z gwarancją kolejności

Atrybut defer mówi przeglądarce: „pobieraj skrypt w tle, wykonaj po pełnym sparsowaniu HTML". Kolejność wykonania jest zachowana, skrypty działają dokładnie w tej sekwencji, w jakiej są podane w znacznikach.

1
<script src="https://example.com/analytics.js" defer></script>
2
<script src="https://example.com/chat-widget.js" defer></script>

Idealny wybór dla skryptów, które muszą być wykonane w określonej kolejności: biblioteka, potem jej wtyczka, potem inicjalizacja. defer gwarantuje, że DOM jest już gotowy w momencie wykonania. Zdarzenie DOMContentLoaded nastąpi po wszystkich skryptach defer.

Async: pełna niezależność

async ładuje skrypt równolegle z parsowaniem i wykonuje go natychmiast po załadowaniu, nie czekając na inne. Kolejność nie jest gwarantowana: który skrypt pierwszy załadował się z serwera, ten pierwszy się wykonuje.

1
<script src="https://example.com/independent-widget.js" async></script>

Nadaje się do całkowicie niezależnych skryptów: liczników odwiedzin, przycisków mediów społecznościowych, banerów reklamowych. Jeśli skrypt nie zależy od DOM i nie zależy od innych skryptów, proszę stosować async.

Ważny niuans: skrypt async może wykonać się przed zbudowaniem DOM. Jeśli odwołuje się do elementów strony, których jeszcze nie ma, otrzymają Państwo null i błąd w konsoli. Zawsze należy to sprawdzać.

Programowe ładowanie na zdarzenie load: metoda Patricka Sextona

Co zrobić, jeśli skrypt nie obsługuje defer/async lub nie kontrolują Państwo znaczników? Na przykład skrypt jest wstawiany przez Google Tag Manager lub na sztywno zaszyty w cudzej wtyczce. Z pomocą przychodzi metoda programowa.

Pomysł jest prosty: tworzymy element <script> przez JavaScript i dodajemy go do DOM dopiero po pełnym załadowaniu strony. Autor podejścia, Patrick Sexton, po raz pierwszy opisał tę technikę na varvy.com.

Nowoczesna wersja tego kodu:

1
function loadScriptOnPageLoad(src) {
2
  const script = document.createElement('script');
3
  script.src = src;
4
  script.async = false;
5
  document.body.appendChild(script);
6
}
7
 
8
window.addEventListener('load', () => {
9
  loadScriptOnPageLoad('/wp-content/plugins/chat/chat.js');
10
  loadScriptOnPageLoad('/wp-content/plugins/analytics/tracker.js');
11
});

Dwie kluczowe różnice w stosunku do kodu sprzed dziesięciu lat. Po pierwsze: nasłuchujemy load, a nie DOMContentLoaded. Zdarzenie load następuje później, gdy załadowane są wszystkie obrazy, style i czcionki. Odroczony skrypt na pewno nie wpłynie ani na FCP, ani na LCP. Po drugie: żadnego window.attachEvent. Ta metoda była potrzebna tylko dla Internet Explorer 8 i starszych, które już nie istnieją. Współczesny addEventListener działa we wszystkich aktualnych przeglądarkach.

Trzy sytuacje, w których podejście programowe jest niezastąpione

defer i async działają tylko dla tagów <script> umieszczonych bezpośrednio w HTML. Metoda programowa ratuje, gdy:

• Skrypt wstawiany jest przez Google Tag Manager lub inny menedżer tagów, nie widzą Państwo znaczników.
• Nie można edytować szablonu: obcy wtyczka lub motyw o sztywnej strukturze.
• Potrzebne jest ładowanie warunkowe: na przykład skrypt formularza kontaktowego, tylko na stronach z formularzem.

Intersection Observer: ładowanie na żądanie

Dla niektórych skryptów nawet defer jest zbyt wczesny. Widżet czatu nie jest potrzebny, dopóki użytkownik nie przewinie strony do stopki. Mapa, dopóki nie dotrze do bloku z adresem. Komentarze, dopóki nie doczyta do sekcji dyskusji.

Intersection Observer API rozwiązuje właśnie to zadanie: skrypt ładuje się dopiero wtedy, gdy docelowy element pojawi się w obszarze widocznym.

1
const chatTarget = document.getElementById('chat-container');
2
 
3
if (chatTarget) {
4
  const observer = new IntersectionObserver((entries) => {
5
    entries.forEach((entry) => {
6
      if (entry.isIntersecting) {
7
        const script = document.createElement('script');
8
        script.src = '/wp-content/plugins/chat/chat.js';
9
        document.body.appendChild(script);
10
        observer.unobserve(entry.target);
11
      }
12
    });
13
  }, { rootMargin: '200px' });
14
 
15
  observer.observe(chatTarget);
16
}

Parametr rootMargin: '200px' ładuje skrypt na 200 pikseli przed pojawieniem się elementu na ekranie, użytkownik nie zauważa opóźnienia. Dawniej programiści latami używali nasłuchiwaczy scroll z getBoundingClientRect(), ale te szarpały się przy każdym pikselu przewijania i przeciążały główny wątek.

Intersection Observer działa asynchronicznie i praktycznie nie obciąża przeglądarki. Wsparcie: wszystkie nowoczesne przeglądarki, włącznie z Safari od wersji 12.1. IE11 nie jest wspierany, ale jego udział w czerwcu 2026 zmierza do błędu statystycznego.

WordPress: odroczone ładowanie bez edycji kodu

Jeśli strona działa na WordPressie, odroczone ładowanie można wdrożyć na trzy sposoby, od najprostszego do najbardziej elastycznego.

Wtyczki do odroczonego ładowania skryptów

Dwa sprawdzone rozwiązania, przetestowane na tysiącach stron.

Flying Scripts, bezpłatna wtyczka autorstwa Gijo Varghese, 30 000+ aktywnych instalacji, wersja 1.2.4 (aktualizowana w maju 2026). Potrafi odraczać JavaScript do pierwszej interakcji użytkownika: ruchu myszą, kliknięcia, przewijania, dotknięcia na urządzeniu mobilnym. Wskazuje Pan słowa kluczowe z URL-a skryptu, a wtyczka opóźnia jego wykonanie. Jest timeout: jeśli użytkownik nie wejdzie w interakcję ze stroną, skrypty wykonają się po zadanym czasie. Maksymalny zysk w metrykach, ale czat lub formularz oddzwaniania muszą być wykluczone z opóźnienia, są potrzebne od razu.

WP Rocket, premiumowa wtyczka do cache’owania, w którą wbudowano funkcję odroczonego ładowania JavaScriptu. Dodaje defer lub async do wybranych skryptów przez interfejs panelu administracyjnego. Wskazuje Pan URL, wtyczka zmienia atrybut podczas generowania strony. Odpowiednia dla tych, którzy już używają WP Rocket do cache’owania i nie chcą mnożyć wtyczek.

Hook script_loader_tag w functions.php

Jeśli nie chce Pan instalować osobnej wtyczki, WordPress pozwala filtrować wyjście tagów <script> przez hook script_loader_tag. Poniższy kod dodaje defer wszystkim skryptom oprócz jQuery i panelu administracyjnego:

1
add_filter('script_loader_tag', function($tag, $handle) {
2
    if (is_admin()) {
3
        return $tag;
4
    }
5
    $skip = ['jquery', 'jquery-core', 'jquery-migrate'];
6
    if (in_array($handle, $skip, true)) {
7
        return $tag;
8
    }
9
    return str_replace(' src', ' defer src', $tag);
10
}, 10, 2);

Proszę umieścić kod w functions.php motywu potomnego lub przez wtyczkę Code Snippets. Przed zastosowaniem, kopia zapasowa. defer na jQuery zepsuje każdy kod, który wywołuje $() lub jQuery() przed DOMContentLoaded. Proszę zaczynać od pojedynczych skryptów, sprawdzać konsolę pod kątem błędów po każdej zmianie.

Pełna kontrola: Asset CleanUp

Asset CleanUp, bezpłatna wtyczka (wersja 1.4.0.4, aktualizowana w maju 2026), która pokazuje WSZYSTKIE skrypty i style załadowane na stronie. Z podaniem rozmiaru i źródła. Można wyłączyć konkretny skrypt na konkretnej stronie, zmienić atrybut ładowania na defer/async lub całkowicie wyładować niepotrzebny zasób.

Główna przewaga nad Flying Scripts: Asset CleanUp daje pełny obraz dla każdej strony. Widzi Pan, co dokładnie się ładuje, i podejmuje decyzje punktowo. Wersja Pro dodaje ładowanie warunkowe według typu ekranu oraz przenoszenie skryptów między HEAD a BODY. Działa w parze z każdą wtyczką cache’ującą, WP Rocket, W3 Total Cache, WP Fastest Cache.

Głębsza analiza przyspieszania WordPressa w osobnym materiale: 21 wskazówek, jak poprawić wyniki PageSpeed Insights. Jeśli problem nie leży tylko w skryptach, ale i w ogólnej szybkości hostingu, proszę zajrzeć do sposobów na skrócenie czasu ładowania strony WordPress. A zmierzyć realny efekt optymalizacji pomogą narzędzia do sprawdzania wydajności WordPressa.

Wideo: async i defer w praktyce

Pięciominutowa analiza od kanału xplodivity, z wizualnymi schematami ładowania i żywymi przykładami kodu:

⁉️🤔 Często zadawane pytania

defer** czy async, co wybrać dla Google Analytics?**

async. Analytics.js i gtag.js są całkowicie niezależne od DOM, nie potrzebują określonej kolejności wykonywania. GA4 oficjalnie zaleca async, biblioteka sama obsługuje opóźnioną inicjalizację.

Czym różni się zdarzenie load od DOMContentLoaded?

DOMContentLoaded uruchamia się, gdy HTML jest w pełni sparsowany i zbudowane jest drzewo DOM, style i obrazy mogą się jeszcze ładować. load następuje później: gdy załadowane jest absolutnie wszystko, w tym obrazy, czcionki i arkusze stylów. Dla opóźnionego ładowania skryptów load jest bezpieczniejszy: strona w tym momencie jest już na pewno wyświetlona użytkownikowi.

Czy można dodać defer do skryptu inline?

Nie. Atrybut defer działa tylko dla zewnętrznych skryptów z atrybutem src. Skrypt inline (<script>код</script>) z defer zostanie zignorowany, przeglądarka wykona go jako zwykły skrypt blokujący. Aby opóźnić kod inline, proszę opakować go w nasłuchiwacz DOMContentLoaded lub load.

Czy bezpiecznie jest ustawiać defer na wszystkich skryptach witryny WordPress?

jQuery z defer zepsuje każdy kod, który wywołuje $() lub jQuery() przed DOMContentLoaded. Właśnie dlatego w powyższym fragmencie jQuery jest wykluczone z przetwarzania. Proszę zaczynać od niekrytycznych skryptów: czat, media społecznościowe, reklamy. Proszę rozszerzać listę stopniowo, sprawdzając konsolę pod kątem błędów po każdej zmianie.

Intersection Observer czy defer, co jest lepsze?

Rozwiązują one różne zadania. defer dla skryptów, które są zawsze potrzebne na stronie, ale nie są krytyczne dla pierwszego renderowania: analityka, testy A/B. Intersection Observer dla skryptów powiązanych z konkretnym blokiem: mapa, czat w stopce, widget komentarzy. Prosta zasada: skrypt w górnej części strony, defer; skrypt poniżej linii zagięcia, Intersection Observer.

Co zrobić, jeśli Flying Scripts zepsuł funkcjonalność?

Proszę wykluczyć problematyczny skrypt z listy opóźnień w ustawieniach wtyczki. Flying Scripts pozwala wskazać słowa kluczowe do uwzględnienia, proszę usunąć słowo kluczowe problematycznego skryptu, a będzie on ładowany jak zwykle. Dla krytycznych elementów, takich jak formularze i czaty, jest to obowiązkowy krok przed aktywacją opóźnienia.

Co wdrożyć na Pana/Pani stronie: macierz wyboru

Wybór sprowadza się do prostej tabeli decyzyjnej:

• Skrypt jest umieszczony w HTML, ma Pan/Pani kontrolę nad tagami, defer, jeśli zależy od kolejności, async, jeśli jest całkowicie niezależny.
• Skrypt jest wstawiany przez GTM lub zewnętrzną wtyczkę, tagi są niedostępne, programowe ładowanie po zdarzeniu load.
• Skrypt jest powiązany z blokiem poniżej linii zagięcia, Intersection Observer z rootMargin: '200px'.
• WordPress, potrzebne rozwiązanie bez kodu, Flying Scripts (bezpłatny, 30 000+ witryn) lub Asset CleanUp dla pełnej kontroli nad zasobami.

Proszę zacząć od najprostszego: proszę otworzyć PageSpeed Insights, znaleźć blokujące zewnętrzne skrypty i dodać im defer. Jeden atrybut i FCP może przejść z czerwonego na zielony. A kiedy opanuje Pan/Pani atrybuty, proszę zajrzeć do naszego przeglądu narzędzi do sprawdzania wydajności WordPressa, pomoże on zmierzyć rzeczywisty efekt.