Problém s rychlostí webu u http a https
už se dlouho plácám s jedním problémem u webu na doméně www.e-cons.cz , kde řeším problém s rychlostí načítání stránky www.e-cons.cz/ereporting.html . Web jede na Joomle 3.8.7, hostng WEDOS, PHP 7.0.
V čem je problém - verze s https je cca o 4 vteřiny pomaleji načtená než verze s http - a to u prvního načtení.
Co může ovlivnit to, že z verze s https se např. lokálně uložené js a css soubory načítají přes 1 sekudnu, ale u http verze jsou časy řádově do 100 ms?
Je možné, že by ověřování certifikátu až tak ovlivnilo rychlost webu?
Tady jsou výsledky testu (testováno na webpagetest.org)
- s https - www.webpagetest.org/result/180525_FJ_21a...1583559b08d163a53fe/
- bez https - www.webpagetest.org/result/180525_DC_0fc...9299bc43282a4eb21fb/
Díky za každé nakopnutí správným směrem.
Dokonce i vlastní generování stránky (step 1) je u https 2x delší a trvá skoro 4 vteřiny.
Web je postaven na šabloně od WarpTheme - a ti používají tuším framework UiKit.

publib.boulder.ibm.com/tividd/td/ITAME/S.../HTML/ss7aumst18.htm
Hlavně je to problém, když se posílá hodně malých dotazů (oproti jednomu velkému).
Phoca Cart - www.phoca.cz/phocacart - e-shop, e-commerce
Phoca Gallery - www.phoca.cz/phocagallery - obrázková galerie
Phoca Download - www.phoca.cz/phocadownload - stahování souborů
Phoca Guestbook - www.phoca.cz/phocaguestbook - guestbook

SSL má v tom grafu vlastní kolonku, ukazuje jim to 112 ms, mně nějakých 22.
Pingdom také nedopadá tak špatně
tools.pingdom.com/#!/dGyzBa/https://www....s.cz/ereporting.html
H13 napsal: No, většinou je za to zodpovědný tzv. handshake - prostě u https dochází k šifrování (to už je .......
Hlavně je to problém, když se posílá hodně malých dotazů (oproti jednomu velkému).
Takže z tohoto pohledu je lepší, když by se minimalizoval počet stahovaných souborů (js a css soubory z modulů a šablony) do co nejmenšího počtu?
U http připojení mi právě příjde lepší, když jich je více malých a stahují se paralelně ve více vláknech, než mít jeden velký a čekat, než se stáhne tento....ale může to být jen subjektivní dojem.
Škoda, že se na srazu vypustilo to téma přechod z HTTP na HTTPS

Ještě jednou díky všem.

webpagetest pro http:
www.webpagetest.org/result/180529_T0_f50...b999061543f70b0d182/
webpagetest pro https:
www.webpagetest.org/result/180529_B7_87e...dffd847e9b52ba8f34d/
Rozdíl v rychlosti je minimální, nicméně kde jsem schopen to ještě narychlit? Jediné, co mne napadá, tak stáhnout fonty z fonts.google.com a nechat je lokálně. Slučování css a js souborů do jednoho vzhledem k použití šablony asi nepřichází v úvahu - nebo je na to nějaká cesta, jak to narychlit?
Díky za tipy.

Pravděpodobně ano, protože jestli u každého souboru dochází k výměně informací, může to dělat rozdíl.Takže z tohoto pohledu je lepší, když by se minimalizoval počet stahovaných souborů (js a css soubory z modulů a šablony) do co nejmenšího počtu?
To bych nedělal, osobně si myslím, že se ty fonty z Google serveru stáhnout do uživatelova počítače rychleji než z tvého serveru (100% to tvrdit nebudu, protože jsem testy nedělal).Jediné, co mne napadá, tak stáhnout fonty z fonts.google.com a nechat je lokálně.
Zkoušel jsi zapnout například GZIP komprimaci?
Phoca Cart - www.phoca.cz/phocacart - e-shop, e-commerce
Phoca Gallery - www.phoca.cz/phocagallery - obrázková galerie
Phoca Download - www.phoca.cz/phocadownload - stahování souborů
Phoca Guestbook - www.phoca.cz/phocaguestbook - guestbook

Nginx jako reverzní proxy pro Apache
Reverzní proxy
Měl jsem to na vlastním VPS. Běžel tam CentOS, Nginx jako reverzní proxy, Apache. Odezva byla super


Pozor, tohle nedělá HTTPS ale HTTP/2, pro který je ovšem HTTPS nutnou podmínkou. Nicméně e-cons HTTP/2 má.Martens napsal: U http připojení mi právě příjde lepší, když jich je více malých a stahují se paralelně ve více vláknech, než mít jeden velký a čekat, než se stáhne tento....ale může to být jen subjektivní dojem.
Obávám se, že ještě se do toho započítává načtení cca 20 souborů z webu smatsupp.com (formulář pro on-line chat), kde mi to dělá cca 1,5-2 vteřiny.
A existuje něco (plugina), jak u modulárního CMS systému, kde si jeden každý modul či komponenta tahá své js a css soubory, která je sloučí do jednoho?
U těch fontů mi to ukazuje, že se tahají cca 390ms, z toho 61ms je vlastní stažení fontu a zbytek navazování komunikace. Zatím to taky nemám vyzkoušené, tak je to spíš otázka, zda a jaká by vůbec byla úspora času.
Další věc, co mne napadá - klient uváděl, že v loňském září byla rychlost načtení cca 4 vteřiny - tehdy běželi na https přes Let's encrypt, ale od listopadu 2017 mají přímo obchodní certifikát od jiné certifikační autority. Může na to mít vliv i toto?

Pluginy slučující CSS a skripty do jednoho sice existují, ale občas mi přišel efekt spíše negativní než pozitivní. Např. JCH optimize. Navíc takovým plugin se first byte time naopak ještě zvýší, zrychlí se pak dotažení ostatních skriptů apod...
V tuto chvíli to mají u WEDOSu (NoLimit) a to už se přešlo i na NoLimit Extra, kde je povolen větší počet PHP procesů (místo 5 je 10) a PHP_memory_limit je 256MB, ale moc velký efekt to při zpracování vlastních PHP scriptů nemá....

@H13: Ano, GZip komprimace bylo to první, co jsem zapínal včetně cachování na straně Joomly.

Může to být tak i tak, jak psal H13, více paralelních dotazů má také svoje proti. Osobně bych se zaměřil na cestu méně JS i CSS celkem, tj. vyházet nepotřebné pluginy a moduly a používat opravdu jen to nezbytné.Martens napsal: Ok Cony, takže pokud to chápu správně, tak tady by de facto bylo sloučení do menšího počtu větších js a css souborů kontraproduktivní. Je to tak?
Pokud to je k tomu JCH optimise, tak ne, ten plugin může fungovat i na hostingu.Martens napsal: Tohle by ale bylo použitelné v případě, že pojedou na vlastním serveru a ne na webhostingu.
