headersitespeed
headersitespeed

WordPress optimaliseren

| 2 Comments

Buffering

Het volgende dat me opvalt in bovenstaande grafieken is dat het meer dan een 1 sec duurt van de pagina aanvraag totdat de eerste byte binnenkomt. Met meer testen zie ik dit soms tot 4 sec oplopen. Over het algemeen wordt alles boven 0.2 sec tot 0.4 sec als langzaam gezien. Waar ligt dit nou aan? Dat is lastig te zeggen, het zou bijvoorbeeld de tijd kunnen zijn die de aanvraag nodig heeft om vanuit Nijmegen naar Amsterdam te komen en daarna de eerste data weer terug komt. Dat lijkt niet het geval te zijn als we naar de onderstaande trace-route kijken:

traceroute nl Wordpress optimaliseren image

Traceroute naar webserver in Amsterdam

Het dataverkeer heeft er ongeveer 40-50 msec voor nodig om heen en terug te komen.

Wat is dan de oorzaak van de laadtijd van de HTML pagina. De webserver en WordPress (mijn blog software) blijven over over.  De webserver instellingen zijn de verantwoordelijkheid van onze hoster, Versio, dus daar kunnen we niet zo veel aan doen.  We kunnen wel kijken of WordPress kunnen optimaliseren.

Vanaf het moment dat de pagina aanvraag WordPress bereikt, worden grofweg de volgende stappen genomen om  een webpagina te genereren:

  1. Bytecode maken van de WordPress php code
  2. ophalen van artikelen uit de database
  3. deze data vertalen in objecten
  4. objecten presenteren als een webpagina

Al deze 4 stappen kunnen gebufferd worden. Voor de eerste hebben we een PHP accelerator nodig, helaas is deze niet bij Versio geïnstalleerd. De volgende stappen kunnen we zelf wel bufferen.

Dit wordt makkelijker gemaakt door de plugins die er voor WordPress zijn. Super Cache is er een van, maar ik heb gekozen voor W3 Total cache omdat deze veel meer opties heeft om mee te spelen. De opties die ik heb gebruikt zijn:

  1. Page Cache – Dit is pagina buffering
  2. Browser Cache – Hiermee kunnen we de webbrowser van de gebruiker instrueren om elementen te bufferen
  3. Minify – het verkleinen van Javascript en Stylesheets zoals al eerder genoemd.
  4. CDN – het verplaatsen van data naar een Content Delivery Network.

De eerste en belangrijkste optie van W3 Total cache is Page Cache. Met Page Cache worden statische pagina’s gecreëerd voor elke (dynamische WordPress) pagina die opgevraagd wordt. Na de eerste aanvraag hoeft WordPress dan niks meer te doen, en wordt de statische pagina opgelepeld. Dit ontlast de server en zou voor flinke winst kunnen zorgen.

Hieronder een voorbeeld: Als we de eerste keer de beginpagina van deze website  opvragen wordt deze door WordPress aangemaakt en vervolgens gebufferd als _index.html, Bovendien wordt  de pagina ook nog eens gecomprimeerd naar _index.html.gzip. Dit levert toch weer 20 KB winst op en alle beetjes helpen.

CachedCompressedWebpage Wordpress optimaliseren image

Cached and compressed webpage

De plug-in ondersteunt ook database buffering  en object buffering.  Maar in een shared hosting omgeving is het twijfelachtig of dit winst oplevert. Bovendien is dit blog redelijk statisch , en dat maakt page caching de belangrijkste vorm van buffering.

Een andere optie die W3 Total cache ondersteund is het automatisch minify-en en combineren van JavaScript files en Stylesheet files.  Zoals eerder gezegd, de JQuery bibliotheek kan nauwelijks kleiner worden gemaakt, maar vele van de plug-ins die ik in WordPress heb geïnstalleerd gebruiken hun eigen javascript en CSS files. Hier is dus nog wel wat winst te halen.

Als laatste  ondersteunt W3 Cache ook Content Delivery Networks.  Nu we toch bezig zijn kunnen we daar ook nog wel even een blik op werpen.

2 Comments

  1. It would be fine if you could write this is English too!
    (The pages you have in English are very impressing!)
    Ole Jacob Bryhni Frostad (Norway)

Leave a Reply

Required fields are marked *.