Website 10 keer sneller in half uur werk

snelheid websiteSinds begin dit jaar is snelheid van een website officieel een factor die (een klein beetje) invloed heeft op je ranking in Google. Daarnaast is traagheid een van de grootste conversie killers. André Scholten schreef op zijn blog een uitgebreid verhaal met allemaal technische tips om je site sneller te maken. Nou ben ik niet zo’n techneut, maar ik moet natuurlijk wel een beetje op de hoogte blijven.

Bovendien zag ik met mon.itor.us dat mijn site rond de 400 milliseconden nodig heeft om te laden en dat is bijna 10 keer zo langzaam als bijvoorbeeld nu.nl en de site van André. En in de Google webmaster tools zag ik het grafiekje hiernaast. Dus ik ging aan de slag.

Update (29 juli 2010 15:15): Lees even mijn toevoeging onderaan als je dit gaat toepassen.

Gzip: pagina’s gezipped over het internet

Gisteravond heb ik gzip aangezet. In essentie komt het erop neer dat gzip er voor zorgt dat een webpagina gecomprimeerd over het internet verstuurd wordt. Daarvoor wordt de pagina server-side ingepakt. Dit kost wat rekenkracht en dus tijd op de server.
Vervolgens wordt het bestand gecomprimeerd (in mijn geval zo’n 76% kleiner) over het internet verstuurd. Vooral op lange afstanden en voor mensen met een trage verbinding levert dat dus tijdwinst op. En tot slot wordt de pagina client-side weer uitgepakt en getoond in de browser van de gebruiker.
Via Jaap-Jan kreeg ik deze uitleg en dat werkte perfect. Een kind kan de was doen en dus ik ook ;-)

Maar mijn site werd langzamer!

Ik had verwacht dat ik nu klaar zou zijn, maar het volgende gebeurde:

website snelheid gzip

Het lijkt er dus op dat de snelheidswinst die ik haalde bij het versturen van de files niet opweegt tegen de extra tijd die je kwijt bent met inpakken en uitpakken van de bestanden.

Caching FTW!

Gelukkig bleek dat makkelijk op te lossen door caching aan te zetten. Daarvoor heb ik W3 Total Cache gebruikt.
Als een nieuwe of gewijzigde pagina voor de eerste keer opgevraagd wordt, slaat die plugin de de pagina op in de cache. (dus nadat alle scripts en queries uitgevoerd zijn en de pagina door gzip is ingepakt) Elke keer daarna dat die zelfde pagina opgevraagd wordt stuurt de server de opgeslagen versie terug. Dus de database hoeft niet meer geraadpleegd te worden, de scripts hoeven niets te doen en gzip is al klaar. Een flinke tijdwinst op de server dus.

Van 400 naar 40 milliseconden

En toen zag het grafiekje er ineens zo uit:

site speed cache

Door de scaling is het wat lastig te zien, maar ik zat vanmorgen rond de 1300 a 1400 milliseconden. (pieken niet meegeteld) Gisteren, voordat ik gzip aanzette was het 400 milliseconden. En nu schommelt het ronde de 40 a 50 milliseconden!
Ik vermoed dat die piek om 12 uur te maken heeft met dat de cache af en toe ververst wordt.

Maak ook jouw site sneller !

Dus ik kan iedereen die een wordpress website heeft aanraden om hier even naar te kijken. In nog geen half uur heb je cache en gzip op je site en is die voor bezoekers én zoekmachines veel sneller. Mocht je een ander platform gebruiken, dan bestaan er ongetwijfeld vergelijkbare oplossingen om cache en gzip aan te zetten.

Mocht je dit niet genoeg vinden en verder willen tweaken om je site nog sneller te maken, dan zou je je kunnen verdiepen in:
CSS sprites
Dit is een gave techniek voor als je veel plaatjes in je site gebruikt voor de opmaak. Bijvoorbeeld voor alle randjes en hoekjes en dergelijke. In feite komt het erop neer dat je al die kleine plaatjes naast elkaar in één grote jpg stopt en vervolgens met CSS op elke plek waar je dat nodig hebt de juiste stukjes laat zien.
Hier vindt je uitleg en wat voorbeelden.

Code opschonen
Een goede programmeur maakt schone nette code. Ik ben geen goede programmeur, dus bij mij wil er nog wel eens wat meer code staan dan nodig is. Ruim die dingen op, dat scheelt laadtijd.
Een beetje extra aandacht voor CSS en JavaScript kan daar trouwens geen kwaad. Bedenk dat een browser maar een aantal bestanden synchroon kan laden. Roep je vanuit je pagina meerdere plaatjes, stylesheets en scripts op, dan moeten die vaak op elkaar wachten. Dit kun je oplossen door die bestanden samen te voegen.

Update (29 juli 2010 15:15)
Er bleken ineens rare errors op te treden in FireFox en de mobiele browser van m’n telefoon. Bij een deel requests zag de site er ongeveer zo uit:

�L3 ���� �3q �< �}�� U��s��! +=Ý�U ��M�¦� �[��ݕ!���� B�� �o���� �I# �P<� d��?iT� ���4= � � }D�{�|;�*�כ`�yr��5 t� � Z�� �}�� <� �r�GQ锬 �q�|9e#�e� �@6�˃X �8 �W�W�ؤt/��ݚ{A/��Ә��Q “�@�f�و�/|�6�ш�qZ

In Chrome en Internet Explorer ging het trouwens goed. In FireFox niet. Maar als je daar een harde refresh (ctrl-F5) deed wel. Daarnaast begreep ik dat het bij sommige mensen in FireFox wel goed ging.

Wat bleek?
De W3 Total Cache plugin heeft een ingebouwde gzip module. Die had ik natuurlijk over het hoofd gezien en ik had de eerder genoemde gzip methode ook nog aan staan. Hierdoor trad er waarschijnlijk een conflict op tussen de twee verschillende gzip methoden. Gelukkig wees Jaap-Jan me hier zojuist op en nu lijkt het gefixed!

About Remi van Beekum

Storm Marketing Consultants| Chief Innovation Officer | communicatie| marketing| strategie| organisatie| innovatie | groei| duurzaamheid| online| muziek| politiek| snowboarden| Groningen| Winsum google+ profiel

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>