Rychlost načítání webu - diagnostika

1) je to tak, jak říkáš - je to doba, za kterou server zpracuje PHP, vykomunikuje data s DB, někdy provede i HTTP dotazy na další servery (což dost zdržuje), a také s v tom promítne rychlost sítě (to jsou ale většinou max desítky ms). U statické stránky je to prakticky jen doba přečtení dat z HDD, zabalení do HTTP komunikace a poslání po síti. 1.4s je vcelku normální na neoptimalizovaný web, normální ale neznamená dobré :-)

2) + 3) obecně je tam vidět, že serveru dlouho trvá posílání dat, to může být způsobeno přetíženým serverem, odcházejícím diskem, nebo nekvalitním síťovým připojením. Sloučení více souborů do jednoho je dobrá a doporučovaná technika (u HTTP/2 už nutná není) a dost pomůže, zde to však nebude hlavní problém. Většina prohlížečů stahuje soubory v 6 vláknech z jedné domény - jak se jednotlivá vlákna dokončují, tak se spouští stahování dalších souborů - někdy načítaný zdroj stahuje další zdroj, takže je výsledek dost neurčitý. Protože se soubory načítají podle jejich pozice v kódu, je dobré nepotřebné věci načítat až na konci stránky a na obrázky použít lazy loading.

Průhledná barva značí čekání od požadavku na soubor po okamžik, kdy od serveru začla chodit první data.

4) Smartsup je načítaný až po vykreslení stránky celé, takže to není takový problém, měření však považuje stránku za visualy complete až v okamžik, kdy se tam objeví smartsupp tlačítko

Pokud má server problémy se servírováním statických souborů, lze tomu pomoci použitím externího CDN, kde jsou obrázky načteny. Zdarma je třeba základní (a pro spoustu webů dostatečná) verze www.cloudflare.com - funguje to tak, že si změníš DNS servery na jejich a tak veškeré požadavky procházejí přes jejich servery, které je optimalizují a uchovávají si statické soubory v cache.

Na toto téma jsem publikoval pár článků:
lynt.cz/blog/10-nejcastejsich-problemu-modernich-webu
lynt.cz/blog/optimalizace-vykonu-webovych-aplikaci-na-co-se-zamerit

Výsledky, které to zobrazuje, nesouhlasí s tím, co mi zobrazí prohlížeč. U verze s HTTP/1.1 to ještě jakž takž sedí, to nové měření je mimo. Prohlížeči věřím víc než internetové službě. Otevři si v prohlížeči (Chrome, Firefox) vývojářské nástroje, záložku Síť / Network, obnov stránku tak, aby se nenačetla z cache a dívej se na grafy tam. Jsou k tomu i podrobnější údaje, popis pro chrome je tu: developers.google.com/web/tools/chrome-devtools/network-performance/reference#timing

1) 1,5 s je hodně, optimalizací skriptu se dá získat nejvíc. Poměrně jednoduchý způsob je cachovat části stránky, které se jen tak nemění - třeba menu. Jako cache jde použít i file systém, pořád by to mělo být řádově rychlejší než opakované generování.
2) Můj prohlížeč tvrdí opak. Na HTTP je DOMContentLoaded 2.86 s, Load 3.93 s, na HTTPS 2.71 s resp. 3.68 s. Obrázky se stahují desítky milisekund, některé jsou pozdržené, než se stáhnou javascripty, které mají vyšší prioritu. Ta služba buď započítává do času stahování i to pozdržení nebo měla smůlu na chvíli, kdy byl server vytížený nebo je mimo.

Někde jsem četl že SSL neumožňuje sdílené cache mezi serverem a klientem, nebude to tento problém?
Při SSL servery po cestě nevidí do obsahu a nemůžou ho cachovat. V tom problém není, ten graf je při načtení bez použití cache.

Pokud bych to chtěl zrychlit a co nejmíň šahat do kódu, začal bych cachovat v php a statické soubory přemístil někam jinam, knihovny (jquery, bootstrap) načítal z CDN. A zrychlení bych měřil prohlížečem.

Měl jsem na mysli cachování html stránky (přesněji částí html stránky, které jsou pro všechny stejné - menu, patička alias fragment caching). Kus stránky si uložíš do souboru jako html a při příštím načtení vrátíš obsah toho souboru místo toho, abys to generoval znovu. Pokud je to v php, tak na to konkrétní implementaci neznám. Ale i kdyby sis to měl psát sám, mělo by to být na pár řádků (<100).

Obrázky už prohlížeč cachuje. Pokud to obnovíš jen pomocí F5, měl bys to vidět. Při Ctrl+F5 to neuvidíš, to říká nenačítat z cache. Cachování určitě smysl má, jen ho musíš dělat už na serveru nebo nechat na prohlížeči. Není možné, aby si někdo dal do firmy proxy server, který bude cachovat, co přes něj chodí. To šlo u HTTP, ale už ne u HTTPS.

CDN … no, nahraješ je na nějaký jiný server a změníš URL ve stránkách na jiný server. Je potřeba, aby to bylo taky HTTPS. Ale když to počítám, tak bych od toho zas tolik zrychlení nečekal. Server 1,5 s generuje php a pak 1,5 s stahuje styly, obrázky, javascripty, kterých je cca 2 MB. To asi tak odpovídá mé přenosové rychlosti.

Hitman:
1. 5 krát načítavaš jquery.
2. Skripty ani CSS nemáš minifikované.
3. Obrazky banner_tecka a banner_tecka_hover by snad isli riesit cez CSS nie? Urobiť kolečko v CSS zas nieje tak zložité. Banner_pozadi to iste, css gradienty. Vlastne keď na to pozerám tých zbytočných obrázkov je tam oveľa viac. Prečo to nieje riešené cez CSS?

A že je PHP pomalé? No to bude asi tým redakčným systémom JOOMLA a určite kope doplnkov... S tým si pomôžeš tak že budeš googliť ako spraviť Joomlu rýchlejšiu. Začal by som zmazaním nepotrebných doplnkov.

Máš web na PHP 7? Ak nie tak vyskúšaj prechod na neho. Malo by sa znateľne zrýchliť generovanie PHP skriptov. Máš zapnuté OPCache, alebo iný typ cachovania?

A prečo pomalosť stránky nerieši firma ktorá je za to zodpovedná? Teda tá ktorá daný web vytvorila? Toto by som určite riešil ako reklamáciu nekvalitného produktu.

pcmanik:
„3. Obrazky banner_tecka a banner_tecka_hover by snad isli riesit cez CSS nie? Urobiť kolečko v CSS zas nieje tak zložité. Banner_pozadi to iste, css gradienty.“
S tímhle opatrně. Mnoho procedurální grafiky bude web oproti loadingu obrázku/ů spíše zpomalovat. Na kreslení je Photoshop, nikoliv CSS. Ta kolečka jsou stínovaná, to už je v CSS zbytečně složité.

Hitman:
Co se těch obrázků týče, tak se podívej po spritech.

Na minifikaci souborů existují nástroje, které budou minifikovat za tebe. Pokud ale pracuješ stylem "Otevřu FTP, stáhnu soubor, zedituju soubor, nahraju zpět na FTP", tak minifikaci neřeš. Efekt stejně nebude tak velký, bavili bychom se řádově o milisekundách, nikoliv sekundách.

Hitman:
„Jestli jsem to správně pochopil tak v případě HTTPS už počet dotazů (requestů) nehraje roli, ne?“
Ne, počet dotazů hraje roli jak na http tak na https. Rozdíl je mezi HTTPv1.1 a HTTPv2. Nová verze pracuje lépe s navázaným spojením a více dotazů není už takový problém. Naopak, při více dotazech se dá lépe pracovat s kešemi. Ale to už bude jen taková drobnosti, kterou mělo smysl řešit až u obrovských portálů.
Ovšem https má do toho nepřímo co mluvit taky. A to je z toho důvodu, že HTTP verze 2 podporují prohlížeče jen na stránkách běžící na https.

„ale ty asi myslíš nějakého FTP klienta, který to ukládá dvojmo...?“
Nemyslím si, že by měl něco takového na mysli. Jsem si téměř jistý že těmi nástroji myslel ty na mumifikaci.

Hitman:
„Takže v tom případě není třeba počet obrázků (dotazů) řešit.“
Ono vlastně nezáleží na tom, co máš nebo nemáš nasazeno. V důsledku jde vždy o to, jestli jsi se současným stavem spokojený. Pokud ano, nic řešit nemusíš.

Online nástroj je v jiné zeměpisné lokaci a tapy může být rozdíl v "rychlosti stroje", tipnul bych si, že to bude "virtuální mašina" a kdo ví, kolik jich běží současně na fyzickém stroji.