E-commerce Newsupdate Week 30

e-commerce-update-week30
Kennisdeling is een van de belangrijkste kernwaarden van Guapa. We volgen de trends en ontwikkelingen in de snel veranderende e-commerce markt en zetten deze voor u op een rijtje in onze wekelijkse nieuwsupdate.

Laadsnelheid webshop steeds trager

Afgelopen jaar zijn de laadtijden van veel grote e-commerce sites flink opgelopen. Het duurt steeds langer voordat de pagina’s helemaal geladen zijn volgens een onderzoek van Radware. Dit zou voornamelijk komen doordat pagina’s steeds zwaarder worden. De grootste boosdoener wat de laadtijd betreft zijn de afbeeldingen. Bij de top 100 grootste Amerikaanse retail website is de laadtijd gemiddeld met 49% toegenomen. Slechts 14 van deze webshops hadden binnen 3 seconden hun belangrijkste content geladen. Bij 17 sites lag de interactietijd zelfs boven de 10 seconden.

In de winkelstraat met PayPal betalen

Paypal-betalen-guapa-media
Vanaf afgelopen woensdag kan er in bijna 1500 winkels, restaurants en bioscopen in Nederland betaald worden met PayPal. PayPal maakt het mogelijk om met een app op een smartphone te betalen. Het is dan niet meer noodzakelijk geld of een pinpas op zak te hebben. Bij deelnemende horeca zaken kunnen klanten zelfs via een virtuele menukaart in de app hun bestelling plaatsen. Paypal werkt voor het project samen met MyOrder, een dochter van de Rabobank die al langer betalen met de smartphone aanbiedt. PayPal is hard op weg een van de grootste payment service providers te worden. Nederland is na het Verenigd Koninkrijk en Frankrijk het derde land in Europa waar Paypal de mobiele betaaldienst via de ‘Check-in’ aanbiedt.

Zie ginds komt de stoomboot

Het is natuurlijk nog hoogzomer maar over een maand liggen de eerste zakken pepernoten al in de schappen. Ook voor webwinkeliers is het verstandig om al eens na te denken over de strategie voor de drukke decembermaand. In 2013 groeide de gemiddelde omzet van webwinkels in december met 20 procent. Helaas voor de consumenten kwam ruim negen procent van de pakketjes niet op tijd bij hun binnen. Het is aan te raden om nu alvast de voorbereidingen te starten in uw webwinkel. Kleine dingen, zoals de mogelijkheid om producten (in stijl) te laten verpakken of een gepersonaliseerd bedankje achteraf, maken al een heel verschil. Onderschat vooral niet het belang van de verwachting van uw klant, zeker met betrekking tot de gecommuniceerde levertijden in deze tijd. Creëer een prettige en organische shopervaring voor uw (potentiële) klant. Jasper Scheffer van Klarna geeft negen tips om u op tijd klaar te stomen voor de grote stroom sinterklaasfans.

RedLaser maakt realtime prijzen vergelijken op google-glass mogelijk

Google-glass-ebay-guapa-media
EBay heeft een app ontwikkeld voor de Google-glass waarmee gebruikers prijzen kunnen vergelijken. Gebruikers kunnen met hun bril barcodes scannen en de prijs in de app vergelijken met andere on- en offline aanbieders. Bij de woorden ‘Ok glass, scan a barcode’ of het bekijken van de barcode met de bril vergelijkt de RedLaser-app de prijs van het product. RedLaser bestaat al langer en vergelijkt on- en offline prijzen. In 2010 zijn ze overgenomen door eBay zodat zij de barcodescanner ook kunnen toevoegen aan hun eigen apps. Nu maakt eBay de een nieuwe stap door samen te werken met concurrent Google in Glass.

Lek in MailPoet maakt tienduizenden websites kwetsbaar

Eerder deze maand kwam er een lek in MailPoet naar voren. Inmiddels zijn al tienduizenden websites slachtoffer geworden van het misbruik van het lek. MailPoet is een populaire plugin op het eveneens populaire content management systeem (CMS) WordPress. Eenmaal binnen op een WordPress site via MailPoet, is het soms ook mogelijk een achterdeur te creëren op andere sites die op dezelfde fysieke server worden gehost, maar een ander CMS gebruiken, zoals Joomla of Magento. Een snelle upgrade lijkt de enige oplossing. Iedere WordPress-site eigenaar met MailPoet doet er goed aan de nieuwste versie (2.6.7) van de plugin te installeren.

Website laadsnelheid optimaliseren met prerendering & prefetching

Prerendering-Prefetching-Guapa

“High performance web sites lead to higher visitor engagement, retention and conversions” – Google.

Een positieve gebruikerservaring is een van de bepalende factoren voor het succes van uw website. De gebruikerservaring verbetert door de laadsnelheid van uw website te optimaliseren. Dit kan met prerenderen en prefetchen, twee technieken die ervoor zorgen dat een (complete) pagina al is geladen voordat de bezoeker op de link heeft geklikt. Enige terughoudendheid is hierbij geboden. Het succesvol implementeren van prefetchen en prerenderen is afhankelijk van een evenwichtige toepassing. Gebruik het niet over uw volledige website, want dan krijgt u het tegenovergestelde effect.

Hieronder staat uitgelegd wanneer u dit het beste kan gebruiken, hoe u het kan implementeren en waar u op moet letten.

Wanneer prerenderen/ prefetchen?

Het idee is dat u pagina’s laat prerenderen en prefetchen waarvan u zeker weet dat uw bezoeker daar naartoe gaat vanuit de pagina die ze bekijken op uw website. Via Google Analytics of een soortgelijke tool kunt u erachter komen hoe bezoekers meestal door uw website navigeren. Zo kunt u zien welke pagina meestal de volgende pagina is (eerste interactie) waar een bezoeker naartoe gaat. Die pagina kunt u dan vervolgens laten prerenderen en prefetchen.

Google-Analytics-Guapa-Media
Bron: Google Analytics over guapa.nl

Ook kan het handig zijn om JavaScripts, afbeeldingen en CSS-bestanden die vaker voorkomen op de website te laten prefetchen en prerenderen.

Prerenderen

Prerenderen kan eenvoudig gedaan worden door een linktag te plaatsen binnen een < head > -gedeelte:
Prerender-code-Guapa-Media

Hoe werkt prerenderen?

Stel dat de meerderheid van uw bezoekers vanuit uw homepage naar de FAQ gaat (eerste interactie). Dan zou u dus uw FAQ willen laten prerenderen. U plaatst een linktag op de homepage van uw website. In de href van de linktag zet u dan de URL naar de FAQ. Als een gebruiker dan op uw homepage komt met Google Chrome, dan suggereert Chrome dat het de FAQ moet prerenderen via de linktag. Het woord “suggereert” wordt gebruikt, omdat er nog factoren bestaan die er voor kunnen zorgen of een pagina wel of niet wordt geprerenderd.

Als een pagina wordt geprerenderd, dan wordt deze pagina geladen, zoals elke andere pagina, maar dit gebeurd alvast op de achtergrond. Dus zodra een bezoeker eindelijk klikt op FAQ vanuit de homepage, boem. De pagina was al geladen en wordt dus direct aan de bezoeker getoond.

In onderstaand YouTube-video legt Google uit hoe Instant Pages werkt met hun prerendering-technologie en laat Google ook zien wat het verschil is tussen prerenderen en niet prerenderen:

Magento prerender extensie

Voor Magento is er een extensie gebouwd met interessante algoritmes:

Guessing Mode:

  • Per CMS pagina kan er een link opgegeven worden die geprerenderd moet worden.
  • Op een categoriepagina wordt de volgende pagina geprerenderd.

Based Log Mode:

  • De meest bezochte volgende pagina wordt geprerenderd.

Deze algoritmes geven een goed beeld wat er voor Magento shops zou kunnen worden geprerenderd.

Prefetchen

Prefetchen kan net zo eenvoudig gedaan worden als prerenderen, maar prefetchen gebruikt een andere linkrelatie:

Prefetchen-Guapa-Media

Hoe werkt prefetchen?

Prefetchen werkt net als prerenderen, alleen wordt niet de complete pagina geladen, maar alleen het specifieke onderdeel dat wordt aangegeven in de linktag. Prefetchen gebeurd pas zodra de browser alles al heeft geladen op de huidige pagina en daarna dus niets meer te doen heeft (idle). Prefetchen werkt ook met https-inhoud, iets wat met prerenderen helaas niet kan.

Handig om te weten

  • Prefetchen en prerenderen zorgen er wel voor dat u al “pageviews” krijgt zonder dat u daadwerkelijk naar de desbetreffende pagina gaat. Dit kan leiden tot incorrecte websitestatistieken (bijvoorbeeld: welke pagina’s worden het meest bezocht), maar er zijn wel manieren om dit te kunnen omzeilen.
  • Prefetchen en prerenderen kan bandbreedte opslokken, vooral bij browsers op smartphones die niet op WiFi verbonden zijn. Zoals eerder is vermeld, is het dus handig om effectief te kunnen prerenderen en prefetchen.
  • Naar de volgende pagina gaan tijdens het prerenderen of prefetchen zorgt ervoor dat deze processen geannuleerd worden, waardoor u weinig tot niets hebt gemerkt van het prerenderen of prefetchen. Ook hier moet er dus nagedacht worden om prefetchen en prerenderen zo effectief mogelijk toe te passen. Weet bijvoorbeeld hoe lang een bezoeker op een pagina blijft, voordat het door gaat naar de volgende of maak gebruik van de http accelerator Varnish.
  • Prefetchen zorgt er alleen voor dat middelen worden gecached, terwijl prerenderen een complete pagina laadt. Dit betekent dat een geprerenderde pagina direct getoond wordt, wanneer uw bezoeker er naartoe gaat, terwijl een geprefetched pagina nog middelen moet laden die eventueel niet geprefetched zijn.
  • Prefetchen en prerenderen werken niet met sessies, dus onderdelen als winkelmanden kunnen helaas niet worden geprerenderd of geprefetched.
  • U hoeft niet perse alleen de volgende pagina te laten prerenderen en prefetchen vanuit bijvoorbeeld de homepage. Google Analytics laat ook zien wat de tweede interactie is vanuit de eerste interactie. Pagina van de tweede interactie zou dan kunnen worden geprefetched en geprerenderd kunnen worden vanuit de eerste interactie.
  • Prefetchen werkt niet met Google Chrome, terwijl prerenderen niet werkt met Mozilla Firefox (Internet Explorer ondersteunt vanaf versie 11 beide manieren). Het is daarom aan te raden beiden manieren in te zetten voor uw website.

Conclusie

Met behulp van bijvoorbeeld Google Analytics of de Magento prerender extensie kunt u erachter komen welke pagina’s handig zijn om te prerenderen of prefetchen.

Heeft u pagina’s, zoals volgende of vorige op de zoekresultaten of categoriepagina’s en middelen, zoals CSS, JavaScript, etc. die u voor uw bezoekers sneller wilt laten tonen? Dan kan prefetchen en prerenderen zeker uitkomst bieden!

Bij Guapa kunnen we u hiermee helpen om advies te geven en eventueel het implementeren van prerenderen en prefetchen.

Waarom een webshop snel moet laden?

page_speed

[intro]Een website of een webshop moet snel laden om technische redenen en omdat je een blije bezoeker wilt. Milliseconden kunnen daarin al een verschil maken. Het versnellen van de laadtijd is dus één van de belangrijkste onderdelen om je webshop beter te laten presteren. Ik laat je zien waarom een site snel moet laden en hoe je de snelheid van jouw website kunt meten.[/intro]

1. Google beloont een hogere snelheid

Sinds de Panda update kijkt Google ook naar de snelheid van je website. Is de website snel, dan krijg je bonuspunten. Bonuspunten zorgen voor een betere positie in de zoekresultaten. Is je website traag of zelfs heel traag? Dan kom je lager te staan of kom je zelfs op een blacklist, waardoor je niet te zien bent in de zoekresultaten.

2. Servers draaien beter

Snellere websites zijn minder belastend voor een server. Wanneer een server zwaarder wordt belast zullen alle diensten, zoals email, een database, de website en misschien zelfs een WMS of kassasysteem, trager worden. Een te zwaar belaste server kan zelfs offline raken waardoor mensen niet meer bij de website of webshop kunnen komen. Om een zwaarbelaste server weer snel te laten draaien, moet deze ge-upgradet worden. Dit betekent vaak hogere kosten.

3. Ergernissen bij je bezoeker voorkomen

Jouw bezoeker is behoorlijk verwend en wil een snelle website. Is je website te traag, dan zal de bezoeker hem snel wegklikken en waarschijnlijk naar een andere webshop gaan. Het is wat dat betreft net een café. Als mensen te lang moeten wachten op hun drankje, gaan ze naar een ander café en komen waarschijnlijk niet terug.

4. Een snelle webshop genereert meer omzet

Tijd is geld! Het gevolg van een trage website kan leiden tot minder bezoekers, minder goede zoekresultaten en uiteindelijk minder omzet. Een onderzoek bij verschillende websites gaf dat heel concreet in omzetcijfers aan. Hier een aantal feiten die hier uit zijn gekomen:

  • De snelheid van Amazon nam met 0,1 seconde af, waardoor de omzet met 1% daalde.
  • Yahoo kreeg 9% meer bezoekers bij elke 0,4 seconde winst in laadtijd
  • Shopzilla verlaagde de laadtijd van 6 naar 1,2 seconde. Hierdoor nam de omzet toe met 12% en het aantal pageviews met 25%.

Meten is weten

Door de jaren heen zijn er meerdere tools ontwikkeld waarmee je de snelheid van je website kunt testen:

Verbeteren van de laadtijd

Nu wil je natuurlijk aan de slag om de laadtijd van je site te verbeteren. Dat kan op verschillende manieren. CDN, Gzip, caching, Varnish, compressing, sprites zijn een aantal termen die je vaak langs ziet komen en je misschien nu nog niet zoveel zeggen. In komende artikelen zal ik een aantal methodes behandelen waarmee je de laadtijd kunt verbeteren. Tot snel!

P.S. Sta je echt te trappelen en kun je niet wachten? Bel ons dan! Dan gaan we snel aan de slag. Neem ook een kijkje bij onze Magento hosting dienst.

Magento Enterprise en full page caching

Magento Caching snelheid[intro]Sinds kort is Guapa E-commerce een Magento Silver Partner. Eén van de voordelen die daarbij horen is dat je een Magento Enterprise licentie krijgt voor interne doeleinden zoals testen en development. De Magento Enterprise editie is uitgebreider dan de Community editie. Een interessante optie binnen Magento Enterprise is de full page caching. We namen de proef op de som en hebben de verschillen inzichtelijk gemaakt. Ik ben onder de indruk van het resultaat![/intro]

Caching

In de Community editie heb je een aantal standaard caching opties (caching is het vooraf inladen van content, waardoor de pagina sneller geladen kan worden). Daarnaast kun je ook nog gebruik maken van APC en Memcached (dit zijn twee caching opties die je kunt gebruiken mits deze staan geïnstalleerd op de server). Als je dat allemaal ook nog combineert geoptimaliseerde configuraties van Apache en MySQL én snelle hardware, is het mogelijk om erg mooie resultaten neer te zetten. Hierbij ontbreekt echter de mogelijkheid voor full page caching. Er moeten dan alsnog items worden ingeladen vanuit bijvoorbeeld de database.

Bij de Enterprise variant is het mogelijk om full page caching te gebruiken. Hiermee worden, zoals de naam eigenlijk ook al zegt, volledige pagina’s gecached. Een erg interessante optie, maar wat doet dit met de laadtijden van de homepage en een willekeurige productpagina? Met Pingdom en “ab” (Apache Benchmarking) heb ik dat eens nader onderzocht.

Testomgeving

Op één van de shared hosting omgevingen van onze hosting dienst Magento Hosting heb ik een Magento Community editie (versie 1.7.0.2) en een Enterprise editie (versie 1.9.1.1)  geïnstalleerd. Onderaan dit artikel staan de technische specs voor de technische specificaties van deze server. Beide Magento installaties zijn gevuld met de bijhorende sample content. Afbeeldingen, javascripts, etc. zijn verder niet geoptimaliseerd. De Community versie gebruikt naast de ingebouwde caching opties ook Memcached, terwijl de Enterprise enkel de ingebouwde cache opties van Magento gebruikt. Elke test is meerdere keren gedraaid, waarna een gemiddelde is berekend.

Bij elke ab-test werd een aantal requests opgegeven en een aantal gelijktijdige verbindingen. Hiermee geef je aan dat bijvoorbeeld honderd gelijktijdige connecties, vijfhonderd keer een bepaalde pagina moeten laden. Vervolgens krijg je als resultaat het aantal requests per seconde, de laadtijd van de pagina en natuurlijk hoelang de test duurde.

Pingdom

Na verschillende testen is de gemiddelde laadtijd van de Community homepage: 516,25 ms (0,51 seconden). Het aantal requests was 48 en de page size is 335 kB.


De laadtijd van de Enterprise homepage met full page caching  is: 440 ms (0,44 seconden). Het aantal requests was 39 en de page size is 314.

De resultaten van een willekeurige productpagina zijn: Community editie:  763,5 ms (07,6 seconden). Het aantal requests hier was 58 en de page size is 338 kB.

Enterprise editie:  293 ms (0,29 seconden). Het aantal requests hier was 50 en de page size is 235 kB.

Apache Benchmark

Met een ab-test zijn de verschillen tussen beide installaties helemaal goed te zien. Alle tijden in de grafieken zijn in miliseconden. De eerste tabel zijn de resultaten van de homepage van de Community, Enterprise zonder full page caching en Enterprise met full page caching. De tweede tabel geeft de resultaten weer van een productpagina van de Community versie en de Enterprise variant (met en zonder full page caching). In beide gevallen geldt: hoe lager, hoe beter.

Conclusie

Wow! Wat een geweldige resultaten. Voordat ik begon met het testen had ik natuurlijk wel gedacht dat full page caching een stuk sneller zou zijn, maar dit is wel een erg groot verschil. Wanneer ik de kijk naar de load van de server, is deze bij full page caching aanzienlijk lager. Wat natuurlijk ook wel logisch is, aangezien er veel minder database requests gedaan worden.

Technische specificaties:
De shared server is uitgerust met een Intel Xeon Quad-Core processor met 8 threads (2.4 GHz) en 16 GB RAM. De harde schijven zijn 4 SSD’s in een RAID-10 opstelling geplaatst.