obrovský "wait" u načítání stránek

marvays:
Tak to co tě v důsledku zajímá je jak se to načte u zákazníka. 4 vteřiny na TTFB z obrázku mi přijde jako opravdu hodně, u mě to bylo 2.5. Takže reálný problém to je. Osobně ten limit, kdy to ještě jde a kdy už je to pomalé mám okolo 0.5 vteřiny. Chápu, že optimalizace se dělají těžko pro někoho kdo eshop provozuje nad redakčním systémem protože to jinak technicky nezvládne.
Jedním z typických problémů dlouhého načítání stránky může být nějaký neoptimalizovaný složitý dotaz do databáze který trvá prostě dlouho. Takže bych se podíval na dobu běhu jednotlivých dotazů.
Dalším celkem typickým problémem eshopů je, že je pro ně náročné počítat cenu u produktů. Když má produkt několik variant, uživatel je v různých zákaznických skupinách, do toho se motají slevy akce a kupony, pak počet těch možných kombinací je opravdu hodně a počítání všech cen to může hodně brzdit. Takové výpočty se pak hodí kešovat.
No a třetí možnost, která je zase typická pro redakční systémy jsou pluginy. Čím jich je více, tím náročnější je pro server je všechny aplikovat před vytvořením stránky. Rychlosti může pomoci odstranit ty nepotřebné. Je klidně možné že to způsobuje jeden špatně napsaný plugin a kdyby se vyměnil za nějaký jiný, hned by to fungovalo lépe.
Ale těch důvodů může být více. Snažil jsem se napsat ty typické, co mě napadly.

marvays:
Já proti tomu nic nemám. Naprosto chápu proč to tak někteří (naprostá většina) dělá. A ani to není špatně, pro spoustu těch malých eshopů je to vhodné řešení.

„není jen čekání na odpověď serveru, ale čekání na na kompletní výpočet, který server musí provést, než vygeneruje stránku“
Přesně tak. Z toho obrázku se to špatně poznává ale myslím, že ta zelená část na začátku reprezentuje handshake (poslání ssl certifikátu atp) a jak je vidět, jde to celkem rychle. Takže hlavním problémem by nemělo být zpoždění sítě. Zbývá tedy to vygenerování stránky. A proto si myslím, že většina času bude tedy tam.

Další, čeho jsem si všiml je, že TTFB pro přesměrování z domény bez www na doménu s www je u mě 400ms což je opravdu hodně. Jsou dvě možnosti, buď to přesměrovává webserver (což je vhodnější) ale pak v takovém případě je server tvého poskytovatele neskutečně přetížený (nebo pomalý). Nebo přesměrování neprovádí webserver ale až ta eshopová aplikace. Z toho je vidět, že 400ms stráví něčím a to nemusela zobrazit ani jeden produkt, článek, nic. Navíc vyhodnocování url adresy bývá v aplikaci někde na začátku, aby se určilo, co se má vlastně zobrazovat.

„Takže si udělám kopii webu, nejlépe na stejném hostingu a použiju mou oblíbenou vylučovací metodu. Budu vypínat a zapínat a testovat. A to by to byl čert, aby v tom něco nenašel.“
Skvělý přístup.

„Co kdybych to dal do htaccess?“
Mělo by to být rychlejší. Někde kolem řádu jednotek milisekund.