WordPress-hosting en plug-ins
WordPress snel en veilig maken: een controlelijst voor prestaties en plug-ins
WordPress is slechts zo snel en veilig als de omgeving waarop het draait. Hier is de praktische controlelijst die wij toepassen op elke WordPress-site die wij hosten — wat u moet cachen, wat u moet beveiligen, en welke plug-ins hun plek verdienen vergeleken met de plug-ins die het platform overbodig maakt.
WordPress is maar zo goed als hetgeen waarop het draait
WordPress drijft een groot deel van het web aan omdat het flexibel is, maar die flexibiliteit zorgt er ook voor dat het traag en onveilig wordt: een standaardinstallatie bevraagt de database tientallen keren per pagina, toont zijn versie en stack aan iedereen die kijkt, en nodigt u uit om plugins op te stapelen totdat zowel de prestaties als het aanvalsoppervlak geruisloos opzwellen. Niets daarvan is zozeer een fout in WordPress als wel een gevolg van het draaien ervan op infrastructuur die niets doet om te helpen.
Het goede nieuws is dat dezelfde handvol beslissingen het merendeel hiervan oplost, en dat zijn beslissingen over de stack in plaats van over de content. Pas agressieve caching toe op de juiste laag, houd de database buiten het kritieke pad, draai alleen die paar plug-ins die hun plek echt verdienen, houd alles gepatcht en isoleer de site zodat een probleem beperkt blijft. Dit bericht is die controlelijst, in de volgorde waarin we deze toepassen op elke WordPress-site op het platform.
Cache op de server, niet alleen in een plug-in
De grootste factor voor de snelheid van WordPress is WordPress bij de meeste bezoeken helemaal niet uit te voeren. Een standaardverzoek start WordPress op, voert uw plug-ins uit en raadpleegt de database voordat er één byte wordt verzonden; een volledige-paginacache levert bij het volgende bezoek de voltooide pagina rechtstreeks vanaf de webserver en slaat die hele opstartprocedure over. Waar die cache zich bevindt, maakt uit: een caching-plug-in bevindt zich binnen PHP, waardoor PHP nog steeds start voordat de cache kan antwoorden, terwijl een cache op serverniveau eerder in het verzoek antwoordt en pagina's bewaart in een vorm die de server onmiddellijk kan wissen.
Elke WordPress-site die we hosten draait op LiteSpeed Enterprise met LSCache op serverniveau, en onze eigen cache-plug-in koppelt WordPress hier direct op de juiste manier aan — vooraf geïnstalleerd en automatisch bijgewerkt, zodat u dit niet zelf hoeft te configureren of actueel te houden. Op een niet-LiteSpeed-origin stuurt dezelfde plug-in simpelweg geen 'full-page'-headers uit en blijft deze op de achtergrond terwijl de objectcache blijft werken, zodat een gemigreerde site nooit half geconfigureerd achterblijft. De praktische regel voor uw eigen controlelijst: één 'full-page'-cache, op de server, en stapel er geen tweede caching-plug-in bovenop — ze gaan met elkaar conflicteren.
De objectcache en de database
Niet elk verzoek kan een statische pagina zijn. Ingelogde sessies, het beheergedeelte, zoekopdrachten, winkelwagens en elk gepersonaliseerd fragment moeten PHP uitvoeren, en daarvoor verschuift het doel van het overslaan van de applicatie naar het overslaan van de database. Een objectcache per site — in ons geval Redis — bewaart de resultaten van herhaalde database-leesbewerkingen in het geheugen, zodat dezelfde opties, transients en lookups niet bij elk bezoek opnieuw bij de database worden opgevraagd. Het effect is precies zichtbaar waar paginacache niet kan helpen: een snellere beheeromgeving, snellere winkelwagens en een aanzienlijk lagere databasebelasting bij veel verkeer.
Het woord dat ertoe doet is per-site. Een gedeelde objectcache betekent dat één drukke of slecht geschreven site de gecachte gegevens van alle anderen kan verdringen en de database voor zijn buren kan uithongeren; een toegewijde cache per site, gecombineerd met databaselimieten per site, houdt die schaderadius beperkt. Beschouw op uw controlelijst een persistente objectcache als niet-optioneel voor elke site met ingelogde gebruikers of een winkel, en wees op uw hoede voor hosting waarbij deze wordt gedeeld over meerdere huurders.
De plugins die het waard zijn om te gebruiken — en degene die het platform vervangt
Elke plug-in die u toevoegt is code die bij verzoeken wordt uitgevoerd en een deur waar ooit iemand doorheen zou kunnen lopen; het eerlijke doel is dan ook het kleinste aantal plug-ins dat het meeste doet. Een goede host neemt de noodzaak voor een hele categorie ervan weg: met caching op serverniveau, een beheerde objectcache en platformback-ups hebt u geen caching-plug-in, afzonderlijke objectcache-plug-in of back-up-plug-in nodig — die taken worden beter onder WordPress uitgevoerd, en ze erbovenop draaien zorgt alleen maar voor conflicten en overhead.
Wat overblijft dat het uitvoeren waard is, is de kleine set die echte functionaliteit toevoegt: de plug-ins die uw site daadwerkelijk nodig heeft voor zijn werking, en — op ons platform — de twee plug-ins van repository-kwaliteit die we bouwen en meeleveren met elke site. Onze cache-plug-in verbindt WordPress met de servercache en verzorgt slimme schoning, zodat een bewerking alleen de pagina's wist die gewist moeten worden. Onze footprint-plug-in verwijdert bij elke implementatie de herkenningspunten die een standaard WordPress-installatie uitzendt — de versie- en generator-tag, discovery endpoints, XML-RPC, pingbacks en de powered-by-header — zodat een plug-in- of thema-update deze niet stilletjes kan terugplaatsen. Beide zijn gebouwd volgens de richtlijnen van de WordPress.org-plug-indirectory, zijn gratis en updaten zichzelf.
WordPress veilig en up-to-date houden
De meeste WordPress-beveiligingsincidenten zijn niet geavanceerd; ze zijn oud. Een verouderde core, thema of plug-in met een bekend, gepubliceerd beveiligingslek is veruit de meest voorkomende manier waarop websites worden getroffen. Up-to-date blijven is dan ook het meest waardevolle beveiligingswerk dat er is — en het meest tijdrovende, waardoor het vaak wordt overgeslagen. Managed hosting hoort dit uit handen te nemen: het patchen van de stack onder WordPress en het veilig maken van core- en plug-in-updates door u een testomgeving te bieden om ze te testen en een back-up om naar terug te keren.
Boven op de actualiteit mag u verwachten dat de grenzen voor u worden bewaakt: malwarescans die standaard zijn ingeschakeld zodat een infectie wordt onderschept in plaats van ontdekt door een bezoeker, isolatie zodat een gecompromitteerde site geen andere kan bereiken, DDoS-bescherming aan de rand van het netwerk, en overal TLS met certificaten die automatisch worden vernieuwd. Niets daarvan vervangt de basishygiëne — sterke inloggegevens, toegang met minimale rechten, het verwijderen van plugins die u niet meer gebruikt — maar het betekent wel dat de infrastructuur niet de zwakke schakel is. Op uw checklist is de vraag voor elke host eenvoudig: is beveiliging de standaard, of een bundel die u moet kopen?
WooCommerce en de pagina's die u nooit mag cachen
Een winkel is waar agressieve caching zijn grootste winst behaalt en zijn ergste schade aanricht als het naïef gebeurt. De catalogus-, product- en categoriepagina's zijn de pagina's met het meeste verkeer en de beste cachemogelijkheden die u heeft, en het aanbieden ervan vanuit een paginacache is het allerbeste wat u kunt doen voor de snelheid van een winkel. Maar winkelwagen-, afreken- en accountpagina's zijn persoonlijk en mogen nooit vanuit een gedeelde cache worden aangeboden — doet u dat wel, dan ziet een koper het winkelmandje van iemand anders, wat zowel een kapotte winkel als een inbreuk op de privacy betekent.
De manier om beide te hebben, is door de pagina te cachen en gaten te maken voor de dynamische onderdelen. Edge Side Includes renderen het winkelwagenfragment, de minitotalen van de winkelwagen en de accountstatus per verzoek terwijl de rest van de pagina vanuit de cache wordt geserveerd, en winkelwagen-, afreken-, mijn account- en eventuele nonce- of sessiepagina's zijn standaard uitgesloten. Versheid wordt afgehandeld door slimme automatische opschoning die wordt geactiveerd wanneer een product, prijs of bestelling verandert, zodat een verouderde prijs nooit blijft hangen. Als u WooCommerce gebruikt, is dit het onderdeel van de checklist dat u precies goed moet hebben: een snelle storefront vanuit de cache, een live winkelwagen per gebruiker, en nooit iets persoonlijks gecachet.
Veelgestelde vragen
Heb ik nog steeds een caching-plugin zoals WP Rocket nodig?
Nee. Volledige paginacaching wordt op de webserver afgehandeld door LSCache van LiteSpeed, onze eigen caching-plugin koppelt WordPress hieraan en regelt het slim legen van de cache, en daarachter bevindt zich per site een Redis-objectcache. Het toevoegen van een tweede plugin voor volledige paginacaching werkt de cache op serverniveau doorgaans eerder tegen dan dat het helpt, waardoor dit noch nodig noch aanbevolen is.
Welke plug-ins maakt het platform overbodig?
Cachingplug-ins, afzonderlijke object-cacheplug-ins en back-upplug-ins zijn hier allemaal overbodig, omdat die taken onder WordPress worden uitgevoerd — caching op serverniveau, een beheerde object-cache per site en platformback-ups. Door ze te verwijderen, vermindert u conflicten en het aanvalsoppervlak. Wat de moeite waard blijft om te draaien, zijn de plug-ins die uw site daadwerkelijk nodig heeft voor zijn werking, plus onze twee gratis cache- en footprintplug-ins, die vooraf geïnstalleerd worden geleverd.
Verbreekt caching mijn WooCommerce-winkelwagen of pagina's voor ingelogde gebruikers?
Nee. Winkelwagen, afrekenen, mijn-account en eventuele nonce- of sessiepagina's zijn standaard uitgesloten van de cache, en Edge Side Includes houden het winkelwagenfragment en de totalen actueel op pagina's die verder gecachet zijn. Klanten zien altijd hun eigen winkelmandje en een werkende kassa terwijl de storefront nog steeds vanuit de cache laadt, en slimme automatische opschoning wist de getroffen pagina's wanneer een product, prijs of bestelling verandert.
Hoe houdt u WordPress veilig zonder dat ik het hoef te beheren?
Wij patchen de stack onder WordPress, zorgen dat core- en plugin-updates veilig kunnen worden toegepast met staging en herstel met één klik, schakelen malwarescans en DDoS-bescherming standaard in, isoleren elke site zodat een beveiligingslek zich niet kan verspreiden, en verstrekken en vernieuwen TLS-certificaten automatisch. Daarmee is de infrastructuur niet langer de zwakke schakel; basishygiëne zoals sterke inloggegevens en het verwijderen van ongebruikte plugins blijft uw verantwoordelijkheid.
Gerelateerd
Probeer het 14 dagen gratis
Start uw eerste sites 14 dagen gratis — geen creditcard vereist. Verhuist u een bestaande site of netwerk? Migraties zijn gratis, zonder limiet.
Gratis starten