Kiedy dział marketingu mówi o Core Web Vitals, zwykle ma na myśli pozycje w Google. To prawda tylko w połowie. Dla sklepu mid-market szybkość strony jest przede wszystkim dźwignią konwersji, a dopiero potem sygnałem rankingowym. Klient nie widzi Twojego wyniku w Lighthouse. Widzi, że strona produktu ładuje się sekundę zamiast trzech, i częściej dochodzi do koszyka.
Ten tekst tłumaczy trzy metryki Core Web Vitals prostym językiem, a potem schodzi głębiej do jednej liczby, która rządzi resztą: TTFB. Pokażemy, co ją napędza, dlaczego celujemy poniżej 200 ms i co konkretnie zrobić na Shopify Plus, PrestaShop, WooCommerce i Syliusie. Na końcu znajdziesz checklistę do przejścia u siebie jeszcze dziś.
Core Web Vitals w jednym akapicie: LCP, INP, CLS
Core Web Vitals to trzy metryki, którymi Google opisuje realne doświadczenie użytkownika — mierzone nie w laboratorium, ale na prawdziwym ruchu z przeglądarek Twoich klientów. Warto je znać, bo to język, w którym rozmawia się o wydajności zarówno z zespołem technicznym, jak i z zarządem.
LCP — jak szybko widać najważniejszą treść
Largest Contentful Paint mierzy, po jakim czasie na ekranie pojawia się największy element treści: zwykle zdjęcie produktu albo nagłówek. To najbliższa metryka temu, co użytkownik nazwałby po prostu „strona się załadowała”. Cel: poniżej 2,5 sekundy. Powyżej 4 sekund klient zaczyna się zastanawiać, czy nie wrócić do wyników wyszukiwania.
INP — jak szybko strona reaguje na dotyk
Interaction to Next Paint mierzy opóźnienie między kliknięciem a widoczną reakcją strony — rozwinięciem menu, dodaniem do koszyka, otwarciem wariantu produktu. W 2024 roku zastąpił starszą metrykę FID i jest znacznie bardziej wymagający, bo obejmuje cały czas przetwarzania, a nie tylko pierwszą reakcję. Cel: poniżej 200 ms. Wysokie INP to najczęściej wina zbyt ciężkiego JavaScriptu — przeciążonego wątku głównego przeglądarki.
CLS — czy treść nie skacze pod palcem
Cumulative Layout Shift mierzy, jak bardzo układ strony przesuwa się podczas ładowania. Każdy zna ten moment: chcesz kliknąć „kup teraz”, a w ostatniej chwili doładowuje się baner i klikasz coś innego. Cel: poniżej 0,1. Winowajcy to zwykle obrazy bez zarezerwowanych wymiarów, reklamy i późno ładowane czcionki.
Te trzy metryki opisują to, co widać. Ale zanim przeglądarka w ogóle zacznie cokolwiek renderować, musi dostać pierwszy bajt odpowiedzi z serwera. I tu wchodzi liczba, której na oficjalnej liście Core Web Vitals nie ma, a która decyduje o tym, czy pozostałe w ogóle mają szansę wyjść dobrze.
TTFB: liczba spoza listy, która rządzi całą resztą
TTFB (Time to First Byte) to czas od momentu, w którym przeglądarka wysyła żądanie, do chwili, gdy wraca pierwszy bajt odpowiedzi serwera. Składa się z kilku etapów: wyszukania DNS, nawiązania połączenia TCP, uzgodnienia szyfrowania TLS, a następnie — i to zwykle największa, kontrolowalna część — czasu, w którym serwer aplikacyjny faktycznie zbuduje odpowiedź.
TTFB nie jest jedną z trzech oficjalnych metryk Core Web Vitals. Jest czymś ważniejszym: jest ich fundamentem. LCP nie może być szybsze niż TTFB, bo nie da się wyrenderować treści, zanim przyjdzie pierwszy bajt. Jeśli backend potrzebuje 900 ms na wygenerowanie HTML, LCP poniżej 2,5 sekundy jest wciąż osiągalne, ale walczysz o niego z ręką związaną z tyłu. Jeśli backend odpowiada w 150 ms, cała reszta optymalizacji frontendu ma z czego czerpać.
Każda milisekunda TTFB to milisekunda, której LCP już nigdy nie odzyska. Optymalizacja frontendu na wolnym backendzie to malowanie trawy na zielono.
Dlatego w audytach technicznych TTFB traktujemy jako pierwszy pomiar, a nie przypis. To on mówi, czy problem wydajnościowy leży po stronie serwera, czy przeglądarki — i gdzie w ogóle zacząć.
Dane z pola, nie z laptopa
Jedna pułapka psuje większość rozmów o TTFB: mierzenie go w złych warunkach. Wynik z Lighthouse na Twoim laptopie, po podłączeniu do firmowego światłowodu i z rozgrzanym cache, to dane laboratoryjne — przydatne do debugowania, ale bezużyteczne jako obraz rzeczywistości. Google ocenia stronę na podstawie danych z pola (field data), czyli realnych pomiarów z przeglądarek użytkowników, zbieranych w raporcie CrUX. To dwie różne liczby i regularnie się rozjeżdżają.
Praktyczny wniosek: mierz TTFB tam, gdzie są Twoi klienci, na sprzęcie i łączach, jakich realnie używają, i na pierwszym, niecache'owanym trafieniu. Pojedynczy pomiar to anegdota — potrzebujesz rozkładu, i zwykle patrzy się na 75. percentyl, bo to on decyduje o ocenie i o tym, ilu klientów faktycznie czeka. Stały monitoring realnych użytkowników (RUM) powie Ci to, czego jednorazowy test nigdy nie pokaże: że TTFB rośnie w godzinach szczytu, gdy baza jest pod obciążeniem — czyli dokładnie wtedy, gdy tracisz najwięcej koszyków.
Co naprawdę napędza TTFB
Gdy TTFB jest wysoki, przyczyna prawie zawsze mieści się w jednym z czterech obszarów. Warto je znać z nazwy, bo „strona jest wolna” to diagnoza bezużyteczna — a „backend renderuje stronę produktu w 700 ms, bo katalog robi 40 nieindeksowanych zapytań” już nie.
Czas backendu i zapytania do bazy
To najczęstszy winowajca w sklepach mid-market. Kod aplikacji buduje stronę: pobiera produkt, ceny, dostępność, rekomendacje, dane koszyka. Jeśli robi to nieefektywnie — klasyczny problem N+1, gdzie pętla po 30 produktach odpala 30 osobnych zapytań, brak indeksów, ciężkie zapytania na tabelach statystyk — czas backendu rośnie liniowo z katalogiem. W jednym z naszych projektów legacy zapytania do monolitycznej bazy potrafiły trwać po kilka sekund. Żaden CDN tego nie naprawi, bo problem jest w kodzie i schemacie bazy.
Cache — na każdym poziomie
Cache to najtańszy sposób na obniżenie TTFB, bo najszybsze zapytanie to takie, którego nie wykonujesz. Działa na kilku poziomach naraz: OPcache trzyma skompilowany bajtkod PHP, żeby nie kompilować kodu przy każdym żądaniu; object cache (Redis, Memcached) trzyma wyniki powtarzalnych zapytań do bazy; full-page cache (np. Varnish) serwuje gotowy HTML dla ruchu anonimowego, w ogóle nie dotykając aplikacji. Sklep bez object cache zwykle powtarza te same zapytania tysiące razy dziennie.
Hosting i wersja PHP
Współdzielony hosting za 30 zł miesięcznie i dedykowany serwer z poprawnie skonfigurowanym PHP-FPM to dwa różne światy TTFB. Liczba workerów PHP-FPM, dostępny CPU i I/O, a także sama wersja PHP mają bezpośrednie przełożenie. Przeskok z PHP 7.4 na 8.2 to często kilkadziesiąt milisekund odzyskane bez jednej linijki zmian w kodzie — nowsze wersje po prostu wykonują ten sam kod szybciej.
TLS, sieć i CDN
Uzgodnienie TLS i fizyczna odległość do serwera też kosztują. Klient z Krakowa łączący się z serwerem we Frankfurcie płaci podatek od każdego kilometra. CDN skraca ten dystans, serwując treść z węzła bliżej użytkownika, a nowoczesne protokoły (HTTP/2, HTTP/3, wznawianie sesji TLS) redukują narzut nawiązywania połączenia. Dla treści statycznej, a czasem i dla całego HTML, to darmowe kilkadziesiąt milisekund.
Dlaczego poniżej 200 ms to właściwy cel
Dlaczego akurat 200 ms? Bo to próg, przy którym backend przestaje być wąskim gardłem. Poniżej 200 ms serwer oddaje pierwszy bajt praktycznie od razu i zostawia całą resztę budżetu czasowego — te 2,5 sekundy na dobre LCP — na to, na co realnie wpływa frontend: obrazy, czcionki, JavaScript. To cel inżynierski, nie marketingowy: daje zespołowi zapas, zamiast zmuszać go do nadrabiania strat od pierwszej milisekundy.
Druga strona medalu jest twarda finansowo. W naszych projektach i danych branżowych TTFB powyżej 500 ms koreluje z 5–10% spadkiem konwersji. To nie jest liniowy spadek rankingu w Google — to klienci, którzy zamykają kartę, zanim strona odpowie. Dla sklepu robiącego kilkadziesiąt milionów złotych obrotu rocznie te kilka procent to kwota, przy której inwestycja w Redis i optymalizację zapytań zwraca się w tygodniach, nie w latach.
Uczciwie: nie każdy sklep powinien rzucać wszystko, żeby zejść z 250 do 180 ms. Jeśli Twoim realnym problemem jest wysokie INP przez przeciążony JavaScript albo słabe LCP przez nieskompresowane zdjęcia bohatera, to tam leżą Twoje pieniądze, a nie w backendzie. Dlatego kolejność jest zawsze ta sama: najpierw zmierz, gdzie faktycznie uciekają milisekundy, a dopiero potem inwestuj. Ale jeśli TTFB regularnie przekracza 500 ms, jest to prawie na pewno Twoje najtańsze i najszybciej zwracające się usprawnienie.
TTFB poniżej 200 ms to nie chwalenie się liczbą w raporcie. To budżet czasowy, który oddajesz z powrotem klientowi — i konwersji.
Bogart Meble: dowód, że to nie teoria
Konkret zamiast teorii. W migracji sklepu meblowego Bogart z 12-letniego legacy (PHP 5.4, custom framework, monolityczna baza) na Symfony 6.4 punktem wyjścia były zapytania do bazy trwające po kilka sekund. Czas ładowania strony produktu, mierzony jako LCP, wynosił kilka sekund.
Po przepisaniu logiki, dołożeniu Redis jako warstwy cache i sesji, wyniesieniu wyszukiwania produktów do Elasticsearcha i optymalizacji zapytań, LCP spadł do poniżej sekundy — kilkukrotnie szybciej. Nie było w tym magii ani jednej srebrnej kuli: był object cache tam, gdzie powtarzały się te same zapytania, poprawione zapytania z indeksami i odciążenie bazy od operacji, które nie muszą blokować renderowania strony. Efekt biznesowy po trzech miesiącach: wyraźny wzrost konwersji (w połączeniu z nowym checkoutem). Cały case opisaliśmy w naszych realizacjach.
Konkretne kroki, platforma po platformie
TTFB optymalizuje się inaczej na każdej platformie, bo na każdej co innego kontrolujesz. Poniżej mapa: gdzie zwykle jest wąskie gardło i od czego zacząć.
| Platforma | Typowe wąskie gardło TTFB | Pierwszy ruch o największym zwrocie |
|---|---|---|
| Shopify Plus | App bloat i ciężki Liquid; serwera nie kontrolujesz | Audyt aplikacji i skryptów third-party, uproszczenie szablonu |
| PrestaShop | Brak OPcache, słaby hosting, nieoptymalne zapytania | OPcache + PHP-FPM + full-page cache |
| WooCommerce | Brak object cache, plugin bloat, wolna baza | Redis jako object cache + przegląd wtyczek |
| Sylius / Symfony | Zapytania Doctrine (N+1), brak cache i kolejek | Redis + optymalizacja zapytań + Messenger na zadania async |
Shopify Plus
Na Shopify serwera nie dotykasz — HTML jest serwowany z globalnego edge/CDN platformy, więc surowy TTFB jest zwykle dobry z pudełka. Twoje wąskie gardło jest gdzie indziej: w app bloacie i w szablonie. Każda zainstalowana aplikacja dokłada swój JavaScript, CSS i często zewnętrzne skrypty; ciężkie, zagnieżdżone pętle w Liquid potrafią rozdąć czas renderowania. Kroki: przejrzyj listę aplikacji i usuń nieużywane (pamiętając, że płatne to często 80–300 USD miesięcznie — bloat kosztuje podwójnie), odłóż skrypty third-party na później, uprość Liquid, unikając pętli po dużych kolekcjach. Gdy szablon dobija do limitów, rozwiązaniem jest Hydrogen — headless frontend w React renderowany na edge, dający pełną kontrolę nad tym, co i kiedy się ładuje. Realny cel dla dobrze zrobionego wdrożenia to Core Web Vitals 90+. Więcej o architekturze na stronie platformy Shopify Plus.
PrestaShop
PrestaShop hostujesz sam, więc TTFB jest w 100% w Twoich rękach — i to dobra wiadomość. Kolejność od największego zwrotu: włącz i skonfiguruj OPcache (i sprawdź jego hit rate), dostrój liczbę workerów PHP-FPM do dostępnego CPU, włącz wbudowany cache szablonów Smarty i łączenie assetów (CCC), a dla ruchu anonimowego dołóż full-page cache lub Varnisha. Po stronie bazy: znajdź wolne zapytania w slow query logu, dodaj brakujące indeksy, wyczyść rozdęte tabele statystyk i połączeń. Na koniec upewnij się, że stoisz na PHP 8.x i na hostingu, który nie jest współdzielony z tysiącem innych stron.
WooCommerce
W WooCommerce (czyli WordPress plus warstwa sklepu) największą dźwignią jest object cache. Dołożenie Redisa, który przechwytuje powtarzalne zapytania — opcje, transienty, meta produktów — potrafi ściąć TTFB dramatycznie, zwłaszcza że koszyka i checkoutu nie da się w pełni cache'ować i tam liczy się każde zapytanie do bazy. Drugi front to plugin bloat: każda wtyczka dokłada zapytania i wpisy w autoloaded options; przejrzyj listę bez sentymentów i wyczyść wygasłe transienty oraz rozrośnięte wp_options. Trzeci: hosting. Zarządzany hosting pod WooCommerce z PHP 8.x, OPcache i PHP-FPM to inny poziom niż uniwersalny pakiet współdzielony. Dla ruchu anonimowego dołóż full-page cache; dla zalogowanych postaw na szybki backend i object cache.
Sylius / Symfony
Przy custom buildach na Symfonie kontrolujesz wszystko — i cała skrzynka narzędzi stoi otworem. Redis jako pool cache i magazyn sesji to punkt startowy (dokładnie ten ruch zrobiliśmy w Bogarcie). Po stronie Doctrine: wytrop zapytania N+1, włącz cache drugiego poziomu tam, gdzie ma sens, świadomie zarządzaj eager i lazy loadingiem. Ciężkie operacje — wysyłkę maili, indeksowanie, webhooki, synchronizację z ERP — wynieś do kolejek przez Messenger, żeby żądanie wracało do klienta od razu, zamiast czekać na robotę, która może poczekać. Do tego produkcyjne podstawy, o których łatwo zapomnieć: APP_ENV=prod, zoptymalizowany autoloader, rozgrzany cache i OPcache z preloadingiem. Wyszukiwanie produktów warto oddać Elasticsearchowi, żeby nie obciążać głównej bazy.
Checklist: co zweryfikować u siebie
Lista kontrolna do przejścia niezależnie od platformy. Jeśli na którymś punkcie odpowiedź brzmi „nie wiem” — to jest właśnie miejsce, od którego zacząć.
- Zmierz TTFB w warunkach produkcyjnych, z lokalizacji Twoich klientów, a nie z cache przeglądarki na własnym laptopie.
- Sprawdź, ile zajmuje samo renderowanie backendu. Powyżej 500 ms szukaj przyczyny w bazie i cache, nie na frontendzie.
- Upewnij się, że OPcache jest włączony, i sprawdź jego hit rate.
- Dodaj object cache (Redis lub Memcached) tam, gdzie powtarzają się te same zapytania.
- Znajdź zapytania N+1 i wolne zapytania w slow query logu; dodaj brakujące indeksy.
- Wynieś ciężkie operacje (maile, indeksowanie, webhooki, synchronizacje) do kolejek asynchronicznych.
- Serwuj statyczne assety — a jeśli się da, także HTML — z CDN blisko klienta.
- Sprawdź wersję PHP. Przeskok z 7.x na 8.x to często kilkadziesiąt milisekund za darmo.
- Ogranicz liczbę wtyczek, aplikacji i skryptów third-party do tych, które realnie pracują.
- Ustaw stały monitoring TTFB i Core Web Vitals z alertami. Pomiar raz na kwartał to nie monitoring.
Podsumowanie
Core Web Vitals to nie checkbox pod SEO, tylko dźwignia konwersji — a TTFB jest jej fundamentem, bo rządzi wszystkim, co dzieje się później na stronie. Celuj poniżej 200 ms, traktuj 500 ms jako sygnał alarmowy, a największych zwrotów szukaj tam, gdzie zawsze: w bazie danych i w cache. Przykład Bogarta pokazuje, że skok z kilku sekund do poniżej sekundy to nie jest ezoteryka, tylko uporządkowana robota inżynierska.
Jeśli chcesz wiedzieć, gdzie konkretnie leżą Twoje milisekundy i ile realnie kosztują w konwersji, od tego zaczynamy każdy projekt — nasz audyt sklepu mierzy TTFB, LCP, CLS i INP w kontekście Twojej branży i konkurencji, z prognozą wpływu na sprzedaż. Chętnie pokażemy, jak to wygląda u Ciebie — napisz do nas przez stronę kontaktu.