Je bent hier: ITFAQ.nl » WordPress » Besteed aandacht aan een goede WordPress cache plugin configuratie

Besteed aandacht aan een goede WordPress cache plugin configuratie

Waarom je even de tijd moet nemen om je WordPress cache plugin goed in te richten…

Het gebruiken van een cache plugin in WordPress is belangrijk voor een snelle website, dat weet je inmiddels. Maar wist je dat het óók belangrijk is om de plugin goed te configureren? In dit artikel laat ik je zien hoe je .htaccess of web.config rewrites kunt gebruiken om WordPress / PHP geheel te omzeilen en direct de gecachete HTML weer te geven. Dit maakt jouw WordPress site nóg sneller!

Page caching goed instellen in WordPress

Mijn post caching concepten in WordPress geeft al een kleine voorzet op WordPress page caching, door te stellen:

… zijn jouw posts en pagina statisch, én herschrijf je HTTP-verzoeken goed d.m.v .htaccess of web.config URL Rewrite, dan kun je voor alle vervolgverzoeken PHP geheel omzeilen.

wat is caching en hoe maakt dit WordPress sneller?

Als je het uitvoeren van PHP geheel kunt omzeilen dan geeft dat een gigantische performance winst. Want zoals je wellicht weet zijn PHP-processing en database-operaties de meest zware operaties die uitgevoerd worden als je een post of page opvraagt. Als een webserver dat niet meer hoeft te doen dan scheelt dat enorm! Al eerder gegenereerde HTML staat bijna real-time op het scherm van de bezoeker.

Maar, helaas stellen cache plugins niet altijd even goede, of de beste, URL rewrites in voor je website. Voor we hierop verder gaan, eerst een korte beschrijving over hoe het herschrijven van URL’s (Permalinks) werkt in WordPress.

Het basis .htaccess bestand in WordPress, voor het herschrijven van URL’s, is als volgt:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

In een notendop betekent dit dat alle HTTP-verzoeken (requests) die niet voldoen aan de volgende condities worden doorgestuurd naar /index.php:

  • het HTTP-verzoek is niet voor /index.php
  • het HTTP-verzoek is niet voor een bestaand bestand (!-f)
  • het HTTP-verzoek is niet voor een bestaande map (!-d)

Helaas gebruik ik HTTP-verzoek en request door elkaar in deze post. Het betekent beide hetzelfde.

Een request gaat dan de PHP processing pipeline in, via /index.php, naar wp-blog-header.php naar wp-load.php, wp-config.php en afhankelijk van verschillende eisen en condities vele andere .php-bestanden. Uiteindelijk komt een request bij WPINC/rewrite.php en WPINC/class-wp-rewrite.php. WPINC is de constante voor de map wp-includes.

Protip: heb je problemen met WordPress Permalinks? Sla deze opnieuw op via het Dashboard om gecachete varianten te flushen en vernieuwen.

Voordat een request bij WPINC/rewrite.php en WPINC/class-wp-rewrite.php komt, is in wp-settings.php geëvalueerd of WP_CACHE gedefinieerd is in wp-config.php en op TRUE staat:

if ( WP_CACHE && apply_filters( 'enable_loading_advanced_cache_dropin', true ) && file_exists( WP_CONTENT_DIR . '/advanced-cache.php' ) ) {
        // For an advanced caching plugin to use. Uses a static drop-in because you would only want one.
        include( WP_CONTENT_DIR . '/advanced-cache.php' );

        // Re-initialize any hooks added manually by advanced-cache.php
        if ( $wp_filter ) {
                $wp_filter = WP_Hook::build_preinitialized_hooks( $wp_filter );
        }
}

Dit is belangrijk om te weten omdat veel cache plugins een advanced-cache.php bestand plaatsen met daarin (PHP-) regels en condities. Dit bestand moet staan in de map wp-content (WP_CONTENT_DIR constante).

Het advanced-cache.php voert verschillende acties uit en complexe calculaties op inkomende URL requests, om na te gaan of die wel of niet bij een bestaande post of gecachete versie daarvan horen. Pff wat een zin, sorry :) Maar wat nou als je al die PHP processing, acties en calculaties kunt omzeilen zodra een post gecachet is? Als je de cache preload, of als een bezoeker een niet gecachete post bekijkt, dan is de cache erna aangemaakt voor volgende bezoeken.

Lees ook:  Caching concepten in WordPress: wat is caching en hoe maakt dit WordPress sneller?

Dus waarom niet direct een HTTP-verzoek herschrijven naar de cache als de cache al bestaat?

HTTP-requests direct herschrijven naar de gecachete HTML variant met mod_rewrite en .htaccess

In een mod_rewrite .htaccess bestand op Apache (of web.config in IIS) kun je verschillende condities opgeven waaraan een HTTP-request moet voldoen. Of juist niet aan moet voldoen. Hierdoor kun je een HTTP-verzoek heel precies sturen.

Condities kun je zien als “if this then that” of een keten van eenvoudige voorwaarden (wordt aan de conditie voldaan, voer dan de actie uit of ga anders door naar de volgende conditie).

Protip: hier op ITFAQ.nl schreef ik al eerder over .htaccess-bestanden, bijvoorbeeld voor een website redirect naar HTTPS. Ook op Saotn.org staat een groot aantal artikelen over Apache, mod_rewrite en .htaccess. Zoek ze eens op en lees ze door om meer over .htaccess en mod_rewrite te weten.

Belangrijk hierbij is enige kennis van rewrite condities (RewriteCond) en een rewrite regels (RewriteRule) en wat reguliere expressies. Yikes!

Defines a condition under which rewriting will take place

https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond

Defines rules for the rewriting engine

https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriterule

Apache mod_rewrite Introduction

https://httpd.apache.org/docs/2.4/rewrite/intro.html

Dit bovenstaande is veel leesvoer, ja, maar lees gauw eerst dit artikel door en ik zal het proberen je duidelijk te maken.

Uitgaande van een vrij standaard cache plugin zoals WP-Optimize, Cache-Enabler of WP-Super-Cache, weten we twee zaken bij een HTTP-request op een post:

  1. de opgevraagde post is nog niet gecachet
  2. de opgevraagde post is wel gecachet

En heb je jouw cache plugin goed ingesteld, dan is na het eerste de tweede het geval (een post is nog niet gecachet bij het eerste verzoek, en daarna wel). Goed.

Als voorbeeld neem ik nu WP-Optimize, maar het gaat net zo goed op voor Cache-Enabler of WP-Super-Cache. WP-Optimize maakt een map wpo-cache aan in de standaard cachemap van WordPress (wp-content/cache): wp-content/cache/wpo-cache. In die map worden mappen gemaakt met de hostnaam van de site. Mijn voorbeeld is www.itfaq.nl, dus wordt de hele cachemap-structuur: wp-content/cache/wpo-cache/www.itfaq.nl.

De WP-Optimize cache plugin zorgt er dan voor dat gecachete versies van posts worden opgeslagen in dezelfde structuur als jouw site. Dat is belangrijk om te weten. Zo wordt de hoofdpagina hier opgeslagen als /index.html, maar de post MySQL-database beheren krijgt een submap met de post-slug als naam en de post wordt daarin opgeslagen als index.html:

wp-content/cache/wpo-cache/www.itfaq.nl/mysql-database-beheren/index.html

Dus resumé is de map wp-content/cache/wpo-cache/www.itfaq.nl een constant gegeven, en dat wat erachter komt is variabel. Nu je dit weet kun je een regel bouwen die dynamisch kijkt of de gecachete variant bestaat, en zo ja het HTTP-verzoek voor je WordPress post direct doorstuurt. Dit scheelt enorm in het uitvoeren van PHP en redirects, omdat direct de gecachete HTML getoond kan worden.

Je doet dit als volgt:

Condities en regels plaats je bóven het standaard blokje WordPress Permalinks rewrites. Je kunt heel simpel beginnen:

RewriteCond %{REQUEST_URI} (^/mysql-database-beheren/) [NC]
RewriteRule .? /wp-content/cache/wpo-cache/www.itfaq.nl%1 [L]

Dit doet niets anders dan requests voor de post /mysql-database-beheren/ herschrijven naar /wp-content/cache/wpo-cache/www.itfaq.nl%1. Nu moet je weten: in %1 zit de match op REQUEST_URI gevangen (/mysql-database-beheren/), dus inclusief de /. Die komt daarom niet na .nl.

Probeer het eens uit: zorg ervoor dat er een gecachete versie van een post is, en wijzig daarvan de HTML een beetje zodat je het herkent. Je zult dan zien dat dit klopt. Of gebruik éénmalig een redirect met R=302:

RewriteRule .? /wp-content/cache/wpo-cache/www.itfaq.nl%1 [L,R-302]

Dit zorgt ervoor dat de redirect niet in de browser wordt opgeslagen, ideaal om te testen.

Lees ook:  WordPress 5.0 "Bebo" met Gutenberg uitgebracht

Nu is dit met een paar posts nog wel handmatig te doen, maar met een groot blog heb je liever iets dynamisch.

Je kunt een mod_rewrite RewriteCond maken aan de hand van de REQUEST_URI (welke URL wordt opgevraagd?) en daarbij kijken of dat HTML-bestand aanwezig is op het bestandssysteem. Hiervoor gebruik je DOCUMENT_ROOT als server variabele, samen met HTTP_HOST.

De DOCUMENT_ROOT kun je zien als de webroot, of de map waarin WordPress staat. En HTTP_HOST is de hostnaam die opgevraagd wordt door de browser: www.itfaq.nl in mijn geval. Test dan met -f of een bestand bestaat. Hier bovenaan stond !-f, wat betekent: als het bestand niet bestaat. De ! maakt de conditie negatief. Met -f test je dus of een bestand wel bestaat.

Dit samengevoegd krijg je:

RewriteCond %{REQUEST_URI} (.*) [NC]
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/wpo-cache/%{HTTP_HOST}/%1/index.html -f
RewriteRule ^(.*) /wp-content/cache/wpo-cache/%{HTTP_HOST}/%1/index.html [L]

Conclusie herschrijven naar WordPress cache

In dit artikel heb ik je uitgelegd dat je, door middel van een .htaccess-bestand, eenvoudig HTTP-verzoeken voor WordPress posts kunt herschrijven naar een gecachete variant. Als je een cache plugin hebt geïnstalleerd tenminste.

Deze page caching is ideaal en scheelt enorm aan PHP-processing op de webserver. Omdat de webserver het verzoek doorstuurt naar een puur HTML-bestand is dat het enige wat verwerkt hoeft te worden. De browser toont dit vrijwel direct.

Let er wel op dat je onder het blokje met jouw RewriteCond / RewriteRule het oorspronkelijke WordPress Permalinks blokje plaatst. Anders gaat het alsnog fout. Ook moet je erop letten dat verschillende cookies kunnen worden gezet door WordPress, of dat er bepaalde URL’s of request-methoden zijn die het cache-gedrag moeten beïnvloeden. Dit moet je ook opnemen in jouw rewrites. Voor deze post is dat net te veel van het goede, maar in WP-Super-Cache .htaccess rewrite fix voor op cookie-gebaseerde acties lees je er alles over.

Probeer het eens uit, ik ben benieuwd naar je resultaten. Laat het weten in en reactie. In een tweede post zal ik een Windows Server IIS web.config voorbeeld hiervoor maken.


Heeft dit bericht jou geholpen bij het oplossen van een probleem? Of vond je het interessant? Steun dan ITFAQ.nl met een rechtstreekse donatie via Paypal of via IBAN: NL31 ABNA 0432217258 (t.n.v Jan Reilink). Slechts €5,- is al ruim voldoende, bedankt!

Steun ITFAQ.NL


Laat een reactie achter

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

129 queries, took 0,762 seconds running PHP version 7.4.8