Caching modellen en jouw WordPress website

Stappen om jouw WordPress website te versnellen

De laatste maanden liep ik tegen de grenzen van de snelheid die er met mijn toenmalig VPS te bereiken was. Ik stond voor een keuze, op zoek naar een nieuwe caching plugin of het gewoon compleet en drastisch anders aanpakken? Ik heb voor het laatste gekozen en in dit artikel neem ik je graag mee op mijn ontdekkingstocht, Maar laten we het -voor het begrip- eerst eens over de verschillende caching modellen hebben, die met WordPress mogelijk zijn.

De scope bepalen

Nu is ‘caching’ een veel omvattend woord. Caching is een technologie die wordt gebruikt om resultaten van een proces tijdelijk op een sneller toegankelijke plaats op te slaan. Zo heeft je processor een cache, je harddisk of SSD heeft een cache… Maar dit is allemaal buiten de scope van dit artikel. In dit artikel beperk ik mij tot het cachen van gegevens die te maken hebben met het opbouwen van een webpagina. Die opgebouwde webpagina wordt daarna naar jou toegestuurd en komt ook weer in een cache, de browser cache. En ook deze cache valt buiten de scope van dit artikel. Ik heb als beheerder van een website immers weinig invloed op hoe jij jouw cache instelt.

Ik bespreek een aantal caching modellen. Dat wil niet zeggen, dat die caching modellen elkaar uitsluiten, in de praktijk zal er vaak gebruik gemaakt worden van verschillende caching modellen, die elkaar -indien goed geconfigureerd- versterken. Is het wat minder goed geconfigureerd kunnen ze elkaar danig in de weg zitten.

Wat doet een cache?

Ik heb al meer dan eens in verschillende artikelen uitgelegd wat een cache doet. Omdat het proces waarin een WordPress pagina wordt aangemaakt een traag proces is, zorgt een cache ervoor, dat nadat die pagina eenmaal is aangemaakt deze ‘nog even bewaard blijft’. Wil iemand binnen een bepaalde tijd diezelfde informatie nogmaals hebben, dan wordt deze niet opnieuw gemaakt, maar vanuit de cache getoond.

1. Een website zonder cache

De makkelijkste manier om je website te tonen is natuurlijk helemaal geen cache gebruiken. Het is ook de meest trage manier. Toch kan een website zonder enige vorm van caching in een aantal gevallen de beste oplossing zijn. Heb je een website met weinig bezoekers, dan is er zelfs een kans dat een cache je website vertraagt. Want dat hele proces van ‘een pagina opslaan nadat hij gemaakt is’ kost tijd. En wanneer je weinig bezoekers hebt, is er een grote kans, dat die ‘gegenereerde pagina’ al verstreken is, voor er een nieuwe bezoeker komt aan die pagina. Maar aangezien vrijwel niemand als doel heeft een website met weinig bezoek te hebben, helemaal al niet, wanneer het een zakelijke site is, gaan we er even vanuit, dat je vroeger of later toch een vorm van caching wilt gaan gebruiken.

2. Caching plugins

Het meest eenvoudige model van alle caching modellen is denk ik wel de ‘caching plugin’. Het mooie van de meeste caching plugins is dat ze meer doen dan alleen reeds gegenereerde pagina’s opnieuw aanbieden. Omdat een plugin letterlijk toegang heeft tot de diepste werking van WordPress, doet de gemiddelde caching plugin heel wat meer. Behalve het opslaan van gegenereerde pagina’s wordt meestal ook een aantal optimalisatieslagen voor het netwerk verkeer uitgevoerd. Hierbij kan je onder meer denken aan:

• Samenvoegen en comprimeren van CSS en JavaScript bestanden, waardoor deze in minder ‘requests’ en met minder webverkeer verzonden kunnen worden.
• JavaScript ‘uitgesteld’ laden.
• Ondersteuning bieden om resources (denk hierbij aan afbeeldingen, video etc) via een CDN te laden.
• Pagina’s ‘pre-loaden’ in de ‘idle’ tijd. Op het moment dat de website niets, of niet veel, te doen heeft, worden pagina’s ‘alvast’ geladen en gecached op de achtergrond. Dit gebeurt echter alleen wanneer je website bezoekers heeft. Meer informatie over achtergrondprocessen en WordPress lees je in mijn blogartikel over WP-Cron.

Kortom, de gemiddelde caching plugin voor WordPress doet heel wat meer dan caching alleen en kan je website aanzienlijk versnellen.

Omdat de meeste caching plugins ook ‘iets’ doen met .htaccess bestanden, heeft het gebruik van een caching plugin meestal alleen zin, wanneer je een Apache compatible webserver gebruikt (wanneer je een shared hosting pakket hebt, is dat altijd het geval). Gebruik je NGINX als webserver (en niet als ‘reversed proxy’, zie later), hebben de meeste caching plugins geen zin of meerwaarde. Sterker nog, het kan je site sterk vertragen.

3. Reverse proxies gebruiken

In de meeste ‘standaard web configuraties’ wordt gebruik gemaakt van Apache als webserver. In mijn artikel over VPS-en heb ik uitgelegd, hoe Apache (ongeveer) werkt:

• Jij begint een conversatie met Apache
• Apache stelt een vraag aan PHP en wacht op antwoord.
• Apache geeft het antwoord.
• En indien er nog een andere persoon komt, wordt een nieuw proces gestart.

Een reverse proxy is eigenlijk een tweede webserver, maar één die anders werkt. Een populaire reversed proxy is NGINX (Uitgesproken als Engine Ex). Hoeft een bestand niet ‘geïnterpreteerd’ te worden door de server (bijvoorbeeld afbeeldingen, javascript files, video, pdf bestanden etc), dan wordt de opdracht door Apache doorgeleid naar de reversed proxy, die op zijn beurt direct de bestanden doorstuurt. Hiermee wordt de Apache server bevrijdt van ‘lichte taken’, en hoeft alleen het zware werk nog maar te doen.

Wat behoorlijk in de tijd kan schelen, omdat in een WordPress pagina tientallen tot honderden ‘lichte taken’ uitgevoerd moeten worden.

4. Een CDN gebruiken

Een CDN is op een bepaalde manier te vergelijken met een ‘reversed proxy’, maar op andere fronten is het een compleet andere oplossing. En een CDN en een ‘reversed proxy’ zijn naast elkaar te gebruiken.

Alweer een tijdje geleden heb ik een vrij uitgebreid artikel over CDN’s geschreven.

Een CDN -ofwel een Content Distribution Network- is een cloud oplossing, waarbij jouw content wordt geupload naar een netwerk van computers in de cloud over de hele wereld. Vraagt iemand in Australië of Argentinie een afbeelding op, dan reist die afbeelding niet van jouw server in Nederland over de hele wereld, maar krijgt de bezoeker de afbeelding te zien die op een server in het desbetreffende land staat. Scheelt dus heel wat netwerk verkeer, en het scheelt jou ook nog eens serverbelasting.

Wanneer jouw belangrijkste doelgroep in Nederland en België is, heeft voor wat betreft de verspreiding een CDN weinig meerwaarde, maar voor wat betreft het ontlasten van je server kan een CDN, vooral wanneer je een media-rijke website hebt, een goede -aanvullende- oplossing zijn.

Er is een aantal grote verschillen tussen een CDN en een Reverse Proxy, die ik toch even op een rijtje wil zetten.

Intermezzo

Wanneer je gehost bent op een shared server, dan zijn dit de cache modellen die mogelijk zijn voor jouw website. De belangrijkste reden dat Apache en Apache compatible webservers zo populair zijn, is omdat de eindgebruiker van het hosting account (jij dus) bepaalde ‘maatwerk configuraties’ zelf kan maken via .htaccess bestanden. Dat is een belangrijke reden ook van het succes van Apache.

In de caching modellen die ik hierna ga bespreken, wordt NGINX gebruikt als webserver. Ja, dezelfde NGINX die we zojuist nog als reverse proxy gebruikten.

Omdat NGINX niet vanuit bepaalde folders met .htaccess bestanden geconfigureerd wordt, maar centraal eigen configuratiebestanden heeft, is het veel lastiger, zoniet bijna onmogelijk, om NGINX velig in een shared hostingomgeving te gebruiken als webserver.

De onderstaande caching modellen zijn dus alleen maar bij VPS hosting mogelijk.

En omdat het ‘werken met een NGINX webserver’ toch wel om andere bekwaam- en vaardigheden vraagt dan werken met Apache, zullen ook weinig hostingpartijen in het geval van Managed hosting (zie nogmaals mijn artikel over VPS-en over het verschil tussen managed en unmanaged hosting) onderstaande opties aanbieden: Om alles betaalbaar te houden, probeert men toch alles zoveel mogelijk ‘uniform’ te houden in het kader van managed hosting.

De opties hieronder genoemd zijn dus vooral van belang voor ‘unmanaged vps hosting’.

En omdat hier mijn eigenlijke verhaal over mijn avonturen met een andere vorm van caching begint, verweef ik mijn eigen avonturen gelijk in het complete verhaal.

Het probleem met Apache

Maar eerst, laten we eens kijken naar onderstaande afbeelding.

Hier zie je mijn server performance over de periode dat ik -op zaterdag 23 november 2024 – overstapte van mijn ‘oude’ configuratie naar een ‘nieuwe’ configuratie.

Het verschil is leuk zichtbaar te maken, omdat het overgangstijdstip precies midden in de periode valt.

In mijn oude situatie maakte ik gebruik van Apache met NGINX als reverse proxy, in de nieuwe situatie maakte ik gebruik van NGINX als webserver.

De staven in de grafiek geven de gemiddelde servertijd per dag aan die nodig is om een complete pagina te genereren en door te sturen naar de bezoeker. Dus inclusief content, exclusief de render-tijd in de browser. Nu is een gemiddelde waarde natuurlijk altijd tricky. Wanneer ik -even heel extreem- 1000 mensen heb die een taak in 1 seconde verrichten, en één persoon die er 1000 seconden over doet, dan is het gemiddelde bijna 2 seconden, dus bijna twee keer zo lang als de meest voorkomende waarde.

Maar hoewel een gemiddelde geen absolute indruk geeft over metingen, is het een goede indicatie voor problemen. En de laatste maanden had ik regelmatig dagen waar de gemiddelde response vanuit de server 4 of meer seconden was. En op dit soort dagen, gebeurde het ook wel eens dat de maximale responsetijd 10 of meer seconden was… met als een extreem voorbeeld 31 seconden.

Dat is natuurlijk onacceptabel. Maar hoe kwam dat?

Soms zit Apache zichzelf in de weg

Soms zit Apache gewoon zichzelf in de weg. Wat doe jij, wanneer een pagina traag laadt? Ik weet wel wat ik doe. Wanneer ik de informatie op die pagina graag wil zien, verbreek ik de verbinding door op de x naast de adresbalk te klikken en druk daarna op dezelfde knop, nu met een ronde pijl, om de pagina te refreshen.

Voor Apache wil dat zeggen, dat er een nieuwe vraag binnen komt, terwijl deze nog staat te wachten op het antwoord uit een ander proces. Op dat moment zijn er twee processen voor mij aan het werk… waarvan het eerste proces pas als het klaar is merkt, dat ik inmiddels ben weggelopen.

Bij een drukke site gebeurt het dus, dat de traagheid van Apache zorgt voor ‘reloads’ van bezoekers, die op zich tot nog meer traagheid gaan leiden. Wanneer je dit als beheerder van de server merkt, is het snel op te lossen, gewone Apache opnieuw opstarten, maar wie zit er de hele dag performance te meten?

Het alternatief

Het alternatief waarvoor ik gekozen heb, is niet voor iedereen even vanzelfsprekend. Ik heb hier het geluk een kleine voorsprong te hebben op de gemiddelde bezitter van een website: Ik ben vertrouwd met de achterliggende techniek.

Er was een kleine lijst met vragen, die ik mijzelf eerst moest stellen

• Ben ik vertrouwd met de Linux bash commandline interface? check
• Denk ik te begrijpen, hoe NGINX als webserver werkt? … nou, nee niet helemaal… dus
• Wil ik hierover bijleren? check. En gelijk de daad bij het woord gevoegd
• Past de door mij gewenste configuratie nog wel in mijn budget? CHECK! Toen ik het nader uitzocht bleek ik zelfs bijna 20 euro per maand te kunnen gaan besparen. Lees hier later meer over.
• Kan ik het mij veroorloven eventueel ‘ongemak’ voor bezoekers te introduceren? Nee, natuurlijk niet. Maar ik had een eenvoudige keuze, want traag ladende sites zijn ook ‘ongemak’. En dat zou een blijvend ongemak zijn, terwijl mijn migratie naar een andere serveromgeving -hopelijk- een tijdelijk ongemak zou zijn. Vandaar met enige twijfel, toch een voorzichtige ‘check’.

Maar, eenmaal de stoute schoenen aangetrokken, was ik binnen een week klaar om met het grote experiment te beginnen.

Mijn toenmalige hoster, waar de WordXPression website op een VPS draaide, kon mij als enig advies geven een zwaarder -en dus duurder- VPS te nemen. Ik ging dus op zoek naar een andere aanbieder (nog steeds goed contact met mijn hoster, en de meeste van mijn andere sites draaien daar nog steeds… maar ja, die trekken niet zoveel verkeer als WordXPression) voor mijn VPS.

In de ‘oude’ situatie betaalde ik 25 euro per maand voor de hosting en 10 euro voor een externe dienst voor cache warming. 35 euro per maand dus voor de WordXPression site.

In mijn nieuwe situatie betaal ik bij Hostinger 11 euro per maand (op basis van een jaarcontract). Ik had nog minder kunnen betalen, wanneer ik voor een lichtere server was gegaan, maar het geringe prijsverschil van 2,50 per maand maakte de ‘grotere’ oplossing (2 CPU cores, in plaats van één, 8 GB RAM, ipv 4 GB en 8TB bandbreedte ipv 4) alleszins aantrekkelijker. En bovendien, die 11 euro gaat volgend jaar pas in, het eerste jaar betaal ik nog geen 6 euro per maand (BFCM aanbieding).

Hierbij moet ik wel opmerken, dat dit exclusief offsite backup is. Zou je dit ook nog willen, betaal je 6 euro per maand meer. Maar aangezien het maken van offsite backups één van de diensten is die ik zelf aanbiedt, kost het mij weinig moeite om die back-ups zelf te maken.

De configuratie

Ik heb zelf in totaal meer dan 16 jaar bij bedrijven gewerkt, waar ik met de ‘linux cli’ (bash, voor de geïnteresseerden) moest werken en het beheren van een server via een command prompt geeft mij geen ongemakkelijk gevoel, hoewel ik wel eerlijk moet zeggen, dat ik het gemak van ‘doorklikken’ op een grafische interface meer dan waarderen kan.

Ik heb dus geen ‘alleskunnend’ panel als CPanel, DirectAdmin of Plesk nodig. Sterker nog, ik heb het nu tweemaal meegemaakt (in de ongeveer 10 jaar dat ik met Plesk werk, dus dat valt ook nog mee), dat door een foutje in Plesk servers plat gingen, en dit alleen via de prompt opgelost kon worden.

Ik wilde dus een ‘lichtgewicht’ en liefst ook gratis (open source) panel. En met CloudPanel heb ik dat ook gevonden. En het leuke van CloudPanel is dat je vanuit CloudPanel ook automatische back-ups kan maken naar bekende opslagdiensten als Amazon AWS, DropBox en meer (zie afbeelding)

Maar laten we nu even verder gaan met de andere caching modellen.

5. NGINX zonder caching

Ik hoor je al denken: Hé, wacht eens Wilko, is dat niet precies hetzelfde als het eerste caching model? Dat is half waar. Maar er is één gigantisch verschil. In mijn artikel over VPS-en heb ik hier al iets over geschreven.

De traditionele webservers (Apache, LiteSpeed, MS-IIS) werken allemaal volgens hetzelfde principe, een synchrone afhandeling van de ‘requests’. Wanneer jij om een pagina vraagt, dan houdt de server de verbinding ‘bezet’ tot het antwoord daar is. Wordt het aantal aanvragen te groot, dan zal de webserver een extra proces starten om meer mensen te helpen.

NGINX werkt wat dat betreft iets anders. Op het moment, dat jij een pagina vraagt, wordt die vraag ‘doorgespeeld’, en pakt NGINX direct de volgende vraag op. In de tijd dat een ‘normale’ webserver wacht op antwoord, heeft NGINX al een aantal andere vragen op kunnen pakken.

Laten we nog eens naar het plaatje kijken:

Op 23 november is mijn site gemigreerd, De cijfers die je daar ziet zijn een ‘mix’ van de oude en de nieuwe server. Daar moet je dus niet teveel aandacht aan besteden.

Zondag 24 november is veel interessanter. Dat is de eerste dag, dat de site 100% op de nieuwe server draaide. Vanaf dat moment zie je eigenlijk tot en met 3 december, dat de gemiddelde snelheid per dag beter was dan de tijd daarvoor. De performance pieken na 24 november zijn vrijwel allemaal lager, dan de performance dalen daarvoor. Kortom op ‘slechte’ dagen presteerde de site beter dan op ‘goede’ dagen daarvoor.

Maar het kon beter. En daarmee komen we op het volgende caching model.

6. NGINX met PHP-FPM caching

Laat me beginnen om te zeggen, dat NGINX altijd met PHP-FPM werkt. Want NGINX is niet veel meer dan een doorgeefluikje voor bestanden. Apache kan met ‘mods’ (modules) PHP begrijpen, maar NGINX begrijpt er helemaal niets van. Het enige wat NGINX kan is het verzoek om een PHP bestand niet zelf af te handelen, maar dit verzoek door te geven aan ‘PHP-FPM’, waarbij FPM staat voor ‘FastCGI Process Manager’. In plaats van -wat Apache traditioneel deed- proberen het PHP bestand zelf te interpreteren, laat NGINX dit door een aparte toepassing dien en geeft het door, zodra het resultaat er is.

En om het één en ander sneller te laten verlopen, is het mogelijk PHP-FPM zo te configureren, dat de caching actief is.

Toen de caching goed geconfigureerd was, bleek ongeveer de helft van de opgevraagde pagina’s uit de cache geleverd te kunnen worden. Dit komt omdat ik een site met meer dan 750 blogposts heb (ja, ik schreef een paar weken geleden nog 800, maar ik heb in de afgelopen tijd wat oud materiaal opgeschoond, en er verdwijnt nog meer in de komende tijd). Er zijn heel wat posts die slechts éénmaal per dag of week opgevraagd worden. Of nog minder. Voor zo’n pagina heeft caching weinig zijn. Heb je een site met een kleiner aantal pagina’s, maar wel de traffic die ik heb, dat is jouw te verwachten winst door de cache vele malen hoger.

Maar ik wist dat het nog beter kon. Maar daarvoor moest ik eerst een probleem oplossen.

7. NGINX met Varnish als reverse proxy

Varnish Cache is al weer een tijdje in omloop en als caching oplossing speelt Varnish een bijzondere rol, omdat Varnisch niet voorgecompileerde pagina’s opslaat, maar pagina’s in het geheugen laadt. De eerste keer dat een pagina wordt opgevraagd wordt de pagina netjes van schijf gelezen en gecompileerd, daarna wordt die pagina iedere keer direct vanuit het geheugen doorgegeven. En dat scheelt natuurlijk behoorlijk. In benchmark situaties zijn snelheidsverbeteringen van 100-250x geen uitzondering. Varnish heeft een eigen configuratie taal (VCL, Varnish Configuration Language), waardoor in specifieke situaties de snelheid behoorlijk verbeterd kan worden.

Mijn uiteindelijke doel met mijn migratie was om NGINX als webserver te gebruiken met Varnish als reverse proxy. Maar daarbij liep ik tegen een groot probleem aan, wat ik niet direct wist te tackelen, maar het positieve bijeffect is, dat je hierdoor 7 en geen 5 caching modellen hebt.

Wat was mijn probleem? Het probleem was vooral, dat ik in eerste instantie niet wist wat het probleem was. Toen ik Varnish Cache begon te gebruiken, merkte ik, dat regelmatig mijn hele website overhoop lag. Zoals in ‘Het ziet er niet uit’.

En dus Varnish Cache even uitgezet, en dieper gedoken in de mogelijke problemen. Nu eten de kinderen van de bakker oud brood, en omdat de verzoeken van mijn klanten belangrijker waren dan mijn uitdaging met Varnish Cache duurde het een paar dagen voordat ik het probleem kon lokaliseren.

Elementor en Varnish Cache

Het probleem is dat Elementor een bug heeft, die in 2019 al is benoemd, maar tot op vandaag niet is gerepareerd, omdat het aantal mensen wat NGINX in combinatie met zowel Elementor als Varnish Cache gebruikt relatief klein is. Maar wanneer je een update van Elementor doet, dan wordt na de update de functie van Elementor aangeroepen, die de CSS bestanden opnieuw genereert, omdat tussen twee Elementor versies de structuur aangepast zou kunnen zijn. Hoera voor Elementor.

Ook Hoera voor de caching methodiek binnen WordPress. Zodra Elementor de bestanden heeft aangepast, vertelt Elementor de WordPress caching plugins, dat de cache leeg gemaakt moet worden.

Dus geen vuiltje aan de lucht.

Nou ja, niet helemaal. Zoals ik in het begin van dit artikel al vertelde, alle WordPress caching plugins gaan uit van een Apache compatible webserver. En NGINX is dat niet! Dus NGINX krijgt niet het signaal, dat de Varnish cache leeg gemaakt moet worden.

Het resultaat is dat bij Elementor updates de HTML wel wordt vernieuwd, de CSS niet. En dat leidt tot een rommeltje.

Op dit moment is er geen oplossing voor. Tenminste geen automatische. Wat er zou moeten gebeuren is dat Elementor na een update the Varnish Cache leeg zou moeten maken. Maar aangezien dit klaarblijkelijk bij de makers geen prioriteit heeft (en om eerlijk te zeggen, dit begrijp ik, omdat ik als Beta tester weet wat er allemaal ligt aan verbeteringsvoorstellen, en hoe klein de groep is, die door dit ‘probleem’ gehinderd wordt. Voor mij persoonlijk heeft een ‘abandoned cart’ trigger voor Elementor een hogere prioriteit)

De handmatige oplossing is Elementor niet (meer) automatisch te updaten. Wanneer er een update van Elementor beschikbaar is, is er een aantal stappen te volgen, om ervoor de zorgen, dat Varnish je site niet door elkaar gooit

1. Wanneer er een update voor Elementor, of Elementor Pro is, voer deze niet direct uit, maar…
2. Maak de Varnish cache leeg
3. Zet Varnish caching uit
4. Update Elementor (Pro)
5. Regenereer de CSS
6. Check de site in een ‘Incognito’ verster.
7. Ziet alles er goed uit, zet Varnish caching weer aan

Is Varnish wel die moeite waard?

Ik kan mij heel goed voorstellen, dat je het idee hebt, dat indien Varnish werkelijk zoveel problemen oplevert, het eigenlijk niet de moeite waard is om te gebruiken. Maar dat is een grote vergissing. Ik laat je dat graag zien aan de hand van een plaatje. Dezelfde grafiek die je al gezien hebt, maar een paar dagen later nadat Varnish actief is geworden.

Op 7 december 2024 had ik mijn ‘Varnish probleem’ opgelost. Omdat de staven nu zo klein zijn geworden in vergelijking met de ‘oude’ situatie even een tabel met de responsetijden sinds 3 december

Zoals je ziet, na het ‘opbouwen’ van de cache sinds 4 december, gaat tijd nodig voor het opbouwen van ‘de gemiddelde pagina’ regelmatig omlaag. Op 10 december heb ik een upgrade naar de nieuwste versie van Elementor gedaan, en de cache leeg gemaakt, met als gevolg, dat de performance ‘even’ iets minder was. Maar nog steeds verwaarloosbaar.

Server response en User Experience

Wat belangrijk is te begrijpen, dat er een verschil is tussen ‘Server response’ en ‘User Experience’ (UX). Op Zondag 8 december had de gemiddelde bezoeker aan de website binnen 0,08 seconde (zo snel kan je niet eens knipperen met je ogen. Een ‘oogknipper’ duurt 0,3 tot 0,4 seconden) een antwoord van de server. Dat is niet hetzelfde als ‘een pagina voor ogen’.

Ruwweg zijn er 4 belangrijke componenten in het opbouwen van een webpagina.

1. Allereerst de tijd tussen het opvragen van een website, en het daadwerkelijk contact krijgen. Om een IP adres bij een domeinnaam te krijgen, moet je contact maken met een DNS server. En die DNS server vertelt je weer, waar de site is. Over dit proces is vrijwel geen controle, maar de tijd hiervoor is tussen de 0,04 seconden en 0,1 seconde (een derde tot vierde oogknipper).
2. Wanneer je contact met de server hebt, komt de ‘Server response tijd’. Wat dat kan zijn zie je in de grafieken en tabellen hierboven.
3. Omdat die informatie ook moet reizen, komt daar de ‘network time’ bovenop. Heb je een snelle internetverbinding, zal dat sneller zijn, dan wanneer je een langzame verbinding hebt.
4. En tenslotte hebben we de DOM time. DOM staat voor ‘Document Object Model’, en dat is de tijd die jouw browser nodig heeft om het beeld zichtbaar te maken. En die DOM tijd, hangt onder andere af van:
   • Snelheid van je processor
   • Hoeveelheid RAM geheugen
   • Grootte van je SWAP file
   • Browser die je gebruikt
   • Aantal applicaties wat je open hebt
   • Tabs en vensters open in je browser

Er zijn maar twee factoren, waar jij als eigenaar van de site invloed op hebt. Hoofdzakelijk op de server-response, en in mindere mate over het netwerkverkeer. De locatie van de server voor je site is van belang. En als die ver verwijderd is van een belangrijke doelgroep, kan een CDN -zie hierboven- je helper zijn.
Wat de capaciteit van de computer van je bezoeker is, welke browser hij gebruikt en hoeveel programma’s hij open heeft… daar heb je geen invloed op.

Het verschil tussen Apache + NGINX als reverse proxy en NGINX en Varnish als proxy

Tussen caching model nummer 3, met NGINX als reverse proxy en dit caching model is één gigantisch verschil.

Wanneer een webserver iets moet doen is het ‘doorgeven van bestanden’ het lichtste werk. In caching modellen als #3, waar Apache de resultaten van het interpreteren van PHP door moet geven, wordt de belangrijkste component van de communicatie -de webserver- het zwaarst belast.

In een configuratie met NGINX als doorgeefluik voor het zwaarste werk, wordt de webserver het minst belast.

Bovendien, in de configuratie met Varnish, is Varnish in staat om alle resultaten direct door te geven aan de client. Nadat NGINX de opdracht aan Varnish heeft uitbesteed, hoeft NGINX letterlijk niets meer te doen.

Wanneer we nu kijken naar mijn slechtste resultaat in de grafieken (gemiddeld 7,2 seconden server tijd) en het beste resultaat (0,8 seconden server tijd) dan is het beste resultaat letterlijk 87,5x sneller dan het slechtste resultaat.

Zou een nog snellere server een nog beter resultaat bereikt hebben met eenzelfde configuratie? Niet waarschijnlijk. In mijn huidige configuratie is het CPU gebruik gemiddeld rond de 25%, het geheugen gebruik rond de 20%. Pas als het gemiddelde gebruik in de buurt van het dubbele zou komen, zou ik mij zorgen gaan maken.

Is er een conclusie mogelijk

Het moge duidelijk zijn, dat de combinatie van NGINX als front-end server met Varnish als ‘reverse proxy’ de snelheid van je site enorm kan verbeteren. De vraag is echter, of de extra kosten de moeite waard zijn. Voor mij was deze ‘overgang’ naar deze configuratie een aanzienlijke besparing voor een revolutionaire snelheidswinst. Maar ik zat tegen de grenzen van mijn huidige configuratie.

Bovendien, het beheren van een dergelijke configuratie kost mij vrijwel niets. Het is mijn vakgebied, en voel mij 100% in mijn element.

Wanneer jij voor een dergelijke configuratie zou kiezen, is je eerste uitdaging een partij te vinden die ‘managed hosting’ voor een dergelijke configuratie aan zou bieden. En dan nog voor een bedrag wat jou de ‘betere prestatie’ waard is.

Denk jij echter, dat een 75+ maal versnelling van je huidige website jou meer omzet op zou kunnen leveren, denk ik graag met je mee. Neem contact op!

Deze blogpost biedt antwoord op ondermeer de volgende vragen:

• Wat is caching en welke rol speelt het bij het opbouwen van een webpagina?
• Welke cachingmodellen zijn er beschikbaar voor WordPress-websites?
• Wat zijn de voor- en nadelen van het gebruik van een cachingplugin?
• Hoe werkt een reverse proxy zoals NGINX in combinatie met WordPress?
• Wat is een Content Delivery Network (CDN) en hoe kan het de prestaties van een WordPress-website verbeteren?