WordPress-tárhely és bővítmények
A WordPress gyorsabbá és biztonságosabbá tétele: Teljesítmény- és bővítmény-ellenőrzőlista
A WordPress mindig csak annyira gyors és biztonságos, mint az azt futtató környezet. Íme a gyakorlati ellenőrzőlista, amelyet minden általunk üzemeltetett WordPress-webhelyre alkalmazunk: mit érdemes gyorsítótárazni, mit kell biztonságossá tenni, és mely bővítmények érdemlik meg a helyüket szemben azokkal, amelyeket a platform feleslegessé tesz.
A WordPress csak annyira jó, mint a futtató környezete
A WordPress rugalmassága révén működteti az internet jelentős részét, ám ugyanez a rugalmasság vezet a lassulásához és sebezhetőségéhez is: egy alapértelmezett telepítés oldalanként több tucat adatbázis-lekérdezést hajt végre, bárki számára közzéteszi a verzióját és a technológiai környezetét, valamint bővítmények halmozására ösztönöz, amíg a teljesítmény és a támadási felület észrevétlenül fel nem duzzad. Mindez nem annyira a WordPress hibája, mint inkább annak a következménye, hogy olyan infrastruktúrán futtatják, amely semmilyen segítséget nem nyújt.
A jó hír az, hogy ugyanaz a néhány döntés megoldja a problémák túlnyomó részét, és ezek a technológiai infrastruktúrát érintő döntések, nem pedig a tartalmat. Gyorsítótárazzon agresszívan a megfelelő rétegben, tartsa távol az adatbázist a kritikus útvonaltól, csak azt a néhány bővítményt futtassa, amely valóban kiérdemli a helyét, tartson mindent naprakészen frissítve, és különítse el a webhelyet, hogy a felmerülő probléma elszigetelt maradjon. Ez a bejegyzés ezt az ellenőrzőlistát tartalmazza, pontosan abban a sorrendben, ahogyan a platformon található összes WordPress webhelyre alkalmazzuk.
Gyorsítótárazzon a szerveren, ne 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 szabványos kérés elindítja a WordPress-t, futtatja a bővítményeket, és lekérdezi az adatbázist, mielőtt egyetlen bájtot is elküldene; a teljes oldalas gyorsítótár a következő kéréskor közvetlenül a webszerverről szolgálja ki a kész oldalt, teljesen kihagyva ezt a betöltési folyamatot. Az is számít, hogy hol található ez a gyorsítótár: egy gyorsítótárazó bővítmény a PHP-n belül helyezkedik el, így a PHP még a gyorsítótár válaszadása előtt elindul, míg a szerverszintű gyorsítótár a kérés korábbi szakaszában válaszol, és olyan formában tárolja az oldalakat, amelyet a szerver azonnal ki tud üríteni.
Minden általunk üzemeltetett WordPress webhely LiteSpeed Enterprise szerveren fut szerverszintű LSCache gyorsítótárazással, saját gyorsítótár-bővítményünk pedig már az első pillanattól megfelelően összekapcsolja vele a WordPress rendszert — előre telepítve és automatikusan frissítve, így eggyel kevesebb dologgal kell foglalkoznia a konfigurálás vagy a naprakészen tartás során. Nem LiteSpeed-alapú forráskiszolgálón ugyanez a bővítmény egyszerűen nem bocsát ki teljes oldalas fejléceket, és észrevétlen marad, miközben az objektum-gyorsítótár tovább működik, így az átköltöztetett webhely soha nem marad félig konfigurálva. A gyakorlati szabály az Ön ellenőrzőlistájához: egyetlen teljes oldalas gyorsítótár a szerveren, és ne halmozzon rá egy második gyorsítótárazó bővítményt — összeakadnak.
Az objektum-gyorsítótár és az adatbázis
Nem minden kérés lehet statikus oldal. A bejelentkezett munkameneteknek, az adminisztrációs felületnek, a keresésnek, a kosaraknak és minden személyre szabott töredéknek futtatnia kell a PHP-t, és ezek esetében a cél az alkalmazás kihagyásáról az adatbázis kihagyására módosul. Egy webhelyenkénti objektum-gyorsítótár — a mi esetünkben a Redis — a memóriában tárolja az ismételt adatbázis-olvasások eredményeit, így nem kérdezi le ugyanazokat a beállításokat, transients elemeket és kereséseket az adatbázisból minden egyes lekéréskor. A hatás pontosan ott mutatkozik meg, ahol a teljes oldal gyorsítótárazása nem segíthet: gyorsabb adminisztrációs felület, gyorsabb kosarak és jóval alacsonyabb adatbázis-terhelés forgalom alatt.
A döntő szó a „webhelyenkénti”. A megosztott objektum-gyorsítótár azt jelenti, hogy egyetlen forgalmas vagy rosszul megírt webhely kilökheti az összes többi gyorsítótárazott adatait, és kiéheztetheti az adatbázist a szomszédai elől; egy dedikált, webhelyenkénti gyorsítótár a webhelyenkénti adatbázis-korlátokkal párosítva féken tartja ezt a káros hatássugarat. Az ellenőrzőlistáján tekintse a perzisztens objektum-gyorsítótárat kötelezőnek minden bejelentkezett felhasználókkal vagy áruházzal rendelkező webhely esetében, és legyen óvatos az olyan tárhelyekkel, ahol ez meg van osztva a bérlők között.
A futtatásra érdemes bővítmények — és amelyeket a platform helyettesít
Minden hozzáadott bővítmény olyan kód, amely a kérések során fut le, és egy olyan ajtó, amelyen egy nap valaki beléphet, így az őszinte cél a lehető legkevesebb bővítmény használata, amelyek a legtöbbet nyújtják. Egy jó tárhelyszolgáltató ezek egy egész kategóriáját feleslegessé teszi: a szerverszintű gyorsítótárazással, a felügyelt objektum-gyorsítótárral és a platformszintű biztonsági mentésekkel nincs szüksége gyorsítótárazó bővítményre, külön objektum-gyorsítótár bővítményre vagy biztonsági mentési bővítményre — ezeket a feladatokat a WordPress alatt jobban el lehet végezni, a felülről történő futtatásuk pedig csak konfliktusokat és felesleges terhelést okoz.
Amit érdemes futtatni, az a bővítmények azon szűk köre, amely valódi funkciót nyújt: azok a bővítmények, amelyekre webhelyének ténylegesen szüksége van a működéséhez, valamint — a mi platformunkon — az a két hivatalos tároló-szintű bővítmény, amelyet mi fejlesztünk és minden webhelyhez 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 azokat az oldalakat törli a gyorsítótárból, amelyeket szükséges. A footprint-eltávolító bővítményünk minden közzétételkor eltávolítja azokat az azonosító jegyeket, amelyeket az alapértelmezett WordPress telepítés közvetít — a verziót és a generator címkét, a felderítési végpontokat, az XML-RPC-t, a pingbackeket és a powered-by fejlécet —, így a bővítmények vagy témák frissítései nem tudják észrevétlenül visszaállítani őket. Mindkettő a WordPress.org bővítménytár szabványai szerint készült, ingyenes, és automatikusan frissül.
A WordPress biztonságban és naprakészen tartása
A legtöbb WordPress-feltörés nem kifinomult, hanem elavult hibákra épül. A webhelyeket túlnyomórészt az elavult mag, sablon vagy beépülő modul ismert, közzétett sebezhetőségein keresztül érik támadások, ami a frissítések követését a legértékesebb biztonsági feladattá teszi — és a legunalmasabbá is, ezért szokták elhanyagolni. A menedzselt tárhelynek le kellene vennie ezt a terhet az Ön válláról: a WordPress alatti technológiai háttér javításával, valamint a mag és a bővítmények biztonságos frissíthetőségének garantálásával egy tesztkörnyezet és egy visszaállítható biztonsági mentés biztosítása révén.
A naprakészségen felül számítson arra, hogy a biztonsági határok érvényre jutnak Ön helyett: a rosszindulatú programok vizsgálata alapértelmezés szerint be van kapcsolva, így a fertőzést észleli a rendszer, ahelyett hogy egy látogató fedezné fel, az elkülönítés révén egy kompromittálódott webhely nem érhet el egy másikat, a hálózat peremén működő DDoS-védelem biztosított, valamint mindenhol jelen lévő TLS automatikusan megújuló tanúsítványokkal. Ezek egyike sem helyettesíti az alapvető digitális higiéniát — az erős hitelesítő adatokat, a legkisebb jogosultság elvét követő hozzáférést, a már nem használt bővítmények eltávolítását —, de azt jelenti, hogy nem az infrastruktúra a gyenge láncszem. Az Ön ellenőrzőlistáján a kérdés bármely tárhelyszolgáltató felé egyszerű: a biztonság az alapértelmezett állapot, vagy egy megvásárolandó csomag?
A WooCommerce és az oldalak, amelyeket soha nem szabad gyorsítótáraznia
Egy webáruház az a hely, ahol az agresszív gyorsítótárazás a legnagyobb hasznot hozza, ugyanakkor a legsúlyosabb károkat okozza, ha nem kellő körültekintéssel alkalmazzák. A katalógus-, termék- és kategóriaoldalak a legnagyobb forgalmú és legjobban gyorsítótárazható oldalai, így a teljes oldalas gyorsítótárból való kiszolgálásuk a legjobb dolog, amit a webáruház sebességéért tehet. A kosár-, a pénztár- és a fiókoldalak azonban személyes jellegűek, és azokat soha nem szabad megosztott gyorsítótárból kiszolgálni — ha mégis megteszi, a vásárló más kosarát fogja látni, ami a működésképtelen áruház mellett súlyos adatvédelmi incidens is.
A kettő ötvözésének módja az oldal gyorsítótárazása és a dinamikus részek számára lyukak kivágása. Az Edge Side Includes kérésenként jeleníti meg a kosárrészletet, a minikosár összegzését és a fiók állapotát, miközben az oldal többi része a gyorsítótárból kerül kiszolgálásra, a cart, checkout, my-account, valamint a nonce vagy session oldalakat pedig alapértelmezés szerint kizárja a rendszer. A frissességről egy intelligens automatikus ürítés gondoskodik, amely egy termék, ár vagy rendelés módosításakor aktiválódik, így az elavult ár soha nem marad látható. Ha Ön WooCommerce rendszert futtat, az ellenőrzőlistának ezt a részét kell tökéletesen megvalósítania: gyors kirakat a gyorsítótárból, élő kosár felhasználónként, és a személyes adatok gyorsítótárazásának teljes mellőzése.
Gyakran ismételt kérdések
Szükségem van még gyorsítótárazó bővítményre, mint például a WP Rocket?
Nem. A teljes oldalas gyorsítótárazást a webszerveren a LiteSpeed LSCache modulja kezeli, saját gyorsítótárazó bővítményünk ehhez kapcsolja a WordPress rendszert és intézi az intelligens ürítést, a háttérben pedig egy webhelyenkénti Redis objektum-gyorsítótár működik. Egy második, teljes oldalas gyorsítótárazó bővítmény hozzáadása jellemzően inkább ütközik a szerverszintű gyorsítótárral, mintsem segítene, így sem nem szükséges, sem nem ajánlott.
Mely bővítményeket teszi feleslegessé a platform?
A gyorsítótárazó bővítmények, a különálló objektum-gyorsítótár bővítmények és a biztonsági mentést végző bővítmények itt mind feleslegesek, mivel ezek a feladatok a WordPress szintje alatt zajlanak – szerverszintű gyorsítótárazás, webhelyenként kezelt objektum-gyorsítótár és platformszintű biztonsági mentések formájában. Eltávolításuk csökkenti az ütközéseket és a támadási felületet. Amit érdemes futtatva hagyni, azok a webhelye működéséhez valóban szükséges bővítmények, valamint 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 tönkreteheti a WooCommerce kosaramat vagy a bejelentkezett felhasználók oldalait?
Nem. A Cart, checkout, my-account, valamint a nonce- vagy munkamenet-oldalak alapértelmezés szerint ki vannak zárva a gyorsítótárból, az Edge Side Includes pedig élőben tartja a kosár töredékét és az összegeket az egyébként gyorsítótárazott oldalakon. A vásárlók mindig a saját kosarukat és egy működő fizetési felületet látnak, miközben a kirakat továbbra is a gyorsítótárból töltődik be, és az intelligens automatikus ürítés törli az érintett oldalakat, ha egy termék, ár vagy rendelés megváltozik.
Hogyan tartják biztonságban a WordPress-t anélkül, hogy nekem kellene kezelnem?
Biztosítjuk a javításokat a WordPress alatti technológiai környezethez, a tesztkörnyezetnek (staging) és az egykattintásos visszaállításnak köszönhetően biztonságossá tesszük a mag és a bővítmények frissítéseit, alapértelmezés szerint bekapcsolva tartjuk a rosszindulatú programok keresését és a DDoS-védelmet, elszigeteljük az egyes webhelyeket, hogy egy esetleges biztonsági rés ne terjedhessen tovább, valamint automatikusan kiállítjuk és megújítjuk a TLS-tanúsítványokat. Ez kiküszöböli az infrastruktúrát mint gyenge láncszemet; az alapvető higiénia, mint például az erős hitelesítési adatok használata és a nem használt bővítmények eltávolítása, továbbra is az Ön feladata.
Kapcsolódó
Próbálja ki ingyenesen 14 napig
Indítsa el első webhelyeit 14 napig ingyenesen — bankkártya nélkül. Meglévő webhelyet vagy hálózatot költöztet? Az átköltöztetés korlátlanul ingyenes.
Kezdés ingyen