שיפור מהירות אתר מתחיל במדידה, לא בתוסף. קודם בודקים ב-PageSpeed Insights איזה מדד תקוע, ורק אחר כך מתקנים את מה שבאמת מאט: שרת בלי מטמון, תמונות כבדות, עודף JavaScript מתוספים, CSS שחוסם את הציור או תוכן שקופץ.
הסדר חשוב. אין טעם לדחוס תמונות אם השרת לוקח זמן רב רק כדי להתחיל לענות, ואין טעם להפעיל עשר הגדרות אופטימיזציה בבת אחת, כי אם משהו נשבר לא תדע מה שבר אותו.
לכן ריכזתי כאן את הסדר שבו אני עובר על אתר וורדפרס איטי: איך מגלים כל בעיה, איך מתקנים אותה, ומתי עדיף לעצור.
שיפור מהירות אתר מתחיל במדידה
לפני שנוגעים במשהו, מריצים PageSpeed Insights על שלושה או ארבעה עמודים מייצגים: עמוד הבית, עמוד שירות, ואם יש חנות גם עמוד מוצר. שומרים צילום מסך של התוצאות, במובייל ובדסקטופ. וכשאתה כבר שם, שווה לבדוק שהעמוד גם נראה תקין במובייל ולא רק נטען מהר, לפי הצ'קליסט במדריך אתר רספונסיבי.
בדוח יש שני סוגי נתונים. לפי התיעוד של PageSpeed Insights, נתוני השטח מגיעים מ-Chrome User Experience Report ומסכמים חוויות של משתמשים אמיתיים לאורך 28 הימים האחרונים. נתוני המעבדה מגיעים מ-Lighthouse, שבודק את העמוד פעם אחת בסביבה מדומה.
שלושת המדדים שכדאי להכיר הם Core Web Vitals, ולכל אחד יש סף משלו:
| מדד | מה הוא מודד | טוב עד | מה משפיע עליו בעיקר |
|---|---|---|---|
| LCP | זמן הופעת התוכן הגדול ביותר במסך | 2.5 שניות | השרת, התמונות וקבצים שחוסמים את הציור |
| INP | מהירות התגובה ללחיצות | 200 מילישניות | כמות ה-JavaScript |
| CLS | כמה התוכן קופץ | 0.1 | מידות תמונות, באנרים וגופנים |
אחרי כל תיקון מנקים מטמון ומריצים שוב. נתוני המעבדה ישתנו מיד. נתוני השטח יתעדכנו בהדרגה, כי הם מכסים חלון של 28 ימים. ורק תקפיד למדוד את הכתובת הרגילה של העמוד. פעם מדדתי כתובת עם תוספת אחרי סימן שאלה בסוף, וקיבלתי מספרים חסרי ערך, כי תוסף המהירות לא מאיץ כתובות כאלה.
1. השרת עונה לאט: מטמון עמודים ו-PHP
בנתוני השטח של PageSpeed Insights מופיע TTFB, הזמן עד שהשרת מתחיל לשלוח את העמוד. ב-web.dev הוא מוגדר כחלק הראשון מתוך ארבעת החלקים שמרכיבים את ה-LCP. אם הוא גבוה, כל שאר התיקונים יעזרו פחות. אלה הדברים שמורידים אותו:
- מטמון עמודים. לפי מדריך האופטימיזציה של וורדפרס, תוסף מטמון ששומר את הפוסטים והעמודים כקבצים סטטיים נותן את התועלת הגדולה ביותר במאמץ הקטן ביותר. עדיף לבחור תוסף מטמון אחד ולהגדיר אותו עד הסוף. השוואה בין האפשרויות הנפוצות נמצאת במדריך תוסף שיפור מהירות.
- מטמון אובייקטים. באתרים עם הרבה שאילתות, כמו חנויות, מטמון אובייקטים קבוע חוסך פניות למסד הנתונים. זה דורש תמיכה מצד האחסון.
- גרסת PHP ו-OPcache. באתר של וורדפרס, בעמוד הדרישות, ההמלצה היא PHP 8.3 ומעלה. מדריך האופטימיזציה ממליץ גם על מטמון opcode כמו OPcache. את שניהם בודקים בלוח הבקרה של האחסון. את גרסת ה-PHP רואים גם בוורדפרס עצמו, תחת Tools ואז Site Health, בלשונית Info. אם הגרסה ישנה, Site Health מציג בלשונית Status הודעה שמתחילה ב-Your site is running on an older version of PHP, או ב-Your site is running on an outdated version of PHP כשהגרסה כבר לא מקבלת עדכוני אבטחה.
לפני שמעדכנים PHP עושים גיבוי מלא, כי תוסף או תבנית ישנים עלולים לא לתמוך בגרסה החדשה.
2. תמונות כבדות או שנטענות בזמן הלא נכון
Lighthouse מציג בחלק האבחון איזה אלמנט נבחר כ-LCP. אם זו תמונה, בודקים את המשקל שלה, את הפורמט, ואם יש לה טעינה עצלה. מה שאפשר לתקן:
- פורמט ודחיסה. מדריך האופטימיזציה של וורדפרס ממליץ על WebP כשאפשר. מעלים תמונה בגודל שבו היא מוצגת, לא צילום מקורי ענק.
- לא לטעון בעצלות את התמונה הראשית. web.dev ממליץ לא להחיל טעינה עצלה על אלמנט ה-LCP, ולתת לו
fetchpriority="high". וורדפרס מוסיף טעינה עצלה לתמונות כברירת מחדל מאז גרסה 5.5, ומגרסה 6.3 הוא מנסה לזהות את התמונות שבחלק העליון, לא לטעון אותן בעצלות ולתת עדיפות לתמונה שנראית כראשית. תוסף אופטימיזציה או תבנית יכולים לעקוף את זה, ולכן כדאי לבדוק בקוד המקור של העמוד מה בפועל יש על התמונה העליונה. - מידות. לכל תמונה צריך
widthו-height, כדי שהדפדפן ישמור מקום ולא יהיו קפיצות.
3. יותר מדי תוספים ו-JavaScript
הסימנים כאן הם INP גבוה בנתוני השטח, או המלצות ב-Lighthouse כמו הפחתת JavaScript שלא בשימוש וצמצום העבודה על ה-main thread. לפי web.dev, הגורם העיקרי ל-INP גרוע הוא משימות ארוכות שתוקעות את הדפדפן, ו-JavaScript כבד הוא המקור הנפוץ שלהן. וזה מה שאפשר לעשות:
- לצמצם תוספים. זה הסעיף הראשון ברשימת האופטימיזציה של וורדפרס. עוברים על רשימת התוספים ומסירים את מה שלא בשימוש. צ'אטים, סליידרים ופופאפים שאף אחד כבר לא צריך טוענים קוד בכל עמוד.
- לדחות JavaScript. ב-WP Rocket, לשונית File Optimization, יש שתי אפשרויות. Load JavaScript deferred מוסיפה לסקריפטים את המאפיין
deferכדי שלא יחסמו את הציור. Delay JavaScript execution דוחה את טעינת הסקריפטים עד לאינטראקציה ראשונה של המשתמש, כמו גלילה, הקשה או תנועת עכבר. - סקריפטים חיצוניים. פיקסלים, מפות וצ'אטים הם JavaScript של צד שלישי. כל אחד מהם הוא עוד עבודה לדפדפן.
דחיית JavaScript היא גם המקום שבו דברים נשברים, למשל תפריט מובייל שלא נפתח או טופס שלא נשלח. ב-WP Rocket ממליצים לבדוק תקלה כזו עם ?nowprocket בסוף הכתובת, שעוקף את האופטימיזציות שלהם. אם הבעיה נעלמת, מכבים את האפשרויות בלשוניות File Optimization ו-Media ומדליקים אותן אחת אחרי השנייה עד שמוצאים את האשמה.
4. CSS שחוסם את הציור
Lighthouse מסמן בקשות שחוסמות את הרינדור. הדפדפן חייב להוריד ולעבד את קבצי ה-CSS לפני שהוא מצייר את העמוד, וכל קובץ כזה מעכב את מה שהמבקר רואה.
ב-WP Rocket, לפי התיעוד שלהם, יש לזה שתי דרכים: Remove Unused CSS, שהיא השיטה המומלצת שלהם לביצועים, ו-Load CSS Asynchronously. מדריך האופטימיזציה של וורדפרס ממליץ גם על הקטנת קבצי CSS ו-JavaScript (minify) ועל צמצום מספר הבקשות.
אחרי ההפעלה בודקים את העמוד בחלון גלישה בסתר, בלי להיות מחובר כמנהל, ומוודאים שהעיצוב שלם.
5. תוכן שקופץ: CLS
כאן הסימן הוא CLS מעל 0.1, או תחושה שהעמוד זז בזמן שאתה מנסה ללחוץ.
לפי web.dev, תזוזה שקורית בתוך 500 מילישניות מלחיצה של המשתמש לא נספרת ב-CLS. תפריט שנפתח כי לחצת עליו הוא לא הבעיה. הבעיה היא תוכן שזז בלי שנגעת בשום דבר.
לפי web.dev, הגורמים הנפוצים הם תמונות בלי מידות, פרסומות והטמעות שנטענות מאוחר, תוכן שמוזרק מעל תוכן קיים, החלפת גופנים ואנימציות שמזיזות אלמנטים. ובהתאם, מתקנים כך: נותנים מידות לתמונות, שומרים מקום עם min-height לבאנרים ולהטמעות, טוענים מראש את הגופן הקריטי ומנפישים עם transform.
6. CDN ומסד נתונים
מדריך האופטימיזציה של וורדפרס מסביר שהעברת התמונות, קבצי ה-JavaScript וה-CSS ל-CDN מהירה יותר ומורידה עומס מהשרת. זה רלוונטי במיוחד כשהשרת רחוק מהמבקרים.
לגבי מסד הנתונים, אותו מדריך ממליץ לנקות אותו, להגביל גרסאות שמורות של פוסטים (revisions) ולשמור את האפשרויות שנטענות אוטומטית (autoloaded options) מתחת ל-800KB. אם אתה לא בטוח איך לבדוק את זה, אפשר לבקש מהאחסון.
אם אתה עובד גם על התנועה לאתר ולא רק על המהירות, כתבתי על זה במאמר איך להביא תנועה אורגנית לאתר.
מצבים שבהם עדיף לא לתקן לבד
- TTFB גבוה גם אחרי שהפעלת מטמון עמודים. כנראה שהבעיה בשרת, באחסון או בקוד שרץ בצד השרת. במקרה כזה שווה לבדוק אם האחסון עצמו הבעיה, ועל זה כתבתי במדריך אחסון אתרים מהיר.
- הפעלת אופטימיזציה ומשהו נשבר, ואתה לא מצליח לבודד מה.
- האתר הוא חנות, וכל שינוי בעמוד המוצר או בקופה עלול לפגוע בהזמנות.
- עדכון PHP נדרש, אבל יש באתר תוספים או תבנית שלא עודכנו מזמן.
ועוד דבר שכדאי לדעת מראש: גוגל כותבת במסמך על חוויית עמוד שתוצאות טובות ב-Core Web Vitals לא מבטיחות מקום בראש התוצאות. שיפור מהירות אתר משפר את החוויה של המבקרים, אבל הוא לא מחליף תוכן רלוונטי.
שאלות נפוצות
האם דחיית JavaScript יכולה לשבור את האתר?
כן. אם תפריט, טופס או סליידר מפסיקים לעבוד אחרי ההפעלה, בודקים את העמוד עם ?nowprocket ב-WP Rocket, ומחריגים את הסקריפט הבעייתי או מכבים את האפשרות.
מה ההבדל בין Load JavaScript deferred ל-Delay JavaScript execution?
לפי התיעוד של WP Rocket, Load JavaScript deferred מוסיפה לסקריפטים את המאפיין defer, כך שהם רצים אחרי שהדפדפן קרא את ה-HTML ולא חוסמים את הציור. Delay JavaScript execution הולכת רחוק יותר: היא לא טוענת את הסקריפטים בכלל עד שהמשתמש גולל, נוגע במסך, מזיז את העכבר או לוחץ על מקש. היא חזקה יותר, ולכן גם הסיכוי שהיא תשבור משהו גבוה יותר.
האם שיפור מהירות האתר ישפר את הדירוג בגוגל?
גוגל אומרת שמערכות הדירוג שלה מתחשבות בחוויית עמוד, אבל אין סיגנל יחיד, והרלוונטיות של התוכן קודמת. אי אפשר להבטיח שינוי בדירוג בגלל מהירות.
צריך להגיע לציון 100?
לא. היעד הוא ששלושת המדדים יהיו בטווח הטוב אצל משתמשים אמיתיים, במובייל ובדסקטופ.
אם עברת על השלבים והאתר עדיין איטי, או שאופטימיזציה שבורה מחכה לתיקון, אני יכול לטפל בזה בשבילך.
