WordPress Hosting & Plugins
WordPress snel en veilig maken: Een checklist voor prestaties en plug-ins
WordPress is altijd slechts zo snel en veilig als wat erop draait. Dit is de praktische checklist die we toepassen op elke WordPress-site die we hosten: wat u moet cachen, wat u moet beveiligen, en welke plugins hun plek verdienen in vergelijking met degene die het platform overbodig maakt.
WordPress is zo goed als wat erop draait
WordPress drijft een groot deel van het web aan omdat het flexibel is, maar die flexibiliteit is tevens de reden dat het traag en onveilig wordt: een standaardinstallatie raadpleegt de database tientallen keren per pagina, zendt zijn versie en stack uit naar iedereen die kijkt, en nodigt je uit om plugins te stapelen totdat de prestaties en het aanvalsoppervlak stilletjes de pan uit swingen. Dat is minder een fout in WordPress dan wel een gevolg van het draaien op infrastructuur die daar niets aan probeert te doen.
Het goede nieuws is dat dezelfde handvol beslissingen het meeste hiervan oplost, en dat het beslissingen over de stack zijn in plaats van over de inhoud. Cachel agressief op de juiste laag, houd de database buiten het kritieke pad, draai de weinige plugins die hun plek echt verdienen, houd alles gepatcht en isoleer de site zodat een probleem beheersbaar blijft. Dit bericht is die checklist, in de volgorde waarin we deze toepassen op elke WordPress site op het platform.
Cache op de server, niet alleen in een plugin
De grootste enkele hefboom voor WordPress-snelheid is om WordPress bij de meeste bezoeken helemaal niet uit te voeren. Een standaardverzoek start WordPress, voert je plug-ins uit en raadpleegt de database voordat er ook maar één byte wordt verzonden; een full-page cache levert de kant-en-klare pagina bij een volgend bezoek direct vanuit de webserver, waarbij dat hele opstartproces wordt overgeslagen. Waar die cache zich bevindt is belangrijk: een caching-plug-in bevindt zich binnen PHP, waardoor PHP nog steeds opstart voordat de cache kan reageren, terwijl een cache op serverniveau al eerder in het verzoek reageert en pagina's bewaart in een vorm die de server direct kan doorsturen.
Elke WordPress-site die we host draait op LiteSpeed Enterprise met server-level LSCache, en onze eigen cache plugin koppelt WordPress hier direct goed aan uit de doos — vooraf geïnstalleerd en automatisch bijgewerkt, dus dat is weer één ding minder om te configureren of up-to-date te houden. Op een niet-LiteSpeed-bron stuurt dezelfde plugin eenvoudigweg geen full-page headers uit en blijft deze op de achtergrond terwijl de object cache blijft werken, zodat een gemigreerde site nooit half geconfigureerd achterblijft. De praktische regel voor je eigen checklist: één full-page cache, op de server, en stapel er geen tweede caching plugin bovenop — die gaan concurreren.
De object-cache en de database
Niet elk verzoek kan een statische pagina zijn. Ingelogde sessies, de beheeromgeving, zoekopdrachten, winkelwagens en elk gepersonaliseerd fragment moeten PHP uitvoeren, en daar 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 databaselezingen in het geheugen, zodat dezelfde opties, transients en lookups niet bij elke hit opnieuw worden opgevraagd bij de database. Dit effect is precies daar merkbaar waar volledige-paginacache niet kan helpen: een snellere beheeromgeving, snellere winkelwagens en een aanzienlijk lagere databasebelasting bij veel verkeer.
Het cruciale woord is per-site. Een gedeelde object-cache betekent dat één drukke of slecht geschreven site de gecachete gegevens van al de anderen kan wissen en de database kan laten verhongeren voor zijn buren; een toegewijde per-site cache, gecombineerd met per-site databaselimieten, houdt die trefkracht ingeperkt. Beschouw een persistente object-cache op uw checklist als onmisbaar voor elke site met ingelogde gebruikers of een webshop, en wees op je hoede voor hosting waarbij deze over huurders wordt gedeeld.
De plugins die de moeite waard zijn — en degene die het platform vervangt
Elke plug-in die je toevoekt, is code die wordt uitgevoerd bij aanvragen en een deur waar iemand op een dag doorheen zou kunnen lopen, dus het eerlijke doel is het minste aantal plug-ins dat het meeste doet. Een goede host heft de noodzaak van een hele categorie daarvan op: met caching op serverniveau, een managed object cache en platformback-ups heb je geen caching-plug-in, een aparte object-cache-plug-in of een back-upplug-in nodig — die taken worden beter uitgevoerd onder WordPress, en ze erbovenop draaien zorgt alleen maar voor conflicten en overhead.
Wat er nog de moeite waard is om te gebruiken, is de kleine selectie die daadwerkelijk waarde toevoegt: de plugins die je site nodig heeft om te functioneren, en — op ons platform — de twee plugins van repository-kwaliteit die we bouwen en meeleveren met elke site. Onze cache-plugin verbindt WordPress met de servercache en zorgt voor slim wissen, zodat een aanpassing alleen de pagina's wist die dat moeten zijn. Onze footprint-plugin verwijdert bij elke implementatie de kenmerken die een standaard WordPress-installatie uitzendt — de versie- en generator-tag, discovery-endpoints, XML-RPC, pingbacks en de powered-by-header — zodat een update van een plugin of thema deze niet stilletjes terug kan zetten. Beide zijn gebouwd volgens de standaarden van de WordPress.org plugin-directory, zijn gratis en updaten zichzelf.
WordPress veilig en up-to-date houden
De meeste compromitteringen van WordPress zijn niet slim; ze zijn oud. Een verouderde core, thema of plugin met een bekende, gepubliceerde kwetsbaarheid is de overstelpende meerderheid van de manier waarop sites worden getroffen, wat up-to-date blijven het meest waardevolle beveiligingswerk maakt dat er is — en het meest eentonige, en daarom wordt het overgeslagen. Managed hosting zou dit van uw bord moeten nemen: het patchen van de stack onder WordPress, en het veilig maken van core- en plugin-updates door u een staging-kopie te geven om ze op te testen en een back-up om naar terug te keren.
Los van geld moet je erop rekenen dat de grenzen voor je worden bewaakt: standaard ingeschakelde malware-scanning zodat een infectie wordt onderschept in plaats van ontdekt door een bezoeker, isolatie zodat een gehackte site geen andere kan bereiken, DDoS-bescherming aan de rand, en overal TLS met automatisch vernieuwde certificaten. Dat vervangt allemaal geen basisdiscipline — sterke inloggegevens, least-privilege-toegang, het verwijderen van plugins die je niet meer gebruikt — maar het betekent wel dat de infrastructuur niet de zwakke schakel is. Op je checklist is de vraag voor elke host eenvoudig: is beveiliging de standaard, of een pakket dat je moet kopen?
WooCommerce en de pagina's die je nooit mag cachen
Een webshop is de plek waar agressieve caching zijn grootste overwinning boekt en de meeste schade aanricht als deze naïef wordt toegepast. De catalogus-, product- en categoriepagina's zijn de best bezochte en meest cachebare pagina's die je hebt, en deze vanuit een full-page cache serveren is het allerbeste wat je kunt doen voor de snelheid van een webshop. Maar winkelmand-, afrek- en accountpagina's zijn persoonlijk en mogen nooit vanuit een gedeelde cache worden geserveerd — als je dat doet, ziet een shopper het mandje van iemand anders, wat zowel een kapotte webshop als een privacyschending is.
De manier om allebei te bereiken is door de pagina te cachen en gaten te maken voor de live onderdelen. Edge Side Includes renderen het winkelwagenfragment, de subtotalen van de mini-winkelwagen en de accountstatus per aanvraag terwijl de rest van de pagina vanuit de cache wordt geserveerd, en de winkelwagen, het afrekenen, mijn-account en eventuele nonce- of sessiepagina's worden standaard uitgesloten. Versheid wordt geregeld door slimme automatische opschoning die wordt geactiveerd wanneer een product, prijs of bestelling wijzigt, zodat een verouderde prijs nooit blijft hangen. Als je WooCommerce gebruikt, is dit het deel van de checklist dat je precies goed moet hebben: snelle winkelpuin vanuit de cache, live winkelwagen per gebruiker, er wordt nooit iets persoonlijks gecached.
Veelgestelde vragen
Heb ik nog steeds een caching-plugin zoals WP Rocket nodig?
Nee. Volledige-pagina-caching wordt op de webserver afgehandeld door de LSCache van LiteSpeed, onze eigen cache-plugin koppelt WordPress eraan en beheert het slim legen van de cache, en een Redis-objectcache per site bevindt zich daaraan ten grondslag. Het toevoegen van een tweede volledige-pagina-caching-plugin daarbovenop werkt doorgaans juist tegen de cache op serverniveau in in plaats de te helpen, dus dat is noch nodig noch aanbevolen.
Welke plugins maakt het platform overbodig?
Caching-plugins, aparte object-cache-plugins en back-plugin zijn hier allemaal overbodig, omdat die taken onder WordPress worden uitgevoerd — server-level caching, een beheerde per-site object cache en platformback-ups. Het verwijderen daarvan vermindert conflicten en het aanvalsoppervlak. Wat de moeite waard is om te laten draaien, zijn de plugins die je site daadwerkelijk nodig heeft voor zijn werking, plus onze twee gratis cache- en footprint-plugins, die vooraf geïnstalleerd worden geleverd.
Zorgt caching ervoor dat mijn WooCommerce winkelmandje of ingelogde pagina's niet meer werken?
Nee. Winkelwagen, checkout, mijn-account en eventuele nonces of sessiepagina's worden standaard uitgesloten van de cache, en Edge Side Includes houden het winkelwagenfragment en de totalen actief op overigens gecachete pagina's. Shoppers zien altijd hun eigen winkelmandje en een werkende checkout terwijl de winkelpuist toch vanuit de cache laadt, en slimme automatische opschoning wist getroffen pagina's wanneer een product, prijs of bestelling wijzigt.
Hoe houd je WordPress veilig zonder dat ik het hoef te beheren?
We patchen de stack onder WordPress, maken kern- en plugin-updates veilig toe te passen met staging en herstellen met één klik, voeren standaard malwarescanning en DDoS-beveiliging uit, isoleren elke site zodat een hack zich niet kan verspreiden, en geven automatisch TLS-certificaten uit en vernieuwen deze. Dat haalt de infrastructuur weg als zwakke schakel; basisbeveiliging zoals sterke inloggegevens en het verwijderen van ongebruikte plugins is nog steeds uw eigen verantwoordelijkheid.
Gerelateerd
Probeer het 14 dagen gratis
Lanceer je eerste websites gratis gedurende 14 dagen — geen creditcard vereist. Verhuis je een bestaande site of netwerk? Je eerste migratie is op ons.
Start gratis