Joomla sneller maken: praktische gids voor betere prestaties
Een trage website verliest bezoekers nog voordat er iets te zien is. De helft van de bezoekers vertrekt terwijl de pagina nog aan het laden is, zoekmachines geven de site een lagere positie en bij elke campagne die je voert, betaal je voor klikken die meteen weer wegklikken. Het goede nieuws: de meeste trage Joomla-sites zijn traag om redenen die goedkoop op te sporen en op te lossen zijn, en Joomla biedt meer prestatietools dan de meeste mensen ooit inschakelen.
Dit artikel legt Joomla-prestatie-optimalisatie van boven tot onder uit. Het behandelt de basis en de snelle winst voor eigenaren, meten, afbeeldingen, assets en servertuning voor beheerders, en profiling en query-discipline voor ontwikkelaars. Het bouwt voort op het Focus On-artikel over Joomla-cache, dat het cachesysteem diepgaand behandelt; hier is caching een hoofdstuk in het grotere verhaal: meten, de server-stack, afbeeldingen, CSS en JavaScript, extensies, de database en CDN's.
Prestaties zijn niet één grote schakelaar. Het zijn twintig kleine schakelaars, en het gaat erom te weten welke daarvan voor jouw website van belang zijn.
Het doel is eenvoudig: je Joomla-site meetbaar sneller maken, in de volgorde die de grootste winst eerst oplevert.
1. De basis
1.1 Waarom snelheid telt
- Bezoekers: elke seconde laadtijd kost conversies en geduld; mobiele bezoekers op trage netwerken voelen het dubbel.
- Zoeken: Google gebruikt paginabelevingssignalen, gemeten via de Core Web Vitals, als rankingfactor.
- Geld: een snellere site doet meer met dezelfde hosting, en advertenties naar een trage site verbranden budget.
1.2 De vier lagen van Joomla-prestaties
| Laag | Voorbeelden | Typisch aandeel in het probleem |
|---|---|---|
| Server | PHP-versie, OPcache, database, hostingkwaliteit. | Het fundament waar alles op rust. |
| Joomla | Caching, gzip, sessie-afhandeling, aantal extensies. | De schakelaars die dit artikel behandelt. |
| Frontend | Afbeeldingen, CSS, JavaScript, lettertypen, templategewicht. | Meestal verreweg het grootste aandeel. |
| Netwerk | HTTPS-opzet, compressie, CDN, afstand tot bezoekers. | Telt het zwaarst voor internationaal publiek. |
De frontend-laag verdient nadruk: op de meeste sites zijn het de afbeeldingen en scripts die de laadtijd domineren, niet PHP. De server tunen terwijl je hero-afbeeldingen van 4 MB verstuurt, is de motor poetsen van een auto met vierkante wielen.
1.3 De ene regel: meet eerst
Optimaliseer nooit blind. Meet, verander een ding, meet opnieuw. Zonder getallen kun je een echte verbetering niet onderscheiden van een placebo - en prestatie-werk zit vol placebo's.
Naar boven2. Meten: weten voordat je tunet
2.1 De Core Web Vitals
Google's Core Web Vitals zijn drie gebruikersgerichte getallen, gemeten op echte bezoeken:
| Metriek | Meet | Goed |
|---|---|---|
| LCP (Largest Contentful Paint) | Hoe snel de hoofdcontent verschijnt. | <= 2,5 s |
| INP (Interaction to Next Paint) | Hoe snel de pagina reageert op klikken en typen. | <= 200 ms |
| CLS (Cumulative Layout Shift) | Hoeveel de layout verspringt tijdens het laden. | <= 0,1 |
Test met PageSpeed Insights (lab-data plus echte gebruikersdata waar beschikbaar) en Lighthouse in de developer tools van de browser. Test de pagina's die ertoe doen - de homepage, een typisch artikel, de drukste landingspagina - met mobiele instellingen, want daar bijten de drempels.
Houd naast de drie vitals ook TTFB (Time To First Byte) in de gaten: de kale serverresponstijd. Dat is het getal dat Joomla-caching, PHP-versies en hostingkwaliteit direct bewegen. Een trage TTFB wijst naar de achterste helft van dit artikel; een snelle TTFB met een trage LCP wijst naar de frontend.
Lab-tools meten een pagina tegelijk. Professionele crawlers zoals Screaming Frog (gratis tot 500 URL's per crawl) breiden de meting uit naar de hele site: elke te grote afbeelding, elke redirect-keten, elke zware pagina - en met de betaalde PageSpeed Insights-integratie de Core Web Vitals van de volledige site in een rapport. Voor alles voorbij een handvol paginatypen vervangt een crawl uren pagina-voor-pagina testen.
2.2 Joomla's eigen meetgereedschap
Voor de PHP-kant toont Joomla's Debug systeem (Algemene configuratie → Systeem, plus de plugin System - Debug) precies waar de tijd heen gaat: elke databasequery met zijn duur, geheugengebruik, en profiling-markeringen door het hele request. Tien seconden de querylijst lezen vindt de module die tweehonderd query's afvuurt. Gebruik het op een ontwikkelkopie - debug blijft uit in productie, zoals het artikel over security hardening benadrukt.
2.3 Houd een logboek bij
Noteer de getallen voor en na elke wijziging: datum, pagina, LCP, totaalgewicht, aantal requests. Het houdt je eerlijk, laat zien welke wijzigingen echt iets deden, en geeft je een referentie wanneer iemand zegt "de site voelt de laatste tijd traag".
Naar boven3. Het serverfundament
3.1 PHP-versie en OPcache
Elke grote PHP-release is meetbaar sneller dan de vorige, dus een actuele PHP-versie draaien is gratis prestatie (en gratis veiligheid, zoals het hardening-artikel opmerkt). Net zo belangrijk: OPcache moet aanstaan. Die houdt gecompileerde PHP-bytecode in het geheugen zodat Joomla's code niet bij elk request opnieuw gecompileerd wordt - op de meeste hosts staat hij standaard aan, maar controleer het in je hostingpanel of in een phpinfo-uitvoer op een ontwikkelkopie.
3.2 De database
Draai een actuele MariaDB of MySQL, en geef hem geheugen om mee te werken (de InnoDB buffer pool). Op shared hosting heb je hier weinig invloed, wat een reden te meer is waarom hostingkeuze een prestatiebeslissing is: vraag hosts naar PHP-versies, OPcache, databasetuning en SSD-opslag voordat je tekent.
3.3 HTTP/2 en moderne TLS
HTTP/2 (of HTTP/3) laat browsers veel assets over een verbinding ophalen, wat vooral pagina's met veel CSS-/JS-/afbeeldingsbestanden helpt. Het komt gratis met elke degelijke hosting-stack over HTTPS - bevestig het een keer met een online checker. Serveert je host in 2026 nog HTTP/1.1, dan zegt dat ook iets over de rest van hun stack.
Naar boven4. Joomla-instellingen die ertoe doen
4.1 Gzip-paginacompressie
Algemene configuratie → Server → Gzip-paginacompressie (gzip): Joomla comprimeert zijn HTML-uitvoer voor verzending. HTML comprimeert extreem goed - typisch tot een kwart van de grootte - dus dit is gratis winst, tenzij je server al op webserverniveau comprimeert (laat het dan aan de server). Biedt de server Brotli, kies dat dan boven gzip - het comprimeert beter - en houd de regel uit sectie 14.5 aan: elk antwoord precies een keer gecomprimeerd.
Op LiteSpeed en OpenLiteSpeed is dit al voor je geregeld. Compressie is daar een serverinstelling (Server Configuration → Tuning → Enable Compression), die staat standaard aan, en ze dekt ook dynamische PHP-uitvoer met zowel Brotli als gzip - OpenLiteSpeed levert standaard een dynamisch Brotli-niveau van 2. Laat Joomla's gzip daar uit. LiteSpeed hercomprimeert een antwoord dat al een Content-Encoding heeft niet, dus gzip aanzetten in Joomla kost PHP-tijd en zet je bezoekers terug van Brotli naar gzip. Controleer wat er echt binnenkomt:
curl -sI -H 'Accept-Encoding: br,gzip' \
https://example.com/ | grep -i content-encodingOp een gezonde LiteSpeed antwoordt dat br.
4.2 Caching aan
Caching is de grootste schakelaar op Joomla-niveau: conservatieve caching in de Algemene configuratie plus de plugin Paginacache voor gastbezoekers kan serverresponstijden van honderden milliseconden naar een paar terugbrengen. Het Focus On-artikel over Joomla-cache behandelt de niveaus, de handlers (waaronder Redis en Memcached voor drukke sites) en de valkuilen met ingelogde gebruikers - lees dat als de metgezel van deze sectie in plaats van het hier herhaald te krijgen.
4.3 Sessies
De standaard database-sessiehandler is prima voor de meeste sites. Drukke sites schrijven sessiedata bij elk request, en sessies verplaatsen naar Redis (waar hosting dat biedt) haalt die last van de database. Houd de scheduler-plugin Task - Session GC actief zodat verlopen sessies echt opgeruimd worden.
4.4 Zet uit wat je niet gebruikt
Debug systeem uit in productie (het voegt werk toe aan elk request), ongebruikte plugins uitgeschakeld, statistiekmodules die je nooit leest gedepubliceerd. Elke ingeschakelde extensie draait code; sectie 7 maakt dit systematisch.
Naar boven5. Afbeeldingen: het zwaarste deel van bijna elke pagina
5.1 Juiste maat, juist formaat
De meest voorkomende prestatiefout in het wild is een foto van 4000 pixels geperst in een kolom van 400 pixels. Twee regels lossen de meeste afbeeldingsproblemen op:
- Verklein naar de getoonde maat voor of tijdens de upload. Joomla's mediabeheer bevat core media action-plugins - bijsnijden, verkleinen, roteren - zodat redacteuren afmetingen kunnen repareren zonder de backend te verlaten.
- Gebruik moderne formaten: het mediabeheer accepteert standaard
webpenavif, en beide zijn dramatisch kleiner dan JPEG/PNG bij dezelfde visuele kwaliteit. Converteren is de ene stap die de Joomla core niet voor je doet - gebruik een beeldbewerkingstool of een extensie voor bulkconversie.
5.2 Lazy loading
Browsers stellen afbeeldingen buiten beeld van nature uit wanneer het attribuut loading="lazy" aanwezig is. De Joomla core voegt het niet automatisch toe aan intro- en volledige artikelafbeeldingen - wat dit tot een perfecte template override maakt: voeg loading="lazy" (plus breedte en hoogte) toe aan de afbeeldingsmarkup in je override van de artikel-layouts, en elke artikelafbeelding onder de vouw stopt met concurreren met de zichtbare content. Houd het attribuut weg van de LCP-afbeelding (de grote zichtbare bovenaan) - die lazy laden maakt de pagina juist trager.
5.3 Afmetingen tegen verspringende layout
CLS - de verspringende layout - is meestal afbeeldingen zonder afmetingen. Geef altijd breedte en hoogte op (of CSS aspect-ratio) zodat de browser de ruimte reserveert voordat de afbeelding arriveert. Het mediabeheer vult de velden voor je bij het invoegen van afbeeldingen in de editor; overrides horen ze te behouden.
6. Assets: CSS, JavaScript en de Web Asset Manager
6.1 De Web Asset Manager doet de boekhouding
Joomla's Web Asset Manager laadt CSS en JavaScript via benoemde assets met afhankelijkheden en gewichten (het Cassiopeia-artikel loopt door een echte joomla.asset.json). Voor prestaties telt het omdat assets een keer laden, in de juiste volgorde, ontdubbeld - en omdat script-assets attributen zoals defer kunnen declareren, zodat JavaScript het renderen niet meer blokkeert. Voeg je eigen assets toe, registreer ze dan netjes in plaats van script-tags in templates te plakken.
6.2 Laad assets alleen waar ze gebruikt worden
De goedkoopste kilobytes zijn degene die je nooit verstuurt. Slider-scripts, gallerij-CSS, kaartbibliotheken: die horen alleen op de pagina's die ze tonen, niet in het globale template. De Web Asset Manager maakt dit vanzelfsprekend - registreer de asset een keer, en roep dan useScript()/useStyle() aan in de module-layout of override die de functie echt rendert; Joomla laadt hem op precies die pagina's, ontdubbeld wanneer meerdere blokken om dezelfde asset vragen. Een template doorlichten op globaal geladen assets voor een pagina levert vaak honderden kilobytes op voor elke andere pagina.
6.3 Voorgecomprimeerde assets - al op je server
Weinig mensen weten dat Joomla zijn core-CSS en -JavaScript voorgecomprimeerd meelevert: naast template.min.css staat template.min.css.gz. De meegeleverde htaccess.txt bevat een kant-en-klaar (uitgecommentarieerd) blok dat die .gz-bestanden direct serveert aan browsers die gzip accepteren - dat bespaart bytes en realtime compressiewerk. Comprimeert je server assets nog niet, schakel dat blok dan in: het is gratis snelheid die werkloos op de schijf ligt. Een uitzondering: op LiteSpeed en OpenLiteSpeed doet dat blok niets. Die servers lezen wel rewrite-regels uit .htaccess, maar negeren mod_deflate-directives zoals AddOutputFilterByType - compressie bestaat daar alleen als hun eigen gzip- en Brotli-instellingen, en ze bewaren sowieso een gecomprimeerde kopie van statische bestanden in hun eigen cache.
6.4 Lettertypen en derde partijen
Elk extern domein kost een verbinding voordat de eerste byte arriveert. De aanpak van Cassiopeia - lettertypen en libraries lokaal gehost, geen CDN-aanroepen - is de juiste standaard voor prestaties en privacy tegelijk. Drie lettertyperegels betalen zichzelf terug: beperk de site tot een of twee families in de gewichten die je echt gebruikt, declareer font-display: swap zodat tekst meteen rendert met een terugvallettertype, en preload het ene fontbestand waar je koppen van afhangen. Doorloop je derde partijen: elk analytics-snippet, chatwidget en social embed levert JavaScript dat met je content concurreert. Houd wat zijn kosten waard is; schrap de rest.
6.5 Templategewicht
Template-frameworks en pagebuilders ruilen gemak tegen gewicht: meerdere CSS-frameworks, jQuery naast moderne scripts, iconenfonts voor drie iconen. Je hoeft de site niet te herbouwen om dit te verbeteren - maar kies je een template voor een nieuw project, bekijk dan de broncode van de demo en tel de requests. Lichte templates bestaan, en Cassiopeia met een child template is er een.
Naar boven7. Extensies, modules en query-discipline
7.1 Elke extensie draait code
Plugins draaien op events - sommige bij elk request. Modules draaien query's om hun uitvoer op te bouwen. Een site met zestig ingeschakelde extensies draagt bij elke paginaweergave de kosten van zestig codebases. De doorlichting is dezelfde als in het artikel over security hardening, met dezelfde conclusie: deinstalleer wat je niet gebruikt, en kies een goede extensie boven drie overlappende.
7.2 De dure vinden
Met Debug systeem aan (ontwikkelkopie) lees je per pagina de querylijst: die benoemt de module of component achter elke query. De gebruikelijke verdachten zijn "gerelateerde artikelen"- en "laatste nieuws"-modules met diepe categoriebomen, slecht gecachete menu's, en zoekmodules die bij elke lading dingen tellen. De meeste modules hebben een eigen cache-instelling onder Geavanceerd - gebruik die, zoals het cache-artikel uitlegt.
7.3 Contentdiscipline
Prestaties wonen ook in redactionele gewoonten: een homepage die veertig volledige artikelen insluit in plaats van intro's, categorieblogs die honderden items tonen zonder paginering, of een menuboom van zes niveaus diep genereren allemaal werk per request. Structureer content zo dat een pagina toont wat een bezoeker nodig heeft en naar de rest linkt.
Naar boven8. Database en huishouding
8.1 Gepland opruimen
De taakplanner verdient zich ook voor prestaties terug:
| Taak-plugin | Prestatiewaarde |
|---|---|
sessiongc |
Ruimt verlopen sessies op zodat #__session klein blijft. |
deleteactionlogs |
Snoeit de gebruikersactielog voordat hij miljoenen rijen groeit. |
checkfiles |
Signaleert te grote bestanden - de PDF van 40 MB die iemand naar de afbeeldingenmap uploadde. |
globalcheckin |
Geeft oude vergrendelingen vrij die redacteuren laten herladen en opnieuw proberen. |
8.2 Tabellen die stilletjes groeien
Een paar tabellen groeien met het gebruik mee en verdienen af en toe een blik: de actielogs, de indextabellen van Smart Search (herbouw de index na grote contentwijzigingen), en logtabellen van extensies van derden. Het database-onderhoud onder Systeem → Database houdt het schema in vorm na updates; je databasetool laat zien welke tabellen echt de megabytes bevatten.
8.3 Limieten op versiegeschiedenis
Joomla bewaart contentversies per item; de versielimiet in de opties van elke component begrenst hoeveel versies bewaard blijven. De standaard is verstandig - zet hem alleen niet op iets enorms op een site met duizenden artikelen.
Naar boven9. CDN's en reverse proxies
9.1 Wat een CDN je echt oplevert
Een content delivery network cachet je statische bestanden (en optioneel hele pagina's) op servers dicht bij je bezoekers. Voor een Nederlandse site met Nederlandse bezoekers op degelijke hosting is de winst bescheiden. Voor internationaal publiek, of als schild voor bescheiden hosting, is hij aanzienlijk: assets komen van 30 km in plaats van 3000, en verkeerspieken raken het CDN in plaats van je server.
9.2 De praktische route
De gangbare opzet is een proxy-CDN (Cloudflare en vergelijkbare): DNS wijst naar het CDN, dat statische assets automatisch cachet en paginaverzoeken doorstuurt naar Joomla. Het combineert vanzelf met de WAF-rol uit het artikel over security hardening - een dienst, twee taken. Joomla heeft er geen speciale configuratie voor nodig; zet behind_loadbalancer aan in de Algemene configuratie zodat Joomla echte bezoekers-IP's ziet, en leeg de CDN-cache wanneer je grote wijzigingen uitrolt.
9.3 Houd de oorsprong eerlijk
Een CDN verbergt traagheid van de oorsprong voor anonieme bezoekers en statische bestanden - niet voor ingelogde gebruikers, formulieren, afrekenprocessen of de backend. Tune eerst Joomla, en voeg dan het CDN toe als buitenste laag, niet als pleister op een ongetunede site.
Naar boven10. Prestatierecepten uit de praktijk
10.1 De opknapbeurt van een middag (elke site)
- Meet de drie belangrijkste pagina's in PageSpeed Insights; bewaar de getallen.
- Werk Joomla, extensies en PHP bij naar actuele versies.
- Zet gzip, conservatieve caching en de Paginacache-plugin aan (sites met alleen gasten).
- Schakel het blok voor voorgecomprimeerde assets in
.htaccessin. - Repareer de vijf zwaarste afbeeldingen (verkleinen, naar WebP converteren).
- Meet opnieuw en archiveer het voor-en-na.
10.2 Het afbeeldingszware blog
Voeg loading="lazy" plus afmetingen toe via artikel-layout-overrides, bulkconverteer de afbeeldingsbibliotheek naar WebP, en laat de taak checkfiles toekomstige te grote uploads signaleren. De Largest Contentful Paint halveert meestal.
10.3 De communitysite met ingelogde gebruikers
Paginacaching is nauwelijks van toepassing (zie het cache-artikel), dus verleg de inspanning: Redis voor sessies en cache, modulecaching waar de content het toelaat, query-discipline in de drukste modules, en een CDN voor de statische assets die voor iedereen gelijk zijn.
10.4 De internationale brochuresite
Bescheiden content, bezoekers overal: proxy-CDN met volledige paginacaching voor gasten, lange browser-cachetijden voor assets, en lokaal gehoste lettertypen. De oorsprongsserver doet nauwelijks nog iets.
Naar boven11. Onder de motorkap (ontwikkelaarsblik)
11.1 De profiler lezen
Met JDEBUG aan toont de debugbalk profiling-markeringen (afterLoad, afterDispatch, afterRender) met tijden en geheugen - die vertellen of de tijd verdwijnt in het opstarten, de component of het renderen - plus elke query met duplicaten gemarkeerd. Dat onderscheid bepaalt waar je optimaliseert: trage dispatch betekent component-/modelwerk; traag renderen is vaak template- of modulewerk.
11.2 De klassieke trage patronen
- Query's in lussen: items een voor een laden in plaats van een query met
whereIn(). De querylijst maakt dit meteen zichtbaar - vijftig bijna identieke query's op rij. - Businesslogica in overrides: zoals het overrides-artikel waarschuwt, draait een override die modellen aanroept onzichtbare query's bij elke render.
- Niet-gecachet duur werk in modules en plugins: wikkel het in de caching-API (zie het cache-artikel) met een verstandige levensduur.
- Events die zwaar werk doen bij elk request: een plugin geabonneerd op
onAfterInitialisebetaalt zijn kosten bij elke paginaweergave - houd die handlers triviaal.
11.3 Lever prestatievriendelijke extensies
Registreer assets via de Web Asset Manager met defer waar mogelijk, declareer afhankelijkheden in plaats van je eigen kopie van een library te bundelen die Joomla al meelevert, maak je query's pagineringsbewust, en geef je modules een cache-optie. Extensies die zo gebouwd zijn, overleven de doorlichtingen van sectie 7.
12. Prestaties en de Web Services API
API-antwoorden slaan de hele frontend-laag over - geen template, geen modules, geen assets - dus ze zijn van nature licht; de kosten die overblijven zijn het model en de database. De paginacache geldt niet voor API-verzoeken, dus zware API-afnemers hebben hun eigen strategie nodig: vraag alleen benodigde velden op, pagineer eerlijk, en cache antwoorden aan de afnemende kant met normale HTTP-caching-semantiek.
Draai je integraties die de API vaak bevragen, houd ze dan in de gaten in de serverlogs: een goedbedoeld script dat elke minuut een volledige artikellijst ophaalt, kan meer databaselast genereren dan alle menselijke bezoekers samen. Geef integraties eigen accounts (zoals het ACL-artikel aanraadt) zodat hun verkeer herkenbaar is, en spreek verstandige polling-intervallen af of gebruik triggers via de taakplanner.
Naar boven13. SEO en metadata
Prestaties zijn een van de weinige technische onderwerpen waar het SEO-voordeel officieel is: Google bevestigt paginabeleving, gemeten via de Core Web Vitals, als rankingsignaal, en metingen bij je echte bezoekers voeden het. De praktische implicatie: lab-scores zijn diagnostiek, maar de velddata in het Core Web Vitals-rapport van Search Console is het getal dat telt - bekijk het maandelijks.
Snelheid bepaalt ook het crawlen: zoekmachines kennen per site een crawlbudget toe, en een server die in 200 ms antwoordt, krijgt meer pagina's per dag gecrawld dan een die er 2 seconden over doet. Op grote sites vertalen snellere antwoorden zich direct in versere indexering. En elke redirect-keten, kapotte afbeelding en time-out verspilt crawlbudget zoals hij bezoekersgeduld verspilt - het artikel over redirects en dit artikel lossen hetzelfde probleem van twee kanten op.
Naar boven14. Veelvoorkomende fouten en valkuilen
14.1 Optimaliseren zonder te meten
Symptoom: weken tunen, geen meetbaar verschil - of een site die trager werd.
Oplossing: eerst een referentiemeting (sectie 2), een wijziging tegelijk, na elke wijziging meten. Verwijder de wijzigingen die de getallen niet bewogen; complexiteit zonder voordeel is puur risico.
14.2 De hero-afbeelding van 4 MB
Symptoom: een prachtige homepage met een LCP van acht seconden op mobiel.
Oplossing: verklein naar de weergavemaat, converteer naar WebP, en lazy-laad nooit de LCP-afbeelding zelf. Deze ene reparatie verslaat op de meeste sites elke servertweak bij elkaar.
14.3 Debug-modus in productie
Symptoom: elke pagina draagt profiling-overhead, en de voettekst lekt querydetails naar bezoekers.
Oplossing: Debug systeem uit in productie, altijd. Profileer op een kopie.
14.4 Caching als pleister
Symptoom: de gecachete pagina is snel, maar elke cache-misser (en elke ingelogde gebruiker) wacht drie seconden.
Oplossing: caching vermenigvuldigt een snelle site; hij maskeert een trage. Repareer eerst de onderliggende query- en assetproblemen, en cache dan het resultaat.
14.5 Verwarring door dubbele compressie
Symptoom: gzip aan in Joomla en op de server, of het voorgecomprimeerde-assets-blok aan terwijl de server al comprimeert - af en toe met verminkte uitvoer of verspilde CPU als gevolg.
Oplossing: comprimeer elk antwoord precies een keer. Controleer de response-headers (Content-Encoding); regelt de server het al, laat Joomla's gzip dan uit en sla het htaccess-blok over. Op LiteSpeed en OpenLiteSpeed is het symptoom stiller en de schade echt: de server accepteert de gzip die PHP al maakte in plaats van zijn eigen Brotli toe te passen, dus de pagina blijft correct maar komt groter aan dan nodig.
14.6 De verzameling scripts van derden
Symptoom: analytics, tagmanager, twee chatwidgets, social embeds - en een INP die op elke telefoon zakt.
Oplossing: inventariseer elk extern script, meet zijn kosten in het prestatietabblad, en houd alleen wat aantoonbaar geld of inzicht oplevert. Laad wat overblijft met defer.
Naar boven15. Best practices
Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:
- Meet voor en na elke wijziging; Core Web Vitals op mobiel zijn het scorebord.
- Repareer eerst afbeeldingen: juiste maat, WebP/AVIF, lazy loading onder de vouw, altijd afmetingen.
- Draai actuele PHP met OPcache, op hosting die je koos met prestatievragen in de hand.
- Zet gzip, conservatieve caching en de Paginacache-plugin aan waar de site het toelaat - en lees het cache-artikel voor de details.
- Serveer de voorgecomprimeerde assets die Joomla al meelevert, via het htaccess-blok.
- Doorloop extensies en scripts van derden jaarlijks; deinstalleer, schakel niet alleen uit.
- Laat de taakplanner de huishouding doen: sessies, logs, te grote bestanden.
- Voeg een CDN toe als buitenste laag voor internationaal publiek - nadat de oorsprong getuned is, niet in plaats daarvan.
- Ontwikkelaars: lees de profiler, houd query's uit lussen en overrides, registreer assets met defer.
16. In het kort
METEN PageSpeed Insights / Lighthouse, mobiel, 3 kernpagina's
CWV-doelen: LCP <= 2,5s INP <= 200ms CLS <= 0,1
TTFB = kale serverrespons (caching-/hostingterrein)
Joomla: querylijst van Debug systeem (alleen dev-kopie)
SERVER actuele PHP + OPcache aan, actuele MariaDB/MySQL
HTTP/2 of HTTP/3 over HTTPS
JOOMLA gzip Aan (tenzij de server comprimeert)
caching Conservatief + Paginacache-plugin (gasten)
sessies: database prima, Redis voor drukke sites
debug Uit in productie
BEELD verkleinen naar weergavemaat (media actions)
webp / avif geaccepteerd door mediabeheer
loading="lazy" onder de vouw (via override, niet core)
nooit de LCP-afbeelding lazy laden; altijd breedte+hoogte
ASSETS Web Asset Manager: afhankelijkheden + defer
pagina-specifiek: useScript()/useStyle() waar gebruikt
het .gz-voorcompressieblok in .htaccess inschakelen
fonts lokaal, 1-2 families, font-display: swap
scripts van derden doorlichten; Brotli > gzip waar mogelijk
HUISHOUDEN scheduler: sessiongc, deleteactionlogs, checkfiles,
globalcheckin; let op actielog + finder-tabellen
CDN proxy-CDN voor internationaal bereik + piekbescherming
behind_loadbalancer Aan; legen bij deployments
eerst de oorsprong tunen
DEV profiler: dispatch traag = model, render traag =
template/modules; geen query's in lussen of overrides
module-cache-optie; whereIn() boven query's per item
VOLGORDE afbeeldingen > caching+gzip > extensies > server > CDN17. Samenvatting
Joomla-prestatiewerk is een volgorde, geen geheim:
- Meet eerst: Core Web Vitals voor de bezoekerservaring, Joomla's debug-querylijst voor de PHP-kant.
- Fundament: actuele PHP met OPcache, een gezonde database, HTTP/2 - hosting is een prestatiebeslissing.
- Joomla-schakelaars: gzip, caching (het cache-artikel is de diepe duik), slanke sessies, debug uit.
- De frontend is het slagveld: afbeeldingen op maat in moderne formaten met lazy loading en afmetingen, assets via de Web Asset Manager, de meegeleverde voorgecomprimeerde bestanden echt geserveerd, derde partijen doorgelicht.
- Discipline: minder extensies, gecachete modules, geplande huishouding, eerlijke contentstructuur.
- De buitenste laag: een CDN voor bereik en veerkracht zodra de oorsprong snel is.
Niets hiervan vereist exotisch gereedschap - vrijwel alles in dit artikel komt met Joomla of met je hosting mee. Wat het wel vereist: meten, de saaie reparaties in de juiste volgorde doen, en de neiging weerstaan om een plugin te kopen voordat je het probleem begrijpt.
Zakt jouw site voor zijn Core Web Vitals en kun je niet zeggen waarom, dan vindt een gestructureerde prestatie-audit - meten, laag voor laag, grootste kostenpost eerst - meestal dat tachtig procent van de traagheid twee of drie oorzaken heeft. Die methodisch vinden in plaats van gokken is precies het soort werk dat een Joomla-specialist goed af gaat, en het verschil is dezelfde middag meetbaar.
Naar boven
