Met adoptie van Instant.page, tevens compatible gemaakt voor IE11, hebben we deze week websites voor onze opdrachtgevers 3.125 keer sneller kunnen maken dan de norm.
Google's geadviseerde bovengrens als TTFB voor dynamische content ligt op 500 milliseconden. Met TTFB's van 0,16 ms liggen de websites van onze opdrachtgevers met de adoptie van Instant.page daar inmiddels een factor 3.125 onder. Afgelopen week hebben we meerdere websites voorzien van deze update.
Time to First Byte
Over Time to First Byte schreef ik eens eerder, waarin de volgende normen te lezen viel:
- Statische content zou een TTFB van onder de 100ms maar in elk geval 200ms moeten behalen. Deze kunnen immers direct van de server worden 'geplukt';
- Een CMS (c.q. dynamische content) zou tijden van 200ms tot 500ms na moeten streven, dit wordt gezien als standaard;
- Samengevat is alles boven de 500ms of 1000ms, respectievelijk alles behalve ideaal en reden voor maatregelen.
Pagespeed en performance gaan echter verder dan alleen de TTFB. Net als SEO in zijn algemeen, is ook optimale performance een optelsom van factoren en metrics. Elke metric kent weer zijn eigen factoren: Een zwaar CMS als ook hosting kunnen debet zijn aan een slechte TTFB.
Resultaten voor onze klanten zijn gemiddeldweg inmiddels als volgt:
Nuance op behaalde pagespeed resultaten
Enige nuance is uiteraard op zijn plaats omtrent de behaalde resultaten binnen het CMS dat wij inzetten voor opdrachtgevers. Waar "Google's norm" 500ms betreft voor dynamische content, stelt het door ons benut CMS en techniek ons in staat te monitoren op de uiterste bovengrens van statische content (200ms), vanaf nu genoemd "onze norm".
Want; een halve seconde om alleen met een response terug te komen is eigenlijk te veel, wanneer je je bedenkt dat verdere CSS, JS en afbeeldingen nog gedownload en verwerkt moeten worden door je browser. Wanneer je daarin enkele steken laat vallen, komt je website al snel boven de seconde uit qua totale laadtijd.
De nuance op de behaalde pagespeed resultaten is als volgt:
- TTFB voor dynamische content was met 83ms (zie "Server side rendering" in bovenstaande afbeelding) reeds een factor 6 lager dan Google's norm, een factor 2 lager dan onze norm;
- Het CMS voorziet in server side caching, waarmee de TTFB (20ms, zie "Server side cache") een factor 25 lager ligt dan Google's TTFB norm, een factor 10 lager dan onze norm;
- Met een TTFB van 0,16 ms in geval van "Prefetching", zijn we er een factor 125 op vooruit gegaan ten opzichte van reeds behaalde resultaten, een factor 1.250 ten opzichte van onze norm en een factor 3.125 ten opzichte van Google's norm.
Deze optimalisatie-ronde is mogelijk gemaakt door verdere onderliggende techniek. Een goede pagespeed middels optimale TTFB kan echter eenvoudig om zeep worden geholpen bij veelvuldig inzet van bijvoorbeeld JavaScript, bijvoorbeeld via plugins.
Waarneembare winsten
Doordat met de inzet van JavaScript, CSS en afbeeldingen precair wordt omgegaan door het CMS dat wij gebruiken, zijn de behaalde winsten ten opzichte van voorheen behaalde resultaten nauwelijks waarneembaar. We praten immers over een verschil van 19 milliseconden ten opzichte van de 20 ms en 0,16 ms.
Echter, op een minder optimale internetverbinding, oudere toestellen of minder dure servers kan of zal dit resulteren in een waarneembare laadtijd-verbetering. In combinatie met het volgende, heb je een website waar niet tegen te knipogen is, terwijl je navigeert:
Inzet resource hints
Resource hints worden soms, ook wellicht binnen jouw website, al automatisch toegepast. Niet altijd even optimaal, zoals bijvoorbeeld in Wordpress. Toch zal het bij correct gebruik voor waarneembare verschillen zorgen. Uiteraard op langzame verbindingen beter waarneembaar dan op je eigen wifi.
Terwijl de browser de website opbouwt, kun je alvast verbindingen laten leggen of bronnen laten downloaden die later gebruikt gaan worden. Vooral handig wanneer je gebruik maakt van een CDN of geen standaard lettertypen gebruikt op je website. Deze (download-)taken die je aan de browser mee kunt geven, blokkeren de main-thread van de browser níet, waardoor het de performance niet in de weg zit, maar juist verbetert; Bronnen zijn immers reeds gedownload (of in gang gezet om te downloaden) voordat ze gebruikt gaan worden.
Prefetching: technische implementatie
Dezelfde techniek kan ook worden gebruikt om een pagina alvast in te laden voordat deze bezocht gaat worden door een gebruiker. Google heeft hiervoor een library geschreven, waarmee alle zichtbare hyperlinks al ingeladen worden voordat iemand er op klikt. Deze pagina's worden dus daadwerkelijk opgevraagd, wat het een vrij agressieve vorm van prefetching maakt doordat er veel dataverkeer wordt gegenereerd.
Kanttekeningen van prefetching
Zit iemand op een smartphone, dan zal dat ten koste gaan van dataverbruik binnen een internet-abonnement. Ook kan dit juist voor toegenomen server-load zorgen. Een beter alternatief, zo zegt ook Google zelf, is dus Instant.page. Deze toepassing zal pas eigen interne pagina's inladen indien men op het punt staat interactie aan te gaan met een menuknop of hyperlink in de tekst.
Wil je gebruik maken van prefetching, zorg dan dat je alleen bronnen vooraf inlaadt, waarvan de kans groot is dat ze gebruikt gaan worden. Probeer daarbij inline slideshows uit te sluiten, aangezien afbeeldingen soms vrij groot kunnen zijn.
Geef bovendien de voorkeur aan prefetch of -indien je zeker weet dat een bronbestand op een pagina gebruikt gaat worden, zoals fonts- preload, in plaats van prerender. Wanneer je prerender gebruikt, wordt er een onzichtbare tab geopend waarin een pagina alvast wordt ingeladen, maar dan inclusief alle bronnen waarnaar verwezen wordt binnen de onzichtbare pagina's. Niet alleen het dataverkeer van je bezoekers en je eigen server zal toenemen, ook je analytics zullen niet waarheidsgetrouwe data tonen.
Getweaked voor browsers en producten
De Instant.page toepassing hebben we getweaked, zodat het ook compatibel is met Internet Explorer 11. Verder hebben we ondersteuning voor prefetching van afbeeldingen toegevoegd, wat voor webshops met productafbeeldingen van toegevoegde waarde is; zodra iemand vanuit de webshop naar een productpagina navigeert, kan het belangrijkste, de titel en eerste foto, direct getoond worden. Dit zie je in actie op wiecherswonen.nl -> merken.
Dubbele winsten binnen Lightbolt CMS
Juist middels optimale scheiding van HTML, CSS en JavaScript, zijn de HTML documenten die door het LightBolt CMS gegenereerd worden, vrij klein van stuk (dit artikel is nog geen 10kb). Prefetching heeft dus nooit een heel groot impact op dataverkeer voor bezoeker of server.
Ander voordeel is inzet van server side caching. Bezoekt iemand een pagina die al eens eerder bezocht is en tussentijds niet is gewijzigd, dan zal een server side cache-bestand aan de bezoeker worden voorgeschoteld. Dit kan resulteren in een zeer lage TTFB van 20ms.
In die zin heeft prefetching twee voordelen:
- Het laadt een document alvast vooraf in zodat deze alvast in de browser-cache zit;
- Terwijl dit gebeurde, werd er door het CMS direct gecontroleerd of een cache-versie al bestond, of zal deze aanmaken indien dit niet het geval is.
Dubbele winst dus!
Ook dubbele winsten behalen en ruim 3.000 keer sneller zijn dan de norm? Neem vooral contact met me op! Zelf aan de slag? Bekijk eerst de 8 redenen waarom je SEO verkeerd doet.
