Om te kijken hoe e-commerce platformen onder druk presteren, voerde Computest gedurende de week van Black Friday performance-metingen uit op 25 populaire webwinkels, waaronder de Twinkle Top 10.
Tekst: Jeffrey de Ridder en Mike van Toledo
Black Friday: er was geen ontkomen aan. Schreeuwende reclames en vele nieuwsbrieven die consumenten aansporen om op koopjes te jagen. Ongetwijfeld heeft het voor veel online retailers voor nieuwe bezoekersrecords gezorgd. Records die ook voor problemen kunnen zorgen als je niet weet wat deze doen met de snelheid en beschikbaarheid van je webwinkel. Om te kijken hoe webshops onder druk presteren, namen we een week lang de Black Friday performance-metingen* van 25 populaire webwinkels onder de loep, waaronder de Twinkle Top 10. Lees hoe de sites presteerden én ontdek hoe je als online retailer zorgt dat je platform zelfs bij massaal bezoek topprestaties levert.
Veel retailers hielden de Black Friday-acties niet beperkt tot afgelopen vrijdag. We hebben daarom gedurende een week gekeken hoe de shops presteerden. Hierbij hebben we zowel naar de laadtijd (ook wel responstijd genoemd) van de homepage gekeken als naar de speciale Black Friday-pagina’s. Uit onze metingen blijkt dat Zalando zowel gedurende de week als op Black Friday het best presteerde, gevolgd door bol.com. Met een gemiddelde responstijd van 0,91 seconden over de hele week en 1,09 seconden op Black Friday was Zalando blijkbaar goed voorbereid op de drukte. Voor de gemiddelde responstijd op Black Friday waren de Hema en de Bijenkorf de nummers 3 en 4 met responstijden van respectievelijk 1,58 en 1,59 seconden.
Coolblue hekkensluiter
Als je kijkt naar de platformen die de afgelopen week minder sterke prestaties lieten zien valt direct iets op: Coolblue is hekkensluiter. De webwinkel die service tot een kunst heeft verheven, heeft zijn klanten afgelopen week online iets langer laten wachten. Met een gemiddelde responstijd van 4,10 seconden moesten consumenten hier het meeste geduld hebben voordat zij een aankoop konden doen. Ook Albert Heijn presteert met 3,23 seconden beneden verwachting, wat grotendeels te herleiden is naar de zwakke prestaties op maandagavond.
Verder was duidelijk te zien dat BCC, die net buiten de top 10 valt, afgelopen week online wat uitdagende momenten had. Op 27 november was de webwinkel bijna 12 uur lang onbereikbaar voor bezoekers. Dit lijkt te wijten aan een issue dat vanaf 23.20 opspeelde. Rond 11.00 uur de volgende ochtend leek dit opgelost. Gezien het feit dat BCC de hele week acties had, zal dit ongetwijfeld invloed hebben gehad op het transactievolume.
Ideale gemiddelde responstijd
Idealiter ligt de gemiddelde responstijd van e-commerceplatformen onder de twee seconden. Onderzoek van de Aberdeen Group laat bovendien zien dat 40 procent van de consumenten een website verlaat als het meer dan drie seconden duurt voordat deze geladen is. Nu hebben mensen als het om een Black Friday deal gaat wellicht iets meer geduld, maar doorgaans raakt de consument bij te lang wachten geïrriteerd of haakt deze af. Dit is niet alleen een risico voor de conversie in je webwinkel, maar maakt ook de kans dat de consument terugkeert kleiner. Een optimale responstijd zou je dan ook niet alleen moeten zien als een manier om je conversie te verhogen, maar moet onderdeel zijn van de service die je als webshop biedt.
Adviezen voor optimale performance
Hoe zorg je er dan voor dat je platform altijd klaar is om topprestaties te leveren onder hoge belasting?
-
Vertrouw niet zomaar op automatisch opschalen in de cloud
Doorgaans wordt de hardware-capaciteit gezien als belangrijkste beperkende factor van een webwinkel. Limieten op dit gebied zijn echter heel simpel door te rekenen. Op basis daarvan kun je voorspellen wat de benodigde bandbreedte of rekencapaciteit is gerelateerd aan het aantal bezoekers. Mocht hier onvoldoende capaciteit zijn, dan kun je met een cloud-infrastructuur heel makkelijk uitbreiden. Dit brengt echter ook risico’s met zich mee.
Automatisch schalen in een cloud-infrastructuur betekent namelijk niet dat het systeem de maximaal verwachte belasting altijd aankan. Er zijn immers systeeminstellingen of -grenzen die niet overschreden kunnen worden. Denk aan een maximum van het aantal gelijktijdige connecties met de webservers of databases. Of quota’s op het netwerkverkeer of aantal requests per seconde. Daarnaast kan het gehuurde aantal CPU’s dermate hoog zijn dat het maximum wordt bereikt waardoor er niet meer automatisch opgeschaald kan worden. Daar wil je op je drukste moment niet tegenaan lopen. Zorg dus dat je hier altijd inzicht in hebt.
2. Onderschat de impact van de locatie van de cloud niet
Ook de locatie van de cloud heeft invloed op de performance. De infrastructuur van Amazon bevindt zich bijvoorbeeld in Ierland en die van Rackspace in Engeland. Dat levert automatisch een hogere latency op, ondanks dat de technologie steeds beter wordt en de snelheid van het datatransport toeneemt. Zo kan de applicatie veel interactie hebben met andere applicaties, waarvan de infrastructuur wél in Nederland staat. Dit is een factor die veel impact kan hebben op de responstijden, maar waar niet direct aan wordt gedacht.
3. Laat rijke (promotie)content serveren door een Content Delivery Network
Om speciale aanbiedingen zoals Black Friday-koopjes te promoten zetten online winkeliers vaak rich media in. Deze hebben logischerwijs ook invloed op de laadtijd van je site. Om te zorgen dat deze content niet voor problemen zorgt bij piekbelasting kun je static resources zoals JavaScripts, afbeeldingen en stylesheets laten serveren door een Content Delivery Network (CDN). Hiermee worden de eigen webservers ontlast van verkeer zodat de performance van de webshop wordt geoptimaliseerd. Dit kan een belangrijk verschil betekenen in de ervaring van de doorgaans weinig geduldige online shopper. Het inzetten van een CDN is overigens niet zonder risico’s dus als je dit doet, schakel dan de hulp in van experts.
4. Voer voor de actieperiode testen uit vanuit gebruikersperspectief
Om een reëel beeld te krijgen of jouw platform klaar is voor piekbelasting, is het verstandig om voor de actieperiode je webwinkel te testen vanuit het perspectief van de gebruiker. Zorg dat je inzicht hebt in gebruikersgedrag en boots dit na. Hiervoor kun je scripts (laten) bouwen die gebruikers simuleren die de gewenste acties binnen de webapplicatie doorlopen. Vervolgens kun je variatie aanbrengen in de test door verschillende gebruikerspopulaties te simuleren volgens een vastgestelde verdeling. Zo krijg je een realistische test waarmee je nog voordat je met je actie van start gaat performance-issues op tijd opspoort en kunt oplossen.
5. Houd vinger aan de pols met continue monitoring
Je voert niet iedere dag een test uit. Daarom is het raadzaam om je platform continu te monitoren. Zo weet je altijd of de doelen met betrekking tot responstijd worden gehaald en wanneer niet. Hiervoor kun je tools inzetten die iedere paar minuten testen of de kritieke paden van je webwinkel nog werken binnen de gestelde tijden. Als er onregelmatigheden voorkomen in de responstijden, dan krijg je direct een notificatie.
6. Maak gebruik van caching
Om de belasting op je infrastructuur te reduceren en de laadtijd te bevorderen, kun je caching inzetten via de browser en het CDN. Als er wordt gecached in het CDN kijk dan ook goed naar de cache-instellingen. Wanneer deze niet voldoende zijn geoptimaliseerd dan moet het CDN teveel vragen van de origin en verlies je alsnog tijd in het laden van de content.
7. Verspreid je acties en je load
Als je slim om wilt gaan met je capaciteit kun je, zoals een aantal webshops afgelopen week al deden, je acties over een langere periode laten lopen in plaats van op 1 dag. Nu werd hier door Twinkle-100 aanvoerder Bol.com ook voor gepleit, al had dit meer te maken met de logistieke afhandeling van alle pakketten gedurende de Sinterklaas- en kerstperiode. Zoals we hebben gezien is logistieke afhandeling van je webverkeer echter ook een belangrijke reden om goed na te denken over hoe je je actieperiode plant en inricht.
Bedenk hoe je wil falen...
Mocht het niet haalbaar zijn om met bovenstaande zaken aan de slag te gaan, bedenk dan van tevoren hoe je zou willen falen. Hier kan een goede error-pagina het verschil maken. Een voorbeeld dat we op Black Friday zagen was slim bedacht, maar schoot in de praktijk het doel voorbij: Dyson kon het aantal bezoekers niet aan en had een pagina met een wachtrij. Dit is alleen weinig hoopgevend als je nummer 7516 krijgt toegewezen. Bovendien liep de laadtijd van de website soms op tot 30 seconden.
Vandaag zal ‘Cyber Monday’ ongetwijfeld tot nieuwe, interessante performance-cijfers leiden. En hopelijk ook tot inzichten voor online retailers dat iedere milliseconde vertraging bij het bezoeken van hun webwinkel, een actie kan maken of breken. Want koopje of niet, voor de hedendaagse consument is geduld al lang geen schone zaak meer.
* Voor het uitvoeren van de metingen heeft Computest een geautomatiseerd testscript gemaakt. Deze startte iedere 5 minuten de webbrowser en navigeerde vervolgens naar de homepage en indien aanwezig, naar de actiepagina voor Black Friday. Voor het beoordelen van de performance werd op iedere pagina gekeken hoe snel bepaalde elementen zoals een afbeelding of tekst waren geladen waardoor nauwkeurig kon worden vastgesteld hoe lang de bezoeker moest wachten.
Tekst: Jeffrey de Ridder is Team Captain & Performance Engineer en Mike van Toledo is Performance-specialist bij Computest.
Beste Twinkle,
Wij doen ook dit soort testen en die leveren bij kleine wijzigingen van de opzet en/of onjuiste uitleg van de 'test', direct een andere lijst van 'best performancers' op.
Daarom mijn brandende vraag:
- is het respons tijd (response time); dus het client verzoek in de browser tot aan de website (de ping) of is het de tijd van een volledig ingeladen website?
- In geval van volledig ingeladen website meting is het 'appels met peren vergelijken', een webshop met veel afbeeldingen van producten op de homepage zal het dan altijd afleggen van een meer textbased site
- Welke browser is gebruikt?
- Is bij de homepage request telkens de cache geleegd? Is er bij elke shop een cookie gezet om een first visit (en dus acceptatie cookie) te voorkomen?
- Door het enorme aanbod van displayadvertenties gericht op de actieprducten zal een groot deel diep op de shop zijn geland; zijn die relevante landingspagina's gemeten?
- Is de trace route bekeken? Dat zijn omwegen die bij grote shops worden aangebracht om bij een hoge piek in traffic de bezoeker om te leiden
Alvast dank voor de moeite om response te geven.
Met vriendelijke groet, Patrick Petersen - AtMost.nl
Hoi Patrick!
Leuk dat je ons artikel gelezen hebt en inhoudelijk hierop reageert!
De metingen die we hebben uitgevoerd zijn erop gericht om de daadwerkelijke klantbeleving in kaart te brengen als het gaat om responstijd. Het gaat hier dus om een geheel geladen en bruikbare website voor de klant.
Ik snap wat je zegt m.b.t. 'appels met peren' vergelijken, een website met veel content, plaatjes of javascripts zal in de regel inderdaad een slechtere responstijd hebben dan een pagina met enkel tekst. Het is aan de ontwerper/webshop om hierin een keuze te maken. Performance en user experience kunnen op dat vlak botsen. Wil je de gebruiker voorzien van rijke content met hoge resolutie afbeeldingen en leuke bewegende onderdelen, dan moet je accepteren dat hier een performance penalty tegenover staat. De metingen brengen deze penalties ook in kaart.
We hebben de metingen verricht met Marvin_ (https://www.computest.nl/application_monitoring/) in combinatie met openrunner( https://github.com/computestdev/Openrunner ) welke firefox gebruikt. Iedere eerste homepage call is een nieuwe gebruiker met lege cache, bij iedere website krijg je dan inderdaad een cookiemelding. Deze melding accepteren we en we laden de homepage opnieuw. Deze laatste meting wordt gebruikt voor het resultaat.
We hebben de homepages en Black Friday-pagina's gemeten van de webshops, dit zijn de meest generieke beschikbare pagina's en daarom goed te vergelijken.
Ik snap je vraag met betrekking tot de traceroute niet helemaal, een traceroute is een diagnosetool die met behulp van het udp of icmp protocol de route richting de destination kan weergeven. Mocht deze route wijzigen, dan 'weten' we dat niet, maar gaat wel mee in de metingen die wij verrichten.
Hopelijk heb ik je vragen hiermee beantwoord, neem gerust contact met mij op als je meer vragen hebt: jderidder@computest.nl
Hallo, dank voor jullie artikel. Zijn er responsverschillen per (type) device gezien? Of is Mobiel tegenwoordig alles overheersend dat dat er niet toe doet?
Leuke vergelijking, maar het laat denk ik in het midden hoe druk sommige websites zijn. Een CoolBlue (waarbij mensen voor de service en prijs echt wat langer willen wachten) zal een bereik hebben waarbij normaliter al veel meer mensen naar toe gaan dan een Zalando (hoeveel bezoekers heeft Zalando normaal, hoeveel waren dit tijdens BlackFriday (BF).
Mijn inziens toont het voor de BF niet echt een meerwaarde, de scores liggen dicht bij elkaar (BF en de week ervoor)
Wat het wel toont is dat sommige winkelketens (AH, CoolBlue) de regel bevestigen dat mensen langer willen wachten dan de genomen 3 seconden uit het onderzoek. Dit sterkt een mogelijk onderzoek naar wanneer mensen de uitzondering accepteren v.s. niet.
Vraag is ook in hoeverre een Albert Heijn echt meer bezoekers trekt door BF deals, het zit mijn inziens (maar dat zou je ook eerst moeten onderzoeken) meer in technologie nog dan echt goedkopere vleeswaren of wasmiddel (denken mensen uberhaupt tijdens BF om extra veel naar een AH website te gaan)
Gezien de scores zo dicht bij elkaar liggen zou je data moeten opvragen van de bedrijven zelf, hoe veel drukker was hun website tijdens BF v.s. de week ervoor. Dan kan je aantallen vergelijken met vergrote (en in sommige gevallen zelfs lagere) responstijden.
Succes met het volgende onderzoek en dank voor het leuke artikel!
Michiel
Had een leuk onderzoek kunnen zijn, maar de meeste partijen zijn op Black Friday zelfs sneller? Dat lijkt meer aan de meetmethode te liggen. Zo is de periode voor black friday veel langer en dus meer meetpunten, wat op black friday waarschijnlijk een grotere afwijking geeft.
Dit onderzoek laat dus vooral goed een vergelijking zien tussen de verschillende aanbieders en daarbij is het natuurlijk opvallend dat CoolBlue zo slecht scoort.
Wellicht nog eens herhalen over een paar maanden om zo periodiek te benchmarken? Is zinvoller dan black friday vergelijken met de week daarvoor, daaruit kunnen we namelijk nu concluderen dat de partijen prima voorbereid waren op Black Friday of niet echt een piek in bezoekers hebben gezien.
Hallo Ivo Temmink,
Bedankt voor het lezen. Goede terechte vraag! De performance-metingen voor mobiele applicaties hebben wij voor dit onderzoek buiten beschouwing gelaten. We hebben ons middels de tool Marvin_ gericht op desktopomgevingen met een vaste internetaansluiting om zo vanuit een controleerbare omgeving, met zo min mogelijk externe factoren zoals 3G/4G, de consument na te bootsen voor deze 25 webshops. Mocht je nog vragen hebben kan je mij ook persoonlijk benaderen: mvantoledo@computest.nl
Groet, Mike
Hoi Marcel, Het klopt dat er een aantal webshops qua responstijden iets beter presteerden tijdens Black Friday dan gezien over de hele week. De verschillen zijn echter klein, hieruit kan je inderdaad concluderen dat de webshops goed voorbereid waren voor de Black Friday load of dat de load in ieder geval niet hoog genoeg was om ergens een bottleneck te triggeren en de responstijd te verhogen. Door de aanbiedingen over de hele week te verspreiden zal de load ook meer verdeeld zijn geweest. Deze prestaties verwacht je eigenlijk ook gewoon van goed draaiende websites. Er is altijd wat fluctuatie in responstijd wat ervoor kan zorgen dat de ene dag net wat hoger of lager uitkomt dan de andere dag, daar ontkom je niet aan.
Voor het artikel zou het leuk geweest zijn als de responstijden hoger waren tijdens Black Friday, maar we zijn blij verrast dat de webshops niet slechter presteerden tijdens deze dag. Load zou in die zin ook zeker niet 1 op 1 moeten zorgen voor hogere responstijd, sterker nog in sommige gevallen kan hogere load zelfs zorgen voor een betere responstijd.
Als je het interessant vindt om jezelf met spelers uit de twinkle-100 te vergelijken of met wellicht andere concurrentie dan kan dat hier: https://measure.works/benchmark/benchmarktrial.php
De onderligger hiervan is ook gebruikt voor de performance scores in de Twinkle-100. Het enige verschil is dat deze scores niet standaard handmatig gecontroleerd worden. Maar in de meeste gevallen er vrijwel geen afwijking is.