Core Web Vitals: איך לתקן LCP, CLS ו-INP באתר וורדפרס

קיבלת מ-Search Console הודעה שעמודים באתר נכשלים ב-Core Web Vitals, או שדוח החוויה מלא באדום? התשובה הקצרה היא שקודם צריך לזהות איזה מדד נכשל ובאיזה מכשיר, ורק אחר כך לתקן. כל אחד משלושת המדדים, LCP, CLS ו-INP, נכשל מסיבות אחרות, ולכל אחד יש תיקון אחר.

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

הדוח נמצא ב-Search Console, והנתונים בו מגיעים מ-Chrome User Experience Report (CrUX). זה אומר שהם באים ממשתמשים אמיתיים שגלשו באתר שלך, ולא מבדיקה במעבדה. הדוח מחולק לנייד ולמחשב, ומסווג כתובות לשלושה מצבים: Good, Need improvement ו-Poor.

אלה הספים ש-web.dev מגדיר לכל מדד:

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

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

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

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

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

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

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

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

ב-PageSpeed Insights, בחלק האבחון, רואים איזה אלמנט סומן כ-LCP. אם זו תמונה, כדאי לבדוק בקוד המקור של העמוד אם יש לה loading="lazy".

אלה הדברים שבודקים ומתקנים:

• לא לטעון את תמונת ה-LCP בטעינה עצלה. web.dev כותב שאסור לעולם לטעון את תמונת ה-LCP בטעינה עצלה, כי זה תמיד יוצר עיכוב מיותר. אם הפעלת טעינה עצלה (LazyLoad) בתוסף מטמון, צריך לוודא שהתמונה הראשית של כל תבנית לא נכללת בה.
• fetchpriority. מאז וורדפרס 6.3 הליבה מוסיפה אוטומטית fetchpriority="high" לתמונה שהיא מזהה כתמונת ה-LCP הסבירה. בכל זאת כדאי לבדוק בקוד המקור שהמאפיין נמצא על התמונה שבאמת מסומנת כ-LCP.
• זמן תגובת השרת. web.dev מפרק את LCP לכמה חלקים, והראשון בהם הוא הזמן עד שהבייט הראשון מגיע מהשרת (TTFB). אם השרת איטי, שום אופטימיזציה של תמונה לא תספיק, וכאן נכנסים מטמון עמודים ואחסון.

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

אלה הסיבות ש-web.dev מונה:

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

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

התיקון מתחיל בכך שלכל תמונה יש width ו-height. אם אתה משתמש ב-WP Rocket, יש בו אפשרות Add missing image dimensions שמוסיפה את המאפיינים החסרים לתמונות. לגופנים יש אפשרות Preload fonts שטוענת מראש את הגופנים של החלק העליון בעמוד. ולפרסומות ולבאנרים שומרים מקום קבוע מראש ב-CSS, כדי שהם ימלאו מקום קיים ולא ידחפו תוכן.

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

לפי web.dev, הדפדפן מריץ את ה-JavaScript בתהליכון הראשי (main thread). טעינה, פענוח והרצה של סקריפטים יוצרים משימות ארוכות, וכל עוד משימה ארוכה רצה, הדפדפן לא מגיב ללחיצה. באתר וורדפרס זה מצטבר מהר: תוספים, בוני עמודים, צ'אטים, פיקסלים וכלי אנליטיקה.

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

מה שאפשר לעשות:

• לעבור על רשימת התוספים ולבטל את מה שלא בשימוש. כל תוסף שטוען סקריפט בכל עמוד מוסיף עבודה.
• ב-WP Rocket, האפשרות Load JavaScript deferred גורמת לדפדפן לרנדר את העמוד ולטעון את הסקריפטים אחר כך. האפשרות Delay JavaScript execution מעכבת את טעינת הסקריפטים עד לאינטראקציה הראשונה של הגולש.
• אחרי כל שינוי כזה צריך לבדוק ידנית את הדברים שחייבים לעבוד: תפריט בנייד, טפסים, הוספה לסל.

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

כשסיימת לתקן, חוזרים לדוח ב-Search Console, נכנסים לבעיה ולוחצים על Start Tracking. גוגל פותחת תקופת מעקב של 28 ימים שבה היא בודקת אם הבעיה עדיין מופיעה.

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

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

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

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