Core Web Vitals : כל מה שחשוב לדעת

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

על פי גוגל, חווית השימוש מורכבת ממספר פרמטרים:

✔️ Core Web Vitals (הנושא העיקרי של המאמר הזה)
✔️ ידידותיות לניידים (Mobile Friendliness)
✔️ גלישה בטוחה
✔️ הצפנה מסוג HTTPS
✔️ השימוש ב"מודעות חודרניות" (Intrusive Ads). כלומר, מודעות שמכסות את רוב המסך ומפריעות לראות את התוכן.

בהכרזה של גוגל משנת 2021 אפשר ללמוד כי:

1. זו למעשה הפעם הראשונה מזה מספר שנים שבה גוגל מזכירה לו שלמהירות יש השפעה על דירוג האתר.
2. כל הפרמטרים שעד כה היו חלק ממהירות עליית האתר ייקראו מעכשיו Core Web Vitals. לא מדובר בפרמטרים חדשים (הם הופיעו בערך מאז שהוצג ה-Page Speed Insights), אלא במיתוג חדש.
3. חשוב לשים לב להבדל שבין הצפנה באמצעות תעודת אבטחה (HTTPS) לבין "גלישה בטוחה" (Safe Browsing). הכוונה בגלישה בטוחה היא לתוכנות מזיקות, הורדות חשודות או עמודים שמובילים לדברים האלו.
   אם עד כה גוגל פשוט הייתה חוסמת אתרים כאלו עם הודעה מתאימה ושולחת התראה ב-Search Console, מעכשיו אתרים שלא יטפלו בבעיות האלו יוכלו לספוג ירידה של ממש בדירוגים. ושוב, זה לא באמת חידוש, אבל זו פעם ראשונה שגוגל מציינת זו במפורש.
4. ביחד עם העדכון, לא תצטרכו יותר להשתמש בפורמט AMP כדי להציג חדשות / סטוריס במובייל אם האתר שלכם הוא חלק מ-Google News. מצד שני, גוגל רומזת באופן עבה שעמודי AMP הם בדרך כלל בעלי חווית השימוש הטובה ביותר.

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

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

קצת תובנות והמלצות שלי על שיפור מהירות האתר בעזרת AMP

אז מה הם בכלל ה-Core Web Vitals?

Core Web Vitals הם שלושה פרמטרים שיש להם את ההשפעה הגדולה ביותר על המהירות שבה האתר עולה וגוגל מתייחסת אליהם כשלושה חלקים מהשלם.

✔️ טעינה ראשונית: כמה זמן לוקח לאתר להיטען, נקרא גם Largest Contentful Paint (LCP)
✔️ אינטראקטיביות: מתי בדיוק אתם יכולים להתחיל לתקשר עם הדף? נקרא גם First Input Delay (FID)
✔️ יציבות וויזואלית: נקרא גם Cumulative Layout Shift (CLS). את הקונספט הזה קצת יותר קשה להסביר, אבל בגדול מדובר בשאלה עד כמה האתר משתנה או "מתבלגן" בזמן שהוא נטען.

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

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

LCP

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

מבחינת המשתמש, ה-LCP היא לרוב אותה נקודה שבו הוא ממש יכול לראות את האתר.

ל-LCP יש שלושה ציונים:

טוב – עד 2.5 שניות
טעון שיפור – בין 2.5 ל-4 שניות
גרוע – מעל 4 שניות

איך משפרים את ה-LCP?

את ה-LCP אפשר לשפר בדרכים הבאות:

1. ביצועי הקוד עצמו. לדוגמה, יש מסגרות עבודה (framework) ששולפות המון נתונים באופן איטי מדי ממסד הנתונים (דאטא בייס).
2. שימוש ב-CDN או קאש – חשוב לזכור שבמקרים רבים שהנתונים מתבססים על נתוני שימוש של גולשים אמיתיים ולכן חשוב מאוד שהאתר יעלה מהר גם אצלם ולא רק ב"מעבדה" של גוגל.
   גוגל ממליצה גם על שיטות קאש ששולחת גרסאות HTML שלא צריכות לעבוד עיבוד ברמת הקוד. לדוגמה, אם יש לנו עמוד סטטי עם מאמר, נצטרך לשלוח אותו שוב מחדש רק כשמישהו מוסיף תגובה.
3. מן הסתם, גם שרת איטי יכול לפגוע במהירות העלייה. שימו לב ששרת האחסון שלכם קרוב כמה שיותר גאוגרפית לקהל היעד העיקרי.
4. שימו את כל הקודים שמתחברים לשירותים חיצונים בהתחלה וסמנו אותם בתוך הקוד עם סימון שנקרא preconnect.
5. הסירו פקודות עיצוב לא נחוצות ב- CSS וסקריפטים מקומיים או צמצמו אותם.
6. כווצו תמונות ואפילו סרטונים (אם אתם מארחים אותם אצלכם).
7. זכרו תמיד להשתמש באלמנטים שמתאימים למכשירים מסוימים. מצד שני, בגלל שגוגל מסתכל קודם כל על גרסת המובייל (Mobile First Index), אל תסירו מהגרסה הזו אלמנטים שיש להם חשיבות מהותית לקידום.

FID

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

טוב – עד 100 מילישניות (עשירית השנייה)
טעון שיפור – בין 100 מילישניות ל-300 מילישניות
גרוע – מעל 300 מילישניות

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

איך משפרים את ה-FID?

1. טיפול נוסף בסקריפטים – בנוסף למזעור (minify) של סקריפטים קיימים, העדיפו להשתמש בסקריפטים שמחלקים את העבודה ולא בכאלו ש"טוחנים" את העמוד ויוצרים השהיות. (מכירים את העמודים האלו שמתחילם לעלות ואז נתקעים?).
   הסקריפטים הידועים לשמצה הם אלו של צד שלישי מכיוון שהם קוראים לשרת חיצוני. אם אתם יכולים, הימנעו מהם או לשים על השרת המקומי.
   ישנן גם טכניקות כמו Web Workers שלמעשה מפרידות בין סקריפטים שפועלים ברקע לבין כאלו שנוגעים לממשק המשתמש.
2. טעינה עצלה (Lazy Load) – טעינה עצלה טוענת את האלמנט רק כשהמשתמש מגיע אליו.

CLS

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

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

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

טוב – עד 0.1
טעון שיפור – בין 0.1 ל-0.25
גרוע מ – מעל 0.25

איך משפרים את ה-CLS?

1. הגדירו מראש את הממדים של התמונות, כולל באנרים ואנימציות, כך שיהיו לכם "ממלאי מקום" (Placeholders) בגודל מדויק. ניתן גם לבחור כברירת מחדל בגדלים הכי גדולים של המודעות שיש לכם במאגר, אבל אז עשויים להיווצר יותר מדי רווחים.
2. חשוב גם לטפל במצבים שבהם מודעה מסוימת אינה זמינה.
   חשוב להיזהר במיוחד ממודעות בראש העמוד מכיוון שהן דוחפות את כל התוכן למטה.
3. יש להיזהר עם הטמעות מרשתות חברתיות ש"נדחפות" אל העמוד ועדיף להשתמש בכאלו שהגודל שלהן מצוין מראש (לדוגמה , מי-טיוב) או לקבוע גודל שונה מברירת המחדל בתנאי שלא נוצרים עיוותים.
4. במידת האפשר היזהרו מ-Popups אוטומטים שלא נטענים בשכבת על. אם יש לכם כל מיני דברים כמו הסכמה לשימוש בעוגיות וכו', הצמידו אותם לחלק העליון או התחתון כך שהן לא יגרמו לתזוזות בעמוד.
5. היזהרו גם מאנימציות או טעינת פונטים בצורה כזו שמזיזה ודוחפת אלמנטים באתר.

שיפור המדדים בוורדפרס

לוורדפרס עשרות תוספי מהירות. חלק מהם גם מתגאים בכך שהם יכולים לטפל ב-Core Web Vitals, אך מכיוון שלעיתים מדובר בנושאים די מורכבים, בפועל גם כאן לפעמיים נדרשת עבודה ידנית. לדוגמה, אם נסתכל במדריך של WP-Rocket, נוכל לראות שיש המון אלמנטים שהוא לא יכול לתקן באופן אוטומטי כמו קסם.

מכיוון שסביר להניח שרוב התוספים כן יתחילו להתייחס ל-Core Web Vitals בתיעוד שלהם כדי לגרום לכם להוריד דווקא אותם, כדאי לבצע השוואה ביניהם או לראות מה אפשר לשנות בתוסף הנוכחי שאתם משתמשים בו כדי לשפר את המדדים עבור גוגל.

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

נתוני שטח ונתוני מעבדה (ולמה לא צריך להיות אובססיביים למספרים)

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

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

במקרים האלו חשוב לראות מה בדיוק הכלי מזהה ולתת לבעיות האלו עדיפות.

לסיכום

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

לעוד מדריכים באתר:

• איך לבחור מקדם אתרים
• איך לבחור חברה לקידום אתרים