# Jak poprawiliśmy TTFB o 88% dzięki route caching w naszym serwerze > URL: https://4eck-media.de/pl/blog/jak-poprawilismy-ttfb-o-88-dzieki-route-caching-w-naszym-serwerze/ > Language: pl > Description: Czas pierwszej reakcji serwera vs. TTFB: czym się różnią i jak wydajny route caching poprawia performance twojej strony internetowej? --- Przy wczytywaniu strony liczy się każda milisekunda. Szybkość, z jaką reaguje strona internetowa, ma bezpośredni wpływ na doświadczenie użytkownika i optymalizację pod kątem wyszukiwarek (SEO). Jako agencja specjalizująca się w szybkich i wydajnych stronach internetowych stale szukamy możliwości optymalizacji, aby zwiększać performance naszych projektów. Decydującym czynnikiem dla szybkości strony jest **czas pierwszej reakcji serwera (Server Response Time)** – czyli **czas serwera**, który mierzy, jak szybko serwer zaczyna wysyłać dane do przeglądarki. W tym artykule chcę ci pokazać, jak dzięki **optymalizacji route cachingu** na naszej stronie TutKit.com udało nam się drastycznie poprawić czas pierwszej reakcji serwera, a tym samym również wartość TTFB. Oto porównanie wartości z narzędzia tech-SEO Audisto przed i po wdrożeniu route cachingu – minus 88 procent w Response Time: ![Response Time Audisto](https://4eck-media.de/wp-content/uploads/2025/11/response_time_audisto_90d456b642-1920x1080.avif) Zanim powiesz sobie: wow, świętują tu taką poprawę szybkości po samym włączeniu cache’a. Nie chodzi tu o klasyczny cache bazy danych! Krótkie rozróżnienie: omawiany tutaj route cache skraca czas przetwarzania logiki routingu, dzięki czemu serwer może szybciej reagować na zapytania. Cache bazy danych zapisuje wyniki zapytań do bazy, co zmniejsza liczbę bezpośrednich odwołań do bazy danych i optymalizuje czasy ładowania. Cache bazy danych działał u nas oczywiście już wcześniej. ## Czas pierwszej reakcji serwera vs. TTFB (Time to First Byte) Na początek jeszcze wyjaśnienie, jak Server Response Time i **TTFB** są ze sobą powiązane, ponieważ oba pojęcia będą się dalej wielokrotnie pojawiać. Czas pierwszej reakcji serwera jest częścią TTFB, ale odnosi się wyłącznie do czasu, jakiego serwer potrzebuje na przetworzenie zapytania i wysłanie pierwszej odpowiedzi. TTFB to bardziej całościowy wskaźnik, który uwzględnia także inne wielkości związane z opóźnieniami sieci (DNS, połączenie, transmisja danych), zanim pierwszy bajt odpowiedzi dotrze do przeglądarki. **Czas pierwszej reakcji serwera** (określany także jako Server Response Time lub czas odpowiedzi serwera) mierzy czas, jakiego serwer potrzebuje, aby odebrać zapytanie, przetworzyć je i wysłać pierwszą odpowiedź. Ten czas obejmuje: - Moment, w którym serwer otrzymuje zapytanie. - Czas przetwarzania na serwerze (np. ładowanie danych, renderowanie szablonów, wykonywanie logiki). - Wysłanie pierwszej odpowiedzi (często nagłówka HTTP lub pierwszej części strony HTML). - Czas pierwszej reakcji serwera jest zatem ważnym czynnikiem dla wydajności strony internetowej, ponieważ decyduje o tym, jak szybko serwer zaczyna wysyłać odpowiedź. TTFB to bardziej szczegółowa metryka, która mierzy czas, jaki upływa, zanim pierwszy bajt odpowiedzi z serwera dotrze do klienta (przeglądarki). Ten czas zaczyna się w momencie wysłania zapytania przez przeglądarkę, a kończy, gdy pierwszy bajt odpowiedzi dotrze do klienta. TTFB składa się z kilku komponentów: - DNS lookup: czas, jakiego przeglądarka potrzebuje, aby znaleźć adres IP serwera. - Nawiązanie połączenia: czas potrzebny na zestawienie połączenia TCP oraz bezpiecznego połączenia (np. przez TLS). - Czas pierwszej reakcji serwera: czas, jakiego serwer potrzebuje, aby przetworzyć zapytanie i wysłać odpowiedź. - Transmisja danych: czas potrzebny na przesłanie pierwszego bajta odpowiedzi z serwera do klienta. Jeśli twój serwer jest bardzo szybki, ale połączenie sieciowe jest wolne albo zapytanie DNS trwa długo, twój czas pierwszej reakcji serwera może być dobry, a TTFB i tak będzie wykazywać słabe wartości. Jeśli zapytanie DNS i nawiązanie połączenia są szybkie, ale serwer wolno reaguje na zapytania, słabe będą zarówno czas pierwszej reakcji serwera, jak i TTFB. TTFB jest więc metryką bardziej kompleksową niż czas pierwszej reakcji serwera, ponieważ obejmuje nie tylko przetwarzanie na serwerze, lecz także sieciowy transport odpowiedzi do klienta. ## Punkt wyjścia: potencjał poprawy czasu pierwszej reakcji serwera Nasz zespół przeanalizował wiele stron naszego wielojęzycznego portalu TutKit.com za pomocą narzędzi takich jak Google PageSpeed Insights. Rzucającym się w oczy punktem w wynikach był czas pierwszej reakcji serwera w szczególności oraz wartość TTFB ogólnie. Przed naszą optymalizacją Server Response Time wahał się między 280 a 700 milisekund – w zależności od typu strony – co w wielu przypadkach prowadziło do odczuwalnego opóźnienia. Takie wartości są suboptymalne dla nowoczesnych stron internetowych wymagających szybkiej interakcji z użytkownikiem. Poświęciliśmy dużo czasu na refaktoryzacje CSS & JavaScript w celu poprawy wartości PageSpeed i zrealizowaliśmy także kolejne sugestie optymalizacyjne z PageSpeed Insights, jak choćby zastosowanie [nowoczesnego formatu obrazów AVIF](https://4eck-media.de/pl/blog/avif-najlepszy-format-pliku-dla-image-seo-i-pagespeed/). Mimo to wynik TTFB pozostawał słaby. Co więcej: z każdym kolejnym językiem, który udostępnialiśmy w naszym portalu, czasy pierwszej reakcji serwera i wartość TTFB się pogarszały. Rollout języka angielskiego i rosyjskiego rozpoczęliśmy w lutym 2024 roku. Nasze wcześniej dobre wartości TTFB gwałtownie się załamały. ![TTFB - Time to first byte](https://4eck-media.de/wp-content/uploads/2025/11/ttfb_tutkit_eb3a25ab68-1920x1080.avif) W marcu wystartowaliśmy z naszym dużym sprintem refaktoryzacji JavaScriptu, który teraz, w październiku, dobiega finału. Ten sprint JS obejmował kilka kamieni milowych, dzięki czemu co kilka miesięcy wdrażaliśmy online ulepszenia, które bardzo pozytywnie wpływały także na szybkość strony. O tym sprincie refaktoryzacji JS powstanie cała seria artykułów, ponieważ protokołowaliśmy nasze prace refaktoryzacyjne, a dokument do tej serii liczy już teraz ponad 100 stron. Będzie to prawdopodobnie najobszerniejsza dokumentacja sprintu refaktoryzacji JS, jaka pojawi się w internecie. Oto zrzut ekranu z naszej tablicy Miro wizualizujący poszczególne kroki sprintu refaktoryzacji JS, który faktycznie trwał od marca do października i został zrealizowany przez mojego Head of Development. ![JS Refactoring Sprint](https://4eck-media.de/wp-content/uploads/2025/11/miroboard_js_refactoring_sprint_710fdfc728-1920x1080.avif) W kwietniu równolegle odbył się sprint bazodanowy poświęcony [redukcji zapytań do bazy danych](https://4eck-media.de/pl/blog/efektywna-optymalizacja-baz-danych-i-redukcja-zapytan-bazodanowych/), dzięki któremu obniżyliśmy liczbę requestów miejscami nawet o 98 procent, co z kolei przyspieszyło ładowanie stron. Wartość TTFB w kwietniu dalej się poprawiała. W maju udostępniliśmy kolejne języki, tak że w tym czasie byliśmy online z 16 wersjami językowymi na ok. 35 000 stron. Na wykresie dobrze widać, jak poprawione kwietniowe wartości znów się załamały. W kolejnych miesiącach dalej refaktoryzowaliśmy pliki JavaScript i optymalizowaliśmy rozmiary DOM, co wyszło PageSpeed na dobre. Zadbaliśmy też o kilka usprawnień CSS, w szczególności przy ładowaniu fontów i sposobie osadzania ikon (sprite’y SVG). Równolegle udostępnialiśmy kolejne języki, tak że na dziś mamy online 26 języków na ponad 98 000 podstron. Podczas gdy wszystkie pozostałe Core Web Vitals i wskaźniki istotne dla PageSpeed były dobre, problem wykazywał jedynie TTFB. Było jasne, że przyczyna musi tkwić gdzieś w DNS lookup, w serwerze, a przede wszystkim w cachingu. Poniższy zrzut ekranu pochodzi z[Core Web Vitals Checkera od RumVision](https://www.rumvision.com/tools/core-web-vitals-checker/tutkit.com/origin/mobile/?path=/) i pokazuje wartości przed aktywacją route cachingu. Dla TutKit.com wszystko wygląda świetnie poza wartością TTFB. ![CRUX RumVision](https://4eck-media.de/wp-content/uploads/2025/11/crux_rumvision_0e5020a38e-1920x1080.avif) Po kilku weryfikacjach i sesjach debugowania stwierdziliśmy, że jedną z przyczyn tych opóźnień był nieaktywowany route caching. W Laravelu route caching jest domyślnie wyłączony. Trzeba go aktywować ręcznie, aby poprawić performance aplikacji, zwłaszcza przy większych projektach z wieloma trasami (routes). Kiedy byliśmy jeszcze małym projektem, nie stanowiło to problemu. TTFB był pozytywny, strona błyskawiczna. Zwykły caching bazy danych dobrze wykonywał swoją pracę. Dopiero wraz ze skalowaniem stron i języków stało się to u nas problemem. ## Klucz do optymalizacji: route caching Route caching to funkcja, która pozwala serwerowi zapisać wszystkie zdefiniowane trasy (routes) strony internetowej w cache’u, zamiast obliczać je na nowo przy każdym zapytaniu. To znacząco zmniejsza liczbę operacji, które serwer musi wykonać dla każdego zapytania – szczególnie w przypadku większych stron z wieloma podstronami i dynamicznymi trasami. U nas na jedno zapytanie przypada od 500 do 800 adresów URL w routingu na każdą wersję językową. W Laravelu cache tras nie jest tworzony automatycznie, nawet jeśli trasy są już używane. Zamiast tego musisz utworzyć cache tras ręcznie, wykonując polecenie *php artisan route:cache*. To polecenie kompiluje wszystkie trasy do jednego pliku cache, aby poprawić wydajność, zwłaszcza na produkcji. Korzystanie z tras podczas normalnego użytkowania strony nie uruchamia cachowania tras, ponieważ Laravel opiera się na tym ręcznym poleceniu cachowania tras. Bez wykonania tego polecenia Laravel nadal przy każdym zapytaniu ładuje trasy bezpośrednio z plików tras. My wykonujemy to polecenie po każdym live-deploymencie, aby zapewnić optymalną wydajność. Laravel jako framework PHP oferuje kilka opcji cachowania. Jedno cachowanie odbywa się poprzez bazy danych (standard, który wielu właścicieli stron zna jako serwerowy cache bazy danych), a drugie poprzez PHP. W tym drugim przypadku do gry wchodzi route caching, który we frameworkach PHP domyślnie nie jest aktywowany, ponieważ na większości stron nie jest też potrzebny. Poza tym jest to mniej lub bardziej specyficzna opcja cachowania w Laravelu. Laravel oferuje wiele możliwości cachowania, które musisz aktywować i skonfigurować, aby korzystać z ich zalet. Dla najlepszych rezultatów w środowisku produkcyjnym zaleca się aktywowanie cache’a konfiguracji, tras i widoków, wraz z odpowiednim backendem cachowania bazy danych, w zależności od potrzeb twojej aplikacji. Po aktywowaniu route cachingu szybko jednak stwierdziliśmy, że nie działa on zgodnie z oczekiwaniami. Dzięki debugowaniu odkryliśmy, że w 12 różnych miejscach naszego kodu konieczne były zmiany. W szczególności funkcja MapApiRoutes była ładowana podwójnie, co znacząco obniżało efektywność cache’a tras. **Debugowanie i fix:** Po analizie tych podwójnych ładowań i innych problemów w zarządzaniu trasami wdrożyliśmy niezbędne poprawki i z powodzeniem aktywowaliśmy cache tras. Doprowadziło to bezpośrednio do odczuwalnej poprawy sposobu, w jaki nasza strona reaguje na zapytania. **Skrócony czas pierwszej reakcji serwera:** Po aktywacji route cachingu i wprowadzonych korektach ponownie przeprowadziliśmy testy w Google PageSpeed Insights, aby zmierzyć efekty. Wyniki były imponujące: wcześniej czas pierwszej reakcji serwera dla różnych typów stron wynosił od 280 do 700 ms. Po optymalizacji czas pierwszej reakcji spadł do 30–70 ms. Udało nam się więc obniżyć Server Response Time o ok. 88 do 90 procent. Oznacza to, że strona reaguje teraz na zapytania znacznie szybciej, co przekłada się nie tylko na lepsze doświadczenie użytkownika, lecz także na lepsze wyniki SEO. Ta redukcja Server Response Time poprawia również wartości TTFB i jest ogromnym zyskiem pod względem szybkości i performance. [Test w Pingdom](https://tools.pingdom.com/) pokaże ci TTFB na żywo (ponieważ w PageSpeed Insights widzisz tylko wartości średnie z ostatnich 28 dni): wartość przy *Wait* wynosi u nas 29,4 ms. To czas, przez jaki przeglądarka czeka na dane z serwera. Czyli time to first byte. ![Pingdom TTFB](https://4eck-media.de/wp-content/uploads/2025/11/pingdom_ttfb_97e9acbc0c-1920x1080.avif) ## Optymalizacja DNS jako dodatkowy czynnik Kolejnym aspektem, który przyczynia się do poprawy ogólnej wydajności, jest **czas zapytania DNS** (DNS Query Time). Chodzi o czas potrzebny na rozwiązanie domeny strony internetowej na jej adres IP. Czas przeciętnego DNS lookup wynosi [zazwyczaj od 20 do 120 milisekund](https://sematext.com/glossary/dns-lookup-time/#:~:text=The%20average%20DNS%20lookup%20time,is%20generally%20considered%20very%20good.). Przeanalizowaliśmy również czasy DNS naszej strony i stwierdziliśmy, że nasz DNS Query Time wynosi od 6 do 11 milisekund, a więc jest wyraźnie poniżej średniej 20–120 ms. To pokazuje, że także nasza konfiguracja DNS była już optymalna i tym samym nie miała negatywnego wpływu na ogólną szybkość. ## Specyfika wielojęzycznych, rozbudowanych projektów: wyzwania dla route cachingu Ważnym wyzwaniem, które pojawiło się przy optymalizacji naszego projektu, jest wielojęzyczna struktura naszej strony. Nasz portal jest obecnie online w 26 językach. Każdy język ma aktualnie ponad 3700 podstron. Z każdym nowym językiem powstawały dodatkowe adresy URL, co wykładniczo zwiększało liczbę tras, którymi serwer musi zarządzać. ### Rosnąca liczba tras i jej wpływ na TTFB W projekcie wielojęzycznym każdy nowy język oznacza, że dla każdej pojedynczej strony w tabeli routingu zakładany jest dodatkowy adres URL. Na przykład: Strona taka jak /kontakt staje się /de/kontakt, /fr/contact, /es/contacto i tak dalej. Przy 26 językach liczba tras odpowiednio się zwielokrotnia, co dramatycznie zwiększa ilość danych, które serwer musi przetwarzać. W konsekwencji bez wydajnego cachowania każdy kolejny język wydłuża czas pierwszej reakcji serwera (a tym samym TTFB), ponieważ serwer przy każdym zapytaniu musi przeszukiwać i obliczać coraz więcej tras. W naszym przypadku z każdym nowo dodanym językiem zauważaliśmy stopniowe **pogarszanie się wartości TTFB**, co dobrze widać także na powyższym boardzie CrUX – wartości TTFB załamały się wraz z udostępnieniem nowych języków w lutym i maju. Dlaczego duże, wielojęzyczne projekty są szczególnie dotknięte tym problemem: 1. Wykładniczy wzrost liczby tras: wielojęzyczne strony mają nie tylko proste trasy statyczne, lecz także trasy dynamiczne, zależne od interakcji użytkowników lub wywołań API. Jeśli pomnożyć to przez nasze 26 języków, tabela routingu rośnie wykładniczo, co przy każdym zapytaniu bardziej obciąża serwer. 2. Zwiększona złożoność: projekty wielojęzyczne mają często bardziej złożone wymagania, zwłaszcza jeśli chodzi o poprawną strukturę URL i lokalizację. Serwer musi nie tylko znaleźć właściwą trasę, lecz także zapewnić, że treści zostaną dostarczone we właściwym języku. Bez cachowania każde zapytanie staje się przez tę złożoność wolniejsze. 3. Zwiększona liczba zapytań do bazy danych: w wielu przypadkach projekty wielojęzyczne wymagają dodatkowych zapytań do bazy danych, np. w celu załadowania zlokalizowanych treści lub produktów. Route caching pomaga tutaj, zapewniając, że te zapytania nie muszą być wykonywane na nowo przy każdym żądaniu. Jeśli przyjrzysz się dużym platformom contentowym o wielojęzycznej strukturze, na wielu stronach znajdziesz problemy z PageSpeed ogólnie i z wartością TTFB w szczególności. Oto zestawienie stron, które pod względem treści są zbudowane podobnie jak TutKit.com (tylko znacznie większe pod względem liczby stron) – utworzone w RUMVision. ![Mehrere Screenshots des Rumvision-Core-Web-Vitals-Checkers für freepik.com, pinterest.com, elements.envato.com, canva.com und stock.adobe.com, genutzt von 4eck Media zur Performance-Analyse, Core-Web-Vitals-Optimierung und technischem SEO](https://4eck-media.de/wp-content/uploads/2025/11/rumvision_core_web_vitals_checker_933546f23d-1080x1920.avif "Core Web Vitals Check") To wszystko renomowane, odnoszące duże sukcesy serwisy. A jednak wszystkie mają swoje problemy z TTFB i innymi wskaźnikami Core. ## Route caching jako rozwiązanie dla projektów wielojęzycznych W naszym przypadku aktywacja route cachingu była szczególnie istotna, ponieważ mocno odciążyła serwer. Dzięki cachowaniu tras serwer mógł ładować wszystkie trasy – niezależnie od liczby języków – z szybkiego cache’a, zamiast obliczać je za każdym razem na nowo. Doprowadziło to do ogromnej poprawy czasów pierwszej reakcji serwera: z wcześniejszych 280–700 ms do zaledwie 30–70 ms. Dla projektów wielojęzycznych jest zatem kluczowe, aby route caching był nie tylko aktywowany, lecz także dobrze zoptymalizowany. Route caching to dobrze zaimplementowana funkcja w Laravelu, jednym z najpopularniejszych **frameworków PHP**. Laravel daje deweloperom takim jak my możliwość zapisania wszystkich tras aplikacji w jednym pliku, który można potem szybciej załadować, co znacząco poprawia wydajność, szczególnie przy dużych projektach z wieloma trasami. Ale route caching nie ogranicza się tylko do Laravela. Także w innych CMS-ach i frameworkach PHP istnieją podobne koncepcje lub implementacje służące optymalizacji efektywności zarządzania trasami. - Efektywne zarządzanie cache’em: im więcej języków i tras ma twój projekt, tym ważniejsze staje się posiadanie wydajnego mechanizmu cache. Regularnie sprawdzaj integralność cache’a, aby upewnić się, że przestarzałe lub zbędne trasy niepotrzebnie go nie powiększają. - Poprawne cachowanie tras dynamicznych: upewnij się, że trasy dynamiczne, powstające np. w wyniku działań użytkowników lub wywołań API, są poprawnie obsługiwane w cache’u. Trasy dynamiczne mogą w niektórych przypadkach wymagać specyficznych reguł lub inwalidacji. - Testowanie skuteczności cache’a: korzystaj z narzędzi takich jak Google PageSpeed Insights czy WebPageTest, aby sprawdzać, jak efektywnie działa route caching. Właśnie przy dużych, wielojęzycznych projektach regularne testy są ważne, aby mieć pewność, że cache pracuje zgodnie z oczekiwaniami. Oto aktualny crawl w Audisto z 25.10.2024. Nasza wartość poprawiła się dalej – do średnio 38 ms. ![Response Time TutKit](https://4eck-media.de/wp-content/uploads/2025/11/response_time_tutkit_e61fa50f8a-1920x1080.avif) ## Podsumowanie: caching jako krytyczny czynnik przy wielojęzycznych stronach internetowych Dla dużych, wielojęzycznych stron internetowych poprawna implementacja route cachingu ma decydujące znaczenie dla poprawy TTFB i ogólnej wydajności. Obecnie działamy w 26 językach. Naszym celem do połowy 2025 roku jest 50 języków na TutKit.com. Każdy nowy język dodaje więcej złożoności i potencjalnego obciążenia serwera. Bez cachowania czas pierwszej reakcji zauważalnie pogarsza się z każdym nowym językiem. Dzięki aktywacji i optymalizacji cache’a tras zrobiliśmy duży krok w kierunku lepszego czasu pierwszej reakcji serwera. Zmniejszenie czasu pierwszej reakcji serwera z ponad 280 ms do około 30 ms pokazuje, jak skuteczne jest to działanie. Do tego dochodzi już zoptymalizowany **DNS Query Time**, który razem z cachingiem znacząco zwiększył szybkość naszej strony. Optymalizacja naszego systemu cachowania była kluczem do zapewnienia szybkiej i responsywnej strony mimo wielu tras i języków. Projekty wielojęzyczne i platformy contentowe ogromnie korzystają zatem z dobrze przemyślanej i pielęgnowanej strategii cachowania – nie tylko dla user experience, lecz także dla wyników SEO. Aktualizacja 17.11.2024: Co ciekawe, dzięki poprawie czasów odpowiedzi serwera wzrosła także liczba żądań crawlowania, przez co nasze strony są crawlowane i włączane do indeksu Google liczniej i szybciej. ![Crawling-Statistik](https://4eck-media.de/wp-content/uploads/2025/11/crawling_statistik_ttfb_6bc5f42aad-1920x1080.avif) Aktualizacja 17.12.2024: Miesiąc później widać, że trend się utrzymuje. Kolejne usprawnienia obniżyły średni czas reakcji, podczas gdy liczba żądań crawlowania dalej rosła. ![Crawlanfragen und Serverresponse](https://4eck-media.de/wp-content/uploads/2025/11/crawlanfragen_server_response_tutkit_a303e3c8c8-1920x1080.avif) Jeśli sam szukasz **usprawnień performance** dla swojej wielojęzycznej, wysoko skalowanej strony, powinieneś sprawdzić i zainicjalizować route caching także w swoim systemie. Implementacja wymaga w niektórych przypadkach nieco debugowania i optymalizacji, ale wyniki mówią same za siebie: krótsze czasy ładowania, lepsze doświadczenie użytkownika i lepsze SEO. Jeśli potrzebujesz pomocy, napisz do nas! Jako **agencja technologiczna od SEO & optymalizacji PageSpeed** chętnie pomożemy.