Hosting en prestaties
Hoe we WordPress snel maken: LiteSpeed Enterprise, LSCache en Redis per site
Het snelste WordPress-verzoek is het verzoek dat nooit wordt uitgevoerd — ontdek hoe onze stack de meeste bezoeken vanuit de cache beantwoordt voordat PHP of MySQL ooit 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 de taak over aan PHP, PHP start WordPress op, voert de plug-ins uit, voert enkele tientallen queries uit op MySQL, stelt HTML samen en stuurt pas daarna bytes terug. Op een drukke site gebeurt die hele cyclus voor elke bezoeker, en dat is waar bijna al uw time-to-first-byte naartoe gaat.
Ons antwoord is ervoor te zorgen dat dit bij de meeste bezoeken helemaal niet gebeurt. Op alle sites die we hosten — meer dan 100.000 PBN-sites plus reguliere beheerde WordPress — wordt de overgrote meerderheid van de front-end paginaweergaven als een vooraf gerenderde volledige pagina rechtstreeks vanuit de cache geserveerd, zonder PHP aan te roepen of de database te raadplegen. De rest van dit bericht gaat over hoe de lagen die dat mogelijk maken op elkaar aansluiten, en waar elk van deze lagen zijn waarde bewijst.
Het cruciale uitgangspunt is dat dit geen met elkaar concurrerende caches zijn waaruit u moet kiezen. Full-page cache, objectcache en de CDN-edge vangen elk een ander type verzoek op, en de werkelijke waarde zit in de manier waarop ze het werk aan elkaar overdragen.
LiteSpeed Enterprise + LSCache: de volledige-paginalaag
Elke site draait op LiteSpeed Enterprise met LSCache op serverniveau. Wanneer een front-endreactie kan worden gecachet, markeert de webserver deze met LiteSpeed-cache-control- en tag-headers, en levert LiteSpeed de volledige pagina direct bij het volgende bezoek — er wordt geen PHP-proces gestart en geen MySQL-query uitgevoerd. Dat is de grootste hefboom voor de TTFB van WordPress, omdat het de volledige opstart van de applicatie uit het kritieke pad verwijdert.
Omdat LSCache zich binnen de webserver bevindt in plaats van in een PHP-plug-in, begint het vroeger in de levenscyclus van het verzoek te werken en bewaart het pagina's in een vorm die de server direct kan leegmaken. Een cache-crawler houdt populaire pagina's warm, zodat de eerste bezoeker na een opschoning niet degene is die betaalt voor het opnieuw genereren van de pagina. Het resultaat is een aanzienlijk lagere en consistentere TTFB dan bij een cache die uitsluitend via een plug-in op een generieke stack is geplaatst, waarbij de cache zich nog steeds achter PHP bevindt.
Onze eigen repo-grade cache-plug-in wordt vooraf geïnstalleerd en automatisch bijgewerkt op elke site geleverd, waardoor WordPress direct op de juiste manier met LSCache wordt verbonden. Op een niet-LiteSpeed-origin verzendt deze eenvoudigweg geen headers voor volledige pagina's en treedt hij 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 leveren: ESI en slim automatisch opschonen
Agressieve caching van volledige pagina's kent twee klassieke foutmodi: een ingelogde gebruiker de pagina van iemand anders tonen, en iemand een pagina tonen die gewijzigd had moeten zijn. Beide worden opgelost op de cachinglaag in plaats van door minder te cachen.
Met ESI (Edge Side Includes) kunnen we de pagina cachen terwijl er gaten worden gemaakt voor de onderdelen die live moeten blijven. Op een WooCommerce-winkel worden de catalogus-, product- en categoriepagina's geleverd als volledige-paginacache voor de snelst mogelijke TTFB, terwijl ESI het winkelwagenfragment, de minitotalen van de winkelwagen en de accountstatus per verzoek rendert. Winkelwagen-, afreken-, mijn account- en eventuele nonce- of sessiepagina's zijn standaard uitgesloten. Shoppers zien altijd hun eigen winkelmandje en een werkende kassa; iedereen krijgt de storefront nog steeds uit de cache.
Versheid wordt geregeld door slimme automatische opschoning. Opschoningshooks worden automatisch geactiveerd wanneer inhoud, producten, prijzen of bestellingen wijzigen, zodat de relevante gecachte pagina's direct worden vernieuwd in plaats van op basis van een timer, en u kunt ook op verzoek opschonen via het dashboard of vanuit WordPress. Opschonen op basis van tags houdt in dat het bewerken van één bericht alleen dat bericht en de bijbehorende archieven wist — niet de volledige cache — zodat een enkele bewerking niet de hele site een 'cold start' bezorgt.
Redis-objectcache per site: voor wat geen volledige pagina kan zijn
Niet elk verzoek kan een statische volledige pagina zijn. Aangemelde sessies, het WordPress-beheer, WooCommerce-winkelwagens, zoekopdrachten en de dynamische fragmenten die ESI live laat, moeten allemaal PHP uitvoeren. Voor deze verschuift het doel van 'de applicatie overslaan' naar 'de database overslaan'.
Elke site krijgt een eigen dedicated Redis-objectcache. WordPress slaat de resultaten van herhaalde databaseleesbewerkingen — opties, transients, zoekacties naar berichten en termen, WooCommerce-product- en sessiegegevens — op in het geheugen, zodat niet bij elk bezoek dezelfde query op MySQL wordt uitgevoerd. Het effect is het best zichtbaar op de plekken waar een volledige paginacache geen uitkomst biedt: snellere dashboards, snellere winkelwagens en een aanzienlijk lagere databasebelasting bij veel verkeer.
De objectcache is per site en wordt niet gedeeld, wat van belang 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 naburige sites. U kunt meer lezen over hoe de complete meerlaagse configuratie in elkaar past op onze pagina over cachingfuncties, en over de grenzen tussen tenants onder isolatie.
De edge en het onderliggende transport
Cache die zich op de origin bevindt, moet nog steeds het netwerk oversteken. Vóór de server bevindt zich de CDN-edge, zodat statische bestanden en cachebare pagina's worden geleverd vanaf een aanwezigheidspunt dicht bij de bezoeker, en de origin zelfs onder zware belasting rustig blijft. Voor onze footprint-vrije hostinglijn is diezelfde edge een multi-CDN-pool verdeeld over meerdere providers, wat zowel een footprint-doel als een prestatiedoel dient; op mainstream WordPress is het simpelweg een snelle, goed functionerende laag die origins ontlast.
Onder de motorkap is er niet bezuinigd op de fundamenten. Websites draaien op NVMe-opslag met HTTP/3, waardoor de bytes die de cache verstuurt aankomen via een modern, gemultiplexed transport met snelle opslag achter elke cache miss. Geen van deze lagen is een add-on: LiteSpeed, LSCache, Redis per site, NVMe en HTTP/3 vormen de basis op elk pakket, en zijn geen duurdere upgrade.
Wat Core Web Vitals echt verbetert
Het is de moeite waard om nauwkeurig te zijn, omdat hosting vaak te rooskleurig wordt voorgesteld wat betreft Core Web Vitals. TTFB is het deel van de vergelijking dat de server beheert, en de bovenstaande caching-stack zorgt voor de verlaging ervan — een gecachte volledige pagina die via HTTP/3 vanaf de edge wordt geleverd, is zo'n beetje de laagste TTFB die haalbaar is. Omdat TTFB de voorhoede vormt van Largest Contentful Paint, geeft een snelle origin elke downstream-metriek een voorsprong die anders niet mogelijk zou zijn.
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, een lay-out die verschuift terwijl lettertypen en advertenties laden, en zwaar werk op de main-thread door plug-ins. Geen enkele hoeveelheid servercaching lost een hero-afbeelding van 2 MB op of een thema dat megabytes aan JavaScript levert. Eerlijke hosting maakt de bijdrage van de server effectief kosteloos en consistent, waarna het aan de site is om de front-end gestroomlijnd te houden.
Die taakverdeling is het nuttige denkmodel. Wij garanderen dat het verzoek de browser snel bereikt en snel blijft onder druk van verkeer; u zorgt dat de payload klein en stabiel blijft. Waar die twee samenkomen — cache warm-up, edge delivery 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 op een generieke host.
Veelgestelde vragen
Heb ik nog steeds een caching-plugin zoals WP Rocket nodig?
Nee. Caching van de volledige pagina wordt op de webserver afgehandeld door LSCache van LiteSpeed, en onze eigen cacheplug-in — vooraf geïnstalleerd en automatisch bijgewerkt — koppelt WordPress hier correct aan, met een Redis-objectcache per site erachter. Het toevoegen van een tweede plug-in voor paginacaching werkt de servercache doorgaans eerder tegen dan dat het helpt, dus het is niet nodig en wordt afgeraden.
Verbreekt caching mijn WooCommerce-winkelwagen of pagina's voor ingelogde gebruikers?
Nee. Cart-, checkout-, my-account- en eventuele nonce- of session-pagina's zijn standaard uitgesloten van caching, en ESI houdt het winkelwagenfragment en de totalen actueel op pagina's die verder wel gecachet zijn. Klanten zien altijd hun eigen winkelmandje en een werkend afrekenproces, terwijl de etalage nog steeds vanuit de cache wordt geladen.
Hoe blijft de cache up-to-date wanneer ik publiceer of bewerk?
Slimme automatische opschoning wordt geactiveerd op de relevante WordPress-hooks, zodat bij het publiceren, bewerken van inhoud of het wijzigen van een product, prijs of bestelling alleen de getroffen pagina's en hun archieven worden gewist — niet de hele cache — waarna een crawler ze opnieuw opwarmt. U kunt ook op aanvraag opschonen via het dashboard of vanuit WordPress.
Kan hosting alleen mij perfecte Core Web Vitals opleveren?
Het biedt u de best mogelijke TTFB, wat het aandeel van de server is en een voorsprong geeft voor Largest Contentful Paint. Maar LCP, CLS en INP worden grotendeels bepaald door de pagina zelf — afbeeldingsformaten, render-blokkerende bronnen, lay-outstabiliteit en JavaScript op de hoofdthread. Onze stack maakt de bijdrage van de server snel en consistent; het slank houden van de front-end payload overbrugt de rest van het verschil.
Gerelateerd
Probeer het 14 dagen gratis
Lanceer uw eerste sites 14 dagen gratis — geen creditcard nodig. Een bestaand netwerk verhuizen? Migraties zijn gratis, zonder limiet.
Gratis starten