בדיקת autoload_size אינה מתמקדת באופציה ספציפית אלא ב-סכום הכולל של כל השורות בטבלת wp_options שמסומנות autoload='yes'. זה הנתון שקובע כמה זיכרון WordPress טוען אוטומטית בכל בקשה - לפני שטיפת קוד יחידה רצה. אתר בריא צריך להיות מתחת ל-500KB; אתר סביר עד 1MB; כל מה שמעל 1.5MB נחשב לבעיה ביצועית פעילה.
למה זה משנה
השאילתה שמעמיסה את $alloptions רצה ב-bootstrap של WordPress, לפני שאר הקוד. זה אומר שכל בקשה - כולל endpoints קצרים מאוד כמו /wp-json/wp/v2/posts/123, admin-ajax.php?action=heartbeat, ובקשות AJAX של תוסף לטעינת מודאל - משלמת את העלות. ב-MySQL מודרני על SSD, שאילתת SELECT שמחזירה 1MB של נתונים לוקחת בערך 30-80ms; ב-2MB זה כבר 80-180ms; ב-5MB זה 250-500ms. ה-unserialize של PHP על מערך עמוק מוסיף 30-50% נוספים.
לסכום autoload יש השפעה מצטברת: ב-LCP (יעד ≤ 2.5s) הוא משפיע דרך TTFB, וב-INP של דשבורד WP-Admin הוא משפיע דרך משך הבקשה לכל פעולה. אתר WooCommerce עם 3MB autoload יראה זמן תגובה של 1.5 שניות לכל בקשת AJAX של עגלה - גרוע מספיק כדי שגולשים נוטשים בזמן checkout.
איך לזהות
השאילתה הסטנדרטית לסך הכולל:
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS total_mb,
COUNT(*) AS rows
FROM wp_options
WHERE autoload = 'yes';בדיקה משלימה - אילו אופציות הכי כבדות:
SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) AS kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 30;Query Monitor מציג את הנתון בכל עמוד ב-toolbar העליון. ב-WP-CLI: wp option list --autoload=on --fields=option_name --format=count לסך השורות, ועם --format=csv אפשר לסכום בעצמך. כלי נוסף הוא תוסף Advanced Database Cleaner - הוא מציג גרף וויזואלי של חלוקת הגדלים.
איך לתקן
אסטרטגיית הניקוי מורכבת משלושה שלבים: (1) אופציות יתומות - תוסף שהוסר אך השאיר אופציות. אלה מועמדות מיידיות ל-DELETE. (2) אופציות פעילות שגדלו מעבר לכוונה - לרוב logs, history, transients שלא דרך ה-API. כאן צריך להפוך autoload ל-no או לאפס את הערך עצמו דרך הגדרות התוסף. (3) אופציות גדולות לגיטימיות - rewrite_rules באתר עם 10K פוסטים, או cron עם 200 jobs מתוזמנים. עליהן להישאר אבל לרוב הן יישבו טוב ב-autoload=no בלי השפעה.
-- מחיקה של אופציה יתומה
DELETE FROM wp_options WHERE option_name = 'OPTION_NAME';
-- הפקעה מ-autoload בלי מחיקה
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'OPTION_NAME';אחרי הפעולות הללו הרץ wp cache flush אם יש object cache - אחרת הגרסה הישנה נשארת ב-Redis/Memcached.
טעויות נפוצות
שגיאה ראשונה: לכבות autoload לאופציות core (siteurl, active_plugins, template) - יוצר עשרות שאילתות נפרדות בכל בקשה ומחרבן את הביצועים יותר מהבעיה המקורית. שגיאה שנייה: למחוק אופציה של תוסף פעיל בלי בדיקה - התוסף ייצור אותה מחדש בבקשה הראשונה, ולפעמים בערך נקי שגדל מהר. שגיאה שלישית: לשכוח לעשות OPTIMIZE TABLE wp_options אחרי המחיקות - InnoDB לא מצמצם את הקובץ הפיזי לבד, וגיבויים ימשיכו להיות גדולים.
בדיקה לאחר תיקון
הרץ שוב את שאילתת ה-SUM וודא שירדת מתחת ל-1MB. ב-PageSpeed Insights בדוק TTFB - שיפור של 150-400ms הוא תוצאה ריאלית. ב-WebPageTest השווה תמונת "before" ו-"after" של הדיאגרמה - שלב ה-server response יתקצר. אם משתמשים ב-page cache (WP Rocket, LiteSpeed Cache) - דפים מקושיים לא ירוויחו, אבל בקשות AJAX והאדמין יורגשו מהירים מיד.