Jak sprawdzić, czy hosting spowalnia stronę internetową?

Strona firmowa zaczyna działać coraz wolniej.

Pierwsza reakcja właściciela jest zwykle prosta:

**Trzeba kupić lepszy hosting.**

Czasami jest to właściwy kierunek. Zbyt niskie limity procesora, mała ilość pamięci lub wolna baza danych mogą rzeczywiście ograniczać stronę.

Bardzo często problem znajduje się jednak gdzie indziej.

Przyczyną może być:

• zbyt duże zdjęcie,
• ciężki motyw WordPress,
• nadmiar wtyczek,
• wolne zapytania do bazy,
• zewnętrzne skrypty,
• błędna konfiguracja cache,
• niedziałająca integracja,
• źle przygotowany kod,
• przeciążony serwer.

Przeniesienie źle zoptymalizowanej strony na droższy hosting może poprawić wyniki tylko częściowo. W niektórych przypadkach nie zmieni prawie niczego.

Dlatego przed zakupem większego pakietu trzeba ustalić, gdzie dokładnie powstaje opóźnienie.

Dlaczego szybkość strony jest ważna?

Wolna strona wpływa na więcej niż komfort użytkownika.

Może powodować:

• opuszczanie strony przez klientów,
• niższą liczbę zapytań,
• porzucanie koszyka,
• słabsze wyniki kampanii reklamowych,
• problemy z panelem administratora,
• wolniejsze indeksowanie,
• większe obciążenie serwera.

Użytkownik nie analizuje, czy winny jest hosting, wtyczka czy baza danych.

Widząc długo ładującą się stronę, może po prostu wrócić do Google i wybrać konkurencję.

Dlatego problem wydajności trzeba traktować biznesowo, a nie wyłącznie technicznie.

Czy wolna strona zawsze oznacza słaby hosting?

Nie.

Hosting jest jednym z elementów wpływających na wydajność, ale nie jedynym.

Na szybkość strony wpływają między innymi:

• lokalizacja serwera,
• procesor,
• pamięć RAM,
• szybkość dysku,
• limity konta,
• konfiguracja PHP,
• baza danych,
• kod strony,
• liczba zapytań,
• zdjęcia,
• fonty,
• skrypty reklamowe,
• narzędzia analityczne,
• pamięć podręczna,
• CDN.

Możliwe są więc różne sytuacje:

• szybki serwer i źle przygotowana strona,
• wolny serwer i dobrze zoptymalizowana strona,
• poprawny hosting, ale przeciążona baza,
• dobry kod, ale ciężkie zewnętrzne skrypty.

Sama zmiana hostingu bez pomiarów jest zgadywaniem.

Pierwszy krok: sprawdź czas odpowiedzi serwera

Jednym z ważniejszych parametrów jest czas potrzebny serwerowi na rozpoczęcie wysyłania odpowiedzi.

Często określa się go jako TTFB, czyli czas do pierwszego bajtu.

Wysoki TTFB może wskazywać na:

• wolny serwer,
• przeciążone konto,
• długie wykonywanie kodu,
• wolną bazę danych,
• brak cache,
• problem z zewnętrzną usługą.

Trzeba jednak uważać z interpretacją.

Wysoki czas odpowiedzi nie zawsze oznacza, że infrastruktura hostingowa jest słaba. Serwer może czekać, aż aplikacja wykona ciężkie operacje.

Przykładowo WordPress może przed wyświetleniem strony:

• uruchomić wiele wtyczek,
• wykonać dziesiątki zapytań,
• pobrać dane z API,
• wygenerować dynamiczną zawartość.

Hosting odpowiada szybko na prosty plik, ale aplikacja potrzebuje kilku sekund na przygotowanie strony.

Dlatego warto porównać odpowiedź:

• strony dynamicznej,
• prostego pliku statycznego,
• strony z cache,
• panelu administratora.

Test prostego pliku statycznego

Dobrym sposobem oddzielenia wydajności serwera od aplikacji jest utworzenie prostego pliku HTML.

Może on zawierać wyłącznie krótki tekst.

Jeżeli prosty plik ładuje się szybko, a WordPress lub aplikacja odpowiada wolno, problem prawdopodobnie znajduje się w:

• kodzie,
• bazie,
• wtyczkach,
• konfiguracji aplikacji.

Jeżeli również prosty plik odpowiada bardzo wolno, warto dokładniej sprawdzić:

• serwer,
• sieć,
• DNS,
• przeciążenie hostingu,
• lokalizację centrum danych.

Test nie daje pełnej diagnozy, ale pomaga zawęzić obszar poszukiwań.

Sprawdź szybkość strony z wyłączonym cache

Pamięć podręczna może ukrywać problem z wydajnością aplikacji.

Strona z cache jest wcześniej wygenerowana i może być wyświetlana bardzo szybko.

Po wyczyszczeniu pamięci pierwszy użytkownik może jednak czekać znacznie dłużej.

Warto porównać:

• pierwsze wejście po wyczyszczeniu cache,
• kolejne wejście,
• stronę dla zalogowanego użytkownika,
• panel administratora.

Jeżeli pierwsze ładowanie trwa kilka sekund, a kolejne jest szybkie, problem może dotyczyć dynamicznego generowania strony.

W sklepie i systemie rezerwacji wiele elementów nie może być w pełni zapisywanych w cache.

Dlatego dobra wydajność wersji zapisanej w pamięci nie zawsze oznacza, że całe środowisko działa prawidłowo.

Sprawdź limity hostingu

Hosting współdzielony często posiada limity, których klient nie widzi w głównej tabeli oferty.

Mogą dotyczyć:

• użycia procesora,
• pamięci RAM,
• procesów PHP,
• liczby jednoczesnych procesów,
• operacji dyskowych,
• liczby połączeń do bazy,
• czasu wykonywania skryptu.

Po przekroczeniu limitu hosting może:

• spowolnić konto,
• zatrzymać proces,
• zwrócić błąd,
• ograniczyć liczbę żądań.

W panelu hostingowym warto sprawdzić historię wykorzystania zasobów.

Szczególnie ważne są momenty:

• większego ruchu,
• publikacji nowych treści,
• wykonywania backupu,
• importu produktów,
• wysyłki newslettera,
• działania kampanii reklamowej.

Jeżeli limity są regularnie osiągane, trzeba ustalić, czy przyczyną jest wzrost ruchu, czy nieefektywne działanie strony.

Porównanie hostingu współdzielonego i własnego serwera opisaliśmy w artykule [VPS czy hosting współdzielony – co wybrać dla firmy](/blog/vps-czy-hosting-wspoldzielony-co-wybrac-dla-firmy).

Procesor i obciążenie serwera

Procesor wykonuje kod aplikacji i obsługuje zapytania.

Wysokie wykorzystanie CPU może być spowodowane przez:

• duży ruch,
• nieefektywny kod,
• ciężką wtyczkę,
• generowanie raportów,
• import danych,
• wykonywanie backupu,
• atak botów,
• nieskończoną pętlę,
• wiele jednoczesnych zadań.

Sam wysoki wynik przez krótki czas nie musi oznaczać problemu.

Niepokojąca jest sytuacja, gdy procesor przez dłuższy czas działa blisko maksymalnej wartości, a kolejka zadań rośnie.

Wtedy użytkownicy zaczynają dłużej czekać na odpowiedzi.

Na VPS można sprawdzić konkretne procesy zużywające zasoby. Na hostingu współdzielonym często dostępne są jedynie ogólne wykresy konta.

Pamięć RAM

Zbyt mała ilość pamięci może powodować:

• spowolnienia,
• zatrzymywanie procesów,
• błędy 502,
• częste restarty,
• problemy podczas buildów,
• awarie bazy danych.

Na serwerze mogą jednocześnie działać:

• system operacyjny,
• Nginx lub Apache,
• PHP-FPM,
• Node.js,
• baza danych,
• Redis,
• monitoring,
• procesy backupu.

Mały VPS może wyglądać atrakcyjnie cenowo, ale po uruchomieniu wszystkich usług pozostaje niewielki zapas pamięci.

Jeżeli system regularnie korzysta z dużej ilości swapu, wydajność może znacznie się pogorszyć.

Szybkość dysku

Wolny dysk wpływa między innymi na:

• bazę danych,
• odczyt plików,
• zapisywanie logów,
• uploady,
• backupy,
• generowanie cache.

Nowoczesne dyski NVMe są szybsze od tradycyjnych dysków HDD, ale sama nazwa technologii nie gwarantuje określonej wydajności.

Na serwerze współdzielonym wiele kont może jednocześnie wykonywać operacje.

Ważne są więc również limity I/O oraz obciążenie całej infrastruktury.

Objawami problemów z dyskiem mogą być:

• długie zapisywanie zmian,
• wolne importy,
• opóźnienia panelu,
• skoki czasu odpowiedzi podczas backupu.

Baza danych może być prawdziwym problemem

Strona może działać na dobrym serwerze, ale wykonywać bardzo wolne zapytania.

Przyczyną mogą być:

• brak indeksów,
• rozbudowane zapytania,
• ogromne tabele,
• stare dane,
• sesje,
• logi,
• źle napisana wtyczka,
• zbyt wiele połączeń.

W WordPressie baza z czasem może gromadzić:

• wersje wpisów,
• stare opcje,
• dane usuniętych wtyczek,
• transients,
• sesje WooCommerce,
• logi.

Nie należy jednak usuwać danych automatycznie bez kopii i analizy.

Najpierw trzeba ustalić, które tabele rosną i jakie zapytania wykonują się najdłużej.

Wolny panel WordPressa

Czasami strona publiczna działa szybko dzięki cache, ale panel administratora jest bardzo wolny.

Może to wskazywać na:

• ciężkie wtyczki,
• dużą bazę,
• zewnętrzne połączenia,
• procesy uruchamiane w panelu,
• problem z WP-Cron,
• brak pamięci,
• niskie limity hostingu.

Panel administratora zwykle nie korzysta z pełnego cache strony.

Dlatego pokazuje realną wydajność WordPressa i bazy.

Jeżeli każda zmiana wpisu trwa kilka sekund, nie zawsze oznacza to konieczność zmiany serwera. Najpierw trzeba sprawdzić wtyczki i zapytania.

Więcej o właściwym utrzymaniu WordPressa opisaliśmy w artykule [hosting WordPress z opieką – co powinien obejmować](/blog/hosting-wordpress-z-opieka-co-powinien-obejmowac).

Wtyczki WordPress

Każda aktywna wtyczka może dodawać:

• kod PHP,
• zapytania do bazy,
• skrypty frontendowe,
• zewnętrzne połączenia,
• zadania cron.

Problemem nie musi być sama liczba wtyczek.

Dziesięć dobrze napisanych dodatków może działać lepiej niż jedna ciężka i źle zoptymalizowana wtyczka.

Szczególnie wymagające bywają moduły:

• statystyk,
• backupów,
• skanowania bezpieczeństwa,
• builderów,
• wyszukiwania,
• filtrów produktów,
• integracji zewnętrznych.

Testowe wyłączanie wtyczek powinno odbywać się na środowisku testowym albo po wykonaniu backupu.

Nie należy wyłączać losowych dodatków na aktywnym sklepie bez sprawdzenia zależności.

Motyw i builder strony

Rozbudowany motyw może generować:

• wiele zapytań,
• duży kod HTML,
• liczne pliki CSS,
• rozbudowane skrypty,
• niepotrzebne funkcje.

Builder wizualny ułatwia edycję strony, ale może zwiększać ilość kodu i obciążenie.

Nie oznacza to, że każdy builder jest zły.

Problem pojawia się, gdy:

• użyto wielu dodatków do buildera,
• strona zawiera zagnieżdżone sekcje,
• każdy element ładuje osobny skrypt,
• kod nie jest optymalizowany,
• motyw posiada funkcje, których strona nie wykorzystuje.

Zmiana hostingu może przyspieszyć wykonywanie kodu, ale nie usunie nadmiarowych zasobów pobieranych przez przeglądarkę.

Duże zdjęcia

Zdjęcia są jedną z najczęstszych przyczyn wolnego ładowania.

Grafika przesłana prosto z aparatu może ważyć kilka lub kilkanaście megabajtów.

Hosting może wysłać plik szybko, ale użytkownik nadal musi go pobrać.

Warto sprawdzić:

• rozmiar pliku,
• wymiary obrazu,
• format,
• kompresję,
• ładowanie mobilne,
• lazy loading.

Nowoczesne formaty, takie jak WebP lub AVIF, mogą znacznie zmniejszyć rozmiar zdjęć.

Nie ma sensu wysyłać obrazu o szerokości 5000 pikseli, jeżeli na stronie jest wyświetlany w szerokości 800 pikseli.

Zewnętrzne skrypty

Strona może czekać na zasoby pobierane z innych serwerów.

Mogą to być:

• systemy analityczne,
• reklamy,
• czaty,
• mapy,
• fonty,
• filmy,
• systemy zgód,
• narzędzia śledzące.

Hosting nie ma pełnej kontroli nad czasem odpowiedzi zewnętrznych usług.

Możliwe jest więc, że własny serwer odpowiada szybko, ale przeglądarka długo czeka na skrypty zewnętrzne.

W takim przypadku zmiana hostingu przyniesie niewielką poprawę.

Trzeba przeanalizować kolejność ładowania zasobów oraz usunąć narzędzia, które nie przynoszą realnej wartości.

Problem z DNS

DNS odpowiada za przetłumaczenie domeny na adres serwera.

Zbyt wolna lub błędna konfiguracja może opóźnić początek połączenia.

Problem może dotyczyć:

• operatora DNS,
• dużej liczby przekierowań,
• błędnych rekordów,
• nieprawidłowego IPv6,
• zewnętrznych usług.

DNS zwykle nie jest głównym powodem kilkusekundowego ładowania strony, ale może dodawać opóźnienie przed nawiązaniem połączenia.

Po migracji warto sprawdzić, czy domena nie prowadzi nadal części użytkowników do starego serwera.

Proces bezpiecznej zmiany środowiska opisaliśmy w artykule [jak przenieść stronę na inny hosting bez przestoju](/blog/jak-przeniesc-strone-na-inny-hosting-bez-przestoju).

Lokalizacja serwera

Im dalej użytkownik znajduje się od serwera, tym dłużej trwa przesyłanie danych.

Jeżeli firma obsługuje głównie klientów w Polsce, serwer w Europie zwykle będzie lepszym wyborem niż infrastruktura po drugiej stronie świata.

Lokalizacja nie naprawi jednak:

• ciężkiego kodu,
• wolnej bazy,
• dużych zdjęć,
• błędnych skryptów.

Może natomiast ograniczyć opóźnienie sieciowe.

W projektach obsługujących użytkowników na całym świecie pomocne może być CDN.

CDN

CDN przechowuje kopie statycznych zasobów w wielu lokalizacjach.

Może przyspieszyć dostarczanie:

• zdjęć,
• CSS,
• JavaScript,
• fontów,
• plików.

CDN nie przyspiesza automatycznie całej aplikacji.

Dynamiczne żądania do panelu, API, koszyka lub bazy nadal mogą trafiać do głównego serwera.

Dlatego CDN jest dodatkiem do poprawnej infrastruktury, a nie zamiennikiem optymalizacji hostingu.

Cache na poziomie serwera

Cache może działać na różnych poziomach:

• przeglądarki,
• wtyczki,
• serwera WWW,
• obiektów,
• bazy,
• CDN.

Dobrze skonfigurowany cache potrafi znacznie ograniczyć liczbę operacji.

Źle skonfigurowany może powodować:

• nieaktualne treści,
• problemy z koszykiem,
• błędne sesje,
• konflikty po aktualizacji.

W WooCommerce trzeba wykluczyć z cache dynamiczne podstrony, takie jak koszyk, konto i checkout.

Więcej o wymaganiach sklepu opisaliśmy w artykule [hosting WooCommerce – na czym nie warto oszczędzać](/blog/hosting-woocommerce-na-czym-nie-warto-oszczedzac).

WP-Cron i zadania automatyczne

Domyślny mechanizm WordPressa może uruchamiać zadania podczas wejść użytkowników.

Przy większej liczbie zadań może to wpływać na czas odpowiedzi.

Zadania mogą obejmować:

• publikację wpisów,
• wysyłkę wiadomości,
• czyszczenie danych,
• synchronizację,
• procesy sklepu.

W bardziej wymagających serwisach warto rozważyć uruchamianie zadań przez prawdziwy harmonogram systemowy.

Trzeba również sprawdzić, czy jakieś zadanie nie wykonuje się zbyt często lub nie kończy błędem.

Backup może chwilowo spowalniać stronę

Wykonywanie kopii wymaga:

• odczytu plików,
• eksportu bazy,
• kompresji,
• transferu danych.

Na słabszym hostingu backup może znacząco obciążyć konto.

Jeżeli strona zwalnia codziennie o tej samej porze, warto sprawdzić harmonogram kopii i zadań automatycznych.

Rozwiązaniem może być:

• zmiana pory wykonywania,
• kopia przyrostowa,
• zewnętrzny system backupu,
• większe zasoby.

Backupów nie należy jednak wyłączać tylko po to, aby poprawić wynik wydajności.

Trzeba dobrać ich sposób do możliwości środowiska.

Zasady kopii opisaliśmy w artykule [kopie zapasowe strony – jak często je wykonywać i gdzie przechowywać](/blog/kopie-zapasowe-strony-jak-czesto-i-gdzie-przechowywac).

Skanowanie bezpieczeństwa

Rozbudowane skanowanie wszystkich plików może zużywać dużo zasobów.

Wtyczki bezpieczeństwa mogą:

• analizować żądania,
• zapisywać logi,
• skanować pliki,
• sprawdzać adresy IP,
• wykonywać zapytania zewnętrzne.

Ochrona jest potrzebna, ale powinna być odpowiednio skonfigurowana.

Wykonywanie pełnego skanu w godzinach największego ruchu może pogarszać wydajność.

Część zabezpieczeń lepiej realizować na poziomie serwera niż przez kolejne ciężkie wtyczki.

Boty i niepotrzebny ruch

Strona może być obciążana przez:

• roboty wyszukiwarek,
• skanery,
• spam,
• próby logowania,
• narzędzia zbierające dane,
• błędnie działające integracje.

Ruch botów nie zawsze jest widoczny w podstawowych statystykach użytkowników.

Logi serwera mogą jednak pokazać tysiące żądań do:

• logowania,
• XML-RPC,
• wyszukiwania,
• API,
• nieistniejących adresów.

W takim przypadku większy serwer może tylko tymczasowo zwiększyć odporność.

Trzeba również ograniczyć niepotrzebny ruch i zabezpieczyć najbardziej obciążane elementy.

Wolna aplikacja Next.js lub Node.js

W aplikacji problem może dotyczyć:

• renderowania po stronie serwera,
• API,
• bazy,
• zewnętrznej integracji,
• braku cache,
• procesu Node.js,
• nieprawidłowej liczby workerów.

Warto sprawdzić osobno:

• frontend,
• backend,
• endpoint health,
• czas zapytań do bazy,
• logi procesu,
• pamięć,
• liczbę restartów.

Aplikacja może działać szybko jako statyczny frontend, ale wolno pobierać dane z API.

Wtedy problem nie leży w przesyłaniu strony, lecz w backendzie lub bazie.

Środowiska dla takich projektów opisaliśmy w artykule [hosting dla Next.js i Node.js – czego potrzebuje aplikacja firmowa](/blog/hosting-dla-nextjs-nodejs-czego-potrzebuje-aplikacja-firmowa).

Monitoring wydajności

Jednorazowy test pokazuje tylko konkretny moment.

Strona może działać szybko rano i bardzo wolno podczas największego ruchu.

Dlatego warto monitorować:

• czas odpowiedzi,
• kody HTTP,
• procesor,
• pamięć,
• dysk,
• bazę,
• liczbę procesów,
• restarty aplikacji.

Monitoring pozwala połączyć pogorszenie szybkości z:

• godziną,
• wzrostem ruchu,
• backupem,
• importem,
• wdrożeniem,
• przeciążeniem.

Zakres prawidłowego monitoringu opisaliśmy w artykule [monitoring strony internetowej 24/7 – co naprawdę powinien sprawdzać](/blog/monitoring-strony-internetowej-24-7-co-powinien-sprawdzac).

Porównuj testy w podobnych warunkach

Wynik testu może się zmieniać w zależności od:

• lokalizacji,
• urządzenia,
• połączenia,
• pory dnia,
• stanu cache,
• aktualnego obciążenia.

Dlatego porównując hosting przed i po migracji, trzeba używać:

• tej samej strony,
• tego samego narzędzia,
• tej samej lokalizacji,
• podobnej pory,
• tego samego stanu cache.

Inaczej łatwo wyciągnąć błędne wnioski.

Pojedynczy wynik nie powinien decydować o zmianie serwera.

Objawy, że hosting może być za słaby

Hosting może być rzeczywistym ograniczeniem, jeżeli:

• regularnie osiągasz limity CPU,
• kończy się pamięć,
• strona zwalnia przy większym ruchu,
• procesy są zatrzymywane,
• baza regularnie przekracza limity,
• pojawiają się błędy 500 lub 502,
• backupy przeciążają konto,
• operator ogranicza potrzebne funkcje,
• aplikacja wymaga usług niedostępnych w pakiecie.

Błędy serwera mogą być skutkiem braku zasobów, ale również problemów z aplikacją. Ich diagnostykę opisaliśmy w artykule [błąd 500 lub 502 na stronie – co oznacza i jak go naprawić](/blog/blad-500-lub-502-na-stronie-co-oznacza-i-jak-naprawic).

Objawy, że problem leży w stronie

Problem prawdopodobnie znajduje się w aplikacji, jeżeli:

• prosty plik ładuje się szybko,
• tylko jedna podstrona jest wolna,
• po wyłączeniu konkretnej wtyczki strona przyspiesza,
• baza wykonuje wolne zapytania,
• zdjęcia są bardzo duże,
• wiele czasu zajmują zewnętrzne skrypty,
• panel zwalnia podczas określonej operacji,
• wolne są tylko niezapisane w cache strony.

Wtedy sama zmiana hostingu może dać mniejszy efekt niż optymalizacja kodu lub bazy.

Czy warto przenieść stronę na VPS?

VPS warto rozważyć, gdy obecny hosting:

• ogranicza zasoby,
• nie obsługuje potrzebnej technologii,
• nie daje dostępu do konfiguracji,
• nie pozwala uruchomić procesów,
• jest niewystarczający dla rosnącego sklepu lub aplikacji.

Nie warto przechodzić na VPS wyłącznie na podstawie jednego słabego wyniku testu.

Własny serwer wymaga:

• konfiguracji,
• zabezpieczeń,
• aktualizacji,
• backupów,
• monitoringu,
• administracji.

Czasami lepszym rozwiązaniem będzie dobrze zarządzany hosting zamiast samodzielnego VPS.

Co sprawdzić przed zmianą hostingu?

Przed migracją przygotuj dane dotyczące:

• obecnego ruchu,
• użycia procesora,
• pamięci,
• miejsca na dysku,
• wielkości bazy,
• czasu odpowiedzi,
• błędów,
• wymaganych technologii.

Sprawdź także:

• czy problem dotyczy całej strony,
• kiedy występuje,
• co zmieniło się ostatnio,
• czy cache działa,
• czy baza posiada wolne zapytania,
• czy boty generują nadmierny ruch.

Dzięki temu nowy serwer można dobrać do rzeczywistych potrzeb.

Jak wygląda prawidłowy audyt wydajności?

Audyt może obejmować:

1. pomiary strony publicznej,
2. analizę czasu odpowiedzi,
3. test pliku statycznego,
4. analizę logów,
5. kontrolę zasobów,
6. sprawdzenie bazy,
7. analizę wtyczek,
8. kontrolę zdjęć i skryptów,
9. sprawdzenie cache,
10. monitoring w czasie.

Wyniki powinny prowadzić do konkretnych wniosków:

• strona wymaga optymalizacji,
• hosting ma zbyt niskie limity,
• potrzebny jest mocniejszy pakiet,
• potrzebny jest VPS,
• wystarczy poprawić cache,
• trzeba zoptymalizować bazę.

Dobry audyt nie kończy się ogólnym stwierdzeniem „strona jest wolna”.

Powinien wskazać źródło opóźnienia.

Ile kosztuje poprawa szybkości?

Koszt zależy od problemu.

Prosta optymalizacja może obejmować:

• kompresję zdjęć,
• konfigurację cache,
• usunięcie zbędnych wtyczek,
• poprawę skryptów.

Bardziej rozbudowane działania mogą wymagać:

• przebudowy zapytań,
• optymalizacji bazy,
• zmiany motywu,
• migracji serwera,
• przebudowy aplikacji,
• konfiguracji VPS.

Nie zawsze warto kupować największy pakiet.

Czasami jedna poprawka w bazie daje większy efekt niż podwojenie parametrów serwera.

Koszty utrzymania różnych środowisk opisaliśmy w artykule [ile kosztuje utrzymanie strony internetowej miesięcznie](/blog/ile-kosztuje-utrzymanie-strony-internetowej-miesiecznie).

Audyt hostingu i szybkości w HeatLogic

W HeatLogic sprawdzamy zarówno serwer, jak i samą stronę.

Analiza może obejmować:

• czas odpowiedzi,
• wykorzystanie zasobów,
• limity hostingu,
• konfigurację cache,
• bazę danych,
• wtyczki WordPressa,
• procesy Node.js,
• logi,
• błędy,
• zdjęcia i zasoby frontendowe.

Na tej podstawie określamy, czy potrzebna jest:

• optymalizacja strony,
• zmiana pakietu,
• migracja,
• VPS zarządzany,
• monitoring,
• opieka techniczna.

Nie zakładamy automatycznie, że większy serwer rozwiąże każdy problem.

Celem jest znalezienie realnego ograniczenia i usunięcie go w sposób opłacalny dla firmy.

Usługa może być połączona z [hostingiem i opieką techniczną HeatLogic](/hosting-i-opieka).

Lista kontrolna wolnej strony

Sprawdź:

1. Czas odpowiedzi serwera.
2. Szybkość prostego pliku HTML.
3. Wynik strony bez cache.
4. Wynik strony z cache.
5. Limity CPU.
6. Wykorzystanie pamięci.
7. Użycie swapu.
8. Wolne miejsce na dysku.
9. Limity operacji dyskowych.
10. Wielkość bazy danych.
11. Wolne zapytania.
12. Aktywne wtyczki.
13. Rozmiar zdjęć.
14. Zewnętrzne skrypty.
15. Konfigurację cache.
16. Zadania cron.
17. Harmonogram backupów.
18. Ruch botów.
19. Logi błędów.
20. Wyniki monitoringu z różnych godzin.

Podsumowanie

Wolna strona nie zawsze oznacza słaby hosting.

Przyczyną może być:

• serwer,
• baza danych,
• kod,
• WordPress,
• wtyczka,
• zdjęcia,
• cache,
• zewnętrzna integracja.

Najlepszą decyzję można podjąć dopiero po wykonaniu pomiarów.

Jeżeli hosting regularnie osiąga limity i zwalnia przy większym ruchu, zmiana środowiska może być uzasadniona.

Jeżeli natomiast prosty plik odpowiada szybko, a problem dotyczy jedynie aplikacji, najpierw trzeba zoptymalizować stronę.

Nie warto płacić za większy serwer tylko po to, aby ukryć źle działający kod.

Twoja strona działa wolno i nie wiesz, czy winny jest hosting?

Skontaktuj się z HeatLogic. Sprawdzimy serwer, bazę, stronę i wykorzystanie zasobów, a następnie wskażemy, czy potrzebna jest optymalizacja, migracja czy mocniejsze środowisko.

Najczęściej zadawane pytania

Jak sprawdzić, czy hosting jest wolny?

Porównaj czas odpowiedzi strony dynamicznej z prostym plikiem statycznym, sprawdź limity zasobów oraz wyniki o różnych porach dnia.

Czy zmiana hostingu przyspieszy WordPressa?

Może pomóc, jeżeli obecny serwer ma niskie limity lub wolną bazę. Nie naprawi jednak ciężkiego motywu, dużych zdjęć ani źle działających wtyczek.

Jaki czas odpowiedzi serwera jest dobry?

Im krótszy, tym lepiej, ale wynik trzeba interpretować w kontekście rodzaju strony. Dynamiczny sklep będzie wymagał więcej pracy niż prosty plik HTML.

Czy VPS zawsze przyspieszy stronę?

Nie. VPS daje większą kontrolę i zasoby, ale źle skonfigurowany może działać gorzej od dobrego hostingu zarządzanego.

Czy duża liczba wtyczek spowalnia WordPressa?

Nie zawsze decyduje sama liczba. Jedna źle napisana wtyczka może powodować większe problemy niż kilkanaście lekkich dodatków.

Czy backup może spowalniać stronę?

Tak. Kompresja plików i eksport bazy zużywają zasoby. Backup warto wykonywać poza godzinami największego ruchu.

Czy monitoring pomoże znaleźć przyczynę?

Tak. Historia czasu odpowiedzi, zasobów i błędów pozwala powiązać spowolnienie z obciążeniem, backupem, importem lub awarią.