Vandaag gaan we dieper in op de wp_options tabel van je WordPress database. Dit is een terrein dat vaak vergeten wordt als het gaat om de prestaties van je WordPress site en je database. Een slecht onderhouden database kan zorgen voor langzame aanvragen (Engels: queries) door de grote hoeveelheid autoloaded data van plugins en thema’s. Daardoor speelt dit probleem vaak bij oudere en grotere websites. Lees daarom nu deze tips om problemen met je wp_options tabel te checken, diagnosticeren en op te lossen.
Wat is de wp_options tabel?
De wp_options tabel bevat verschillende soorten data van je WordPress website, zoals:
- Website URL, homepage URL, e-mail van de admin, standaardcategorieën, hoeveelheid artikelen per pagina, tijdsindeling, etc.
- Instellingen voor plugins, thema’s, widgets
- Tijdelijk gecachete data
De tabel bevat de volgende velden, waarbij sommigen belangrijker zijn dan anderen als het gaat om de prestaties van je WordPress website:
- option_id
- option_name
- option_value
- autoload
Een van de belangrijkste dingen om in de gaten te houden in de wp_options tabel is het autoload veld. Deze bevat een ‘yes’ of ‘no’ waarde. Dit veld is belangrijk, want een ‘yes’ zorgt ervoor dat de bijbehorende functie automatisch geladen wordt door de wp_load_alloptions() functie. Automatisch geladen data is data dat geladen wordt op elke pagina van je WordPress website. We hebben je laten zien hoe je kan voorkomen dat bepaalde scripts op elke pagina van je website geladen worden. We kunnen we hetzelfde toepassen op de wp_options tabel. Standaard staat elke plugin op autoload, maar dit is lang niet voor elke plugin nodig.
Problemen kunnen ontstaan wanneer de wp_options tabel teveel automatisch geladen data bevat. Dit heeft vaak de volgende oorzaken:
- Data van een bepaalde plugin staat op autoload, terwijl dit eigenlijk op ‘no’ moet staan. Een goed voorbeeld is de Contact Form plugin. Is het echt nodig om deze data op elke pagina te laden of volstaat alleen de ‘contact’ pagina?
- Plugins of thema’s zijn verwijderd van de WordPress website, maar de options zijn achtergebleven in de wp_options tabel. Dit kan betekenen dat elke keer nutteloze data wordt aangevraagd, wanneer iemand je website een verzoek doet.
- Plugin- en themaontwikkelaars gebruiken de wp_options tabel om hun data te laden in plaats van hun eigen tabel. Dit heeft voor- en nadelen en sommige ontwikkelaars kiezen er simpelweg voor om geen extra tabellen aan te maken en alles binnen wp_options te houden. Het is echter wel zo dat de wp_options tabel niet is gemaakt om duizenden rijen te faciliteren.
Wat is teveel autoloaded data? Dit hangt er natuurlijk van af, maar idealiter wil je tussen de 300KB en 1MB zitten. Zodra je rond de 3-5MB zit, zijn er waarschijnlijk een aantal dingen uit de wp_options tabel die je kan optimaliseren of verwijderen. Wanneer je boven de 10MB uitkomt, doe je er verstandig aan er meteen naar te kijken.
Problemen oplossen met autoloaded data in de wp_options tabel
Als je WordPress trager is dan je gewend bent, dan kunnen autoloaded data en verzoeken van een oude, inmiddels verwijderde, WordPress plugin de oorzaak zijn. Hieronder laten we je zien hoe je de deze autoloaded data kan vinden en tonen we een voorbeeld van hoe we de database van een bestaande website hebben opgeschoond.
Check de grootte van de autoloaded data
Het eerste dat we uitleggen is hoe je de huidige hoeveelheid autoloaded data van je WordPress website opzoekt. Dit kan je doen door in te loggen bij phpMyAdmin. Klik op je database aan de linkerkant en daarna op het SQL tabblad. Vul onderstaand commando in en klik vervolgens op ‘Go’.
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Er is een kleine kans dat je een wijziging moet aanbrengen in de code als je WordPress een ander voorvoegsel gebruikt dan ‘wp_’.
De grootte van de autoload data krijg je terug in bytes. Er zitten 1.024 bytes in een KB en 1.024KB in een MB. In ons geval gaat het om 249.025 bytes wat ongeveer 0.25MB is. Onze database heeft dus een prima grootte! Als de output onder de 1MB uitkomt, hoef je je geen zorgen te maken. Kom je boven de 1MB uit, ga dan verder met deze tutorial.
Hieronder vind je een geteste website met 137.724.715 aan bytes oftewel 137MB. Dit is een goed voorbeeld van een website waar iets mis mee is en waar we dingen kunnen optimaliseren.
Je kan ook een langer verzoek indienen, zoals het verzoek hieronder. Door middel van deze code kom je erachter hoeveel autoloaded data je hebt, hoeveel ingevoerde code de tabel bevat en de eerste 10 codes met hun grootte.
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Als je toegang hebt tot New Relic (licentie vereist), dan kan je deze ook gebruiken om problemen op te lossen met de wp_options tabel. Het databases tabblad wijst je op de tabellen en het soort verzoeken die je WordPress website het meest vertragen. Wanneer je een entry in de lijst aanklikt, krijg je meer informatie te zien, waaronder een voorbeeldaanvraag. In het voorbeeld hieronder, kan je zien dat er wordt verwezen naar autoloaded data uit je wp_options tabel. Na korte analyse komen we erachter dat deze specifieke website bijna 250MB aan autoloaded data heeft!
Sorteren van Autoloaded Data
De volgende stap is om de lijst met autoloaded data te sorteren op grootte. Hier is een korte SQL code die je kan gebruiken om de top 10 grootste autoloaded data te krijgen:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;Nogmaals, als je WordPress site met een andere prefix dan ‘wp_’ werkt, dan moet je dit gedeelte wijzigen.
Nadere bestudering van individuele Autoloaded Data in wp_options
In de volgende stap gaan we de individuele autoloaded data nader bestuderen.
301_redirects
Zoals je ziet is de nummer 1 van de lijst met autoloaded data ‘301_redirects’. Omdat we gesorteerd hebben op grootte is dit ook meteen de grootste. Dit bestaand is waarschijnlijk direct gerelateerd aan een zogenaamde verwijzingsplugin die de website gebruikt, of de WordPress SEO plugin, welke in feite ook een verwijzingsplugin is. In dit geval zouden we voorstellen om de verwijzingen op serverniveau te doen, in plaats van vanuit de wp_options tabel.
De reden dat we dit willen doen is omdat deze gratis WordPress verwijzingsplugins soms voor prestatieproblemen zorgen doordat ze gebruik maken van de wp_redirect functie. Dit zorgt er op zijn beurt weer voor dat aanvullende codes en hulpmiddelen worden opgevraagd. Daarnaast is het ook zo dat deze ‘301_redirects’ een grote hoeveel aan autoloaded data in je wp_options tabel plaatst.
Als je een klant van Kinsta bent, kun je eenvoudig redirects toevoegen op serverniveau met behulp van de redirect rules tool in je MyKinsta dashboard. Dit is niet alleen beter voor de prestaties, maar je hebt ook een plugin minder om je zorgen over te maken!
wpurp_custom_template_
De nummer twee van onze lijst met autoloaded data is ‘wpurp_custom_template_#’. Deze neemt een groot aantal rijen in beslag. Normaal gesproken zou je in staat moeten zijn om de naam van een option te koppelen aan een plugin of thema als je kijkt in de lijst met thema’s en plugins. In dit geval verzonden we een grep opdracht naar de server om de naam van de bijbehorende plugin of het thema vinden. Als alternatief kan je via SFTP verbinding maken en het handmatig bekijken.
grep -Ri "wpurp_custom_template_"Bovenstaande opdracht bracht helaas geen oplossing, dus gingen we naar Google voor een zoekopdracht. We kwamen er snel achter dat de data afkomstig was van de Ultimate Recipe plugin, die we al lang geleden verwijderd hadden. Dit is een schoolvoorbeeld van compleet onnodige achtergebleven autoloaded data. Wil je weten hoe je je plugins écht verwijderd, zonder dat deze potentieel vertragende dingen achterlaat? Lees dan onze uitgebreide tutorial waarin we beschrijven hoe je WordPress plugins op de juiste manier verwijderd.
um_cache_userdata_
De volgende option die we tegenkwamen was um_cache_userdata_#. Ook hier zien we dat deze een aantal rijen in beslag neemt. Omdat we al redelijk aan de onderkant zitten van onze top10, willen we de lijst uitbreiden naar de top40. Hiervoor gebruikten we de volgende SQL opdracht:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;Hieronder vind je een alternatieve opdracht waarmee je een opsomming krijgt van de waarden met deze prefix:
SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"We zien dat meteen dat er nog veel meer options met deze ‘um_cache_userdata_#’ prefix in de wp_options tabel te vinden zijn. Opnieuw stuurden we een grep opdracht naar de server om de bijbehorende plugin of thema te vinden:
grep -Ri "um_cache_userdata_"Dit keer hadden we meer geluk en konden we onze data koppelen aan de Ultimate Member plugin! Een snelle zoekopdracht via Google gaf ons een aantal oplossingen voor dit probleem (lees het supportartikel). Onderschat de kracht van een simpele Google-zoekopdracht nooit! Het blijkt dat er verschillende alternatieven zijn om binnen deze plugin het probleem op te lossen.
- Ultimate Member > Dashboard > User Cache > Clear Cache.
- Ultimate Member -> Settings -> Advanced -> Stop caching user’s profile data (switch to ON), then Save Changes.
Een andere mogelijkheid om erachter te komen of een option autoloaded is, is door op de ‘Edit’ knop te klikken. Dit laat de map zien waar de plugin zich bevindt of de website van de ontwikkelaar.
Cron Jobs
Een andere veelvoorkomende option met autoloaded data is cron. In ons geval kan het alles zijn dat met cron te maken heeft. Om een beter idee te krijgen waar we kunnen optimaliseren, kan je op de ‘Edit’ knop klikken. In het voorbeeld hieronder is het meteen duidelijk dat ‘do_pings’ de dader was. Ook in dit geval gaf Google uitkomst en we vonden al snel een oplossing om ‘do_pings’ op te schonen.
wp_options tabel opschonen
Het is een goed idee om je tabel op te schonen als jouw resultaten (enigszins) overeenkomen met de onze. Dit doen we door de autoloaded data van je wp_options tabel op te schonen. Het is daarnaast aan te bevelen om het aantal options in je wp_options tabel tot een minimum te beperken. Zorg er alsjeblieft voor dat je altijd back-ups maakt voordat je data verwijderd uit je database. Als je het liever aan iemand anders overlaat, dan kan je altijd overwegen een WordPress ontwikkelaar in te schakelen. Dit is ook een goed moment om binnen een testomgeving te werken. Klanten van Kinsta kunnen gratis in een testomgeving werken en op elk moment hun echte website vervangen met de testomgeving.
Net al we eerder deden, moeten we inloggen bij phpMyAdmin. Vul dan de volgende opdracht in en klik op ‘Go’:
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'Ook hier moet je misschien de opdracht aanpassen als jouw WordPress website met een andere prefix begint dan ‘wp_’. Bovenstaande opdracht zorgt ervoor dat je alleen autoloaded data ziet uit je wp_options tabel.
Wanneer je door deze lijst scrolt, kom je waarschijnlijk allerlei plugins tegen die niet meer gebruikt worden door de website. In ons specifieke voorbeeld is dat de Jetpack plugin die een aantal rijen in beslag neemt. Op onze website was de Jetpack plugin niet langer in gebruik.
Je doet er altijd verstandig aan om de documentatie van je plugin te raadplegen. Soms bieden ze je namelijk de mogelijkheid om hun plugin te verwijderen inclusief de data in de wp_options tabel. Mocht dit zo zijn, dan is het veiliger en ook veel makkelijker om de desbetreffende plugin opnieuw te installeren om deze vervolgens te verwijderen, gebruikmakend van de optie om dit veilig te doen. Omdat niet elke plugin deze optie biedt, laten we je hieronder zien hoe je dit handmatig kan doen.
In ons geval willen we de autoloaded data van de Jetpack plugin vinden in de wp_options tabel. Dit doen we door de volgende opdracht in te voeren. Om je eigen plugin te vinden, kan je %jetpack% vervangen met de naam van je eigen plugin:
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'Vervolgens selecteer je alle rijen en klik je op ‘Delete’.
Een alternatief is om de volgende opdracht uit te voeren:
DELETE
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'
Dit proces kan je herhalen voor elke verwijderde plugin en thema die data heeft achtergelaten in je wp_options tabel.
Opschonen van tijdelijke data
Behalve wanneer je gebruikt maakt van object caching, bewaart WordPress tijdelijke data in de wp_options tabel. Doorgaans bevat deze data een houdbaarheidsdatum en zullen ze dus op den duur verwijderd worden. Toch is dit niet altijd het geval. We hebben databases gezien met duizenden rijen verlopen data. Het is belangrijk om te weten dat tijdelijke data normaal gesproken niet automatisch wordt geladen. Met onderstaande opdracht kan je erachter komen of er tijdelijke autoloaded data in je wp_options tabel zit:
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'Toch is er een betere optie. Met de gratis Transient Cleaner plugin kan je verlopen tijdelijke data makkelijk uit je wp_options tabel halen.
Opschonen van WordPress sessies
Een ander veelvoorkomend probleem is dat cron jobs niet synchroon lopen of niet (op tijd) uitgevoerd worden. Hierdoor kan het zo zijn dat bepaalde sessies niet opgeschoond worden. Hierdoor kan je een enorme hoeveelheid aan _wp_session_ rijen in je database krijgen. In het voorbeeld hieronder vind je een website die meer dan 3 miljoen rijen in de wp_options tabel had. Niet vreemd dus dat deze tabel over de 600MB was!
Door middel van onderstaande opdracht kan je erachter komen of je tabel ook een dergelijk probleem heeft:
SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
In de meeste gevallen kan je deze data veilig verwijderen (wat een cron job eigenlijk al gedaan zou moeten hebben) met de volgende opdracht:
DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'Na het opruimen van alle overgebleven _wp_session_ rows had de tabel minder dan 1.000 rijen en was hij verkleind tot 11 MB.
Door het opschonen van de database kregen we ook geen MySQL pieken meer in de website!
Een index toevoegen aan autoload
Als het opschonen van de wp_options tabel niet genoeg was, dan kan je ook nog proberen een ‘index’ toe te voegen aan het autoload veld. Simpel gezegd kan de rij daardoor makkelijker opgezocht worden. Het team van 10up heeft enkele tests uitgevoerd die de resultaten laat zien van het toevoegen van een index aan de wp_options tabel.
We bevelen van harte de volgende twee handleidingen aan van WP Bullet:
- Hoe je een MySQL Index toe kan voegen aan de wp_options tabel
- Opschonen van de wp_options tabel door middel van WP-CLI
Bekijk voor nog meer optimalisatietips zeker onze diepgaande gids: Jouw WordPress website sneller maken (de ultieme handleiding)
