Een website die snel aanvoelt, begint lang voordat de eerste afbeelding in beeld verschijnt. De webserver moet een verzoek herkennen, PHP uitvoeren, gegevens uit de database ophalen, een pagina samenstellen en die efficiënt naar de bezoeker sturen. Als iedere stap vertraging toevoegt, kunt u aan de voorkant nog zoveel optimaliseren: de basis blijft langzaam. Daarom gebruiken wij bij Gigatech LiteSpeed Enterprise als webserver en bouwen we daar een complete caching- en beveiligingslaag omheen.
LiteSpeed is geen magische snelheidsknop en ook geen vervanging voor een goed gebouwde website. Het is wel een bijzonder sterke basis. De webserver, de LiteSpeed Cache-plugin voor WordPress, Redis-objectcaching, HTTP/3 en serverbrede beveiliging kunnen rechtstreeks samenwerken. Daardoor hoeven minder verzoeken helemaal door WordPress en de database te worden verwerkt.
TTFB: het moment waarop snelheid begint
Time to First Byte, meestal afgekort tot TTFB, is de tijd tussen het verzoek van de browser en het eerste antwoord van de server. Het is niet hetzelfde als de volledige laadtijd, maar een hoge TTFB werkt wel door in alles wat daarna komt. De browser kan immers pas verder zodra de server reageert.
Een dynamische WordPress-pagina kan bij ieder bezoek opnieuw PHP-code uitvoeren en meerdere databasequery’s doen. Met een geldige full-page cache kan LiteSpeed een eerder opgebouwd resultaat direct aanbieden. De route wordt dan veel korter: verzoek, cachecontrole, antwoord. Dat scheelt rekenwerk, databasebelasting en wachttijd. Vooral bij drukte is dat verschil belangrijk, omdat gecachete pagina’s veel minder servercapaciteit vragen.
De browser vraagt een pagina op.
LiteSpeed controleert of een actuele kopie beschikbaar is.
Bij een hit zijn PHP en veel databasewerk niet nodig.
De browser kan eerder gaan renderen.
LSCache werkt dichter bij de webserver
Er bestaan veel WordPress-cacheplugins. Het onderscheid van LiteSpeed Cache is dat de plugin kan communiceren met de cache-engine in LiteSpeed Web Server. De plugin begrijpt WordPress: hij kan een cache legen wanneer een bericht verandert, aparte varianten voor ingelogde gebruikers beheren en onderdelen uitsluiten die echt dynamisch moeten blijven. De server kan vervolgens de opgeslagen pagina leveren zonder WordPress volledig op te starten.
Dat is vooral nuttig voor webshops en sites met veel content. Een winkelmandje, persoonlijke accountpagina of recente voorraadstatus mag niet als algemene kopie aan iedereen worden getoond. Caching moet daarom slim worden geconfigureerd. Wij kiezen liever voor correct en voorspelbaar dan voor een agressieve instelling die op papier snel lijkt maar functionele problemen veroorzaakt.
Redis: een andere laag voor een ander probleem
Full-page caching en objectcaching worden vaak door elkaar gehaald. Een page cache bewaart een compleet antwoord. Redis kan veelgebruikte WordPress-objecten en resultaten tijdelijk in het snelle geheugen bewaren. Bij een bezoek dat niet uit de page cache kan komen, hoeft WordPress daardoor minder vaak dezelfde informatie opnieuw uit de database te berekenen of op te vragen.
Redis maakt een slecht databasemodel niet vanzelf goed. Het helpt vooral bij herhaald leeswerk, zoals instellingen, menu’s en veelgebruikte queryresultaten. Daarom bieden we Redis-support op pakketten waar de workload er daadwerkelijk voordeel van heeft. De combinatie is logisch: LiteSpeed voorkomt zoveel mogelijk volledige WordPress-runs, Redis versnelt het werk dat overblijft.
HTTP/3 en moderne verbindingen
LiteSpeed ondersteunt HTTP/3 over QUIC. Bij oudere TCP-verbindingen kan het verlies van één pakket andere gegevensstromen tijdelijk tegenhouden. QUIC verwerkt stromen onafhankelijker en kan bij wisselende mobiele netwerken efficiënter omgaan met de verbinding. Dat betekent niet dat iedere pagina plotseling twee keer zo snel wordt, maar het vermindert onnodige vertraging en maakt de overdracht robuuster, vooral op mobiele of minder stabiele verbindingen.
Bad bots stoppen vóór ze WordPress uitputten
Een groot deel van internetverkeer bestaat niet uit echte bezoekers. Bots proberen inloggegevens, vragen grote aantallen URL’s op of sturen misbruikverzoeken naar bekende WordPress-doelen zoals wp-login.php en xmlrpc.php. Zelfs een mislukte aanval kan CPU, PHP-processen en databasecapaciteit verbruiken.
LiteSpeed Enterprise heeft ingebouwde WordPress-bruteforcebescherming en kan aanvallend verkeer vertragen, weigeren of een challenge tonen. Bij Gigatech staat dit niet op zichzelf. Imunify360 voegt firewallregels, reputatiegegevens, malwaredetectie, Proactive Defense en anti-botmaatregelen toe. CloudLinux beperkt bovendien hoeveel middelen één hostingaccount kan opeisen. Het doel is tweeledig: aanvallen blokkeren én voorkomen dat slecht verkeer naar één website de rest van het platform beïnvloedt.
Waarom hardware nog steeds telt
Software kan wachten verminderen, maar kan geen trage opslag, te weinig geheugen of een overvolle server wegtoveren. Snelle CPU-kernen helpen bij PHP, voldoende RAM ondersteunt caches en processen, en snelle SSD-opslag verkort database- en bestandsacties. Wij combineren LiteSpeed daarom met enterprisehardware, gecontroleerde accountlimieten en actieve monitoring. Caching is een vermenigvuldiger van een goede infrastructuur, geen excuus om op infrastructuur te besparen.
Wat u zelf kunt doen
- Gebruik één goed ingestelde cacheoplossing en voorkom overlappende plugins.
- Optimaliseer grote afbeeldingen en laad niet-kritische media vertraagd.
- Beperk zware plugins en controleer trage databasequery’s.
- Test na wijzigingen zowel als bezoeker als ingelogde beheerder.
- Meet TTFB en Core Web Vitals op meerdere pagina’s en momenten.
Wilt u een WordPress-site die niet alleen in een snelheidstest goed scoort, maar ook tijdens echte drukte stabiel blijft? Bekijk onze WordPress-hosting en hostingpakketten, of neem contact op via Support.
