Klient mi napíše „web je pomalý, sprav s tým niečo" a očakáva, že na to mám jedno tlačidlo. Nemám. Pomalý web je symptóm, nie diagnóza — a kým nevieš, kde presne to viazne, tak len strieľaš naslepo (čo, priznám sa, robím tiež, ale len po druhej káve). Poďme to teda spraviť poriadne: najprv zistíme, kde je problém, a potom ho riešime.
Najprv otázka za milión: server, alebo frontend?
Toto je rozcestník, ktorý ti ušetrí hodiny. Pomalosť webu má v zásade dve domény: server (backend) — kým ti vôbec príde prvý bajt odpovede — a frontend — čo sa deje v prehliadači, kým sa stránka vykreslí.
Najjednoduchšie meradlo na rozlíšenie je TTFB (Time to First Byte) — čas od požiadavky po prvý prijatý bajt odpovede. Podľa web.dev sa TTFB skladá z piatich fáz: presmerovaní, štartu service workera, DNS lookupu, nadviazania spojenia a TLS, a samotnej fázy požiadavky (web.dev). Inými slovami: TTFB je hlavná podozrivá pre serverovú stranu.
Najrýchlejší test bez akéhokoľvek nástroja — curl:
Ak je time_starttransfer (to je v praxi TTFB) vysoký a time_total je len o kúsok vyšší, problém je na serveri. Ak je TTFB nízky, ale celkové načítanie pomalé, hľadaj vo frontende — obrázky, JavaScript, fonty. Pravidlo palca: rieš to, čo dominuje.
TTFB a hosting: kde sa míňa čas ešte pred prvým bajtom
Koľko je „dobre"? web.dev hovorí jasne: väčšina webov by mala mať TTFB 0,8 sekundy alebo menej, a nad 1,8 sekundy je to už zlé (web.dev). Ak ti curl ukazuje TTFB cez sekundu na obyčajnej stránke, niečo je zhnité v štáte dánskom.
Príčiny vysokého TTFB sú zvyčajne:
- Preťažený shared hosting — na jednom serveri sedíš s tisíckou ďalších webov a „sused" ti zožerie CPU.
- Žiadna page cache — server generuje celú stránku nanovo pri každej požiadavke (o tom nižšie).
- Pomalé spracovanie PHP alebo databázy — backend jednoducho dlho ráta.
- Zlá geografická vzdialenosť — server v USA, návštevníci na Slovensku.
Na WordPresse je najčastejší vinník absencia cache. Keď web generuje HTML pri každom requeste z PHP a databázy namiesto toho, aby servíroval hotový súbor, TTFB letí hore.
Core Web Vitals: LCP, INP, CLS a čo s nimi
Keď je TTFB v poriadku, ale „pocitovo" je web stále pomalý, si vo frontende. Google to meria cez Core Web Vitals — tri metriky, ktoré navyše vplývajú aj na hodnotenie pri vyhľadávaní. Odporúčané hranice (priamo od Googlu):
- LCP (Largest Contentful Paint) — meria načítanie, cieľ je do 2,5 sekundy (Google). Najväčší prvok (zvyčajne hero obrázok alebo nadpis) by sa mal vykresliť rýchlo. Lieky: zmenšiť a lazy-loadovať obrázky, servírovať WebP/AVIF, predzaťažiť kritický obrázok, znížiť TTFB.
- INP (Interaction to Next Paint) — meria odozvu na interakciu, cieľ je menej ako 200 milisekúnd (Google). Keď klikneš a nič sa „dlho" nedeje, vinník je obvykle ťažký JavaScript. Lieky: menej skriptov, defer/async, vyhodiť nepotrebné pluginy.
- CLS (Cumulative Layout Shift) — meria vizuálnu stabilitu, cieľ je menej ako 0,1 (Google). To je to nepríjemné poskakovanie obsahu počas načítania. Lieky: pevne definované rozmery obrázkov a reklám, rezervovať miesto pre dynamický obsah.
Dôležité: LCP vieš čiastočne zlepšiť aj na serveri (nižší TTFB = skorší začiatok vykresľovania), ale INP a CLS sú takmer čisto frontendová robota. Žiadny upgrade hostingu ti neopraví poskakujúci layout.
PHP verzia a OPcache: najlacnejšie zrýchlenie, aké existuje
Toto je moja obľúbená situácia, lebo riešenie je často „klikni a hotovo". Veľa WordPress webov beží na zastaranej verzii PHP, ktorá je pomalšia a — čo je horšie — už nedostáva bezpečnostné záplaty.
Ako si overíš verziu PHP? Najrýchlejšie cez CLI:
Ak nemáš SSH prístup, hoď si do koreňa webu súbor info.php s obsahom <?php phpinfo();, otvor ho v prehliadači a po kontrole hneď zmaž (vážne, zmaž ho — vyzrádza o serveri viac, než je zdravé). Na WordPresse vidíš verziu aj v Nástroje → Stav stránky → Info.
Ktorá verzia je „aktuálna"? Podľa oficiálneho prehľadu PHP majú v čase písania aktívnu podporu PHP 8.4 a 8.5, pričom 8.4 má aktívnu podporu do 31. 12. 2026. PHP 8.2 a 8.3 sú už len v režime bezpečnostných opráv (php.net). Ak beží web na niečom starom z rady 7.x, si dávno za hranicou podpory — upgrade rieši aj výkon, aj bezpečnosť naraz.
K verzii patrí OPcache — rozšírenie, ktoré drží prekompilovaný PHP bytecode v pamäti, takže ho server neparsuje pri každej požiadavke. Či beží, overíš jednou riadkou:
Ak je opcache.enable => On, máš to. Ak nie a vieš editovať konfiguráciu, zapneš ho v php.ini:
Na slušnom managed hostingu to máš zapnuté automaticky. Na lacnom shared niekedy nie.
Databáza a object cache: keď za to môžu dotazy
Ak je PHP svieže a cache beží, ale TTFB stále vysoký, pozri sa na databázu. Na WordPresse to typicky znamená pomalé alebo nadbytočné SQL dotazy — často kvôli zle napísanému pluginu, ktorý pri každom načítaní robí desiatky requestov.
Diagnostika na WordPresse: zapni si plugin Query Monitor, ktorý ti ukáže počet dotazov, ich čas a ktorý plugin ich generuje. Keď vidíš jeden dotaz, čo žerie 300 ms, máš vinníka.
Druhá vec je persistent object cache. WordPress má vstavanú object cache, ale predvolene je iba „per-request" — výsledky dotazov si nepamätá medzi načítaniami. S Redisom alebo Memcached ich uložíš do pamäte a opakované dotazy sa neopakujú. Rozdiel na databázovo náročných weboch (e-shopy, členské sekcie, weby bez plnej page cache) býva citeľný. Object cache nie je to isté ako page cache — page cache servíruje hotové HTML, object cache zrýchľuje generovanie toho HTML.
CDN a cache: dva rôzne nástroje, často zamieňané
Page cache ukladá vygenerované HTML stránky, aby ich server nemusel skladať nanovo. To je tvoja prvá obrana proti vysokému TTFB na WordPresse. Rieši to plugin (napr. typu full-page cache) alebo to robí server na úrovni Nginx/Varnish. Bez nej platíš PHP a databázou za každú jednu návštevu.
CDN (Content Delivery Network) je o niečom inom: distribuuje statický obsah (obrázky, CSS, JS) na servery rozmiestnené po svete, takže návštevník ich tiahne z najbližšieho uzla. Tým znižuje latenciu a odbremení tvoj server. CDN pomôže najmä, ak máš návštevníkov z viacerých krajín alebo veľa statiky.
Praktická postupnosť, ktorú odporúčam: najprv page cache (najväčší efekt na TTFB), potom optimalizácia obrázkov a frontendu, a CDN ako čerešnička. CDN ti neopraví pomalé PHP — len rozdistribuuje to, čo už máš.
Kedy už shared hosting nestačí
Shared hosting je super, kým nezačne byť limitom. Znaky, že si z neho vyrástol:
- TTFB sa nedá dostať pod kontrolu ani s cache a aktuálnym PHP — server je jednoducho preťažený susedmi.
- Návštevnosť rastie a v špičkách web padá alebo extrémne spomalí.
- Potrebuješ Redis/Memcached, vlastnú PHP konfiguráciu alebo OPcache nastavenia, ktoré shared neumožňuje.
- Beží ti e-shop alebo členská sekcia — teda veľa nenacacheovateľných, dynamických požiadaviek.
V tom momente dáva zmysel VPS (kde máš vyhradené zdroje a plnú kontrolu) alebo managed WordPress hosting (kde cache, object cache a aktuálne PHP máš vyladené bez toho, aby si bol admin). Ktoré z toho — záleží, či chceš spravovať server sám, alebo chceš mať pokoj.
Záver: postupuj od príčiny, nie od symptómu
Zhrnutie postupu, ktorý reálne funguje: zmeraj TTFB cez curl → ak je vysoký, rieš server (cache, PHP, databáza); ak nízky, rieš frontend (Core Web Vitals). Skontroluj verziu PHP a OPcache. Pridaj page cache. Pri databázovo ťažkých weboch nasaď object cache. CDN ako doplnok. A keď narazíš na strop shared hostingu, je čas na VPS alebo managed WordPress.
Ak zvažuješ presun na výkonnejšie riešenie, porovnaj WordPress hosting a VPS a vyber podľa toho, koľko kontroly chceš mať v rukách.
FAQ
Ako rýchlo zistím, či je problém na serveri alebo vo frontende?
Zmeraj TTFB príkazom curl (pole time_starttransfer). Ak je vysoký, problém je na serveri; ak je nízky a web sa aj tak načítava pomaly, hľadaj vo frontende. Cieľ pre TTFB je podľa web.dev 0,8 sekundy alebo menej (web.dev).
Aké sú odporúčané hodnoty Core Web Vitals?
LCP do 2,5 sekundy, INP menej ako 200 milisekúnd a CLS menej ako 0,1 (Google).
Akú verziu PHP mám používať?
Čo najaktuálnejšiu z podporovaných. Aktívnu podporu majú PHP 8.4 a 8.5, zatiaľ čo 8.2 a 8.3 sú už len v režime bezpečnostných opráv (php.net). Staršie verzie aktualizuj kvôli výkonu aj bezpečnosti.
Aký je rozdiel medzi page cache a object cache?
Page cache ukladá hotové HTML celej stránky, takže ju server nemusí generovať nanovo. Object cache (Redis/Memcached) ukladá výsledky databázových dotazov a zrýchľuje samotné generovanie stránky. Sú to doplnkové nástroje, nie náhrada jeden za druhý.
Pomôže CDN na pomalý WordPress?
CDN zrýchli doručenie statiky (obrázky, CSS, JS) a odbremení server, najmä pri medzinárodnej návštevnosti. Neopraví však pomalé PHP ani databázu — na to slúži cache a optimalizácia backendu.
Kedy mám prejsť zo shared hostingu na VPS?
Keď sa TTFB nedá zlepšiť ani s cache a aktuálnym PHP, web padá v špičkách, potrebuješ Redis či vlastnú PHP konfiguráciu, alebo prevádzkuješ e-shop s množstvom dynamických požiadaviek.
