„Strona chodzi wolno, chyba trzeba ją przepisać” — to zdanie słyszę kilka razy w roku. W połowie przypadków okazuje się, że strona jest w porządku, a wolny jest serwer, na którym stoi. Różnica jest istotna, bo przebudowa strony kosztuje kilka tysięcy złotych, a przeniesienie jej na sensowny hosting to wydatek rzędu kilkuset złotych rocznie i jeden wieczór pracy.
Problem w tym, że z zewnątrz jedno wygląda jak drugie. Dlatego opisuję tu konkretne objawy, po których rozpoznaję, że wąskim gardłem jest hosting, oraz proste pomiary, które możesz wykonać sam, bez wiedzy technicznej i bez płacenia za audyt.
TTFB, czyli najbardziej wymowna liczba
TTFB (time to first byte) to czas od kliknięcia w link do momentu, w którym przeglądarka dostaje pierwszy bajt odpowiedzi z serwera. To nie jest czas ładowania całej strony — to czas, przez który serwer myśli, zanim w ogóle zacznie odpowiadać. Grafiki, skrypty i wygląd strony nie mają tu jeszcze nic do rzeczy.
Przyjmuję prostą skalę. Poniżej 200 ms — bardzo dobrze. 200–500 ms — akceptowalnie, typowe dla WordPressa bez cache. 500–800 ms — jest się czym zająć. Powyżej 800 ms przy stronie, która nie robi nic nadzwyczajnego, zaczynam podejrzewać serwer, nie stronę. Jeśli TTFB skacze między 300 ms a 3 sekundami w kolejnych pomiarach, to prawie zawsze znak, że serwer jest przeciążony przez cudzy ruch.
Limity PHP — cicha przyczyna dziwnych błędów
PHP to język, w którym napisany jest WordPress. Hosting narzuca mu limity: ile pamięci może zużyć jedno żądanie, jak długo może się wykonywać, jak duży plik można wgrać. Przy zbyt niskich limitach strona nie tyle zwalnia, co zaczyna zachowywać się nieprzewidywalnie.
- memory_limit — minimum 256 MB. Przy 64 lub 128 MB wtyczki potrafią wywalać biały ekran przy imporcie albo w edytorze.
- max_execution_time — minimum 60 s, dla sklepów 120 s. Przy 30 s import produktów urywa się w połowie.
- upload_max_filesize i post_max_size — minimum 64 MB, inaczej nie wgrasz zdjęcia z telefonu ani filmu do galerii.
- max_input_vars — minimum 3000. Przy niższej wartości menu z wieloma pozycjami zapisuje się w połowie i nikt nie wie dlaczego.
- Wersja PHP — 8.1 lub wyżej. PHP 7.4 nie dostaje już poprawek i działa zauważalnie wolniej.
Wszystkie te wartości sprawdzisz w panelu WordPressa: Narzędzia, potem Stan witryny, zakładka Informacje, sekcja Serwer. To pierwsze miejsce, do którego zaglądam przy zgłoszeniu „coś się dziwnie zachowuje”.
CPU throttling, czyli dławienie zasobów
Na hostingu współdzielonym Twoja strona stoi na jednej maszynie razem z kilkuset innymi. Każde konto ma przydział mocy procesora i liczby jednoczesnych procesów. Kiedy go przekroczysz, serwer nie wyłącza strony — po prostu zaczyna ją spowalniać albo ustawiać żądania w kolejce. To nazywa się throttling i objawia się dokładnie tak, jak opisują to klienci: „rano śmiga, po południu się wlecze”.
Rozpoznaję to po trzech rzeczach naraz: strona jest wolna nierównomiernie w ciągu doby, panel administracyjny zamula bardziej niż część widoczna dla odwiedzających, a w panelu hostingu widać wykres zużycia CPU dobijający do 100% w tych samych godzinach. Jeśli hosting nie pokazuje takiego wykresu, to sam w sobie jest sygnałem ostrzegawczym.
Jak to zmierzyć w kwadrans, samodzielnie
Nie potrzebujesz do tego żadnego płatnego narzędzia. Wystarczy taka kolejność:
- Wejdź na PageSpeed Insights i przepuść adres strony. W sekcji diagnostyki znajdziesz pozycję o czasie odpowiedzi serwera — to jest Twój TTFB.
- Powtórz pomiar trzy razy: rano, w południe i wieczorem. Zapisz wyniki. Rozrzut większy niż dwukrotny to sygnał od serwera, nie od strony.
- Zajrzyj do Stanu witryny w WordPressie i przepisz limity PHP oraz wersję PHP.
- W panelu hostingu znajdź statystyki zużycia CPU i pamięci za ostatni tydzień. Szukaj płaskich odcinków na maksimum — tak wygląda dławienie.
- Wyłącz na chwilę wtyczkę cache i porównaj TTFB. Jeśli bez cache strona odpowiada trzy razy wolniej, cache maskuje słaby serwer.
Jeśli TTFB jest wysoki i niestabilny, limity są niskie, a wykres CPU regularnie dobija do sufitu — masz komplet dowodów. Przy takim zestawie objawów przenoszę stronę na Hosting Premium z podniesionymi limitami PHP i gwarantowanym przydziałem zasobów, i w większości przypadków czas odpowiedzi spada do wartości poniżej 300 ms bez dotykania samej strony.
Kiedy to jednak nie jest wina hostingu
Uczciwie: nie zawsze winny jest serwer. Jeżeli TTFB jest stabilnie niski, a strona i tak ładuje się wieczność, problem leży po stronie samej witryny. Najczęstsze przyczyny to zdjęcia wrzucone prosto z aparatu, ważące po 4–6 MB każde, kilkanaście wtyczek, z których połowa nie jest używana, oraz slider na stronie głównej ładujący dziesięć grafik naraz.
Kolejność diagnozy jest zawsze taka sama: najpierw serwer, potem strona. Odwrotnie nie ma sensu, bo optymalizowanie strony na zadławionym hostingu przypomina strojenie silnika w samochodzie stojącym w korku.
Trzy liczby, które warto znać na pamięć
Jeśli miałabym to skrócić do minimum, są to: TTFB poniżej 500 ms, memory_limit 256 MB i PHP w wersji co najmniej 8.1. Sprawdzenie ich zajmuje kwadrans, a odpowiada na pytanie, czy w ogóle warto rozmawiać o przebudowie strony. W mojej praktyce co druga rozmowa o „wolnej stronie” kończy się na tym etapie — i na fakturze mniejszej o rząd wielkości.
Jeśli podejrzewasz, że to hosting spowalnia Twoją stronę, a nie chcesz zgadywać — odezwij się, zmierzę to i pokażę Ci liczby. Sprawdzam TTFB o różnych porach, limity PHP i zużycie zasobów, a potem mówię, czy wystarczy zmiana serwera, czy trzeba ruszyć samą stronę; potrzebuję adresu strony i dostępu do panelu hostingu.
Ewelina Grzelak, EWELA design
tel. +48 511 254 321
e-mail: biuro@eweladesign.pl
Zobacz pakiety i ceny