Ha a WordPress admin felülete hónapról hónapra lassabb, pedig nem telepített új bővítményt, érdemes megnézni a wp_options táblát. A WordPress minden kérés legelején, még a sablon és a bővítmények előtt egyetlen lekérdezéssel betölti az összes automatikusan betöltendő (autoload) beállítást, és a memóriában tartja. Ez minden oldalbetöltésnél, minden admin oldalnál, minden AJAX-kérésnél és minden cron-futásnál megtörténik.

Ezt eredetileg kis értékekre találták ki: a webhely címe, az aktív sablon, az időzóna. Sok bővítmény azonban ide teszi a gyorsítótárát, a naplóját vagy egy nagy beállítástömböt is, és az eltávolított bővítmények beállításai is itt maradnak. Egy-két megabájt autoload adat már minden kérést észrevehetően lassít. Az adatbázis általános karbantartásáról (revíziók, átmeneti adatok, takarító bővítmények) blogcikkünk szól.

Mennyi a webhelyén?

A WordPress 6.6 óta a Webhely Egészség (Eszközök menü) figyelmeztet, ha az automatikusan betöltött beállítások túl nagyok: „Az automatikusan betöltött opciók befolyásolhatják a teljesítményt”. A pontos számot WP-CLI-vel kérdezheti le:

cd ~/public_html
wp option list --autoload=on --format=total_bytes

A teszt-webhelyünkön ez 40775 bájt, azaz körülbelül 40 KB, ami egy friss webhelyre jellemző. Néhány száz KB még rendben van, 1 MB fölött érdemes utánajárni, több MB esetén biztosan találni fog valamit. A sorok száma is számít: több ezer kicsi beállítás is lassít.

Mi foglalja a helyet?

A legnagyobb tételek WP-CLI-vel:

wp option list --autoload=on --fields=option_name,size_bytes --format=csv | sort -t, -k2 -n -r | head -20

Vagy a phpMyAdminban (cPanel Adatbázisok csoport), az adatbázis SQL fülén. A táblaelőtagot (a példában 1vL7334_) cserélje a sajátjára; a wp db prefix parancs kiírja, és a phpMyAdmin bal oldali listájában is látja:

SELECT option_name, autoload, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM 1vL7334_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

A WordPress 6.6 óta az autoload oszlopban nemcsak yes és no állhat: az on és az auto-on kötelező, az auto a WordPress döntésére bízott automatikus betöltést jelenti, az off és az auto-off pedig a nem automatikusat. Ezért a régi útmutatók WHERE autoload = 'yes' feltétele ma a tételek nagy részét kihagyja.

A nevek sokat elárulnak a gazdájukról: wf_ a Wordfence, rocket_ a WP Rocket, elementor_ az Elementor, _transient_ és _site_transient_ átmeneti adat (gyorsítótár), a cron pedig a WP-Cron saját ütemezése (egy forgalmas webáruháznál ez maga is lehet 1 MB fölött). Egy nagy érték elejébe így nézhet bele anélkül, hogy több megabájtot írna a terminálba:

wp option get rocket_cache_files --format=json | head -c 500

Az összesítés bővítményenként (előtag szerint) SQL-ben:

SELECT SUBSTRING_INDEX(option_name, '_', 2) AS elotag,
       COUNT(*) AS db,
       ROUND(SUM(LENGTH(option_value)) / 1024) AS kb
FROM 1vL7334_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
GROUP BY elotag
ORDER BY kb DESC
LIMIT 20;

Javítás

Előtte mentse el az adatbázist. Az aWh cPanel szerverein a wp db export nem működik, ezért használja a mysqldump parancsot (WP-CLI cikk), vagy a phpMyAdmin Exportálás fülét.

1. Kapcsolja ki az automatikus betöltést, ahol nem kell

Egy beállításnak csak akkor kell automatikusan betöltődnie, ha szinte minden oldalbetöltésnél szükség van rá. Ami csak egy beállítási oldalon vagy egy ritka feladatnál kell, azt a bővítmény akkor is megkapja, ha nem töltődik be előre, csak egy külön lekérdezéssel:

wp option set-autoload rocket_cache_files off
wp cache flush

Ha a bővítmény a következő mentéskor újra automatikus betöltéssel írja vissza, az a bővítmény hibája; jelezze a fejlesztőnek.

2. Törölje a lejárt átmeneti adatokat

A WordPress a lejárt átmeneti adatot csak akkor törli, ha valaki olvasni próbálja, vagy a napi takarítás eléri. Ami soha többé nem kell, az bent maradhat:

wp transient list --format=count
wp transient delete --expired

A teljes ürítés (wp transient delete --all) is biztonságos, a bővítmények újraépítik, amit használnak; az első oldalbetöltések ilyenkor lassabbak lehetnek.

3. Törölje az eltávolított bővítmények beállításait

Ha egy bővítményt biztosan nem használ már, és nincs a listában (wp plugin list), a beállításait törölheti. Egyenként:

wp option list --search="regibovitmeny_*" --fields=option_name,size_bytes
wp option delete regibovitmeny_settings regibovitmeny_cache

SQL-ben az aláhúzásjelet le kell védeni, mert a LIKE mintában az _ egy tetszőleges karaktert jelent:

DELETE FROM 1vL7334_options WHERE option_name LIKE 'regibovitmeny\_%';

Csak akkor töröljön előtag alapján, ha az előtag egyértelműen egy bővítményé; egy túl rövid minta más bővítmények beállításait is elviheti.

4. Tömörítse a táblát

A törlés után a tábla mérete a lemezen nem csökken. A phpMyAdminban jelölje ki a wp_options táblát, és válassza a Tábla optimalizálása műveletet, vagy parancssorból: mysql "$(wp config get DB_NAME)" -e "OPTIMIZE TABLE $(wp db prefix)options".

Ellenőrzés és megelőzés

Mérje meg újra (wp option list --autoload=on --format=total_bytes), és nézze meg a Webhely Egészség oldalt. Az admin felület oldalbetöltési ideje a böngésző fejlesztői eszközeinek Hálózat fülén is látszik, a változás pár száz KB-os csökkenésnél is mérhető.

A legjobb megelőzés a bővítmények számának féken tartása és a nem használt bővítmények törlése (nem csak kikapcsolása). Nézzen rá félévente az autoload méretére; a gyorsításról további tippeket a WordPress gyorsításáról szóló cikk ad, a többi felduzzadó táblát a wp_postmeta és az Action Scheduler cikk tárgyalja. cPanel tárhely csomagjainkban az AccelerateWP is segíthet a gyorsításban.