Pomalý web: co zkontrolovat dřív než začnete kupovat nový hosting?

Čím dál častěji se ke mě dostávají weby, které potřebují zrychlit. Někdy se načítají až neuvěřitelně pomalu, rekord mám zatím asi minutu a půl na jednu stránku. Nekecám. A pomalý web často svádí k rychlému řešení: koupit lepší hosting. Jenže hosting bývá někdy až poslední viník, ne hned první příčina problému.

Důležité tipů, na co se zaměřit při revizi rychlosti webu, jsem sepsala v článku už dříve. Najdete tu hned 7 tipů, jak takovému webovému šnekovi pomoci, aby běhal trochu rychleji.

Jenže tyhle body jsou užitečné spíš v okamžiku, kdy web stavíte. Co když se dostanete do situace, když se vám do ruky dostane už hotový web, který leze pomaleji než šnek, a vy s ním potřebujete něco vymyslet?

Podělím se s vámi s postupem, který většinou na takových webech dělám, kdy je potřebuji zrychlit.

0. Než začneme

Udělejte si zálohu. Nevíte dopředu, co se s webem bude dít a co tam bude potřeba dělat, proto záloha je nejjistější řešení. Samozřejmě jen ta, kterou umíte hned obnovit.

Další věcí, kterou vypínám, je plugin na cache.

• Je to čistě kvůli tomu, abych viděla, jak se web chová bez optimalizací. Několikrát jsem viděla cache špatně nastavenou a po vypnutí běžel web paradoxně rychleji než s ní.

Mimochodem, už máte zálohu? Pokud ne, teď je na ni ten správný čas. Opravdu.

1. Vliv pluginů a šablon na web

K tomu je skvělý nástroj Code Profiler, který vykreslí hezký graf a odhalí hlavní viníky. Není nutně pravda, že víc pluginů se rovná pomalejšímu webu – velmi záleží na tom, co pluginy dělají. A někdy může paradoxně pomoci nahradit jeden plugin třemi menšími.

Je potřeba také rozšlišovat 2 typy zátěže webu:

1. v administraci, kde různá nastavení a fancy UI pluginů zpomalují administraci,
2. na “frontendu”, kde se většinou načítají nějaké skripty nebo styly a ve výsledku jich můžou být stovky (můj rekord je 651 načtených zdrojů, bez obrázků).

Pozn.: Je dobré pustit Profiler pro víc různých typů stránek, abyste dostali opravdu nezávislý vzorek dat bez většího zkreslení.

2. Revize pluginů

U hotového webu nemáte luxus v podobě toho, že můžete vyměnit šablonu – např. kvůli builderům znamená výměna šablony přestavět celý web znovu. Proto se většinou vyplatí dělat o to důkladnější revizi u pluginů.

Musíte projít seznam pluginů, a zjistit, k čemu který je. Někdy se web zrychlí jen tím, že se vypne plugin, který se např. zacyklil v databázi a web se kvůli tomu razantně zpomalil. A najednou web ožije jako srnka. Nebo zjistíte, že tam je celý plugin kvůli tomu, že z něj potřebujete nějaké fancy tlačítko.

Každý ze seznamu pluginů pravděpodobně zapadne do nějaké z těchto skupin:

1. musí zůstat na webu, nejde ničím vyměnit (což je často i případ šablony),
2. musí zůstat na webu jako funkcionalita, ale jde nahradit jiným pluginem (tady je potřeba myslet např. na import dat),
3. lze ho vypnout, protože funkcionalitu můžeme postrádat.
4. lze ho vypnout, protože není vůbec spoužitý (tady je potřeba si opravdu vizuálně i funkčně ověřit, že to opravdu nikde použito není – pozor na cache!).

Tip: Díky AI můžete dokonce zjistit, jestli nějaké pluginy (hlavně kdejaká rozšíření s “cool tlačítky”) použita i jinde na webu. Ideální je stáhnout si lokální kopii webu k sobě do počítače a nechat AI projít všechny stránky – díky tomu je schopna zjistit, jaké moduly nebo celé pluginy jsou kde potřeba (a nezatěžujete zdrojový web). Nedávno jsem takto z jednoho webu vyhodila hned dvě rozšíření, která načítala dost CSS a JS souborů pro moduly, které se nakonec nikde nepoužily. Jen kvůli tomu, že autor měl nějaký univerzální balík univerzálně nastavený pro univerzální tvorbu webů… uff.

3. Konzole a logy taky leccos napoví

Je dobré se podívat, co se děje v konzoli prohlížeče. Typičtí viníci, kteří se tam můžou objevit:

• Služby 3. stran – je dobré udělat revizi, jestli jsou opravdu všechny nutné a musí se při načtení webu pouštět (případně je vhodně odložit).
• Chyby 404 – zdánlivá maličkost může zabrat naprosto zbytečně jeden z procesů, které se starají o načtení webu, a zpomalení je na světě. Toto jsem řešila nedávno na jednom webu, kde chybějící CSS naprosto “zabilo” zřetězení stylů. Když se podařilo viníka napravit, najednou web ožil a načetl se o 6 vteřin rychleji.
• S tím souvisí i různá přesměrování mezi http/https variantami a podobně. Opět zkušenost. Používejte jednu a vše ostatní vyčistěte a přesměrujte.
• I když je to rarita, někdy narazíte i na protokol http/1.1. Problém je v tom, že je velmi starý a neumí posílat požadavky paralelně a tak efektně, jako ty mladší.

Určitě nezapomeňte ani na WordPress error_logy, které vám do souboru vypíšou různé chyby a další informace, které můžou být užitečné.

4. Něco musíte oželet

Ruku na srdce, ne všechno se dá vyleštit. Jsou věci, které se optimalizovat nevyplatí, protože jejich oprava by stála mnohem víc než užitek jako takový.

• Typický příklad tohoto jsou např. google fonts (nic proti nim! jen by měly být uložené lokálně na webu od začátku tvorby, už kvůli cookies a dalším – nahradit je zpětně je někdy časově hodně náročné).

Dalším příkladem jsou různé JS a CSS, které jsou součástí pluginů z 1. skupiny výše. Ty prostě na webu být musí. Pokud takový plugin psal dobrý vývojář, napsal ho alespoň modulárně, což znamená, že se dají jednotlivé moduly zapnout nebo vypnout.

Stejně tak se málokdo pouští do optimalizace databáze, protože je někdy velmi těžké určit, jaká data už potřeba nejsou a jaká ještě ano. Ale i to je někdy potřeba udělat.

5. Optimalizace toho, co zbylo

Např. obrázky, videa a další zdroje, které se dají komprimovat nebo zmenšit, často i automaticky na webu. A protože se pak díky kompresi načítá měně dat, web je logicky rychlejší. Sice vám to moc nepomůže v administraci, ale webu to může pomoct.

• Je třeba myslet i na to, že obrázky jsou na webu v několika kopiích = zmenšeninách. A pak se z webu, kde je 2500 obrázků, může stát otesánek, který má 19 GB. To už je záloha, kterou málokam nacpete.

6. Nastavení cache

Když skončíte s čištěním, je na čase cache. Protože každý hosting je jiný, neexistuje “jeden magický plugin” (ideálně s jedním tlačítkem), který by se nastavil a hotovo. Každý hosting potřebuje trochu jiné nastavení.

• Někde najdete objektovou cache (Redis),
• někde serverovou (Memcahced, Varnis, Litespeed cache),
• někde oboje (výborně!),
• … někde taky nic.

Musíte zjistit, jaké má vás hosting možnosti a podle toho nastavit vhodné cachování.

Pozor: Cache trvá, než se “napočítá”. V závislosti na velikosti webu to můžou být i vyšší desítky hodin.

7. Poslední eso v rukávu

Výměna hostingu je až poslední možnost, když nic jiného nezabere. Nabízím to málokdy, až opravdu jako poslední možnost, protože s každou migrací se pojí nějaké problémy – řešíte, kde jsou nastavené jaké služby, DNS záznamy, musíte zmigrovat e-maily… a to jsme se k webu ještě ani nedostali.

Kdy už má smysl řešit hosting?

• když je web očištěný od zbytečných pluginů a pořád má pomalou odezvu serveru,
• když hosting neumí rozumnou serverovou cache,
• když web naráží na limity CPU/RAM (co často způsobuje “bílé obrazovky smrti”),
• když administrace padá nebo dlouho čeká i po vypnutí problematických pluginů.

Někdy pomůže jen výměna za jiný, parametrově podobný (protože má prostě rychlejší “železo”), jindy je potřeba povýšit tarif nebo přesunout na silnější hosting. Ale je to opravdu až poslední věc, kterou navrhuji.

Nový hosting může pomoct, ale neměl by být první slepý výstřel. Nejdřív je dobré vědět, co web skutečně brzdí. Pak se dá rozhodnout, jestli stačí úklid, lepší cache, výměna pár pluginů, nebo je migrace celého webu opravdu potřeba.

Řešíte pomalý web a nevíte, kde začít? Napište mi.