Cache in Joomla

1. De basis

1.1 Wat is com_cache?

Een Joomla component is een kleine applicatie die binnen Joomla draait. De meeste componenten gaan ergens over: com_content gaat over artikelen, com_users gaat over gebruikers. com_cache gaat over gecachte gegevens - de tijdelijke kopieen die Joomla bewaart zodat het niet bij elk bezoek elke pagina opnieuw hoeft op te bouwen.

Het component zelf is heel klein. Het heeft een taak die in tweeen is gesplitst: je kunt er de cache wissen (de opgeslagen kopieen verwijderen) en de verlopen cache opschonen (alleen de kopieen verwijderen die over hun houdbaarheidsdatum heen zijn). Het component maakt de cache niet zelf aan - de rest van Joomla doet dat. com_cache is het schoonmaakscherm.

1.2 Wat is een cache eigenlijk?

Cache is een opgeslagen antwoord. De eerste keer dat een bezoeker een pagina opent, doet Joomla al het werk: het vraagt de database uit, bouwt de artikelen op, rendert de modules en stelt de HTML samen. Met caching aan bewaart Joomla ook een kopie van het resultaat. De volgende bezoeker die om dezelfde pagina vraagt, krijgt het opgeslagen kopie terug en slaat het meeste werk over.

Caching ruilt actualiteit in voor snelheid: je levert een iets oudere kopie zodat je hem veel sneller kunt leveren.

Die afweging is het hele verhaal. Al het andere in dit artikel gaat over het beheersen van hoe oud de kopie mag worden en welke delen van de site uit een kopie geleverd mogen worden.

1.3 Waarom het belangrijk is

Caching raakt de twee dingen waar elke site-eigenaar om geeft:

• Snelheid. Een gecachte pagina slaat databasequery's en rendering over. Op een drukke site is dit het verschil tussen een snelle en een trage pagina.
• Serverbelasting. Minder query's per bezoek betekent dat de server veel meer bezoekers aankan voordat hij het moeilijk krijgt.

De prijs is veroudering. Als je een nieuw artikel publiceert en de homepage is 15 minuten gecacht, verschijnt het nieuwe artikel mogelijk pas na maximaal 15 minuten. Weten hoe je de cache wist - en hoe lang die meegaat - hoort bij het goed beheren van een Joomla-site.

1.4 Waar je het vindt

In de Joomla backend zijn er twee opties, beide onder het menu Systeem:

Systeem -> Onderhoud -> Cache wissen
Systeem -> Onderhoud -> Verlopen cache wissen

Beide openen hetzelfde component, com_cache, in twee verschillende weergaven. De instellingen die bepalen hoe caching zich gedraagt staan ergens anders, in de Globale configuratie (paragraaf 6).

3. Hoe caching in Joomla werkt

3.1 De levenscyclus van de cache

Elk gecacht item volgt dezelfde eenvoudige cyclus:

1. Er komt een verzoek binnen.
2. Joomla bouwt er een cache-ID voor (een hash van de relevante invoer).
3. Bestaat er een opgeslagen item voor dat ID, en valt het nog binnen de cachetijd?
     JA  -> geef de opgeslagen kopie terug. Klaar. (een cache-"hit")
     NEE -> doe het echte werk, sla het resultaat op, geef het terug. (een cache-"miss")

Het cache-ID is het kernidee. Joomla bouwt het op uit de dingen die de uitvoer anders zouden moeten maken - de option, de view, het Item-ID, de taal, de toegangsgroepen van de gebruiker, enzovoort. Twee verzoeken met dezelfde invoer krijgen hetzelfde ID en dus dezelfde kopie.

3.2 Cachegroepen

Items worden geordend in groepen, vrijwel altijd genoemd naar de component die ze heeft aangemaakt: com_content, com_modules, com_plugins, plus een paar interne zoals _system en com_templates. De groep is wat je op het scherm Cache wissen ziet en aanvinkt. Door het groeperen kun je de cache van een component wissen zonder de rest aan te raken.

3.3 Waar de cache staat

Met de standaard File-handler zijn gecachte items gewone bestanden in twee mappen:

cache/                 (de cache van de site / frontend)
administrator/cache/   (de cache van de backend)

Daarbinnen krijgt elke groep zijn eigen submap, en elk item is een .php-bestand met het cache-ID als naam. Het bestand begint met een die-regel zodat het niet rechtstreeks via het web gelezen kan worden. Je kunt de inhoud van deze mappen veilig met de hand verwijderen als de backend onbereikbaar is - dat is hetzelfde als een volledige Cache wissen.

3.4 Welke tabellen de cache voeden

Een punt dat ontwikkelaars verrast: com_cache heeft geen eigen databasetabel. De cache bestaat uit bestanden of geheugen, nooit uit rijen. Wat het opslaat is echter het gerenderde resultaat van gewone query's. Wanneer een view of pagina wordt gecacht, is dat opgebouwd uit inhoudstabellen zoals:

#__content       Artikelen
#__categories    Categorieen
#__modules       Module-inhoud en paginatoewijzingen
#__menu          Menu-items (bepalen via Itemid het cache-ID)
#__extensions    Component- en plugininstellingen
#__session       Inlogstatus (bepaalt caching voor gast vs ingelogd)

De cachelaag zit tussen deze tabellen en het antwoord in: bij een hit slaat Joomla de query's hierop volledig over.

5. Cache-handlers: waar items worden opgeslagen

De cache-handler bepaalt het opslagmedium. Joomla 6 levert er vier:

Oudere Joomla-versies boden ook XCache, eAccelerator, WinCache en een gewone database-handler. Die zijn in modern Joomla verdwenen - reken er niet op.

5.1 Een handler kiezen

• File is prima voor de meeste kleine en middelgrote sites. De enige echte zwakte is veel kleine bestanden op trage schijven.
• APCu is de gemakkelijke winst op een enkele server: het houdt items in het geheugen, dus er is geen schijf-I/O. Het overleeft een PHP-herstart niet en wordt niet tussen servers gedeeld.
• Memcached of Redis zijn het juiste antwoord voor load-balanced clusters, omdat elke webnode dezelfde gedeelde cache leest en schrijft. Redis voegt optionele persistentie toe en is de gangbare moderne keuze.

5.2 Platformspecifieke caching

De optie Platformspecifieke caching (de instelling cache_platformprefix) voegt het browser-/apparaattype toe aan het cache-ID. Zet dit alleen aan als je vanaf dezelfde URL echt verschillende HTML aan desktop en mobiel levert. Voor een responsief template dat dezelfde HTML naar elk apparaat stuurt, laat je het uit - aanzetten verdubbelt simpelweg het aantal gecachte kopieen zonder voordeel.

7. De Paginacache-plugin

7.1 Wat het doet

De plugin Systeem - Paginacache (plg_system_cache) cacht de volledige gerenderde HTML-pagina. Bij een hit geeft Joomla de opgeslagen pagina terug nog bijna voordat de applicatie volledig is opgestart - dit is de snelste cache die Joomla heeft.

Activeer hem op Systeem -> Beheren -> Plug-ins, zoek naar Systeem - Paginacache en zet hem aan. Hij gebruikt dezelfde handler en cachetijd als de globale instellingen.

7.2 Alleen gasten

De belangrijkste regel: de paginacache bedient alleen uitgelogde (gast)bezoekers. Zodra een gebruiker inlogt, stapt de plugin opzij en levert een vers opgebouwde pagina. Dit is opzettelijk - een volledige paginacache kan niet veilig een opgeslagen pagina delen tussen een gast en een ingelogde gebruiker, of tussen twee verschillende ingelogde gebruikers, omdat de pagina persoonlijke gegevens bevat zoals hun naam of winkelwagen.

7.3 De plugin-opties

Browsercaching gebruiken verdient een waarschuwing: zodra de browser van een bezoeker de pagina vasthoudt, kan je server hem niet vertellen te verversen tot de tijd is verstreken. Laat het uit tenzij je de gevolgen begrijpt.

7.4 Wat uit te sluiten

Sluit altijd pagina's uit die live of persoonlijk moeten zijn: contactformulieren, zoekresultaten, inloggen en registreren, winkelwagens en afrekenen, en elke pagina met een token per bezoeker. Het paginacachen daarvan leidt tot ingediende formulieren die "niets doen" of verouderde tokens die de beveiligingscontroles niet doorstaan.

9. Onder de motorkap: de caching-API

Caching is voor elke extensie beschikbaar via een kleine, consistente API. Er zijn vier cache-controllers, elk geschikt voor een ander soort gegevens.

9.1 De callback-cache (meest bruikbaar)

De callback-controller is het dagelijkse gereedschap. Je geeft hem een functie en zijn argumenten; hij voert de functie uit bij een miss, slaat het resultaat op en geeft bij een hit de opgeslagen waarde terug. De moderne manier om een controller te krijgen is via de cache controller factory:

use Joomla\CMS\Cache\CacheControllerFactoryInterface;
use Joomla\CMS\Factory;

$cache = Factory::getContainer()
    ->get(CacheControllerFactoryInterface::class)
    ->createCacheController('callback', ['defaultgroup' => 'com_myext']);

$data = $cache->get(
    function ($id) {
        // Het dure werk draait alleen bij een cache-miss.
        return MyHelper::loadExpensiveData($id);
    },
    [42],          // argumenten die aan de callback worden doorgegeven
    'item-42'      // een optioneel cache-ID
);

De oudere sneltoegang werkt nog steeds en komt veel voor in bestaande code:

use Joomla\CMS\Factory;

$cache = Factory::getCache('com_myext', 'callback');
$data  = $cache->get([MyHelper::class, 'loadExpensiveData'], [42]);

9.2 De output-cache

Wanneer je al een string HTML hebt opgebouwd en die alleen wilt opslaan:

$cache = Factory::getCache('com_myext', 'output');
$id    = 'sidebar-' . $itemId;

if ($html = $cache->get($id)) {
    echo $html;            // cache-hit
} else {
    $html = buildSidebar($itemId);
    $cache->store($html, $id);
    echo $html;            // cache-miss, nu opgeslagen
}

9.3 Kies een goed cache-ID en groep

Twee regels houden gecachte gegevens correct:

• Stop alles wat het resultaat verandert in het cache-ID (het item-ID, de taal, het toegangsniveau van de gebruiker indien relevant). Vergeet je er een, dan lever je de verkeerde kopie.
• Gebruik je componentnaam als de groep zodat beheerders jouw cache afzonderlijk kunnen wissen vanaf het scherm Cache wissen.

11. Caching, ingelogde gebruikers en personalisatie

Het lastigste deel van caching is het prive houden van persoonlijke inhoud. Joomla regelt dit in twee lagen.

11.1 Het toegangsniveau zit in het cache-ID

Conservatieve caching neemt de toegangsniveaus van de gebruiker op in het cache-ID. Een gast en een geregistreerde gebruiker krijgen daarom verschillende gecachte kopieen van een view, zodat een gast nooit inhoud ontvangt die alleen voor leden bedoeld is. Dit gebeurt automatisch en correct, zolang je eigen code dezelfde regel volgt bij het opbouwen van een cache-ID.

11.2 De paginacache blijft weg bij ingelogde gebruikers

Zoals paragraaf 7 uitlegde, bedient volledige paginacaching alleen gasten. Dit is het eenvoudigste veilige beleid: alles wat persoonlijk is gebeurt op een vers opgebouwde pagina. De afweging is dat ingelogde gebruikers minder voordeel van caching hebben - wat meestal prima is, omdat het meeste verkeer op een openbare site anoniem is.

11.3 De klassieke personalisatiebug

De grootste cachebug is een persoonlijke waarde die in een gedeelde cache wordt gebakken: een "Welkom, Peter"-begroeting die gecacht en aan iedereen getoond wordt, of een token per gebruiker dat in een formulier wordt gecacht. De oplossing is altijd een van drie dingen: zet die module op Geen caching, sluit die pagina uit van de paginacache, of voeg het gebruikers-ID toe aan het cache-ID zodat elke gebruiker zijn eigen kopie krijgt.

13. SEO en prestaties

Caching is een van de meest directe SEO opties die je hebt, omdat paginasnelheid een ranking- en gebruikerservaringfactor is.

13.1 Snelheid en Core Web Vitals

Een gecachte pagina bereikt de bezoeker sneller, wat de Time To First Byte verbetert en de Core Web Vitals helpt waar zoekmachines op letten. Voor een inhoudssite met veel gasten is de paginacache-plugin plus Conservatieve caching de goedkoopste betekenisvolle snelheidswinst die er is.

13.2 Cache jezelf niet uit verse inhoud

Lange cachetijden helpen de snelheid maar schaden de versheid. Een nieuwssite die 60 minuten cacht kan oude koppen tonen aan zowel zoekmachinecrawlers als bezoekers. Stem de cachetijd af op hoe vaak je inhoud werkelijk verandert, en wis de cache na het publiceren van iets tijdgevoeligs.

13.3 Caching vervangt de basis niet

Caching laat Joomla de pagina sneller teruggeven, maar het verkleint geen te grote afbeeldingen, verwijdert geen render-blokkerende scripts en repareert geen traag template. Behandel caching als een onderdeel van een prestatieplan, niet als het geheel.

13.4 Cache opwarmen

De eerste bezoeker na een cache-wis betaalt de volle prijs voor het opnieuw opbouwen van elke pagina - een koude cache betekent een trage eerste hit en, op een drukke site, een piek in serverbelasting. Grote sites vermijden dit met cache opwarmen: de cache vooraf opbouwen voordat echte bezoekers arriveren, meestal als laatste stap van een deployment.

Deployment klaar
   |
Opwarmscript vraagt de belangrijkste pagina's op
   |
Joomla rendert elke pagina en slaat hem op
   |
Eerste echte bezoeker krijgt een cache-hit

Een eenvoudige opwarming is een script dat je belangrijkste URL's opvraagt - de homepage, de belangrijkste categorieen, de drukste artikelen - zodat elke pagina is gecacht voordat het verkeer arriveert. Combineer het met de cache:clean bij deployment uit paragraaf 10.3: eerst wissen, dan opwarmen, zodat bezoekers nooit een half-oude site of een koude cache tegenkomen.

15. Best practices

Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:

• Gebruik Conservatieve caching op productie; vermijd Progressief tenzij je het hebt getest.
• Voeg de plugin Systeem - Paginacache toe voor een echte snelheidswinst - deze wordt alleen aan gasten getoond, waardoor het veilig gebruikt kan worden.
• Zet gepersonaliseerde modules op Geen caching, en sluit formulieren, logins en winkelwagens uit van de paginacache.
• Stem Cachetijd af op hoe vaak je inhoud verandert; verlaag het voor nieuws, verhoog het voor brochuresites.
• Wis de hele cache als laatste stap van elke update of deployment, met de knop of cache:clean.
• Gebruik op een cluster Redis of Memcached zodat alle nodes een cache delen.
• Plan Verlopen cache wissen in zodat de cachemap niet onbeperkt groeit.
• Wanneer ontwikkelaars hun eigen gegevens in de cache opslaan, moeten ze elke variabele in de cache-ID opnemen en de componentnaam als groep gebruiken.

17. Samenvatting

Het cachesysteem van Joomla is de snelste manier om een website vlot te laten werken, en com_cache is het kleine schermpje dat alles in de gaten houdt:

• com_cache doet twee dingen: Cache wissen (opgeslagen kopieen verwijderen) en Verlopen cache wissen (alleen de verouderde verwijderen).
• Het gedrag wordt ingesteld in de Globale configuratie: het cacheniveau, de handler, de cachetijd en het pad.
• Conservatieve caching is de veilige standaard; Progressieve ruilt veiligheid in voor snelheid en breekt vaak modules.
• De handler kiest de opslag: File standaard, APCu voor een snelle server, Redis of Memcached voor een cluster.
• De Paginacache-plugin cacht hele pagina's alleen voor gasten - de grootste enkele snelheidswinst, met uitsluitingen voor formulieren en persoonlijke pagina's.
• Ontwikkelaars cachen hun eigen gegevens via de controllers callback en output, en wissen die met cleanCache() of de gebeurtenis onContentCleanCache.

Zodra je caching ziet als een set lagen - viewcache, modulecache, paginacache en misschien een CDN erbovenop - houden de vreemde "verouderde inhoud"-problemen op mysterieus te zijn. Elke laag heeft een kopie, en elke laag heeft een manier om gewist te worden. Als je site traag is, of inhoud toont waarvan je weet dat je die al hebt gewijzigd, ligt de oorzaak vrijwel altijd in een van deze lagen, en weten hoe Joomla cacht is de snelste manier om die te vinden en veilig af te stemmen.