Röviden: igen, elég. Amit most nézel, egy teljes értékű WordPress, ami havi 199 forintos csomagon fut, benne 128 MB memóriával és 100m CPU-val (azaz egy processzormag tizedével). Nem trükk, nem egy nagyobb szerver álcázva — a pénztárnál én magam is ezt a Nano csomagot rendeltem meg, ügyfélként. Ebben a cikkben megmutatom a valós méréseket, és hogy mitől fér el egy WordPress ilyen kevés helyen.
A számok, amiket ezen az oldalon mértem
- Egy teljes oldalletöltés csúcsmemóriája: 6 MB. Ennyit használ a PHP, amíg összerakja a főoldalt — sablon, menü, lábléc, minden. A 128 MB-nak ez a töredéke.
- Válaszidő gyorsítótárból (TTFB): ~0,13 másodperc. Ilyenkor a PHP el sem indul, a kiszolgáló kész HTML-t ad vissza.
- Válaszidő gyorsítótár nélkül: ~0,67 másodperc. Ez az, amikor a PHP és a MariaDB tényleg dolgozik. Egy látogató ezt gyakorlatilag sosem látja.
- Aktív bővítmény: 0 darab. Erről lentebb írok.
A háttér: WordPress 7.0, PHP 8.3, GeneratePress téma, bekapcsolt opcache. Semmi egzotikus.
Miért nem fullad meg a WordPress 128 MB-ban?
A közhiedelem szerint a WordPress „nehéz”. Valójában egy csupasz WordPress egy oldalletöltése pont hogy nem az — a gond mindig az, amit rátesznek: tucatnyi bővítmény, egy nehéz drag&drop sablon, külső betűkészletek, követőkódok. Ha ezeket elhagyod, marad egy fürge rendszer.
A másik fele a történetnek a gyorsítótár. Ezen a tárhelyen a kiszolgáló (nginx) teljes oldalas gyorsítótárat használ: amikor egy kijelentkezett látogató megnyit egy oldalt, először a PHP legenerálja a HTML-t, a kiszolgáló pedig elteszi. A következő látogató már ezt a kész HTML-t kapja — a PHP-hez hozzá sem kell nyúlni. Egy blognál, ahol a látogatók 99%-a csak olvas, ez azt jelenti, hogy a PHP és az adatbázis szinte mindig pihen.
A válaszfejlécen is látszik: a gyorsítótárból kiszolgált oldal x-fastcgi-cache: HIT jelölést kap, a bejelentkezett szerkesztő pedig BYPASS-t — vagyis te a wp-adminban mindig a friss oldalt látod, a látogató meg a villámgyorsat.
Ezért nincs rajta gyorsítótár-bővítmény
Ez sokakat meglep: nincs WP Super Cache, nincs W3 Total Cache, semmi. Nem is kell. A gyorsítótárazást a kiszolgáló intézi, ott, ahol a leggyorsabb — jóval a PHP előtt. Egy cache-bővítmény ehhez képest csak memóriát és karbantartást enne. Kevesebb bővítmény = kevesebb RAM, kevesebb hibalehetőség, kevesebb frissítendő dolog. A gyorsítási cikkben részletesen leírom, mit érdemes és mit nem.
Hol lenne mégis kevés a 128 MB?
Hogy őszinte legyek: nem mindenre elég. Egy nagy WooCommerce-áruház tele bővítménnyel, sok egyidejű bejelentkezett vásárlóval már kinőné — ott a bejelentkezett forgalom nem gyorsítótárazható, és minden kérés valódi PHP-munka. Ugyanígy egy fórum, egy tagsági oldal vagy egy oldalbuilderrel épített, nehéz kezdőlap. Ezekről a költségekről szóló cikkben írok bővebben. De egy blog, egy bemutatkozó oldal, egy portfólió vagy egy kisebb céges honlap? Arra a Nano bőven elég — épp ezt bizonyítja ez az oldal.
Kipróbálnád te is?
Ez az oldal, amit épp olvasol, az ait.hu Nano csomagján fut — 199 Ft/hó + ÁFA (negyedéves számlázással 597 Ft). Ez a csomag rendes ára — nincs akció, nincs apróbetű.