Hosting en prestaties
Hoe we WordPress snel maken: LiteSpeed Enterprise, LSCache en per-site Redis
Het snelste WordPress-verzoek is het verzoek dat nooit wordt uitgevoerd — dit is hoe onze stack de meeste bezoeken vanuit de cache afhandelt voordat PHP of MySQL überhaupt wordt aangeroepen, en wat dat betekent voor Core Web Vitals.
Het snelste verzoek is het verzoek dat nooit wordt uitgevoerd
Een standaard WordPress-verzoek is kostbaar. De webserver draagt het over aan PHP, PHP start WordPress op, voert de plugins uit, raadpleegt MySQL een paar tiental keren, stelt HTML samen en stuurt pas dan bytes terug. Op een drukke site vindt die hele dans plaats voor elke bezoeker, en daar gaat bijna al uw time-to-first-byte naartoe.
Ons antwoord is ervoor zorgen dat dit voor de meeste bezoeken helemaal niet gebeurt. Op de sites die we hosten — meer dan 100.000 PBN-sites plus reguliere managed WordPress — wordt de grote meerderheid van de front-end paginaweergaven geleverd als een vooraf gerenderde volledige pagina rechtstreeks vanuit de cache, zonder PHP aan te roepen of de database te raken. De rest van dit bericht gaat over hoe de lagen die dat mogelijk maken op elkaar aansluiten en waar elke laag zijn waarde verdient.
Het belangrijke uitgangspunt is dat dit geen concurrerende caches zijn waar je tussen kiest. Full-page cache, object cache en de CDN-edge vangen elk een andere klasse aan verzoeken op, en de waarde zit in de manier waarop ze elkaar opvolgen.
LiteSpeed Enterprise + LSCache: de full-page laag
Elke site draait op LiteSpeed Enterprise met server-level LSCache. Wanneer een front-end response cachebaar is, voorziet de webserver deze van LiteSpeed cache-control- en tagheaders, en levert LiteSpeed de volledige pagina direct bij de volgende hit — er wordt geen PHP-proces gestart en er wordt geen MySQL-query uitgevoerd. Dat is de allerbelangrijkste factor voor WordPress TTFB, omdat het de volledige applicatie-opstart verwijdert uit het kritieke pad.
Omdat LSCache zich binnen de webserver bevindt in plaats van in een PHP-plug-in, werkt het al eerder in de aanvraagcyclus en bewaart het pagina's in een vorm die de server direct kan doorsturen. Een cache-crawler houdt populaire pagina's warm, zodat de eerste bezoeker na een opschoning niet degene is die betaalt om de pagina opnieuw te genereren. Het resultaat is een aanzienlijk lagere en consistentere TTFB dan een cache op basis van alleen een plug-in die is toegevoegd aan een generieke stack, waarbij de cache zich nog steeds achter PHP bevindt.
Onze eigen repo-grade cache-plugin wordt vooraf geïnstalleerd en automatisch geüpdatet op elke site, waardoor WordPress direct correct wordt gekoppeld aan LSCache. Op een niet-LiteSpeed-bron worden eenvoudigweg geen headers voor volledige pagina's verzonden en blijft de plugin op de achtergrond, terwijl de objectcache en uitsluitingsregels hun werk blijven doen — zodat een gemigreerde site nooit in een kapotte, half geconfigureerde staat achterblijft.
Snel blijven zonder verouderde content te serveren: ESI en slimme auto-purge
Aggressive full-page caching kent twee klassieke faalmodi: het tonen van de pagina van iemand anders aan een ingelogde gebruiker, en het tonen van een pagina die had moeten veranderen aan wie dan ook. Beide worden opgelost in de cachinglaag in plaats de hoeveelheid cache te verminderen.
ESI (Edge Side Includes) stelt ons in staat om de pagina te cachen en tegelijkertijd open gaten te laten voor onderdelen die live moeten blijven. Op een WooCommerce winkel worden de catalogus-, product- en categoriepagina's geserveerd als volledige paginacache voor de snelst mogelijke TTFB, terwijl ESI het winkelwagenfragment, de totalen van de mini-winkelwagen en de accountstatus per aanvraag weergeeft. Winkelwagen, afrekenen, mijn-account en alle nonce- of sessiepagina's worden standaard uitgesloten. Shoppers zien altijd hun eigen winkelmandje en een werkende checkout; iedereen krijgt de winkelvloer nog steeds vanuit de cache.
Versheid wordt beheerd door slimme auto-purge. Purge-hooks worden automatisch geactiveerd wanneer inhoud, producten, prijzen of bestellingen wijzigen, zodat de relevante gecachete pagina's direct worden vernieuwd in plaats van op een timer, en u kunt ook handmatig purgen vanuit het dashboard of vanuit WordPress. Dankzij tag-based purging worden bij het bewerken van één bericht dat bericht en bijbehorende archieven gewist — en niet de hele cache — zodat een enkele bewerking niet de hele site hoeft te herstarten.
Per-site Redis object cache: voor wat geen volledige pagina kan zijn
Niet elk verzoek kan een statische volledige pagina zijn. Ingelogde sessies, de WordPress-beheeromgeving, WooCommerce-winkelwagens, zoekopdrachten en de dynamische fragmenten die ESI achterlaat, moeten allemaal PHP draaien. Voor die onderdelen verschuift het doel van 'de applicatie overslaan' naar 'de database overslaan'.
Elke site krijgt zijn eigen toegewezen Redis object cache. WordPress caches the results of repeated database reads — options, transients, post and term lookups, WooCommerce product and session data — in memory, zodat dezelfde query niet bij elke hit wordt uitgevoerd op MySQL. Het effect is het meest merkbaar precies waar full-page caching niet kan helpen: snellere dashboards, snellere winkelwagens en een aanzienlijk lagere databaseload onder verkeer.
De object cache is per site en wordt niet gedeeld, wat belangrijk is voor zowel prestaties als isolatie. In combinatie met databasethrottling per site kunnen zware of slecht geschreven query's van één site de database niet uitputten voor de omliggende sites. Meer informatie over hoe de hele meertrapsopstelling in elkaar zit, leest u op onze pagina met caching-functies, en over de grenzen tussen tenants onder isolatie leest u bij isolatie.
De edge en het onderliggende transport
Cache die op de origin blijft, moet nog steeds het netwerk over. Vóór de server bevindt zich de CDN-edge, waardoor statische assets en cachebare pagina's worden geserveerd vanaf een point of presence dicht bij de bezoeker, en de origin rustig blijft, zelfs onder belasting. Voor onze footprint-free hostinglijn is dezelfde edge een multi-CDN-pool verspreid over verschillende providers, die zowel een footprint-doel als een prestatiedoel dient; op mainstream WordPress is het simpelweg een snelle, welwillende laag die origins inactief houdt.
Onder de motorkap wordt er niet bezuinigd op de fundamenten. Websites draaien op NVMe opslag met HTTP/3, zodat de bytes die de cache wel verzendt, arriveren via een modern, gemultiplexeerd transport met snelle opslag achter elke cache-miss. Geen van deze lagen is een add-on: LiteSpeed, LSCache, per-site Redis, NVMe en HTTP/3 vormen de basis bij elk abonnement, en zijn geen betaalde upgrade.
Wat Core Web Vitals daadwerkelijk beïnvloedt
Het loont de moeite om nauwkeurig te zijn, omdat hosting vaak wordt oververkocht op het gebied van Core Web Vitals. TTFB is het onderdeel van de vergelijking dat toebehoort aan de server, en de caching-stack erboven is wat dit omlaag brengt — een gekachte volledige pagina die via HTTP/3 vanaf de edge wordt geserveerd, is ongeveer zo laag als de TTFB kan zijn. Omdat TTFB het beginpunt is van Largest Contentful Paint, geeft een snelle origin elke downstream-metriek een voorsprong die deze anders niet kan hebben.
Maar LCP, CLS en INP worden grotendeels in de browser bepaald, door de pagina zelf: een niet-geoptimaliseerde hero-afbeelding, render-blokkerende CSS en JavaScript, layout die verschuift naarmate lettertypen en advertenties laden, en zwaar werk op de main-thread door plugins. Geen enkele hoeveelheid servercaching lost een hero van 2 MB of een thema dat megabytes aan JavaScript meestuurt op. Eerlijke hosting maakt de bijdrage van de server vrijwel gratis en consistent, waarna het aan de website is om de front-end slank te houden.
Die taakverdeling is het nuttige mentale model. Wij garanderen dat het verzoek de browser snel bereikt en snel blijft onder verkeer; jij houdt de payload klein en stabiel. Waar de twee elkaar ontmoeten — cache warm-up, edge-levering en het responsief houden van de database zodat dynamische pagina's niet vastlopen — is precies waar onze stack op is afgestemd, en dat is wat managed WordPress op dit platform sneller maakt dan dezelfde site bij een generieke host.
Veelgestelde vragen
Heb ik nog steeds een caching-plugin zoals WP Rocket nodig?
Nee. Full-page caching wordt op de webserver afgehandeld door LiteSpeed's LSCache, en onze eigen cache-plugin — vooraf geïnstalleerd en automatisch geüpdatet — koppelt WordPress hier correct aan, met een per-site Redis object cache erachter. Het toevoegen van een tweede full-page caching-plugin werkt doorgaans juist tegen de cache op serverniveau in plaats van dat het helpt, dus dit is niet nodig en niet aanbevolen.
Zorgt caching ervoor dat mijn WooCommerce winkelmandje of ingelogde pagina's niet meer werken?
Nee. Winkelwagen-, afreken-, mijn-account- en eventuele nonce- of sessiepagina's worden standaard uitgesloten van de cache, en ESI zorgt ervoor dat het winkelwagensubfragment en de totalen live blijven op overigens gecachete pagina's. Klanten zien altijd hun eigen winkelmandje en een werkende afrekenpagina terwijl de storefront nog steeds vanuit de cache wordt geladen.
Hoe blijft de cache up-to-date wanneer ik publiceer of bewerk?
Slimme auto-purge wordt geactiveerd bij relevante WordPress hooks, waardoor het publiceren, bewerken van content of het wijzigen van een product, prijs of bestelling alleen de getroffen pagina's en hun archieven wist — en niet de hele cache — waarna een crawler deze opnieuw opwarmt. Je kunt ook handmatig purgen vanuit het dashboard of vanuit WordPress.
Kan alleen hosting mij perfecte Core Web Vitals opleveren?
Het levert je de best mogelijke TTFB op, wat het aandeel van de server is en een voorsprong biedt voor Largest Contentful Paint. Maar LCP, CLS en INP worden grotendeels bepaald door de pagina zelf — afbeeldingsformaten, render-blokkerende assets, lay-outstabiliteit en JavaScript op de hoofdthread. Onze stack zorgt ervoor dat de bijdrage van de server snel en consistent is; het compact houden van de front-end payload dicht de rest van het gat.
Gerelateerd
14 dagen gratis proberen
Lanceer je eerste sites 14 dagen lang gratis — geen creditcard nodig. Verhuis je een bestaand netwerk? Je eerste migratie is op ons.
Start gratis