← Tudásbázis
Technológia

Cache-plugin vagy szerveroldali gyorsítótár? — WordPress-gyorsítás érthetően

Ha WordPress-ed van, előbb-utóbb szembejön a kérdés: kell-e cache-plugin? WP Rocket, W3 Total Cache, WP Super Cache — mind gyorsulást ígér. Közben viszont a tárhelyszolgáltatód (mi biztosan) azt mondja: a szerver már eleve gyorsítótáraz. Akkor most melyik kell? Mindkettő? Egyik sem? Elmagyarázzuk — érthetően.

Ha a gyorsítótár (cache) fogalma új, kezdd inkább itt: Miért gyors az oldalad nálunk? — a gyorsítótár közérthetően. Ez a cikk onnan folytatja, WordPress-re hegyezve.

A cache-plugin: gyorsítás a WordPressen belül

A cache-plugin a WordPress részeként fut. Amikor egy látogató kér egy oldalt, a szervernek el kell indítania a PHP-t és legalább részben magát a WordPresst — a plugin ezután adja oda a korábban elmentett, kész oldalt ahelyett, hogy az egészet újragenerálná. Ez gyorsabb, mint a teljes újrafőzés, de a motor minden kérésnél beindul.

Az étterem-hasonlatunkkal: a séf nem főz újra, hanem a konyhában előre elkészített tányért ad át. Jobb, mint a semmi — de a konyhát ehhez is ki kell nyitni, a séfnek ott kell állnia.

Amit a pluginek ezen felül tudnak (és ez a hasznos részük): képtömörítés, CSS/JS-kicsinyítés, késleltetett képbetöltés (lazy load), adatbázis-takarítás. Ezek nem gyorsítótárazás — hanem magát az oldalt teszik könnyebbé, és bármilyen tárhelyen segítenek.

A szerveroldali gyorsítótár: gyorsítás a WordPress előtt

Nálunk a gyorsítótár nem a WordPressben él, hanem előtte: maga a webszerver (nginx) tartja készen a kész oldalakat. Amikor a látogató kér egy oldalt, a kérés el sem jut a PHP-ig és a WordPressig — a webszerver a másodperc törtrésze alatt odaadja a polcon lévő példányt.

Ugyanazzal a hasonlattal: a kész tál már a pultnál van. A konyhát ki sem nyitjuk, a séf pihen. Ezért nagyságrendekkel kevesebb erőforrás kell hozzá — és ezért bírja el egy kis csomag is a forgalmat.

Nálunk ezt egyetlen pipával kapcsolod be: KubePanel → Domains → Enable Page Caching. A rendszer okosan kihagyja, amit nem szabad gyorsítótárazni: bejelentkezett felhasználó és a wp-admin mindig friss, élő oldalt kap.

Kell-e akkor nálunk cache-plugin?

  • A page cache (oldal-gyorsítótár) funkciója: nem. A szerveroldali megoldás ugyanezt csinálja, csak korábban és hatékonyabban. Két oldal-gyorsítótár egymásra rakva nem kétszer gyorsabb — inkább kétszer nehezebb kitalálni, miért látsz régi tartalmat.
  • Az optimalizáló funkciók: jöhetnek. Képtömörítés, kicsinyítés, lazy load — ezek jól kiegészítik a szerveroldali gyorsítótárat. Ha például WP Rocketet vagy W3 Total Cache-t használsz, kapcsold ki benne az oldal-gyorsítótárazást, a többi funkció maradhat.

Mikor érdemes gyorsítótárazni — és mikor nem?

Szinte mindig érdemes, ha az oldalad tartalma mindenkinek ugyanaz: bemutatkozó oldal, céges weboldal, blog, portfólió, étlap, rendezvényoldal. Ilyenkor a látogatók túlnyomó része a kész példányt kapja, az oldalad pedig villámgyors.

Óvatosan vagy egyáltalán nem érdemes, ha a tartalom látogatónként más:

  • webshop kosár- és pénztároldala (a termékoldalak gyorsítótárazhatók, a kosár nem),
  • tagsági, bejelentkezős oldalak — ahol a látogatók személyre szabott tartalmat látnak,
  • percenként változó adatok (élő árfolyam, foglalási naptár aktuális állapota).

A jó hír: a kihagyási szabályok miatt ezekben az esetekben sem „romlik el" semmi — a rendszer a nem gyorsítótárazható kéréseket automatikusan frissen szolgálja ki. Csak ilyenkor a gyorsítótár kevesebbet segít, így erősebb csomagra lehet szükség.

Elég lehet a 199 Ft-os csomag?

Ha az alábbiak igazak az oldaladra, akkor bekapcsolt oldal-gyorsítótárral jó eséllyel a legolcsóbb, 199 Ft/hó + ÁFA Nano csomagunkon is simán elfut a WordPress oldalad:

  • bemutatkozó oldal, blog vagy portfólió — nem webshop, és a látogatóid nem jelentkeznek be;
  • a tartalom nem változik percenként (a napi-heti frissítés bőven belefér);
  • a médiatárad — képek, fájlok — belefér 1 GB tárhelybe;
  • nem futnak folyamatosan „nehéz" bővítmények (például valós idejű statisztika vagy komplex keresőmodul).

Élő példa: a tarhely199.hu pontosan így fut — valódi WordPress, Nano csomagon, bekapcsolt gyorsítótárral.

Bizonytalan vagy? Kérj ingyenes átvizsgálást — megnézzük az oldalad, és megírjuk, hogyan tudnánk optimalizálni, és melyik a legolcsóbb csomag, amin gond nélkül futna. Semmire nem kötelez.


Technikásabbaknak: a szerveroldali oldal-gyorsítótár nginx FastCGI cache. Hogy egy oldal honnan jött, az X-FastCGI-Cache válasz-fejlécben látod: HIT = a gyorsítótárból, MISS = frissen készült (és mostantól a polcon van), BYPASS = kihagyási szabály miatt szándékosan friss (például bejelentkezve).

Nem sikerült valami, vagy kérdésed maradt? Írj nekünk — vagy kattints a chat buborékra.