Każdego roku pod koniec listopada część stron firmowych MŚP zaczyna działać wolno albo nie odpowiada. Nie dlatego, że nagle zjawiło się dziesięć razy więcej odwiedzających — ale dlatego, że nikt przez cały rok nie sprawdził, co stanie się, gdy ruch wzrośnie. Październik to ostatni sensowny moment, żeby to naprawić zanim przyjdzie Black Friday.
Ten artykuł nie jest przeznaczony dla programistów ani specjalistów SEO. Jest dla właściciela firmy, który chce wiedzieć: czy moja strona jest gotowa na Q4 i co zrobić, jeśli nie jest?
Dlaczego wydajność strony robi różnicę właśnie teraz
W październiku ruch na stronach MŚP jest zwykle normalny. W listopadzie — szczególnie w okolicach Black Friday i Cyber Monday — może wzrosnąć dwu- lub trzykrotnie, jeśli firma prowadzi działania promocyjne, pojawia się w porównywarkach cenowych albo wysyła e-mail marketing.
Wolna strona nie tylko frustruje odwiedzających — bezpośrednio wpływa na sprzedaż. Wg badania Google i Deloitte z 2019 r. („Milliseconds Make Millions”) każde 0,1 sekundy poprawy czasu ładowania strony zwiększa konwersje w handlu detalicznym o 8%. To starsze badanie, ale kolejne analizy Chrome UX Report je potwierdzają: związek między szybkością a sprzedażą jest trwały.
Warto znać też aktualny stan branży. Firma BootLeads przeanalizowała dane Chrome UX Report (CrUX) z sierpnia 2026 dla ponad 1,5 miliona aktywnych sklepów internetowych. Tylko 62% z nich zalicza wszystkie trzy podstawowe metryki wydajności jednocześnie. W podziale na platformy obraz jest niejednolity: sklepy na WooCommerce (WordPress + WooCommerce) zdają ten test w 38,9% przypadków, sklepy na Shopify w 81,7% (wg BootLeads, analiza CrUX, sierpień 2026).
Jeśli Twoja strona stoi na WordPressie z WooCommerce, statystycznie bardziej prawdopodobne jest, że ma problem z wydajnością, niż że go nie ma. To nie wyrok — to punkt wyjścia do działania.
Jak sprawdzić stronę w 15 minut — bez agencji
Zanim zaangażujesz kogokolwiek zewnętrznego, zrób podstawowy przegląd sam. Potrzebujesz jednego narzędzia: PageSpeed Insights (bezpłatne, od Google) dostępnego pod adresem pagespeed.web.dev.
Krok 1: Wybierz właściwe adresy do testowania
Nie ograniczaj się do strony głównej. Przetestuj:
- stronę główną — witryna wizytówkowa,
- stronę produktu lub usługi — na nią kierujesz ruch z reklam,
- koszyk lub formularz kontaktowy — tu finalizuje się sprzedaż.
Strona główna może być szybka, a strona produktu wolna — i to ona decyduje o konwersji.
Krok 2: Zrozum różnicę między Field Data a Lab Data
W raporcie PageSpeed Insights zobaczysz dwa rodzaje danych. Nie mieszaj ich — mają inne znaczenie:
Dane terenowe (Field Data) to wyniki z prawdziwych odwiedzin prawdziwych użytkowników na Twojej stronie z ostatnich 28 dni. Zbiera je Chrome (przeglądarka Google) i agreguje jako Chrome UX Report (CrUX). To są dane, które Google bierze pod uwagę przy pozycjonowaniu. Jeśli Twoja strona ma niewystarczający ruch, to pole może być puste — i to też jest informacja.
Dane laboratoryjne (Lab Data) to symulowany test na wirtualnym urządzeniu mobilnym w kontrolowanych warunkach. Przydatny do diagnozowania konkretnych problemów technicznych, ale nie jest bezpośrednim sygnałem rankingowym. Wg ekspertów Search Engine Journal: „Jeśli konfliktują — ufaj Field Data przy priorytetach, a Lab Data używaj do diagnozy”.
Praktyczna zasada: jeśli oba wskaźniki są czerwone — problem jest poważny. Jeśli tylko Lab Data jest czerwony, a Field Data zielony — sytuacja jest lepsza, ale warto rozumieć przyczynę różnicy.
Krok 3: Odczytaj wynik liczbowy
PageSpeed Insights przydziela stronie wynik od 0 do 100 (to Lab Data — przydatne do porównań):
- 90–100 (zielony): dobry
- 50–89 (pomarańczowy): wymaga poprawy
- 0–49 (czerwony): słaby
Wynik poniżej 50 w październiku, przed Q4, to sygnał do natychmiastowego działania. Wynik 50–70 to coś, co warto poprawić przy okazji — szczególnie na urządzeniu mobilnym.
Krok 4: Co zrobić, jeśli Field Data jest puste
Jeśli Twoja strona ma małe odwiedziny (mniej niż kilkaset miesięcznie z Chrome), pole Field Data może być puste — Google nie ma wystarczającej próbki. To nie oznacza, że strona jest szybka. W tej sytuacji polegaj wyłącznie na Lab Data jako orientacji i testuj stronę na prawdziwym telefonie z siecią komórkową (nie WiFi) — to realniejszy obraz niż symulacja.
Co mierzą Core Web Vitals — trzy liczby, które warto zapamiętać
Core Web Vitals to trzy metryki, które Google uznaje za podstawowe wskaźniki doświadczenia użytkownika. Są mierzone na 75. percentylu wizyt — co oznacza: 3 na 4 odwiedzających ma wynik lepszy lub równy podanemu progowi. Brzmi skomplikowanie, ale w praktyce chodzi o pytanie: jak wolno ładuje się strona dla tych, dla których ładuje się najgorzej?
LCP — czas ładowania głównej treści
Analogia: to moment, w którym właściciel sklepu otwiera drzwi i klient w końcu widzi całe wnętrze — nie tylko wizytówkę na drzwiach.
LCP (Largest Contentful Paint) mierzy czas, w jakim pojawia się największy widoczny element na stronie — zwykle główne zdjęcie lub nagłówek.
| Wynik | Próg | Ocena |
|---|---|---|
| Dobry | ≤ 2,5 s | Zielony |
| Wymaga poprawy | 2,5–4,0 s | Pomarańczowy |
| Słaby | > 4,0 s | Czerwony |
Źródło: web.dev/articles/vitals (Google), progi aktualne dla 2026.
Dla sklepów z produktami — wolny LCP bezpośrednio oznacza, że klient czeka na załadowanie zdjęcia produktu. W Black Friday, gdy porównuje kilka sklepów jednocześnie, po prostu nie czeka.
INP — czas reakcji na kliknięcia
Analogia: to czas między naciśnięciem przycisku „dodaj do koszyka” a widoczną reakcją strony. Kelner reagujący w 2 sekundy jest w porządku. Kelner po 15 sekundach — to jest problem.
INP (Interaction to Next Paint) mierzy, jak szybko strona odpowiada na kliknięcia, tapnięcia i wpisywanie tekstu.
| Wynik | Próg | Ocena |
|---|---|---|
| Dobry | ≤ 200 ms | Zielony |
| Wymaga poprawy | 200–500 ms | Pomarańczowy |
| Słaby | > 500 ms | Czerwony |
Źródło: web.dev/articles/vitals (Google).
INP zastąpił FID (First Input Delay) jako metrykę interaktywności w 2024 r. Jest bardziej wymagający — mierzy czas reakcji przez całą wizytę, nie tylko pierwsze kliknięcie. Dla stron e-commerce w Q4 ma to szczególne znaczenie: wolna odpowiedź na kliknięcie „dodaj do koszyka” w środku procesu zakupowego to jeden z najczęstszych powodów porzucania koszyka.
CLS — stabilność wizualna
Analogia: to miara tego, jak bardzo elementy strony „skaczą” podczas ładowania. Przycisk przenoszący się tuż gdy chcesz go kliknąć — klasyczny CLS.
| Wynik | Próg | Ocena |
|---|---|---|
| Dobry | ≤ 0,1 | Zielony |
| Wymaga poprawy | 0,1–0,25 | Pomarańczowy |
| Słaby | > 0,25 | Czerwony |
Źródło: web.dev/articles/vitals (Google).
Wysoki CLS to nie tylko kwestia estetyki — badania wskazują na bezpośredni wpływ na porzucanie formularzy i koszyków zakupowych. Typową przyczyną jest banner reklamowy, który ładuje się z opóźnieniem i „popycha” treść w dół.
Najczęstsze przyczyny słabego LCP — i co z tym zrobić
LCP to metryka, nad którą właściciel strony MŚP ma największą bezpośrednią kontrolę. Wg oficjalnej dokumentacji Google (web.dev/articles/optimize-lcp) problemy LCP koncentrują się w czterech obszarach:
1. Za duże zdjęcia bez nowoczesnych formatów
Problem: strona używa zdjęć w JPG z aparatu (2–5 MB) lub PNG zamiast formatów WebP albo AVIF. Przeglądarka pobiera kilkanaście razy więcej danych, niż potrzebuje do wyświetlenia strony.
Rozwiązanie: przekonwertuj obrazy do formatu WebP. Większość nowoczesnych CMS-ów obsługuje to automatycznie (WordPress z wtyczką Imagify, Smush lub WP Rocket, Astro — wbudowany Image component). WebP jako minimum dla 2026; AVIF jest jeszcze efektywniejszy, ale dla stron MŚP WebP w zupełności wystarczy.
2. Lazy loading na głównym zdjęciu
Problem: programista albo właściciel strony dodał atrybut loading="lazy" do wszystkich obrazów „bo przyspiesza stronę”. Dla obrazów w dalszej części strony to poprawne. Dla pierwszego, głównego obrazu (hero image) — działa odwrotnie. Mówi przeglądarce: nie śpiesz się z tym obrazem.
Rozwiązanie: usuń loading="lazy" z pierwszego głównego obrazu na stronie. Google wprost wskazuje w dokumentacji: nigdy nie używaj lazy loadingu na elementach LCP.
Jak sprawdzić? Otwórz stronę, kliknij prawym na główne zdjęcie, wybierz „Zbadaj element” i poszukaj loading="lazy" w atrybutach tagu <img>.
3. Brak priorytetu na krytycznym obrazie
Problem: przeglądarka nie wie, które zasoby załadować najpierw i pobiera je równolegle — w tym obrazy w stopce, ikonki mediów społecznościowych, skrypty reklamowe. Główne zdjęcie stoi w kolejce razem ze wszystkimi.
Rozwiązanie: dodaj atrybut fetchpriority="high" do głównego obrazu (hero). To sygnał dla przeglądarki: zacznij od tego zasobu. W WordPress możesz to ustawić ręcznie lub przez wtyczki optymalizacyjne (WP Rocket, Perfmatters). Nowoczesne frameworki jak Astro ustawiają to automatycznie dla obrazów oznaczonych jako priorytetowe.
4. Wolny serwer (wysoki TTFB)
Problem: serwer odpowiada wolno — zanim przeglądarka zacznie pobierać zasoby, mija więcej niż 600–800 ms. Na tanim współdzielonym hostingu z WordPressem to norma, nie wyjątek. TTFB (Time to First Byte) powyżej 800 ms praktycznie uniemożliwia dobry LCP.
Rozwiązanie: CDN, buforowanie na poziomie serwera lub migracja na szybszy hosting. Więcej o wyborze hostingu dla MŚP — z konkretnymi porównaniami — pisaliśmy w artykule Hosting dla strony firmowej MŚP 2026.
Cloudflare jako tania ochrona przed skokiem ruchu
Cloudflare oferuje bezpłatną warstwę CDN i cache, która może drastycznie zmienić wydajność strony — bez migracji serwera i bez dotykania kodu. Wystarczy zmienić serwery DNS domeny na Cloudflare (zajmuje ~15 minut).
Co Cloudflare robi domyślnie
Po podłączeniu domeny Cloudflare automatycznie cache’uje statyczne zasoby na swoich serwerach brzegowych (edge servers) rozmieszczonych globalnie. Domyślnie w cache trafiają: obrazy (PNG, JPG, JPEG, GIF, WEBP, SVG), arkusze stylów CSS, skrypty JavaScript, dokumenty PDF, multimedia i archiwa (ZIP, RAR).
Ważna informacja: Cloudflare domyślnie nie cache’uje HTML — strony dynamiczne są zawsze pobierane z Twojego serwera. Wg oficjalnej dokumentacji Cloudflare (developers.cloudflare.com/cache) nie cache’uje też zasobów, gdy nagłówek Cache-Control ma wartość private, no-store lub no-cache, ani gdy odpowiedź zawiera ciasteczka sesyjne.
Dla stron statycznych (wizytówka firmowa, portfolio, landing page) warto przez Cache Rules włączyć cache’owanie HTML — w efekcie cała strona jest serwowana z edge Cloudflare i Twój serwer dostaje minimalny ruch.
Cache Rules w planie Free — 10 reguł wystarczy
Cloudflare daje 10 reguł cache w planie bezpłatnym (plan Pro: 25 reguł). To wystarczająca liczba dla typowej strony MŚP.
Przykład prostej reguły: „cache’uj wszystkie pliki kończące się na .css, .js, .png, .webp przez 7 dni”. Taka konfiguracja powoduje, że przy skoku ruchu w Black Friday — 80–90% zasobów Twojej strony pochodzi z cache Cloudflare, a nie z Twojego serwera. Serwer obsługuje tylko pierwsze zapytania, potem Cloudflare odpowiada zamiast niego.
Domyślne TTL dla zasobów z kodem HTTP 200/301: 120 minut, jeśli serwer nie wysyła nagłówka Cache-Control. Ustawienie własnej reguły TTL na tydzień lub miesiąc dla statycznych zasobów znacznie poprawia wydajność.
Efekt CDN dla TTFB
Odwiedzający z Gdańska odpytuje serwer Cloudflare w Warszawie lub Frankfurcie, a nie Twój serwer fizycznie ulokowany w Amsterdamie. Czas odpowiedzi spada z 200–400 ms do 20–50 ms. To bezpośrednio przekłada się na TTFB i LCP.
Lista kontrolna przed Q4 — co zrobić do końca października
Zakładając, że masz 2–3 godziny i nie jesteś programistą, oto priorytetyzowana lista działań:
1. Zmierz punkt wyjścia Uruchom PageSpeed Insights dla 3 adresów: strona główna, strona produktu/usługi, formularz lub koszyk. Zapisz wyniki — bez pomiaru bazowego nie wiesz, czy cokolwiek poprawia sytuację.
2. Podłącz Cloudflare, jeśli jeszcze tego nie zrobiłeś Bezpłatnie, ~15 minut. Zmiana serwerów DNS domeny i podstawowe cache. Przy WordPressie zainstaluj oficjalny plugin Cloudflare — automatycznie czyści cache przy zmianach treści.
3. Sprawdź rozmiary obrazów W narzędziach deweloperskich przeglądarki (F12 → zakładka Network → filtr Img) sprawdź, ile ważą obrazy na stronie. Każdy obrazek powyżej 300 KB to kandydat do optymalizacji. Jeśli masz JPG-i po 2–5 MB — to jest Twój numer jeden.
4. Usuń lazy loading z głównego obrazu Wyświetl kod źródłowy strony (Ctrl+U w przeglądarce). Znajdź tag <img pierwszego, dużego obrazu (hero). Jeśli widzisz loading="lazy" — usuń to albo przekaż programiście lub agencji.
5. Przetestuj stronę na telefonie PageSpeed Insights testuje domyślnie wersję mobilną. Sprawdź też wyniki na prawdziwym telefonie, nie emulatorze. W Q4 coraz większy odsetek zakupów i zapytań pochodzi ze smartfonów.
6. Sprawdź ważność certyfikatu SSL Upewnij się, że certyfikat SSL (kłódka przy adresie) jest ważny co najmniej przez kolejne 3 miesiące. Cloudflare oferuje bezpłatny certyfikat SSL automatycznie po podłączeniu. Wygaśnięcie certyfikatu w środku Black Friday to scenariusz, który się zdarzył — i jest w pełni do uniknięcia.
7. Wyślij testowe zapytanie przez formularz Zanim przyjdzie ruch, sprawdź, czy formularz kontaktowy lub zamówienie testowe dociera na Twój adres e-mail. W szczycie ruchu formularz to pierwsze miejsce, gdzie coś się psuje (przepełniona skrzynka, błąd konfiguracji, filtr spamu).
Jeśli po tych krokach strona działa szybko, ale ruch nie zamienia się w zapytania ani sprzedaż — artykuł o optymalizacji konwersji strony firmowej pokazuje kolejne kroki.
Podsumowanie
Wydajność strony to temat dla właściciela firmy, nie tylko dla programistów. Narzędzia są bezpłatne, a podstawowe problemy możesz zdiagnozować samodzielnie w kwadrans.
Trzy liczby do zapamiętania: LCP poniżej 2,5 sekundy, INP poniżej 200 ms, CLS poniżej 0,1. Wszystkie mierzysz jednym narzędziem — PageSpeed Insights.
Cloudflare w planie bezpłatnym robi za Ciebie większość pracy z cache — bez kosztów i bez migracji serwera. W Q4 to może być różnica między stroną, która „wytrzymuje” skok ruchu, a stroną, która pada akurat gdy jest potrzebna.
Wskazówka: zacznij od pomiaru, nie od narzędzi. Otwórz PageSpeed Insights dla strony swojego produktu lub usługi teraz. Wynik powie Ci, ile masz do zrobienia — i czy możesz to zrobić sam, czy potrzebujesz wsparcia. Jeśli chcesz przedyskutować wyniki — napisz do nas.