בכל בקשה לאתר WordPress, ה-core מבצע שאילתה אחת גדולה לטבלת wp_options ושולף את כל השורות שמסומנות autoload='yes'. השורות האלה נטענות ל-$alloptions בזיכרון של PHP, מבוצע עליהן unserialize, והן זמינות לכל קוד שיריץ get_option() בלי לפנות שוב ל-DB. הרעיון תקין ביסודו - אבל כשאופציה אחת או כמה גדלות לעשרות KB ומסומנות autoload, כל בקשה משלמת את המחיר, גם בקשות AJAX קצרות שלא צריכות את האופציה כלל.
למה זה משנה
אופציות autoload כבדות פוגעות באופן ישיר בשני מדדים מרכזיים: TTFB (Time To First Byte) ו-INP בעמודי אדמין. שאילתה של 5MB מ-MySQL לוקחת 50-150ms על דיסק SSD ו-200-500ms על דיסק רגיל; ה-unserialize של מערך עמוק מוסיף עוד 30-100ms. כשאתר מקבל 10 בקשות בשנייה - כל בקשה (גם בקשת admin-ajax למניית גלגלים, גם ה-REST API לעדכון תמונות) משלמת את העלות הזו.
במצבים קיצוניים שבהם $alloptions מגיעה ל-10MB+ זה מתחיל לחנוק את memory_limit של PHP - כל worker מחזיק עותק משלו. אתר עם 20 PHP workers ו-10MB autoload צורך 200MB RAM רק על options - לפני שהקוד התחיל לרוץ. ה-LCP יכול להגיע ל-4 שניות גם בעמוד פשוט, רחוק מהיעד של Core Web Vitals (LCP מתחת ל-2.5 שניות).
איך לזהות
הרץ את השאילתה הבאה ב-phpMyAdmin או ב-Adminer:
SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) AS kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;כל שורה מעל 100KB דורשת בדיקה. הסכום הכולל לא צריך לעבור 1MB באתר בריא. כלי נוסף הוא Query Monitor - אחרי התקנה הוא מציג בכל עמוד את משקל autoload בפאנל Database Queries. ב-WP-CLI אפשר לקבל את אותו מידע עם wp option list --autoload=on --format=table --orderby=size.
איך לתקן
לכל אופציה כבדה, חפש את שמה בגוגל ובמאגר התוספים של WordPress.org. ברוב המקרים שם המפתח מזהה את התוסף שיצר אותה (למשל wpseo_taxonomy_meta שייך ל-Yoast). אם התוסף הוסר מהאתר אבל האופציה נשארה - מחק אותה:
DELETE FROM wp_options WHERE option_name = 'OPTION_NAME';אם התוסף עדיין פעיל אבל האופציה לא חיונית בכל בקשה (logs, היסטוריית סטטיסטיקות, transients שלא ב-API), הפוך אותה ל-autoload=no:
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'OPTION_NAME';אופציה שהוגדרה autoload=no עדיין נטענת ב-get_option(), פשוט בשאילתה נפרדת בעת הצורך - לכן הקוד ממשיך לעבוד בלי שינוי.
טעויות נפוצות
אל תיגע באופציות core: siteurl, home, blogname, active_plugins, template, stylesheet, permalink_structure - הן באמת נדרשות בכל בקשה והפיכתן ל-no תגרום ל-N+1 queries ולהאטה הפוכה. טעות נוספת: לבצע פעולות בלי גיבוי. wp_options היא טבלה קריטית; שגיאת UPDATE על שורה לא נכונה תפיל את האתר. גבה תמיד עם UpdraftPlus או mysqldump לפני.
בדיקה לאחר תיקון
הרץ שוב את שאילתת הזיהוי וודא שהסכום ירד מתחת ל-1MB. ב-PageSpeed Insights בדוק את ה-TTFB - אמור לרדת ב-100-300ms. ב-Query Monitor המשקל של autoload בעמוד צריך להיות מתחת ל-500KB. אם משתמשים ב-Redis Object Cache - הרץ wp cache flush או לחץ Flush Cache בעמוד התוסף, אחרת הגרסה הישנה של $alloptions תישאר ב-cache.