Ultimátní test webhostingů – Rychlost načtení WordPress po nasazení jednoduché cache v2

U minulého dílu jsem narazil na několik závažných připomínek, kvůli kterým jsem musel testování opakovat. Po zveřejnění, že se pouštím do opakování jsem dostal řadu ohlasů, návrhů ke konzultaci a tipů jak se vyhnout problémům. Musím říct, že mě hodně překvapilo, jak náročné je tyto uživatelské testy dělat a vyhnout se možným problémům se zveřejněním výsledků. Na druhou stranu mě také potěšilo jak velký je o tyto detailní testy zájem. Dokonce jsem dostal dva návrhy, že bych je mohl dělat na zakázku pro soukromé účely. Jeden z toho byl celkem zajímavý.

Co se muselo změnit, aby se opět někdo nenaštval

Předně z testů bude muset zmizet tabulka, kde budou hostingy řazeny podle podle jakýchkoliv čísel a to i přesto, že jsou čísla podložena konkrétní a detailně rozepsanou metodikou. Místo toho budou hodnoceny “pocitově”. Prostě průměr a medián nahradí hodnocení písmeny A, B, C, D a E, protože je snadnější obhájit jaký z toho mám pocit, než že někde vyšlo konkrétní číslo z desítek měření. Samozřejmě aby testování mělo smysl, tak písmena postavím na číslech, jen se to prostě musí tvářit “pocitově” 🙄

Rozhodně mám zapomenout na nějaká open data, což mě velmi mrzí. Chtěl jsem výsledky měření publikovat ve strojově čitelné formě a každý kdo by měl zájem, by si je mohl stáhnout a napsat vlastní článek. Jednak bych tím získal autoritativní zpětný odkaz, ale hlavně zpracovat a číst data umí každý jinak. Někdo by si to spojil s vlastním měřením a mohl třeba zjistit jaký vliv má konektivita, CPU, značka, verze PHP, webserver atd. Samozřejmě nemám na mysli test jako je tento, ale už po nocích vyvíjím vlastní WP plugin, který bude umět automaticky sbírat hodně zajímavá data. Takže se nebavíme o desítkách měřeních ale o tisících, klidně i desítkách tisíc.

Ještě jedna zajímavost. Open data by mě mohla dostat před soud, kde by bylo zdlouhavé vysvětlit soudci, že protistrana třeba nemá ponětí jak funguje cachovací plugin a i když bych to vyhrál stálo by to hodně mentálních sil, což by mě znechutilo. Ovšem pokud bych všechna data měření prodal pod NDA (smlouva o mlčenlivosti) třeba soukromé firmě, co vypracovává podklady pro investory a těm kdyby se nelíbila, tak je daleko snadnější vysvětlit metodiku. Bylo by to na úrovni argumentů o konkrétním problému. Tohle byl jeden z ověřených tipů co jsem dostal.

Jinými slovy všechno se musí tajit až dokud nepůjde do tuhého. Všechna měření samozřejmě archivovat a to včetně logů atd. Nikomu je bez NDA nedávat. Pokud by došlo na soud, tak předložit až tam jako důkaz. Blbí? Další řešení je anonymní profil a doména .onion na dark netu. V ČR si prostě musíte hlídat zadek 😅

 

Metodika

Před spuštěním byla každá instalace aktualizována na poslední verzi WordPress (5.2.2) a s nejnovější verzí PHP, kterou hosting veřejně nabízel k 1.6.2019. Dále pokud hosting nabízel v ceně či s příplatkem do 50 CZK, HTTPS bylo toho využito a to včetně HTTP/2.

Testování probíhalo na nástroji tools.pingdom.com, kde se měřil celkový čas načtení stránky z lokality Europe – Germany – Frankfurt. Tuto lokalitu jsem vybral, protože z dlouhodobého hlediska vždy test proběhl nejrychleji. Celkový čas znamená načtení všech prvků na stránce. Vzhledem k tomu že testovací instalace WordPress byly čisté, bez grafiky a jen se základní šablonou Twenty Nineteen.

Celkem se jednalo o malé množství requestů (8) i objem dat (44,8 KB).

 

Každý instalace WordPress v době testu obsahovala následující aktivní pluginy:

• Query Monitor
• WEDOS OnLine monitoring
• Wordfence Security
• WP Fastest Cache

WP Fastest Cache jsem zvolil protože v testu z prosince 2018 dosáhl nejlepších výsledků u Wedos, ovšem z reakcí čtenářů jsem se dozvěděl, že dosahuje skvělých výsledků i jinde. Plugin byl aktivován a nastaveno u něj pouze aby cachoval. Tedy to co by udělal nezkušený uživatel.

Weby jsou pod kontrolou dostupnosti UptimeRobot (každých 5 minut) a Wedos OnLine (každou 1 minutu). Takže i kdyby se plugin rozhodl smazat cache (což neměl nastaveno), tak by se obnovila.

Testování probíhalo od 01.8.2019 do 03.09.2019. Celkem bylo provedeno 30 započtených měření, které splňovali podmínky. Čas byl vybrán náhodně, respektive kdy jsem zrovna měl čas to spustit. Je třeba si uvědomit, že každé měření zabralo 5 – 20 minut. Nástroj tools.pingdom.com má totiž interní limit na testování. Občas jsem také musel testování přerušit, abych pracoval na něčem jiném. Celé testování a napsání článku zabralo mnoho hodin času.

Při testování jsem se vyhnul celým hodinám a půlhodinám, kdy ostatní zákazníci na sdíleném fyzickém serveru často spouští skripty přes CRON anebo se aktivuje WP-Cron. Tyto skripty mohou být značně náročné a ovlivnit výsledek až o desítky ms.

Pokud při testu vrátil nástroj delší dobu než bylo 1000 ms, tak jsem toto měření ignoroval a opakoval jej. Toto pravidlo jsem si dal už na začátku měření. Důvodem bylo vyhnout se náhodnému přetížení, které by mohlo být způsobeno útokem anebo nějakou činností na serveru (například zálohování, reset atd.). Vzhledem k tomu že pracuji s průměrem, tak by započtení takovéhoto měření značně zkreslilo výsledek.

Seznam testovacích webů

Ještě uvádím seznam testovacích webů, hostingů a aktuální konfigurace v době testu. Pořadí bylo určeno na začátku Ultimátního testu webhostingů podle aktuálního počtu hostovaných .cz domén. V tomto pořadí jsou také rozepsány výsledky testu.

Doména	Kde	WordPress	PHP	DB	Table	HTTPS	HTTP/2
badrequest.eu	WEDOS	5.2.2	7.3.1	5.5.5-10.1.37-MariaDB	InnoDB	ANO	ANO
connectionfailed.eu	FORPSI	5.2.2	7.3.1	5.6.42-84.2	InnoDB	NE	NE
connectiontimedout.eu	ACTIVE 24	5.2.2	7.3.6	5.5.5-10.3.15-MariaDB	InnoDB	ANO	ANO
expectationfailed.eu	Web4U	5.2.2	7.3.5	5.5.5-10.1.37-MariaDB	InnoDB	NE	NE
gatewaytimeout.eu	Savana	5.2.2	7.3.4	5.5.5-10.2.23-MariaDB	InnoDB	NE	NE
generalfailure.eu	ONEbit	5.2.2	7.2.19	5.7.25	InnoDB	NE	NE
internalservererror.eu	Gigaserver	5.2.2	7.2.14	5.7.24-27	InnoDB	ANO	NE
requesttimeout.eu	Station	5.2.2	7.3.3	5.5.5-10.3.12-MariaDB	InnoDB	NE	NE
serviceunavailable.eu	Nethost	5.2.2	7.3.6	mysqlnd 5.0.12-dev	InnoDB	NE	NE
unknownerror.eu	TELE3	5.2.2	7.2.13	5.5.5-10.0.37-MariaDB-1	InnoDB	ANO	NE
webserverisdown.eu	EBOLA	5.2.2	7.3.1	5.7.21-log	InnoDB	ANO	ANO

Jak funguje WP Fastest Cache

WP Fastest Cache v základním nastavení řeší jen cache v “backendu”, to znamená že nijak nepomáhá prohlížeči. Právě naopak.

1. V .htaccess je řada podmínek, které určí zdali návštěvník uvidí cache (nepřihlášený uživatel, cachovatelný obsah, robot atd.)
2. Pokud je podmínka splněna, uživatel je přesunut na soubor /wp-contenet/cache/all/nazev-clanku/index.html části článku pod ním jsou pak v  /wp-contenet/cache/all/nazev-clanku/casti-clanku/index.html  (části článku jsou třeba stránky s komentářem anebo mediálním souborem).
3. Pokud jakákoliv podmínka splněná není, tak uživateli se normálně vygeneruje stránka v PHP.
4. Cachovaný soubor je kompletní html stránkou, proto je WP Fastets Cache tak rychlý – prakticky přes .htaccess jen přesměruje návštěvníka na html stránku. Tato stránka je ukončena komentářem, kdy byl cachovaný soubor vytvořen a jak dlouho trvalo jí vygenerovat.
5. Uživateli se vrátí tedy html soubor ovšem s hlavičkou, že si obsah nemá ukládat do cache prohlížeče.

Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Mon, 29 Oct 1923 20:30:00 GMT"

Tento header však mohou prohlížeče ignorovat, případně jim to může webserver poslat jinak.

WP Fastest Cache je tedy vlastně jednoduchý plugin. Pokud neexistuje cachovaná verze stránky, tak vytvoří html soubor s obsahem a na ten pak přes .htaccess přesměrovává obsah.

Problém je v tom, že to nemusí vždy dělat správně. Zadrhnou se to může kdekoliv. Takže i když ukazuje komentář v html stránce, že obsah je cachován, tak ve skutečnosti být nemusí, což byl případ Active 24, kde bylo nutné udělat úpravu .htaccess. Dále vše funguje za předpokladu, že jsou splněny všechny podmínky pro přesměrování.

Jinak vzhledem k tomu, že vše je na úrovni .htaccess a přesměrování na html stránku, tak se do toho vlastně vůbec nezatahuje WordPress, což pro řadu pluginů může být velký problém.

Naopak tento plugin skvěle funguje všude, kde si vystačíte se statickým obsahem a nemusíte přihlašovat uživatele, abyste jim zobrazili individuální obsah.

Jak hodnotím

• Zvládnutí tohoto testu je oznámkováno A, B, C, D, E a nezvládnutí F.
• Základem je průměr a medián z 30 testů.
• Hostingy testované přes HTTPS mají bonus -22 ms, toto číslo vzniklo na základě mediánu času navázání SSL spojení potřebného pro stahování txt souboru z 5 webhostingů.
• Známku také mohou ovlivnit použité technologie, výskyt problémů, podezřele extrémní hodnoty, (ne)přítomnost anomálií, výsledky z předchozích měření (polepšil se, zhoršil se).

Tabulka hodnocení v ms:

	HTTP	HTTPS
A	1 – 175	1 – 197
B	176 – 200	177 – 222
C	201 – 225	223 – 247
D	226 – 250	248 – 272
E	251 – 300	273 – 322
F	Nad 300	Nad 322

Proč právě tato čísla? Průměrná reakční doba člověka na vizuální vjem je prý 250 ms. Řekl jsem si že to je fajn číslo a odsud budu dávat E. Zbytek známek bude rovnoměrně rozdělen. Jak se ukázalo tak nakonec jsou známky D, E a F u testovaných českých webhostingů zbytečné. Což není překvapivé, protože z toho co jsem mohl zatím vyzkoušet, tak zahraniční konkurenci hravě strčí do konkurencí jak výkon, parametry tak i cenou.

Koloběh zaplňování serverů

Než se pustíme do hodnocení jednotlivých služeb rád bych ještě zmínil jednu důležitou věc, kterou Ultimátní Test Webhostingů dokáže odhalit, a to je co bude s vašim webem až se zaplní server. Běžný koloběh zaplňování fyzických serverů, který má velký vliv na rychlost je totiž následující:

• Nový fyzický server – když si koupíte novou službu, tak jste umístěni většinou na nový server, který se zaplňuje. Vše je rychlé, protože fyzický server je poloprázdný, většina dalších zákazníků teprve svůj projekt rozjíždí anebo třeba nikdy ani nerozjede.
• Naplněný fyzický server – server je zaplněný podle nějakých parametrů, které používá hosting. Může to být počet zákazníků, celkové množství využitého místa, vytížení CPU, protože se rozhodli atd. Dalším zákazníkům se už zřizují služby jinde. Teď se většinou začínají postupně objevovat nějaké problémy.
• Přetížený fyzický server – zákazníkům se weby rozbíhají, často stačí špička a chyby jsou na denním pořádku. Chyby často ani nepostřehnete, protože se objevují nahodile. Stačí však projít error log anebo mít důslednější měření a víte že něco není v pořádku.
• Čištění fyzického serveru – Hosting si všimne, že něco není v pořádku v horším případě na něj začnou tlačit zákazníci. Většinou identifikuje “přetěžovače” a rozhodne se s nimi něco dělat. Někde jim jen napíšou a pohrozí, jinde omezí (viditelně anebo skrytě) a jsou i hostingy, které je přesunou na “trestanecký server”, aby neomezovali ostatní.
• Klidný server – Po vyčistění je server zaplněný, ale stabilní. Chyby většinou zmizí a vše jede v pohodě. Časem postupně ostatní zákazníci odpadávají ostatním se zase začne dařit, ale ve výsledku vládne pořádek. Zůstanou lidi co si umí své skripty optimalizovat a vládne klid. Občas k vám někoho přemigrují, protože mu vadí že je zrovna na přetíženém serveru.

Jak dlouho jednotlivé fáze trvají záleží na fyzickém serveru (velký, malý) jak je hosting řešen (externí úložiště/databáze anebo localhost) a hlavně jak je velký. Největší hostingové společnosti mají velký přírůstek nových webhostingů, takže zaplní fyzický server rychle. Jednotlivé fáze mohou být také rychlejší. Jak klidný server bude ovlivňuje i finanční stránka věci. Ti co mají peníze mohou nechat i poloprázdný server, protože chtějí spokojené zákazníky, případně jim prodat další služby.

Mimochodem tohle je také jeden z důvodů proč kupovat nový webhosting, když je velká akce. Často ze zaplní rychleji a spousta lidí ani projekt nerozjede 😉

Výsledky jednotlivých hostingů

Konečně se můžeme dostat k samotným výsledkům testů. Opakuji že všechny hostingy si vedli v testování opravdu skvěle a můžeme na ně být opravdu hrdí. Hostingy jsou seřazeny podle počtu hostovaných domén v době začátku testu.

Wedos

Wedos prodává nejvíce webhostingů NoLimit, čímž se rád často chlubí. Jejich fyzické servery se tak velice rychle zaplní. Tuším že další webhosting jsem zřizoval dva měsíce po začátku testu a id serveru bylo o čtyři vyšší. Test už tak probíhal na naplněném fyzickém serveru. Podle grafu zhruba v 1/4 testování došlo k jeho čištění a rychlost se tak ustálila.

U Wedos bylo provedeno celkem 30 plnohodnotných měření. Web na Wedos má HTTPS. Minimum bylo 182 ms, maximum 322 ms (rozdíl 140 ms), což je druhý nejlepší rozdíl z testovaných. Rozdíl mezi mediánem a průměrem byl 10 ms. Wedos jak za průměrem i medián dostal známku B.

Nutno připomenout že Wedos používá v cestě ještě DDoS ochranu, IPS/IDS ochranu a Proxy servery, které mu mohou nějaké ms ubrat. Za ochrany jsem rád a klidně pro ně i pár desítek ms obětuji. U některých webů mi blokují až 90 % zbytečných přístupů, které by jinak přetěžovali servererové prostředky. Proxy servery neumí WP Fastest Cache pro cachování obsahu využívat.

Wedos podal velmi dobrý výkon. S výjimkou testu 01.08.19 10:23 nepřesáhl ani jednou 300 ms.

Forpsi

Forpsi patří také k nejznámějším hostingům v ČR. Sdílený webhosting Webhosting Easy je často propagován v reklamách. Předpokládám že server už bude také ve fázi plný fyzický server. Podle grafu to vypadá, že na fázi čištění ještě čeká.

U Forpsi bylo provedeno celkem 30 plnohodnotných měření. Minimum bylo 167 ms a maximum 397 ms (rozdíl 230 ms). Z grafu to vypadá že se trochu zpomaluje, ale těžko soudit když jde o ms. Osobně to přisuzuji tomu, že weby zákazníků na fyzickém serveru rostou (množství souborů v adresářích, databáze, počet přístupů) a v průměru jsou pak o pár ms pomalejší. Za medián i průměr dostal Forpsi známku C.

Server Forpsi jel začátek srpna opravdu dobře, ale od 24. srpna už to ve většině případů bylo nad 220 ms, což pokazilo jak průměr, tak i medián.

Active 24

Webserver Active 24 měl problém s pluginem WP Fastest Cache a bylo nutné upravit .htaccess, tak aby fungoval. Matoucí je, že WP Fastest Cache se tváří že cachuje. V každém případě v této sadě testů jsem se ujistil, že vrací správně cache z roku 1923 🙂 U Active 24 bylo provedeno celkem 30 započtených měření.

Active 24 jel až na jednu výjimku celou dobu velice slušně. 30.08.19 v 03:13 mi tam vyskočila špička 443 ms. Zajímavé bylo, že se nejednalo o problém s PHP, prostě se čekalo na soubory s CSS a JavaScript. Pro zajímavost přikládám screenshot z měření. Podobná špička se pak už u dalších měření neobjevila.

Minimum bylo 150 ms a maximim 443 (rozdíl 263 ms). V každém případě medián i průměr měl Active 24 opravdu skvělé a po započtení bonusu za HTTPS se si zaslouží A. Asi více není co dodat.

Active 24 podával po celou dobu měření dobrý a velice vyrovnaný výkon. Rozdíl mezi průměrem a mediánem byl 9 ms.

Web4U

U Web4U jsem si téměř jistý, že jede na localhostu (úložitě i DB), což vyhovuje rychlosti a právě těmto testům.

Web4u měl při měření 04.08.19 v 09:23 nejrychlejší test ze všech 123 ms maximum bylo 288 ms (rozdíl 165 ms).

Web4U měl ze všech hostingů nejrychlejší medián i průměr. Je tedy vítězem tohoto testu. Jako jediný také měl medián pod 150 ms.

V předchozím testu měl Web4U těch špiček více a větších, proto mu spadl průměr. Medián však měl i před dvěmi měsíci nejlepší. Cachovanou prezentaci tak zdládl ze všech nejlépe. Uvidíme jak si poradí s většími výzvami 😉

Savana

Vypadá to že u Savana jsme ve stádiu zaplnění serveru a projekty ostatních pekně rostou. Podle grafu se vše o pár ms postupně zpomaluje. Ale podobně jako Web4U i u Savana jede vše na localhostu a je to znát.

Savana měla minimum 127 ms a maximým 260 ms (rozdíl 133 ms), což je nejnižší rozdíl ze všech. I přes špičky na grafu a viditelné zpomalení je v testu druhá a to jak v průměru, tak i v mediánu.

Savana už v minulém testu podala velmi dobrý výkon. Opakovaný test, tak potvrdil předchozí výsledky. Přišlo mi že dokáže velmi rychle servírovat prohlížeči statické soubory, což v tomto testu bylo rozhodující. V některých testech dokonce nejvíce času spotřeboval dotaz na DNS. No uvidíme jak si poradí s opravdovou výzvou, když WordPress bude plný dat.

OneBit

U OneBit se jeden test nepodařilo dokončit, proto data vychází z 29 měření. Důvodem bylo že test nedokázal stáhnout data ze serveru. OneBit začátkem srpna nepodával zrovna ideální výsledky. Což se u testů kolem 25. srpna změnilo. Je možné že na fyzickém serveru byl nějaký přetěžovač anebo to prostě vyčistili.

Minimum bylo hezkých 159 ms maximum 382 ms (rozdíl 223 ms). Různé špičky se také podepsaly na velkém rozdílu mezi průměrem a mediánem, což bylo 15 ms. U OneBit se občas objevovaly prodlevy ve stahování obsahu. To vidíte například níže v nezapočteném testu.

Průměr řadí OneBit do známky C, medián na hranici spíše do B. Pokud přihlédnu k problémům se stahováním rozhodl jsem se dát C. Vliv na to má i zhoršení průměru a mediánu oproti předchozímu měření.

OneBit se nám po 2 měsících trochu zhoršil. Ovšem stále se bavíme o testu který v podstatě testuje přesměrování přes .htaccess na html stránku. Tedy čistě statický obsah. Uvidíme jak si povede, když půjde o pořádný obsah.

Gigaserver

Gigaserver je jedním z důvodů proč se testování opakuje, takže jsem si dobře hlídal jestli cachování funguje. Celkem bylo započteno 30 testů. Podle grafu je vidět, že na serveru mírně přibývá zátěž. Výkon je víceméně vyrovnaný, narazil jsme jen na dvě špičky 13.08.19 v 16:16 (271 ms) a 30.08.19 v 09:43 (562 ms).

Minimum bylo velmi slušných 142 ms, maximum pak 562 ms (rozdíl 420 ms). Což by nevadilo, nějakou tu špičku najdete u každého zvláště když měříme v něčem tak malém jako jsou ms.

Po započtení bonusu za HTTPS dostanou Gigaserver známku B za průměr i medián.

Oproti minulému testu jsem už nezaznamenal žádné dlouhé prodlevy. Všechny testy šly přes .htaccess přímo na html soubor, takže cachování fungovalo. Uvidíme co ukážou pokročilé testy.

Station

Station také jede na localhostu a proto mu také tento test vyhovoval. Je škoda že se jednou za čas objevily špičky a zkazily průměr. Fyzický server Station totiž dokázal občas příjemně překvapit. Třeba 12.08.19 v 09:56 vytáhl rychlost 132 ms, což je třetí nejlepší čas.

U Station bylo minimum 132 ms a maximum 357 ms (rozdíl 225 ms). Mezi špičkami jsem nenašel žádnou spojitost. Různé dny i denní doba. Možná tam mají nějakého zlobivce 🙂

Mimo špiček jsem na žádný problém nenarazil, takže hodnotím jen podle průměru a mediánu, který Station řadí do známky B.

V minulém testu bylo o dost více špiček. Je tak možné že u Station už nějakou čistku provedli. Obecně můžu říct že Station to kazí jen ty špičky. Většina měření je pod 200 ms.

Nethost

Nethost jel ze začátku měsíce opravdu skvěle, skoro mi to přišlo že jsem na serveru sám 🙂 pak se objevily nějaké menší turbolence a opět vše šlapalo. Mimochodem během tří testů 28. – 29.8 vyšlo za sebou 3x 180 ms. Úžasná náhoda. Bohužel poté testem 29.08.19 v 10:47  se začaly objevovat špičky.

Minimum u testu Nethost bylo 152 ms a maximum 385 ms (rozdíl 233 ms). Kvůli rozhozeným špičkám na konci testování je rozdíl mezi průměrem a mediánem 27, což je nejvíce ze všech testovaných webhostingů. Průměr je tak v C a medián v B. Vzhledem k tomu, že tendence je však zhoršující dávám známku C.

Nethost bylo příjemné nostalgické překvapení celého ultimátního testu. Vypadá to že na serveru mají nějakého zlobivce. Uvidíme jak to pořeší.

Tele3

TELE3 je řekněme velice zvláštní hosting. Z několikaměsíčního omezeného testování bych je hodnotil jako zkušené lowcostaře.  Prostě to umí nastavit, připravit, jede to a je to levné. Občas to zazlobí je výpadek, ale pak to zase jede jakoby se nic nedělo.

TELE3 je localhost a využívá toho na maximum. Minimum bylo 132 ms a maximum 301 ms (rozdíl 169 ms). Tedy stejně jako Station mají 3. nejrychlejší čas, ale pozor. Do toho všeho je třeba započítat i HTTPS, kam se s cenou 50 CZK dostanete. Takže TELE3 webhostingu Na míru patří v tomto testu nejrychlejší webhosting s HTTPS. Asi tedy nikoho nepřekvapí že by se dostal do A i bez bonusu.

Jak jsem psal výše. Jede to dobře, rychle, levně a občas to zazlobí, nahodí to a jede to zase dobře, rychle a hlavně levně 😉

Ale uvidíme jak si poradí až dojde na pořádné testy.

Ebola

Přiznám se, že začátek měsíce jsem si říkal, co se s mou oblíbenou Ebolou stalo. Později se to trochu zlepšilo, ale nebylo to úplně ono. Nevím jestli je to plnějším fyzickým serverem, ale těch měření nad 250 ms bylo 20 %.

Přitom nejrychlejší test zvládl server Ebola za krásných 147 ms a to není žádný localhost. Maximum pak bylo 491 (rozdíl 344 ms). Že to není ono bylo znát z rozdílu mezi průměrem a mediánem 17 ms, což je druhý nejhorší výsledek. Po započetení bonusu za HTTPS se však nadoraz vlezla Ebola do známky B.

V srpnu byla Ebola plná extrémů. 20 % testů bylo nad 250 ms a 40 % pod 200 ms. No uvidíme, třeba to jen někdo přetěžuje.

Zajímavosti

Na konec ještě pár zajímavostí, které z testů vyplynuly.

• Nejrychleji zvládl test přes HTTP splnit WEB4U a to 19.08.19 v 09:43 za 123 ms
• Nejrychleji zvládl test přes HTTPS splnit TELE3 a to 12.08.19 v 09:56 za 132 ms
• Nejmenší rozdíl mezi minimem a maximem přes HTTP měla Savana a to 133 ms.
• Nejmenší rozdíl mezi minimem a maximem přes HTTPS měl Wedos a to 140 ms.
• Nejtěžším dnem pro všechny webhostingy byl ten v pátek 30.08.19 v 09:43. Průměr ze všech webhostingů byl 235  ms.
• Nejlehčím dnem byla naopak sobota 17.08.19 v 08:33, kdy byl průměr 170 ms.
• Nejrychleji dokázal odbavit SSL komunikaci Active 24, z 10 měření stahování .txt souboru mu zabrala v průměru 17,74 ms. Tento test proběhl samostatně, abych zjistil jaký bonus zhruba dát webům s HTTPS.
• Cachování WP Fastest Cache se tvářilo že funguje ale nefungovalo u 9 % hostingů.
• Ze zvědavosti jsem zkusil provést test 24.08.19 v hluboké noci 3:33. Překvapivě s ním měl nějvětší problém TELE3 (293 ms). Je možné že zrovna probíhala záloha. U ostatních byl provoz víceméně průměrný.
• Nethost dal 3 testy za sebou 180 ms.

 

Závěr

Rád bych tento test uzavřel s tím, že všechny hostingy podali skvělý výkon. Podle testu tools.pingdom.com dokážou v průměr i mediánu zobrazit prázdný WordPress s nainstalovaným a zapnutým pluginem WP Fastest Cache rychleji než mrknete a to doslova. A to se bavíme často o tarifech, které nejsou primárně určeny pro WordPress. Od toho mají jednotlivé hostingy vlastní varianty anebo nabízí dražší alternativy.

 

---