Listy nazw tu nie znajdziesz. Rankingi hostingów i tak wskazują różne firmy, bo każdy mierzy co innego, a większość zarabia na prowizji od sprzedaży. Dostajesz za to kryteria w trzech grupach: szybkość, bezpieczeństwo i narzędzia do codziennej pracy przy stronie.
Jaki hosting wybrać? Zacznij od tego, co na nim postawisz
Strona firmowa i sklep internetowy obciążają serwer w zupełnie inny sposób. Zanim zaczniesz porównywać oferty, sprawdź, do którego wiersza pasuje Twój projekt:
| Projekt | Co obciąża serwer | Na co patrzeć najpierw |
|---|---|---|
| Strona firmowa, wizytówka | Niewiele zapytań, większość z cache | Lokalizacja, kopie zapasowe, SSL |
| Blog lub portal z dużym ruchem | Wiele odsłon tych samych stron | Cache stron, łącze, obrazy |
| Sklep WooCommerce | Koszyk i zamówienia omijają cache, dużo zapytań do bazy | Procesor, Redis, IOPS, limit procesów |
| Agencja z 10+ stronami klientów | Wiele instalacji i aktualizacji | Izolacja kont, staging, zarządzanie z jednego panelu |
Większości stron firmowych i sklepów wystarczy dobry hosting współdzielony. Serwer VPS ma sens, gdy potrzebujesz własnego oprogramowania (Node.js, Docker), pełnych uprawnień administratora (root) albo stale wysokiego obciążenia. Więcej o tym w porównaniu serwerów VPS i Cloud oraz na stronie Cloud VPS.
Szybki hosting: od czego zależy szybkość strony
Hosting odpowiada głównie za TTFB (Time To First Byte), czyli czas od wysłania zapytania przez przeglądarkę do otrzymania pierwszego bajtu odpowiedzi. Google uznaje TTFB do 0,8 s za dobry wynik. Wolny serwer opóźnia wszystko, co dzieje się później, w tym LCP, czyli moment wyświetlenia największego elementu strony.
Google mierzy szybkość wskaźnikami Core Web Vitals:
- LCP, czyli wyświetlenie największego elementu: do 2,5 s,
- INP, czyli reakcja na kliknięcie: do 200 ms,
- CLS, czyli przesunięcia układu podczas ładowania: do 0,1.
Hosting ma duży wpływ na LCP, ale INP i CLS zależą głównie od motywu, skryptów i obrazów. Jeśli strona ma ciężki motyw z kilkunastoma skryptami, sama przeprowadzka na szybszy serwer tych dwóch wskaźników nie naprawi.
Na TTFB wpływa sześć elementów: dyski, procesor, serwer WWW, cache, wersja PHP i lokalizacja serwera.
Dyski NVMe zamiast SSD SATA
Kiedy otwierasz stronę na WordPressie, serwer wczytuje kilkaset małych plików PHP i wysyła kilkadziesiąt zapytań do bazy danych. Sama przepustowość dysku mówi więc niewiele. Równie ważne są opóźnienie i IOPS, czyli liczba operacji odczytu lub zapisu na sekundę.
| Parametr | HDD | SSD SATA | SSD NVMe (PCIe 4.0) |
|---|---|---|---|
| Odczyt sekwencyjny | ok. 150 MB/s | ok. 550 MB/s | ok. 7000 MB/s |
| Opóźnienie | 5–10 ms | 50–200 µs | poniżej 100 µs |
| IOPS (losowy odczyt 4K) | 100–200 | ok. 100 000 | ponad 1 000 000 |
Na hostingu współdzielonym dysk dzielisz z innymi kontami. Dlatego ważniejszy od możliwości samego dysku jest limit IOPS przydzielony Twojemu kontu. Jeśli dostawca go nie podaje, zapytaj o niego przed zakupem.
Uczciwie: przy wizytówce z kilkuset wejściami dziennie, podawanej z cache, różnicy między SSD SATA a NVMe nie zauważysz. Zobaczysz ją w sklepie i w kokpicie WordPressa, gdzie prawie każde kliknięcie odpytuje bazę.
W Joton dane leżą na dyskach Samsung PM9A3 i Intel P5520 połączonych w RAID-10. Macierz zapisuje każdy blok na dwóch dyskach, więc awaria jednego z nich nie zatrzymuje serwera, a wydajność nie spada podczas odbudowy. Limit IOPS na konto wynosi od 2000 do 6000, zależnie od pakietu.
Taktowanie procesora
PHP generuje każdą stronę w jednym procesie na jednym rdzeniu. Czas wygenerowania strony zależy więc od szybkości pojedynczego rdzenia, a liczba rdzeni i procesów decyduje o tym, ile stron serwer przygotuje jednocześnie.
Dlatego zapis „1 GHz CPU”, który pojawia się w niektórych rankingach, nic nie mówi. Pytaj o model procesora i jego taktowanie w trybie boost, czyli maksymalną częstotliwość, z jaką rdzeń pracuje pod obciążeniem. Na koncie z dostępem SSH sprawdzisz to poleceniem:
lscpu | grep "Model name"Drugi parametr to limit procesów, czyli liczba zapytań PHP, które Twoje konto obsłuży w tej samej chwili. Przy limicie 10 jedenasty klient, który w tej sekundzie przechodzi do kasy, czeka w kolejce. Strony podawane z cache tego limitu nie zużywają.
W Joton hosting działa na procesorach AMD Ryzen 5 7600 (architektura Zen 4, taktowanie bazowe 3,8 GHz, boost do 5,1 GHz). Ryzen ma mniej rdzeni niż typowe serwerowe procesory EPYC, ale wyższe taktowanie, a przy PHP to ono decyduje o czasie wygenerowania strony. Limit procesów wynosi od 10 do 40, zależnie od pakietu.
Serwer WWW: LiteSpeed, Nginx czy Apache
Serwer WWW przyjmuje zapytania z przeglądarek i przekazuje je do PHP. Apache w klasycznej konfiguracji uruchamia osobny proces lub wątek dla każdego połączenia, więc przy dużym ruchu szybko zużywa pamięć. Nginx i LiteSpeed obsługują tysiące połączeń w jednym procesie, dzięki czemu przy tym samym ruchu potrzebują mniej zasobów.
Dla WordPressa LiteSpeed ma przewagę nad Nginx: czyta pliki .htaccess tak jak Apache, więc reguły dopisywane przez wtyczki działają bez zmian. Ma też wbudowany cache stron (LSCache) z oficjalną wtyczką do WordPressa, który oddaje gotowy HTML bez uruchamiania PHP. Do tego obsługuje HTTP/3, nowszą wersję protokołu, która szybciej nawiązuje połączenie, zwłaszcza przy słabym zasięgu w telefonie. Według testów producenta LiteSpeed zużywa do 5 razy mniej CPU niż Apache przy tym samym ruchu.
Joton używa LiteSpeed Enterprise z HTTP/3.
Cache: OPcache i Redis
Dobry hosting przyspiesza stronę na trzech poziomach:
- OPcache trzyma w pamięci skompilowany kod PHP, więc serwer nie analizuje plików przy każdym zapytaniu.
- Cache stron (np. LSCache) zapisuje gotowy HTML. Kolejny odwiedzający dostaje stronę bez uruchamiania PHP i bez zapytań do bazy.
- Cache obiektów (Redis) trzyma w pamięci RAM wyniki zapytań do bazy danych.
W sklepie WooCommerce koszyk, kasa i konto klienta nie trafiają do cache stron, bo każdy klient widzi tam co innego. Tam pracuje Redis: zamiast pytać bazę o te same ustawienia i produkty, WordPress bierze je z pamięci.
W Joton Redis jest dostępny w każdym pakiecie hostingu WWW.
Aktualna gałąź PHP
Wersja PHP wpływa jednocześnie na szybkość i bezpieczeństwo. Każda gałąź PHP ma 2 lata aktywnego wsparcia (poprawki błędów i bezpieczeństwa), a potem 2 lata samych poprawek bezpieczeństwa. Po tym czasie nikt już jej nie łata. Stan na październik 2026 według php.net:
| Gałąź | Status | Poprawki bezpieczeństwa do |
|---|---|---|
| 8.5 | Aktywne wsparcie | 31.12.2029 |
| 8.4 | Aktywne wsparcie | 31.12.2028 |
| 8.3 | Tylko bezpieczeństwo | 31.12.2027 |
| 8.2 | Tylko bezpieczeństwo | 31.12.2026 |
| 8.1 i starsze | Bez wsparcia | – |
Dobry hosting udostępnia nową gałąź w ciągu kilku dni od premiery, jako domyślną ustawia wersję z aktywnym wsparciem i pozwala wybrać wersję osobno dla każdej domeny. Najnowsza gałąź nie zawsze jest najlepszym ustawieniem domyślnym, bo część wtyczek potrzebuje czasu na pełną zgodność. Starsze wersje mogą zostać dla zgodności ze starym kodem, ale strona na PHP 8.1 lub starszym działa na oprogramowaniu, które nie dostaje już poprawek bezpieczeństwa.
W Joton nowe konta startują na PHP 8.4, a w panelu wybierzesz wersję od 5.6 do 8.5. Nowa gałąź trafia do panelu w ciągu kilku dni od premiery.
Lokalizacja serwera
Każde zapytanie musi dotrzeć do serwera i wrócić. Ten czas to RTT (round-trip time). Z Polski wynosi:
- 1–5 ms do serwera w Polsce,
- 20–40 ms do serwera w Niemczech,
- 80–150 ms do serwera w USA.
Przeglądarka wykonuje kilka takich wymian, zanim dostanie pierwszy bajt strony, więc różnica się sumuje. Jeśli Twoi klienci są w Polsce, serwer też powinien być w Polsce. Dane w polskim centrum danych ułatwiają też zgodność z RODO.
Serwery hostingu Joton stoją w centrach danych Korbank we Wrocławiu i IQ.pl w Gdańsku.
Jak sprawdzić szybkość hostingu przed zakupem
Deklaracje z cennika sprawdzisz tylko na własnej stronie. Wykorzystaj okres testowy:
- Przenieś na testowy hosting kopię swojej strony, a nie pustego WordPressa. Pusta instalacja jest szybka wszędzie.
- Zmierz TTFB z własnego komputera kilka razy z rzędu:
Pierwszy pomiar pokazuje stronę bez cache, kolejne z cache. Zmierz też stronę, która nie trafia do cache, np.curl -o /dev/null -s \ -w 'TTFB: %{time_starttransfer}s\n' \ https://twojadomena.pl//moje-konto/w sklepie. - Sprawdź stronę w PageSpeed Insights. Dane z sekcji „Co widzą Twoi użytkownicy” pojawią się dopiero przy odpowiednim ruchu, więc na nowej stronie zobaczysz tylko test laboratoryjny.
Joton daje 30 dni testów, a przeniesienie strony jest w cenie.
Bezpieczny hosting: co powinien robić za Ciebie dostawca
Większość ataków na strony WordPress celuje we wtyczki. Według raportu Patchstack w 2025 roku zgłoszono 11 334 nowe podatności w ekosystemie WordPressa, o 42% więcej niż rok wcześniej. 91% dotyczyło wtyczek, 9% motywów, a w samym rdzeniu WordPressa znaleziono 6 drobnych błędów. W 46% przypadków autor nie wydał poprawki przed publicznym ujawnieniem podatności. Przy najczęściej atakowanych lukach mediana czasu do masowych ataków wyniosła 5 godzin.
Jedno zabezpieczenie tu nie wystarczy.
Kopie zapasowe
Przy kopiach zapasowych liczą się dwa parametry:
- RPO mówi, ile danych możesz stracić. Kopia raz na dobę oznacza, że w najgorszym razie tracisz zamówienia z ostatnich 24 godzin.
- RTO mówi, ile trwa przywrócenie strony. Jeśli musisz pisać do supportu i czekać na odpowiedź, liczysz godziny. Jeśli przywracasz kopię samodzielnie w panelu, liczysz minuty.
Przed zakupem zapytaj:
- jak często powstaje kopia i jak długo jest przechowywana,
- czy kopie leżą na innym serwerze niż strona (kopia na tym samym dysku nie chroni przed jego awarią),
- czy możesz samodzielnie przywrócić całe konto, pojedynczy plik albo samą bazę danych,
- czy kopie zajmują miejsce w Twoim pakiecie.
W Joton kopia powstaje codziennie i jest przechowywana przez 30 dni. Przywracasz ją w panelu. W pakietach Maxi i Ultimate możesz też zrobić kopię na żądanie, która nie zajmuje miejsca na koncie. Kopie trzymamy w osobnej serwerowni, w odizolowanym środowisku.
Sklep z dziesiątkami zamówień dziennie może potrzebować częstszych kopii bazy danych niż raz na dobę. Wtedy warto dodać własną kopię bazy co kilka godzin do zewnętrznego magazynu.
WAF, czyli firewall aplikacyjny
WAF (Web Application Firewall) analizuje zapytania HTTP, zanim dotrą do WordPressa. Blokuje typowe ataki: SQL injection (próbę przemycenia polecenia do bazy danych), XSS (wstrzyknięcie złośliwego skryptu do strony) i zgadywanie haseł przez wp-login.php i xmlrpc.php.
Wtyczka bezpieczeństwa w WordPressie też filtruje ruch, ale działa dopiero wewnątrz PHP. Zanim zablokuje atak, serwer musi uruchomić WordPressa, a to kosztuje procesor. WAF na poziomie serwera zatrzymuje zapytanie wcześniej.
WAF nie zastąpi aktualizacji. W testach Patchstack standardowe reguły WAF blokowały tylko 12–26% ataków na podatności specyficzne dla WordPressa. Patchstack sprzedaje własną ochronę, więc do tych liczb podchodzimy z dystansem. Kierunek się jednak zgadza: WAF to tylko jedna z warstw.
W Joton WAF działa na ModSecurity (otwartoźródłowy silnik WAF), jest w cenie każdego pakietu i blokuje SQL injection, XSS oraz ataki brute force.
Ochrona przed DDoS
Atak DDoS polega na zalaniu serwera ruchem z tysięcy źródeł naraz. Są dwa rodzaje takich ataków:
- Ataki sieciowe (warstwy 3 i 4) wysyłają ogromną liczbę pakietów. Dostawca musi je odfiltrować, zanim dotrą do serwera, bo łącze serwera tego nie wytrzyma.
- Ataki aplikacyjne (warstwa 7) wysyłają zapytania wyglądające jak zwykłe wejścia na stronę, np. do wyszukiwarki albo koszyka. Każde uruchamia PHP i bazę. Tu pomaga ograniczanie liczby zapytań z jednego adresu i weryfikacja podejrzanych klientów.
Na hostingu współdzielonym atak na jedną stronę spowalnia też sąsiednie konta. Samo „mamy ochronę DDoS” w ofercie to za mało. Zapytaj, na którym poziomie ta ochrona działa.
W Joton ochronę przed DDoS zapewnia centrum danych i obejmuje ona wszystkie nasze usługi, także hosting WWW. Nie podajemy jednej liczby przepustowości filtracji, bo skuteczność zależy od rodzaju ataku.
Szybkie łatanie podatności
Skoro od ujawnienia luki do masowych ataków mija często kilka godzin, cotygodniowe ręczne aktualizacje to za wolno. Hosting może pomóc na trzy sposoby:
- Aktualizuje oprogramowanie serwera: system, PHP, LiteSpeed, MariaDB. Zapytaj, ile czasu mija od wydania poprawki do jej wdrożenia.
- Automatycznie aktualizuje wtyczki, ale z kontrolą: drobne wersje i poprawki bezpieczeństwa od razu, duże wersje po teście na stagingu.
- Stosuje wirtualne łatki, czyli reguły WAF, które blokują konkretną podatność, zanim autor wtyczki wyda poprawkę.
W Joton automatyczne aktualizacje ustawiasz w panelu: tylko drobne poprawki albo wszystkie wersje.
Izolacja kont
Na jednym serwerze hostingu współdzielonego działają setki kont. Bez izolacji zainfekowana strona może czytać pliki innych kont na tym samym serwerze. Każde konto powinno działać jako osobny użytkownik systemu, najlepiej we własnym kontenerze, czyli wydzielonym środowisku z własnymi procesami i limitami procesora oraz pamięci. Limity chronią też przed sytuacją, w której jedna przeciążona strona spowalnia pozostałe.
W Joton każde konto działa w osobnym kontenerze.
SSL, 2FA i bezpieczne logowanie
Pozostałe elementy są proste do sprawdzenia:
- Certyfikat SSL: darmowy Let's Encrypt, instalowany i odnawiany automatycznie, z przekierowaniem na HTTPS. Do zwykłej strony firmowej i sklepu płatny certyfikat nie jest potrzebny.
- Dwuskładnikowe logowanie (2FA) do panelu klienta. Kto przejmie panel, ten ma dostęp do wszystkich Twoich stron i skrzynek.
- SFTP zamiast FTP. Zwykłe FTP przesyła hasło otwartym tekstem.
- Skanowanie złośliwego oprogramowania z powiadomieniem, gdy na koncie pojawi się podejrzany plik.
W Joton SSL instaluje się i odnawia automatycznie dla każdej domeny, a panel klienta obsługuje 2FA. Więcej o certyfikatach znajdziesz na stronie certyfikat SSL.
Narzędzia, które przyspieszają pracę
Do ceny hostingu doliczasz jeszcze godziny spędzone na obsłudze strony. Przy jednej stronie to kilka minut tygodniowo. Przy trzydziestu stronach klientów robi się z tego ponad 10 godzin miesięcznie.
Panel, w którym nie trzeba pisać zgłoszeń
Każda sprawa załatwiana przez support oznacza czekanie. W panelu powinno dać się samodzielnie:
- zmienić wersję PHP i limity, np.
memory_limit(ile pamięci może zużyć jeden skrypt), dla każdej domeny, - przejrzeć logi błędów,
- ustawić zadania cykliczne (cron),
- edytować rekordy DNS,
- przywrócić kopię zapasową.
Staging i podgląd zmian
Staging to kopia strony pod osobnym adresem, na której testujesz zmiany, zanim zobaczą je klienci. Przykład: aktualizacja WooCommerce psuje bramkę płatności. Bez stagingu dowiadujesz się o tym od klientów, którzy nie mogą zapłacić. Ze stagingiem widzisz błąd na kopii, a na produkcję wypychasz wersję, która działa.
W Joton staging jest w każdym pakiecie, także w najmniejszym Micro. Funkcja live preview pokazuje zmiany pod osobnym adresem URL.
WP-CLI, SSO i zarządzanie z jednego miejsca
WP-CLI to obsługa WordPressa z wiersza poleceń. Zamiast klikać w kokpicie, wpisujesz jedno polecenie, np.:
wp plugin update --allalbo zmieniasz adres domeny w całej bazie po przeprowadzce:
wp search-replace 'stara.pl' 'nowa.pl'Przy wielu stronach liczy się też to, czy obsłużysz je z jednego miejsca. W Joton z panelu:
- uruchamiasz WP-CLI bez konfigurowania SSH,
- logujesz się do każdej instalacji WordPressa jednym kliknięciem (SSO), bez wpisywania haseł,
- aktualizujesz, włączasz i usuwasz wtyczki bez logowania do kokpitu,
- dodajesz i blokujesz konta użytkowników, np. po odejściu współpracownika,
- włączasz tryb debugowania (WP_DEBUG) bez edycji
wp-config.php.
Wszystkie funkcje opisuje strona WordPress Toolkit.
Integracje: GitHub i Slack
Jeśli kod strony trzymasz w repozytorium, hosting powinien umieć go z niego wdrożyć. Wypychasz zmiany do głównej gałęzi repozytorium (np. main), a serwer pobiera je sam. Masz historię każdej zmiany, możesz wrócić do poprzedniej wersji, a nikt nie nadpisze przez FTP pracy kolegi.
Druga przydatna integracja to powiadomienia na kanale Slack: o aktualizacjach, błędach i kopiach zapasowych. Cały zespół widzi, co dzieje się ze stronami, bez logowania do panelu.
W Joton powiadomienia Slack są częścią WordPress Toolkit.
Ile czasu to oszczędza
Przykład (szacunek): agencja utrzymuje 30 stron na WordPressie. Ręczna aktualizacja jednej strony to zalogowanie, aktualizacja wtyczek i sprawdzenie, czy wszystko działa. Przy 5 minutach na stronę wychodzi 2,5 godziny tygodniowo, czyli ok. 11 godzin miesięcznie.
Z jednym panelem, automatycznymi drobnymi aktualizacjami i stagingiem dla dużych wersji ta sama praca zajmuje ok. 40 minut tygodniowo, czyli ok. 3 godziny miesięcznie. Różnica to 8 godzin. Przy koszcie 150 zł za godzinę pracy daje to ok. 1200 zł miesięcznie.
Czego nie widać w specyfikacji
Gwarancja dostępności (SLA)
SLA to procent czasu, w którym dostawca gwarantuje działanie usługi. Różnice między wartościami wyglądają na małe, dopóki nie przeliczysz ich na godziny:
| SLA | Dopuszczalny przestój w roku |
|---|---|
| 99% | 87 h 36 min |
| 99,5% | 43 h 48 min |
| 99,9% | 8 h 46 min |
| 99,95% | 4 h 23 min |
| 99,99% | 53 min |
Sprawdź też, co dostajesz, gdy dostawca SLA nie dotrzyma, i czy publikuje historię awarii.
Hosting WWW w Joton ma SLA 99,9%. Infrastrukturę monitorujemy całą dobę (Prometheus, Grafana, PagerDuty), a na awarie reagujemy w czasie poniżej 15 minut.
Wsparcie techniczne
Hasło „support 24/7” nic nie mówi, jeśli na zgłoszenie odpowiada ktoś, kto nie zna PHP ani WordPressa. Zapytaj, jaki jest czas pierwszej odpowiedzi, kto ją pisze (administrator czy dział sprzedaży) i czy możesz rozmawiać po polsku.
Cena po pierwszym roku i „brak limitów”
Promocja za 1 zł w pierwszym roku często kończy się odnowieniem dwa lub trzy razy droższym. Policz koszt na trzy lata.
Oferty „bez limitu” zwykle mają limity, tylko ukryte w regulaminie: procesora, procesów albo liczby plików. Przy większym ruchu konto zostaje wtedy spowolnione albo zawieszone. Przejrzysty dostawca podaje limity w cenniku. Joton publikuje dla każdego pakietu procesor, pamięć RAM, IOPS i limit procesów.
Lista kontrolna: jak porównać oferty hostingu
| Cecha | Czego wymagać | Joton |
|---|---|---|
| Dysk | NVMe, podany limit IOPS | NVMe RAID-10, 2000–6000 IOPS |
| Procesor | Znany model i taktowanie | AMD Ryzen 5 7600, do 5,1 GHz |
| Serwer WWW | LiteSpeed lub Nginx, HTTP/3 | LiteSpeed Enterprise, HTTP/3 |
| Cache | Cache stron i Redis | LSCache, Redis w każdym pakiecie |
| PHP | 8.4 lub 8.5, wybór per domena | Domyślnie 8.4, wybór 5.6–8.5 |
| Lokalizacja | Polska | Wrocław i Gdańsk |
| Kopie zapasowe | Codziennie, min. 14 dni, przywracanie w panelu | Codziennie, 30 dni, osobna serwerownia |
| WAF | W cenie | ModSecurity, w cenie |
| DDoS | Filtracja przed serwerem | W centrum danych, dla wszystkich usług |
| Izolacja | Osobny kontener na konto | Kontener na konto |
| Staging | W każdym pakiecie | W każdym pakiecie |
| WP-CLI i SSO | Bez zgłoszeń do supportu | Z panelu |
| Integracje | Git, powiadomienia | Slack |
| SLA | Min. 99,9% | 99,9% |
| Okres testowy | Min. 14 dni | 30 dni, migracja w cenie |