De meeste WordPress snelheid optimalisatie begint op de verkeerde plek. Iemand installeert een caching-plugin, comprimeert de afbeeldingen, ziet de paginasnelheidsscore stijgen en gaat ervan uit dat de klus geklaard is. Vervolgens voelt de site nog steeds traag aan en weet niemand waarom.
Het probleem zijn niet de oplossingen. De oplossingen zijn prima. Het probleem is dat ze worden toegepast voordat u weet waar uw laadtijd daadwerkelijk aan opgaat. Deze gids behandelt de zeven controles die u dat vertellen, zodat u stopt met gissen en begint met het verbeteren van datgene wat u daadwerkelijk seconden kost.
Waarom WordPress snelheid optimalisatie faalt zonder metingen
Een paginasnelheidsscore is een enkel getal dat tientallen afzonderlijke vertragingen in uw laadtijd dekt: hoe snel de server antwoordt, hoeveel werk PHP verricht, hoe zwaar de databasequery is, hoe groot de afbeeldingen zijn, hoeveel JavaScript de rendering blokkeert.
Verbeter de verkeerde en het getal beweegt nauwelijks. Verbeter de juiste en het daalt merkbaar. Zonder metingen kunt u niet zien welke welke is, waardoor u uiteindelijk plugins installeert in de hoop dat een ervan helpt.
Dat is ook de reden waarom twee sites met identieke configuraties zo sterk kunnen verschillen in websiteprestaties. Het knelpunt bevindt zich zelden twee keer op dezelfde plek.
7 controles voordat u iets wijzigt
1. Serverresponstijd, eerst en altijd
Time to First Byte is hoe lang uw server erover doet om te beginnen met antwoorden. Dit gebeurt voordat er ook maar één afbeelding of script wordt geladen, dus elk ander deel van uw laadtijd wordt hier bovenop gestapeld.
Als dit hoog is, zal niets wat u op de pagina doet de site snel laten aanvoelen. Het is ook de controle die direct naar de oorzaak wijst: hosting die te klein is, een database die te veel werk verricht, of PHP die bij elk verzoek zware code uitvoert.
Begin hier. Als uw serverresponstijd in orde is, ligt het probleem met de paginalaadsnelheid in de pagina zelf. Als dat niet zo is, bevindt het probleem zich daaronder, en geen enkele hoeveelheid front-end werk zal dat verbergen.
2. Veldgegevens, niet alleen uw labscore
Testtools geven u twee verschillende zaken. Labgegevens zijn een simulatie: één pagina, één apparaat, ideale omstandigheden. Veldgegevens zijn wat echte bezoekers de afgelopen maand daadwerkelijk hebben ervaren.
Ze komen vaak niet overeen, en de veldgegevens zijn de gegevens die Google gebruikt. U kunt beide zien in Google PageSpeed Insights. Als uw labscore groen is terwijl de veldgegevens dat niet zijn, optimaliseert u voor de test in plaats van voor mensen.
3. De pagina’s die u niet test
Bijna iedereen meet de homepage. Het is meestal de lichtste pagina op de site en de best gecachte, wat het de minst nuttige pagina maakt om te testen.
Controleer de pagina’s waar mensen daadwerkelijk iets doen: een diepe contentpagina, een formulier, een zoekresultaat, een accountpagina. Bij een webshop de winkelwagen en het afrekenen. Die omzeilen de cache en draaien live, wat precies de reden is waarom hun websitesnelheid zich anders gedraagt.
4. Databasegrootte en vervuiling
Elke berichtrevisie, verlopen sessie, verweesde optie en achtergebleven tabel van een verwijderde plugin blijft in de database staan, tenzij iets het verwijdert. Jaren daarvan voegen gewicht toe aan query’s die bij elke paginalading worden uitgevoerd.
Controleer de grootte voordat u ervan uitgaat dat het in orde is. Zodra een database een paar gigabyte overschrijdt, draagt deze meestal bij aan uw trage laadtijden, en geen enkele cachinglaag raakt dit aan. Een opgeblazen database is zichtbaar aan de voorzijde en achter de schermen, wat de reden is waarom een trage WooCommerce-admin vaak het eerste waarschuwingssignaal is.
5. Welke plugins u daadwerkelijk kosten
Het aantal plugins zegt u bijna niets. Twintig lichte plugins kunnen beter presteren dan vijf zware.
Wat telt voor siteprestaties is wat elke plugin laadt en wanneer. De dure zijn meestal degene die scripts en stijlen sitewide laden voor een functie die op een enkele pagina wordt gebruikt. Het is bijna nooit de plugin die eigenaren vermoeden, wat de reden is waarom dit gemeten moet worden in plaats van gegokt.
6. Afbeeldingsgewicht versus weergavegrootte
Afbeeldingen zijn nog steeds de grootste vertraging voor de laadtijd van de meeste pagina’s. De controle is simpel: vergelijk het bestand dat wordt geserveerd met de ruimte waarin het verschijnt.
Een afbeelding van 4000 pixels die in een vak van 400 pixels wordt getoond, is verspilde bandbreedte, en compressie verzacht dat slechts. Moderne formaten en correcte afmetingen doen hier meer voor de paginasnelheid dan welke plugin-instelling dan ook.
7. Wat uw caching niet dekt
Caching serveert kant-en-klare kopieën in plaats van pagina’s opnieuw op te bouwen, wat de reden is waarom scores zo snel verbeteren na het inschakelen ervan.
De controle is wat daarbuiten blijft. Alles wat persoonlijk is voor een ingelogde bezoeker mag nooit worden gecacht, anders zien mensen elkaars gegevens. Bij een shop betekent dat de winkelwagen, het afrekenen en de accountpagina’s. Die draaien elke keer live, dus als uw trage paginaladingen daar zitten, zou caching nooit gaan helpen.
De resultaten interpreteren
Zodra u de zeven controles heeft uitgevoerd, wijst het patroon meestal naar een van de drie lagen.
Als uw serverresponstijd hoog is, bevindt het probleem zich onder de site: hosting, database of code die bij elk verzoek wordt uitgevoerd. Bij een webshop veroorzaakt die laag de meeste problemen, wat we uitsplitsen in waarom uw WooCommerce-winkel traag is. Als de responstijd in orde is maar de pagina traag rendert, is het front-end gewicht: afbeeldingen, scripts, render-blokkerende bronnen. En als alles goed test maar mensen nog steeds klagen, meet u vrijwel zeker de verkeerde pagina’s.
Dat is het hele punt van eerst meten. WordPress prestatie optimalisatie is geen vaste lijst met taken. Het is ontdekken welke van die drie lagen u tijd kost, en die vervolgens goed verbeteren.
Wanneer u het uit handen moet geven
De bovenstaande controles vertellen u waar uw siteprestaties daadwerkelijk tekortschieten. Sommige zaken die ze onthullen zijn eenvoudig aan te pakken. Hosting, afbeeldingen en ongebruikte plugins zijn allemaal binnen handbereik als u de tijd heeft.
Andere bevindingen zijn dat niet. Het herstructureren van een database, het herconfigureren van een server of het opsporen van een plugin-conflict op een live site zijn klussen waarbij een fout meer kost dan de trage laadtijden deden. Als uw controles daarheen wijzen, of als u de voor de hand liggende oplossingen al heeft toegepast en de cijfers niet zijn veranderd, is dat het moment om te stoppen met onderzoeken.
Woosa verbetert de volledige stack, hosting, database, configuratie en front-end, waarbij eerst op een staging-kopie wordt gewerkt zodat uw site blijft draaien terwijl deze sneller wordt. Elk project wordt geleverd met voor- en nametingen, en we zien een gemiddelde omzetstijging van 18% na een optimalisatie. Als u het liever laat repareren dan zelf te blijven graven, is onze snelheid optimalisatie service het startpunt.
Veelgestelde vragen
Wat is WordPress snelheid optimalisatie?
WordPress snelheid optimalisatie, ook wel WordPress prestatie optimalisatie genoemd, is het proces van het vinden en verwijderen van alles wat uw paginasnelheid en laadtijd schaadt. Dat omvat hosting, serverresponstijd, database, plugins, afbeeldingen en front-end code. Goed uitgevoerd begint het met metingen, omdat het knelpunt zelden op dezelfde plek zit bij twee verschillende sites.
Hoe weet ik wat mijn WordPress-site traag maakt?
Controleer eerst uw serverresponstijd, vergelijk vervolgens uw veldgegevens met uw labscore en meet daarna de pagina’s die mensen daadwerkelijk gebruiken in plaats van alleen de homepage. Die drie controles beperken het tot de serverlaag, de front-end, of iets waar uw tests nooit naar keken.
Waarom is mijn WordPress-site nog steeds traag na het installeren van een caching-plugin?
Omdat caching alleen helpt bij pagina’s die als kopieën kunnen worden geserveerd. Als uw serverresponstijd hoog is, uw database is opgeblazen, of het trage laden gebeurt op pagina’s die niet kunnen worden gecacht, verbetert caching uw score zonder de ervaring te verbeteren.
Wat is het verschil tussen labgegevens en veldgegevens?
Labgegevens zijn een gesimuleerde test van één pagina onder ideale omstandigheden. Veldgegevens zijn de websitesnelheid die echte bezoekers de afgelopen maand hebben ervaren. Ze komen vaak niet overeen, en Google gebruikt de veldgegevens, dus dat is het getal dat actie waard is.
Hoe groot is te groot voor een WordPress-database?
Er is geen harde limiet, maar zodra een database een paar gigabyte overschrijdt, voegt deze meestal meetbare vertraging toe aan query’s die bij elke paginalading worden uitgevoerd. Het opschonen ervan helpt de siteprestaties, hoewel het zorgvuldigheid vereist omdat plugins afhankelijk kunnen zijn van gegevens die ongebruikt lijken.
Moet ik WordPress snelheid optimalisatie zelf doen?
De voor de hand liggende lagen zijn het waard om zelf te doen: hosting, afbeeldingen en het verwijderen van plugins die u niet meer gebruikt. Geef het uit handen zodra de controles wijzen naar de server, de database of een plugin-conflict, want dat zijn de zaken waarbij trial-and-error op een live site echte schade aanricht.