Jak ctíme zásady pro svižný web (2. díl)

Sobota, 13. Duben 2013

S drobným zpožděním vychází druhý díl článku o zrychlování stránek. Tentokrát se podíváme na zoubek HTTP požadavkům, datové velikosti, JavaScriptu a možnému zrychlení analyzovaných stránek.

Proč jsem se vůbec rozhodl článek rozdělit?

V prvním díle článku padl dotaz, proč jsem se rozhodl článek rozdělit. Je to proto, že ten původní byl příliš dlouhý. Lidé obecně dlouhé články nemají rádi a já tu nechci psát dlouhé eseje. Většina mých článků má kolem 700 slov a to je podle mého ideál přínosného a zároveň ne moc dlouhého postu.

Rozhodně jsem článek nerozděloval, abych měl více článků či stránek, protože je s tím spíše jen více práce. Šlo prostě jen o to, že něco přes 1200 slov bylo na jeden článek (navíc s plno obrázky) příliš. To je myslím vše, co jsem k tomu chtěl říct, pojďme se tedy už podívat na výsledky měření.

Datová velikost a počty HTTP požadavků – wow

Tahle část pro mě byla nejpracnější (bylo třeba zaznamenat ohromné množství čísel a ty pak zprůměrovat), ale vyplatila se. Přinesla totiž plno překvapení. Po spočítání jsem doslova zůstal v úžasu, protože takové výsledky jsem opravdu nečekal. Hned vysvětlím proč. Pojďme na graf.

Datová velikost souborů podle typu.

Ten nám znázorňuje datovou velikost podle typu souboru. Díky němu víme, jak je velký průměrný CSS soubor, kolik kB mají dohromady všechny obrázky na stránce a podobně. Osobně jsem čekal, že JS bude ohromný a někde daleko za ním budou obrázky a CSS, ale není tomu tak. Celých 68 % celé datové velikosti stránek zabírají obrázky. Nevím, co k tomu víc říct.

Zřejmě je používáme příliš a nezmenšujeme je. Z tohohle předpokladu vycházím, protože většina stránek by optimalizací obrázků uspořila sotva 100 kB (podle čísel z předchozího článku). Není tedy možné, že obrázky prostě blbě ukládáme. Používáme jich zkrátka příliš. Zkuste proto obrázky více ořezávat, zmenšovat je (všechny obrázky k článkům zde mají třeba rozměry jen 380 či 460) a používat je opravdu jen za předpokladu, že budou přínosem. Ušetříte plno dat a stránky díky tomu budou o dost svižnější.

Počet HTTP požadavků na typ souboru.

Tento graf v kontextu s předchozím už bohužel nic zajímavého nepřináší. Používáme na webu zkrátka příliš obrázků. Proto ze svých stránek zkuste vyházet ty nepřinášející užitek, prťavé převeďte na data URI a vkládejte na web obrázky v rozumných rozměrech. Nic jiného snad už doporučit nejde. Prostě průměrně 61 HTTP požadavků o načtení obrázku na jednu stránku je příliš. Přitom cirka těch 10-20 jsou právě ty malé, které jen zdržují.

První načítání a možné zrychlení – docela fajn

Při zkoumání toho, jak se lidé snaží udělat své stránky ještě rychlejší mě velmi zajímala velikost JavaScriptu. To je totiž typ souboru, který se poslední roky nepříjemně zvětšuje. I když na datovou velikost obrázků to asi nemá, na některých webech jsou tyto knihovny už opravdu ohromné a někdy trvá i celé vteřiny jen jejich načtení. Jak to ovšem dopadlo průměrně?

Průměrný datový objem JS na webu.

Docela fajn. Nějakých 75 % webů má JS do 300 kB. Znamená to sice vteřinu načítání, ale nedělejme si iluze, lepší to už nebude. Do budoucna by jen bylo dobré velikost těchto knihoven příliš nezvětšovat a už vůbec nevkládat celé velké knihovny na web kvůli nějakému hejblátku. Zjednodušujte a snažte se používat jen to nejdůležitější. Samozřejmostí je pak u takových velkých souborů gzip komprese a dlouhé kešování (klidně i na několik měsíců).

O kolik by šlo zrychlit webové stránky.

Asi jedním z nejzajímavějších grafů je určitě tento. A to sice možné zrychlení analyzovaných stránek. Těchto výsledků bylo dosaženo plnou optimalizací kódu, dodržováním pravidel a postupů při optimalizaci stránky. Polovina stránek by šla zrychlit průměrně o 20 %. Opět – není to žádné zázračné číslo, ale poznat by se to dalo. Mnohem zajímavější je koláč, který má po svém spojení 38 %. Takové stránky by šlo udělat svižnější o 20 až 60 (!) %. To už je poměrně hodně a určitě by se vyplatilo něco zkusit. Pro ilustraci, třeba tento weblog byl urychlen optimalizací o cirka 40 % a znát je to ohromně.

Skóre v PageSpeed Insights a slovo závěrem…

A teď jsme na úplném konci článku. Už nás čeká jen poslední graf, který ukazuje průměrné skóre v jednom z nejpopulárnějších nástrojů pro urychlování webu – PageSpeed Insights. A takhle nějak to dopadlo.

PageSpeed Insights.

Velkou pochvalu si tady zaslouží web Jak psát web, který má nádherné hodnocení 98 / 100. Úplným opakem pak jsou stránky Sreality s žalostným skóre 11 / 100. Web nemá aktivované gzip a díky tomu stahujete skoro půl mega naprosto zbytečně, má nesmyslně krátkou dobu u kešování, JavaScript není minifikovaný a web odkazuje na hromadu malých obrázků, které nemají ani 10 pixelů. Něco takového se má řešit přes data URI. Hrůza.

Průměrně vzato jsou však výsledky docela hezké. Špatných webů moc není a nad 80 bodů se drží polovina testovaných stránek. Jsem docela spokojen, i když by mohlo být lépe. A co vy? Překvapilo vás na výsledcích něco?

Nezapomeňte si přečíst i předchozí díl článku, ať máte ucelenější pohled na věc. Přeci jenom, ty články patří k sobě a poslouží tak mnohem lépe.

Nabízíme vám širokou škálu zdravotnických potřeb.
V sortimentu www.dentimedshop.cz máme například inkontinenční pomůcky, zdravotní kompresní punčochy nebo ortézy. Pomůžeme vám s výběrem.

{ Komentáře k článku }

Jan

Snad nebudu příliš OT, ale zeptám se: Chystáš ještě nějaké články o optimalizaci? Jsou pěkný a líbí se mi.

Tomáš Erlich

Díky za zájem, ale s největší pravděpodobností ne. Myslím si, že jsem celé téma již vyčerpal a napsal dost tipů, jak udělat web rychlejší. Ucelenější to snad už být ani nemůže. Tento článek měl jen za účel celé tohle uzavřít a doplnit návody nějakou statistikou, která lidem při zrychlování pomůže.

Už snad není ani o čem psát, protože kdyby někdo opravdu šel článek po článku a vše udělal, měl by určitě bleskurychlé stránky. A o to tu celou dobu šlo. Takže ber tyto statistiky jako završení celé této série. Ale kdo ví, třeba mě ještě něco napadne a v takovém případě určitě nezaváhám a sepíšu to sem.

heptau

Osobne jsem na svuj server nastavil do cronu, aby se automaticky jednou tydne (pred tydeni uplnou zalohou) spoustel prikaz optipng a jpegoptim a tim jsem vyresil snad to nejhorsi. Osobne ted uz nemusim optimalizaci moc resit a ani nikomu vysvetlovat, ze by mel obrazky optimalizovat. Krome toho se mi na webu uvolnilo i par GB mista (a v zalohach jeste jednou).

Jeste jsem samozrejme nastavil cachovani a kompresi a vic uz toho hned tak delat nebudu – uz tak mam prace az nad hlavu.

Tomáš Erlich

Pár GB? To máš na serveru asi hromadu obrázků. Nejlepší na tom podle mě je, že ušetříš datový přenos, protože se třeba ten neoptimalizovaný obrázek zobrazuje tisíckrát a tak server musí odesílat přebytečná data. Tím, že se obrázky optimalizují, server nemusí lidem posílat ani kB navíc :).

Jinak pro lidi, co tohle moc neřeší… ono aktivované gzip a dobře nastavené kešování většinou bohatě stačí. Pokud na webu fakt nejsou špatné uložené obrázky (v Photoshopu přes „Uložit jako“ namísto „Uložit pro web a zařízení…“), není třeba nic jiného řešit. Ale pokud chce mít člověk fakt svižné stránky, je dobré stránku analyzovat a podívat se, co by se dalo zlepšit.

Kolesova plavkyně

Pokud pouštíš 1× týdně jpegoptim ve ztrátovém režimu, tak to za chvíli bude vypadal jako u Picassa. Doufám, že to děláš rozumněji.

Tomáš Erlich

Podle mého určitě myslel bezztrátovou kompresi. Tu ztrátovou nikomu nedoporučuji. To ty obrázky totiž rovnou můžete zahodit, protože by to vyšlo nastejno. Na první pohled jsou takové obrázky od originálu nerozeznatelné, ale stačí si je jen drobet přiblížit a už vidíte tu hrůzu. A my přece chceme obrázky stejně hezké jako nyní, jen nechceme přebytečné kB…

pvy

„Používáme na webu zkrátka příliš obrázků. Proto ze svých stránek zkuste vyházet ty nepřinášející užitek, prťavé převeďte na data URI a vkládejte na web obrázky v rozumných rozměrech. Nic jiného snad už doporučit nejde.“

Tohle je s prominutím hovadina, která dehonestuje celý článek.
Protože:
1) css image sprites
2) přesun obrázků (statického obsahu obecně) na jinou adresu, aby prohlížeč využil paralelní přenos
3) http hlavičky pro maximální využití cache
4) převod grafiky do vektorů, kvůli kompatibilitě třeba přebalením do webfontu.

Josef Kroupa

Tomáši,
děkuji za užitečný mini-seriál. Díky němu jsem se dostal i k jednomu Tvého staršímu článku o gzip kompresi. Díky několika zde uvedeným radám se mi podařilo své weby poladit a zvýšit rychlost načítání.

Tomáš Erlich

Takový komentář vždycky udělá ohromnou radost, takže díky. Koukal jsem na tvé stránky, zkusil je proklikat a načítají se fakt bezvadně. Jestli mohu ještě něco poradit – zkus své obrázky optimalizovat nástrojem Kraken a případně aktivuj kešování, alespoň těch základních souborů (CSS, JS a obrázky). Po tom všem budou tvé stránky určitě rychlé jako blesk.

Josef Kroupa

Tomáši, tak jsem dle Tvého doporučení aktivoval kešování, tak uvidíme, zda veškeré provedené úpravy budou mít vliv na návštěvnost. Pevně věřím, že ano :-).

Komentáře jsou pro tento článek již uzavřeny.

Předchozí příspěvek:

Následující příspěvek:

Tato stránka již není udržována. Děkuji za pochopení.