בדיקה של Core Web Vitals
מדריך שלב אחרי שלב לזיהוי בעיות ותיעדוף תיקונים לפני עדכון חוויית העמוד (Page Experience Update) אשר ייכנס לעדכון אלגוריתם החיפוש במאי 2021
כבר במאי 2020, גוגל הכריזה כי נתוני Core Web Vitals יהפכו לחלק מהאלגוריתמים של גוגל במהלך 2021, אך החברה גם אמרה לבעלי אתרים שאין צורך מיידי לבצע מהלכים או פעולות בהקשר לכך. לקראת סוף 2020, גוגל כבר שיחררה יותר פרטים ופרסמה כי עדכון האלגוריתם יבוצע במאי 2021, כך שעבור בעלי אתרים ומקצועני SEO בכל העולם, הזמן ליישם פעולות בהקשר לעדכון "חוויית העמוד" הוא בהחלט עכשיו.
מהם נתוני Core Web Vitals?
המונח Core Web Vitals מתאר סט של מדדי חוויית משתמש למדידת הטעינה, האינטראקטיביות והיציבות הוויזואלית של אתרי אינטרנט. כל שלושת המדדים קשורים למהירות אתר בדרך זו או אחרת, משהו שאנו יודעים שהיה חשוב מאוד גם למנועי חיפוש וגם למשתמשים במשך הרבה מאוד זמן.
בין היתר, מה שמעניין לגבי Core Web Vitals ועדכון Page Experience בפרט, הוא שגוגל בדר"כ לא גלויה במיוחד לגבי שינויים ספציפיים בעדכוני האלגוריתם שלה. אך במקרה זה, קיבלנו מדדים מדויקים שעלינו למדוד ולשפר וגם את התאריך בו השינוי הזה ייכנס לפועל. זה ממחיש כי Page Experience יהיה עדכון חשוב, אך גם כזה שאנו כאנשי דיגיטל יכולים להתכונן לקראתו, כל עוד תהליך הבדיקה מפורט ומדויק. לפניכם פירוט המדדים שיש לנתח במסגרת בדיקת Core Web Vitals:
- Largest Contentful Paint (LCP): מודד ביצועי טעינה, קרי כמה זמן לוקח לפריט הגדול ביותר על המסך להיטען. כדי לספק חוויית משתמש טובה, LCP צריך להתרחש בתוך מקסימום 2.5 שניות מהרגע בו העמוד מתחיל להיטען, או מקסימום של 4 שניות כדי להימנע מציון גרוע (Poor”"). שימו לב שגם מדד שבין 2.5 שניות ל-4 שניות עדיין זוכה לציון של "מצריך שיפור".
- First Input Delay (FID): מודד אינטראקטיביות – קרי, כמה זמן לוקח לעמוד להגיב כאשר המשתמש מקליק על משהו. כדי לספק חוויית משתמש טובה, עמודים צריכים להחזיר ציון FID של פחות מ-100 מילי-שניות, כאשר ציון של 100-300 מילי-שניות יספק ציון "מצריך שיפור" ותוצאה גבוהה (איטית) יותר תספק ציון גרוע. נציין כי בתהליך הבדיקה המפורט כאן נעשה שימוש במדד דומה, "Total Blocking Time" (TBT), זאת מכיוון שמדד ה-FID להלן דורש מידע מעשי "מהשטח", אך בדיקה זו מסתמכת על נתוני "מעבדה" מכיוון שנתוני שטח לא תמיד יהיו זמינים עבור האתר שאתם בודקים.
- Cumulative Layout Shift (CLS): מודד יציבות ויזואלית – קרי, האם העמוד קופץ בצורה לא תקינה כאשר המשתמש גולל דרך התוכן. לציון של חוויית משתמש טובה, עמודים צריכים לתחזק מדד CLS של פחות מ-0.1, כאשר ציון גבוה יותר ועד 0.25 יספק ציון "מצריך שיפור" וגבוה מכך ציון גרוע.
הבדיקה המוסברת כאן מתמקדת במדדים עם ציון "גרוע" מכיוון שאלו יהיו אזורי הטיפול בעדיפות העליונה, אך אתם יכולים לכוונן לעצמכם את התוצאות כך שיכללו גם מדדים המחזירים ציון של "מצריך שיפור". עכשיו אנחנו יודעים מה אנחנו מודדים, בואו ניכנס לתהליך הבדיקה עצמו.
איך לבצע בדיקת Core Web Vitals באמצעות Screaming Frog
לדעת מה הם נתוני Core Web Vitals זה דבר אחד, אך למצוא דרך לבדוק ולבקר את הנתונים באתרים שלכם או של לקוחותיכם ולתקשר בעיות בדרך שתהיה גם שימושית ואשר מקדמת ביצוע פעולות, זה כבר עניין אחר ומאתגר יותר. אבל בהחלט נראה שאנשי SEO בכל העולם יצטרכו ללמוד את הנושא וליישם אותו. בחלק זה של המדריך לגבי ביקורת Core Web Vitals נשתמש במערכת המצוינת ורבת היכולות של Screaming Frog.
כדי להתחיל את הבדיקה, תזדקקו לשלושה דברים:
- גרסה משולמת של זחלן האתרים Screaming Frog.
- מפתח API של PageSpeed Insights– אשר תוכלו לקבל מעמוד המוצר של גוגל.
- הדומיין של האתר שאותו אתם רוצים לבדוק.
צעד 1: חברו את מפתח ה-API של PageSpeed Insights ל- Screaming Frog
חיבור ה-API למערכת של Screaming Frog יאפשר את הגישה לנתוני PageSpeed Insights ולהמלצות על בסיס כל עמוד בנפרד. אתם מקבלים מספר מוגבל של שאילתות PageSpeed Insights (כ-25,000 ליום) אך זה אמור להספיק לאתרים קטנים יחסית. באתרים גדולים יותר תוכלו ליישם תובנות מהעמודים שכן תקבלו שאילתות לגביהם על יתר האתר.
- עם מפתח ה-API של PageSpeed Insights שלכם זמין, פתחו את Screaming Frog ונווטו אל Configuration > API Access > PageSpeed Insights
- הדביקו את מפתח -API שלכם לשורת הטקסט "Secret Key"
- לחצו על התחברות – Connect
לאחר ההתחברות, לחצו על metrics. כאן תוכלו להגדיר את המדדים (metrics) שיוצגו בתוך הזחילה שלכם. אפשר לבחור בכל קבוצות המדדים (All Metric Groups), אבל אפשר גם לבחור רק את האפשרויות שאתם רוצים.
קבוצות המדדים הזמינות הן כדלקמן:
- Overview– סקירה: מספקת מידע כללי לעמוד, למשל גודל העמוד ופוטנציאל לקיצור זמני טעינה שאפשר להשיג בעמוד.
- מדדי CrUX: נתונים מדו"ח חוויית המשתמש של כרום (Chrome User Experience Report). אם קיים מידע אמיתי ממשתמשים שאישרו שליחת נתונים, הוא יופיע בקטגוריה זו.
- מדדי Lighthouse: רוב נתוני המעבדה שאנו משתמשים בו בבדיקה מגיע מכאן, כולל ציוני LCP, TBT ו-CLS שהוסברו למעלה.
- Opportunities – הזדמנויות: קטגוריה המספקת המלצות לשיפורים בזמני טעינת עמודים, ספציפיות לכל עמוד.
- Diagnostics– אבחנות: קטגוריית מדדים המספקת נתונים נוספים לגבי הביצועים הכוללים של האתר בו המערכת זוחלת.
צעד 2: זחילה באתר
השלב הבא בתהליך הוא להתחיל את הזחילה באתר שבו מריצים את הבדיקה. העתיקו שם הדומיין של האתר והדביקו לקופסת הטקסט בראש העמוד, זו שכתוב עליה "Enter URL to spider". לאחר שתתחילו את הזחילה, תראו שמוצגות לכם בפינה הימנית העליונה שתי שורות התקדמות, גם Crawl וגם API. תצטרכו לחכות ששתיהן תגענה ל-100% לפני תחילת ניתוח הנתונים.
צעד 3: דו"ח על היקף הבעיות
לפני שתיכנסו לפרטים הספציפיים ולעומק הדברים שיש לתקן ולשפר באתר, יש להבין מה היקף וגודל הבעיה באופן כללי. כדי לעשות זאת, עליכם להסתכל מהו אחוז הדפים שנכשלו מלהגיע לסף המינימום בכל נתון Core Web Vitals.
בתפריט הניווט העליון, בחרו באפשרות PageSpeed ואז לחצו על Export (ייצוא) לפורמט של אקסל.
כאשר אתם מסתכלים על הנתונים שייצאתם ממערכת Screaming Frog, מצאו את הטורים הבאים ובצע וסינון בהתאם:
- Largest Contentful Paint Time (מילי-שניות):סננו כדי למצוא את העמודים עם ציון LCP של 4000ms או יותר.
- Total Blocking Time:סננו למצוא את כל העמודים עם ציון TBT של 300ms או יותר.
- Cumulative Layout Shift: סננו למצוא את כל העמודים עם ציון CLS של 0.25 או יותר.
הוסיפו את הנתונים האלו לגיליון אקסל נפרד כך שאתם או לקוחותיכם תוכלו לראות את העמודים שכשלו בכל סוג Core Web Vitals. מתוך זה תוכלו לבנות דו"ח הסבר תמציתי ואפקטיבי לגבי היקף העמודים שכשלו בכל אחד ממדדי Core Web Vitals. להלן דוגמא לתוצאות של דו"ח שכזה שניתן למשל לשלוח ללקוח:
- 95% מהעמודים מציגים תוצאת Largest Contentful Paint של מעל 4 שניות (כשל במדד) – ראה בלשונית "LCP >4" בגיליון האקסל המצורף.
- 58% מהעמודים קיבלו תוצאת Total Blocking Time של מעל 300 מילי-שניות (כשל במדד) – ראה בלשונית "TBT >3ms" בגיליון האקסל המצורף.
- 93% מהעמודים קיבלו תוצאת Cumulative Layout Shift של מעל 0.25 (כשל במדד) – ראה בלשונית "CLS >0.25" בגיליון האקסל המצורף.
עכשיו אתם חמושים ברשימה מלאה (או חלקית אם האתר היה גדול מדי) של עמודים אשר נכשלים לעמוד בדרישות המינימום במדדי חוויית המשתמש Core Web Vitals. כך מפתחי האתר יכולים לדעת איפה לחפש עמודים עם בעיות בחוויית המשתמש. אם אתם מזהים דפוסים כלשהם (למשל, הבעיות הן רק בעמודי בלוג וכדומה), אז יש לצרף זאת לדיווח הכולל כמובן.
צעד 4: זיהוי בעיות ספציפיות בכל עמוד והצגת המלצות מתאימות
כאן לוקחים נתונים מהבדיקה והופכים אותם לפתרונות לבעיות בזמני הטעינה ובחוויית המשתמש. אנחנו יודעים כעת כי מספר מסוים של עמודים נכשלים בדרישות המינימום של Core Web Vitals, אך מה אנחנו/הלקוח יכולים לעשות לגבי זה? כאן ה-API של PageSpeed Insights ממש עושה את הקסם שלו.
בצד הימני של מערכת Screaming Frog, בלשונית Overview, גללו למטה לאפשרות PageSpeed. כאן תמצאו את רשימת הבעיות וההמלצות הנוגעות הנוגעות למהירות העמוד וברוב המקרים גם למדדי Core Web Vitals.
בחלק זה של הדו"ח יש מגוון רחב של נושאים מפורטים. אם אתם נתקלים בנושא או בעיה שאינכם מכירים, ניתן לחפש מידע לגבי זה באתר web.dev של גוגל המיועד בדיוק לנושא זה של Core Web Vitals. בעוד שהמידע הזמין בתוך Screaming Frog ו- PageSpeed Insights לא מציג רשימה מלאה לחלוטין של כל בעיה אפשרית העשויה להשפיע על Core Web Vitals, המידע שכן זמין בהחלט מסייע בעת ניתוח האתר שלכם או של לקוחותיכם כמכלול.
לחצו על בעיה כדי לראות את העמודים המושפעים ממנה ויצאו אותם כדי לשמור בגיליון הנתונים שלכם. עכשיו אתם מדווחים ומזהים לגבי הפרטים הספציפיים של כמה עמודים מושפעים מבעיה מסוימת ומה כתובות ה-URL של העמודים המושפעים. אם למשל יש הרבה עמודים שבהם משאבים החוסמים ומאטים טעינת אלמנטים אשר משפיעים לרעה על מדד LCP, ההמלצה תהיה לבחון את רשימת העמודים ולטפל במשאבים המשפיעים לרעה על הטעינה.
עבור כל המלצה שאתם מבצעים דרך הנתונים, תוכלו גם לראות את חיסכון הזמן (Savings) הפוטנציאלי מתיקון כל בעיה ספציפית, חיסכון המושג במילי-שניות או בבייטים. תוך שימוש בנתונים המיוצאים לכל בעיה, תוכלו לסכם את חיסכון הזמן הפוטנציאלי לכל בעיה ואת ממוצע החיסכון שניתן להשיג לכל עמוד דרך פתרון אותה בעיה. כך אפשר לבצע המלצות באילו בעיות לטפל קודם בהתבסס על היקף פוטנציאל חיסכון זמן הטעינה ושיפור חוויית המשתמש. למשל, לטפל בעיכוב טעינת תמונות שאינן בחלק המסך המוצג בעדיפות גבוהה יותר לעומת הסרת קבצי CSS שאינם בשימוש.
צעד 5: דיווח על דוגמאות של בעיות ספציפיות לכל עמוד
ע"י דיווח של דוגמאות לבעיות ספציפיות בכל עמוד, אנו מספקים סט נתונים מעמיק ומפורט יותר אשר מאפשר ללקוח/למפתח האתר להבין במהירות מה מהות הבעיה והאם מדובר על משהו שניתן לפתור או לא.
אם נמשיך עם הדוגמא לבדיקה המעלה כי יש בעמודים בעיה של משאבים החוסמים ומעכבים טעינת אלמנטים, אתם צריכים כעת לבחור כתובת URL המושפעת מבעיה זו ולבחור באפשרות PageSpeed Details בשורת הניווט התחתונה. הפאנל השמאלי תחתון יציג כעת מידע מהירות עמוד הרלוונטי לעמוד הנבחר. נווטו אל האפשרות Opportunities > Eliminate Render Blocking Resources.
בפאנל הימני התחתון תראו כעת את כתובות ה-URL של משאבים מעכבי טעינה באותו עמוד, הגודל שלהם (בבייטים) ואת פוטנציאל החיסכון בזמני הטעינה (מילי-שניות) שניתן להשיג אם משאבים אלו ינוטרלו.
למרבה הצער, אי אפשר לייצא בעיות ספציפיות אלו כקבוצה גדולה, אך אפשר להעתיק ולהדביק כמה דוגמאות לתוך גיליון הנתונים שלכם ושוב לחפש דפוסים. לא אחת, אותם המשאבים היוצרים בעיות יופיעו בעמודים רבים או בכל עמוד באתר, כך שאפשר ליישם את מה שלמדתם לכל האתר.
לאחר שמשכתם את הנתונים הללו לגבי כל בעיה באתר, תוכלו לספק דו"ח כתוב ומפורט עם המלצות לגבי כל בעיה לפי סדר תיעדוף ולהפנות לנתונים הפרטניים בגיליון שהכנתם.
צעד 6: לאחר יישום השינויים, בצעו זחילה חוזרת באתר והשוו תוצאות
מכיוון שעדכון Page Experience וההתבססות על תוצאות של Core Web Vitals נכנסים ליישום כבר במאי 2021, מומלץ לבצע את הבדיקה הזו בהקדם, גם כי חלק מבעיות אלו יצריכו זמן כדי לפתור אותן בצורה יעילה ונכונה. לאחר שביצעתם את השינויים הנדרשים לבעיות שעלו מהבדיקה להלן, בצעו שוב זחילה באתר ובדקו כיצד דברים השתנו. כאן נתוני אחוזי הדפים שלא עמדו בדרישות הסף של Core Web Vitals מהזחילה הראשונה יהיו שימושיים מאוד כי כך ניתן לראות בקלות ובמהירות האם השינויים שביצעתם השיגו את האפקט הרצוי.
סיכום
עדכון Page Experience לאלגוריתם החיפוש של גוגל הוא בהחלט חשוב וכך גם הדגש הרב יותר שגוגל שמה על Core Web Vitals ועל חוויית המשתמש. אך ככל הנראה אתרים שלא יעמדו בדרישות הסף של Core Web Vitals לא יספגו ירידות חדות מדי בדירוגים, בטח לא באופן פתאומי. לעומת זאת, אתרים שכן יצליחו לעמוד בדרישות המינימום או אף להתעלות מעליהן בהקשר לנתוני Core Web Vitals כנראה יחוו שיפורים קטנים בדירוגים שלהם – מה שכן יכול לפגוע במידה מסוימת בדירוג של האתרים שעדיין לא יישרו קו. הנחת יסוד זו גם תואמת להצהרות של גוגל בעצמה לגבי הנושא.
חוויית המשתמש חשובה מאוד ורק הולכת והופכת חשובה יותר, אך עמודים עם התוכן האיכותי, המדויק והטוב ביותר הם עדיין האלמנט החשוב יותר, אפילו אם יש אלמנטים מסוימים בחוויית המשתמש שאינם אופטימאליים. חוויית עמוד טובה לא עוקפת את הצורך בתוכן מעולה באותו עמוד. למרות זאת, במקרים בהם יש באתר עמודים שונים עם תוכן דומה, חוויית העמוד הופכת לחשובה הרבה יותר לתוצאות האתר והעמודים בחיפוש.
בעלי אתרים שיכולים לעמוד בדרישות של מדדי Core Web Vitals שמים את עצמם בנקודת יתרון ברורה מבחינת נראות בתוצאות החיפוש ועמידה בדרישות של גוגל לעתיד. בדיקת Core Web Vitals מקרבת אתכם צעד אחד חשוב בדרך לשם.
