OPcache ב-PHP: למה זה הכרחי לכל אתר WordPress וכיצד מגדירים נכון

OPcache הוא הרחבה מובנית של PHP (מאז 5.5) שמאחסנת את ה-bytecode הקומפל של קבצי PHP בזיכרון משותף. בלי OPcache, כל בקשה ל-WordPress מבצעת לקסור + פרסר + קומפיילר על מאות קבצי PHP מחדש - בזבוז של 30-60% מזמן העיבוד של PHP. עם OPcache פעיל, רק הבקשה הראשונה אחרי deploy משלמת את העלות; כל אחת אחר כך פשוט שולפת את ה-opcode מ-RAM.

למה זה משנה

WordPress core לבדו הוא 1,500+ קבצי PHP. תוסף Yoast SEO מוסיף 400; WooCommerce 800; Elementor 600. בקשת frontend טיפוסית טוענת 100-200 קבצים. בלי OPcache, כל אחד עובר parse + compile מ-0 - 200-500ms של עבודה ב-CPU. עם OPcache פעיל, אותו תהליך נחסך לחלוטין; הקבצים נשלפים מזיכרון ב-microseconds.

בייצור, ההפעלה של OPcache היא תנאי מקדים לכל אופטימיזציה אחרת. PageSpeed Insights ידווח על TTFB גבוה גם אחרי הוספת page cache, object cache, ו-CDN - אם OPcache כבוי. ב-WP-Admin (שלא מקושי על ידי page cache), ההבדל מורגש מיד: ניווט שלוקח 800ms הופך ל-200ms.

חשוב לדעת: OPcache לא קשור לתוסף W3 Total Cache או לקאש של תוכן. הוא ברמה נמוכה יותר - הוא חוסך עיבוד של הקוד עצמו.

איך לזהות

הוסף קובץ phpinfo.php זמני בשורש האתר עם:

<?php phpinfo(); ?>

פתח אותו וחפש "Zend OPcache". אם רואים את הסעיף עם "Opcode Caching: Up and Running" - פעיל. אם לא רואים אותו או "Disabled" - כבוי. חשוב: מחק את phpinfo.php מיד אחרי הבדיקה - הוא חושף מידע רגיש על השרת.

חלופה: WP-CLI:

wp eval 'var_dump(opcache_get_status() !== false);'

החזרה bool(true) = פעיל.

איך לתקן

שלב 1: ודא ש-OPcache מותקן. כמעט כל אחסון מודרני כולל אותו, אבל פעמים נדירות הוא לא טעון. בדוק php -m | grep -i opcache.

שלב 2: הפעל אותו. ב-cPanel: "Select PHP Version" או "PHP Selector" > Extensions > סמן opcache. ב-Plesk: Domain > PHP Settings > Extensions.

שלב 3: הגדר נכון ב-php.ini:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
opcache.fast_shutdown=1
opcache.validate_timestamps=1
opcache.save_comments=1

הסבר ערכים: memory_consumption=256 זה מספיק ל-WordPress טיפוסי עם 50 תוספים; אם רואים אזהרת "out of memory" בלוגים - העלה ל-512. max_accelerated_files=20000 חיוני לאתרים גדולים - כל קובץ PHP תופס סלוט. revalidate_freq=2 אומר שכל 2 שניות OPcache בודק אם קבצי PHP שונו (מאוזן בין ביצועים לעדכון מהיר).

שלב 4: הפעל מחדש PHP-FPM:

systemctl restart php8.2-fpm

שלב 5: בדוק שה-cache מתמלא. התקן opcache-gui או הוסף ל-functions.php:

if (current_user_can('manage_options') && isset($_GET['opcache_status'])) {
    var_dump(opcache_get_status());
    exit;
}

גש ל-?opcache_status=1. בדוק opcache_statistics->opcache_hit_rate - אמור להיות מעל 95%.

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

הטעות הראשונה: לא להגדיל את memory_consumption מעל ברירת המחדל (64MB). באתר עם הרבה תוספים, OPcache לא מצליח לאחסן את הכל ומפזר/מבטל בקשות חוזרות - זה גורם לעיתים גם להאטה כי הוא טוען את אותם קבצים שוב ושוב. הטעות השנייה: opcache.validate_timestamps=0 בלי להבין את ההשלכות - אז OPcache לא יראה שינויים בקוד עד שנעשה restart ידני. זה טוב לביצועים אבל קטסטרופלי בעת deploy. הטעות השלישית: לשכוח להפעיל OPcache reset אחרי שדרוג גרסת PHP, שדרוג WordPress, או deploy של תוסף - לפעמים נשארים בעיות עד שמפעילים opcache_reset().

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

הרץ Lighthouse על דף הבית - TTFB אמור לרדת ב-100-300ms. בעת בקשה ל-wp-admin (שלא מקושי), ההבדל בולט יותר. בדוק את opcache_get_status() - opcache_hit_rate צריך להיות 95-99%. אם נמוך מ-90%, הגדל את memory_consumption. בדוק oom_restarts - אם זה לא 0, יש לך לחץ זיכרון.