Skocz do zawartości
Diego164

Hosting z bardzo niskim TTFB pod WordPress z HTTP2

Rekomendowane odpowiedzi

Cześć

Szukam bardzo szybkiego hostingu pod WordPressa koniecznie z TTFB max 50ms w polskiej lokalizacji z protokołem HTTP2.

Edytowane przez Diego164

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Rozumiem, że zdajesz sobie sprawę z faktu, że TTFB nie zależy wyłącznie od hostingu? 

Nie zrozum mnie źle - jest wiele firm które technicznie są w stanie zapewnić niskie TTFB, ale tylko wtedy, gdy sama strona też jest doskonale zoptymalizowana.

  • Lubię 1
  • Super! 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Strona jest bardzo dobrze zoptymalizowana, nawet podstrony zwykle ważą ok 400kb ale i tak co nie zmienię hostingu, to TTFB wynosi raz 300ms a na innym już ok 2s... Jedyne co mi jest potrzebne to naprawdę szybki dobrze zoptymalizowany hosting.

Edytowane przez Diego164

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Obawiam się, że nie znasz za bardzo natury hostingu. Nieważne jak bardzo będziesz izolował klientów, to oni i tak zużywają zasoby całego serwera w różny sposób. A hosting, jak mówi jego definicja, to dzielenie zasobów między wielu klientów - firma musi zarobić (przez mniejszy lub większy overselling), więc oczywistym jest że klientów na 1 maszynie będzie wielu, a więc obciążenie będzie bardzo zmienne. Nawet jak trafisz na taki serwer z zerowym obciążeniem, to pewnie tylko dlatego, że firma nie zdążyła tam jeszcze wrzucić zbyt wielu innych klientów ;) Reasumując - chcesz mieć 100% pewnych zasobów, to kupuj serwer dedykowany (bo nawet na VPS możesz mieć sytuację j/w).

Inna sprawa, że ja chyba każdego dnia widzę te "doskonale zoptymalizowane wordpressy" złożone z 15 motywów i 50 pluginów ;)

  • Lubię 2

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
15 minut temu, Diego164 napisał:

Strona jest bardzo dobrze zoptymalizowana, nawet podstrony zwykle ważą ok 400kb ale i tak co nie zmienię hostingu, to TTFB wynosi raz 300ms a na innym już ok 2s... Jedyne co mi jest potrzebne to naprawdę szybki dobrze zoptymalizowany hosting.

 

Podaj adres strony na poparcie tej tezy :) TTFB zależy od wielu czynników, nie tylko związanych z samą wydajnością maszyn a np. odwołań zewnętrznych. Możesz mieć stronę o rozmiarze 100 kb z 1 pluginem tylko co z tego skoro ten plugin robi 120 requestów do zewnętrznych serwerów - póki nie odpowiedzą to TTFB będziesz miał taki, na jaki zasługujesz. Jeżeli Twój TTFB waha się od 300ms do 2s to najpierw sprawdź u źródła, w kodzie.

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Godzinę temu, Diego164 napisał:

Jedyne co mi jest potrzebne to naprawdę szybki dobrze zoptymalizowany hosting.

Mylisz się. Hosting serwujący plik - wynikowy kod HTML strony to nie wszystko.
Zainteresuj się CDN'ami pod statyczny kontent strony oraz dodatkowo Dns Anycast.
Dzięki CDN relatywnie odciążysz żądania HTTP do serwera głównego (PHP/Node.js etc...)

Edytowane przez Mion
  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
2 godziny temu, Kapitan_Bomba napisał:

 

 Inna sprawa, że ja chyba każdego dnia widzę te "doskonale zoptymalizowane wordpressy" złożone z 15 motywów i 50 pluginów ;)


Dokładnie o to chodzi. Z ciekawostek, miałem ostatnio klienta, który nie miał żadnych nadmiarowych wtyczek, ale motyw z którego korzystał łączył się do serwera aktywacyjnego aby potwierdzić legalność użytkowania, a nie mógł tego zrobić bo prace były wykonywane na niezgłoszonej nigdzie domenie testowej. Dojście do tej informacji chwilę zajęło, w międzyczasie oczywiście "zrób coś z tym serwerem, bo mam ttfb po 3 sekundy" ;)

 

Godzinę temu, Mion napisał:

Zainteresuj się CDN'ami pod statyczny kontent strony oraz dodatkowo Dns Anycast.
Dzięki CDN relatywnie odciążysz żądania HTTP do serwera głównego (PHP/Node.js etc...)


Po co się interesować CDNami na tym etapie? Wydaje mi się, że to znaczne wychodzenie "przed szereg", kompletnie zresztą niepotrzebne przy przeciętnej stronie i nie mające wiele wspólnego z TTFB na hostingu.  TTFB zwykle rośnie przez działanie interpretera danego języka (lub przez całkowite obciążenie serwera), a nie przez obsługiwanie plików statycznych.

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Przede wszystkim dobry cache musi być. W większości problem z TTFB będzie wszędzie.

 

U mnie WP z małą ilością wtyczek i szablonem kupionym bez optymalizacji z mojej strony a ttfb jest bardzo duży.

 

Warto też powiedzieć że ładowanie zewnętrznych elementów ma na to wpływ. U jednego klienta był problem np. z wtyczką fejsbuczka, który zamulał stronę bo za każdym razem skrypt musiał czekać aż on się załaduje a ładował się topornie.

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
10 minut temu, theqkash napisał:

Po co się interesować CDNami na tym etapie?

Po to, by uzyskać większą relatywną szybkość wczytywania strony jako całość, bo chyba o to w tym wszystkim chodzi, a nie tylko polepszyć czas wysłania pierwszych bajtów z serwera od przetworzenia kodu PHP liczony w milisekundach.  Przyśpieszenie samego WP z masa wtyczek jest IMHO  tym samym co trenowanie konia pociągowego do wyścigów.

16 minut temu, theqkash napisał:

(lub przez całkowite obciążenie serwera), a nie przez obsługiwanie plików statycznych. 

To według Ciebie serweer wysyłający mase plików statycznych wykonujących do tego operacje dyskowe nie jest przez to dodatkowo obciążany ? :D

Zwróć uwagę, że wodpress przeważnie ładuje masę plików CSS/ JS zwłaszcza taki  z wtyczkami.

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
24 minuty temu, Mion napisał:

Po to, by uzyskać większą relatywną szybkość wczytywania strony jako całość, bo chyba o to w tym wszystkim chodzi, a nie tylko polepszyć czas wysłania pierwszych bajtów z serwera od przetworzenia kodu PHP liczony w milisekundach. 


O jakim relatywnym wzroście szybkości mówisz? Na moje oko zarówno CDN jak i DNS Anycast to rozwiązania wybitnie nadmiarowe dla 95~99% serwisów, w praktyce nie dające wiele przy realnym użyciu poza ewentualnymi warunkami testowymi. Mając małą stronę która na dzień dobry generuje się pół sekundy i posiadającą 50-100 elementów statycznych plus jakieś zewnętrzne rozwiązania typu Facebook, Google Analytics, Hotjar, Callpage, zatosowanie zarówno CDN da zysk szybkości w granicach błędu statystycznego (choć często to są skrypty asynchroniczne oczywiście, ale opóźnienie wynikające z tych skryptów często uwidacznia się w narzędziach analitycznych). 

Dlaczego sugerujesz, że zastosowanie CDNa do każdej strony poprawi cokolwiek i jest warte rozważania? Moim zdaniem CDNa warto wprowadzić tylko wtedy jeśli serwujesz mnóstwo elementów statycznych i to do szerokiego grona odbiorców, w przeciwnym razie jest to zbędna inwestycja. 


DNS Anycast już kompletnie nie ma sensu jeśli skupiasz się na odbiorcach z jednego kraju i w tym kraju stawiasz DNSa, we wszystkich innych przypadkach zysk jest jednak stosunkowo niewielki.

 

24 minuty temu, Mion napisał:
40 minut temu, theqkash napisał:

 

To według Ciebie serweer wysyłający mase plików statycznych wykonujących do tego operacje dyskowe nie jest przez to dodatkowo obciążany ? :D

 

Oczywiście, że jest obciążany, ale w większości przypadków obciążenie wynikające z samego przesyłanie plików statycznych dla przeciętnej strony firmowej jest w granicach błedu statystycznego

 

24 minuty temu, Mion napisał:

Zwróć uwagę, że wodpress przeważnie ładuje masę plików CSS/ JS zwłaszcza taki  z wtyczkami.


Po to się stosuje scalanie tych plików w jeden plik i istnieją rozwiązania które robią to z automatu, nie trzeba tu CDNów, bo te i tak niewiele dadzą.

Edytowane przez theqkash
  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

No cóż, nie napisałem że się znam w tym temacie, ale dziwne wydaje się być to, iż ta sama strona na WordPress na różnych hostingach miała TTFB ok 400ms a na innym już ok 2000ms. Na tych przypadkach wyciągnąłem poprostu wnioski, że to wina hostingu. Szukam poprostu czegoś najszybszego pod jedną stronę na WP.

 

PS

Strona ma ok 30 zapytań/podstrona. W tym 8 zapytań na zewnętrzne (6 fontsgoogla, analytics i tagmanager)

 

http://prntscr.com/ltx848

Edytowane przez Diego164

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
4 minuty temu, theqkash napisał:

Dlaczego sugerujesz, że zastosowanie CDNa do każdej strony poprawi cokolwiek i jest warte rozważania? Moim zdaniem CDNa warto wprowadzić tylko wtedy jeśli serwujesz mnóstwo elementów statycznych i to do szerokiego grona odbiorców, w przeciwnym razie jest to zbędna inwestycja. 

No właśnie dlatego po co stworzono CDN by serwować pliki statyczne nie z serwera aplikacji jak najbliżej klienta.  Jak już pisałem i możesz sam sprawdzić patrząc w źródła WP lądują cała mesęplików CSS / JS do tego jeszcze liczne fonty., które muszą być przez serwer odczytane i wysłane itd...  Pliki z CDN w Warszawie do przeglądarki klienta w Polsce powinien przejść szybciej niż ten sam plik z serwera we Francji, a to już daje całkiem wymierne korzystności.

 

9 minut temu, theqkash napisał:

dla przeciętnej strony firmowej jest w granicach błedu statystycznego

Nie wiem co to jest statystyczny błąd dodatkowego obciążenia serwera.

 

 

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
8 minut temu, Diego164 napisał:

No cóż, nie napisałem że się znam w tym temacie, ale dziwne wydaje się być to, iż ta sama strona na WordPress na różnych hostingach miała TTFB ok 400ms a na innym już ok 2000ms. Na tych przypadkach wyciągnąłem poprostu wnioski, że to wina hostingu. Szukam poprostu czegoś najszybszego pod jedną stronę na WP.


Jeśli masz aż takie rozbieżności w TTFB sprawdź jakie TTFB będziesz miał dla strony statycznej umieszczonej na tych serwerach, a potem dla jakiegoś prostego skryptu napisanego w php, pozwoli Ci to już pewne wnioski wyciągnąć - dowiesz się bowiem czy ewentualne wysokie ttfb wynika z obciążenia ogólnego serwera lub z obciążenia wynikającego tylko i wyłącznie z działania interpretera skryptów.

Jeśli w obu przypadkach będziesz miał niewielkie czasy, podczas gdy wordpress będzie miał wysoki TTFB, rozważ w WordPressie instalację systemu cache'ującego który wygeneruje statyczne pliki z instalacji wordpressa i będzie je serwował dla odbiorców. 

 

 

4 minuty temu, Mion napisał:

Jak już pisałem i możesz sam sprawdzić patrząc w źródła WP lądują cała mesęplików CSS / JS do tego jeszcze liczne fonty., które muszą być przez serwer odczytane i wysłane itd...


CSS/JS się scala, a fonty i tak zwykle są brane z Google Fonts, który jak przypomnę jest zasobem zewnętrznym na którego wydajność masz niewielki wpływ.

 

 

4 minuty temu, Mion napisał:

Pliki z CDN w Warszawie do przeglądarki klienta w Polsce powinien przejść szybciej niż ten sam plik z serwera we Francji, a to już daje całkiem wymierne korzystności.


Nie znam chyba szanującego się polskiego hostingu (bo temat jest o hostingach) który miałby serwery we Francji. No i nadal nie rozumiem jak to się ma do TTFB o które było pytanie w temacie.

 

 

4 minuty temu, Mion napisał:

Nie wiem co to jest statystyczny błąd dodatkowego obciążenia serwera.


Przeczytaj dokładnie i ze zrozumieniem to co napisałem, bo chyba gdzies się zagalopowałeś 🙂

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
1 minutę temu, theqkash napisał:

Jeśli masz aż takie rozbieżności w TTFB sprawdź jakie TTFB będziesz miał dla strony statycznej umieszczonej na tych serwerach, a potem dla jakiegoś prostego skryptu napisanego w php, pozwoli Ci to już pewne wnioski wyciągnąć

Dla WP IMHO jedynym sensownym rozwiązaniem jest wszechstronne cache, bo wykonywanie kodu PHP skryptów składowych WP jest bardzooo długotrwałe, a im więcej wtyczkę tym gorzej i nic z tym nie zrobisz. Do WP są też wtyczki do CDN'ow.

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
7 minut temu, Mion napisał:

Dla WP IMHO jedynym sensownym rozwiązaniem jest wszechstronne cache, bo wykonywanie kodu PHP skryptów składowych WP jest bardzooo długotrwałe, a im więcej wtyczkę tym gorzej i nic z tym nie zrobisz.


Są systemy cache'ujące które generują wynikowy plik html dla każdej z podstron i serwują go klientowi za pomocą htaccess'a, co jest moim zdaniem najbardziej korzystną z punuktu widzenia wydajności opcją, choć oczywiście nie uniwersalną. 

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

TTFB to sporo czynników, jeżeli chce się uzyskać najlepszy, a strona jest regionalna to szukamy dostawcy z bardzo dobrym łączem, np. w Polsce OVH.

Dalej tego WP przerabiamy w mocno statyczną wersje i można tu użyć modułów jak np. wp supercache.

Strony mamy więc w HTML i wystarczy załatwić szybki serwer WWW który poda pliki HTML przed PHP ( dla niezalogowanych ).

Tu najlepsze czasy generuje Nginx i wystarczy mu wklepać kilka linijek konfiguracji by działał jak z stroną HTML.

 

Warto też mieć na uwadze szybkość dysków, bo jednak musimy z nich czytać dane.

 

Reasumując zestaw sobie na test VPS z SSD w takim OVH i sklep prosty setup Nginx + PHP 7.2 FPM, MariaDB, a do tego cache supercache z konfiguracją po stronie Nginx.

 

Ciężko znaleźć szybsze rozwiązanie pod serwowanie WP :)

  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

No i w miarę możliwości oferowanych przez hosting ustaw najnowsze wersje PHP o ile wtyczki Twojego WP na to pozwalają.
Dodatkowo proponuję zobacz co Google ma do powiedzenia na temat Twojej strony : https://developers.google.com/speed/pagespeed/insights/?hl=pl

Edytowane przez Mion
  • Lubię 1

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się

  • Przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników, przeglądających tę stronę.

×

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.