Otwierasz swoją stronę i zamiast grafiki widzisz białe prostokąty. Albo PageSpeed Insights pokazuje czerwone LCP 4.8s, mimo że zainstalowałeś wtyczkę do optymalizacji. Znajomy problem? Lazy loading w WordPress brzmi jak magia – załaduj tylko to, co widać – ale w praktyce bywa źródłem nerwów. Źle skonfigurowany potrafi zepsuć Core Web Vitals bardziej, niż ich brak. W tym poradniku pokażę konkretne diagnozy i fixy. Bez lania wody, z przykładami kodu i listą wtyczek, które faktycznie działają w 2026 roku.
Krótka odpowiedź
Lazy loading w WordPress działa natywnie od wersji 5.5 przez atrybut loading="lazy" na tagach . Najczęstsze problemy to: obrazy above-the-fold oznaczone jako lazy (psują LCP), brak atrybutów width/height (powodują CLS) oraz konflikt wtyczek z CDN.
Rozwiązanie: wyłącz lazy dla pierwszego obrazu (fetchpriority="high"), ustaw wymiary, wybierz jedną wtyczkę (np. WP Rocket lub LiteSpeed Cache) i monitoruj Core Web Vitals w Google Search Console.
Usługi KC Mobile
Sprawdź naszą ofertę
Potrzebujesz pomocy specjalisty? Skorzystaj z naszych usług i rozwiń swój biznes online.
Lazy loading w WordPress 2026 – native vs plugin
Od wersji 5.5 (sierpień 2020) WordPress dodaje atrybut `loading="lazy"` automatycznie do wszystkich obrazów wstawianych przez edytor. Nie potrzebujesz już JavaScriptu ani wtyczki do podstawowego lazy loadingu – przeglądarka robi to sama. Wszystkie nowoczesne silniki (Chromium, Firefox, Safari od iOS 15.4) to wspierają. Statystyki z CanIUse pokazują pokrycie ~97% w 2026 roku.
Kiedy więc sięgać po wtyczki? Tylko w trzech przypadkach:
- Gdy chcesz lazy loading dla obrazów tła CSS (`background-image`) – native tego nie robi
- Gdy potrzebujesz placeholderów typu LQIP (Low Quality Image Placeholder) lub blur-up effect
- Gdy używasz starszego theme'u, który nie wspiera natywnych atrybutów
Porównanie podejść:
| Metoda | Zalety | Wady |
|---|---|---|
| Native `loading="lazy"` | Brak JS, 0 KB overhead, wspierany wszędzie | Brak placeholderów, tylko ` |
| Wtyczka (WP Rocket, LiteSpeed) | Obrazy tła, placeholdery, iframe facade | 10-40 KB JS, konflikty z CDN |
| Własny Intersection Observer | Pełna kontrola | Dużo pracy, ryzyko błędów |
W większości przypadków native wystarczy. Jeśli serwer masz u CyberFolks, LiteSpeed Cache ma lazy loading w cenie hostingu – i działa wyjątkowo dobrze, bo integruje się z LiteSpeed Web Server na poziomie serwera, nie PHP. Zanim zaczniesz kombinować, sprawdź też problemy z cache w WordPress, bo bywa że lazy źle działa właśnie przez agresywne cachowanie HTML.
Obrazy nie ładują się wcale – diagnostyka krok po kroku
Biała strona tam, gdzie powinien być obraz – klasyka. Zanim zaczniesz odinstalowywać wtyczki, zrób szybką diagnozę w Chrome DevTools. Otwórz zakładkę Network, odfiltruj po `Img`, przeładuj stronę i patrz co wraca.
5 najczęstszych przyczyn:
1. Błąd JavaScript blokuje Intersection Observer – jakiś inny skrypt rzuca wyjątek i zatrzymuje inicjalizację lazy loadera. Sprawdź konsolę (F12 → Console). Czerwone komunikaty? Masz sprawcę.
2. Wtyczka lazy load + native lazy load jednocześnie – podwójne lazy. Wtyczka czeka aż obraz wejdzie w viewport, a obraz ma `loading="lazy"`, więc przeglądarka i tak go nie pobiera. Deadlock.
3. CDN nie obsługuje `data-src` – niektóre konfiguracje Cloudflare Image Resizing lub Bunny CDN nie podmieniają atrybutu `data-src` na `src`. Obraz nigdy się nie ładuje.
4. Broken Intersection Observer polyfill – stare wtyczki ładują polyfill dla IE11, który ma bug w iOS Safari 17+.
5. Ad blocker blokuje skrypt lazy.js – uBlock Origin zna wiele ścieżek popularnych wtyczek i potrafi je ubić.
Szybki test: wyłącz tymczasowo wszystkie wtyczki optymalizacyjne (WP Rocket, Autoptimize, LiteSpeed) i zobacz czy obrazy wracają. Jeśli tak, włączaj po jednej i szukaj winowajcy.
W panelu WordPressa przejdź do *Narzędzia → Zdrowie witryny*. Jeśli widzisz błędy JS, masz trop. Więcej o diagnozowaniu całościowych problemów z prędkością znajdziesz w artykule WordPress wolno się ładuje – co robić.
Potrzebujesz profesjonalnej strony WordPress?
Tworzymy strony WordPress, które są szybkie, bezpieczne i zoptymalizowane pod SEO. Od 3000 zł.
Obrazy ładują się za wolno przy scrollu
Scrollujesz w dół i widzisz białe pole przez pół sekundy, dopiero potem pojawia się obraz. Irytujące. Technicznie to niedoskonałość domyślnej implementacji – przeglądarka zaczyna pobierać obraz dopiero gdy znajdzie się on praktycznie na ekranie. Nie ma buforu.
Co możesz zrobić:
- Zwiększ threshold – w większości wtyczek (WP Rocket, LiteSpeed) możesz ustawić, ile pikseli przed wejściem w viewport obraz zacznie się ładować. Domyślnie ~200px, zwiększ do 500-800px.
- Dodaj placeholdery LQIP – mały, rozmyty obraz (2-4 KB) w miejscu docelowego. Użytkownik widzi coś od razu, nie czeka na białym tle.
- Użyj `decoding="async"` – pozwala przeglądarce dekodować obraz w tle, zamiast blokować główny wątek.
- Włącz prefetch DNS dla CDN-u obrazów – `` w ``.
Przykład HTML, który działa dobrze:
<img src="zdjecie.webp"
width="1200" height="800"
loading="lazy"
decoding="async"
alt="Opis obrazka">Jeśli masz dużo obrazów w galerii (np. produkty w sklepie), rozważ paginację zamiast infinite scrollingu – z lazy loading też, ale bez szalonego DOM-a. Przy okazji zajrzyj do poradnika problemy z wydajnością WooCommerce, który omawia podobne wyzwania w kontekście sklepów.
LCP wysoki – największy obraz nie może być lazy
To jest grzech numer jeden, który widzę regularnie na audytach. Pierwszy, duży obraz na stronie – hero banner, zdjęcie produktu na górze, główna grafika artykułu – MA być pobierany natychmiast. Nie lazy. Nigdy lazy.
Dlaczego? Bo LCP (Largest Contentful Paint) mierzy kiedy największy widoczny element zostanie wyrenderowany. Jeśli oznaczysz go `loading="lazy"`, przeglądarka czeka na Intersection Observer, zamiast od razu pobrać. Dodajesz 300-800 ms opóźnienia. Czerwone LCP murowane.
Cel Core Web Vitals 2026:
| Metryka | Dobry | Wymaga poprawy | Słaby |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5-4.0s | > 4.0s |
| CLS | ≤ 0.1 | 0.1-0.25 | > 0.25 |
| INP | ≤ 200ms | 200-500ms | > 500ms |
| FCP | ≤ 1.8s | 1.8-3.0s | > 3.0s |
| TTFB | ≤ 0.8s | 0.8-1.8s | > 1.8s |
Jak to naprawić:
- Dodaj `fetchpriority="high"` do hero image – mówi przeglądarce "to najważniejsze, pobierz pierwsze"
- Usuń `loading="lazy"` z pierwszego obrazu
- Dodaj preload w ``: ``
- W WP Rocket włącz opcję "Exclude first X images from lazy load" (zazwyczaj 1-2)
Wtyczki jak WP Rocket od wersji 3.13 wykrywają to automatycznie, ale warto zweryfikować. Otwórz PageSpeed Insights i sprawdź sekcję "LCP element" – tam zobaczysz co jest LCP-em i czy ma odpowiednie atrybuty. Więcej o optymalizacji Core Web Vitals znajdziesz w artykule pozycjonowanie SEO a szybkość strony.
CLS – layout shift przez obrazy bez wymiarów
Drugi grzech: obrazy bez `width` i `height`. Efekt? Strona "skacze" gdy obrazy się ładują. Użytkownik klika przycisk, a ten mu ucieka bo wyżej właśnie załadował się banner. Google nienawidzi CLS – i użytkownicy też.
Rozwiązanie jest proste, ale wymaga dyscypliny. Każdy `` musi mieć atrybuty `width` i `height` – najlepiej w pikselach, pasujące do rzeczywistego aspect ratio. WordPress od wersji 5.5 dodaje je automatycznie przy wstawianiu z Media Library, ale importowane obrazy, stare wpisy albo ręcznie kodowane szablony często ich nie mają.
Szybki audyt:
- Zainstaluj wtyczkę Image Dimensions (darmowa) – skanuje wpisy i dodaje brakujące atrybuty
- Alternatywa dla deweloperów: funkcja `wp_get_attachment_image()` zamiast ręcznego HTML
- CSS fix dla starych wpisów: `img { aspect-ratio: attr(width) / attr(height); height: auto; }`
Placeholder skeleton screens też pomagają. Wtyczki takie jak Flying Images generują rozmyty placeholder o dokładnych wymiarach – strona się nie rusza nawet gdy obraz jeszcze nie doszedł.
Jeśli walczysz z CLS w konkretnym theme'ie, otwórz plik `single.php` lub `page.php` i sprawdź czy `the_post_thumbnail()` ma rozmiar sprecyzowany. Domyślnie WordPress zna wymiary z Media Library, ale niektóre page buildery (Elementor, Divi) potrafią je zgubić. Polecam też rzucić okiem na czy warto używać page builders w WordPress.
WebP i AVIF – nowoczesne formaty a lazy loading
WebP to dziś standard – waży 25-35% mniej niż JPEG przy tej samej jakości wizualnej. AVIF jest jeszcze lepszy (40-50% oszczędności), ale obsługa w narzędziach to nadal trochę ruletka. W 2026 roku oba formaty mają pokrycie >96% w przeglądarkach globalnych.
Porównanie konwerterów (stan na 2026):
| Wtyczka | Cena | Konwersja WebP | Konwersja AVIF | Lazy loading | CDN |
|---|---|---|---|---|---|
| Imagify | Free 20 MB/mies, $4.99/mies | Tak | Tak | Nie | Tak |
| ShortPixel | Free 100 img/mies, $9.99/mies | Tak | Tak | Nie | Tak |
| Smush | Free unlimited, $7/mies | Tak (Pro) | Nie | Tak | Tak (Pro) |
| Converter for Media | Free | Tak | Tak | Nie | Nie |
| LiteSpeed Cache | Free (z hostingiem) | Tak | Tak | Tak | QUIC.cloud |
Moja rekomendacja dla większości małych i średnich stron: LiteSpeed Cache + hosting CyberFolks. Dostajesz konwersję WebP, AVIF, lazy loading i CDN QUIC.cloud w cenie hostingu. Zero dodatkowych kosztów.
Dla większych projektów (>10000 obrazów) warto zainwestować w ShortPixel Pro – ma lepszą kompresję lossy, zachowuje metadane EXIF jeśli potrzebujesz i integruje się z każdym CDN-em.
Na co uważać przy konwersji:
- Backup oryginałów – niektóre wtyczki nadpisują pliki
- Jakość kompresji 80-85% (Imagify "Aggressive", ShortPixel "Glossy")
- PNG z przezroczystością → WebP lossless, nie JPEG
- Nie konwertuj logo i ikon, zwłaszcza SVG
Więcej o wyborze: najlepsze wtyczki do konwersji WebP w WordPress.
CDN a lazy loading – konflikty i fix
CDN przyspiesza stronę – to wiemy. Ale gdy do tego dodasz wtyczkę lazy loading, czasami pojawiają się dziwne efekty. Obrazy mrugają, nie ładują się albo ładują dwa razy.
Najczęstsze konflikty:
- Cloudflare Rocket Loader – opóźnia wykonanie wszystkich skryptów JS, łącznie z Intersection Observer. Obrazy pojawiają się z 1-2 sekundowym opóźnieniem. Fix: wyłącz Rocket Loader. W Cloudflare Dashboard → Speed → Optimization → Rocket Loader → OFF.
- Cloudflare Polish + local WebP conversion – Polish konwertuje w locie JPG/PNG do WebP, ale lokalna wtyczka już to zrobiła. Serwer wysyła WebP, Polish próbuje konwertować WebP do WebP i zwraca błąd 502. Fix: wybierz jedno.
- Bunny CDN + relative URLs – BunnyCDN potrzebuje absolutnych URL-i. Jeśli wtyczka lazy loading używa `data-src="/wp-content/..."` zamiast pełnego URL-a, obraz nie załaduje się z CDN-a.
- Cloudflare Mirage – ma własny lazy loading. Z wtyczką WP = dwa lazy loadingi = chaos. Wyłącz Mirage jeśli używasz dedykowanej wtyczki.
Rekomendacja stacka 2026:
1. Hosting z LiteSpeed Web Server (np. CyberFolks)
2. LiteSpeed Cache + QUIC.cloud CDN
3. Cloudflare jako proxy DNS (Polish OFF, Rocket Loader OFF)
4. Native lazy loading z `loading="lazy"` + `fetchpriority="high"` na hero
To prosty, działający setup dla 90% stron. Jeśli chcesz wiedzieć więcej o konfiguracji Cloudflare, zajrzyj do jak zainstalować Cloudflare w WordPress. A jeśli zastanawiasz się nad wyborem samego hostingu, mamy rozdzieloną analizę w problemy z hostingiem WordPress.
Smush vs Imagify vs ShortPixel – co wybrać w 2026
Trzy najpopularniejsze wtyczki do optymalizacji obrazów. Każda ma swoich zwolenników, każda ma też swoje bolączki. Testowałem wszystkie trzy na produkcji przez ostatnie dwa lata i widzę konkretne różnice.
Smush (WPMU DEV)
- Plusy: darmowa wersja obsługuje nieograniczoną liczbę obrazów (do 5 MB każdy), dobry lazy loading w wersji free, integracja z multisite
- Minusy: brak AVIF w wersji darmowej, kompresja lossy tylko w Pro ($7/mies), duża liczba zapytań do zewnętrznego API
- Dla kogo: blogi i małe firmowe strony, gdzie liczba obrazów jest spora, ale wymagania są standardowe
Imagify (WP Rocket team)
- Plusy: świetna kompresja (Aggressive level), WebP + AVIF w jednym planie, integracja z WP Rocket, backup oryginałów
- Minusy: darmowa wersja to tylko 20 MB/miesiąc (ok. 200 zdjęć), brak natywnego lazy loadingu – potrzebujesz osobnej wtyczki
- Dla kogo: sklepy WooCommerce i strony mocno wizualne, gdzie już płacisz za WP Rocket
ShortPixel
- Plusy: najlepsza kompresja lossy w testach, WebP + AVIF + Glossy mode, zachowanie EXIF, API do zewnętrznych systemów
- Minusy: darmowa wersja to 100 obrazów/miesiąc, interfejs mniej intuicyjny niż Imagify
- Dla kogo: fotografowie, portfolio, strony z tysiącami wysokiej jakości zdjęć
Dla większości klientów polecam LiteSpeed Cache – robi wszystko co powyższe (WebP, AVIF, lazy loading) gratis, pod warunkiem że masz hosting LiteSpeed jak CyberFolks. Oszczędzasz 200-400 PLN rocznie.
Przy migracji z jednej wtyczki na drugą pamiętaj – najpierw przywróć oryginały, potem odinstaluj starą, wtedy instaluj nową. Inaczej możesz stracić jakość obrazów na zawsze. Zobacz też problemy z wtyczkami WordPress pod kątem konfliktów.
Lazy loading iframes – YouTube, Google Maps i inne
YouTube embed wrzucony na stronę potrafi dodać 1.5 MB do transferu, zanim użytkownik w ogóle kliknie play. Google Maps iframe? 2 MB i 30+ zapytań sieciowych. Jeśli masz to na każdej podstronie, Core Web Vitals leżą i proszą o łaskę.
Rozwiązanie to facade pattern – zamiast prawdziwego iframe'a, pokazujesz statyczny obraz (placeholder) i dopiero po kliknięciu ładujesz właściwy embed.
Dla YouTube:
- Lite YouTube Embed (darmowa wtyczka lub własny kod) – placeholder z miniaturką, załaduje się dopiero po kliknięciu. Oszczędność 1.4 MB per embed.
- WP YouTube Lyte – dodaje tryb "lazy" do wszystkich embedów na stronie automatycznie
- W WP Rocket i LiteSpeed Cache jest opcja "Replace YouTube iframe with preview image" – działa out of the box
Dla Google Maps:
- Statyczny obraz z Google Static Maps API jako placeholder (bezpłatny do 28k zapytań/mies)
- Wtyczka WP Google Maps Lite z opcją lazy
- Custom rozwiązanie: kliknij → dopiero ładujesz iframe
Dla iframe ogólnie:
Native `loading="lazy"` działa też na iframe'ach od Chrome 77. Dodaj atrybut do HTML-a i przeglądarka zajmie się resztą. Dla starszych implementacji sprawdź też problemy z integracjami zewnętrznymi w WordPress.
Jeden tip: iframe'y Facebooka (Like Box, embed posta) też warto lazy-załadować. Skrypt FB SDK to kolejne 300 KB, których 90% użytkowników nie potrzebuje.
Audyt Core Web Vitals – Lighthouse, PageSpeed, Chrome UX
Nie da się optymalizować tego, czego nie mierzysz. Wszystkie poprawki, które tu opisałem, muszą być weryfikowane danymi. Inaczej strzelasz w ciemno.
Trzy narzędzia, z których korzystam codziennie:
1. PageSpeed Insights (pagespeed.web.dev) – najszybszy audyt, pokazuje field data (z Chrome UX Report) i lab data (z Lighthouse). Używaj field data do oceny, lab data do diagnozy.
2. Chrome DevTools → Lighthouse – pełny audyt lokalny, bez limitu requestów, symulacja mobile 4G
3. Google Search Console → Core Web Vitals – najważniejsze, bo to dane z prawdziwych użytkowników Google Chrome z ostatnich 28 dni. Jeśli tu jest czerwono, to Google widzi stronę jako wolną – i tak ocenia ją w rankingach.
Workflow audytu:
- Otwórz PageSpeed Insights, wklej URL, poczekaj
- Sprawdź sekcję "Core Web Vitals Assessment" – field data z CrUX
- Przejdź do "Diagnostics" – zobaczysz jakie obrazy są problemem
- Sprawdź "Avoid enormous network payloads" i "Properly size images"
- Otwórz zakładkę "Treemap" (link na dole) – widzisz co waży najwięcej
- Porównaj z danymi z GSC w zakładce Core Web Vitals → URL examples
Checklist po każdej zmianie:
- [ ] LCP < 2.5s (mobile field data)
- [ ] CLS < 0.1
- [ ] INP < 200ms
- [ ] Wszystkie obrazy mają width/height
- [ ] Hero image ma fetchpriority="high"
- [ ] Obrazy below fold mają loading="lazy"
- [ ] Format WebP lub AVIF
- [ ] Brak konfliktów w Chrome DevTools Console
Pamiętaj, że field data aktualizują się co 28 dni (rolling window). Nie zobaczysz efektu poprawki z dzisiaj jutro – poczekaj 2-3 tygodnie na solidne dane. Jeśli potrzebujesz szybszego feedbacku, używaj Web Vitals Chrome Extension (real-time pomiar lokalnie).
## Potrzebujesz pomocy?
Strona wolno się ładuje mimo optymalizacji? LCP zielone w Lighthouse, ale czerwone w Search Console? Napisz lub zadzwoń – robimy audyty Core Web Vitals regularnie.
Zadzwoń: +48 604 939 140
Formularz: /kontakt/
Usługa: Strony internetowe – kompleksowa optymalizacja
W 1-2 dni roboczych wskażemy konkretne problemy i przygotujemy wycenę naprawy. Bez ogólników, konkretne numery i priorytety.
Wspomniane narzędzia
Potrzebujesz pomocy z WordPress?
Tworzymy i naprawiamy strony na WordPress. Optymalizacja prędkości, bezpieczeństwo, aktualizacje. 500+ zrealizowanych projektów.
Najczęściej zadawane pytania
Jak działa lazy loading w WordPress 2026?
Dlaczego obrazy w moim WordPressie nie ładują się?
LCP wysoki – jak naprawić problem w WordPress?
Czy native lazy loading wystarczy bez pluginu?
WebP czy AVIF w WordPress – co wybrać w 2026?
Jak zoptymalizować obrazy bez utraty jakości?
CDN obrazów w WordPress – warto czy nie?
Jak zmierzyć Core Web Vitals mojej strony?
Potrzebujesz pomocy?
Potrzebujesz profesjonalnej strony WordPress?
Tworzymy strony WordPress, które są szybkie, bezpieczne i zoptymalizowane pod SEO. Od 3000 zł.