Breng snelheid in je site voor gebruikers en zoekmachines

Het is een hot onderwerp: de snelheid van je site wordt steeds belangrijker. Bezoekers hebben snelle sites altijd al prettig gevonden en Google gaat het daarom nu ook meenemen in het bepalen van je ranking. Mede hierom ben ik eens flink bezig gegaan met het optimaliseren van mijn site. De genomen stappen en de resultaten wil ik graag met jullie delen.

Welk stappen heb ik genomen

Om de snelheid van het laden van mijn site te versnellen heb ik de software (WordPress), de server, de broncode (HTML, CSS en Javascript), de plaatjes aangepakt. Elke verbetering heb ik vervolgens gemeten met de tools Google Page Speed en Yahoo! YSlow, beide weer aanvullingen op de populaire developers tool Firebug. Een hoop kleinere wijzigingen zal ik hier niet behandelen, maar de echte impact-makers zal ik zeker noemen.

Caching aangezet
De eerste stap was het implementeren van de W3 Total Cache plugin voor WordPress. Deze zorgt er voor dat alle pagina's in mijn site van te voren alvast in elkaar gedraaid worden tot kant en klare HTML. Wanneer een bezoeker dan een pagina opvraagt kan direct de HTML geserveerd worden en hoeven er dus geen PHP of enkele database verzoeken aan te pas te komen. Extra voordeel is dat de broncodes van alle javascript, CSS en HTML ontdaan worden van onnodige elementen als spaties en commentaren.
De 2de stap in het caching verhaal is het aanzetten van zogenaamde caching headers. Hiermee vertel je aan een browser dat bijvoorbeeld een bepaald plaatje niet elk bezoek opnieuw opgehaald hoeft te worden omdat hij toch niet veranderd. Zo blijven de plaatjes in de cache van de bezoeker staan en dat scheelt laadtijd. Op mijn type server (Apache) kon dat simpel door de volgende regels op te nemen in het .htaccess bestand:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault A300
ExpiresByType image/x-icon A4838400
ExpiresByType application/x-javascript A4838400
ExpiresByType text/css A4838400
ExpiresByType image/gif A4838400
ExpiresByType image/png A4838400
ExpiresByType image/x-icon A4838400
ExpiresByType image/ico A4838400
ExpiresByType image/jpeg A4838400
ExpiresByType text/plain A4838400
ExpiresByType application/x-shockwave-flash A4838400
ExpiresByType video/x-flv A4838400
ExpiresByType application/pdf A4838400
ExpiresByType text/html A300
</IfModule>

Per type bestand wordt een houdbaarheidsdatum meegegeven. A4838400 staat gelijk aan 56 dagen (4838400 secondes) vanaf het moment dat het bestand opgevraagd wordt (A).

GZip
Wat veel tijd kan schelen is het inpakken van alles wat je over de kabel verstuurd. Bijna elke server beschikt wel over een module die dit kan regelen. De GZip module is wellicht de meest bekende. Zodra een HTML pagina geserveerd wordt zal hij eerst ingepakt worden, en na ontvangst wordt hij weer uitgepakt. Het werkt zo'n beetje hetzelfde als het zippen van een bestand op je eigen pc. Het is een beetje afhankelijk van je hosting pakket of deze module wel of niet geïnstalleerd is.

CSS Sprites

Een mooie truc die ook vaak bij games gebruikt wordt zijn de zogenaamde CSS Sprites. Dat zijn plaatjes die bestaan uit een aantal (tientallen tot honderden) andere plaatjes. Om even duidelijk te maken wat ik bedoel kun je het beste kijken naar de sprite die ik voor deze site gemaakt heb. Je ziet in dat plaatje precies 10 plaatjes die daarin samengevoegd zijn. Met behulp van handige CSS positionering plaats ik deze sprite zo dat alleen het gewenste deel zichtbaar is op de juiste plek.
Wat is dan het voordeel? In plaats van 10 HTTP connecties hoeft er nu maar 1 gemaakt te worden die het plaatje binnenhaalt. Dat scheelt tijd en resources die door andere elementen gebruikt kunnen worden. Het plaatje staat vervolgens in het geheugen van de PC en kan zo vaak gebruikt worden als dat nodig is. Het 2de voordeel is simpelweg het aantal kb's. Deze 10 plaatjes afzonderlijk waren in totaal 29.882 bytes groot. De sprite is maar 15.812 bytes. Dat betekent een besparing van 48%.

Verkleinen van diverse afbeeldingen
Ik heb niet simpelweg alle plaatjes in mijn site geopend en als .JPG opgeslagen met een kwaliteit van 5%, dat zou te simpel zijn. Met behoud van kwaliteit is het mogelijk om bijna alle bestanden te verkleinen. Dat kan omdat een heleboel grafische formaten allerlei extra zaken in een bestand opslaan die eenvoudig verwijderd kunnen worden. Check deze pagina voor een aantal handige tools.

Opruimen
De meeste simpele manier van allemaal: opruimen. Is alles wat je op je site toont echt nodig? Kan er niet het een en ander weg? Of zou je het externe logo niet zelf kunnen hosten? Een extern iets op je site kan het laden enorm vertragen. Elk ander domein dat nodig is bij het laden van je site betekent ook een extra DNS aanroep. Gebruik deze externe zaken dus met mate.
Op deze site stond een grapje: als je over mijn neus heen ging kreeg je een tekstballon met een mededeling. Geinig, maar totaal overbodig. Er moest extra HTML, CSS, Javascript en een plaatje ingeladen worden. Dit 'grapje' is nu dus ook verleden tijd.

Asynchrone Google Analytics code
Google lanceerde onlangs een nieuwe asynchronous meetcode die een aantal mooie voordelen bevat. Hij kan bovenin de broncode geplaatst worden omdat het script dusdanig geladen wordt dat het laden van de site hier niet op hoeft te wachten. En zodra het script binnen is vindt direct de meting plaats. Door de bank genomen zal de meting nu eerder plaatsvinden dan wanneer de meetcode helemaal onderaan je pagina had gestaan, en daardoor zul je meer pageviews en bezoekers gaan meten.

En wat zijn de resultaten

In de kerstvakantie ben ik hier mee begonnen en heb in de loop van januari nog enkele stappen genomen in het optimaliseren van de site. Ik kan op dit moment nog niet zeggen of de wijzigingen effect hebben op mijn SEO rankings, maar het bezoek vanuit die hoek is wel harder gestegen dan de rest.

Wat zeggen de WebMaster Tools
De Google Webmaster Tools heeft 2 mooie grafieken in de rapportage zitten. De eerste laat zien hoe lang de Google Spider doet over het downloaden van de pagina's in je site:

Je kunt goed zien dat begin januari de downloadsnelheid van gemiddeld 1,5 naar 1 seconde is gegaan. Dat heeft deels te maken met de instellingen die ik gemaakt heb. Maar daarnaast is ook de snelheid van de hosting partij een belangrijke factor waar je wat moeilijker invloed (verhuizen) op kunt uitoefenen.

En de 2de grafiek laat zien hoe lang vervolgens het renderen (het samenbrengen van de JS, CSS, HTML en plaatjes om daar een werkende pagina van te maken) van die pagina duurt:

Een mooie daling in de loop van de tijd. De berg zo rond half december werd veroorzaakt door een externe toolbar (Wibiya) die ik even getest heb. Helaas wogen de voordelen niet op tegen de nadelen. Buiten die berg om loopt de daling mooi door tot een 2,9 secondes per pagina gemeten op 22 januari.

Google Analytics
Er zijn een aantal wijzigingen te zien in Google Analytics. Maar of de veranderingen te wijten zijn aan de nieuwe plaats van de asynchrone code (bovenaan de broncode) of de laadsnelheid van de site is moeilijk te zeggen. Beide factoren tezamen leveren dit als resultaat:

Het organische verkeer laat de normale kerstdip zien en stijgt vervolgens flink zonder aanwijsbare reden. Ik had al een tijdje niet meer geblogd en ook niet aan linkbuilding oid gedaan. Toch heb ik vaker dit soort stijgingen in januari gezien en durf er dus niet keihard conclusies aan te verbinden.

Een andere duidelijk stijging is te zien in het weigeringspercentage. Dat was voorheen altijd onder de 70% en is nu opeens rond de 73% constant. Dat betekent dat bezoekers die voorheen al wegklikten zonder dat de Google Analytics code geladen was nu wel gemeten worden. De site en de nieuwe GA code laden zo snel dat vrijwel iedereen gemeten wordt.

Rankings
Op dit moment zie ik nog niet echt een positieve invloed op mijn rankings, maar ik verwacht dit ook pas over een langere termijn te kunnen zien. En dat maakt het ook weer moeilijk om te isoleren, er gaan in een langere periode andere zaken meespelen die de data vertekenen.

Conclusie

Het was leuk om te doen. Nerd als ik ben wilde ik met de Google Page Speed module toch minimaal een score van 85 neerzetten. Alle kleine details moesten aangepakt worden. Resultaat is nu wel dat de site aanmerkelijk sneller ingeladen wordt. En daar draait het uiteindelijk toch om, een trage site is één van de grootste ergernissen tegenwoordig.

Iemand anders nog tips of ervaringen die gedeeld moeten worden?

Click to activate social bookmarks

 
  • Leuke, inzichtelijke post, André.
    En goed je weer wat vaker te zien schrijven hier 🙂

  • Ha Eduard, thanks. Ik heb nog een paar onderwerpen in de rij staan dus je kunt nog meer verwachten 😉

  • Grappige is, dat Google Analytics code ook een boosdoener is wat betreft de lage loadsnelheid. Als je dat vervangt met de asonchronous-versie wordt je website nog trager. Gemeten door GWT uiteraard.

    Ten minste bij twee van de websites, waar ik een tijdje al mee bezig ben, sneller te maken.

    Een item hierover komt nog op m’n blog.

    Was btw leuk om te lezen over jou bevindingen hieromtrent.

  • @Navin: ben benieuwd naar je bevindingen omtrent de async code. Technisch gesproken mag deze het laden niet vertragen, dat effect hebben ze bereikt door het script element met appendchild aan de DOM toe te voegen. De browser wacht dan niet tot het script geladen is om te zien of het script iets met de DOM doet, maar laadt gewoon verder zonder te wachten.

  • Je hebt het geimplementeerd vanaf januari toch? Je toont namelijk een analytics plaatje van oktober tot december? P.s. die gzip implementatie heb je niet echt uitgelegd kan je daar nog iets meer over vertellen? Want ik snap dat je met gzip je css en js kan inpakken maar als je dan in wordpress een wijziging wilt maken in je css dan moet je dus weer lokaal heb zippen en uploaden? Niet echt werkbaar lijkt mij?

    Met VisualStudio kan je een after build event maken die dan de css gzipt maar in wordpress wordt dat denk ik wat lastig.

    Tot horens,
    Bjorn

  • "Een extern iets op je site kan het laden enorm vertragen. Elk ander domein dat nodig is bij het laden van je site betekent ook een extra DNS aanroep. Gebruik deze externe zaken dus met mate."

    Dus je bent tegenstander van een CDN (Content Delivery Network)? Of het laden van bekenden scripts via de Google AJAX Libraries API? Waarom?

  • @Robbert: Het gebruik van een CDN is altijd aan te bevelen en mag zeker een extra DNS aanroep kosten. Er staat niet voor niets "met mate" bij 😉 Een additioneel script van Google kan ook nog wel, zolang het maar niet een brij van allerlei externe scripts wordt, dat gaat ten koste van de snelheid.

  • Mooi artikel, ik ben nu bezig met artikelen verzamelen over snelheidsverbeteraars en ga binnenkort ook maar eens flink aan de slag. Eigenlijk stond het al lang op de lijst vanwege usability voordelen. Maar ja, die to-do lijst lijkt alleen maar te groeien.

    Die stijging van bezoekersaantallen in januari heb ik ook gemeten op verschillende websites. Ik had wel wat veranderd maar niet voldoende om die stijging te verklaren. Het voelt een beetje als januari blues. Lastig meten of dit nu met de snelheid te maken heeft.

  • Zoals je zelf ook al aangeeft heeft de host ook een groot effect op de laadsnelheid.
    Zo wil je de website hosten in Nederland (tenminste als daar je doelgroep ligt) zodat de laadsnelheid voor Nederlanders optimaal is. Daarnaast is het verstandig om de website(s) niet op een shared hosting account te plaatsen aangezien hier vaak duizenden andere sites op staan.
    Daardoor kan het erg druk worden voor de server waardoor de website op sommige momenten gewoon traag is ook al is alles geoptimaliseerd.

    Ook zijn er verschillende mogelijkheden om de snelheid van je website in de gaten te houden. Bij seomonitor kan je bijvoorbeeld dagelijks je snelheid laten checken en krijg je een mailtje als ze een te hoge laadtijd constateren.

  • Jan

    Als ik het goed begrijp zijn allerllei scripts zoals ckicktale , crzyegg erg vertragend.
    Zijn daar nog trucjes voor ?

  • Door de Page Speed Analyzer van google te gebruiken in combinatie met ySlow hebben we de laadtijd weten te verlagen van 3,4s naar 1,8s en laadt de site nu in 73% van gevallen sneller dan gemiddeld. 't optimaliseren van je loadtime heeft vooral effect op de bezoekers, betere positionering heb ik er ook nog niet mee kunnen ontdekken, alhoewel Google inderdaad aangeeft dat dit van belang zou zijn.

  • @Jan: erg vertragend zou ik ze niet noemen. Helemaal niet de wat grotere pakketten die fatsoenlijke servers hebben staan. Maar kies wel met mate de juiste software uit en meet niet klakkeloos alles door met 15 meetpakketten 😉 En als truc werkt het toch vaak het beste om dit soort scripts helemaal onderaan je broncode te plaatsen.

    @Gerben: mooie cijfers. Dat geeft direct aan dat je eenvoudig een bestaande site flink kunt versnellen. En dat is zeer zeker altijd goed voor je gebruikers.

  • Leuk om weten dat google ook rekening gaat houden met de laadsnelheid van de websites.

    Ik meld even dat de stijging van de bezoekers in Januari te verklaren is door het herberekenen van alle pageranks door google (heb ik ergens gelezen). Een soort nieuwjaarscadeau zeg maar. Hoe dat juist in zijn werk gaat waat ik niet maar dat zou verklaren waarom sites die geoptimaliseerd werden het plots veel beter doen op 1 januari...

  • Dit artikel komt precies op het goede moment nu ik bezig ben met het optimaliseren van de snelheid van mijn website.

    Bedankt Andre!

  • Mooi artikel! Duidelijk uitgelegd allemaal! Ben wel benieuwd in hoeverre dit invloed heeft op de rankings! Ik zie trouwens in mijn statistieken ook duidelijk dat in januari de bezoekersaantallen weer toenemen.

  • Jan

    Vergeet niet allerlei plugins en widgets die je tegenwoordig overal kunt downloaden en op je site kunt zetten. Jij hebt hier ook de Twitter Widget, en die heeft er ook vaak moeite mee om op te starten.

    Verstandig is het om afbeeldingen en scripts die lang laden onder in je body te zetten, zo hebben je lezers er in ieder geval geen last van.

  • Ecommerce help

    Snelheid wordt steeds belangrijker in seo. soms kan dat echt een pain in the ass zijn, kijk bijvoorbeeld naar magento!

  • Leuk stukje André. Ook hier is het steeds meer op het vizier aan het raken (ik heb het dan over het uitpersen in de details, de basis zou gewoon goed moeten zijn) en wellicht dat we daar in de (nabije) toekomst maar eens over moeten bomen!

  • Je zegt:

    In plaats van 10 HTTP connecties hoeft er nu maar 1 gemaakt te worden die het plaatje binnenhaalt.

    Maar dit is eigenlijk niet waar sinds HTTP 1.1. Er worden waarschijnlijk zo'n 2 à 3 connecties geopend, waarover de afbeeldingen achter elkaar worden opgevraagd. Dit sequentiële maakt het traag, omdat er tien keer heen-en-weer gecommuniceerd moet worden, en met sprites maar een keer.

  • @Jorrit: Dat ligt er aan. Het kan zijn dat je server de zogenaamde "keep-alive" directive niet aan heeft staan en er dus voor elk element opnieuw een verbinding opgezet moet worden. Het ligt technisch ook nog eens aan welke browsers je gebruikt omdat sommige browsers dit zelf ook nog eens limiteren. Maar voor het artikel vond ik dit technisch gezien de meest handige uitleg 😉

  • Goeie .htaccess tip ook! Dat stukje caching is nu ook gecovered. Homepage zit nu op 90/100 (dat kan dus nog steeds beter 😉 )

  • Hoi Anderé!

    Mooi stukje, ben alleen opzoek naar de functie van "W3 Total Cache" alleen dan voor zelf gemaakte websites

    Kan hier alleen weinig over vinden, iemand?

  • Bedankt voor het delen van deze handige tips André!
    Ik ben ermee aan de slag gegaan.
    Mijn hosting provider wil overigens Gzip niet beschikbaar stellen omdat dit de shared hosting servers te veel zou belasten als erg veel klanten dit gaan gebruiken.

  • jay

    Leuke inzichten en punten bedankt.
    Als ik kijk naar Page Speed van je site zie ik een hoge score van 90 staan, respect!
    Maar ook zie ik dat er toch nog suggesties gegeven worden zoals DNS optimaliseren.
    Hoever moet je gaan hierin en in hoeverre is je hosting van invloed op het cijfer?

  • @jay: je moet zo ver gaan als logisch is. Ik ga bijvoorbeeld geen CDN regelen voor mijn site die voornamelijk door Nederlanders bekeken wordt. En de DNS meldingen worden veroorzaakt door meetscripts, en die ga ik ook niet wegdoen.
    Je hosting is heel belangrijk in dit verhaal, ik heb nu alles bijna maximaal geoptimaliseerd, als het dan nog 5 seconden zou duren weet ik dat het aan de hosting ligt. In mijn geval is de gemiddelde snelheid 1,4 seconden per pagina, en dat vind ik mooi genoeg 🙂

  • Mooie score. Ik zit me ook af te vragen hoe ver ik moet gaan. Ik zou graag sneller zitten dan 1,5 seconden met mijn sites. Ik ben nu bezig met het optimaliseren van 1 site (bedrijfopzetten.nl) en merk dat vooral de hoeveelheid plaatjes lastig is. Naast een lastigheidje in Drupal heb ik op de homepage ook een mooi aantal thumbnails. Ik ben nu eigenlijk op zoek naar een manier om die parallel te laten laden.

    Het opschonen van de html+css is ook nog een mooie. Dat vraagt echter input van een pro en dat staat op dit moment niet in de top10 van kosten die ik binnenkort wil gaan maken.

  • @Erik

    Gzip? Memcache? Willen allemaal wel eens goed helpen, maar wederom werk voor pro's. 😉

  • Gzip heb ik eens aangezet via htaccess maar dit leverde meer server denktijd op. Ik test nu enkele weken een ander systeem en dan enkele weken die gzip via htaccess.

    Nu gebruik ik de module boost. Deze zet alles in gzip en cached die vervolgens op de server. Echter, volgens yslow en pagespeed wordt niet de gzip uitgeserveerd maar de reguliere cache bestanden. wss een serverinstelling maar voor mij lastig te vinden.

    Ik zal binnenkort ook eens memcache bekijken. Ik had er al eens van gehoord en meende dat het vooral gebruikt werd naast boost maar dan voor ingelogde gebruikers.

  • Eric,

    Voor plaatjes gebruik deze gratis website:
    http://www.gracepointafterfive.com/punypng

    Kan je in 1x een hele reeks verkleinen zonder kwaliteitsverlies.

    Om je CSS te verkleinen kan je deze gratis online dienst gebruiken:
    http://www.lotterypost.com/css-compress.aspx

  • @Bjorn,
    Thx ik ga die sites een kans geven, wel ff kijken hoe dit samen gaat met drupal. Mijn image module heeft volgens mij ook al een verkleiningspakket. Ik kan het in ieder geval wel gebruiken voor enkele plaatjes in de achtergrond.

    Daarnaast is spriteme (http://spriteme.org/) ook een handige tool om de achtergrond CSS plaatjes in een sprite te zetten. Deze site maakt de sprite en geeft aan in welke regels je wat aan je css moet veranderen.

    Tot slot worden er op elke pagina plaatjes ingeladen die niet op de pagina voorkomen maar wel in de CSS bestanden. Blijkbaar worden de CSS achtergronden direct ingeladen. Deze plaatjes zitten diep verstop in de core code van Drupal. Ik kan daar wel gaan wijzigen maar dan ben ik bij elke update gedwongen dit opnieuw te doen. Ik moet hierover nog een vraag stellen op het drupal forum want ik zal toch zeker niet de eerste zijn die hier iets aan wil doen.

  • Een zeer handige lijst. Betreffende afbeeldingen heb ik de WP Smush-it plugin geïnstalleerd, deze op Yahoo werkende tool verwijderd alle meta-info van foto's, logo's, ... De kwaliteit blijft behouden maar de bestandsgrootte van de afbeelding maakt wel een kleine duik.

  • Ga zo door! Leuke inzichten en punten bedankt.
    Als ik kijk naar Page Speed van je site zie ik een hoge score van 90 staan, respect!

  • Er valt, ook voor jouw website, nog meer snelheidswinst te behalen. Kijk eens naar GTMetrix.com.

  • In feite maakt die tool gebruik van dezelfde tools als ik doe, maar zonder dat je ze hoeft te installeren. Bedankt voor de tip. Sneller maken dan nu ga ik niet doen, de lage score die ik bij CDN haal zal zo blijven. Ik ga op dit moment geen CDN gebruiken voor het geringe bezoekersaantal 😉

  • Bedankt voor de tips. Laadtijd is vooral voor bezoekers van belang. Invloed op rankings verwacht ik niet.

    Voor plaatjes in de wordpress media directory gebruik ik de smushit plugin.

    Voor het meten van de snelheid (en daar een filmpje van maken) kun je eens kijken bij: http://www.webpagetest.org/

  • vrouwen verleiden

    Ik heb sinds kort zelf een blog gemaakt met wordpress, en ik merkte dat door het gebruik van plugins (ze hoeven niet eens geactiveerd te zijn) mijn blog VEEL langzamer werd... plugins verwijderd en nu laad hij binnen enkele seconden!

  • Weer een leuk stukje geschreven. Erg handige tips en heel duidelijk alles uitgelegd. Dank je wel en respect voor je score van je Page Speed!

  • Het is hierboven al een paar keer genoemd maar een CDN kan echt flink schelen. Ik heb enkele weken geleden de stap gemaakt om van een aantal sites de plaatjes en js en css zoveel mogelijk op een cdn te zetten. Het verschil zit vooral in de connectie en download tijd zoals je in die watervallen zo mooi ziet. Deze verkort aanzienlijk en daarmee ook de laadtijd. Via Amazon cloudfront betaal ik per GB en de prijs lijkt niet duurder dan zelf hosten.

    Sinds enkele weken ondersteunt Amazon cloudfront ook origin pull zodat installatie super makkelijker wordt. Je zet evt een cname met subdomein op naar cloudfront en vervolgens hoef je alleen maar te verwijzen. Cloudfront haalt zelf het origineel van je site en toont deze vanaf haar eigen servers aan de bezoeker.

  • website laten maken

    Goed artikel! Ik heb gelijk even mijn website getest. Deze kan ook nog wel wat sneller ontdek ik nu:P.

  • Hartelijk bedankt voor die tips, erg handig! Ik verwacht geen verschil in rankings met een grotere snelheid, zoals je zelf elders zei, wordt slechts voor 1% van het totaal meegerekend door Google. Maar wel belangrijk voor user experience, en daar draait het uiteindelijk toch om.

  • Veel webmasters negeren hun snelheid, omdat het puur de snelheid in het Algoritme van Google niet heel zwaar meetelt. Maar men vergeet wel een ander aspect. In het algoritme van Google is het wel belangrijk hoe lang bezoekers op je pagina blijven en of ze door klikken naar andere pagina's. Dus inderdaad het weigeringspercentage. Op het moment dat iemand op jouw url klikt, te lang moet wachten, en afsluit neemt dat percentage toe en zal het uiteindelijk invloed hebben op je ranking

  • Vibrators

    Goed artikel! Ik heb gelijk even mijn website getest. Er zijn nog heel wat verbeterpunten voor een aantal sites die ik beheer.

  • Vilmar den Heijer

    Mooi artikel. Ik begrijp inderdaad dat websites snel geladen moeten worden, maar het is weer typerend voor de tijd waar we in leven, een paar seconden meer, waar gaat het over?

  • @Vilmar den Heijer
    Het is wel degelijk belangrijk dat je site sneller laadt. Zodra je site boven de 5 sec laadtijd komt zullen bezoekers je site wegklikken. Hoe sneller je site laadt hoe beter het is voor je bezoekers. Tegenwoordig maakt dit nu ook deel van google's seo factoren.Gebruik daarom een goede vps hosting((ontwijk shared hosting)die je al kunt bestellen voor 8 euro per maand)en download w3 total cache zoals hierboven vermeld staat en je zit al redelijk goed.

  • Jan

    Is het aan te bevelen WP Supercache in te ruilen voor W3 Total Cache of zijn er niet veel verschillen tussen deze twee?

    • Ik zou zo niet de verschillen aan kunnen geven, wel is het zo dat ik de laatste gebruik en daarvan weet dat die wel erg compleet is.

  • Ik heb ook even gekeken en wat aanpassingen gedaan. Bedankt voor de tip en good luck.

  • Ik heb wat tips toegepast en zie daar...het werkt!~

    Bedankt voor deze hulpvolle informatie!

    Groeten,
    Marco

  • Easy Pleasure

    Bedankt voor de goede tip en mooie site

  • Interessant verhaal!
    Het meten alleen al was leuk om te doen. Ik vond de snelheid eigenlijk nog wel oke. Op het moment dat je aan het aanpassen betn geweest merk je pas hoe veel sneller het gaat! 1,8 sec sneller is echt een verschil. Ik hoop dat deze snelheid blijvend is.

  • Snelheid is bij mijn websites altijd een probleem geweest. Bedankt voor de tips!

  • Webdesign Twente

    Net artikel, heb het met plezier doorgelezen, wij blijven natuurlijk graag up2date over deze onderwerpen.