Blog
Hoe jouw website de sales en conversie laat exploderen ... van je concurrent!
Je kent vast van die websites waarvan je je afvraagt of ze de bits met de hand aan het versturen zijn. Maar hoe staat het met de snelheid van jouw website? Of van je webshop? Enne ... hoe snel is die voor een gebruiker die hem met 4G vanaf zijn telefoon bezoekt? Of een gebruiker die nog geen supersnelle glasvezel verbinding heeft of op een wat oudere P.C. werkt?
Klanten wachten niet
Je weet, klanten hebben geen geduld. De tijd dat ze bij het maken van de internet verbinding koffie gingen halen en terug kwamen als het modem uitgeraasd was zijn voorbij. Oud nieuws. En toch verbaas ik me met regelmaat hoeveel super trage websites ik tegenkom. Wanneer je website of webshop in 2 seconden ‘staat’ – ofwel, zichtbaar en bruikbaar is voor de gebruiker, converteer je zo'n 7,5% van de bezoekers. Bij 5 seconden is dat al gedaald naar 2% en bij 10 seconden laadtijd keldert dat naar 0,2%. De rest zit al bij je concurrentie.
Interessant genoeg moet je website of shop ook niet sneller worden dan 0,1 seconde. Als een pagina sneller is dan 0,1 seconde heeft de bezoeker de indruk dat de website niets gedaan heeft.
Je kunt aan je server alleen niet zien wat je klant ervaart. Dat leg ik verderop in de blog uit.
Je zinkt als een baksteen op Google
Niet alleen klanten, ook Google en andere zoekmachines kijken naar je snelheid om je ranking te bepalen. Trage websites ranken lager. Als bezoekers dan ook nog sneller weg navigeren omdat ze je te traag vinden, het zgn. 'pogo sticking', helpen al je dure SEO- en met name zoekwoorden optimalisaties en link building niet meer om je ranking hoog te houden.
Een pagina die 7 seconden bevriest
Ik geef een voorbeeld. Op een webshop die reizen verkoopt bevroor de pagina 7 seconden lang. Ga even na. Tel anders even mee, 1, 2, 3, 4, 5, 6, 7. Duurt lang! Daar wachten de meeste klanten dus niet op daarmee was de conversie dramatisch laag. De webserver was het niet, die was bloedje snel. Wat was er aan de hand? Bij de reizen werd een interactief kaartje getoond van het gebied van de reis. Dat kwam van een third party provider af, niet van de eigen webserver. Dat kaartje kostte de 7 seconden. Maar omdat het onder de welbekende vouw stond, hadden de bezoekers geen idee waar ze op zaten te wachten en hadden ze snel een andere reis elders gevonden.
32 Seconden wachten op een onboarding pagina
Nog een voorbeeld. Een onboarding website voor een financieel product was al niet snel met stellen van de wettelijk verplichte vragen, maar de pagina met het uiteindelijke aanbod kostte 32 seconden voor een potentiële klant. Het hoeft geen betoog dat de verkoop van het financiële product slecht liep. Ook hier was het probleem niet op de eigen webserver te vinden. De aanbod pagina bleek 140(!) JavaScript libraries aan te roepen. Die moesten stuk voor stuk opgehaald, gelezen en verwerkt (geparsed in technische termen) worden. Daarna werden ze aangeroepen, wat ook tijd kost. De pagina had twee grafieken, die elk met een verschillende JavaScript library getoond werden. Opvolgende ontwikkelaars hadden steeds hun eigen favoriete smaak JavaScript toegevoegd waardoor deze pagina een trage olietanker geworden was in plaats van de vlotte speedboat die het had moeten zijn.
Cloudflare vertraagde alleen maar
Voor een website was Cloudflare ingezet als Content Delivery Netwerk (CDN). Bij deze website was Cloudflare verkeerd geconfigureerd. Alle content stond dynamisch, waardoor Cloudflare alles, ook de statische content, bij de webserver ging ophalen. Hierdoor werd de statische content veel langzamer. Omdat de webserver heel veel meer verzoeken kreeg werd deze volledig overbelast en werd de echte dynamische content ook heel veel langzamer.
Door de Cloudflare configuratie op orde te maken gingen de laadtijd van de webpagina's van 6 naar 2 seconden. Bingo! Want de conversie ging van 1,2% naar 7,5%! Een conversiepercentage dat meer dan 5 keer zo hoog ligt. En zodra Google dit ziet zal het aantal bezoekers ook nog eens toenemen.
Voor het geval je niet weet wat een CDN is, dat gebruik je om content die niet wijzigt, zoals afbeeldingen en JavaScript, efficiënt naar je bezoekers te brengen. Het CDN leest die dan eenmaal van je webserver, onthoudt die (cachen in technische termen) en stuurt de tweede en volgende keer je bezoeker deze content vanuit zijn geheugen. Je ontlast hiermee je webserver en je versnelt het afleveren van de content aan je bezoeker omdat ze bij het CDN hele snelle server en een hele snelle Internet verbinding hebben.
Waarvan wordt een website of webshop nou eigenlijk snel of traag?
Voor degenen die willen begrijpen wat er onder de motorkap gebeurt, volgt hier een rijtje zaken wat je website aanzienlijk kan vertragen. Voor iedereen die dat graag aan iemand anders overlaat, ga naar de laatste paragraaf van dit blog!
De webserver: De webserver levert uiteindelijk de content voor de bezoeker. Als de webserver niet snel is dan zal de bezoeker een slechte ervaring hebben. Vooral met web hostingpakketten zien we lange responstijden. Ook met zgn. 'ongelimiteerde' pakketten. Je moet goed kijken wat er ongelimiteerd is, want er is altijd wel ergens een limiet opgezet die je bezoekers gaat hinderen. Maar ook met eigen webservers kan hier snel een bottleneck ontstaan, vooral als je bezoekersaantaallen groeien.
De database: Bij een webshop is vaak ook de achterliggende database, waarin je je producten en verkopen opslaat, niet in staat om grotere drukte af te handelen. Bij een website is dit minder vaak een probleem.
Jouw internet verbinding: Vaak wordt alleen een bepaalde bandbreedte aangeboden, of een bepaald aantal gigabyte per maand. Waar providers vaak niets over zeggen is de zgn latency. De bandbreedte is de breedte van de weg, de latency is de lengte van de weg. Op een weg die breed is maar heel lang ben je alsnog lang onderweg. Ook als je niet in een gedeelde omgeving draait is dit een belangrijke factor.
De Internet verbinding van de bezoeker: Je kunt nog zo snel zijn, als je bezoekers een langzame verbinding hebben of zelf een hoge latency hebben, dan zal de ervaring van je bezoeker slecht zijn als je website of webshop daar niet mee om kan gaan.
Het aantal componenten: Webpagina's worden opgebouwd uit componenten. De webpagina zelf, plaatjes, JavaScript, style sheets, fonts, ... De browser van je bezoeker haalt daarvan maar een beperkt aantal tegelijk op. Heb je er teveel dan komen die allemaal in een wachtrij, waar je bezoeker op moet wachten. De norm is maximaal 20 componenten per pagina. Wij zien er soms 200 of meer en daar wordt je pagina serieus traag van.
De grootte van de componenten: Afbeeldingen zijn de meest voorkomende grote componenten. We zien nog te vaak dat een afbeelding op volle camera-resolutie naar een telefoon gestuurd wordt. Natuurlijk kan de telefoon die schalen, maar het kost tijd om die grote afbeelding over te sturen en daarna om hem omlaag te schalen. Maar ook grote lappen JavaScript-code waarvan maar een klein deel gebruikt wordt en zelfs grote fonts kunnen vertragend werken.
Third party componenten: Denk hierbij aan allerlei bezoekertracking als Google Analytics, Facebook en LinkedIn. Maar ook Google Maps als je een navigatie kaartje naar je fysieke locatie hebt. Het is prachtig al deze functionaliteit, maar het kost allemaal tijd. Laatst hebben we nog een website gezien waar Pinterest doodleuk 6 seconden laat wachten voordat er een tracking GIFje geleverd wordt. En soms zijn er doublures die je echt niet nodig hebt.
Uitvoeren van JavaScript: We zien de mooiste functionaliteit met JavaScript gerealiseerd, alleen soms kost dat vaak ook heel erg veel tijd. Denk aan het kaartje op reiswebsite in het voorbeeld hierboven. JavaScript is heel flexibel, maar bepaald niet de snelste taal.
Gebrek aan caching: Als een browser een component, zoals een afbeelding, van een server krijgt dan kan deze in de browser bewaard worden, zodat deze niet opnieuw van de server opgehaald hoeft te worden als dezelfde component nogmaals nodig is. Dit heet caching. Maar caching gebeurt alleen als de server aan de browser aangeeft dat caching zinvol is. En daar gaat het vaak fout: veel servers gebruiken de verkeerde instellingen waardoor browsers dezelfde component onnodig 2, 5 of meer keer van de server ophalen.
Hoe meet je het?
Om goed te weten wat verschillende gebruikers gaan ervaren op je website of webshop moet je de omstandigheden van hun bezoek zo goed mogelijk nabootsen. Meet eerst hoe je gebruikers binnenkomen, dat kun je uit de server logging halen.
Daarna ga je de omstandigheden van je bezoekers zo goed mogelijk nabootsen. Afhankelijk van je doel, de complexiteit van de website of webshop en je budget kun je daar zelf mee aan de slag of kun je een gespecialiseerd bedrijf, zoals Sciante, inhuren. De kosten om dit meetbaar te krijgen vallen reuze mee, helemaal in vergelijking met de verborgen kosten van een trage website.
En hoe krijg je die website nu snel?
Wat je precies moet doen is natuurlijk afhankelijk van wat er gemeten is maar een aantal verbeteringen helpt altijd:
Maak componenten zo klein mogelijk: Voor afbeeldingen betekent dit dat de server verschillende formaten heeft voor verschillende formaten devices. Voor een telefoon wordt dan een veel kleinere afbeelding gestuurd dan voor iemand die je website bezoekt vanaf haar 70-inch televisie. Voor JavaScript en style sheets betekent het onder andere het zgn. minimizen, een vorm van code compressie. Voor fonts betekent het gebruik maken van vector fonts in plaats van bitmap fonts.
Breng het aantal componenten omlaag: JavaScripts en style sheets die op dezelfde pagina gebruikt worden kunnen aan elkaar geplakt worden zodat ze per soort nog maar 1 component hebben. Gebruik je veel kleine afbeeldingen, combineer die dan in een font.
Gebruik server compressie: Veel componenten kunnen aan de server kant gecomprimeerd worden waardoor ze sneller overgezet kunnen worden. Maar gebruik het wel selectief, afbeeldingen zijn vaak al gecomprimeerd, nogmaals comprimeren kost alleen maar extra tijd.
Gebruik third party content spaarzaam: Het klinkt goed om precies te kunnen zien wat
je bezoekers doen. Maar vraag je af of je het echt gaat gebruiken en kijk goed of er geen doublures zijn. Het plaatsen van een Pinterest tracking GIF is zinloos als je niet op Pinterest adverteert bijvoorbeeld.
Gebruik een CDN voor je statische content: Een CDN kan statische content doorgaans veel sneller en goedkoper uitleveren dan een uitbreiding van jouw webserver dat kan. Maar test het wel goed voor je een lange termijn contract afsluit, er is nog veel kaf onder het koren. Sommige componenten die je gebruikt, zoals JQuery bijvoorbeeld, kun je van een bestaand CDN afnemen.
En nu?
Maak je je zorgen over de snelheid van je website? Maak eens een 15 minuten babbel met mij. Dat kost je geen euro’s, alleen een beetje tijd. En ik beloof je dat dit een goede investering voor je is! Dan weet je waar je staat en leg ik je ook uit wat je eventuele vervolgstappen moeten zijn. Alleen zo weet je of je website jouw sales of die van je concurrent laat exploderen.