Proměřil jsem přes 30 českých e-shopů. 4 chyby, co dělá skoro každý (a jeden falešný nález, co jsem si sám vyrobil)

Dneska jsem si proměřil přes třicet českých e-shopů a menších firemních webů — Shoptet, Shopify, WordPress. Nešlo mi o Lighthouse skóre, ale o věci, které jdou ověřit curlem a které přímo stojí objednávky. Sepíšu, co se opakovalo, ať to nemusí měřit každý znovu. 1) Chybějící lazy loading je zdaleka nejčastější problém Příklady z dneška: e-shop se 164 obrázky na homepage, z toho nula s odloženým načítáním. Jiný se 153. Jiný s 234. Prohlížeč to stahuje všechno naráz při otevření, včetně fotek, které jsou pod deseti obrazovkami textu. Na mobilu první obrazovka soutěží o připojení s obsahem, ke kterému se návštěvník nikdy nedostane. Zajímavé je, že opačný extrém taky existuje — jeden Shopify obchod měl 356 z 360 obrázků správně odložených. Takže to není limit platformy, je to nastavení šablony. 2) Pozor na nález "obrázky nejsou ve WebP" — u Shoptetu bývá falešný Tohle mě dneska stálo hodinu a vyrobil jsem si to sám. Grep na .webp ve zdroji homepage neříká nic: Shoptet a další CDN řeší formát přes content negotiation. V HTML zůstane .jpg, ale server podle hlavičky Accept vrátí image/webp. Ověřoval jsem 12 obchodů a u 9 z nich vrátil curl s hlavičkou Accept: image/webp na .jpg URL reálně image/webp. Měřit se to musí takhle: curl -sL -H "Accept: image/avif,image/webp,image/*" -o /dev/null -w "%{content_type} %{size_download}" URL Jinak klientovi pošlete nález, který neplatí — a to je horší, než mu nenapsat vůbec. 3) Jedna fotka, která položí celou stránku U několika webů byla drtivá většina fotek v pořádku a pak tam byl jeden úlet: 1,79 MB na homepage jednoho e-shopu s kosmetikou, 1,81 MB u jednoho salonu, 896 kB u dalšího. Průměr tohle neukáže. Musíte se dívat na maximum, ne na průměr. 4) Váha samotného HTML, ještě než se stáhne první obrázek Nejhorší dnešní nálezy: 2,2 MB, 980 kB, 834 kB. To je jen dokument, bez fotek. Běžný obchod se vejde do zhruba 200 kB. Prohlížeč to musí stáhnout i naparsovat, než začne vůbec vykreslovat, takže se to sečte i na rychlém připojení. Bonus, co mě překvapilo nejvíc: dva weby vůbec neměly meta viewport. Telefon je vykreslí jako zmenšený desktop a člověk musí přibližovat prsty. U jednoho z nich šlo o kosmetický salon, kam se lidi objednávají skoro výhradně z mobilu. Skript, kterým to měřím (TTFB medián ze tří běhů, reálné bajty obrázků přes Accept hlavičku, lazy, alt, h1, viewport), je pár řádků bashe. Klidně ho sem hodím, jestli to někoho zajímá. A kdyby si někdo chtěl nechat proměřit svůj obchod — hoďte sem odkaz a napíšu, co jsem našel. Zadarmo, je to na pár minut a mě to baví.

To s WebP je docela dobrý příklad toho, jak snadno může člověk dojít ke špatnému závěru, když se podívá jen na HTML. Tady je pěkně vidět, že samotná přípona souboru ještě nemusí říkat, co server ve skutečnosti pošle prohlížeči. A ten rozdíl mezi průměrnou velikostí obrázků a jedním extrémně velkým souborem je taky zajímavý.

Díky za sepsání, hlavně bod 2 je zlatý. Doplním dvě věci z praxe s WordPressem: K lazy loadingu: WordPress od verze 5.5 přidává loading="lazy" sám, ale řada page builderů a sliderů ho vypíná nebo obrázky vkládá jako CSS pozadí. Tam atribut nepomůže. A naopak pozor na opačnou chybu: první velký obrázek nahoře (hero, hlavní fotka produktu) lazy být nemá, jinak se zhorší LCP. Ideálně má fetchpriority="high". Při měření se vyplatí kontrolovat obojí: kolik obrázků pod první obrazovkou lazy není a jestli náhodou lazy není ten hlavní. K WebP přes Accept: totéž dělají i WordPressové pluginy, které WebP servírují přes .htaccess (stejná .jpg adresa, jiný obsah). U nich je dobré zkontrolovat i hlavičku Vary: Accept. Když chybí a před webem je cache nebo CDN, může se stát, že prohlížeč bez podpory WebP dostane WebP z cache, nebo naopak všichni dostanou JPG. Stačí přidat do curlu -I a podívat se na Vary.