מדריך Google PageSpeed למשתמשי וורדפרס – חלק ב׳

זהו חלקו השני של המדריך על Google PageSpeed Insights ואולי אף החלק המעניין יותר לרבים מכם. בחלקו הקודם של המדריך דיברנו בעיקר על נתוני המעבדה שהכלי Google PageSpeed Insights מציג לנו.

בחלק זה נראה איך לשפר בפועל את אותם ציונים ונתוני מעבדה ש PSI מציג לנו. נראה כיצד והאם יש צורך לתקן את אותן הערות ש PageSpeed מציגה, ובאופן כללי ננסה להסביר במילים פשוטות הערות אלו ונבהיר כיצד לפרש אותן, ונעשה זאת במיוחד לטובת אותם בעלי אתר וורדפרס שאינם טכניים.

איך הדו"ח עובד ב-Lighthouse 13

ב-Lighthouse 13, הדו"ח של PageSpeed Insights כבר לא מציג את החלוקה המוכרת ל-Opportunities ו-Diagnostics. במקום זאת, הדו"ח מאורגן לשני חלקים חדשים:

Insights – המלצות מאוחדות שמקבצות נושאים קשורים יחד (למשל, כל הבעיות הקשורות לתמונות מופיעות תחת "Improve image delivery" אחד). כל Insight מסומן במשולש אדום, ריבוע כתום או עיגול אפור לפי חומרה, ורבים כוללים הערכת חיסכון.

Diagnostics – מידע נוסף על ביצועים שלא ממופה ישירות ל-Insight. מדובר בפריטים כמו "Reduce unused CSS", "Reduce unused JavaScript" ו-"Avoid long main-thread tasks".

זכרו! המטרה הסופית אינה לשפר את הציון אלא את חווית המשתמש המשתפרת מעצם טעינה מהירה יותר של האתר והצגת התוכן העיקרי עבור הגולש כמה שיותר מהר.

אשתדל לעבור על כל אחת מההמלצות. ייתכן ובמהלך המדריך אשתמש במונח PSI שהוא קיצור של PageSpeed Insights לטובת נוחות הכתיבה 🙂

Insights – ההמלצות המאוחדות החדשות

חלק ה-Insights הוא המקום העיקרי בו תחפשו המלצות פרקטיות. מספר ביקורות ישנות אוחדו ל-Insights בודדים, מה שהופך את הדו"ח לקריא יותר. הנה מה שצריך לדעת על כל אחד מהם.

1. צמצום השהיה (Document Latency Insight)

ב-Lighthouse 13, שלוש ביקורות שהיו נפרדות – "Avoid Multiple Page Redirects", "Reduce Server Response Time" ו-"Enable Text Compression" – מאוחדות כעת תחת Insight אחד בשם "Reduce its latency".

ה-Insight הזה מכסה כל מה שמוסיף השהיה לפני שהדפדפן יכול להתחיל לרנדר את העמוד. אם ה-URL מבצע הפניות מרובות, השרת מגיב באיטיות (TTFB גבוה), או שהקבצים אינם דחוסים – תראו Insight זה מסומן.

הפניות (Redirects): וודאו שאתם תמיד בודקים את הגרסה הנכונה של ה-URL. אם האתר משתמש ב-HTTPS ובלי www, בדקו את הכתובת המדויקת הזו. הפניות מרובות (למשל HTTP ל-HTTPS ואז www ללא-www) מצטברות.

ייתכן ותמצאו מידע נוסף רלוונטי בפוסט על כיצד להעביר אתר וורדפרס ל-HTTPS.

זמן תגובת השרת (TTFB): ככל שהשרת מגיב מהר יותר, העמוד יהיה נגיש מהר יותר עבור הגולש. באתרי וורדפרס, הסיבות העיקריות ל-TTFB איטי הן:

• לא מתבצע קאשינג או שמתבצע לא נכון.
• חברת אחסון לא איכותית (בדקו את שרת האחסון שאני מציע – מבטיח לכם תוצאות טובות יותר).
• תוספים שגורמים לבעיות ולהאטת זמן תגובת השרת.
• מסד נתונים מנופח.

אם אתם משתמשים בתוסף קאש ומקבלים הערה זו, נסו להריץ את PSI שנית למקרה והבדיקה הראשונה פגעה בעמוד שלא היה בקאש. אם אין לכם קאש ברמת השרת, התקינו תוסף קאש כגון WP-Rocket או Total Cache.

דחיסת טקסט (Text Compression): דחיסה באמצעות gzip או brotli מצמצמת את משקל הקבצים כשהם עוברים מהשרת לדפדפן. זהו פיצ'ר בסיסי ומרבית תוספי הקאש יוסיפו את החוקים הרלוונטיים בקובץ htaccess באופן אוטומטי. אם השרת שלכם לא תומך בדחיסה, הגיע הזמן להחליף חברת אחסון.

קראו את הפוסט המורחב על השפעת TTFB על מהירות האתר ומהם הדרכים לשפר נתון זה.

2. שיפור הגשת תמונות – Improve Image Delivery

ב-Lighthouse 13, ארבע ביקורות שהיו נפרדות – "Properly Size Images", "Efficiently Encode Images", "Serve Images in Next-Gen Formats" ו-"Use Video Formats for Animated Content" – מאוחדות כעת תחת Insight אחד בשם "Improve image delivery".

ה-Insight הזה מסמן כל תמונה בעמוד שגדולה מהנדרש, לא דחוסה כראוי, או מוגשת בפורמט ישן. כשתפתחו אותו, תראו טבלה המפרטת כל תמונה שנמצאה בעייתית עם גודל המשאב והחיסכון המשוער.

גודל תמונות: וודאו שאתם מעלים תמונות במימדים הנכונים. אם תמונת מוצר מוצגת ב-400×400 אך הקובץ בפועל הוא 700×700, הדפדפן עושה עבודה מיותרת – והאתר שולח מידע שלא נחוץ.

למידע נוסף והגדרת גדלים חדשים של תמונות בתבנית, תנו מבט בפוסט גודל התמונות בוורדפרס.

דחיסת תמונות: תמונות כבדות הן אחת הסיבות העיקריות לעמודים איטיים. שימו לב לכמות הבייטים שניתן לחסוך. אם לא ביצעתם אופטימיזציה נכונה לתמונות האתר, סביר שה-Insight הזה יופיע.

שימו לב כי PSI יסמן את כל התמונות בעמוד, כולל תמונות מסקריפטים חיצוניים (למשל הטמעות אינסטגרם). אין באפשרותכם לבצע אופטימיזציה לאלו מכיוון שאין לכם שליטה עליהן.

פורמטים מודרניים: נכון להיום כל הדפדפנים המודרניים תומכים גם ב-WebP וגם ב-AVIF. תוספים כגון Imagify, ShortPixel או LiteSpeed Cache יכולים להמיר את התמונות באופן אוטומטי. AVIF מספק דחיסה טובה אף יותר מ-WebP באיכות גבוהה.

תוכן אנימציה: קבצי GIF אינם יעילים להצגת אנימציות. שקלו להמיר אותם לאנימציות CSS, SVG או וידאו. קיימים שירותים חינמיים ברשת שמאפשרים המרה מ-GIF לוידאו בצורה מהירה.

3. בצעו מיניפיקציה לנכסים – Minify resources

מיניפיקציה היא תהליך של צמצום, הסרת רווחים והסרת הערות מקבצי HTML, CSS ו Javascript באמצעות טכניקות שונות. פעולה זו תקטין את משקל הקבצים ותיאורטית תגרום להורדה של קבצים אלו להיות מהירה יותר.

בפועל, החסכון במידע בעקבות מיניפיקציה כזו הוא אחרת די זניח כדי שתהיה לו השפעה מורגשת על זמן הטעינה של האתר. בדקו את החסכון הפוטנציאלי של קבצים אלו בעקבות מיניפיקציה, אם הוא אינו משמעותי אל תדאגו לגבי זה.

גם במקרה של מיניפיקציה אינכם יכולים לשלוט על קבצים צד שלישי שאינם נמצאים בשרת שלכם.

איך לטפל בהערה זו?

הפתרון פשוט והמון תוספים יכולים לבצע מיניפקציה עבורכם, במיוחד תוספי קאש למינהם, אז למה לא לבצע זאת בעצם? עליכם לשים לב כי הפעולה במצבים מסויימים יכולה לשבור פונקציונליות באתר שלכם.

4. עץ תלויות רשת – Network Dependency Tree

ב-Lighthouse 13, הביקורות הישנות "Preconnect to Required Origins" ו-"Minimize Critical Request Depth" משולבות כעת ב-Insight אחד בשם "Network dependency tree".

ה-Insight הזה מראה כיצד בקשות הרשת של העמוד תלויות זו בזו. כל חיבור DNS נוסף לדומיין צד שלישי לוקח זמן. ניתן להשתמש ב-dns-prefetch או ב-preconnect עליו כתבתי בהרחבה, כדי שהדפדפן יתחיל להתחבר לדומיינים מוקדם יותר.

תוספי קאש יכולים לטפל ב-preconnect עבורכם, או שתוכלו להוסיף זאת באמצעות קוד. חשוב לזכור שהפתרון האמיתי הוא להשתמש בכמה שפחות נכסים צד שלישי – preconnect הוא פלסטר.

הנה דוגמה לשימוש ב-preconnect לטעינה מוקדמת של פונטים מגוגל:

<link href='https://fonts.gstatic.com' rel='preconnect' crossorigin>
<link href="https://fonts.googleapis.com/css?family=Assistant:300,400,700,800" rel="stylesheet">

חלקו העליון הקריטי של העמוד – זה שהמשתמשים רואים ראשון – מושפע מאופן השרשור של הבקשות. עליכם לוודא כי החלק הקריטי מוצג כמה שיותר מהר על ידי מתן עדיפות לקבצים הנחוצים באמת ועיכוב השאר באמצעות async ו-defer.

---

הפסקת קפה 🙂 כעת עליכם לדעת כי ההערות הבאות שאציג מטרתן למגר את התופעה השלילית של בניית דפים מורכבים מדי.

5. בקשות החוסמות רינדור – Render Blocking Requests

ב-Lighthouse 13 ביקורת זו נקראת כעת "Render blocking requests". הרעיון לא השתנה – היא מזהה קבצי CSS ו-JavaScript שחוסמים את הדפדפן מלרנדר את העמוד.

כשהדפדפן נתקל בקובץ CSS או JS, הוא עוצר, מעבד את הקובץ ורק אז ממשיך לרנדר. עצירה זו נקראת Render Blocking. כדי להימנע מכך, ניתן לטעון קבצים אלו באמצעות טכניקות "defer" ו-"async".

אם אתם מעוניינים ללמוד עוד, תנו מבט בפוסט על עיכוב פריסת Javascript ובפוסט יצירת CSS קריטי ותיקון משאבים החוסמים עיבוד.

האם לתקן זאת?

בהחלט. מרבית תוספי הקאש יעשו זאת עבורכם. אלו מאפשרים הטמעה של defer ו-async עבור קבצים החוסמים טעינה ואף מייצרים CSS קריטי לחלקו העליון של העמוד.

שימו לב ובדקו את האתר לאחר שימוש בטכניקות אלו, מכיוון שהן עלולות לשבור פונקציונליות באתר שלכם.

6. Font Display

בעבר נקראה "Ensure Text Remains Visible During Webfont Load", כעת ה-Insight נקרא פשוט "Font display". הוא חל על כל פונט רשת שאתם טוענים, בין אם באמצעות Google Fonts, TypeKit או באמצעות font-face@.

מכיוון שפונטים דורשים זמן לטעון, ישנו זמן בו לא מוצג טקסט על המסך. הפתרון הוא להציג פונט מערכתי בסיסי בזמן הטעינה באמצעות התכונה font-display. כתבתי על כך בהרחבה בפוסט על התכונה font-display.

אם אתם רוצים לתקן זאת, השתמשו ב-font-display: fallback או font-display: swap עבור כל פונט.

7. שימוש יעיל בזיכרון מטמון – Use Efficient Cache Lifetimes

בעבר נקראה "Serve Static Assets With an Efficient Cache Policy", כעת ה-Insight נקרא "Use efficient cache lifetimes".

קאשינג בדפדפן שומר קבצים בזיכרון הדפדפן ומשפר משמעותית את הביצועים בביקורים חוזרים. מרבית השרתים תומכים בכך כברירת מחדל, אך ניתן לכוונן את ההגדרות.

אם הקבצים המסומנים מוגשים מהדומיין שלכם, עליכם לתקן זאת. מרבית תוספי הקאש יטפלו בכך אוטומטית. כמו בהמלצות אחרות, ניתן לשלוט רק על קבצים מהשרת שלכם, לא על קבצים צד שלישי.

תנו מבט בפוסט כיצד לשפר את הביצועים של אתרי וורדפרס. זהו הפוסט הכי נצפה בבלוג ותמצאו שם הגדרות ואופטימיזציות שלא בהכרח מוזכרות כאן.

8. גורמים להזזת פריסה – Layout Shift Culprits

זהו Insight חדש ומאוחד ב-Lighthouse 13 שמקבץ את הביקורות הישנות "Avoid Non-Composited Animations" ו-"Unsized Images". הוא עוזר להבין מה גורם ל-Cumulative Layout Shift (CLS) בעמוד.

אם אתם רואים Insight זה, אלמנטים בעמוד זזים ממקומם במהלך הטעינה. סיבות נפוצות כוללות תמונות ללא רוחב וגובה מפורשים, תוכן שנטען דינמית ואנימציות שגורמות לחישוב מחדש של הפריסה.

9. צדדים שלישיים – 3rd Parties

בעבר נקראה "Third-party Summary", כעת ה-Insight נקרא פשוט "3rd parties". הוא מפרט את כל הסקריפטים מצד שלישי הנטענים בעמוד ואת השפעתם על הביצועים.

ככל שתטענו פחות סקריפטים מצד שלישי, האתר יהיה מהיר יותר. עברו על הרשימה ושאלו את עצמכם אם כל שירות צד שלישי באמת נחוץ.

10. LCP Breakdown ו-LCP Request Discovery

אלו שני Insights חדשים ב-Lighthouse 13 שעוזרים לכם להבין ולשפר את ה-Largest Contentful Paint (LCP). "LCP breakdown" מראה כיצד זמן ה-LCP מתחלק בין שלבים (זמן שרת, זמן טעינת משאב, זמן רינדור). "LCP request discovery" עוזר לוודא שמשאב ה-LCP מתגלה על ידי הדפדפן מוקדם.

11. Forced Reflow

זהו Insight חדש נוסף ב-Lighthouse 13. הוא מזהה קוד JavaScript שמאלץ את הדפדפן לחשב מחדש פריסות באופן סינכרוני, מה שעלול לגרום לגמגום ולאינטראקציות איטיות. אם אתם רואים סימון כאן, סביר שבעמוד יש JavaScript שקורא וכותב מאפייני פריסה בלולאה צפופה.

---

דיאגנוזה וניתוחים – Diagnostics

חלק ה-Diagnostics ב-Lighthouse 13 מכיל ביקורות נוספות שמספקות מידע שימושי אך אינן מקובצות ל-Insights. הנה מה שעשוי להופיע:

12. צמצום CSS שאינו בשימוש – Reduce Unused CSS

כמעט כל בעל אתר וורדפרס ייראה דיאגנוזה זו. תבניות ותוספים טוענים מידע CSS גם כשהוא לא נחוץ בעמוד מסוים, מכיוון שהם מכוונים לכמה שיותר משתמשים עם הגדרות שונות.

הסיכוי להעלים הערה זו לחלוטין הוא אפסי אלא אם אתם מפתחים את התבנית בעצמכם. ההשפעה של CSS שאינו בשימוש בדרך כלל אינה דרמטית, ולכן הייתי מציע לטפל בהמלצות אחרות קודם.

אם אתם רוצים לנסות, בדקו איזה CSS אינו בשימוש באמצעות Chrome Developer Tools תחת לשונית Coverage. תוספים כגון WP-Rocket מציעים "Remove Unused CSS", ו-LiteSpeed Cache מציע "Unique CSS (UCSS)".

13. צמצום JavaScript שאינו בשימוש – Reduce Unused JavaScript

בדומה ל-CSS, דיאגנוזה זו מסמנת קבצי JavaScript שנטענים אך אינם בשימוש מלא בעמוד. הסרת JavaScript מיותר מקטינה את גודל ההורדה ואת זמן הפירוש, מה שמשפר ישירות את Total Blocking Time.

בדקו אילו תוספים וסקריפטים נטענים בכל עמוד ושקלו להשתמש בתוסף כגון Plugin Organizer או Asset CleanUp לביטול סלקטיבי של סקריפטים בעמודים בהם אינם נחוצים.

שתי הדיאגנוזות הבאות קשורות להשפעה שיש ל-JavaScript על ביצועי העמוד. עליכם לדעת מעט על JavaScript כדי להבין אותן. אך קודם נזרוק מספר מילים על ההשפעה השלילית שיש ל-JavaScript.

נספח – ההשפעה השלילית של Javascript על ביצועי האתר

בניגוד ל HTML ו CSS שהם אבני הבסיס של עמוד אינטרנטי, Javascript במרבית המקרים אינה מרכיב הכרחי. השימוש ב JS הוא בדרך כלל כדי להוסיף אלמנטים אינטראקטיבים כדוגמת סליידרים, קרוסלות, אנימציות, נגני וידאו וכדומה.

אם נטען הרבה Javascript בעמוד מסויים הוא יאט את אותו עמוד במרבית המקרים וזאת כי:

• על הדפדפן להוריד את קובץ ה Javascript.
• לפרוס את ה Javascript (שיהיה קריא על ידי הדפדפן).
• להריץ את ה Javascript בדפדפן.

בהתאם לקוד עצמו ותפקידו, השלב השלישי שציינתי ידרוש זמן רב (במונחי זמן טעינת אתרים). מעבר לכך ההשפעה השלילית של JS גדלה אקספוננציאלית במכשירי מובייל מכיוון שלאלו כח עיבוד חלש יותר.

אם אינכם אלו שכתבו את קוד ה Javascript הדרך היחידה שלכם להתמודד עם ההשפעה השלילית שזה מייצר היא להסיר את אותו קוד.

אז לאחר שהוצאתי את שעל ליבי בהקשר זה בוא נמשיך עם אותם דיאגנוזות ש PageSpeed מציג לנו…

14. יש לצמצם את העבודה על התהליכון הראשי – Minimize main-thread work

לא תמצאו הסבר טוב יותר על המלצה זו מההסבר שנכתב במדריך של Addy Osmani (לשעבר ראש חווית המפתחים ב-Chrome בגוגל): Javascript Start-up Optimization.

בכמה מילים (שאולי כבר הזכרנו לפני מספר פסקאות), ל Javascript מחיר גבוה והוא משפיע על ביצועי האתר שלכם. עליכם להבין שככל שנטען יותר JS, ייקח זמן רב יותר לדפדפן לפרוס ולהריץ אותו, ומכאן שייקח זמן רב יותר עד שהגולשים באתר יוכלו לבצע אינטראקציה כלשהי.

האם ניתן לתקן זאת?

כן, על ידי הסרת Javascript כמה שניתן מהאתר שלכם. זה אומר להסיר תוספים ולבטל בין היתר אפשרויות אינטראקטיביות בתבנית שלכם או באותו Page Builder בו אתם משתמשים.

15. יש לקצר את זמן הביצוע של JavaScript

דיאגנוזה זו מציינת שביצוע JavaScript באתר שלכם לוקח זמן רב. ייתכן ותראו הערה זו בדו"ח על מובייל אך לא בדסקטופ, מכיוון שכח העיבוד של מחשבים גדול בהרבה ממכשירי מובייל.

האם עליכם לטפל בכך?

כן. הסירו כמה שיותר JavaScript שאינו הכרחי מהאתר. בדקו אם קיימים קבצים שאינם נחוצים ומצאו דרך להסיר אותם.

הסרה וביטול טעינה של קבצי JavaScript היא דרך מעולה לשפר את ה-Total Blocking Time (TBT) עליו דיברתי בחלקו הראשון של המדריך.

---

16. יש להמנע מהעברה של מטענים ייעודיים ענקיים ברשת – Avoid enormous network payloads

המלצה זו מתייחסת בעיקר לגודל הכללי של העמוד. גודל העמוד נקבע על פי כל הקבצים האינדיבידואלים (נכסים) בהם האתר שלכם משתמש – תמונות, קבצי CSS, קבצי JS, פונטים וכדומה.

האם עליכם לטפל בהמלצה זו?

PageSpeed יציג הערה זו אם הגודל הכולל של העמוד חורג מהסף המומלץ (כ-5MB). עם זאת, נסו לכוון לגודל כמה שיותר נמוך – 1.5MB ומטה הוא יעד ריאלי עבור רוב האתרים. תהיה לכך השפעה משמעותית על מהירות הטעינה במיוחד במובייל.

17. אופטימיזציה לגודל ה-DOM – Optimize DOM Size

בעבר נקראה "Avoid Excessive DOM Size", כעת הדיאגנוזה נקראת "Optimize DOM size" ב-Lighthouse 13. ה-DOM (Document Object Model) הוא המבנה של עמוד שנוצר מהקוד שמרנדר אותו.

כל אלמנט שאתם מוסיפים לעמוד הוא עוד צומת. ככל שיש יותר אלמנטים, ה-DOM מורכב יותר ולוקח יותר זמן לדפדפן לבנות ולרנדר אותו.

שימוש בתבניות קנויות ותוספים, ובמיוחד Page Builders, מגדיל את כמות הצמתים ב-DOM באופן משמעותי.

האם עליכם לטפל בכך?

אם יש לכם אפשרות, הימנעו מבניית עמודים מורכבים מדי והימנעו משימוש ב-Page Builders. דיאגנוזה זו מהווה אינדיקציה למורכבות הכוללת של העמוד. הסרת אלמנטים ופישוט יביאו לשיפור.

הנה פוסט שכתבתי המפרט יותר על ההערה Avoid excessive DOM size, תנו מבט!

18. הימנעות ממשימות ארוכות ב-Main Thread

דיאגנוזה זו (בעבר "Avoid Long Tasks") מסמנת משימות JavaScript שלוקחות יותר מ-50 מילישניות, חוסמות את ה-Main Thread ומונעות מהדפדפן להגיב לקלט המשתמש. נושא זה קשור ישירות למדד INP (Interaction to Next Paint).

Core Web Vitals ו-PageSpeed Insights

חשוב לציין כי מאז כתיבת המדריך המקורי, גוגל הציגה את מדדי Core Web Vitals כחלק מנוסחת הדירוג. שלושת המדדים הנוכחיים הם:

• LCP (Largest Contentful Paint) – מודד כמה זמן לוקח להציג את האלמנט הגדול ביותר בחלקו הקריטי של העמוד. הסף הרצוי הוא 2.5 שניות או פחות.
• INP (Interaction to Next Paint) – מדד זה החליף את FID (First Input Delay) במרץ 2024 ומודד את התגובתיות של העמוד לאורך כל האינטראקציות. הסף הרצוי הוא 200 מילישניות או פחות.
• CLS (Cumulative Layout Shift) – מודד יציבות ויזואלית של העמוד. הסף הרצוי הוא 0.1 או פחות.

מדדים אלו משפיעים על הדירוג בגוגל ומופיעים בחלק נתוני השטח (Field Data) של PageSpeed Insights. אם אתם רואים את אותם מדדים בירוק – אתם במצב טוב.

שאלות נפוצות

שאלות נפוצות על Google PageSpeed Insights:

---

מילים אחרונות על Google PageSpeed Insights

ניתן לומר כי בעל אתר וורדפרס ממוצע, זה שאינו טכני, יכול בהחלט להעזר בדו״ח ש PageSpeed Insights מספק. עם זאת, הוא מציג לאלו ציון בהפשטה מוגזמת על ידי מספר וצבע ואותן המלצות שהוא מציג הן טכניות מדי עבור אלו.

אז עליכם להשתמש בנתונים וההמלצות שכלי זה מציג יחד עם כלים נוספים לבדיקת מהירות הטעינה כדי לקבל את התמונה המלאה על ביצועי האתר שלכם בעולם האמיתי.

כך או כך, מקווה שמדריך זה שפך קצת אור על אותו דו״ח ש PageSpeed מספק. אם אתם בסדר עם העולם, מאד אשמח אם תשתפו את הפוסט או תקשרו אליו – לוקח המון המון שעות לכתוב פוסט במימדים אלו והפידבק מעודד שלכם להמשיך ולכתוב…