Optimalizácia rýchlosti webu - základné postupy na zrýchlenie stránok

Rýchlosť webu je nevyhnutná

Ak niekto klikne na vašu stránku a niekoľko sekúnd sa zdá, že sa nič nenačítava ani nezobrazuje, pravdepodobne odíde s tým, že vaša stránka jednoducho nefunguje. V súčasnosti sa všetko musí načítať alebo aspoň vedieť, že sa načíta, v rádoch desatín sekúnd, pričom absolútne maximum sú veľmi nízke jednotky sekúnd.

Webové stránky dnes jednoducho musia byť svižné a rýchle, inak to nejde. Existuje mnoho štúdií alebo experimentov, v ktorých sa čas načítania webovej stránky zvýšil aj o desatinu sekundy, ale predaj klesol o percentá alebo dokonca o desiatky percent

. Samozrejme, ak načítanie stránky trvá dlhé sekundy, nikto na to nemá odvahu a jednoducho odíde.

Rýchlosť stránky je dôležitá nielen pre čitateľov, ale je aj jedným z rozhodujúcich faktorov, pokiaľ ide o umiestnenie našej stránky vo vyhľadávači. Tento technický faktor SEO je naozaj veľmi dôležité vyriešiť. Pozrime sa na túto problematiku trochu širšie. Aby sme mohli optimalizovať rýchlosť webu, musíme vedieť, ako prehliadače vytvárajú stránky a ako sa sťahujú jednotlivé zdroje, čo nám pomôže lepšie vyhodnotiť, ako by sme mali postupovať, aby bol náš web čo najrýchlejší a aby boli spokojní čitatelia aj vyhľadávače.

Ako merať rýchlosť webu

Ideálne je si stránku len pozrieť 😀 Ale je pravda, že ak sme na vysokorýchlostnom internete, veľa vecí nepoznáme, pretože aj veľké obrázky alebo celkovo objemný kód sa načítajú veľmi rýchlo.

Môžeme nastaviť prehliadač tak, aby simuloval pomalšie pripojenie, čo nám ukáže, ako sa naša stránka zobrazuje napríklad ľuďom s pripojením 3G, čo nám napovie viac o tom, čo zaberá čas a s čím by sme mali niečo urobiť, či už z hľadiska lepšieho kódovania alebo umiestnenia na iné miesto v kóde.

Takto môžeme umelo spomaliť internetové pripojenie v prehliadači Google Chrome stlačením kombinácie kláves Ctrl + Shift + I a potom:

Podľa mňa je najjednoduchšie a často najpresnejšie použiť nástroje, ktoré sa pozrú na stránku a skontrolujú, čo by sa dalo zlepšiť, a okamžite ponúknu zoznam možností, kde je priestor na zlepšenie z hľadiska optimalizácie rýchlosti.

Pre mňa sú najlepšie nástroje GTMetrix, Pingdom Tools a PageSpeedInsight. Všetky tieto nástroje sú bezplatné, bez registrácie a stačí len vložiť adresu URL stránky, ktorú chcete skontrolovať. Zložitá časť je potom skutočne správna optimalizácia, ale je dosť jednoduché zistiť, či máte niekde na stránke naozaj veľkú chybu, ktorú možno pomerne ľahko opraviť.

Ako prehliadače zobrazujú obsah

Nebudem sa tu zaoberať podrobnosťami, pretože to nie je až také dôležité. Základom prakticky každej webovej stránky je kombinácia jazykov HTML, CSS a JavaScript (JS), ktoré sú napísané tak, aby prehliadač rozumel štruktúre, umiestneniu a vzhľadu prvkov (o čo sa starajú jazyky HTML a CSS) a schopnosti vykonávať dynamické zmeny (čo je zvyčajne práca jazyka JavaScript).

Do kódu HTML môžeme v podstate voľne umiestniť CSS a JS, ale aj odkazy na obrázky alebo iné zdroje, ktoré sa postupne sťahujú a používajú na vytvorenie webovej stránky, ako ju nakoniec vidíme v prehliadači.

Prehliadač najprv stiahne samotný kód HTML, ktorý postupne prechádza a vykresľuje webovú stránku. Niektoré zdroje, zvyčajne obrázky, sa začnú sťahovať v okamihu, keď na ne prehliadač narazí v kóde HTML, takže v praxi to vyzerá tak, že tieto obrázky sú potom darované na hotovej stránke.

Našťastie existuje niekoľko metód, ako zabezpečiť načítanie zdrojov vopred, t. j. nikdy nezobrazovať prázdne miesto na pridanie obrázka, alebo naopak, načítať zdroje až neskôr, keď je to potrebné, a tak neblokovať kľúčové zdroje, ktoré sú potrebné na vykreslenie stránky. Pozrieme sa na základy týchto metód, aby sme vedeli, ako vlastne k optimalizácii pristupovať a ktoré metódy sú už zastarané a môžu v skutočnosti spôsobiť, že sa stránka bude načítavať príliš dlho.

Zastarané metódy optimalizácie v čase HTTP/1

Skôr ako sa dostaneme k tomu, čo robiť pre optimalizáciu, je dobré vedieť, čo nerobiť. Protokol HTTP sa používa na prenos HTML. Má však niekoľko verzií a neustále sa vylepšuje. Dnes už zastaraná verzia protokolu HTTP/1 fungovala tak, že na stiahnutie akéhokoľvek zdroja (obrázka, iného súboru CSS alebo JS alebo čohokoľvek iného) bolo potrebné nadviazať spojenie so serverom, z ktorého sa zdroj sťahoval. Nadviazanie tohto spojenia vždy chvíľu trvá, napríklad kým sa overí bezpečnosť, ale aj kým server vôbec odpovie. Toto sa dialo pre každý zdroj, aj keď z toho istého servera prichádzalo viacero zdrojov.

Optimalizácia sa teda kedysi robila tak, že sa snažila udržať čo najmenší počet požiadaviek na server pre každý zdroj. Všetky súbory štýlov alebo skripty, ale často aj obrázky, sa spojili do čo najmenšieho počtu súborov, čím sa znížil počet požiadaviek na server, pričom každá požiadavka znamenala určité oneskorenie kvôli potrebe nadväzovať nové spojenia.

Problémom bolo, že prehliadač musel stiahnuť všetky zdroje, hoci neboli veľmi dôležité a mohli počkať. Napríklad CSS bol v rámci optimalizácie spojený do jedného súboru, hoci mnohé štýly mohli počkať, pretože ovplyvňujú napríklad pätičku stránky, ktorá mohla v pohode počkať na stiahnutie zdrojov. Každé rozdelenie potom znamenalo dlhší čas sťahovania, takže vždy išlo o niečo za niečo.

Našťastie dnes existuje ďalšia verzia HTTP/2 (alebo ešte novšia a ešte efektívnejšia HTTP/3, ale princíp je v tomto prípade rovnaký), ktorá tento problém odstraňuje. Vďaka protokolu HTTP/2 nemusíme neustále vytvárať nové a nové spojenia s tým istým serverom, aby sme stiahli nové zdroje. Pri jednom vytvorenom pripojení sťahujeme množstvo zdrojov, takže nedochádza k oneskoreniu v dôsledku nových pripojení.

To je dosť podstatný rozdiel, pretože zrazu nič nevadí, že sťahujeme menšie súbory, ktorých je viac. Tým sa mení princíp celej optimalizácie, pretože nejde o kombinovanie súborov, ale o ich inteligentné a efektívne rozdeľovanie a načítavanie v správnom poradí a vtedy, keď ich potrebujeme.

Ako zistiť, cez aký protokol váš server sťahuje zdroje

Nie všetci webhostitelia majú automaticky povolený prenos HTTP/2 alebo HTTP/3

. Pre našu stratégiu optimalizácie rýchlosti webu je však absolútne nevyhnutné vedieť, ktorý protokol sa používa.

Našťastie môžeme protokol ľahko zistiť prostredníctvom prehliadača. Použijeme najčastejšie používaný prehliadač Google Chrome:

1. Spustite prehliadač Google Chrome a prejdite na stránku, kde nás zaujíma použitý protokol
2. Kliknite pravým tlačidlom myši kdekoľvek na tejto lokalite a vyberte položku Preskúmať. Môžeme tiež použiť klávesovú skratku Ctrl + Shift + I (mäkké i)
3. Otvorí sa panel pre vývojárov. Ten je mimochodom skvelý na kontrolu a úpravu kódu HTML, úpravu CSS a mnoho ďalších vecí.
4. Prepnite na kartu Sieť
   
5. Obnovenie stránky (napríklad pomocou klávesovej skratky Ctrl + F5)
6. Na karte Sieť sa začnú zobrazovať všetky zdroje, ktoré sa načítali na zobrazenie stránky. Tu môžeme vidieť samotný dokument HTML, obrázky, súbory štýlov a všetko ostatné, čo bolo potrebné na vykreslenie stránky.

Teraz nás zaujíma hlavne stĺpec Protokol, v ktorom vidíme verziu protokolu HTTP. Ak vidíme, že sa súbory sťahujú z nášho servera pomocou protokolu h2 alebo h2, všetko je v poriadku. Ak vidíme http/1.1, potom sa všetko sťahuje pod zastaraným protokolom HTTP/1.

Takto by to malo vyzerať	Takto by to nemalo vyzerať

Ak vidíme HTT//1, musíme kontaktovať nášho webového hostiteľa a požiadať o zmenu protokolu na HTTP/2 alebo HTTP/3.

Povedal by som, že samotný prechod z HTTP/1 na HTTP/2 alebo 3 je naozaj rozhodujúci pre optimalizáciu rýchlosti webu, a čo je skvelé, v podstate tu nie je čo pokaziť

a stačí kontaktovať svojho webového hostiteľa a požiadať o zmenu. Výrazne urýchli načítanie zdrojov vašej stránky a výrazne zlepší celkový dojem z vašej stránky pre čitateľov a vyhľadávače.

Ak to z nejakého dôvodu nefunguje a webový hostiteľ to odmietne alebo čokoľvek iné, prejdite na iného webového hostiteľa, pretože toto je naozaj základ. Dokonca aj najlacnejšie varianty českých webových hostiteľov fungujú na HTTP/2 štandardne alebo túto zmenu bez problémov umožňujú.

Rýchlosť servera a verzia PHP

Môžete mať najrýchlejšie a najlepšie optimalizované webové stránky, ale keď budete na pomalom serveri/webhostingu, všetko sa bude načítavať pomaly. Výber správneho hostingu je jednoducho nevyhnutný a bez neho sa nepohnete. Otázka, aký hosting je pre vás najlepší, je potom o niečo zložitejšia a závisí od toho, čo vlastne potrebujete, na akých technológiách bude váš web bežať a aké náročné budú aplikácie. Ak potrebujete napríklad hosťovať videá alebo veľké obrázky, bude pravdepodobne vhodné niečo iné, ako keď pôjde o stránku založenú prevažne na texte a článkoch.

Ak vaša stránka pobeží na systéme WordPress, mnohí poskytovatelia hostingu ponúkajú riešenia na mieru, kde v podstate nemusíte robiť veľa, samotný WordPress môžete nainštalovať priamo z administrácie niekoľkými kliknutiami.

To je celkom skvelé, ak nechcete robiť veľa a chcete mať všetko rýchlo nastavené na osvedčenej konfigurácii.

Čo je PHP a prečo záleží na verzii

Ďalším faktorom je verzia PHP. PHP je programovací jazyk, ktorý poháňa väčšinu webových stránok. Napríklad WordPress je na ňom postavený. PHP však existuje v mnohých verziách, pričom čoraz viac verzií je hlavne rýchlejších a bezpečnejších, ale vyžadujú si aj programovacie techniky. V súčasnosti je štandardom, aby webhosting podporoval verziu PHP aspoň 7.4, ideálne tak, aby sme v prípade potreby mohli verziu zmeniť

Tu je potrebné trochu testovania, pretože rôzne doplnky mohli byť vytvorené pre staršie verzie PHP, takže musíme všetko otestovať a prípadne nahradiť nefunkčné funkcie tými, ktoré sú pravidelne aktualizované, a teda fungujú na novších verziách PHP.

Hoci staršie verzie PHP sa dajú z hľadiska rýchlosti vyriešiť napríklad cachovaním stránok, o ktorom píšem nižšie, rozhodne VYHRADNE odporúčam prejsť na novšie verzie, minimálne 7+, ktoré sú nielen rýchlejšie, ale aj bezpečnejšie. A ak niečo nefunguje, riešením by mala byť aktualizácia alebo nahradenie príslušnej funkcie, a nie zostať pri nižšej verzii PHP. A ak niečo nefunguje, mala by sa vyriešiť aktualizácia alebo nahradenie tejto funkcie, a nie zostať na nižšej verzii PHP

Minifikácia HTML, CSS a JavaScript

Keď sa pozeráme na zdrojový kód webovej stránky, pravdepodobne chceme, aby bol jasný a aby sme mu rozumeli. To znamená, že bol riadok po riadku, zdokumentovaný a podľa možnosti zrozumiteľný. Ale počítač nič z toho nepotrebuje. Každý zbytočný komentár v kóde, medzera alebo nový riadok je niečo, čo nemusí byť v kóde na správne zobrazenie stránky, ale je to nejaký kód navyše, ktorý sa musí preniesť cez sieť.

Celý kód by sa dal ľahko napísať na jeden veľmi dlhý riadok a počítače to z hľadiska čitateľnosti nezaujíma.

To isté platí aj pre premenné v programovaní. Chceme ich ľudsky pomenovať, aby sme im porozumeli. Ale počítač to nezaujíma a pre počítač sú to len nejaké textové reťazce. Pokiaľ ide o web, ideálne je používať čo najmenej znakov, čo sa potom prejaví v rýchlejšom webe, pretože jednoducho nie je potrebné prenášať toľko údajov cez internet.

Toto orezávanie a zmenšovanie kódu o nepotrebné znaky sa nazýva minifikácia. Najlepším spôsobom, ako to urobiť, je použiť rôzne doplnky, ktoré automaticky minifikujú stránku. Spravidla sa to robí napríklad v systéme WordPress pomocou prakticky všetkých optimalizačných pluginov, ktoré sa zaoberajú aj ukladaním stránok do vyrovnávacej pamäte.

Kompresia súborov

Všetky zdroje webovej stránky sa prenášajú prostredníctvom počítačovej siete. Takže by sme sa mali veľa zaoberať aj veľkosťou súboru. Pri prenose sa používajú kompresné metódy, pri ktorých sa súbor zabalí do komprimovaného súboru, prenesie sa menší a prehliadač ho opäť rozbalí. Často je to oveľa rýchlejšie ako prenos súborov v plnej veľkosti.

Podobným spôsobom komprimujeme napríklad súbory v počítači do formátov .zip alebo .rar. Pri prenose webových stránok sa najčastejšie používajú kompresné metódy Gzip alebo Brotli (často účinnejšia kompresná metóda vyvinutá spoločnosťou Google).

Zatiaľ čo kompresia Gzip je teraz (dúfajme) absolútnym štandardom, ktorý je podporovaný na každom webovom hostiteľovi, kompresiu Brotli zatiaľ weboví hostitelia nemusia podporovať, hoci ju dnes podporujú všetky hlavné prehliadače.

Vprípade kompresie používanej na webových stránkach je tiež dôležité poznamenať, že bola vyvinutá najmä pre textové súbory. Teda samotný kód HTML, CSS, JS alebo čokoľvek, čo sa posiela ako text. Na druhej strane nie je vhodný pre obrázky jpg, png, dokumenty pdf a podobné súbory, ktoré už boli komprimované.

Preto odporúčam opýtať sa webového hostiteľa, či je kompresia Brotli podporovaná, a prípadne aké kroky je potrebné vykonať. Pri kompresii Gzip je aktivácia celkom jednoduchá a stačí pridať tento kód do súboru .htaccess, ktorý dáva serveru pokyn, aké typy súborov má komprimovať:

AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml

Optimalizácia obrazu

Obrázky sú často najväčšími súbormi z hľadiska prenesených údajov. Aj jeden obrázok môže mať veľkosť niekoľko megabajtov, čo nie je nič nezvyčajné ani pri vysokých rýchlostiach internetu, najmä ak je na stránke veľa obrázkov.

V súvislosti s optimalizáciou by sme sa mali venovať niekoľkým veciam.

Formát obrázka

Obrázky na webe by mali byť zvyčajne vo formáte .jpg (ideálny pre fotografie), .png (ideálny pre ilustrácie) alebo v modernom webovom formáte .webp (vyvinutý spoločnosťou Google a podporovaný v podstate všetkými modernými prehliadačmi), prípadne v ešte modernejšom formáte .avif, ktorý však zatiaľ nie je podporovaný všetkými prehliadačmi.

Môžeme použiť aj iné formáty, ako napríklad .svg, ktorý sa používa ako ľahko škálovateľné ikony, alebo gif, ktorý sa dá použiť hlavne na animované obrázky, alebo použiť formát base64, v ktorom zadáme obrázok v textovej podobe priamo do kódu HTML, ale to je asi tak koniec bežných formátov používaných na webe.

Použitie správneho formátu obrázka má veľký vplyv na to, koľko miesta obrázok zaberie, a tým aj na celkovú rýchlosť webu.

Pretože podpora obrázkov niekedy zlyháva, je tu veľký prvok obrázok, do ktorého sa umiestnia obrázky vo viacerých formátoch, a potom prehliadač prechádza formáty obrázkov jeden po druhom, a ak nepozná formát, jednoducho použije iný, ktorý už pozná. Takto sa dajú veľmi rýchlo použiť aj úplne moderné formáty, ktoré prehliadače, ktoré ich podporujú, použijú a prehliadače, ktoré ich nepoznajú, zobrazia nejaký štandardnejší formát jpg alebo png. Viac informácií o obrázkovom prvku s príkladmi nájdete tu.

Rozmery obrázkov

Ak používame obrázky, mali by sme použiť správne rozmery. Napríklad môžeme načítať obrázok v kóde HTML v plnej veľkosti 1000x700px, ale umelo ho zmenšiť na veľkosť 300x200px. Prehliadač skutočne zobrazí menší obrázok, ale najprv musí stiahnuť obrovský súbor, ktorý je mnohonásobne väčší ako skutočne potrebný malý obrázok.

Redakčné systémy to zvyčajne riešia tak, že po nahratí obrázka do systému automaticky vytvoria jeho verzie v rôznych veľkostiach, ktoré sa potom použijú na stránke v rôznych prvkoch, aby sa nenačítali obrovské súbory.

Pri práci s veľkosťou obrázkov by sme mali v kóde HTML vždy definovať, ako veľký obrázok sa zobrazuje. Zahrňte teda atribúty šírka a výška. Napríklad:

<img src="obrazek.jpg%20width="500" height="300">

Všimnite si, že atribúty neobsahujú veľkosť (napr. 500px), ale len číslo. Skutočný rozmer, ktorý zapisujeme do atribútov, je vždy v pixeloch, ale nepíšeme px.

Prehliadač potom vie, koľko miesta má podľa týchto atribútov vyhradiť pre obrázok na stránke, a nedochádza k žiadnym podivným posunom obsahu, pri ktorých by sa po načítaní obrázok presunul za obsah, ale na stránke je vyhradené miesto s rozmermi atribútov width/height, ktoré obrázok dosiahne po stiahnutí. Môžeme potom prechádzať po stránke a nestane sa, že používateľ chce niekde kliknúť, ale obrázok posunie miesto na kliknutie inam, alebo čitateľ klikne inde, ako pôvodne chcel.

Preto by sme mali tieto atribúty vždy pridať k obrázkom a potom načítať obrázok v správnej veľkosti. Takže by sme nemali načítať obrázok s rozmermi 2000x1000px do veľkosti 200x100px. Systém by mal vytvoriť správnu veľkosť veľkého obrázka a potom ho načítať do menšieho priestoru, a nie načítať obrovský obrázok a potom ho umelo zmenšiť samotným prehliadačom.

Kompresia obrazu

Kompresia obrázkov v podstate trochu zníži kvalitu samotného obrázka, ale môže tiež veľmi výrazne znížiť veľkosť súboru. Môžete komprimovať aj bezstratovo, čo znamená, že kvalita obrázka sa zachová až do posledného pixelu, ale súbor sa zvyčajne nezmenší natoľko, aby sa zmenšil.

Ak nemáte stránku založenú len na dokonalých fotografiách, určitá úroveň stratovej kompresie je zvyčajne úplne v poriadku a určite by ste mali mať na stránke nejaký mechanizmus, ktorý optimalizuje obrázky pri ich nahrávaní. Toto je presne ten typ veci, ktorú je najlepšie raz nastaviť a potom na ňu zabudnúť.

Lazy loading

Veľmi užitočná vec. Lazy Loading (nielen obrázky) načíta zdroj len vtedy, keď je to naozaj potrebné. Ak sa obrázok nachádza v spodnej časti stránky, nie je potrebné ho skutočne sťahovať, kým používateľ neposunie stránku na spodok. Toto oneskorené načítavanie obrázkov sa nazýva Lazy Loading.

Správne nasadenie sa riešilo rôznymi spôsobmi, ale našťastie dnes je Lazy Loading natívne podporovaný priamo všetkými hlavnými prehliadačmi, alebo aspoň čoskoro bude. Z nášho pohľadu musíme na obrázky nasadiť atribút loading=“lazy“, ktorý prehliadaču povie, aby obrázok načítal len vtedy, keď je to potrebné. Vyzerá to napríklad takto:

<img src="pes.jpg%20loading="lazy" width="500" height="600">

To je v podstate všetko a nemusíme riešiť žiadne ďalšie problémy, ani inštalovať žiadne knižnice javascriptového kódu s lenivým načítaním alebo niečo podobné. Ak niekto práve prichádza na našu stránku a používa veľmi starý prehliadač, obrázok sa stále načíta, len nie pomocou funkcie Lazy Loading.

Cache

Medzipamäť si možno predstaviť ako údaje, ktoré sa kopírujú a ukladajú na neskoršie použitie. Existuje mnoho druhov vyrovnávacej pamäte, ale my sa pozrieme len na vyrovnávaciu pamäť, ktorá je pri prehliadaní webu nevyhnutná a s ktorou môžeme reálne niečo urobiť, ak nám ide o zrýchlenie nášho webu.

Vyrovnávacia pamäť prehliadača

Niektoré súbory, ktoré prehliadač stiahne, sa uložia do počítača a prehliadač ich ďalej používa bez toho, aby ich znova stiahol. Ušetríte tak množstvo prenosov súborov, ktoré sú rovnaké na každej stránke daného webu. Zvyčajne ide o logo stránky, písma a mnohé obrázky. Preto sa pri prvej návšteve webovej stránky načítava o niečo dlhšie – všetko sa musí stiahnuť, zatiaľ čo po kliknutí je už všetko rýchlejšie – prehliadač používa už stiahnuté zdroje. Nazýva sa vyrovnávacia pamäť prehliadača.

Z pohľadu používateľa to všetko viac-menej vykonáva prehliadač. Z pohľadu vlastníka stránky je však potrebné prehliadaču povedať, ako dlho má zdroje uchovávať, kým ich bude musieť znova stiahnuť. Používateľ, ktorý niekedy vymaže vyrovnávaciu pamäť, môže normálne pokračovať v prístupe na stránku, ale prehliadač všetko stiahne znova.

Nastavenie je opäť pomerne jednoduché a do súboru .htaccess môžete pridať nasledujúci kód, ktorý je prevzatý priamo z GTMetrix, testera rýchlosti webu. Písma, obrázky alebo videá môže prehliadač ukladať do vyrovnávacej pamäte na rok, štýly a skripty na mesiac. Ak chcete, môžete tieto obdobia ľubovoľne meniť.

ExpiresActive On
# Images
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
# Video
ExpiresByType video/webm "access plus 1 year"
ExpiresByType video/mp4 "access plus 1 year"
ExpiresByType video/mpeg "access plus 1 year"
# Fonts
ExpiresByType font/ttf "access plus 1 year"
ExpiresByType font/otf "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType application/font-woff "access plus 1 year"
# CSS, JavaScript
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
# Others
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType image/vnd.microsoft.icon "access plus 1 year"

Stránka vyrovnávacej pamäte

V tomto prípade je situácia trochu zložitejšia, preto sa na ňu pozriem zo širšieho hľadiska. Webová stránka sa vždy posiela ako dokument HTML. Obsahuje odkazy na iné zdroje, ako sú obrázky, skripty alebo súbory štýlov, a niekedy môže byť stránka vykreslená v prevažnej miere pomocou JavaScriptu. HTML je však základ.

Tento dokument HTML sa však takmer určite vytvára dynamicky pomocou nejakej technológie na serveri, takže nejde o statický dokument, ktorý by sme mohli vytvoriť v Poznámkovom bloku. Najčastejšie je to technológia ako PHP + databáza, ale môže to byť aj kombinácia rôznych vecí. Podstatné je, že tieto technológie musia nakoniec vytvoriť dokument HTML, ktorý sa potom zobrazí v prehliadači. A spôsob, akým sa skladá dokument, je určený adresou URL. Niektoré časti stránky sú teda stále rovnaké (logo, menu, päta stránky), zatiaľ čo iné sa menia (obsahová časť stránky).

Ak teda navštívime webovú stránku, server, na ktorom sa webová stránka nachádza, v skutočnosti dynamicky zostaví dokument HTML pomocou rôznych technológií podľa našej požiadavky a odošle ho prehliadaču, ktorý ho potom preloží a zobrazí v čitateľnej podobe ako webovú stránku.

Je to praktické z toho hľadiska, že ak by sme našu stránku uložili ako stovky alebo tisíce dokumentov HTML, každá drobná zmena, ktorú by sme na stránke vykonali, by sa musela zmeniť pre každý súbor. Takto môžeme zmeniť všetko v podstate na jednom mieste, stačí kódovať a programovať. Opäť niečo za niečo. Problémom je aj to, že zostavenie kódu HTML pre server chvíľu trvá a zaťažuje aj server. Pri návšteve danej adresy URL sa musí spracovať všetok kód, ktorý generuje HTML. To zaberá čas a zaťažuje samotný server.

Riešením je vytvorenie tzv. vyrovnávacej pamäte stránok. Keď niekto príde na našu webovú lokalitu, server použije niektoré svoje mechanizmy na zostavenie kódu HTML. Potom však uloží hotový kód, a ak chce tú istú webovú stránku zobraziť niekto iný, server kód HTML znovu nezostaví, ale odošle hotovú verziu.

To má zmysel, ak je webový obsah statický v tom zmysle, že každý používateľ vidí rovnaký obsah na danej adrese URL alebo sa mu zobrazuje rovnaký kód HTML.

Stránky sa teda nevytvárajú pre každého používateľa inak, ako to robí Facebook alebo iné sociálne siete, na základe záujmov, pridaných priateľov, sledovaných stránok atď… Štandardný blog alebo časopis je statický, takže ukladanie do vyrovnávacej pamäte má zmysel.

Problém je vo vytváraní tejto vyrovnávacej pamäte stránky, kde potrebujete len nástroj. Je tu pomerne veľa technických vecí, ktoré treba riešiť, automatické mazanie vyrovnávacej pamäte pri zmene obsahu atď.

Vo WordPress je všetko pomerne jednoduché a riešia to bezplatné pluginy ako W3 Total Cache, WP Super Cache alebo prémiový platený plugin WP Rocket.

WP Rocket mimochodom veľmi pekne zvláda mnohé technické aspekty, ktorým sa venujem v tomto článku, takže takmer všetky chyby môžete vyriešiť jedným záberom, aj keď nemusíte chcieť vedieť všetko dokonale a podrobne. Je to len platený doplnok, ktorý si pravdepodobne nebudete chcieť kúpiť hneď na začiatku, ale ak je váš blog už spustený a niečo zarába, WP-Rocket vám ušetrí dosť času.

Optimalizácia JavaScriptu

Nebudem sa tu úplne venovať optimalizácii z hľadiska samotného písania kódu. CSS aj JS by mali byť napísané efektívne, čo je pravdepodobne zrejmé. Dôležité je však aj to, kedy a čo presne sa načíta.

Umiestnenie JavaScriptu

JavaScript pridáva zaujímavé funkcie, ale zároveň môže spôsobiť, že web bude dosť neprehľadný. Zle napísaný, objemný alebo umiestnený JavaScript môže používateľom výrazne znížiť rýchlosť webu. Pozrieme sa na relatívne jednoduché metódy práce s JavaScriptom, aby čo najmenej spomaľoval web.

Ako bolo uvedené na začiatku tohto článku, prehliadač si stiahne kód HTML a začne ho postupne spracovávať. V prípade obrázkov sa tieto zdroje sťahujú súbežne s inými zdrojmi, ale v prípade JavaScriptu to funguje inak. Keď prehliadač narazí na súbor s kódom JavaScript, stiahne súbor, spracuje všetky skripty a potom pokračuje v spracovaní kódu HTML. Ak teda na začiatok kódu HTML umiestnime obrovský súbor alebo knižnicu, ktoré sa musia spracovať ako prvé, úplne tým zničíme rýchlosť nášho webu, pretože prehliadač bude potrebovať veľa času na spracovanie. Čo s tým?

JavaScript sa niekedy používa na vytvorenie samotného kódu HTML, ale častejšie sa v prípade klasických blogov používa len na pridanie rôznych funkcií, ktoré nie sú v prvej sekunde načítania stránky dôležité. Preto je celkom bežnou praxou umiestňovať JavaScript na úplný koniec kódu HTML, zvyčajne prostredníctvom uzatváracieho tagu </body>.

Acync a JavaScript defer

Umiestnenie JavaScriptu na koniec dokumentu je jednou z možností, ktorú odporúčam, ale našťastie existujú prípady prehliadačov, kde to nie je úplne nevyhnutné. Tieto pokyny sú acync alebo defer. V kóde by potom vyzerali takto:

<script async src="script.js"></script>

alebo

<script defer src="script.js"></script>

Pri načítavaní klasického JS bez atribútov async alebo defer prehliadač zastaví vykresľovanie dokumentu HTML, stiahne JS, spustí skripty a po dokončení opäť začne vykresľovať HTML. Atribúty async a defer dávajú prehliadaču pokyn, aby s JavaScriptom zaobchádzal trochu inak.

• Async– Ak prehliadač narazí na JS s týmto atribútom, začne sťahovať súbor, ale počas sťahovania bude stále vykresľovať dokument HTML. Až po stiahnutí JS sa zastaví vykresľovanie HTML, spracujú sa skripty v súbore a potom sa obnoví vykresľovanie HTML.
• Defer– JavaScript sa stiahne počas vykresľovania kódu HTML. Samotné skripty sa spracujú po dokončení vykresľovania HTML.

Pekne to vidíte na obrázku:

V praxi je až na niekoľko výnimiek v poriadku odložiť všetky JavaScripty, t. j. spustia sa až po úplnom vykreslení dokumentu HTML

. Ďalšou skvelou výhodou je, že prehliadač si pamätá poradie, v akom sa stretol s odloženým JS, a po vykreslení dokumentu HTML ich vykoná v správnom poradí, v akom boli súbory umiestnené v kóde HTML. To je skvelé, keď niektoré súbory závisia od iných (typicky napríklad načítame knižnicu s funkciami typu jQuery a potom náš JavaScript, ktorý túto knižnicu používa – ak je JS v našom kóde umiestnený v správnom poradí, odkladanie zabezpečí, že knižnica bude správne spracovaná pred ostatnými skriptami, ktoré potrebujú túto knižnicu na fungovanie).

Odloženie je teda pravdepodobne najlepší spôsob, ako načítať JavaScript, ktorý nie je potrebný na vykreslenie kľúčových častí dokumentu HTML, ale ktorý len pridáva neživotne dôležité funkcie alebo časti stránky, ktoré môžu chvíľu počkať.

Naproti tomu asynchrónny režim má tú nevýhodu, že nikdy nevieme, kedy sa súbor so skriptom stiahne a začne spracovávať. To je užitočné, keď skripty s atribútom async nie sú závislé od žiadnej knižnice alebo iného JS, ale zároveň nechceme čakať na úplné vykreslenie HTML pred spracovaním skriptov. Preto sa pri zobrazovaní reklamných blokov bežne používa funkcia async. JS sa stiahne a neblokuje vykresľovanie HTML, ale po stiahnutí súboru sa spracuje, a tak sa reklamy zobrazia čo najskôr, čo je žiaduce.

V praxi teda chceme JS umiestniť čo najnižšie v dokumente HTML, aby sťahovanie neblokovalo sťahovanie iných zdrojov + na tento JS ešte umiestnime atribút defer. Ak potrebujeme, aby sa JS spracoval čo najskôr, umiestnime ho podľa potreby do dokumentu a poskytneme atribút async, ktorý neblokuje vykresľovanie HTML počas sťahovania, ale spracuje ho čo najskôr.

Optimalizácia CSS

Keďže používame protokol HTTP/2, nie je žiaduce spojiť všetky štýly do jedného súboru, ale vytvoriť viacero súborov a umiestniť ich postupne do dokumentu podľa potreby. Nie je potrebné okamžite načítať štýly, ktoré riešia vzhľad úplne spodnej časti stránky, kde používateľ určite nebude niekoľko sekúnd. Naopak, bola by to chyba, pretože stiahnutím a spracovaním týchto štýlov by sme zablokovali iné zdroje, ktoré sú potrebné hneď.

Kritická cesta CSS

Takzvaná kritická cesta CSS je veľmi dôležitá. Ide o štýly, ktoré sú absolútne nevyhnutné na správne zobrazenie stránky, ktorú používateľ vidí bez posúvania myšou alebo posúvania obrazovky na mobilnom telefóne. Táto horná časť stránky sa v angličtine nazýva above-the-fold.

Tieto kritické štýly musia byť umiestnené čo najnižšie v kóde HTML, zvyčajne niekde medzi značkami <head>, pretože sú kľúčom k najlepšiemu používateľskému zážitku. Keďže ide o menší súbor alebo štýly vložené priamo do kódu HTML, neblokujú ďalšie vykresľovanie stránky, ako by sa to stalo v prípade jedného veľkého súboru štýlov, ktorý by sa musel najprv stiahnuť celý a potom spracovať.

Dlhšie sťahovanie blokuje vykresľovanie obsahu a môže viesť k rôznym zmenám vzhľadu, čo jednoducho nevyzerá dobre. S kritickými štýlmi je prvý dojem zo stránky oveľa lepší, pretože sa načíta len to, čo je skutočne potrebné, takže aj stránka sa v ideálnom prípade načíta takmer okamžite.

Pozor, pri generovaní kritických štýlov je potrebné trochu testovania. Existujú nástroje, ktoré dokážu extrahovať kritické štýly

a potom ich môžete umiestniť na stránku. Ideálne však je, ak tieto štýly dodáva priamo tvorca webu alebo šablóny, pretože potom sa vždy ľahšie udržiavajú a aktualizujú. Nehovoriac o tom, že bývajú presnejšie a dokážu sa zamerať na všetky typy stránok, ktoré máte na svojom webe. Kritické štýly sa zvyčajne líšia napríklad na domovskej stránke a na stránke článku.

Zbavte sa prebytočných štýlov a skriptov

Toto je strašiak WordPress a najmä stránok, ktoré majú nainštalovaných veľa rozšírení. Stránka je nakoniec zahltená množstvom nadbytočných štýlov a skriptov, čo ju len spomaľuje. Mnohé z týchto dodatočných súborov vôbec nie sú potrebné na každej stránke.

Celkom klasickým príkladom je formulár na zhromažďovanie kontaktných informácií alebo na všeobecné kontaktovanie redakčného tímu. Skripty a štýly pre tento formulár potrebujete len na stránke, kde sa formulár skutočne nachádza (čo môže byť len jedna stránka webu), ale autori formulára môžu natvrdo načítať všetky skripty a štýly na všetkých stránkach webu bez ohľadu na to, či sa na nich formulár nachádza alebo nie, čo je jednoducho zbytočné a len to nafúkne web a spomalí ho.

Uznávam, že je jednoduchšie načítať všetko na každej stránke a potom nemusíte nič riešiť, čo stále nie je taká katastrofa, keď nemáte stránku preplnenú funkciami, ale stále je to čistejšie a pre používateľov príjemnejšie, keď nemusia sťahovať súbory, ktoré nepotrebujú, kvôli funkciám, ktoré na stránke ani nie sú.

Ako zvyčajne, odporúčam riešenie WordPress v podobe pluginu Asset CleanUp, ktorý rieši presne tento problém. Dokonca aj v bezplatnej verzii môžete svoje stránky vyčistiť od prebytočných štýlov a skriptov.

Môžete ich napríklad zakázať všade, ale vytvoriť výnimku pre tie stránky, kde sú potrebné, alebo ich naopak zakázať po jednotlivých stránkach. Platená verzia potom ponúka viac funkcií, ako je detekcia zariadenia a následné (ne)načítanie podľa toho, či je používateľ na mobile, tablete alebo počítači, ale pravdupovediac, bezplatnú verziu považujem za dostatočne dobrú a hlavne veľmi prístupnú aj pre technicky neznalých majiteľov stránok, kde je jasne a zreteľne vidieť, čo zakazujeme a ktorý skript alebo štýl patrí ku ktorému doplnku alebo šablóne.

Predvyplnenie zdrojov

Ak vieme, že budeme potrebovať určité zdroje, napríklad obrázky alebo písma, môžeme dať prehliadaču pokyn, aby ich stiahol vopred a potom ich okamžite použil. Prefetching je dvojsečná zbraň, pri ktorej si musíme vybrať, ktoré zdroje za to naozaj stoja a ktoré prefetchovať nechceme.

Vo všeobecnosti by sme sa mali zaoberať predbežným načítaním obsahu na samom vrchu stránky, t. j. nad záhybom. Zvyčajne ide o logo stránky, úvodný obrázok a písmo(-á) používané na stránke. Podobne nemá zmysel uvádzať prefacky zdrojov, ktoré sa na stránke nepoužívajú. Na druhej strane sa tým načítanie zdrží, pretože sa stiahne niečo, čo nie je potrebné, a dokonca prehliadače budú v konzole trochu reptať, že niektoré zdroje sa v prvých sekundách nepoužili a že by sme ich nemali vopred načítať.

Všetok kód umiestnime medzi značky <head>, kde to má zmysel. Nemá zmysel prefetovať zdroje, na ktoré prehliadač aj tak okamžite narazí a stiahne ich klasickým spôsobom. Ide teda o prefetovanie prostriedku, ktorý je v kóde niekedy neskôr, ale chceli by sme mať tento prostriedok pripravený čo najskôr.

Kódy pre prednačítanie zdrojov môžu vyzerať takto:

Predbežné načítanie písma:

<link rel="preload" href="arial.woff2" as="font" type="font/woff2" crossorigin>

Odporúčam zahrnúť atribút type. Takto prehliadač okamžite zistí, o aký formát súboru ide, a ak tento formát nepodporuje, zdrojový kód nestiahne. Odporúčam prednahrávať písma len vo formáte woff2, ktorý dnes podporujú všetky hlavné prehliadače. Je dobré mať záložný formát woff pre používateľov Internet Explorera, ale toto písmo vopred nenahrávať.

Predbežné načítanie obrázkov:

<link rel='preload' as='image' href='logo.png'>

Určite to nepreháňajte a používajte ho len pre zdroje, o ktorých viete, že ich budete potrebovať veľmi rýchlo po zobrazení stránky. Ak vopred načítate zdroje, ktoré nemajú zmysel, môžete dokonca spomaliť stránku, pretože prehliadač uprednostní veci v okamihu, keď nie sú potrebné.

Príprava na pripojenie k inej doméne

Zdroje často sťahujeme z inej domény. Môže ísť o javascriptové knižnice/frameworky, fonty Google alebo dokonca reklamné bloky. Keď sťahujeme niektorý z týchto zdrojov z cudzej domény, prehliadač musí vždy nadviazať spojenie a stiahnuť zdroj. Chvíľu však trvá, kým sa vytvorí spojenie.

Našťastie môžeme prehliadaču vopred povedať, že sa chystáme neskôr niečo stiahnuť z domény, takže je možné vopred nadviazať spojenie, aby potom mohol jednoducho stiahnuť zdroj bez toho, aby musel nadviazať nové spojenie.

Vo všeobecnosti sa používajú metaznačky dns-prefetch a preconnect, pričom preconnect vytvára kompletné pripojenie, ale (ako zvyčajne) nie je podporovaný prehliadačom Internet Explorer. funkcia dns-prefetchvytvorí len časť spojenia, ale je podporovaná všetkými prehliadačmi.

V praxi je možné použiť obe tieto značky naraz, pričom prehliadače, ktoré nepodporujú preconnect, môžu použiť aspoň dns-prefetch. Tento postup odporúča aj spoločnosť Mozilla.

Treba tiež povedať, že funkcie preconnect a dns-prefetch sa používajú vtedy, keď vieme, že budeme sťahovať z nejakého zdroja, ale ešte nepoznáme presnú adresu URL, z ktorej budeme zdroj sťahovať. Je to napríklad prípad reklám AdSense alebo iných reklamných programov a sietí, alebo písiem Google.

<link rel="preconnect" href="/assets/vendor/googleapis/" crossorigin>
<link rel="dns-prefetch" href="/assets/vendor/googleapis/">

Atribút crossorigin v podstate hovorí, že zdroj môže byť zdieľaný medzi viacerými doménami. Potom si ako URL zdrojového prefixu všimnite, že neuvádza http alebo https, ale len to, čo nasleduje za ním, čo pokryje akýkoľvek protokol.

Je to všetko?

Nie je a nebude. Web je každý trochu iný a vyžaduje si inú starostlivosť. Táto rada je veľmi všeobecná, ale ak ju budete dodržiavať, vaša stránka bude jednoducho rýchlejšia, čo je lepšie pre vás aj vašich čitateľov/zákazníkov.

Uvedené optimalizačné techniky sú veľmi všeobecné, ale myslím si, že ich môže pohodlne nasadiť v podstate každý web a že sa zvýši rýchlosť webu. Samozrejme, ku všetkému je potrebné pristupovať situačne, čo sa týka najmä umiestnenia CSS a JS, prípadne odloženia/asynchronizácie JS. Na druhej strane neriešim veci typu, že stránka by mala byť efektívne naprogramovaná, čo beriem tak trochu ako klamstvo a tu by bola potrebná veľmi dôkladná práca a znalosť zdrojového kódu, kde je potom riešenie naozaj komplikované a nedá sa nijako zovšeobecniť.

Ak sa chystáte nasadiť vyššie uvedené techniky optimalizácie, vrelo odporúčam, aby ste si všetko starostlivo zálohovali a aby ste všetko robili postupne. Občas použijete zásuvný modul na niečo, čo môže trochu narušiť stránku, kde môže prepísať štýly alebo skripty, a potom niečo vyzerá inak alebo nefunguje. Vždy je dobré vedieť, čo ste práve urobili a či všetko funguje, než prejdete na niečo iné. Je potom jednoduchšie zistiť, čo spôsobilo problém, ako keď nasadíte 10 zmien a potom skúmate, ktoré môžu alebo nemusia byť zodpovedné za vzniknutý problém.