Waarom is mijn WooCommerce-site zo traag?

Een trage WooCommerce-winkel is niet één probleem; het zijn meestal drie of vier kleinere op elkaar gestapeld, en dat is precies de reden waarom alleen het installeren van een caching-plug-in dit zelden oplost. Dit is de diagnostische reeks die we doorlopen als een klant zegt dat zijn winkel traag aanvoelt, in de volgorde waarin de oorzaak het snelst wordt gevonden.

Stel een diagnose voordat u iets repareert

Voordat u plug-ins of hosting aanraakt, moet u echte cijfers krijgen. Voer uw startpagina en een productpagina uit via Google PageSpeed Insights en let specifiek op twee dingen:Tijd tot eerste byte (TTFB)en de uitsplitsing van wat de weergave blokkeert. TTFB van meer dan 600 ms wijst bijna altijd op een probleem met de hosting of de server; geen enkele hoeveelheid front-end-optimalisatie lost een trage server op. Als TTFB snel is, maar de pagina nog steeds traag laadt, ligt het probleem waarschijnlijker bij de front-end: afbeeldingen, render-blocking scripts of door plug-ins geïnjecteerde CSS/JS.

Deze enkele controle bespaart uren; het vertelt u of u moet beginnen met uw host of met uw plug-instack, wat heel verschillende oplossingen zijn.

Hosting: de meest voorkomende oorzaak

WooCommerce voert PHP uit op elk verzoek dat de database raakt - met name productpagina's, winkelwagentje en afrekenen zijn dynamisch en niet statisch, dus gedeelde hosting met beperkte PHP-werknemers en CPU-toewijzing heeft moeite met echt verkeer. Als uw TTFB voortdurend traag is, zelfs op een pagina waarop geen zware plug-ins actief zijn, is hosting zeer waarschijnlijk uw antwoord en geen symptoom waar u omheen moet werken.

Wat te controleren:

• PHP-versie.Oudere PHP-versies (7.x en lager) zijn meetbaar langzamer dan de huidige PHP 8.x-releases voor dezelfde code. Controleer of uw host een huidige versie gebruikt. Dit is vaak een gratis wijziging met één klik in uw hostingcontrolepaneel.
• Gedeelde versus beheerde WooCommerce-hosting.Generieke gedeelde hosting die is geoptimaliseerd voor brochuresites is niet gebouwd voor de databasebelasting die WooCommerce genereert. Beheerde WooCommerce of beheerde WordPress-hosting omvat doorgaans caching op serverniveau en toewijzing van middelen die zijn afgestemd op deze specifieke werklast.
• Serverlocatie.Als uw klanten zich voornamelijk in één regio bevinden en uw server zich elders bevindt, zorgt die retour voor echte latentie voordat een CDN kan helpen.

Plugin-audit: kwaliteit boven kwantiteit

"Te veel plug-ins" is een echte oorzaak van traagheid, maar het aantal doet er minder toe dan wat elke plug-in daadwerkelijk doet bij het laden van een pagina. Een lichtgewicht hulpprogramma-plug-in die alleen in de beheerder wordt uitgevoerd, kost u niets in de winkel. Een slecht gecodeerde paginabuilder of een plug-in die bij elk front-endverzoek de database bevraagt, kost u realtime op elke pagina, bij elk bezoek.

Om te controleren:

1. Installeer Query Monitor (gratis) en laad uw langzaamste pagina. Het laat precies zien welke plug-ins databasequery's uitvoeren, hoeveel en hoe lang elk duurt.
2. Deactiveer plug-ins die u niet actief gebruikt: oude SEO-tools, verlaten paginabouwers, dubbele functionaliteit door het wisselen van tools in de loop van de tijd. De meeste winkels verzamelen er meerdere.
3. Controleer voor plug-ins die u behoudt of ze de instelling 'uitschakelen op frontend' of 'alleen laden waar nodig' bieden. Veel populaire plug-ins laden hun assets standaard op de hele site, zelfs als de functie slechts op één pagina wordt gebruikt.

Database-opgeblazenheid

WordPress en WooCommerce schrijven beide veel meer naar de database dan de meeste site-eigenaren zich realiseren: postrevisies bij elke inhoudsbewerking, verlopen transiënten die nooit worden opgeschoond, verlaten winkelwagengegevens en sessierecords van elke afrekenpoging, voltooid of niet. Binnen een jaar of twee kan een niet-onderhouden WooCommerce-database daadwerkelijk in omvang verdrievoudigen met inhoud die geen enkele blijvende waarde biedt.

Een opgeblazen database vertraagt ​​elke zoekopdracht, wat elke pagina vertraagt. Dit leidt tot zoekvraagproblemen op plug-inniveau in plaats van dat deze los daarvan bestaan. Voer een opschoning van de database uit (beperk het aantal postrevisies, wis verlopen transiënten en bekijk verweesde metagegevens) volgens een terugkerend schema, niet slechts één keer.

WooCommerce-specifieke problemen die de meeste handleidingen overslaan

Algemeen WordPress-snelheidsadvies mist een paar dingen die specifiek zijn voor hoe WooCommerce werkt:

• Winkelwagen- en kassafragmenten.WooCommerce ververst standaard "karfragmenten" via AJAX bij elke pagina die wordt geladen, zelfs pagina's waarop geen winkelwageninteractie plaatsvindt - dit is een achtergrondverzoek waarvan de meeste site-eigenaren niet weten dat het actief is. Het kan selectief worden uitgeschakeld of beperkt tot pagina's die het daadwerkelijk nodig hebben.
• Sessieafhandeling in de database.Standaard slaat WooCommerce sessiegegevens op in de database in plaats van in snellere opslag. In winkels met meer verkeer verwijdert het verplaatsen van sessies naar objectcaching (Redis of Memcached, als uw host dit aanbiedt) een echt knelpunt.
• Gerelateerde en upsell-productvragen.Deze voeren niet-triviale databasequery's uit om aanbevelingen te berekenen die u misschien ook leuk vindt. Bij grote catalogi zonder de juiste indexering kan dit alleen al de productpagina's aanzienlijk vertragen.
• Caching van volledige pagina's conflicteert met afrekenen.Afreken- en winkelwagenpagina's mogen nooit vanuit een statische cache worden weergegeven, maar te brede cacheplug-inconfiguraties slaan ze soms toch op in de cache, waardoor verouderde winkelwagengegevens ontstaan. Bevestig dat uw caching-plug-in expliciet winkelwagen-, afreken- en accountpagina's uitsluit.

Caching, afbeeldingen en last-mile-oplossingen

• Paginacaching instellenvoor alles behalve winkelwagen-, afreken- en accountpagina's, met behulp van een gerenommeerde caching-plug-in of de ingebouwde caching-laag van uw host.
• Schakel objectcaching in(Redis of Memcached) als uw host dit ondersteunt: dit versnelt dynamische, ingelogde en WooCommerce-specifieke verzoeken, waarbij paginacaching alleen niet helpt.
• Afbeeldingen comprimeren en verkleinenvóór het uploaden, en bied moderne formaten aan (WebP of AVIF) – productfotografie is meestal het grootste pluspunt op elke e-commercepagina.
• Voeg een CDN toeom statische assets (afbeeldingen, CSS, JS) aan te bieden vanaf een server die geografisch dichter bij elke bezoeker staat.
• Stel ongebruikt JavaScript uit of verwijder het, met name analyse- en marketingscripts die synchroon in de header worden geladen – dit zijn veelvoorkomende, gemakkelijke overwinningen die vaak naar voren komen bij plug-in-audits.

Wanneer optimalisatie niet meer voldoende is

Soms wordt elke oplossing op deze lijst toegepast en is de winkel nog steeds langzamer dan hij zou moeten zijn - meestal omdat het thema zelf zwaar is, de plug-instack dragend is en niet verder kan worden ingekort zonder de echte functionaliteit te verliezen, of de winkel echt is ontgroeid wat WooCommerce op zijn huidige hostinglaag kan bieden. Op dat moment verschuift het eerlijke gesprek van ‘optimaliseer WooCommerce’ naar ‘is WooCommerce nog steeds het juiste platform voor het verkeer en de catalogusgrootte van deze winkel’. OnzeShopify-gids voor snelheidsoptimalisatieis een nuttig vergelijkingspunt als u die beslissing overweegt, en we behandelen de praktische kant van het overstappen in onzeWooCommerce naar Shopify-migratiegids.

Als je liever hebt dat iemand anders deze volledige diagnose uitvoert en de bevindingen oplost,Devmerx verzorgt het prestatiewerk van WordPress— hostingbeoordeling, plug-in-audit, database-opschoning en caching-configuratie, bereik en vaste prijs na een snelle blik op uw site.

Veelgestelde vragen

Waarom werd mijn WooCommerce-site plotseling langzamer na het toevoegen van producten?

Grotere catalogi betekenen grotere databasequery's, vooral voor filteren, zoeken en berekeningen van gerelateerde producten die niet zijn geoptimaliseerd voor schaal. Wat goed aanvoelde bij 200 producten kan merkbaar vertragen bij 2.000 als uw hosting- en plug-instack niet gebouwd was met het oog op groei.

Is shared hosting echt de belangrijkste oorzaak van de traagheid van WooCommerce?

Dit is de meest voorkomende oorzaak die we zien, vooral wanneer TTFB traag is, zelfs op pagina's met weinig plug-ins. Het is niet altijd de enige oorzaak (een opgeblazen gevoel van plug-ins en een opgeblazen database komen vaak voor), maar hosting is meestal het eerste wat de moeite waard is om uit te sluiten.

Hoeveel plug-ins zijn te veel voor WooCommerce?

Er is geen vast nummer. Een site met veertig lichtgewicht, goed gecodeerde plug-ins kan beter presteren dan een site met tien slecht gecodeerde plug-ins. Controleer wat elke plug-in daadwerkelijk aan de voorkant doet, in plaats van zich op een specifiek aantal te richten.

Zal een caching-plug-in een langzame check-out oplossen?

Nee: het afrekenen mag in de eerste plaats nooit vanuit een statische cache worden gedaan, omdat het live winkelwagen- en sessiegegevens moet weerspiegelen. Een caching-plug-in versnelt uw catalogus- en inhoudspagina's, niet het afrekenen. De afrekensnelheid wordt bepaald door de kwaliteit van de hosting, de verwerking van sessies en het opschonen van scripts.

Wanneer moet ik overwegen om WooCommerce volledig te verlaten?

Wanneer u hosting-, plug-in-, database- en caching-oplossingen hebt toegepast en de winkel nog steeds ondermaats presteert vanwege het verkeer en de catalogusgrootte, of wanneer de voortdurende onderhoudslast (beveiligingspatches, plug-inconflicten, serverbeheer) meer tijd kost dan het waard is in vergelijking met een beheerd platform.