Een CDN voor WordPress – Wat is dat eigenlijk?
Een snellere website met een CDN voor WordPress
Ik heb in het verleden al heel wat over WordPress en de performance hiervan geschreven. En het zal je dan ook niet helemaal onbekend zijn, dat één van de manieren om je website sneller te krijgen het zorgen voor een cache van je website is.
Wat is een cache?
Mocht je toch niet helemaal weten, wat een cache is, dan leg ik je dat graag heel in het kort uit.
Om een WordPress pagina op te bouwen vanuit de programmacode heeft een webserver wat tijd nodig, vooral omdat veel van de gegevens die er nodig zijn, opgehaald moeten worden uit een database.
Een caching plugin is een plugin die wanneer zo’n pagina wordt getoond deze gelijk opslaat voor een bepaalde tijd. De volgende keer dat dezelfde pagina wordt opgevraagd, krijgt de bezoeker geen ‘verse’ pagina, maar de eerder opgeslagen pagina.
Wanneer je een blogsite hebt, met maar af en toe een nieuwe blogpost kan dit je site aanzienlijk versnellen.
Nadelen van een cache
Een cache heeft ook een aantal nadelen. Het grootste nadeel is natuurlijk dat zo’n gecachte pagina niet door zal hebben, dat de gegevens op de achtergrond gewijzigd kunnen zijn. En de getoonde pagina zal dan ook niet altijd up-to-date zijn.
Maar bij een website die weinig of niet veranderd, is dat geen groot probleem.
Een tweede nadeel is, dat we nog steeds onze server blijven belasten, al is het nu wat minder.
Want die gecachte pagina’s moeten nog steeds worden afgeleverd bij de bezoeker.
Content Delivery Network – Een CDN voor WordPress
CDN staat voor ‘Content Delivery Network’. En om het maar eens heel platvloers uit te leggen, een ‘Content Delivery Network’ is eigenlijk een ‘cache’ die niet op jouw website staat. Maar hoe werkt het dan wel?
Tussen een cache die vanaf jouw server wordt geleverd en een CDN bestaan twee belangrijke verschillen.
Het eerste verschil is het feit dat het niet op jouw machine staat, het tweede verschil, dat het niet op één machine staat.
Niet op jouw machine
Het eerste voordeel wanneer je een CDN voor WordPress gebruikt is dat jouw server wordt ontlast. En dat op meerdere manieren. De eerste manier waarop jouw server wordt ontlast is natuurlijk omdat deze geen moeite meer hoeft te doen om een groot aantal bestanden aan te leveren.
De tweede manier waarop de server wordt ontlast is echter veel interessanter. Want niet alleen zal de content van een andere server worden geladen, maar ook kan de browser van jouw bezoeker meer bestanden gelijktijdig downloaden. De meeste webservers staan browsers slechts toe om 6 bestanden gelijktijdig op te vragen. Maar wanneer de helft van de content van een andere server wordt gehaald, dan is dat dus 2x dat maximale aantal.
Maar het wordt nog leuker.
Je website gaat naar de klant!
Nu zijn Nederland en België relatief kleine landjes, dus dit voordeel is minder belangrijk, behalve dan natuurlijk wanneer je veel handel met het buitenland doet.
Zo’n CDN is -precies zoals de naam suggereert- een netwerk. Heb je een druk bezochte internationaal georiënteerde website, dan wordt het al snel duidelijk hoe jij kan profiteren van een CDN.
Wanneer jouw server in Nederland staat, maar je klant is gesitueerd in de VS, dan zullen al die megabits en -bytes of door de lucht moeten vliegen via een satelliet, of onder water door een kabel moeten zwemmen. En dat is best vermoeiend, dus die megabits en -bites komen iets later aan, dan je zou verwachten (latency). Een goed CDN echter heeft ‘contactpunten’ (edge locations) over de hele wereld. De eerste maal dat de pagina zal worden opgevraagd, zal er dan inderdaad sprake zijn van een bepaalde ‘latency’, iedere volgende keer dat hij wordt opgevraagd, is hij razendsnel. Mede omdat de pagina als het ware vlak bij de bezoeker staat.
En je begrijpt het al. Wanneer iemand in India diezelfde pagina opvraagt, dan krijgt deze persoon een versie te zien die in de buurt van India is aangemaakt.
Amazon Web Services – CloudFront
Eén van die mogelijke CDN’s is CloudFront van Amazon Web Services. En laat dat toevallig nu ook eens één van de snelste zijn.
CloudFront is overigens niet gratis (de meeste CDN netwerken zijn dit niet, en je zal wel begrijpen waarom: Een wereldwijd verspreid netwerk kost nu eenmaal geld), en de werkelijke kosten zijn sterk afhankelijk van je dataverkeer en hoe ‘wijd verspreid’ jij jouw CDN wilt hebben en of je ook een ‘Web Application Firewall’ actief wilt hebben op CloudFront. Ofwel, dat je site wordt beschermd tegen aanvallen van buitenaf.
De praktijk is, dat ik voor de WordXPression site zo’n 2-3 euro per maand kwijt ben aan het CDN zelf. Daar komt nog eens 8 euro bovenop voor de firewall. Maar dat laatste is optioneel.
Een tweede kostenfactor is wel gebied je wilt bestrijken:
- Noord Amerika en Europa
- Noord America, Zuid Amerika en Azië
- De hele wereld
Mocht iemand van buiten het door jou ingestelde gebied toch contact zoeken met de website is er nog steeds geen mens overboord. De bezoeker krijgt de site gewoon te zien, alleen mist hij of zij de versnelling door het CDN. Omdat er weinig mensen van buiten Europa naar de site van WordXPression komen, heb ik gekozen voor de eerste optie, die direct ook de voordeligste is.
Nu is het instellen van een CDN voor WordPress met behulp van CloudFront wel een uitdaging, maar gelukkig is het door middel van de AWS CDN by WPAdmin plugin wel heel makkelijk gemaakt.
Maar voor je de plugin kan installeren moet je eerst wat voorbereidend werk doen
Een AWS account aanmaken
Het eerste wat je nodig hebt is een AWS account. Nu is het account wel gratis, de diensten zijn het niet. Gelukkig kan je, wanneer je nooit eerder een AWS account hebt gehad, gebruik maken van de ‘Free Tier’. Dat wil zeggen dat gedurende een jaar je een bepaalde capaciteit voor bepaalde diensten helemaal gratis hebt. En in het geval van CloudFront is dat maar liefst 1 TB aan data. Dus je kan gedurende een jaar 1 TB aan data gratis verplaatsen van jouw site naar de edge locaties.
Daar komt echter nog een tweede kostenfactor bij, maar daar zal je waarschijnlijk ook niet wakker van liggen. Je krijgt namelijk 10 miljoen HTTP of HTTPS requests per maand gratis gedurende dat eerste jaar.
Ofwel, in het kort, voor de meeste mensen zal dat eerste jaar helemaal gratis zijn.
Maar wat ga je betalen, wanneer je geen gratis gebruik meer hebt?
Ook dat valt enorm mee. Voor de eerste 10 TB betaal je 8,5 cent per gigabyte voor het verkeer vanuit de bron (je website) naar een edge locatie. Omdat dat verkeer op een ‘on demand’ basis is, en veelal al op de edge locatie zal zijn, valt dit verkeer in de praktijk vaak best mee.
Daarnaast betaal je 1 cent per 10.000 https requests. Let op, dat een pagina meestal uit tientallen requests bestaat (javascript, css en afbeeldingen bijvoorbeeld) en dit moet je dus niet lezen als 1 cent per 10.000 pagina’s.
Maar daar hoef je je het eerste jaar niet druk om te maken. En omdat je gedurende dat jaar wel het overzicht van de verplaatste bestanden en de gemaakte requests krijgt, kan je heel goed inschatten, wat het je na dat jaar zou kunnen gaan kosten.
Om je aan te melden ga je naar de site van AWS en vul je je email adres en een accountnaam in. Daarna krijg je een verificatie email om je account te verifiëren.
Na het instellen van je wachtwoord moet je jouw creditcard gegevens invullen. Want de enige manier waarop je bij Amazon kan betalen is via een creditcard of debitcard. Heb je dat gedaan, dan staat de wereld voor je open.
Een gebruiker aanmaken
De volgende stap in AWS is het aanmaken van een gebruiker.
“Wacht eens even”, denk je misschien, dat heb ik toch zojuist gedaan?
Ja en nee. Je hebt zojuist de ‘root user’ aangemaakt. De beheerder. Maar zoals Ben Parker zijn neefje al leerde: ‘Met grote krachten komen grote verantwoordelijkheden’. En die superkracht van de root user gebruiken we alleen in uitzonderlijke situaties.
We maken afzonderlijke gebruikers aan en al die gebruikers hebben maar heel beperkte bevoegdheden.
En eigenlijk maken we veel liever helemaal geen gebruikers aan. Kijk maar eens op het scherm hieronder:
Ik heb dus één User group, de ‘Admins’, en dat is omdat ik niet met de Root user in wil loggen, wanneer ik in het management console moet zijn. Er zijn drie gebruikers, Eéntje dat ben ik zelf, de andere zijn twee applicatie gebruikers (dus programma’s die inloggen op AWS) en de rest wordt helemaal via ‘Roles’ geregeld.
Wanneer jij boven in het zoekveld van AWS ‘IAM’ intikt, dan kom jij in een scherm wat lijkt op het bovenstaande. Met andere aantallen echter.
Wanneer je klikt op ‘Users’ (bij jou zal er 0 staan waarschijnlijk) dan zie je een scherm als het volgende
Natuurlijk staan er bij jou nog geen gebruikers in. Het eerste wat je doet is een gebruiker aanmaken voor het systeembeheer.
Door in het zoekveld onder ‘Permission policies te beginnen met het intikken van de termen, voeg je aan deze gebruiker minimaal het recht ‘Administrator Access’ toe.
De tweede gebruiker die je aanmaakt is een gebruiker met een naam als ‘CloudFrontAccess’. Wanneer je deze gebruiker aanmaakt krijg je de keuze voor het type gebruiker. Voor het voorbeeld noem ik deze even ‘CloudFrontAccess2’. Let op, dat ik niet aankruis dat de gebruiker toegang krijgt tot de management console. Want deze gebruiker hoeft daar nooit in te loggen.
Na op ‘Next’ geklikt te hebben, kom je in het volgende scherm
Hier kies je respectievelijk voor ‘Attach Policy Directly’ en tik je in het zoekveld het begin van ‘Cloudfront’ in.
De verschillende policies die matchen worden geselecteerd, en je klikt op ‘CloudFrontFullAccess’
Heb je dat gedaan en je klikt op ‘Next’ kom je op een overzichtsscherm met alle door jou gemaakte keuzen en kan je vervolgens op ‘Create User’ klikken.
Daarna ga je terug naar het scherm met een overzicht van de gebruikers. Klik hier op de naam van de gebruiker en je krijgt een scherm als het onderstaande te zien:
Hier klik je op het tabblad ‘Security Credentials’ en daar scroll je omlaag tot ‘Access Keys’.
Daar klik je op één van de ‘Create Access Key’ knoppen.
Je klikt hier ‘Application running outside AWS’ aan en krijgt direct een waarschuwing. Dit is een lijstje met aanbevelingen hoe met access keys om te gaan.
Wat hier niet wordt aangegeven, is dat het verstandig is, om deze access keys slechts voor één applicatie te gebruiken. We gebruiken de keys hier om toegang te krijgen tot CloudFront vanuit een bepaalde plugin. Als we om welke reden dan ook ook vanuit een andere plugin of een ander programma toegang nodig zouden hebben tot CloudFront, maken we nieuwe access keys voor dat specifieke doel aan.
We klikken hier op ‘Next’.
We geven hier aan, waar we deze access keys voor gebruiken. Bijvoorbeeld “Toegang tot CloudFront vanuit [pluginnaam] op [websitenaam].
We klikken op ‘Create Access Keys’
Je krijgt dit scherm maar eenmaal te zien. Je kan hier een CSV bestand downloaden met je keys hierin, maar eigenlijk is het zo, dat je na het ingeven -wat we zo in de plugin doen- deze gegevens nooit meer nodig zal hebben. Mijn advies is dan ook ze niet op te slaan, maar gewoon na het ingeven te ‘vergeten’.
Indien je ze -zoals ik hierboven heb aanbevolen- slechts voor één toepassing gebruikt- zal je ze nooit meer nodig hebben. Voor een andere toegang genereer je gewoon nieuwe keys.
De plugin installeren
De volgende stap in het opzetten van ons CDN voor WordPress. Hiervoor installeren we de plugin.
Na het installeren gaan we naar het ‘plugin’ overzicht en klikken we op ‘Setup’ bij de plugin WPAdmin AWS CDN
We krijgen een scherm als onderstaand te zien:
We geven de Access Key en de Secret Key in, en natuurlijk de naam van onze website. Eventueel passen we de Minimum en de maximum cache tijd aan. Voor de Price Class kiezen we voor Noord Amerika en Europa, tenzij we ook veel verkeer uit de rest van de wereld ontvangen.
De rest van de velden laten we leeg, en we klikken op ‘Create Distribution. Op de achtergrond wordt nu CloudFront helemaal voor ons ingericht.
Wanneer dit gebeurd is krijgen we een dialoog als deze te zien
Hier kunnen we pagina’s toevoegen die we niet gecachet willen hebben (zoals bijvoorbeeld de mijn-account, winkelpagina, de winkelwagen en de afrekenpagina voor WooCommerce) en complete onderdelen die we niet gecacht willen hebben (bijvoorbeeld wp-admin/*)
Wanneer je klikt op de know ‘Enable CDN’ wordt jouw CDN geactiveerd.
CDN vs S3… wat is het verschil?
Wellicht heb je ook gelezen over AWS S3. AWS S3 is een andere service van Amazon die enkele overeenkomsten en enkele grote verschillen met S3 heeft. Voor CloudFront bestond werd S3 vaak ‘misbruikt’ als CDN, en dat werkte prima.
Het grote verschil tussen CloudFront en S3 is echter, dat S3 geen ‘edge locaties’ kent. Dus je bestanden worden gehost op een bepaalde locatie en ook vanuit die locatie aangeleverd.
Heb je een website die zich hoofdzakelijk op Nederland en België richt, dan zal dat weinig uitmaken, maar richt je je op een groter gebied, zeker wel.
Bovendien is S3 duurder in het gebruik. Het is dus zeker aan te bevelen om te kiezen voor CloudFront en niet S3 als CDN.
Waarvoor AWS S3 wel zeer geschikt is, is voor het downloaden van grote bestanden. Denk hierbij bijvoorbeeld aan videos in je online training.
Nog niet uitgelezen?
Vind je dit artikel interessant? Mooi! Want ik heb nog veel meer te bieden. Op deze site vind je letterlijke honderden artikelen over WordPress, marketing, e-commers, e-learning en nog veel meer onderwerpen. Op zoek naar meer informatie? Kies één van de trefwoorden hieronder of tik een zoekopdracht in.
