האופציה הכי כבדה ב-wp_options: כיצד לאתר את האשם הבודד ולנטרל אותו

בדיקה זו מצביעה על אופציה בודדת ב-wp_options שמסומנת autoload='yes' ושוקלת לבדה מאות KB עד מספר MB. הסכום הכולל יכול להיות תקין, אבל ערך אחד חריג כבר פוגע בכל בקשה - כל worker של PHP חייב לטעון אותו, לעבור עליו unserialize, ולהחזיק עותק בזיכרון. זיהוי האשם הבודד הוא לרוב הניצחון הקל ביותר באופטימיזציה של מסד הנתונים.

למה זה משנה

אופציה אחת של 2MB באתר טיפוסי שווה ל-100-200ms תוספת לכל TTFB. כשמכפילים את זה ב-50 בקשות בעמוד יחיד (HTML, REST endpoints של הבלוקים, admin-ajax של wishlist, heartbeat), התוצאה היא 5-10 שניות עבודה מצטברת של MySQL+PHP על משאב יחיד. בעמוד עורך פוסט, אופציה בודדת של 5MB יכולה להאריך את ה-INP מ-100ms ליותר משנייה - הרבה מעל יעד Core Web Vitals של 200ms.

הרבה מהמועמדים השכיחים הם cache או log שתוסף שכח לסגור: אופציות כמו action_scheduler_lock, wpcf7_recent_history, jetpack_sync_settings_data, או log מצטבר של תוסף תיוג שלא מחזורי. מועמד שני: נתוני שארית של תוסף שהוסר - האופציה נשארה אחרי uninstall שלא ביצע cleanup. מועמד שלישי: אופציה לגיטימית שהתנפחה, כמו rewrite_rules באתר עם אלפי קטגוריות, או הגדרות theme builder ש-Elementor/Bricks/Divi שומרים בשורה אחת ענקית.

איך לזהות

שם האופציה מופיע בתוצאות הסריקה של RankPlus. אפשר גם להריץ ידנית:

SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) AS kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 1;

אחרי שיש לך את השם, חפש אותו בגוגל יחד עם המילה wordpress. כמעט תמיד הקישור הראשון יוביל לתוסף שיצר את האופציה. כדי לראות בעצמך מה היא מכילה (לפני שמוחקים), הרץ SELECT option_value FROM wp_options WHERE option_name = '...' LIMIT 1; ובדוק את המבנה - מערך עמוק של logs נראה אחרת לגמרי מהגדרות סטטיות של תוסף.

איך לתקן

אם זיהית שהתוסף לא קיים יותר במערכת, מחק לחלוטין:

DELETE FROM wp_options WHERE option_name = 'OPTION_NAME';

אם התוסף פעיל וזה log/cache, חפש בהגדרותיו אופציה כמו "Clear log" או "Disable history". פעמים רבות זה הפתרון הנכון - לא להפוך autoload ל-no, אלא לעצור את הצמיחה במקור.

אם זו אופציה לגיטימית אבל לא נחוצה בכל בקשה, הפוך אותה ל-no:

UPDATE wp_options SET autoload = 'no' WHERE option_name = 'OPTION_NAME';

אחרי כל שינוי, נקה אובייקט-cache (Redis/Memcached) או page cache (WP Rocket, LiteSpeed) כדי שהשינוי ייכנס לתוקף בקשות מקושיות.

טעויות נפוצות

אל תמחק אופציות שאתה לא מזהה ולא חיפשת - חלק מהאופציות הקריטיות ביותר נראות גנריות (auth_key, secret_keys של תוספי אבטחה). שגיאה שנייה: לכבות autoload לאופציה בודדת בלי לבדוק את הקוד שצורך אותה. אם תוסף משתמש ב-get_option() בכל page-load, הפיכת autoload ל-no יוצרת שאילתה נפרדת בכל בקשה - שזה בדרך כלל גרוע יותר מהמצב המקורי. שגיאה שלישית: לשכוח גיבוי. עבודה ישירה על wp_options דורשת תמיד mysqldump מקדים.

בדיקה לאחר תיקון

הרץ שוב את שאילתת הזיהוי - האופציה הכי כבדה צריכה כעת להיות מתחת ל-100KB, או לפחות נמוכה משמעותית. הפעל Query Monitor על דף בית ובדוק את משקל autoload - השיפור צריך להיות נראה לעין מיד. ב-PageSpeed Insights, בדוק את ה-TTFB - שיפור של 50-200ms בודד מאופציה אחת הוא לחלוטין סביר. אם זו הייתה אופציית log שגדלה מהר, חזור לבדוק שבוע מאוחר יותר - לפעמים תוסף ממשיך למלא אותה.