Dnešní článek budu věnovat mému oblíbenému tématu – zrychlování stránek. Konkrétně vám povím o tom, jak jsem zrychloval načítání tohoto blogu. Můžete se tak v mnohém inspirovat.
Jeden CSS soubor musí stačit
Asi tak bych popsal věc, do které jsem se pustil jako první.
Moje šablona totiž ve výchozím nastavení obsahovala 3 CSS soubory. Každý z nich měl sotva 5 kB.
To je doslova zbytečný HTTP požadavek. Tak malé CSS můžete rovnou vložit do hlavičky dokumentu nebo je všechny sloučit do jednoho. Což jsem také udělal. Zbavil jsem se tak dvou zbytečných HTTP požadavků.
A nejde o nic složitého. Obsah všech CSS jsem jen dal dohromady a vyvolávání přebytečných CSS zrušil v PHP souboru šablony.
Žádné zbytečné pluginy
Kolik mám aktivovaných pluginů? 0. Žádné.
Používat WordPress pluginy pro každou hloupost je zbytečné. Někteří si aktivují 30 pluginů a následně na fórech prosí o rady, jak urychlit své stránky. Já jednu mám – nepoužívejte pluginy, když to není potřeba.
Plno věcí ve skutečnosti nepotřebujete a jiné můžete vyřešit prostým zápisem pár řádků do vaší šablony. Navíc věci, které si napíšete můžou být klidně i 20x menší než plugin, který dělá totéž.
Tím neříkám, že jsou všechny k ničemu, ale jde jen o snadné řešení jak dosáhnout tížených funkcí. Ne efektivní.
Na tomto blogu jsem si kupříkladu vše napsal sám.
V souboru functions.php mám 15 funkcí, které potřebuji a vše mám pod kontrolou. A výsledný soubor nemá dokonce ani 15 kB. Při použití rozšíření bych se přinejlepším dostal na dvacetinásobek. Neopomíjejte zkrátka rychlost svého webu.
Rychlost načítání by mělo být stejně důležité téma jako design webu či jeho obsah.
Omezení obrázků na minimum
Zkušenějším je dnes již jasné, že většina dat při načítání jsou obrázky. Rozhodl jsem se je proto omezit co možná nejvíce.
Tohle je osobní blog a ten je hlavně o textu. Obrázky jsou jen doplněk. Smazal jsem tak některé zbytečné obrázky ze šablony a ty malé převedl na data URI.
Zcela jsem se díky tomu zbavil zbytečných HTTP požadavků.
V tomto se doporučuji inspirovat. Projděte svůj web a určete si, které obrázky jsou a nejsou třeba. Jaké jsou podstatné pro tvář vašeho webu a které tam jsou jen tak. A ty malé převeďte na data URI.
Návod najdete v mém starším článku o data URI.
Omezením obrázků můžete ušetřit plno dat a uvolnit požadavky pro podstatnější soubory.
Žádná tlačítka na sdílení
Když jsem začal používat sociální sítě, všude jsem automaticky vkládal tlačítka pro sdílení. Čím dále jsem se však věnoval rychlosti webu, tím více jsem začínal tlačítka nenávidět.
Proč jsou tak velká? A proč se stahuje tolik souborů?
Proč tlačítka sledují každého návštěvníka? Proč Facebook sleduje dokonce i návštěvníky, který jeho služby nevyužívají? A ví o tom lidé vůbec?
Nehledě na to, že umístěním tlačítek na sdílení necháte uživatele stahovat klidně i dalších 400 kB. Což bylo na mém blogu nepřijatelné. Kompletní načtení náhodného článku zabere i s reklamou nějakých 350 kB.
Proč by měl návštěvník stahovat dvojnásobek (!) jen kvůli hloupým tlačítkům?
Jde to navíc řešit lépe. Používání výchozích tlačítek ukazuje jen na lenost majitelů stránek. Nic vám totiž nebrání v tom udělat si svá.
Vytvoříte si obrázky pro jednotlivé sociální sítě a správný odkaz pro sdílení najdete v dokumentaci jednotlivých sítí. Vlastním řešením ušetříte stovky kB a nenecháte své uživatele sledovat.
Já tlačítka nakonec úplně odstranil. Lidé i přesto obsah sdílejí a na návštěvnost to nemělo žádný negativní efekt. Tvrzení, že potřebujete tlačítka na sdílení je blbost.
Vypnuté Gravatar obrázky
Poslední věcí, kterou jsem na svém webu udělal je vypnutí zobrazování Gravatar obrázků. Na malém webu by to bylo ukradené, ale když u článku máte 60 komentářů – začnete o tom uvažovat.
Takové množství obrázků dokáže solidně zabrzdit prohlížeč.
Můžete sice namítnout, že se obrázky (alespoň většinou) stahují až po vykreslení, ale na tom mi nezáleží. Jde mi o rychlost obecně. A prostě se mi nelíbilo, že jsem měl na webu o 60 požadavků navíc jen kvůli obrázkům v komentářích.
Kromě toho pro stránku nejsou důležité. Vypnete je v administraci WordPressu v dolní části pod volbou Nastavení – Komentáře.
{ Komentáře k článku }
Pěkný článek o optimalizaci.
Rozhodl jsem se uplatnit tvou první radu s CSS a celé styly jsem vložil do hlavičky. Mají jen 16 kB, takže jsem se toho nebál. Chtěl jsem nějak zrychlit stránky.
Rychlost načítání se sice nezměnila, ale k mému překvapení došlo ke zlepšení vykreslování. Podle nástroje WebPageTest se začnou stránky vykreslovat o 600 ms dříve a to je super.
Na mobilech to doufejme uživatelé ocení.
Přijde mi, že se poslední dobou na tomto tématu snaží každý jen přiživit a dělat o něm školení za nemalé peníze. O to více si cením, že nejdeš touto cestou a nebojíš se podělit o své zkušenosti.
Za to palec nahoru. Prima počtení.
PS: Přidám malý tip. Super nástrojem na zlepšení CSS a webu obecně je Yellow Lab Tools. Díky němu jsem dokázal najít a smazat prázdná pravidla a ty duplicitní sjednotit. Bylo jich celkem asi 70 a ušetřilo to další 2 kB kódu. Proto doporučuji.
U toho inlinování stylů a obrázků bych byl opatrný.
Sníží se sice počet requestů, ale mnoho z nich by si prohlížeč nakešoval a načetl jen jednou (při správně nastavených hlavičkách). Jak píše například v komentáři Jan Kovanda:
To znamená, že místo 1x16kB při první návštěvě se teď těch 16kB bude přenášet s každou nově načtenou stránkou.
Navíc expirace stylů bude nejspíš běžně nastavena na delší čas, než expirace HTML stránek (a prohlížeč tak bude nucen znovu načíst celou stránku i styly v ní vložené).
Totéž pro obrázky, obzvlášť ty layoutové. Pokud jsou jako soubor, načtou se jednou. Přes data URI se musí přenášet pokaždé znovu.
S příchodem HTTP/2 mohou být takové optimalizace dokonce kontraproduktivní. Nakonec, inlinování, ruční minimalizace, slučování souborů – to vše jde proti snadné udržovatelnosti kódu.
U vkládání stylů do hlavičky vždy záleží na konkrétním případu. Nejde obecně říci, že je to špatně.
Pokud mám 16 kB velký CSS styl a bylo to myšleno bez Gzip, díky kompresi se bude přenášet navíc jen několik málo kB. Možná tak 4, což je zanedbatelné. A za těch pár kB rychlejší vykreslování rozhodně stojí. Navíc je nutné brát v úvahu, že běžný návštěvník načte / přečte tak dvě stránky a jde pryč. Nenačítá desítky stránek.
Dobrých 70 % návštěvníků (odvážím si tvrdit) na běžný web přijde přes výsledky vyhledávání, přečte si požadované informace a jde pryč. V takovém případě je dlouhé kešování CSS k ničemu. Uživatel se stejně už nevrátí.
Tím neříkám, že je kešování obecně k ničemu – je skvělé, ale vkládání CSS do hlavičky bych se v některých případech skutečně nebránil. Za ty výhody to stojí.
K data URI jen krátce – všechny je mám v CSS, které je kešováno. Takže návštěvník nic znovu nenačítá. Data se přenesou jen jednou, ušetří se HTTP požadavky a při dalším načtení se vše načítá již z keše.
Taktéž si nemyslím, že je HTTP/2 spasení.
Žádné z těchto technik nebudou ani po přechodu z HTTP/1.1 na 2 kontraproduktivní. Stále bude výhodnější slučovat soubory (jeden soubor se bude stále stahovat rychleji než 5 menších), redukovat nadbytečné používání obrázků, HTTP požadavků a s tlačítky na sdílení to neudělá prakticky nic.
Ani rychlejší dodávání CSS stylů nebude, dokud si ho člověk sám nenastaví. Automaticky se nic s HTML stránkou neposílá.
Až uživatel bude muset nastavit, ať se posílá rovnou i
style.css, protože se používá na každé stránce. Na což je většina běžných majitelů stránek vykašle. Pokud ani dnes nejsou schopni naplno využívat kešování a gzip, což jsou věci staré 10 let – nebudou z čista jasna využívat ani toto.PS: Předváděcí dema jako je toto od Akamai jsou zavádějící. Je to extrémní případ, kdy se ukazuje jen rychlost požadavků.
Většinou z dema vyjde, že je obrázek načten 2x rychleji, což budí v lidech pocit, že po zavedení HTTP/2 budou stránky 2x rychlejší, což je blbost. Pokud budou jen o 20 % – budeme za to rádi.
U Gzip komprese pozor na bezpečnost.
Útok BREACH umí dekódovat komunikaci HTTPS, když je zapnutá komprese HTML. Napadá kompresní algoritmus Deflate.
Při použití šifrování se jako prevence doporučuje deaktivace HTML komprese.
S těmi WordPress pluginy máš recht. Já používám jen Google XML Sitemap a nemůžu říct, že bych měl pomalé stránky.
I když jsem rychlost načítání nikdy neřešil.
Komentáře jsou pro tento článek již uzavřeny.