Autor Zpráva
Hitman
Profil
Vážení diskutující,

snažím se zrychlit načítání webu a rozhodl jsem se využít nástroje webpagetest.org. Spoustě věcí v něm nerozumím, existuje někde (nejlépe česky) návod, popis této aplikace? Co které hodnoty vyjadřují a na co se zaměřit?

Konkrétně na tonto testu.

První věc co mě zaráží - document complete 6s, ale fully load 14s. Co to znamená, je to důležité?

1) Poté je pro mě předpokládám nejdůležitější vodopád. První řádek - first bite 1,4s. To mi přijde docela hodně. Tato hodnota vyjadřuje jak dlouho trvá serveru zpracování daného scriptu, chápu to správně? Lze někde vyčíst rozdělení samotný php script a ostatní režije serveru? U html stránky je tento údaj pouze režije serveru?

2) Potom jsou tam do cca 3,5s (beru dobu blokování přístupu dalším zdrojům, v tomto případě obrázkům) javascripty a css. Pokud bych to vše dal teoreticky do 2 souborů, ušetřím tento blokovací čas a další věci (obrázky) se začnou načítat o 2s dříve, nebo ty 2 velké soubory stejně hned "nepustí na řadu" obrázky? Na čem to závisí, za jak dlouho daný soubor pustí k paralelnímu zpracování další? Proč je to někdy víceméně ve stejnou chvíli, někdy v půce načítání souboru a někdy až je celý načtený?

Ještě mě napadá, proč je každý objekt nejdříve průhledně a poté plnou barvou? Souvisí to s tím document complete a fully load?

3) Následují obrázky a přestože jsou poměrně malé, některé se načítají i 1,2s, proč? Lze to něčím ovlivnit?

4)Nakonec tam je asi sekundu smartsup, což je také docela hodně, nebo to jen špatně odečítám z grafu?

Díky moc
smitka
Profil
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
Hitman
Profil
Díky za informace :-)

1) Pokud mám multihosting (managed VPS) tak vyjma optimalizace PHP scriptu asi nic udělat nemůžu, že?

2+3) Zkusil jsem nastavit HTTP/2, ale situace se ještě zhoršila, přes 6s, vypadá to že asi kvůli těm obrázkům. Jak je možné že se favicon načítá 3s, to už úplně běžné není, ne?

Někde jsem četl že SSL neumožňuje sdílené cache mezi serverem a klientem, nebude to tento problém?

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

Je možné to na multihostingu nějak řešit, nebo se s tím smířit/odejít jinam?


Ten poslední odstavec - statickými soubory myslíš i js, css a obrázky? Neexistuje i nějaké řešení bez změn DNS? Mohl by pak prý být problém s SSL a tím pádem HTTP/2 na který jsem chtěl přejít.
TomášK.
Profil *
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.
Hitman
Profil
S tím prohlížečem je to pravda u HTTP/2 mi ukazuje 2,8s. Hodně jsem o použitém nástroji četl, je doporučován hodně články týkající se optimalizace, že by byl tak nepřesný?

1) S tím cachováním tomu úplně nerozumím, vím že je více druhů (cachování html stránky, cachvání pomocí hlaviček http, reverse proxy a další). Které máš na mysli a neměl by jsi nějaký jednoduchý návod na ono kešování? (v těch 20 stránkových popisech se docela ztrácím, spíše nějakou konkrétní implementaci..)

Při SSL servery po cestě nevidí do obsahu a nemůžou ho cachovat.

Takže jestli to správně chápu, při měření výše zmíněnou službou, nebo v prohlížeči přes ctrl+F5 kešování stejně nevidím? A pokud použiji SSL, nemá kešování smysl?

Takže nejjednodušší řešení je tahat js, css a obrázky které se nemění přes CDN? Asi na to neexistuje nějaký návod v češtině, že? Nerad bych zkazil nastavení, aby mi potom nefungovali emaily, nebo celý web...(jde to vůbec použít společně s SSL?)
TomášK
Profil
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.
pcmanik
Profil
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.
Hitman
Profil
TomášK:

Aha a nemáš nějaký tip na zdroj kde by to bylo popsáno? Ať už v html, nebo php. Rád se přiučím něco nového, ale našel jsem jen samé obecné informace a ne konkrétní implementaci.

pcmanik:
1. Ano, to je pravda, odstraním.
2. Má to velký vliv? Takto kdykoliv cokoliv upravím přímo na serveru, pokud to budu mít zmenšené, musím udělat extra zálohu, tu úpravu (pokud to nebude drobnost) provést tam, znovu zmenšit..tak jestli těch -30% za to stojí..
3. To ano, je to už trochu zastaralé, ale pochybuji že těch pár (10?) mini obrázků bude mít zásadní vliv. Nebo ano?

Joomla to sice je, ale hodně upravená, je to komplexní systém pro různé weby, takže obsahuje spoustu věcí navíc. Podílel jsem se na jeho vývoji...a znáte to o kovářově kobyle..
Tomášeek
Profil
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
Profil
Tomášeek:

Jestli jsem to správně pochopil tak v případě HTTPS už počet dotazů (requestů) nehraje roli, ne?

Nástroje? Můžeš to trochu přiblížit? Na minifikaci ano, ale ty asi myslíš nějakého FTP klienta, který to ukládá dvojmo...?
Keeehi
Profil
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
Profil
Ano, špatně jsem se vyjádřil, myslel jsem HTTP/2, ten mám na HTTPS nasazený. Takže v tom případě není třeba počet obrázků (dotazů) řešit..
Keeehi
Profil
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íš.
Hitman
Profil
Otázkou zůstává čemu věřit...jestli pouze vlastnímu prohlížeči, nebo online nástroji s waterfallem...2,8 a 6s je rozdíl.
Bubák
Profil
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.

Vaše odpověď

Mohlo by se hodit

Zajímavé čtení:
Poptávání výměny odkazů je na této diskusi nežádoucí.

Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: