Is jouw WordPress traag? Dan verspil je een hoop potentie. Niet alleen zijn je bezoekers geïrriteerd door de trage laadtijden, je kunt ook je zichtbaarheid in Google verliezen. Ik zal je stap voor stap laten zien hoe je WordPress sneller kunt maken.

Als je iets verkoopt via WordPress, bijvoorbeeld met WooCommerce, dan is er genoeg onderzoek om te bevestigen dat trage websites per saldo minder inkomsten opleveren. Vooral mobiele gebruikers zullen een website verlaten als het langer dan drie seconden duurt om te laden. Snellere websites zijn van vitaal belang voor je bedrijf.

Snelheid meten

Als je een website sneller wilt maken, moet je eerst meten hoe snel/langzaam hij is voordat je optimaliseert. De zuivere laadtijd is belangrijk, maar niet noodzakelijk doorslaggevend. Sommige websites hebben gewoon grote "assets" (bijvoorbeeld afbeeldingen en video) die bezoekers willen zien of downloaden. Sneller is altijd beter, maar het hangt ook af van de verwachtingen van de bezoeker. Bijvoorbeeld, apple.com heeft beruchte slechte prestaties:

Dat is niet echt optimaal. Deze omstandigheid is echter gegrond. Apple hecht er zeer veel waarde aan zijn eigen producten in de hoogst mogelijke kwaliteit weer te geven en gebruikt daarom enorm grote afbeeldingen zonder ze te optimaliseren, zoals deze gids voor WordPress laat zien. Bezoekers van Apple nemen dit voor lief en zijn blij dat ze iets langer moeten wachten tot de pagina geladen is.

Over het algemeen voelen de prestaties van de Apple site vrij snel aan. Vooral de weergave van de eerste elementen is meestal bliksemsnel. Deze worden gemeten onder het aspect "First Contentful Paint " (FCP). Het FCP bepaalt in perceptie hoe snel het laden van een pagina "aanvoelt". Daarom speelt FCP een bijzonder belangrijke rol bij de optimalisering. Waarden van 2 tot 3 seconden mogen niet worden overschreden. Onder de 2 seconden of sneller is beter.

De "Largest Contentful Paint" (LCP) geeft de laadtijd van de resterende elementen van de hoofdinhoud weer. Als je hier onder de 3 seconden kunt blijven, ben je al behoorlijk goed. Grote productafbeeldingen en soortgelijke assets kunnen deze waarde echter ook aanzienlijk opdrijven, wat prima in orde is, afhankelijk van het doel.

De "First Input Delay" (FID) meet de tijd die verstrijkt voordat je bezoekers daadwerkelijk met de pagina kunnen interageren. Bijvoorbeeld het markeren van een tekstpassage, het klikken op een link of button, enz. Een site kan bijvoorbeeld een zoekvakje hebben. Misschien duurt het 10 seconden om deze pagina volledig te laden. Hoe snel kan iemand het zoekvak aanklikken en intypen? Denk eraan: de "gebruiker" is niet altijd een mens. Vaak zijn het bots die met pagina's interageren. Bijvoorbeeld de Google bot, die de prestaties van de pagina meet en deze waarden meeneemt in de berekening van de ranking.

De "Cumulative Layout Shift" (CLS) moet overal worden vermeden. Als een lay-out "verschuift" tijdens het laden, kan dit enorm irritant zijn voor je bezoekers. Klikken op de verkeerde button kan het resultaat zijn. In de meeste gevallen worden dergelijke verschuivingen veroorzaakt door ontbrekende breedte- en lengtespecificaties (breedte/hoogte) voor afbeeldingen. De CLS zou altijd 0 moeten zijn.

Deze vier waarden zijn dus doorslaggevend bij het evalueren van de snelheid van een WordPress website. Zij zijn gericht op de user, d.w.z. niet op ruwe prestatiewaarden zoals de Time to first byte, die een belangrijke rol speelt bij de beoordeling van de serverprestaties of de verbinding met de server. Dit betekent ook dat deze waarden minder worden bepaald door caching en selectie voor WordPress hosting, ook al speelt dit natuurlijk ook een grote rol in de WordPress prestaties. Ze worden veel meer bepaald door de vakkundige opbouw van een pagina en het juiste gebruik van HTML, CSS en JavaScript.

Prestatie-optimalisering is de laatste jaren vrij ingewikkeld geworden. Vooral nu Google heeft aangekondigd dat ze de gebruikersgerichte prestatiecriteria in de rankingberekening zullen opnemen. De beste tools om je WordPress performance te meten:

• PageSpeed Insights van Google
• GTmetrix
• Lighthouse is rechtstreeks ingebouwd in de ontwikkelaarstools van Google Chrome.
• TREO Site Speed

Persoonlijk hou ik van TREO omdat het snel en duidelijk is. PageSpeed Insights en GTmetrix zijn zeer gedetailleerd.

Met deze kennis en tools ben je goed uitgerust om je eigen prestaties te meten. Als je dit zelf doet, stel ik de volgende aanpak voor:

• Meet eerst de begintoestand. Hoe snel is je website vóór optimalisatie?
• Activeer of implementeer een optimalisatie.
• Dan kun je de prestaties opnieuw meten. Heeft het aantoonbaar een verschil gemaakt? Zo niet, verwijder de optimalisatie en probeer iets anders. Zo ja, houd de optimalisatie dan. Test of alles nog werkt zoals voorheen en voeg nog een optimalisatie toe.

Velen proberen een score van 100 te halen op PageSpeed Insights . Daar is voorlopig niets mis mee, behalve dat het niet nodig is om de volledige score te krijgen. Andere tools meten anders en wat een 100 is op PageSpeed Insights is misschien niet zo goed op GTmetrix. Trouwens, van een 30 naar een 90 gaan is duidelijk belangrijker dan van een 90 naar een 100 gaan.

WordPress prestaties verbeteren

Snellere WordPress hosting

DE snelste hoster in elke situatie en op elk moment bestaat niet. Er zijn te veel factoren die van invloed zijn op de leveringstijd en de verwerking van verzoeken. De volgende factoren maken de beoordeling niet gemakkelijk:

• Tijdstip van de dag
• Servergebruik
• Geolocatie
• De snelheid van de verbinding van de gebruiker.

Niettemin biedt elke hoster verschillende pakketten aan die een aanzienlijke impact kunnen hebben op de prestaties van een WordPress website. Instappakketten zijn meestal goedkoper en uiteraard niet zo snel. Daarom is een van de eerste verstandige optimalisaties eigenlijk het upgraden van het pakket.

Bij Raidboxes bijvoorbeeld zijn er starterpakketten in Managed WordPress Hosting die het administratieve werk met WordPress voor hun rekening nemen en al optimalisaties zoals serverzijdige caching bevatten. Maar er zijn ook bijzonder performante pakketten in High Traffic Hosting, bijvoorbeeld voor projecten met zeer hoge toegangsaantallen. Er zijn ook speciale tarieven voor de WooCommerce Hosting van je webshop. Het spreekt voor zich dat de grotere pakketten voor een extra prestatieverhoging zorgen.

Eén ding is duidelijk: als je meer betaalt, krijg je meestal ook meer performance. Dit geldt natuurlijk voor alle hosters. Bijna alle prestatieverbeteringen worden verhoogd door tariefupgrades. Maar wat kan worden bereikt zonder direct over te schakelen op een hoger tarief?

WordPress caching gebruiken

Afgezien van de eenvoudigste blogs, gebruikt bijna elke WordPress site een verscheidenheid aan andere plugins. In de regel vertragen plugins de laadtijd met een fractie van een seconde telkens wanneer de pagina wordt opgeroepen. Vooral als de plugin elementen in de HTML-code invoegt, die dan extra moeten worden geladen of anders nog meer database-query's moeten uitvoeren.

Wat als WordPress deze extra "taken" maar één keer per site hoefde uit te voeren en het resultaat van deze "extra" bewerkingen gewoon bij de volgende oproep uit de cache zou halen? Dit zou het volgende laadproces aanzienlijk versnellen, omdat de server dan alleen nog maar een voltooid bestand hoeft af te leveren. In het ideale geval vinden er geen verdere berekeningen plaats, wat de laadtijd drastisch verminderd. Een pagina die er bijvoorbeeld 5 seconden over doet om oncached te laden, kan binnen milliseconden worden geleverd. Snelheidsverbeteringen van 20 tot 100 keer zo snel zijn niet ongewoon wanneer caching is ingeschakeld.

Caching oplossingen zijn essentieel voor het versnellen van WordPress websites. Idealiter via een server-gebaseerde oplossing, meer daarover zo meteen meer. Gebruik anders een van de cachingplugins die erg populair zijn in de community:

• WP Fastest Cache (gratis + tegen betaling)
• LiteSpeed Cache (gratis, maar werkt alleen met de LiteSpeed Web Server)
• WP-Optimize (gratis + tegen betaling)
• WP Super Cache (gratis, van de WordPress fabrikant)
• Hummingbird (gratis + tegen betaling)
• WP Rocket (tegen betaling, hier mijn tutorial op YouTube)
• Cache Enabler (gratis)
• Borlabs Cache (tegen betaling)
• Hyper Cache (gratis)
• Comet Cache (gratis + tegen betaling)

Betaalde plugins hebben meestal meer functies. Gratis plugins helpen echter in de meeste gevallen om 90 procent van alle mogelijke tijdwinst eruit te halen.

Echter, cachingplugins zijn als een verband. Ze verbergen problemen die beter vanaf het begin opgelost kunnen worden. Ze verwijderen niet noodzakelijk overbodige HTML, ze comprimeren geen te grote afbeeldingsbestanden, ze veranderen niet noodzakelijk de volgorde waarin JS en CSS bestanden worden opgenomen, enzovoort. Zelfs gecachete pagina's kunnen dus nog traag zijn.

Als je vanaf het begin netjes werkt, heb je niet echt een cachingplugin nodig. Tenminste theoretisch. Omdat caching in het algemeen natuurlijk de server ontlast en daarom altijd aan te bevelen is. Ik ben hier meer bezorgd over het argument van goede planning en zuivere, doordachte code.

Bovendien berust Raidboxes op een bijzonder krachtige, serverzijdige caching. Dit betekent dat je geen extra plugin of een betaalde oplossing nodig hebt.

Flex containers in plaats van kolommen en rijen in de Page Builder

Page builders of site builders zijn onmisbaar geworden voor veel bureaus en ontwikkelaars, omdat ze het ontwerpen van pagina's en artikelen in hoge mate vergemakkelijken.

Al meer dan 10 jaar is het een standaardprocedure in alle populaire paginabouwers om de lay-out te maken met kolommen en rijen. Dit leidt vaak tot een geneste DIV-salade:

Dit gebeurt vaak op elke afzonderlijke pagina, waardoor de code meestal onnodig wordt opgeblazen en ook negatieve gevolgen kan hebben voor het FCP. Dit kan meestal worden vermeden door een slimme planning bij het maken van de lay-out. Fabrikanten van websitebouwers beginnen nu rekening te houden met de CSS-standaarden Flexbox en Grid bij het maken van lay-outs. Dit is goed nieuws, want het vermindert de hoeveelheid code.

In de huidige versie van de Elementor Page Builder, bijvoorbeeld, kan de flexbox container worden geactiveerd in de instellingen. Dit geeft je niet alleen meer flexibiliteit in het ontwerp, het vermindert ook de HTML-code en maakt de laadtijden sneller.

Een klik op Direction -> Row lijnt de containers in een rij uit. Een eenvoudige structuur met drie containers zal de prestaties niet onmiddellijk drastisch verbeteren. Maar als alle secties, rijen en kolommen met deze nieuwe techniek worden uitgevoerd, kan de winst aanzienlijk zijn. Vooral over veel pagina's en ook bij het optimaliseren van FCP en LCP.

De functie is nog in de alpha fase bij Elementor. Andere builders gebruiken deze nieuwe aanpak al enige tijd en alle bouwers zullen het in de toekomst aanbieden. Daarom is het de moeite waard om de nieuwe manier van werken zo snel mogelijk in de workflow te integreren.

Het is minder belangrijk om CSS-Flexbox en/of CSS-Grid te gebruiken, maar om nesting te vermijden. Theoretisch kan zelfs een op tabellen gebaseerde lay-out uit de jaren 2000 worden geoptimaliseerd door "de-nesting".

Het juiste WordPress theme

Er zijn duizenden themes voor WordPress. Ik weet zeker dat ze allemaal al optimaal getrimd zijn voor de prestaties, toch? Fout. De meeste thema's concentreren zich op de schoonheid. Vanuit verkoopoogpunt is dat logisch. Themes worden vooral gekozen om hun aantrekkelijkheid. Zeer weinig WordPress thema's geven echt prioriteit aan het maken van slanke code – of voor zover het Page Builder betreft: het genereren van slanke code.

Deze themes en builders zijn momenteel aan te bevelen vanuit mijn oogpunt:

• Astra
• GeneratePress
• Blocksy
• Kadence

Dit zijn echte meta-themes, dus ze laten zowat elke denkbare lay-out optie toe, ze hebben een enorme keuze aan chique lay-outs en zijn vanaf de basis geoptimaliseerd voor prestaties. De meeste van deze WordPress thema's kunnen gecombineerd worden met andere Page Builders zoals Elementor. Sommige hebben hun eigen paginabouwer.

Afbeeldingen en andere elementen optimaliseren

De overgrote meerderheid van de websites maakt gebruik van afbeeldingen. Grotere afbeeldingen zien er vaak beter uit, maar verhogen ook de laadtijd. Kleiner is beter, maar hoe dan ook, er zijn een heleboel tips om te overwegen:

• Maximale afmetingen van minder dan 2.000 pixels worden aanbevolen. Grotere afbeeldingen openen beter in een nieuw venster.
• Het juiste formaat is van cruciaal belang. JPEG voor fotografische beelden met veel kleuren en schakeringen, PNG's en GIF's kunnen veel kleiner zijn voor afbeeldingen met minder kleuren. Het beste is om het uit te proberen.
• Vectorafbeeldingen zoals logo's en illustraties zien er geweldig uit als SVG's, zijn oneindig schaalbaar en ook klein. SVG's zijn ook zuivere tekstbestanden met instructies op basis waarvan een afbeelding wordt gemaakt. Als tekstbestanden profiteren zij van GZIP-compressie, waarover zo dadelijk meer.
• Google's WebP-formaat kan JPG-bestanden met nog eens 25 tot 34 procent verminderen.
• WebP bestaat al sinds 2010, maar het nieuwe AVIF-formaat vermindert WebP met nog eens 30 procent en levert vaak een besparing van 50 procent op ten opzichte van JPEG. AVIF heeft nog geen volledige ondersteuning voor alle browsers, maar dit groeit van maand tot maand.

Er zijn plugins die je afbeeldingen in alle formaten omzetten wanneer je ze uploadt en dan gewoon het kleinste bestand integreren. Hier zijn de meest populaire plugins voor WordPress:

• Smush
• Optimus
• EWWW Image Optimizer
• ShortPixel Image Optimizer
• TinyPNG
• Imsanity
• Imagify
• reSmush.it
• Kraken.io Image Optimizer
• WP Compress
• Autoptimize
• WP Offload Media
• Optimole
• Hammy
• Robin image optimizer
• WP Compress
• Imsanity

WP Compress heeft een zeer duidelijke interface en voert compressietaken uit op de achtergrond. De extensie is niet echt goedkoop, maar wel erg handig. Als je liever begint met een gratis plugin, moet je eens kijken naar Imsanity.

De meeste optimaliseringsprogramma's hebben een premium model dat ofwel de beeldgrootte ofwel het aantal beelden beperkt. De uitzondering is Robin. Moet je überhaupt betalen voor zo'n plugin? Het hangt ervan af hoeveel controle je nodig hebt. Het is ook mogelijk de afbeeldingen zelf te optimaliseren met desktop-tools, of op de opdrachtregel (optimizt, compress-images) of online vóór het uploaden (TinyPNG, Shortpixel).

De meeste plugins maken ook afbeeldingen in verschillende, kleinere formaten. Afhankelijk van de resolutie van de browser van de user, wordt een aanzienlijk kleiner bestand direct geïntegreerd, wat opnieuw tot aanzienlijke prestatieverbeteringen leidt.

Lazy Loading betekent dat een afbeelding pas wordt geladen als je bezoekers naar het punt scrollen waar de afbeelding op de pagina verschijnt. De meeste afbeeldingsoptimalisatoren ondersteunen dit. Hier zijn ook gratis plugins voor, bijvoorbeeld Lazy Load van WP Rocket en Lazy Loader. Video's kunnen of moeten ook pas geladen worden als ze "bereikt" zijn, zie Lazy Load for Videos.

Fonts cachen

Behalve afbeeldingen kunnen ook andere onderdelen lokaal (op de server) in de cache worden opgeslagen. Dit verbetert niet alleen de naleving van de internationale wetgeving inzake gegevensbescherming, maar meestal ook de prestaties. Vooral als de lettertypes in de cache staan. Dan downloadt de browser ze één keer en geeft ze de volgende keer direct weer zonder ze eerst te hoeven laden. Dit werkt goed met de WordPress plugin OMGF Host Google Fonts Locally, bijvoorbeeld.

Selectief laden van assets per pagina

Een bijzonder effectieve methode om meer snelheid te krijgen is het selectief laden van CSS en JS bestanden per pagina of post. Er zijn verschillende mogelijkheden die naar het doel leiden.

Een voorbeeld: De WordPress website gebruikt een formulier manager zoals WPForms. Deze plugin laadt zijn formulierfuncties onmiddellijk op elke pagina. Deze functionaliteit is echter alleen nodig op de contactpagina. Freesoul Deactivate Plugins is een plugin die dit ondersteunt:

Het maakt het activeren of deactiveren van alle plugins per pagina mogelijk via een matrix. Het is ook mogelijk om hiervoor performance plugins zoals perfmatters te gebruiken, die ook de levering van CSS en JS bestanden verhinderen. Freesoul onderdrukt echter het laden van de hele plugin, dus het vermindert ook het werk dat op de achtergrond op de server moet worden gedaan.

Tweaks met perfmatters

Is het de moeite waard om een plugin zoals perfmatters te kopen? Alle optimalisaties kunnen ook handmatig of met andere plugins worden gedaan. Dat zou echter een waanzinnig grote hoeveelheid werk zijn, vooral als het voor meerdere WordPress websites gedaan moet worden.

Alleen al in de normale opties heeft een plugin als perfmatters meer dan twee dozijn optimalisaties. Zijn ze allemaal nuttig? Dat hangt af van hoe vertrouwd WordPress gebruikers zijn met de functies. De RSS-feed kan bijvoorbeeld worden uitgeschakeld, wat een paar bytes bespaart. Maar het betekent ook dat bezoekers van de website zich niet langer eenvoudigweg kunnen abonneren op de artikelen via RSS feed. Dus je moet hier goed over nadenken.

Het is verbazingwekkend hoeveel speeltjes WordPress standaard heeft geactiveerd (emoji's, dashicons, enz.); ze kunnen voorlopig veilig worden gedeactiveerd. Je moet voorzichtiger zijn met de instellingen met betrekking tot de database. Theoretisch zou het deactiveren van de revisies veel werktijd kunnen verspillen. Als er toch een cache wordt gebruikt, zijn database-optimalisaties meestal niet erg belangrijk.

Daarentegen is het gebruik van Google Maps op een pagina meestal een ramp voor de prestaties. Deze kaarten moeten echt alleen worden geladen als het dringend noodzakelijk is. Veel themes bevatten bijvoorbeeld een kaart op de startpagina, maar dit is niet absoluut noodzakelijk. Bij WooCommerce onlineshops kan het oproepen van wc-ajax=get_refreshed_fragments ernstige vertragingen veroorzaken. Deze kunnen worden uitgeschakeld met "Disable card fragments".

In ieder geval is het de moeite waard om de documentatie van perfmatters en WP Rocket te bekijken. Als je er echt in wilt duiken, vind je daar veel aanknopingspunten. Natuurlijk kun je ook gewoon een van deze plugins kopen en jezelf een hoop tijd besparen. Je zult echter minder begrijpen van wat er op de achtergrond gebeurt.

Minificatie

Minificatie verwijdert onnodige tekens, vooral spaties en tabs uit HTML, CSS en JS-bestanden. Het is meer best practice dan dat het echt een grote prestatieboost geeft. Met Autoptimize kan minificatie heel eenvoudig worden in- of uitgeschakeld.

Gzip-compressie en Brotli

In vergelijking met minificatie wordt de bestandsgrootte van tekstbestanden door compressie vaak met meer dan 50 procent teruggebracht. Het is zeker de moeite waard om dit aan te zetten, bijvoorbeeld het Brotli compressie-algoritme. In de meeste gevallen is deze compressie al ingeschakeld door de webhoster. Zo niet, dan zijn er aanvullende tools die de gecomprimeerde bestanden in het bestandssysteem opslaan. Vooral omdat de compressie van tekstbestanden meestal veel doeltreffender is.

Brotli is een compressieformaat dat door Google ontwikkeld is en dat nog efficiënter is dan Gzip. Natuurlijk, Brotli wordt ook ondersteund door Raidboxes.

Aanzienlijke optimalisaties voor JavaScript en CSS

Vooral wat de optimalisatie voor FCP en LCP betreft, zijn er tegenwoordig manieren om drastische prestatieverbeteringen te bereiken via diverse plugins en zelfs rechtstreeks in de themes. In mijn tests zijn dit zelfs vaak de beste technieken om een pagina in het 90 tot 100 bereik te brengen. Dat is het vertraagde herladen van de CSS- en JS-bestanden.

In de gratis plugin Autoptimize is er een instelling "Aggregate JS-files". Dit is standaard geactiveerd. Om van echte versnelling te genieten, zijn de volgende instellingen noodzakelijk:

De "Defer-Option" zorgt ervoor dat JavaScript pas later in het renderproces wordt geladen. HTML en assets worden eerst geladen, dan JS. In de praktijk betekent dit dat met name interactieve elementen in de eerste seconden niet onmiddellijk beschikbaar zijn. Maar de site zelf wordt bliksemsnel weergegeven.

Aangezien JavaScript zo ongeveer alles programmatisch kan herladen, moet deze techniek met voorzichtigheid worden behandeld. Er kan hier veel misgaan. Dit is ook de reden waarom de optie niet standaard geactiveerd is. De prestatiewinst kan gigantisch zijn, maar na activering moet je elke pagina controleren om te zien of het nog goed werkt.

Hetzelfde geldt na elke update en bij gebruik van nieuwe plugins die hun eigen JavaScript-bestanden in het spel kunnen brengen. Het activeren van deze optie is dan ook alleen aan te raden als je achteraf en regelmatig wat tijd kunt investeren in de controle ervan.

De situatie is vergelijkbaar voor de CSS bestanden. Hier moet "Eliminate render-blocking CSS" geactiveerd zijn. Met CSS-instructies is er het bijkomende probleem dat bepaalde pagina's of zelfs gebieden op de website er net iets anders uit moeten zien. Een deel van de s iteziet er hetzelfde uit (kleuren, lettertypes, positie van de header), maar een ander deel ziet er anders uit (afbeelding in de header, extra info in de footer, enz.)

Autoptimize verwijst hier naar een externe en betalende dienst die dit probleem probeert op te lossen. "Critical CSS" is de CSS die helemaal aan het begin geladen moet worden. De rest kan later worden geladen.

Plugins zoals WP Rocket en perfmatters hebben ook zo'n functie. Hoe goed dit werkt hangt af van welke plugins je op je eigen WordPress website wilt gebruiken. Dus het werkt alleen met een test. Maar als het werkt, dan is de boost echt groot.

Deze functie gratis krijgen is momenteel bijna onmogelijk, omdat het een moeilijk probleem is. Want elke website is anders. Zelfs elke subpagina op een website is anders en verandert voortdurend door updates. De enige manier om hier 100 procent performance uit te halen is een diepgaand begrip te ontwikkelen van wat er werkelijk gebeurt wanneer elke pagina wordt geladen. Alleen als je bereid bent deze tijdrovende weg te bewandelen, kun je daadwerkelijk een 100 halen voor elke pagina.

Conclusie – WordPress sneller maken

Er zijn veel maatregelen om de prestaties van WordPress te optimaliseren. Snelle WordPress hosting is belangrijk en de basis voor alles. Maar alleen snelle hosting garandeert geen topsnelheden. Daarvoor is het volgende nodig:

• De assets op de website zo klein mogelijk maken, dus comprimeren.
• Het juiste formaat kiezen (zoals WebP of SVG). Laad alleen afbeeldingen die zo groot zijn als nodig is voor het betreffende doel (desktop vs. tablet vs. mobiel).
• Caching inschakelen of caching op de server gebruiken: zodra een bron is "samengesteld", kan hij uit de caches worden geladen totdat er iets verandert. Externe bronnen zoals Google Fonts moeten ook van je eigen server worden geladen.
• De laadvolgorde optimaliseren. CSS en JS uitstellen door middel van een plugin of service, of eerst laden wat echt nodig is en dan de rest (sleutelwoord: critical CSS).
• Weg met overbodige ballast: hebben we echt emoji's nodig voor elk laadproces?

De belangrijkste tip die ik je uit praktische ervaring kan geven: caching en deferring zorgen meestal voor 90 procent van de prestaties. Dit is dus waar je je eigen optimalisaties op moet richten. Ik wens je veel succes en een hoge snelheid voor je projecten met WordPress en WooCommerce.