Snelheid website deel 3: Optimalisatie

In eerdere blogs schreef ik waarom snelheid belangrijk is en later hoe je dat analyseert voor jouw website. Nu is het tijd om de handen uit de mouwen te steken en iets met die resultaten te doen. Er zijn meerdere redenen waarom een website langzaam voelt en is. Snelheid is een goed beheersbaar aspect en dit blog wijden we dus aan praktische oplossingen. Naast een aantal generieke oplossingen zal ik mij met name richten op WordPress, omdat Pure IM op dat CMS gebouwd is.

Hosting

Er zijn meerdere typen hosting waar je voor kan kiezen als je een website online wilt plaatsen. De meest voorkomende varianten zijn shared, VPS en dedicated. Deze volgorde is in prijs ook grofweg aan te houden, waar shared hosting doorgaans goedkoop is en dedicated het duurst.

Shared

Shared hosting houdt in dat jouw website op een server staat met vele andere websites. Je hebt een bepaalde opslagruimte die voor je gereserveerd is, maar het werkgeheugen, de bandbreedte, het ip adres en de CPU deel je met andere sites. Meestal met heel veel andere websites. Dat heeft tot gevolg dat  jouw site direct nadelen ondervindt wanneer een andere sites gekke dingen doen of veel bandbreedte gebruiken. Shared hosting is dus prima om een siteje goedkoop online te hebben, maar als serieus bedrijf mag dit geen optie zijn. De gevolgen van shared hosting zijn ook goed te zien wanneer je een tool gebruikt om je site te monitoren en een rapport met snelheid per uur bekijkt. Shared hosting zal grote fluctuaties vertonen en trager zijn wanneer het ‘druk is op internet’.

VPS

VPS staat voor Virtual Private Server. Je hebt op een VPS een eigen -gesimuleerde- server met bandbreedte, opslagruimte, werkgeheugen en CPU kracht voor jou gereserveerd. Er is dus geen directe afhankelijkheid van andere websites. In de praktijk draaien op de server echter nog wel een aantal VPS’en. Omdat jouw stuk(je) op de server volledig gereserveerd is, is dat geen probleem. Steeds populairder worden Cloud oplossingen met betrekking tot VPS. Jouw gereserveerde ruimte wordt dan verdeeld over meerdere servers, want in theorie voor veel veiligheid zorgt. In de praktijk kan er nog van alles misgaan met de koppeling naar de HD’s, etc. wanneer wij helaas merken dat minder downtime zeker geen garantie is.

Dedicated

Een eigen server, alle hardware voor jezelf en niets delen. Dat is waar dedicated voor staat. De beste oplossing, want je hebt volledige controle, maar ook meteen de duurste oplossing. Qua prijs/kwaliteit verhouding komt men met een VPS het beste uit, want dedicated servers zijn simpelweg vrij duur.

VPS/Dedicated.. welke hardware

Wanneer je voor VPS of Dedicated hosting kiest sta je onmiddelijk voor een ‘probleem’. Je gaat de hardware in moeten vullen. Hoeveel opslagruimte heb je nodig, op SSD schijf of S-ATA, hoeveel dataverkeer is voldoende , hoeveel werkgeheugen (RAM) is benodigd en welke CPU snelheid met hoeveel cores kies je. Lastige vragen waar helaas geen eenduidig antwoord op is te geven. Jouw web bouwer weet in de meeste gevallen het beste welke hardware nodig is. Toch zijn er wel een aantal richtlijnen. Een simpele WordPress site zonder teveel poespas kan prima uit met 256MB ram en één core. Magento heeft doorgaans minimaal 512GB nodig en liefst al 1GB aan RAM met tenminste een eigen core. Maar nogmaals, raadpleeg zeker ook je web bouwer. Dan; SSD of reguliere HD. In alle gevallen is SSD beter voor de snelheid. De vraag is enkel of je dat de prijsinvestering waard vindt. Wanneer je site snel genoeg is kan je een SSD achterwege laten. Wanneer je echt voor sublieme snelheid wilt gaan, en andere zaken al op orde hebt(!), is een SSD de stap naar echte prestaties.

Afbeeldingen comprimeren

Op nagenoeg alle sites staan afbeeldingen. Wij westerlingen houden namelijk van plaatjes om bevestigd te krijgen wat we ook lezen. Afbeeldingen nemen echter veel meer ruimte in beslag dan tekst en alles wat gedownload moet worden kost tijd. Houdt dat in dat je zo min mogelijk afbeeldingen moet gebruiken? Nee. Een site maak je namelijk voor je bezoekers. Daarna ga je optimaliseren. De usibilty van de site moet geen slachtoffer worden van een wens van het bedrijf. Daarom twee voorbeelden. Zoek de verschillen:

Voorbeeld 1

Voorbeeld 2

Zichtbare verschillen zijn er inderdaad niet, dus geen verschil in usability. Qua grootte van de afbeeldingen is er  wel een verschil. Waar voorbeeld 1 een .jpg is van 88,63kb is, neemt voorbeeld 2 slechts 24,03kb in beslag. Oftewel 27,11% van de oorspronkelijke afbeelding. En dit zijn beide JPG’s. dus al gecomprimeerde bestanden. Enkel een afbeelding als .jpg, .png of .gif opslaan is dus niet voldoende voor publicatie op het web. Verder comprimeren is sterk aan te raden. Indien je geen beschikking hebt tot Photoshop, Gimp of andere goede foto bewerkingsoftware dan zijn er online voldoende gratis tools beschikbaar.

Queries verminderen

De meeste moderne websites gebruiken een database voor inloggegevens en voorkeuren, maar ook voor gepubliceerde content. In de broncode staat dus vaak een query naar een tabel om data op te halen. De database stuurt de inhoud terug en dat wordt vertoond op de website. Steeds wanneer een verzoek bij de database wordt ingediend en een antwoord komt kost dat tijd. In mijn vorige blog beschreef ik al hoe je het aantal queries kunt bekijken (Via het command: <?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?>  seconds.). Om het aantal queries te verminderen open ik een aantal php bestanden van dit theme, waaronder head.php. Ik zoek in dat bestand op “<?php”, om verzoeken te ontdekken en kom daar onder andere dit tegen:

<link rel=”icon” type=”image/x-icon” href=”<?php echo ot_get_option
(‘favicon_uploaded’, get_template_directory_
uri().’/images/favicon.
png’)?>”>

De vertaling: als er een favicon geüpload is, haal dan de URL om deze te vertonen. Echter, er is een favicon en die zal er ook blijven. Zonder aanpassingen. De voorwaarde is dus even overbodig als de database gebruiken om de URL op te halen. Ik vervang de query dus met de URL waarin de favicon staat. In geval van Pure IM zorgt dat voor de volgende code:

<link rel=”icon” type=”image/x-icon” href=”https://www.pure-im.nl/wp-content/uploads/2013/02/favicon.png”>

Datzelfde doe ik voor de locatie van de stylesheet. Deze wordt opgehaald uit de database, maar dat is onnodig evenals de locatie van de homepage. Daar kunnen simpelweg statische URL’s geplaatst worden om een query uit te sparen en zo de snelheid te verbeteren. Ga zo door om database queries te minimaliseren.

Javascript bestanden verminderen

In een ideale wereld heeft een website één javascript bestand en één css bestand. In de praktijk wil dat nog wel eens afwijken. Voor wie bestanden zelf niet kan samenvoegen, of tegen technische problemen aanloopt zijn er oplossingen, zoals BWP Minify. Tien javascript bestanden zijn er dan ineens één, wat aanzienlijk scheelt in het aantal requests om bestanden te laden.

Database optimaliseren

WordPress bewaard revisies van pagina’s en posts. Dat zorgt voor vrij veel extra informatie die niet nodig is. Ook is het voor een database met regelmaat fijn als een tabel geoptimaliseerd wordt. In phpMyAdmin kan dat simpelweg door een tabel (of alle tabbellen) te selecteren en te kiezen voor “Optimaliseer tabel”. Dit komt neer op een soort ouderwetse schijfdefragmentatie, maar dan op tabel niveau. Voor wie dit niet wil, te omslachtig vindt of phpMyAdmin niet weet of durft te gebruiken zijn er prima alternatieven. Voor WordPress zijn er namelijk prima plugins voor te downloaden, zoals WP Optimize. Met WP Optmize kunnen meteen post revisions, etc verwijderd worden. Dit kan simpelweg geselecteerd worden waarna een druk op de knop voldoende is om alle gewenste acties uit te voeren.

WP Settings

WordPress is gemakkelijk in te richten om wat efficienter te werken. Zo kan in WordPress caching aangezet worden, kunnen autosaves minder frequent worden ingezet voor minder database vervuiling en kan om dezelfde reden ook gekozen worden om het aantal post revisies uit te zetten of te verlagen. Dat kan door onderstaande code toe te voegen in  wp-config.php. Belangrijke voorwaarde is wel dat de code wordt geplaatst voordat wp-settings geladen wordt. /** Caching aan. */ define(‘WP_CACHE’, true); /** Autosave minder frequent. */ define( ‘AUTOSAVE_INTERVAL’, 600 ); /** Maximaal aantal post revisies */ define( ‘WP_POST_REVISIONS’, 3 ); Wil je dat post revisies uitgeschakeld wordt, gebruik dan: /** Geen post revisies */ define( ‘WP_POST_REVISIONS’, FALSE );

Caching

De aanpassingen zijn vooralsnog vrij low-impact geweest (maar desondanks belangrijk!). De echte winst is te behalen via caching, feitelijk een tijdelijk geheugen. Caching van je website (of eigenlijk alle pagina’s) houdt in dat informatie tijdelijk in geheugen opgeslagen, waardoor het heel snel te sturen is naar je bezoeker. Nadelen: aanpassingen op de site worden pas na enige tijd zichtbaar (of nadat je de cache opnieuw laad). Voordeel: enorme snelheidswinst. De plugin die ik het liefst gebruik voor caching is W3 Total Cache en die zal ik ook inzetten voor pure-im.nl. Voor Pure IM heb ik Page cache, database cache, object cache en browser cache geactiveerd in W3TC. In de advanced settings heb ik o.a. header zaken aangepast. Deze zie je rechts.

Het resultaat?

Voor het optimaliseren laadde de gehele homepage in 2.267 seconden, terwijl een refresh 1.573 seconden in beslag nam. Na optimaliseren duurt het nog maar 1.735 voor de homepage bij eerste bezoek en 1.104 seconden bij het opnieuw laden van de pagina. Toch best aanzienlijke verbeteringen en ruim onder de gewenste 2 seconde. Oftewel, de optimalisaties hebben gezorgd voor ruim 23% verbetering in snelheid en zelfs bijna 30% verbetering bij het verversen van een pagina.