Acht+ tekenen dat je je WordPress cache snelheids optimalisatie strategie fout doet Blog, The quest for page speed

Je hebt WP Optimize of WP Sweep geïnstalleerd

Periodiek "opschonen" zou handig kunnen zijn, ware het niet dat je site er zeker niet twee keer sneller van gaat worden. Je database heeft zelf zijn interne optimalisatie en die is echt steengoed. Af en toe een optimize operatie doen is wellicht geen overbodige luxe. Maar .. om dit te doen installeer dan geen extra plugin om dit te regelen. Het kost je bij iedere aanroep in WordPress weer extra laadtijd. Vraag je webhost om periodiek je database tabellen te optimaliseren. Maar ook hier: een paar kilobyte "overhead" wegpoetsen gaat je niet echt helpen.

Je gebruikt WP postviews of WP Slimstat voor statistieken

Er is maar een "plugin" die overal werkt, gratis is, geen vertraging geeft in laadtijd en de mooiste grafieken geeft: Google Analytics. Daarnaast werkt het ook met caching aan. WP Postviews of slimstat schrijven bij iedere keer dat iemand een pagina ophaalt een regeltje in je database. Prima als je tien bezoekers per dag hebt. Maar ga je er meer krijgen dan schaalt het voor geen meter. De opslag in je database gaat flink omhoog en het berekenen van statistieken ook. Bespaar je de ellende en kies voor Google Analytics. Houd je van je privacy, kies dan een hosted aanbieder van Piwik. Je kunt Piwik ook zelf in je code zetten, en ook zelf hosten op je server, maar pas ook hier op: de opslag van Piwik kan ook rapido oplopen als je veel bezoekers hebt.

Je hebt een WooCommerce webshop, maar geen page cache plugin aan staan

WooCommerce is, ondanks dat het een webshop is, prima te cachen. Ten eerste wil je je plaatjes en andere bestanden altijd in een snelle cache (zoals varnish) hebben. Ten tweede: zolang er nog geen items in een winkelmandje zitten .. kun je de hele site prima vanuit cache serveren. Als je W3TotalCache gebruikt is het heel simpel (bron: https://www.managedwphosting.nl/2015/02/w3-total-cache-woocommerce-page-caching/) zet namelijk deze twee regeltjes in je page cache cookie exclude:

woocomerce_cache_hash
woocommerce_items_in_cart

Hiermee zorg je ervoor dat iedereen die nieuw is op je site de site lekker snel te zien krijgt. Als je eerste indruk al meteen is "wat een trage site" .. dan zullen mensen sneller weg klikken.

Je bent bezig een maximaal aantal revisies in te stellen (of je hebt ze zelfs uitgezet)

Het idee achter geen of minder revisies van je berichten is duidelijk: je gebruikt minder opslag in je database. Vanuit optimalisatie zeker geen slecht idee. Echter .. van alle sites die we vanaf 2009 hebben gezien weten we uit ervaring dat alle laadtijd voor meer dan 90-95 % bij web/PHP gebruik zit, en de rest, dus maximaal 10-5 % bij database/MySQL gebruik. En het is geen uitzondering dat mysql echt veel minder dan 2 % van je totale laadtijd nodig heeft.

Tip: installeer een WordPress debug toolbar en dan kun je het zelf zien.

Het aantal revisies heeft enkel invloed op de archieven van berichten die gepubliceerd zijn. Als je een bericht bewerkt en weer opslaat wordt de vorige versie als archief opgeslagen. Zo kun je makkelijk terug als je een foutje hebt gemaakt. Concreet "schoon" je de posts en postmeta tabellen op als je revisies beperkt of uitzet. Omdat MySQL ( maar ook MariaDB ) als database zelf al een goede caching laag heeft gaat het niet noemenswaardig helpen als je de revisies tot een stuk of 3 beperkt of uitzet.

Je hebt geen expire headers

Belangrijker dan je denkt. Met expire headers geef je per bestand aan hoelang ze in cache geheugen mogen blijven. Google vind dit ook belangrijk, zie https://developers.google.com/speed/pagespeed/

Zeker als je Cloudflare of varnish gebruikt gaat dit je server enorm ontlasten. Geen proxy oplossing voorhanden zoals Varnish, Cloudflare of nginx microcaching ? Zelfs dan gaat het helpen, want dan snapt de browser van je bezoeker dat hij niet iedere keer een plaatje moet ophalen. Het is er nog van het eerste bezoek van de (bijvoorbeeld) homepage. Gebruik je wel een proxy oplossing dan zullen deze diensten ook veel minder vaak verzoeken naar je webserver doen, waardoor deze het ook veel minder druk krijgt.

Onze page speed score is overigens ook niet slecht, en zelfs met een HTTPS slotje (SSL certificaat) is onze site snel en scoort hij goed in google.

Je gebruikt geen varnish caching

Zelfs als je site's HTML stuk er 5 seconden over zou doen om op te bouwen .. kan varnish je super helpen. Varnish werkt zo snel dat je dat HTML stuk in het servergeheugen (RAM geheugen) supersnel kunt opslaan en ophalen. Zo snel zelfs dat het HTML stuk uit cache in 50 tot 200 milliseconden opgehaald kan worden. Dat is een enorme winst! Ook al heeft de server snelle SSD schijven voor permanente opslag, RAM geheugen is altijd sneller.

En .. varnish gaat je helpen als je in eens echt veel bezoekers gaat krijgen. Stel je hebt net een blogbericht gemaakt en dat bericht wordt op social media flink gedeeld. Fijn! Zonder varnish caching kan je server het gewoon niet aan. Met varnish caching wel. Want het HTML deel van je site wordt in maximaal een vijfde seconde naar je bezoeker gestuurd. Je plaatjes en andere bestanden worden overigens ook snel naar je bezoeker gestuurd. En dat allemaal zonder dat je webserver ook maar een verzoek te verwerken krijgt. Varnish ontlast je webserver dus en schaalt echt extreem goed.

ManagedWPHosting.nl biedt varnish hosting voor WordPress aan, dan kun je zelfs bij je huidige webhost blijven en regelt ManagedWPHosting.nl de varnish dienst. Bekijk alle informatie hier: https://www.managedwphosting.nl/wordpress-webhosting/varnish-wordpress-snelheidswinst/

Je hebt plugins (waaronder thrive en popup "icegram") die cookies voor bezoekers zetten

Hierdoor zal geen enkel page cache HTML verzoek in een cache gezet kunnen worden. En daarom zal iedere bezoeker moeten wachten totdat WordPress volledig is opgebouwd. Kijk dus naar alternatieven, het kan lonen om je site sneller te maken en een stukje plugin uit te zetten. Als mensen je site te traag vinden zullen ze eerder weggaan.

Je gebruikt de Leadpages plugin

Deze plugin heeft 5 seconden nodig om HEEL VEEL verzoeken naar hun server te maken, zie hier een stukje log (gevonden met de plugin Snitch):

Je gebruikt een CDN en verwacht dat die al je snelheidsproblemen oplost

Er zijn altijd drie snelheidsgeboden die voor iedere site gelden, of het nu WordPress is, Drupal, Joomla, of zelfs zonder CMS beheersysteem:

1. Zo weinig mogelijk (DNS) connecties
2. Zo weinig mogelijk data "over de lijn"
3. Als je al data moet sturen, zorg dat deze zo snel mogelijk aankomt

Neem van ons aan: tenzij je (minimaal een van deze punten) ..

1. Bezoekers uit de hele wereld krijgt
2. Geen varnish caching hebt (en je webhost dit ook niet aanbiedt)

Heb je echt geen CDN nodig. Een CDN zorgt ervoor dat je statische bestanden zoals plaatjes vanuit een server die dicht bij je bezoeker staat worden geserveerd. Dus een bezoeker uit Rusland krijgt de plaatjes via een server uit Rusland, en een bezoeker uit Canada uit Canada of de Verenigde Staten. Dat is punt drie van de snelheidsgeboden.

Dat is natuurlijk super, maar als je bezoek eigenlijk alleen uit Nederland komt .. dan is een supersnelle varnish server in Nederland ruim voldoende.

Ongeacht je herkomst van verkeer gaat een CDN trouwens geen wondermiddel voor al je snelheidsproblemen zijn. Want hoewel een CDN (of varnish) snel bestanden kan afleveren bij je bezoeker .. is het nog altijd zaak om te zorgen dat (zie punt twee van de snelheidsgeboden) je je plaatjes alsnog ophaalt in het formaat waarop je ze toont.

Want .. als je bijvoorbeeld een foto op je site laat zien van 200 bij 200 pixels via CSS stylesheets .. maar je haalt m op volledige originele grootte op (stel 2048 bij 2048 pixels) .. dan gaan er drie dingen mis:

1. De browser van je bezoeker moet meer data binnenhalen dan er eigenlijk gebruikt wordt
2. De browser van je bezoeker moet extra "rekenen". Want die moet een verkleining van de foto berekenen van 2048 bij 2048 pixels naar 200 bij 200 pixels.
   Nota bene: Iedere browser is anders waardoor het resultaat er gewoon slecht uit kan zien, en het berekenen kost gewoon laadtijd.
   Het resultaat is er sneller en ziet er ook mooier uit als je echt een 200 bij 200 pixel foto zou inladen.
3. Het formaat staat in relatie met de bestandsgrootte. Uitgaande van ons voorbeeld zou je een bestand van 4194304 pixels ( = 2048 breedte * 2048 hoogte ) inladen om een foto van 40000 pixels ( = 200 breedte * 200 hoogte ) te tonen. Dat is een factor 105 verschil!
   Om het nog simpeler te berekenen, als je een plaatje van 10 bij 10 pixels hebt en je zou m willen laten zien als 5 bij 5 pixels .. ben je "slechts" twee keer kleiner aan het tonen in afmetingen dan het origineel. Maar je oppervlakte van je originele foto is wel 4 keer groter ! Want 5 x 5 = 25 en 10 x 10 = 100. Trek deze berekening maar eens (globaal) door naar je eigen foto's ..

Zorg dus wat je WordPress foto formaten in orde zijn. Je kunt verschillende formaten laten maken door WordPress, en als je de plugin imsanity installeert kun je zorgen dat WordPress automatisch een foto terugschaalt naar een maximale hoogte en breedte al tijdens het uploaden.

Conclusie

Hulp nodig om je site te analyseren en te versnellen? Wij weten hier alles van. Neem hier contact met ons op.

Wees lief voor je WordPress en je server, dan kan de server meer aan en kun jij ook je site sneller bij bezoekers op het scherm toveren. Meten is weten, kijk maar naar google page speed tool, webpagetest.org en GTmetrix. Maar onthoudt dat die enkel gecache-te sites kunnen meten. Dat is zeker belangrijk, maar nog belangrijker is dat je site sneller laadt als je bent ingelogged. Kijk ook eens naar P3 profiler als plugin, die meet de snelheid van je site en meet je thema en iedere plugin qua laadtijd. Ook hier kun je zien hoeveel tijd je database nodig heeft. Goede webhosting met PHP 7, memcached en varnish kunnen hier al enorm bij helpen.