Laadtijd, ranking en kostenbesparing: een praktijkcase
Dit is een guestpost van MacSeth.
In het SEO-wereldje hoor je van alles over het optimaliseren van de website laadtijden en waarom je dat zou moeten doen.
Dat gaan we hier niet herhalen. Wat we wel hebben is een praktijkcase: snellere websites kosten minder geld!
Het antwoord op de vraag of een eigenaar van een website nu wel of niet moet investeren in een betere techniek om zo de snelheid te verbeteren, is een volmondig JA!
Alleen moeten de organische resultaten van een zoekmachine niet als hoofdreden voor die investering worden aangevoerd.
Verhoging Snelheid = verbetering gebruikerservaring
De reden die Google aanvoert om snelheid als een maatstaf te gebruiken, is de "gebruikerservaring". Google redeneert (terecht) dat een snellere website een bezoeker een betere ervaring kan opleveren... immers... niemand heeft zin om te wachten op een website die meer dan 5 seconden duurt om in te laden.Google hanteert dit principe overigens ook al een lange tijd bij het bepalen van de quality score in Adwords (en raad eens wat een slomere laadtijd van een landingpage doet met de CPC in uw campagne?).
Verhoging Snelheid = minder infrastructuur kosten
Ik exploiteer een grote website beoordelingssite met op dit moment rond de 700.000 bezoekers per maand. Toen we de techniek achter de website recentelijk eens goed onder de loep namen resulteerde dit in een zes weken durende stijging waardoor het aantal bezoekers de pan uit begon te rijzen. Nu heeft die stijging overigens wel meer redenen maar een groot deel kan verklaard worden door de verbeterde snelheid van de website.De DB-server had het met deze groeispurt erg lastig, vooral op piekuren. Dit resulteerde op den duur ook in een stijging van de laadtijd. Je kunt je voorstellen dat dit gevolgen had voor de eerder genoemde gebruikerservaring. Uitgaande van bovenstaande onderzochten wij of het wellicht niet verstandig was om de infrastructuur aan te pakken. Immers, we hadden de techniek al zwaar verbeterd, gebruikten YSlow en andere tools totdat we geen optimalisatiepuntjes meer konden ontdekken dus enige optie, dachten wij, was het aankopen van extra servers.
Echter... we kwamen er ook achter dat het aantal queries dusdanig was dat de CPU soms tot wel 95% werd belast. En nu komt de grap. Door de MySQL-queries eens flink onder de loep te nemen en deze te optimaliseren bereikten we een performance verbetering van 300%. Met andere woorden: met dezelfde serveropstelling kunnen we tot vier maal zoveel verkeer behappen dan we in eerste instantie dachten. We hadden dus geen nieuwe DB server nodig (dus geen abbonnementskosten, SLA's etc).
En omdat plaatjes meer zeggen dan 1000 woorden..:
Ook is de snelheid weer flink toegenomen tot een nieuw record. Een investering in snelheid heeft ons dus NAAST een flinke performance verbetering ook een kostenbesparing opgeleverd. Je kunt je voorstellen wat dergelijke verbeteringen bij nog grotere websites kan betekenen.
En ja... het verbetert OOK de organische resultaten.
Verbetert het optimaliseren op snelheid van je website ook je resultaten binnen Google's organische resultaten? Ja... al is het verschil minimaal.Er circuleren verhalen van webmasters die beweren dat het verschil meer dan één procent is tov van het vorige algoritme (en dus zwaarder weegt dan Google beweert) maar die bewering ondersteun ik niet, simpelweg omdat er niet een grote hand tussen te krijgen is. Echter... of het verschil nu maar 0.5% of 1% is, ieder positief verschil is er één. Vergeet immers niet dat website optimalisatie, vooral bij grotere websites of in competitieve markten, een optelsom is van veel factoren.
Conclusie
Het niet optimaliseren op snelheid betekent simpelweg dat je (iedere dag) geld door de plee spoelt op vele fronten. Niet optimaliseren op snelheid is dus absoluut een gemiste kans. Aan de ene kant kost het je kostbare bezoekers en daarmee potentiele afnemers van diensten/producten.En wees eerlijk. Wat heb je aan een hoge positie in Google als de bezoeker die via Google je website binnenkomt, deze weer verlaat doordat je website traag inlaadt?
Zoals eerder aangegeven kost het je onnodig meer geld bij advertentiekanalen als Google Adwords en het levert aan de infrastructuurkant enorme kostenbesparingen op. Je hebt (veel) minder infrastructuur nodig en kunt het geld wat je bespaart, steken in belangrijkere zaken, namelijk die goedkopere adwords campagnes.
En ja... het verbetert tevens je positie in de organische resultaten in Google (een beetje)
De definitieve conclusie zou moeten zijn dat iedere webmaster of ondernemer al na de bovenste twee redenen direct bezig moeten zijn om de snelheid van hun website flink aan te pakken. (verspilde) tijd is geld!
Interessant?
Lees dan ook eens meer artikelen over ...
Reacties
door monchito, 2010 05 04
Hoi Ralk, ik kan niet voor Seth spreken, maar heb er zelf enige ervaring mee. MySQL optimaliseren kan op allerlei manieren, maar waar je bijvoorbeeld kunt beginnen is inderdaad per query kijken of het niet sneller kan, bijvoorbeeld door indices te gebruiken, door juist wel of niet te normaliseren (database structuur, plat is vaak sneller dan relationeel) en last but not least: het juiste datatype gebruiken (geen varchars bij ints), geen duplicaten, evt data aggreren, etc etc
door Fili Wiese, 2010 05 04
Leuke praktijkcase! Front-end optimalisatie kan zeker helpen je infrastructuur en verkeerskosten omlaag te brengen.@Ralf: één optie om je MySQL queries te optimaliseren kan door het aantal queries dat wordt uitgevoerd per pagina te verminderen en met het DESCRIBE of EXPLAIN command je queries experimenteren.
door monchito, 2010 05 04
Een absolute klassieker in dit verband is de case die Alistapart ooit maakte voor CSS/HTML optimalisatie van Slashdot.org. Hun conclusie: minimaal 3650 dollar per jaar minder hostingkosten, alleen door door betere HTML/CSS, zie http://www.alistapart.com/articles/slashdot/
door Thomas Lenting, 2010 05 10
Bij MySQL kun je ook de slow log aanzetten. Deze logt dan de queries die langer dan de opgegeven tijdsduur in beslag nemen; erg handig voor het 'performance-debuggen' van querys. Daarnaast is het gebruik van indexes op kolommen die gebruikt worden in o.a. where-statements erg verdienstelijk.Er zijn dbms-en die een betere performance hebben als MySQL; maar verbetering begint toch bij het databaseontwerp & queryontwerp.
door monchito, 2010 05 11
Hoi Thomas, heb nog wat nagezocht over slow log: hier vind je een mooi overzicht van scripts die daarvoor gebruikt kunnen worden: http://frey-it.com/?p=13
door Thomas, 2010 05 14
Ha Monchito,En trouwens niet te vergeten wat misschien nog wel het beste is: niet onnodig resources gebruiken & berekeningen uitvoeren. Ook wel bekend als 'cachen'.Ik ga vanavond bier cachen ;-)Thomas
door Anouk Jansen, 2010 06 28
Ik denk dat dit grotendeels de verantwoordelijkheid is van de developer en front-end engineer, niet de SEO.Bij Yahoo werd het dan ook in het developer centre aangeboden (Yslow). Google Pagespeed Plug-in is dan ook echt iets wat front-end engineers moeten checken. De database optimaliseren is niet zozeer een SEO werkje.Je kan zoiezo lastig direct SEO effect aantonen. Tuurlijk verlaagt het indirect de bouncerates en verhoogt het de usability.En die ene procent komt niet van webmasters, maar van Google zelf:http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html" While site speed is a new signal, it doesn't carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal in our implementation and the signal for site speed only applies for visitors searching in English on Google.com at this point. "Ik hoop verder dat Google in de toekomst ook W3C validatie, accessibility en usability opneemt als ranking factor. Dit zijn dingen die je wat lastiger aan kunt kopen, zoals een snellere server.
door Easy Website Optimalisatie, 2010 06 30
Ik denk dat de SEO wel verantwoordelijk is om dit door te rapporteren naar de webmaster, en eventueel aan te geven waar dit verbeterd kan worden.groeten,Stijn Driessen
Rants/opmerkingen/suggesties?
Wat is MONLOG
Sinds 2002 is MONLOG het weblog van Ramon Eijkemans, freelance SEO-gun for hire.
Dit weblog bevat how-to's, mijmeringen, soms wat humor. Het gaat vrijwel altijd over SEO. Ik herhaal geen nieuws. Het doel van dit weblog is om jou van praktische en doordachte informatie te voorzien!
En dan nog dit: guestpostings zijn welkom! Mail me als je je ei kwijt wil op dit goed rankende podium.
Laatste comments
@Aartjan: ik heb hetzelfde met 'lekker kontje' :)...
25.11.2011 door Ramon Eijkemans op Ranken op Banaan
Bij mij is 'banaan' toevallig al jaren het zoekwoord waar ik...
23.11.2011 door Aartjan van Erkel op Ranken op Banaan
Gewoon maken waar vraag naar is. Dat is zo oud als de weg...
22.11.2011 door Thomas op Ranken op Banaan
Een banaan natuurlijk :)
09.11.2011 door Ramon Eijkemans op Ranken op Banaan
In welk tineu zien we jou terug binnenkort?
09.11.2011 door Emiel op Ranken op Banaan
@Simme @Navin proost! :)
07.09.2011 door Ramon Eijkemans op Vakantie!
Zo maak je mij wel erg jaloers :)
05.09.2011 door Navin Poeran op Vakantie!
12 bier geeft plezier.en veel succes gewenst tijdens de tw...
31.08.2011 door simme op Vakantie!
@Willem: ik denk op de manier zoals ik in dit artikel...
20.08.2011 door Ramon Eijkemans op Faceted search & SEO: vloek of zegen?
Goed en interessant artikel. Wat mij vooral bezighoudt, is...
20.08.2011 door Willem Hoekstra op Faceted search & SEO: vloek of zegen?
door Ralf, 2010 05 04
Zeer interessant artikel. Hoe hebben jullie het aangepakt om de mysql queries te optimaliseren. Bepaalde tools voor gebruikt of iedere query nagelopen en bekeken of het beter/sneller kon?