WordPress Tárhely: Miért Is Fizet Valójában

A WordPress tárhelyet olyan ársávban árulják, amely nagyjából havi 3 fonttól több százig terjed, és a sáv két végén álló csomagok szinte azonos szavakkal írják le magukat. Gyors. Biztonságos. Mentett. Támogatott. Az a leírás, amelyből a vásárló meg tudná különböztetni őket, vagyis hogy melyik PHP-ág futtatja az oldalt, milyen adatbázismotor áll mögötte, hány gyorsítótár-réteg létezik és ezek közül melyik van valóban bekapcsolva, rendszerint hiányzik arról az oldalról, amelyről a vásárlást kérik.

Ez a hiány a termék része. A „menedzselt" marketingkategória, nem műszaki kategória, és egyetlen szabványügyi testület sem határozza meg. Két szolgáltató, amely ugyanazt a szót használja, eltérhet abban, hogy fut-e állandó objektum-gyorsítótár, hogy megtarthatja-e a saját gyorsítótár-bővítményét, hogy elhagyhatja-e egy mentés az ő infrastruktúrájukat, és hogy egyáltalán megnyithat-e egy parancssort.

Ami következik, az a leírás, amelyet ezek az oldalak kihagynak: mit követel meg a WordPress, a technológiai verem mely részei mozdítják az oldalsebességet, mit ad hozzá és mit vesz el csendben a menedzselt tárhely, és milyen reális havi sávok tartoznak az egyes szintekhez.

Miért fizet valójában a WordPress tárhelynél? Négy dologért. Egy olyan PHP-verzióért és adatbázismotorért, amely megfelel a WordPress közzétett alapkövetelményének. Gyorsítótár-rétegekért, amelyeket különben magának kellene telepítenie és hangolnia. Üzemeltetési munkáért, vagyis frissítésekért, tesztkörnyezetért, mentésekért és tűzfalért. És tartalékért azokhoz a kérésekhez, amelyeket nem lehet gyorsítótárazni. Egy bemutatkozó oldalnak a negyedikből szinte semmi nem kell. Egy webáruház vagy tagsági oldal a költségvetése nagy részét ott költi el.

A WordPress tárhely kategórianév, nem műszaki leírás

Az egyetlen kategórián belüli árszórás az árulkodó jel. Két csomag, mindkettő menedzselt WordPress tárhelyként megjelölve, állhat havi 20 és 250 fonton, és a reklámszöveg nem magyarázza meg a különbséget, mert a különbség olyan dolgokból áll, amelyeket a szöveg nem említ.

Az olcsó végén egy megosztott gép szeletét vásárolja meg PHP-FPM-készlettel, oldal-gyorsítótárral és vezérlőpulttal. A drága végén elkülönített számítási kapacitást vásárol, állandó objektum-gyorsítótárat, tesztkörnyezetet, menedzselt tűzfalat, ügyfélszolgálati csapatot, amely elolvassa a hibanaplóját, és valakit, aki szerződésben felel, amikor egy rendszerfrissítés eltör egy sablont.

Mindkettő jogos termék. A gond az, hogy a vásárló nem látja, melyik áll előtte, így a döntés az ár és az affiliate-jutalék szerint rangsoroló véleményoldalak alapján születik meg. Az eredmény mindkét irányban kiszámítható. Bemutatkozó oldalak kötnek ki havi 150 fontos csomagokon, amelyeket sosem fognak kimeríteni, a WooCommerce-webáruházak pedig havi 5 fontos csomagokon, amelyek az első forgalmas szombaton a pénztárnál összeomlanak.

A kiút az, ha nem a szint neve, hanem négy kérdés alapján vásárol: melyik PHP-ág, mely gyorsítótár-rétegek, hány nem gyorsítótárazható kérést nyel el a csomag, és mi történik az adataival, amikor távozik.

Mit követel valójában a WordPress egy szervertől

A WordPress közzétesz egy követelményoldalt, és ez rövid, éppen ezért ugorják át. Olvassa beszerzési leírásként, mert az a csomag, amely ezen elbukik, még azelőtt kiesik, hogy a teljesítményről szó esne.

A PHP-verzió

A WordPress követelményoldala ajánlott alapként a „PHP 8.3-as vagy újabb verzióját" jelöli meg. Emellett olyan figyelmeztetést is tartalmaz, amely többet nyom a latban, mint maga az ajánlás: a WordPress „továbbra is fut PHP 7.4+ és MySQL 5.5.5+ alatt, de ezek a verziók elérték hivatalos életciklusuk végét, és biztonsági sebezhetőségeknek tehetik ki az oldalát".

Ebben az egyetlen mondatban benne van az egész csapda. A WordPress nem tagadja meg az indulást egy ősrégi PHP-ágon. Fut, normálisnak látszik, és csendben olyan értelmezőn ül, amely évek óta nem kapott biztonsági javítást.

Az adatbázis

Ugyanez az oldal „MariaDB 10.11+ vagy MySQL 8.0+" verziót kér. A régebbi motorok továbbra is működnek, ezért van olyan sok oldal ezeken. A WordPress saját használati statisztikái azt mutatják, hogy körülbelül minden hatodik telepítés MySQL 5.x kiadást jelent, jóval a megadott küszöb alatt, és önmagában a MySQL 5.7 adja a jelentést küldő oldalak nagyjából 12 százalékát.

A következmény nem az, hogy az oldal eltörik. Hanem az, hogy elesik olyan motorfejlesztésektől, amelyek pontosan a nehezen gyorsítótárazható terhelésnél számítanak, és örököl egy migrációt, amelyet előbb-utóbb amúgy is el kell végeznie.

A HTTPS és a PHP-kiterjesztések

A HTTPS „minden telepítéshez kötelezőként" szerepel, nem ajánlottként. Az a szolgáltató, amely 2026-ban még mindig fizetős extraként kezel egy tanúsítványt, mond valamit a csomag többi részéről is.

Ezen túl a WordPress tárhelykézikönyv a json és a mysqli kiterjesztést nevezi kötelezőnek, a curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, xml és zip kiterjesztéseket pedig erősen ajánlottnak. Kettőt érdemes megemlíteni az értékesítőnek. A zip nélkül a bővítmény- és rendszerfrissítési csomagokat nem lehet kicsomagolni. Az imagick nélkül a médiafeltöltések gyengébb képkönyvtárra esnek vissza, és a képei már azelőtt rosszabbul jönnek ki, hogy bárki hozzányúlna egy optimalizáló bővítményhez.

A PHP-verzió a számla leghasznosabb sora

Mindabból, amit egy szolgáltató irányít, a PHP-ág adja a legjobb hatás-ráfordítás arányt. A legtöbb vezérlőpulton ez egy legördülő lista. Semmit nem építenek újra, semmit nem migrálnak, és egy amúgy is kompatibilis oldal egyszerűen elkezd gyorsabb és jobban támogatott értelmezőn futni.

Az ok, amiért évekig változatlan marad, szervezeti és nem műszaki. Senki sem felel érte. Az ügynökség, amely az oldalt építette, továbblépett, a szolgáltató nem változtatja meg egyoldalúan, mert egy elhagyott bővítmény végzetes hibája akkor az ő hibája lenne, a cégnek pedig nincs oka gondolni egy számra, amelyet soha nem mutattak meg neki.

Az első kérdés egy leendő szolgáltatóhoz tehát nem a sebességről szól. Arról szól, melyik PHP-ágat futtatja a csomag alapértelmezetten, mely ágakat kínálja, és hogy Ön maga át tudja-e állítani anélkül, hogy hibajegyet nyitna. Az a szolgáltató, amely csak olyan ágat kínál, amelyet a WordPress már nem ajánl, egyúttal minden más kérdésre is válaszolt.

Tesztkörnyezetben próbálja ki, soha ne az éles rendszert kapcsolja át. Egy oldal, amely PHP 7.4-ről 8.3-ra vált, általában két-három elavulási figyelmeztetést hoz elő karbantartás nélküli bővítményekből, és a valódi költség ez. Számoljon fél naptól egy napig terjedő fejlesztői idővel, amelyről részletesebben a WordPress fejlesztői díjakról és a felteendő kérdésekről szóló útmutatónkban írtunk.

A PHP-érv biztonsági fele

A teljesítmény az az ok, amelyet a PHP frissítésére szoktak felhozni. A biztonság az az ok, amely valóban számít, és amely mérhető ahelyett, hogy vitatható lenne.

A PHP saját támogatott verziós ütemtervet tesz közzé. Minden ág két év aktív támogatást kap, majd további két évig csak biztonsági javításokat. 2026 szeptemberében ez azt jelenti, hogy a PHP 8.2 2026. december 31-ig kap csak biztonsági javításokat, a PHP 8.3 pedig 2027. december 31-ig, miután az aktív támogatása 2025. december 31-én lejárt. A PHP 8.4 2026. december 31-ig marad aktív támogatásban, biztonsági javításokkal 2028. december 31-ig, a PHP 8.5 pedig 2027. december 31-ig, javításokkal 2029. december 31-ig. Minden ennél régebbi lezárult: a PHP 8.1 2025. december 31-én ért véget, a PHP 8.0 2023. november 26-án, a PHP 7.4 pedig 2022. november 28-án.

Állítsa ezt szembe azzal, amit a WordPress-oldalak valójában futtatnak. A WordPress statisztikai oldala a telepítések nagyjából 38,8 százalékáról jelenti, hogy teljesen kifutott ágon vannak, és körülbelül 23,2 százalék még mindig PHP 7.4-en vagy régebbin. Csak mintegy 36,4 százalék éri el a WordPress által ajánlott PHP 8.3-as alapot, további 24,8 százalék pedig PHP 8.2-n ül, amely az idei év végén elveszíti a biztonsági támogatást.

A WordPress-oldalak többsége tehát olyan értelmezőn fut, amely vagy nem kap biztonsági javításokat, vagy hónapokra van ettől az állapottól, és szinte minden esetben egy olyan tárhelybeállításról van szó, amelyet senki nem nézett meg. A javítása kevesebbe kerül, mint egy bővítménylicenc, ezért kezeli első lépésként a WordPress biztonsági megerősítési ellenőrzőlistánk.

A gyorsítótár-rétegek abban a sorrendben, ahogy egy kérés találkozik velük

Szinte minden teljesítményígéret, amelyet egy szolgáltató tesz, a gyorsítótárról szól, és szinte minden vásárló egyetlen, differenciálatlan ígéretként hallja. Négy elkülönülő réteg van, rögzített sorrendben állnak, és mindegyik másfajta munkát takarít meg. Az alábbi sorrend az, amelyen egyetlen kérés végighalad, és az a kérés, amelyet egy korábbi réteg megválaszol, sosem jut el a későbbiekhez.

A peremhálózati vagy CDN-gyorsítótár

Az első, amivel egy kérés találkozik, egy teljesen a szerverén kívüli gyorsítótár, a látogatóhoz közeli jelenléti pontok hálózatán. Ha a válasz már ott van tárolva, a szolgáltatója a kérést egyáltalán nem is látja.

Ez a réteg hálózati távolságot takarít meg, nem csak számítási időt. Egy manchesteri látogató, aki egy londoni peremcsomópontot ér el, elkerül egy transzatlanti oda-vissza utat. Statikus fájloknál majdnem ingyenes, és mindig megéri. HTML-nél erőteljes, de feltételes, mert a peremhálózatnak meg kell mondani, mely válaszok személyesek és soha nem oszthatók meg.

A teljes oldalas gyorsítótár

A második réteg egy oldal kész HTML-jét tárolja, hogy a PHP és az adatbázis ne fusson újra. A WordPress tárhelykézikönyv fordított proxyt ajánl, például NGINX-et vagy Varnisht, amely „a kimenetet közvetlenül a szerver memóriájába vagy merevlemezére tárolja", és hozzáteszi azt a szabályt, amely eldönti, hogy a réteg egyáltalán működik-e: „jó ötlet minden bejelentkezett felhasználót kizárni a gyorsítótárból, mert nekik személyre szabott tartalmat kell látniuk".

Ez az a réteg, amely hízeleg az olcsó tárhelynek. Amikor működik, a látogató egy fájlt kap, és a PHP-verzió, az adatbázismotor és a bővítmények száma megszűnik számítani annál a kérésnél, mert egyik sem fut le.

Az objektum-gyorsítótár

A harmadik réteg az egyes adatbázis-lekérdezések eredményeit és a számított értékeket tárolja. A WordPress alapból szállítja, de nem állandó módon. A WP_Object_Cache dokumentációja egyértelmű: „Alapértelmezés szerint az objektum-gyorsítótár nem állandó. Ez azt jelenti, hogy a gyorsítótárban tárolt adatok csak a memóriában és csak a kérés idejére léteznek."

Állandóvá tenni azt jelenti, hogy Redist vagy Memcachedet tesznek mögé egy drop-in segítségével, ami a gyorsítótárat minden oldalbetöltésnél újraépülő valamiből kérések és látogatók között megosztott valamivé alakítja. Ez az a réteg, amely akkor számít, amikor az oldalak már nem gyorsítótárazhatók egészben, és amely a legtöbbször hiányzik az olcsó csomagokból.

Az opcode-gyorsítótár

A negyedik réteg az OPcache, amely a PHP-fájljai lefordított bájtkódját osztott memóriában tartja, hogy az értelmezőnek ne kelljen minden kérésnél újra beolvasnia és lefordítania azokat. A tárhelykézikönyv kimondja, hogy „éles WordPress-környezetekben ajánlott az OPcache engedélyezése a webes kérésekhez, és a méretezése az adott oldalhoz vagy tárhelyplatformhoz".

Ennek van egy telepítési következménye. Mivel az OPcache lefordított kódot tart, egy telepítésnek vissza kell állítania vagy érvényteleníteni kell a módosított fájlokat, különben a szerver továbbra is az előző verziót futtatja. Az a szolgáltató, amely nem tudja megmondani, hogyan érvénytelenítik az OPcache-t, olyan szolgáltató, ahol egy bővítményfrissítés több percig látszólag semmit sem csinál.

Miért gyors egy bemutatkozó oldal szinte bármelyik szolgáltatónál

Vezesse végig ezt a négy réteget, és a következtetés kényelmetlen a tárhelyiparnak. Ha minden látogató névtelen és minden oldal gyorsítótárazható, a teljes oldalas gyorsítótár válaszol szinte az egész forgalomra, és a mögötte álló gép adatlapja alig számít.

Ezért érhet el egy ötoldalas céges oldal egy havi 4 fontos csomagon, tisztességes oldal-gyorsítótárral, jobb szerverválaszidőt, mint egy túlterhelt oldal egy havi 200 fontos csomagon. Az olcsó oldal fájlokat szolgál ki. A drága PHP-t futtat.

A figyelendő szám az első bájtig eltelt idő, amely önmagában nem Core Web Vital. A Google Web Vitals áttekintése a támogató mérőszámok közé sorolja, amelyek a lassú szerverválaszidők okozta „LCP-problémák diagnosztizálásához" hasznosak. Pontosan ez az oldalsebességnek az a szelete, amelyet a szolgáltató irányít.

A WordPress annyira egyetért ezzel, hogy beleírta a rendszermagba. A WordPress 6.1-ben bevezetett Oldalállapot-teszt a teljes oldalas gyorsítótárra azt vizsgálja, „hogy az oldal használ-e teljes oldalas gyorsítótár-megoldást, és hogy a válaszidő elfogadható-e", 600 ezredmásodperces alapértelmezett küszöbbel. Ha az oldala e fölött van, miközben állítólag be van kapcsolva egy oldal-gyorsítótár, akkor a gyorsítótár nem működik, és a plusz processzor ezt nem fogja elrejteni.

Egy bemutatkozó oldalnál tehát a tárhely fejlesztése rendszerint rossz vásárlás. Amitől lassú lesz, az gyakrabban egy túlméretezett fejléckép, egy oldalszerkesztő, amely több száz kilobájt CSS-t szállít, vagy hat betűvastagság, és éppen ez az érv az Elementor és az egyedi sablon összehasonlításában.

A bejelentkezett forgalom és a WooCommerce felborítja a modellt

Minden fenti azt feltételezi, hogy az oldal-gyorsítótár tud válaszolni. Abban a pillanatban, amikor a látogatók bejelentkeznek, ez a feltevés összeomlik, és a tárhely gazdaságtana megfordul.

A WooCommerce ezt közvetlenül dokumentálja. A gyorsítótárazási útmutatója előírja, hogy a Kosár, a Fiókom és a Pénztár oldalt ki kell zárni az oldal-gyorsítótárból, mert ezeknek az oldalaknak „dinamikusnak kell maradniuk, mivel az adott vásárlóra és a kosarára jellemző információt jelenítenek meg". Felsorolja azokat a sütiket is, amelyeknek meg kell kerülniük a gyorsítótárat, köztük a woocommerce_cart_hash, a woocommerce_items_in_cart és a wp_woocommerce_session_ sütit, és javasolja a _wc_session_ kizárását az adatbázis-gyorsítótárból.

Tárhelyleírásként olvasva ez valami nagyon nyerset mond. Egy webáruházban éppen azok az oldalak termelik a bevételt, amelyekhez az oldal-gyorsítótár nem tud hozzányúlni. A katalógus- és termékoldalak gyorsítótárazhatók a névtelen böngészőknek. A kosár és a pénztár soha, senkinek.

Ugyanez igaz a tagsági oldalakra, a tanulási platformokra, a fórumokra és minden olyan oldalra, amelynek ügyfélportálja van. Amint egy munkamenet-süti beállításra kerül, a legtöbb gyorsítótár-bővítmény teljesen abbahagyja a gyorsítótárazott HTML kiszolgálását annak a látogatónak, így minden kattintás PHP-t futtat és az adatbázist terheli. Itt szűnik meg az objektum-gyorsítótár optimalizálás lenni és válik teherhordóvá, és itt fáj egy olcsó csomag úgy, ahogyan azt semmilyen szintetikus kezdőoldal-teszt nem mutatja meg, ahogy azt a miért lassú a WooCommerce webáruháza leírja.

Mit tartalmaz valójában a menedzselt WordPress tárhely

Vegye el a jelzőket, és a menedzselt tárhely meglehetősen állandó üzemeltetési munkacsomaggá egyszerűsödik. Érdemes ezt a munkát őszintén beárazni, mert egy műszaki személyzet nélküli cégnek gyakran olcsóbb megvenni, mint elvégezni.

A frissítések

A menedzselt csomagok általában automatikusan telepítik a rendszermag frissítéseit, néha a bővítményfrissítéseket is, olykor vizuális regressziós ellenőrzéssel előtte és utána. Hasznos tudni, mennyit tesz meg a WordPress már eleve ingyen.

A WordPress évek óta alapértelmezetten automatikusan frissíti a kisebb rendszermag-kiadásokat és a fordítási fájlokat, az 5.6 óta pedig az új telepítéseknél be van kapcsolva az automatikus frissítés a kisebb és a nagyobb rendszermag-kiadásokra egyaránt, kivéve ha verziókövetési munkapéldányt észlel, míg a meglévő telepítések megtartják a korábbi viselkedést. A fizetős rész tehát nem a kisebb rendszermag-frissítés. Hanem a bővítményfrissítések, a visszaállítás, ha egy elromlik, és valaki, aki észreveszi, hogy elromlott.

Tesztkörnyezet és mentések

Az egykattintásos tesztkörnyezet valóban értékes, és valóban bosszantó saját kezűleg felépíteni. Ne a puszta létezése, hanem két részlet alapján ítélje meg: felülírja-e az élő adatbázist, ha a tesztkörnyezetet visszatolják az élesbe, ami eldobná a másolat óta beérkezett rendeléseket és hozzászólásokat, és le van-e tiltva a tesztoldal a keresőmotorok és a levélküldés felől.

Tűzfal és kártevőkeresés

A legtöbb menedzselt csomag tartalmaz webalkalmazás-tűzfalat a peremhálózaton és valamilyen kártevőkeresést. A tűzfal valódi érték, mert a hálózati rétegben végzett virtuális javítás időt vásárol egy bővítménysebezhetőség nyilvánosságra kerülése és az Ön frissítése között.

A keresés gyengébb, mint amilyennek hangzik. Rendszerint ismert kártékony fájlaláírásokat észlel, vagyis elkapja a tömeges fertőzéseket, és elszalasztja a célzottakat. Kezelje füstjelzőként, ne zárként, és tartsa a megerősítési munkát a saját oldalán a vonalnak.

Mit vesz el a menedzselt tárhely

A korlátozások azt a felet alkotják, amelyet senki nem olvas el, és rendszerint többet nyomnak a latban, mint a szolgáltatások. Védhető okokból léteznek, de az okok a szolgáltatóé, nem az Öné.

A legvilágosabb közzétett példa a WP Engine tiltott bővítmények listája, amely egész kategóriákat tilt, nem pedig egyes vétkeseket. A gyorsítótár-bővítmények azért tiltottak, mert „ütközhetnek a platformunk beépített gyorsítótár-szerkezetével". A mentőbővítmények azon az alapon tiltottak, hogy „szükségtelenül felduzzasztják az oldalát". A kapcsolódó bejegyzéseket megjelenítő bővítmények mint „rendkívül adatbázis-igényesek" tiltottak. A dokumentált sebezhetőségű bővítmények egyenesen tiltottak, ahogy a platform funkcióit megkettőző bővítmények is.

Ezek mindegyike ésszerű mérnöki döntés. Együttesen viszont azt jelentik, hogy az oldala nem hordozható úgy, ahogy Ön feltételezte. Ha a felépítése egy adott gyorsítótár-bővítmény beállításain múlik, az a beállítás nem költözik Önnel.

A parancssori hozzáférés a másik gyakori hiány. Sok menedzselt csomag egyáltalán nem ad SSH-t, vagy korlátozott parancssort ad WP-CLI nélkül, ami egy olyan rutinmunkát, mint a tömeges keresés és csere egy domainváltás után, támogatási hibajeggyé alakít. Két további dolog szokta meglepni az embereket: a hosszan futó folyamatokat gyakran korlátozzák, így 50 000 termék importját darabolni kell, a kimenő levelezést pedig gyakran blokkolják vagy korlátozzák, abból kiindulva, hogy egy feltört oldalt levélszemétre használnak majd.

A teljesítményígéretek, amelyek nem élik túl a mérést

A tárhelymarketing az állítások egy kis készletéből él, amelyek szétesnek abban a pillanatban, amint megkérdezi, mit is mértek.

A „hússzor gyorsabb" szinte soha nem nevez meg viszonyítási alapot. Gyorsabb minél, melyik oldalon, milyen bővítményekkel, mekkora párhuzamosság mellett? E négy nélkül a szám két meg nem nevezett mennyiség hányadosa.

A „korlátlan sávszélesség" ugyanabban a táblázatban áll egy havi látogatókerettel. A sávszélesség egyébként is ritkán korlát egy WordPress-oldalon. A korlát a párhuzamos PHP-végrehajtás, amelyet a csomag rendszerint egyáltalán nem említ.

A „99,9 százalékos rendelkezésre állás" abszolútnak hangzik, és nem az. Egy harmincnapos hónap alatt körülbelül 43 percnyi kiesést enged meg. A három kilences a megosztott tárhelynél szokásos érték, a négy kilences havi körülbelül négy percet enged meg, és a különbség az a különbség, amely egy kellemetlenség és egy észrevétlen kiesés között van. Olvassa el, mit fizet valójában a jóváírás, amikor az érték nem teljesül, ezt a témát külön tárgyaltuk a rendelkezésre állási SLA-k, amelyek jelentenek valamit írásban.

Az utolsó állítás a leggyakoribb és a legfélrevezetőbb: egy képernyőkép egy sebességtesztről egy gyorsítótárazott kezdőoldalon. Az az oldal-gyorsítótárat méri, nem a szolgáltatót, és az oldal-gyorsítótár az az egyetlen összetevő, amely mindenhol nagyjából egyenértékű.

Hogyan kell rendesen letesztelni egy szolgáltatót

A tárhely tesztelése nem nehéz, de azon az útvonalon kell elvégezni, amely valóban megdolgoztatja a szervert. Öt lépés, sorrendben.

Először tesztelje a nem gyorsítótárazott útvonalat. Fűzzön egyedi lekérdezési karakterláncot a címhez, hogy kijátssza az oldal-gyorsítótárat, vagy kérjen le olyan oldalt, amely sosem kerül gyorsítótárba, például kosarat vagy fiókoldalt. Ha nem tud olyan kérést küldeni, amely PHP-t futtat, akkor fájlszervert tesztel.

Másodszor ismételje meg. Egyetlen kérés semmit nem mond a szórásról, és a szórásban mutatkozik meg az olcsó tárhely. Vegyen legalább húsz mintát, és olvassa le a 75. percentilist, azt a statisztikát, amelyet a Google a terepadatokhoz használ.

Harmadszor onnan teszteljen, ahol a látogatói vannak. A szerver melletti adatközpontból mért válasz nem az a válasz, amelyet a leedsi ügyfelei kapnak.

Negyedszer teszteljen párhuzamosság mellett. Indítson tíz vagy húsz egyidejű, nem gyorsítótárazható kérést. Ez az egyetlen teszt, amely megmutatja a PHP-munkafolyamatok kimerülését, és ez a kimerülés dönt le egy webáruházat egy akció alatt.

Ötödször hasonlítson hasonlót hasonlóval: ugyanaz a PHP-ág, ugyanaz a bővítménykészlet, ugyanaz a sablon, ugyanaz a tartalommennyiség. Az a migráció, amely a szolgáltatóval együtt a bővítménykészletet is lecseréli, egyikről sem bizonyított semmit. Ha ezt valódi oldalon szeretné lefuttatni, nem pedig egy jelölt szolgáltatón, pontosan ezt csinálja egy WordPress teljesítményauditálás.

Mely Core Web Vitals mutatókat mozdítja valóban a tárhely

A Core Web Vitals az a pont, ahol a tárhelyígéretek és a keresési helyezések összekeverednek, ezért érdemes pontosan megnevezni, melyik mérőszámot befolyásolhatja egy szerver.

Három van, az oldalbetöltések 75. percentilisén értékelve, mobilra és asztali gépre bontva. A Largest Contentful Paint a betöltést méri, és 2,5 másodpercnél vagy annál kevesebbnél jó, 2,5 és 4,0 másodperc között javításra szorul, 4,0 fölött pedig gyenge. Az Interaction to Next Paint a válaszkészséget méri, és 200 ezredmásodpercnél vagy annál kevesebbnél jó, 500 ezredmásodpercig javításra szorul, afölött gyenge. A Cumulative Layout Shift a vizuális stabilitást méri, és 0,1-nél vagy annál kevesebbnél jó, 0,25-ig javításra szorul, afölött gyenge. A First Input Delay mutatót kivezették, helyére az INP lépett, amely 2024-ben lett stabil Core Web Vital.

A tárhely ezek közül pontosan egyet mozdít közvetlenül. A szerverválaszidő az LCP része, tehát az a szolgáltató, amely 400 ezredmásodpercet levág belőle, minden látogatónak 400 ezredmásodpercet vesz le az LCP-jéből. Egy lassú szolgáltatónál ez lehet a különbség a megfelelés és a bukás között.

A CLS mutatóért szinte semmit nem tesz, mert az méret nélküli képekből és későn betöltő betűtípusokból ered, az INP mutatóért pedig nagyon keveset, amelyet a fő szálon futó JavaScript ural. A szabály az, hogy ha az LCP gyenge, és a gyorsítótár nélküli szerverválasza a WordPress által jelzett 600 ezredmásodperces határ fölött van, akkor a tárhely része a problémának. Ha a válasz kényelmes, és az LCP mégis gyenge, a hiba az oldalban van, és a Core Web Vitals teljesítéséről 2026-ban szóló útmutatónk a jobb hely a költségvetésnek.

A mentések, és az a rész, amelyet senki nem ellenőriz

A legolcsóbb feletti minden csomag mentésekkel hirdeti magát. Aki vesz egyet, szinte soha nem teszi fel azokat a kérdéseket, amelyek eldöntik, hogy a mentés ér-e valamit.

Visszaállította-e valaha bárki

Az NCSC nyíltan kimondja a kis szervezeteknek szóló útmutatójában: ha már készített mentést, „fontos, hogy tudja, hogyan állítsa vissza, és ellenőrizze, hogy minden fontos adatát tartalmazza". Egy nem tesztelt mentés meggyőződés, nem kontroll.

Kérdezze meg a szolgáltatót, hogyan indul egy visszaállítás, mennyi ideig tart egy akkora oldalnál, mint az Öné, és hogy az adatbázis visszaállítása visszaállítja-e a feltöltési könyvtárat is. Aztán végezze el egyszer a tesztkörnyezetben, mielőtt szüksége lenne rá. Az a hibamód, amelyet keresni kell, az a visszaállítás, amely a fájlokat visszaadja, az adatbázist viszont nem, vagy amely sikerül, és csendben elveszít mindent, ami a másolat óta keletkezett.

Megőrzés és gyakoriság

A napi mentések hétnapos megőrzéssel nagyvonalúnak hangzanak, amíg meg nem nézi, hogyan romlik el valójában egy WordPress-oldal. Egy megrongált oldalt órák alatt észreveszik. Egy olyan feltörést, amely csendben levélszemét-hivatkozásokat fecskendez régi bejegyzésekbe, hetek alatt veszik észre, és addigra minden megőrzött másolat tartalmazza a befecskendezést.

A harminc nap hasznosabb alsó határ minden üzleti célra, és egy külön havi másolat olcsó biztosítás. Egy webáruháznak ezenfelül a rendelési mennyiséghez mért adatbázis-mentési gyakoriságra van szüksége, mert négy óra rendelést elveszíteni nem ugyanaz a kategória, mint négy óra blogszerkesztést elveszíteni.

Hol él a másolat, és milyen formátumban

Az NCSC másik pontja az, hogy az a mentés, amely az élő rendszerhez csatlakoztatva marad, nem különálló: egy mentéseket tároló eszköz „nem maradhat az eszközéhez csatlakoztatva, amikor nincs használatban", mert ami a forrást feltöri, elérheti azt is. Tárhelyre lefordítva az a mentés, amely ugyanabban a fiókban van, és csak ugyanabból a vezérlőpultból állítható vissza, osztozik annak a sorsában, amit véd.

A formátum ugyanennek a gondnak a finomabb változata. Ha a mentés elolvasásának egyetlen módja a szolgáltató saját visszaállítás gombja, akkor kényelmi funkciója van, nem hordozható másolata. A próba az, hogy le tud-e tölteni ma egy egyszerű SQL-kiíratást és egy fájlarchívumot, amelyet egy hozzáértő fejlesztő máshol is fel tudna állítani. Ha nem, a migráció megszűnik műszaki döntés lenni, és tárgyalássá válik.

Hol vannak az adatok, és miért számít ez a brit vásárlóknak

A tárhelydöntések adatvédelmi döntések, és egy brit cég esetében nem az a kérdés, hol jegyezték be a társaságot, hanem hogy hol nyugszanak a személyes adatok, és ki férhet hozzájuk.

Az ICO nemzetközi adattovábbításról szóló útmutatója háromlépcsős tesztet állít fel. Ha a brit GDPR vonatkozik az adatkezelésére, ha Ön kezdeményezi a továbbítást, és ha a fogadó szervezet külön jogi személy, akkor korlátozott továbbítást végez. Az ICO kifejezetten kimondja, hogy a szabályok „minden korlátozott továbbításra vonatkoznak, még a kicsikre és ritkákra is", és minden szervezetre kiterjednek, amely személyes adatot kezel, „beleértve az egyéni vállalkozókat és az önfoglalkoztatókat is".

Vegye észre, mi számít továbbításnak. Az ICO ide sorolja a személyes adatok elküldését és a „hozzáférhetővé tételüket" is egy Egyesült Királyságon kívüli szervezet számára. Egy külföldi támogatói csapat, amely hozzáfér az adminisztrációjához, vagy egy másik régióba replikált külső mentés egyaránt megfelelhet ennek a meghatározásnak.

Minden korlátozott továbbítást három dolog egyikének kell fednie: a célországra vonatkozó brit megfelelőségi rendelkezéseknek, megfelelő garanciáknak, például az International Data Transfer Agreementnek, a kiegészítésnek vagy a kötelező erejű vállalati szabályoknak, vagy pedig egy kivételnek. Ahol garanciákra támaszkodik, az ICO továbbítási kockázatértékelést is elvár, amely megmutatja, hogy a védelem utána nem lényegesen alacsonyabb. Mindebből semmi nem teszi használhatatlanná a külföldi szolgáltatót. Olyan döntéssé teszi, amelyet dokumentálni kell, és a dokumentálás sokkal olcsóbb a migráció előtt, mint egy adathozzáférési kérelem közben.

Mit kell tartalmaznia egy adatfeldolgozói szerződésnek

A szolgáltatója adatfeldolgozó, Ön pedig adatkezelő, így az írásbeli szerződés nem opcionális. Az ICO felsorolja, mit kell tartalmaznia annak a szerződésnek, és négy kikötése közvetlenül tárhelykérdésként olvasható.

Az alfeldolgozók jönnek először. A 28(3)(d) cikk szerint az adatfeldolgozó az Ön engedélye nélkül nem vonhat be másik feldolgozót, tájékoztatnia kell a tervezett változásokról, hogy tiltakozhasson, és a lánc mentén egyenértékű kötelezettségeket kell előírnia. Tárhelyre lefordítva ez a CDN, a mentés célhelye, a levéltovábbító és a mögöttes felhőszolgáltató. Kérje el a listát.

A biztonság a második. A 28(3)(c) cikk a 32. cikknek megfelelő intézkedéseket követel meg, az ICO pedig kifejti, mi tartozik ide: titkosítás és álnevesítés, az adatkezelő rendszerek ellenálló képessége, „a személyes adatokhoz való hozzáférés visszaállításának képessége egy incidens esetén", valamint „az intézkedések hatékonyságának rendszeres tesztelésére és értékelésére szolgáló eljárások". Ez a visszaállítás tesztelése, törvénybe írva, nem pedig egy jó gyakorlatokról szóló cikkbe.

A harmadik a kilépés. A 28(3)(g) cikk szerint az adatfeldolgozónak az Ön választása szerint törölnie vagy vissza kell adnia minden személyes adatot a szerződés végén, és törölnie kell a meglévő másolatokat. Az a szolgáltató, amelynek a mentései nem hagyhatják el a platformját, a gyakorlati mellett szerződéses gonddal is küzd. A negyedik az ellenőrzés, amely a 28(3)(h) cikk szerint feljogosítja Önt a megfelelés igazolásához szükséges információkra, valamint a szolgáltató tanúsítványaira és jelentéseire.

A szintek, és mennyibe kerülnek az Egyesült Királyságban

Négy szint szinte minden WordPress-oldalt lefed, és a köztük húzódó határokat nem a forgalom, hanem a nem gyorsítótárazható terhelés jelöli ki. Az alábbi sávok azt mutatják, mennyit fizetnek jellemzően a brit vásárlók havonta. Kategóriasávok, nem egyetlen szolgáltató árlistája, ezért kezelje őket egy árajánlat józansági próbájaként, ne árajánlatként.

Megosztott tárhely, havi 3 és 15 font között

Egy gyorsítótárazható bemutatkozó oldalhoz tökéletesen megfelelő, és valóban rossz vásár, amint bárki bejelentkezik. A PHP-kapacitáson olyan szomszédokkal osztozik, akiket nem lát, tehát terhelés alatt a szórás harap, nem az átlag. Először a PHP-ágat ellenőrizze, mert ezen a szinten sűrűsödnek a kifutott értelmezők.

Menedzselt WordPress, havi 20 és 400 font között

A helyes alapértelmezett választás tartalmi oldalakhoz és kis webáruházakhoz. Frissítéseket, tesztkörnyezetet, tűzfalat, állandó objektum-gyorsítótárat és támogatói csapatot vásárol, és a fenti korlátozásokkal fizet érte. A 20 és 100 font közötti sáv egyetlen, mérsékelt forgalmú oldalt fed le. Efölött rendszerint több oldalért, több látogatásért vagy több PHP-munkafolyamatért fizet.

VPS vagy felhő saját veremmel, 15 és 120 font plusz üzemeltetés

Egy szerény felhőpéldány havi 15 és 120 font közé esik, de a gép az olcsó rész. Valakinek foltoznia kell az operációs rendszert, hangolnia a fordított proxyt, futtatnia az objektum-gyorsítótárat és intéznie a mentéseket, ennek megvásárlása pedig további havi 150 és 600 font közé kerül. Megéri, ha a nem gyorsítótárazható terhelés valós, vagy ha a verme olyan követelményeket támaszt, amelyeket egy menedzselt platform tilt.

Egyedi infrastruktúra, havi 400 fonttól felfelé

Több régióra kiterjedő telepítések, nagy párhuzamosságú események, szigorú adatrezidencia, vagy olyan architektúra, amelyben a WordPress csak egy összetevő a több közül. A tárhely megszűnik terméki döntés lenni, és az építés részévé válik, és pontosan így közelítjük meg egy weboldalfejlesztési megbízáson belül.

Méretezés nem gyorsítótárazható kérésekre, nem oldalmegtekintésekre

A tárhelycsomagokat havi látogatásokban árulják, mert ez olyan szám, amelyet a vásárlók felismernek. Kapacitástervezésre szinte használhatatlan, mert 100 000 gyorsítótárazott névtelen oldalmegtekintés szinte semmibe nem kerül, 10 000 bejelentkezett viszont telítheti egy kis szerver kapacitását.

A számító szám az egyidejű, nem gyorsítótárazható kérések száma, és a számtan egyszerű. Egy PHP-munkafolyamat egyszerre egy nem gyorsítótárazható kérést kezel. A szükséges munkafolyamatok száma nagyjából a másodpercenkénti csúcs nem gyorsítótárazható kérésszám szorozva az átlagos PHP-válaszidővel másodpercben. Húsz nem gyorsítótárazható kérés másodpercenként, egyenként 400 ezredmásodperccel, körülbelül nyolc munkafolyamatot igényel a lépéstartáshoz, és ennek legalább a felét még tartalékként érdemes hozzátenni.

Tegyen fel tehát két kérdést, amelyre egyetlen csomagoldal sem válaszol: hány PHP-munkafolyamatot futtat ez a csomag, és mekkora a folyamatonkénti memóriakorlát? Mindkét szám létezik, és rendszerint egyiket sem teszik közzé. A támogatás általában megmondja, ha közvetlenül kérdez, és a válasz többet mond a csomagról, mint az oldalon szereplő összes teljesítménymérés.

Ezután becsülje meg őszintén a saját oldalát. Számolja meg a bejelentkezett munkamenetek arányát, a pénztári és fiókforgalmat a legforgalmasabb órájában, nem az átlagosban, valamint minden admin-ajax vagy REST forgalmat, amelyet a bővítményei a háttérben termelnek, ami a webanalitikában láthatatlan, a szervernaplóban viszont nagyon is látható.

A bővítmények száma és a szerkesztőségi mennyiség tárhelydöntés

Két dolog az oldalon belül határozza meg, mennyi tárhelyre van szüksége, és mindkettőt rendszerint olyan emberek tartalmi döntéseként kezelik, akik a számlát soha nem látják.

Az első a bővítménykészlet. Minden aktív bővítmény hozzáad automatikusan betöltött beállításokat, amelyek minden kérésnél betöltődnek, ütemezett eseményeket, amelyek a látogatói kérésekre indulnak, mert a WordPress cron nem valódi cron, és lekérdezéseket minden oldalfelépítésnél. Harminc bővítmény egy gyorsítótárazott bemutatkozó oldalon elviselhető. Harminc bővítmény egy olyan webáruházon, ahol semmi nem gyorsítótárazódik, azt jelenti, hogy harminc bővítmény fut le a pénztár minden lépésénél. A WordPress rendszermagjának van egy durva elképzelése arról, mikor kezd ez fájni: az állandó objektum-gyorsítótárra vonatkozó Oldalállapot-ellenőrzés objektum-gyorsítótárazást javasol, amint egy oldal átlép olyan küszöböket, mint 2000 bejegyzés, 2000 felhasználó vagy 600 automatikusan betöltött beállítás.

A második a szerkesztőségi mennyiség. A változatok alapértelmezetten korlát nélkül halmozódnak, a médiatárak több tízezer fájlra nőnek, egyenként több generált mérettel, és mindkettő felduzzasztja az adatbázist és a mentési ablakot. Egy oldal, amely öt éve naponta publikál, lényegesen más tárhelyprobléma, mint ugyanaz a felépítés havi publikálással, és a csomagoldalon semmi nem tükrözi ezt. A felépítés, nem a csomag auditálása az, amit egy WordPress fejlesztőnek el kellene végeznie, mielőtt árat ad egy migrációra.

Választás, sorrendben

Haladjon végig ezen a sorrenden, és a döntés rendszerint magától megszületik. Állapítsa meg, forgalmának mekkora hányada nem gyorsítótárazható, mert ez az egyetlen szám kiválasztja a szintjét. Erősítse meg, hogy a PHP-ág és az adatbázisverzió eléri a közzétett alapot, mert az a csomag, amely itt elbukik, az ártól függetlenül kiesik. Tisztázza, mely gyorsítótár-rétegek járnak, és melyeket kell Önnek biztosítania. Kérdezze meg, hol élnek a mentések, milyen formátumban, és hogy le tud-e tölteni egyet még ma. Ezután olvassa el az adatfeldolgozói feltételeket az alfeldolgozókról, az adatok helyéről és a szerződés végi törlésről. Csak mindezek után jelent bármit is az ár, mert addig olyan termékeket hasonlít össze, amelyek nem ugyanaz a termék.

A Mecanik ezt fix munkacsomagként végzi el minden migráció előtt, rendszerint egy weboldalfejlesztési megbízás mellett, és folyamatos támogatásként is elvállalja a WordPress fejlesztő bérlése szolgáltatásunkon keresztül. Ha azt mérlegeli, merre tart maga a platform, a WordPress 7.0-ról és a rendszermagba került MI-kliensről szóló írásunk jó kísérője ennek.

Gyakran ismételt kérdések

Mennyibe kerüljön a WordPress tárhely az Egyesült Királyságban? Szinte teljesen attól függ, forgalmának mekkora része gyorsítótárazható. Egy névtelen látogatókkal működő bemutatkozó oldalt jól kiszolgál a havi 3 és 15 font közötti megosztott tárhely. Egy tartalmi oldal vagy kis webáruház általában a menedzselt WordPress tárhelyhez tartozik, havi 20 és 100 font között, ami forgalmas vagy többoldalas csomagoknál 100 és 400 font közé emelkedik. Egy nagy bejelentkezett forgalmú webáruháznak vagy tagsági oldalnak rendszerint VPS vagy felhőverem kell, 15 és 120 font között a gépért, plusz havi 150 és 600 font, ha valaki más üzemelteti.

Megéri a menedzselt WordPress tárhely a felárat? Megéri, ha nincs üzemeltetője, mert frissítéseket, tesztkörnyezetet, mentéseket, tűzfalat és állandó objektum-gyorsítótárat vásárol, amelyeket különben magának kellene beállítania. A csere valódi korlátozásokkal jár. A szolgáltatók rendszeresen tiltják a gyorsítótár-, a mentő- és az adatbázis-igényes bővítményeket, gyakran visszatartják a parancssori hozzáférést, korlátozzák a hosszan futó folyamatokat és blokkolják a kimenő levelezést. Ezeket a korlátokat a saját felépítéséhez mérje, mielőtt elkötelezi magát, ne utána.

Milyen PHP-verzióra van szüksége a WordPressnek 2026-ban? A WordPress a PHP 8.3-as vagy újabb verzióját ajánlja. Továbbra is fut PHP 7.4-en és afölött, de azok az ágak kifutottak, és nem kapnak biztonsági javításokat. A PHP 8.1 2025. december 31-én ért véget, a PHP 8.0 2023. november 26-án, a PHP 7.4 pedig 2022. november 28-án, míg a PHP 8.2 2026. december 31-ig csak biztonsági javításokat kap. A WordPress-telepítések körülbelül 38,8 százaléka még mindig teljesen kifutott ágat jelent.

Javítja a jobb tárhely a Core Web Vitals mutatókat? A háromból csak egyet, és azt is csak közvetve. A szerverválaszidő a Largest Contentful Paint része, tehát egy gyorsabb szolgáltató minden látogatónál csökkenti az LCP-t. A Cumulative Layout Shift mutatóért szinte semmit nem tesz, mert az méret nélküli képekből és későn betöltő betűtípusokból ered, az Interaction to Next Paint mutatóért pedig nagyon keveset, amelyet a fő szálon futó JavaScript ural. Ha a szerverválasza már kényelmes, a maradék probléma az oldalban van.

Miért lassú a WooCommerce webáruházam egy olyan csomagon, amely gyorsnak mondja magát? Mert azok az oldalak, amelyek számítanak, nem gyorsítótárazhatók. A WooCommerce megköveteli, hogy a Kosár, a Fiókom és a Pénztár dinamikus maradjon, és olyan munkamenet-sütiket állít be, amelyek a bejelentkezett vásárlóknál megkerülik az oldal-gyorsítótárat. A kezdőoldalán futtatott sebességteszt egy gyorsítótárazott fájlt mér, miközben a pénztár minden kérésnél PHP-t futtat és az adatbázist terheli. A nem gyorsítótárazható kérésekre szánt kapacitás, nem pedig a gyorsítótárazott kezdőoldal száma az, amit egy webáruház valójában megvásárol.