WordPress Tárhely és Bővítmények
A WordPress gyors és biztonságos tétele: Teljesítmény- és bővítményellenőrzőlista
A WordPress csak annyira gyors és biztonságos, amennyire az azt futtató környezet. Íme a gyakorlati ellenőrzőlista, amelyet minden általunk hostolt WordPress oldalnál alkalmazunk: mit érdemes gyorsítótárazni, mit kell biztosítani, és mely pluginok érdemlik meg a helyüket a platform által feleslegessé tettekkel szemben.
A WordPress csak annyira jó, mint ami futtatja
A WordPress a web nagy részét azért mozgatja, mert rugalmas, de ez a rugalmasság okozza azt is, hogy lassúvá és nem biztonságossá válik: egy alapértelmezett telepítés oldalanként tucatjával kérdezi le az adatbázist, minden érdeklődőnek közvetíti a verzióját és a szoftververemét, és arra ösztönöz, hogy addig halmozd a bővítményeket, amíg a teljesítmény és a támadási felület is észrevétlenül meg nem duzzad. Mindez nem a WordPress hibája, sokkal inkább annak a következménye, hogy olyan infrastruktúrán futtatják, amely semmit sem tesz azért, hogy ezen segítsen.
A jó hír az, hogy ugyanezek a döntések megoldják a problémák nagy részét, és ezek inkább a technológiai veremre, mintsem a tartalomra vonatkoznak. Használjon agresszív gyorsítótárazást a megfelelő rétegben, tartsa távol az adatbázist a kritikus útvonalaktól, csak a valóban hasznos bővítményeket futtassa, tartson mindent naprakészen, és izolálja a webhelyet, hogy egy esetleges probléma korlátozott maradjon. Ez a bejegyzés ezt az ellenőrzőlistát tartalmazza abban a sorrendben, ahogyan a platformon található összes WordPress webhelyre alkalmazzuk.
Gyorsítótárazás a szerveren, nem csak egy bővítményben
A WordPress sebességére a legnagyobb hatással az van, ha a legtöbb látogatás során egyáltalán nem futtatja a WordPress rendszert. Egy standard kérés elindítja a WordPress-t, futtatja a bővítményeket, és lekérdezi az adatbázist, mielőtt elküldene egy bájtot is; a teljes oldalas gyorsítótár a következő találatkor egyenesen a webszerverről szolgálja ki a kész oldalt, átugorva ezt az egész indulási folyamatot. Az, hogy hol lakik ez a gyorsítótár, számít: egy gyorsítótárazási bővítmény a PHP-n belül helyezkedik el, így a PHP még mindig elindul, mielőtt a gyorsítótár válaszolhatna, míg egy szerver szintű gyorsítótár korábban válaszol a kérésre, és olyan formában tárolja az oldalakat, amelyet a szerver azonnal ki tud küldeni.
Minden általunk hostolt WordPress webhely LiteSpeed Enterprise-on fut, kiszolgálói szintű LSCache-dzsel, és a saját cache bővítményünk a dobozból kivéve megfelelően összekapcsolja vele a WordPress rendszert – előre telepítve és automatikusan frissítve, így egyvalamivel kevesebb dolga marad a konfigurálás vagy a naprakészen tartás terén. Egy nem LiteSpeed alapú forráskiszolgálón ugyanez a bővítmény egyszerűen nem küld teljes oldalas fejléceket, és nem avatkozik közbe, miközben az objektum-cache továbbra is működik, így az átköltöztetett webhelyek sosem maradnak félig konfigurált állapotban. A gyakorlati szabály az Ön saját ellenőrzőlistájához: egy teljes oldalas cache a szerveren, és ne halmozzon fel rá egy második cache-bővítményt is – mert összevesznek.
Az objektum-gyorsítótár és az adatbázis
Nem minden kérés lehet statikus oldal. A bejelentkezett munkamenetek, az adminisztráció, a kereső, a kosarak és minden személyre szabott töredék PHP-n fut, és ezeknél a cél az alkalmazás kihagyása helyett az adatbázis kihagyására módosul. A webhelyenkénti objektumgyorsítótár – esetünkben a Redis – a memóriában tárolja az ismétlődő adatbázis-olvasások eredményeit, így ugyanazokat a beállításokat, tranzienseket és lekérdezéseket nem az adatbázistól kérdezi le a rendszer minden egyes találatkor. A hatás pontosan ott mutatkozik meg, ahol a teljes oldalas gyorsítótár nem segíthet: gyorsabb adminisztráció, gyorsabb kosarak, és sokkal alacsonyabb adatbázis-terhelés nagy forgalom mellett.
A lényeg a webhelyenkénti megközelítésben rejlik. A megosztott objektum-gyorsítótár azt jelenti, hogy egyetlen forgalmas vagy rosszul megírt webhely kiürítheti az összes többi gyorsítótárazott adatát, és kiéheztetheti az adatbázist a szomszédai számára; a dedikált, webhelyenkénti gyorsítótár a webhelyenkénti adatbázis-korlátokkal párosulva korlátozva tartja ezt a robbanási sugarat. A teendőlistáján kezelje a állandó objektum-gyorsítótárat nem opcionálisként minden olyan webhely esetében, amely bejelentkezett felhasználókkal vagy áruházzal rendelkezik, és legyen óvatos az olyan tárhelyszolgáltatásokkal, ahol ezt bérlők között osztják meg.
A bővítmények, amelyeket érdemes használni — és azok, amelyeket a platform kivált
Minden egyes bővítmény, amit hozzáadsz, olyan kód, amely a kérések alkalmával lefut, és egy ajtó, amelyen valaha bejöhet valaki, így a becsületes cél a lehető legkevesebb bővítmény, amely a legtöbbet nyújtja. Egy jó tárhelyszolgáltató megszünteti a szükségességét egy egész kategóriának: a kiszolgálói szintű gyorsítótárazással, a felügyelt objektum-gyorsítótárral és a platform szintű biztonsági mentésekkel nincs szükséged gyorsítótárazási bővítményre, különálló objektum-gyorsítótár bővítményre vagy biztonsági mentési bővítményre – ezeket a feladatokat jobban elvégzik a WordPress alatt, és a tetejükön futtatni őket csak konfliktusokat és többletterhelést okoz.
Ami érdemes futtatni, az a valódi funkciót adó kis készlet: azok a bővítmények, amelyekre a webhelyének a működéséhez valóban szüksége van, valamint – a platformunkon – a két tárhelyszintű bővítmény, amelyeket minden webhelyhez elkészítünk és mellékelünk. Gyorsítótár-bővítményünk összekapcsolja a WordPress rendszert a szerver gyorsítótárával, és intelligens ürítést végez, így a módosítás csak a megfelelő oldalakat törli. Lábnyom bővítményünk minden egyes üzembe helyezéskor eltávolítja az alapértelmezett WordPress telepítés által sugárzott árulkodó jeleket – a verziót és a generátor címkét, a felderítési végpontokat, az XML-RPC-t, a pingbackeket és a powered-by fejlécet –, így egy bővítmény vagytéma frissítés sem tudja azokat észrevétlenül visszatenni. Mindkettő a WordPress.org bővítménykönyvtár szabványai szerint készült, ingyenes, és saját magát frissíti.
A WordPress biztonságának és naprakészségének megőrzése
A legtöbb WordPress feltörés nem okos; régi. A naprakészség hiánya – egy elavult mag, téma vagy bővítmény ismert, nyilvánosságra hozott sebezhetőséggel – a túlnyomó többsége annak, ahogyan az oldalak áldozatul esnek, így a frissítések fenntartása a legnagyobb értékű biztonsági feladat, ami csak létezik, és egyben a legunalmasabb is, ezért szokták kihagyni. A menedzselt tárhelynek ezt le kellene vennie a válláról: javítania kellene a WordPress alatti stacket, és biztonságossá kellene tennie a mag- és bővítményfrissítések alkalmazását azáltal, hogy egy tesztkörnyezetet biztosít a kipróbálásukhoz, valamint egy biztonsági mentést a visszaállításhoz.
A pénzen felül számíthat arra is, hogy a határokat betartatják Ön helyett: alapértelmezett kártevővizsgálat, hogy a fertőzést még azelőtt kiszűrjék, hogy azt egy látogató észlelné; izoláció, hogy egy feltört webhely ne érhessen el másikat; peremhálózaton biztosított DDoS-védelem; valamint mindenhol TLS automatikusan megújuló tanúsítványokkal. Ezek egyike sem pótolja az alapvető higiéniát – az erős hitelesítő adatokat, a legkisebb jogosultság elvét, a már nem használt bővítmények eltávolítását –, de azt jelenti, hogy az infrastruktúra nem a gyenge láncszem. Az ellenőrzőlistáján bármelyik tárhelyszolgáltató esetén egyszerű a kérdés: a biztonság az alapértelmezett, vagy egy megvásárolható csomag?
A WooCommerce és a oldalak, amelyeket soha nem szabad gyorsítótárazni
Az áruház az a hely, ahol az agresszív gyorsítótárazás a legnagyobb sikereit éri el, és a legsúlyosabb károkat okozza, ha elhamarkodott. A katalógus-, a termék- és a kategóriaoldalak a legnagyobb forgalmú, legjobban gyorsítótárazható oldalak, amelyek kiszolgálása a teljes oldalas gyorsítótárból a legjobb dolog, amit egy áruház sebességéért tehet. A kosár, a pénztár és a fiók oldalak azonban személyesek, és soha nem szolgálhatók ki megosztott gyorsítótárból – ha ezt teszi, a vásárló valaki más kosarát fogja látni, ami egyszerre jelent hibás áruházat és adatvédelmi kudarcot.
A kettő kombinációjának a módja az oldal gyorsítótárazása és az élő részek számára fenntartott lyukak kihagyása. Az Edge Side Includes kérésenként jeleníti meg a kosártöredéket, a minikosár végösszegeit és a fiók állapotát, míg az oldal többi része a gyorsítótárból kerül kiszolgálásra, a kosár, a pénztár, a fiókom, valamint minden nonce- vagy munkamenetoldal pedig alapértelmezés szerint ki van zárva. A frissességről intelligens automatikus törlés gondoskodik, amely egy termék, ár vagy rendelés változásakor lép életbe, így soha nem marad fenn elavult ár. Ha a WooCommerce rendszert futtatja, ez az a része az ellenőrzőlistának, amelyet pontosan be kell állítani: gyors áruházfelület a gyorsítótárból, élő kosár felhasználónként, és soha semmilyen személyes adat nem kerül gyorsítótárazásra.
Gyakran ismételt kérdések
Szükségem van még olyan gyorsítótárazási bővítményre, mint a WP Rocket?
Nem. A teljes oldalas gyorsítótárazást a webszerveren a LiteSpeed LSCache modulja kezeli, a saját gyorsítótár-bővítményünk összeköti a WordPress rendszert vele és kezeli az intelligens ürítést, míg mögötte egy webhelyenkénti Redis objektum-gyorsítótár működik. Egy második teljes oldalas gyorsítótár-bővítmény hozzáadása ezen felül általában a szerver szintű gyorsítótár ellen hat ahelyett, hogy segítene, így sem nem szükséges, sem nem ajánlott.
Melyik bővítményeket teszi feleslegessé a platform?
A gyorsítótár-bővítmények, a különálló objektum-gyorsítótár bővítmények és a biztonsági mentési bővítmények itt mind feleslegesek, mivel ezeket a feladatokat a WordPress szintje alatt végezzük – szerverszintű gyorsítótárazással, felügyelt webhelyenkénti objektum-gyorsítótárakkal és platformszintű biztonsági mentésekkel. Eltávolításuk csökkenti az ütközéseket és a támadási felületet. Ami megmarad és érdemes futtatni, azok azok a bővítmények, amelyekre a webhelyének a működéséhez valóban szüksége van, plusz a két ingyenes gyorsítótár- és footprint-bővítményünk, amelyek előre telepítve érkeznek.
A gyorsítótárazás feltöri a WooCommerce kosaramat vagy a bejelentkezett oldalakat?
Nem. A kosár, a fizetési oldal, a fiókom oldal, valamint a nonce- vagy munkamenet-oldalak alapértelmezés szerint ki vannak zárva a gyorsítótárból, az Edge Side Includes technológia pedig frissen tartja a kosárelemet és az összegeket a egyébként gyorsítótárazott oldalakon. A vásárlók mindig a saját kosarukat látják és egy működő pénztárt, miközben a webáruház továbbra is a gyorsítótárból töltődik be, az intelligens automatikus törlés pedig törli az érintett oldalakat, amikor egy termék, ár vagy rendelés megváltozik.
Hogyan tartjátok biztonságban a WordPress webhelyet anélkül, hogy nekem kellene kezelnem?
Foltokat teszünk a WordPress alatti szoftverhalmazra, a staginggel és az egykattintásos visszaállítással biztonságossá tesszük a mag- és bővítményfrissítések alkalmazását, alapértelmezés szerint futtatjuk a kártevőkeresést és a DDoS-védelmet, elszigeteljük az egyes webhelyeket, hogy egyetlen feltörés se tudjon átterjedni, valamint automatikusan kiállítjuk és megújítjuk a TLS-tanúsítványokat. Ezzel megszüntetjük az infrastruktúrát mint gyenge láncszemet; az olyan alapvető higiéniai intézkedések, mint az erős hitelesítő adatok és a nem használt bővítmények eltávolítása, továbbra is az Ön feladatai.
Kapcsolódó
Próbálja ki ingyen 14 napig
Indítsd el első webhelyeidet ingyen 14 napig – kártya nélkül. Meglévő webhelyet vagy hálózatot költöztetsz? Az első migrációt mi álljuk.
Kezdje ingyen