אם אחרי שהפעלת WP Rocket או שינית בו הגדרה האתר נראה שבור, תפריט לא נפתח, תמונות נעלמו או עיצוב קפץ, כמעט תמיד מדובר באפשרות אופטימיזציה אחת שלא מסתדרת עם התבנית או עם תוסף אחר. אין צורך למחוק את התוסף. מוצאים את האפשרות הבעייתית, ואז מחריגים ממנה את הקובץ או האלמנט שנפגע, או מכבים אותה רק בעמודים שנפגעו.
זו גם הדרך שהתיעוד הרשמי של התוסף ממליץ עליה: לוודא שהוא באמת הגורם, לכבות את אפשרויות האופטימיזציה, ולהדליק אותן חזרה אחת אחרי השנייה עד שהתקלה חוזרת. במדריך הזה ריכזתי את הבדיקות לפי הסדר, ולכל הגדרה נפוצה הסברתי איך מגלים שהיא האשמה ואיך מתקנים אותה.
לפני הכול צריך גיבוי מלא של הקבצים ושל מסד הנתונים. אני לא נוגע בהגדרות מהירות בלי גיבוי כזה, כי עבודת מהירות יכולה לשבור אתר. בלשונית Tools של התוסף אפשר גם להוריד את ההגדרות הנוכחיות כקובץ JSON בכפתור Download Settings, כך שתוכל לחזור בדיוק למצב שהיה.
מה רואים ואיפה לחפש
לפני שעוברים על השלבים, הטבלה הזו מראה לאן כנראה כדאי לקפוץ לפי מה שקורה באתר:
| מה רואים | מה כנראה אשם |
|---|---|
העמוד שבור גם עם ?nowprocket בסוף הכתובת | לא WP Rocket, אלא התבנית, תוסף אחר או השרת (שלב 1) |
העמוד תקין עם ?nowprocket ושבור בלעדיו | אחת האופטימיזציות של התוסף (שלב 2) |
| תפריט, סליידר או טופס לא עובדים, או אלמנט שמופיע רק אחרי גלילה | Delay JavaScript execution (שלב 3) |
| חלק מהעמוד מאבד עיצוב | Remove Unused CSS (שלב 4) |
| קרוסלה או אזור עם תמונת רקע מופיעים ריקים | LazyLoad for CSS background images (שלב 5) |
| מסך לבן כשמנקים מטמון | מחסור בזיכרון PHP (שלב 6) |
שלב 1: לוודא שהתוסף הוא באמת הגורם
לפני שנוגעים בהגדרות, בודקים שהבעיה באמת קשורה לאופטימיזציות של התוסף.
הבדיקה פשוטה: פותחים את העמוד השבור ומוסיפים לסוף הכתובת ?nowprocket, למשל https://yourdomain.com/page/?nowprocket. הפרמטר הזה עוקף את האופטימיזציות. אם העמוד נראה תקין בגרסה הזו, אחת האופטימיזציות גורמת לבעיה. אם הוא שבור גם כך, הבעיה במקום אחר, בתבנית, בתוסף אחר או בשרת.
כשהאופטימיזציות לא אשמות, ממשיכים לבדיקה רגילה של התנגשויות: מחליפים זמנית לתבנית ברירת מחדל ומשביתים תוספים אחד אחרי השני. כשהן כן אשמות, ממשיכים לשלב 2. ובכל פעם ששינית הגדרה צריך לנקות מטמון. עושים את זה ב-Settings > WP Rocket, בלשונית Dashboard, בלחיצה על Clear and preload cache, או דרך אותו קישור בתפריט של התוסף בסרגל הניהול העליון. ואם יש כמה תקלות שונות, התיעוד ממליץ לטפל בכל אחת בנפרד.
שלב 2: למצוא איזו הגדרה של WP Rocket שוברת את האתר
רוב התקלות בהגדרות WP Rocket מגיעות מהלשוניות File Optimization ו-Media. האפשרויות Minify CSS files ו-Minify JavaScript files מופעלות כברירת מחדל כבר בהתקנה הראשונה, כך שגם אם לא שינית כלום, ייתכן שאחת מהן היא הבעיה.
כדי למצוא את האשמה, מכבים את כל האפשרויות בלשוניות File Optimization ו-Media, מנקים מטמון ובודקים את העמוד בחלון גלישה בסתר שבו אתה לא מחובר לוורדפרס. אם התקלה נעלמה, מדליקים את האפשרויות חזרה אחת אחרי השנייה ובודקים אחרי כל אחת. האפשרות שאחריה התקלה חוזרת היא האשמה. אם התקלה לא נעלמה גם כשהכול כבוי, ייתכן שאחת התכונות האוטומטיות של התוסף אחראית, ואז פונים לתמיכה שלו.
כשמצאת את האפשרות, התיעוד מציע שלוש דרכי תיקון, בסדר הזה. הראשונה והנפוצה היא להחריג ממנה את הקובץ או האלמנט שנפגע. השנייה היא לכבות אותה רק בעמודים הבעייתיים, כך ששאר האתר נשאר מהיר. והשלישית, רק אם התקלה מופיעה ברוב האתר, היא לכבות אותה לגמרי. בשלבים הבאים פירטתי את ההגדרות שנוטות לשבור הכי הרבה.
שלב 3: Delay JavaScript execution
האפשרות הזו דוחה את טעינת קבצי ה-JavaScript עד שהגולש מבצע פעולה בעמוד. היא חזקה, ובגלל זה היא גם שוברת תפריטים, סליידרים וטפסים. באחד האתרים שעבדתי עליהם היא הורידה את הזמן שבו העמוד בנייד תקוע ולא מגיב מ-374 ל-14 אלפיות שנייה, אבל השארתי אותה רק אחרי שבדקתי שהכול באתר עדיין עובד.
היא האשמה אם התקלה מופיעה כש-Delay JavaScript execution פעילה וכל שאר האפשרויות בלשונית File Optimization כבויות, ונעלמת כשמכבים אותה. הסימנים הנפוצים הם אלמנט שמופיע רק אחרי גלילה או הזזת עכבר, גלגל טעינה של התבנית (preloader) שממשיך להסתובב עד שנוגעים בעמוד, או תמונות שלא מופיעות כשהתבנית או תוסף אחר עושים טעינה עצלה משלהם.
התיקון מתחיל ב-One-click exclusions שמתחת לאפשרות, שם בוחרים את התוסף, התבנית או השירות הרלוונטי. אם זה לא מספיק, מוסיפים את הקבצים הבעייתיים לתיבת Excluded JavaScript Files. אם לתבנית יש preloader, מכבים אותו בהגדרות התבנית. ואם התבנית עושה טעינה עצלה לתמונות, מכבים אותה ומשאירים את הטעינה העצלה של התוסף. התיעוד מבחין בין תקלה אסתטית, שבה אלמנט רק מופיע באיחור, לבין תקלה שפוגעת בתפקוד, ובתקלה בתפקוד חייבים להחריג. הפירוט המלא נמצא במדריך התקלות של Delay JavaScript execution.
שלב 4: Remove Unused CSS
האפשרות הזו מוחקת מהעמוד את ה-CSS שנראה לא בשימוש. לפעמים היא מוחקת גם סגנונות שכן צריך, ואז חלק מהעמוד מאבד עיצוב.
היא האשמה אם התקלה קורית כש-Remove Unused CSS היא האפשרות היחידה שפעילה, לא קורית כשהיא כבויה, ונשארת גם אחרי שיצרת מחדש את ה-Used CSS. האפשרות פועלת ברקע ולא מיד, ולכן צריך לתת לה זמן לפני שבודקים. ואם התקלה מופיעה רק במובייל, כדאי לוודא שאפשרות Mobile Cache פעילה.
לתיקון יש תיבת CSS Safelist, ובה מוסיפים מחלקות, מזהים, קבצי CSS או משפחות גופנים שחייבים להישאר. כדי לבדוק אם בכלל שווה לעבוד עם הרשימה, מכניסים אליה זמנית (.*), שומרים ומחכים שה-Used CSS ייבנה מחדש. אם התקלה נפתרה, מוחקים את (.*) ומוסיפים רק את הסגנונות החסרים. משפחת גופנים מוסיפים עם @ לפני השם, למשל @Poppins.
שלב 5: טעינה עצלה של תמונות רקע
האפשרות LazyLoad for CSS background images נמצאת בלשונית Media, והיא טוענת תמונות רקע שהוגדרו ב-CSS רק כשצריך להציג אותן. היא פועלת אוטומטית על כל תמונות הרקע באתר, ולפי התיעוד היא לא תואמת לטעינה עצלה של תמונות רקע מתוסף אחר.
מקרה אמיתי מהעבודה שלי: באתר תיירות, האפשרות של WP Rocket לטעינה עצלה של תמונות רקע ב-CSS גרמה לשקופיות בקרוסלה שמחוץ למסך להישאר ריקות. ביטול האפשרות פתר את זה.
הסימן הוא קרוסלה, סליידר או אזור עם תמונת רקע שמופיע ריק, בעיקר באלמנטים שלא נראים מיד כשהעמוד נפתח. כדי לבדוק, מכבים את האפשרות, מנקים מטמון ובודקים שוב.
אם זו היא, אפשר להחריג את התמונות הבעייתיות בתיבת Excluded images or iframes, לפי שם קובץ התמונה, שם קובץ ה-CSS, מחלקת CSS או דומיין, אחד בכל שורה (הפרטים בתיעוד של האפשרות). אם הבעיה בעמוד אחד, במסך העריכה שלו יש תיבה בשם WP Rocket Options, ובה מבטלים את הטעינה העצלה רק לעמוד הזה. ואם האפשרות שוברת יותר ממה שהיא מרוויחה, כמו במקרה שתיארתי, מכבים אותה.
שלב 6: מסך לבן, שגיאה קריטית או תקלה אחרי עדכון
כשהאתר לא עולה בכלל, זה כבר לא עניין של הגדרת אופטימיזציה, וצריך לראות את השגיאה עצמה.
אם המסך הלבן מופיע כשאתה מנקה את המטמון, לפי התיעוד של התוסף זה יכול להיות מחסור בזיכרון PHP. בלוג השגיאות של השרת תופיע אז שורה כמו Fatal error: Allowed memory size of ... bytes exhausted. זו אותה תופעה שמוסברת במדריך על memory limit exceeded בוורדפרס, ושם גם כתוב איך מעלים את המגבלה. לפעמים אותה תקלה מוצגת לגולשים כשגיאה 500, ולה יש דרך אבחון נפרדת. אם אתה רואה את ההודעה על שגיאה קריטית באתר, וורדפרס שולחת למייל של מנהל האתר קישור ל-Recovery Mode, שדרכו נכנסים לניהול כשהתוסף התקול מושהה רק עבורך. כדי לראות את השגיאות בעצמך, מוסיפים ל-wp-config.php, לפני השורה /* That's all, stop editing! Happy publishing. */, את השורות האלה:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );השגיאות ייכתבו לקובץ wp-content/debug.log. וורדפרס לא ממליצה להשאיר את זה פעיל באתר חי, ולכן כשמסיימים מחזירים ל-false.
אם הבעיה היא זיכרון, מעלים את מגבלת ה-PHP או פונים לאחסון. אם אין גישה לניהול בכלל, משנים ב-FTP או במנהל הקבצים את שם התיקייה wp-content/plugins, למשל ל-plugins.hold. זה משבית את כל התוספים בלי למחוק את ההגדרות שלהם. אחרי שנכנסת לניהול, מחזירים לתיקייה את השם plugins ומפעילים את התוספים אחד אחרי השני. ואם התקלה התחילה מיד אחרי עדכון, בלשונית Tools יש כפתור Reinstall Version שמחזיר לגרסה הראשית הקודמת.
כשעדיף לעצור
אם במקום מסך שבור אתה מקבל 503 Service Unavailable, יש לזה מדריך אבחון נפרד. ויש מצבים שבהם עדיף לעצור: אין לך גיבוי, התקלה פוגעת בעגלת קניות או בטופס שמביא לקוחות, האתר שבור גם כשכל האפשרויות כבויות, או שה-debug.log מראה שגיאות שאתה לא מבין. החרגה לא נכונה יכולה להשאיר את האתר איטי, וכיבוי לא נכון יכול להשאיר אותו שבור בלי שתשים לב. אם עברת על השלבים ועדיין משהו לא עובד, אני מטפל בזה: מוצא את ההגדרה האשמה ומשאיר לך אתר מהיר ותקין.
שאלות נפוצות
אילו הגדרות מופעלות כברירת מחדל?
לפי התיעוד, בהפעלה הראשונה מופעלות Minify CSS files ו-Minify JavaScript files, Cache Lifespan של 10 שעות, Preload Cache, Preload Links ו-Heartbeat Control במצב Reduce Activity.
איך מנקים את המטמון?
ב-Settings > WP Rocket, בלשונית Dashboard, לוחצים Clear and preload cache. אפשר גם מהתפריט של התוסף בסרגל הניהול העליון, ולעמוד בודד דרך הקישור Clear this cache ברשימת העמודים.