Een CMS zorgt voor dynamische invulling voor zijn webpagina's, maar deze dynamiek gaat logischerwijs ten koste van de uitvoertijd, en daarmee tevens de zogenaamde Time To First Byte. Des te meer taken het CMS uit moet voeren om de door je bezoeker opgevraagde content te genereren, des te langer het duurt voordat de eerste byte door je bezoeker zijn of haar browser ontvangen is.
Nieuw per juni 2019: TTFB data van CMS oplossingen in CrUX.
Pagespeed is meer dan TTFB
Uiteraard betreft de Time To First Byte, afgekort tot TTFB, één van de vele invloeden in de totaal-ervaring van je website bezoekers als ook de ranking van je website in de SERP's. Hooguit vanaf de First Byte, zal je webbrowser in staat zijn om vervolgtaken uit te voeren (afbeeldingen, CSS, JS files downloaden en uitvoeren) en je browserscherm in te tekenen met uiteindelijk een functionerende webpagina als gevolg. Dit proces kun je bespoedigen door resource hints in te zetten, te voorzien in critical render path en het cookie-loos serveren van overige bronbestanden, voor een snellere website.
TTFB voor Google
De facetten binnen website performance en page speed optimalisatie, betreft een samenspel om tot een optimale pagespeed te komen. Zijn binnen een website niet alle facetten verzorgd, dan loop je het risico andere optimalisatie-slagen teniet te doen in je quest naar een snellere website. Reeds sinds 2010, neemt Google de TTFB metric als ranking-factor mee in hun SERP's. Met de in 2015 bijgekomen Mobilegeddon omtrent Google's mobile-first gedachte, lijkt client side pagespeed optimalisatie minstens zo belangrijk te zijn geworden.
Vandaag probeer ik me echter te beperken tot de Time To First Byte binnen een CMS. Het zal voor zich spreken dat een degelijke hosting een rol speelt, maar ook het CMS dat je gebruikt oefent invloed uit op de TTFB. Magento of Wordpress staan er bijvoorbeeld niet om bekend in de basis snel te zijn.
TTFB in praktijk
Gedurende Wordpress onderhoud in de afgelopen jaren, ben ik Wordpress websites tegengekomen met PHP responsetijden van 4470ms, als ook 1560ms (niet ongewoon voor Wordpress). Ter voorbeeld: Het LightBolt CMS levert tijden op van 0,0015 seconden onder de motorkap. Hogere wiskunde is niet nodig om te concluderen dat Wordpress met behoudt van dynamiek 1.000 tot 3.000 keer langzamer is. Bereken je eigen winst op www.lightbolt.nl.
Bovenstaand betreffen echter de netto server side uitvoertijden door PHP, waarna het nog door de browser ontvangen moet worden. De TTFB zal dus uitvallen tot te hoge aantallen, met nodig bezoeker- of omzetverlies.
- Statische content zou een TTFB van onder de 100ms moeten behalen. Deze kunnen immers direct van de server worden 'geplukt'.
Praktijk leert echter, dat ook hiervoor, afhankelijk van het CMS, dynamiek aan te pas kan komen, bijvoorbeeld in het geval van Wordpress. Mergen van resources of toevoegen van de critical render path gebeurt afhankelijk van de gebruikte plugin, on the fly; - Een CMS zou tijden van 200ms tot 500ms na moeten streven, dit wordt gezien als standaard. Desondanks betreft de grens van maximaal 200ms een factor in Google's PageSpeed Insights test. Dit geeft de noodzaak van ingrepen binnen de meer bekende CMS oplossingen als Wordpress of Magento weer;
- Samengevat is alles boven de 500ms of 1000ms, respectievelijk alles behalve ideaal en reden voor maatregelen.
TTFB voor Wordpress beperken
De TTFB beperken binnen Wordpress, is een taak op zich. Elke nieuwe Wordpress plugin die je installeert, heeft zijn impact op de uitvoertijd op de server en ook de uiteindelijke TTFB. Met plugins, maak je je website dus hooguit langzamer. Maar ook hiervoor zijn Wordpress plugins in het leven geroepen. Ze maken je plugins en website niet sneller, ze werpen een caching mechanisme op.
WP Super cache
De bekendste is WP Super Cache. Dit is eigenlijk de enige Wordpress plugin, die je Wordpress site niet slomer maakt. Wel lever je in op dynamiek, die je al dan niet via .htaccess op zou kunnen vangen. Dit is echter geen onderdeel van de plugin, waardoor uitzonderingen omtrent het al dan niet doormeten van eigen bezoeken, of toepassen van Critical Render Path versus client side caching voor eerste unieke pageviews, eigen invulling betreft.
Ook kent een Wordpress plugin als WP Super Cache niet je gehele website, en dus ook niet de architectuur of dynamiek voortgebracht in andere plugins. Conflicten met andere Wordpress plugins terwijl je probeert de Time To First Byte in te perken, zullen dus niet als een verrassing moeten komen.
LightBolt CMS
Caching in LightBolt
Het LightBolt CMS, kent geen plugins voor optimalisatie; Deze technische pagespeed optimalisatie als resource hints, critical render path, mergen & minimizen van bronbestanden, asynchroon inladen en cookie-loos serveren van bronbestanden zijn aanwezig in de basis. Ook een tweelaagse caching-mechanisme is aanwezig, indien ingesteld voor pagina's. Hierbij wordt rekening gehouden met zaken als wel of niet doormeten van je eigen bezoeken van je eigen website, dynamische optimalisatie mechanismen en dynamische acties. Het CMS vormt een samenspel, waarbij het caching mechanisme rekening houdt met de rest van de CMS architectuur.
Time To First Byte in LightBolt
Het LightBolt CMS was reeds optimaal geprogrammeerd, met responsetijden rond de 0,02s (20 milliseconden), op basis van éénlaags caching. Recent hebben we er een meer intensieve caching voor gezet, waarmee door het CMS responsetijden van 0,0015 seconden (1,5ms) behaald worden. Dit levert in de browser TTFB's op van 20 tot 30ms.
Als frontender reeds bekend met pagespeed en optimalisatie en laat je niets aan het toeval over? Of heb je affiniteit met optimaliseren van de performance en leer je er graag meer over in werkverband? Wij hebben een passende frontend developer vacature open staan.