כדי להתעדכן בשינויים בביצועי אתרים ובחיפוש, בחרו כמה מקורות רשמיים, בדקו אותם במועדים קבועים והשוו כל הודעה למצב באתר שלכם. פעלו כשיש מועד מחייב שרלוונטי לכם או ראיות לבעיה, ואז בדקו את התוצאה באמצעות המדידות המתאימות. כותרת לבדה אינה הוראת עבודה.
קודם כול, הבינו מה השתנה
ידיעה על ביצועי אתרים יכולה לעסוק במדד חדש, בדוח שהשתנה או בעדכון של התוכנה שמפעילה את האתר. אלה סיבות שונות לבדיקה, וכל אחת מחייבת בירור אחר. לפני שפותחים את מערכת ניהול התוכן, כתבו איזה סוג של שינוי עומד בפניכם.
המעבר מ-First Input Delay, או FID, ל-Interaction to Next Paint, או INP, ממחיש את ההבדל. לפי התיעוד של צוות Chrome באתר web.dev, מדד INP החליף את FID כחלק מ-Core Web Vitals ב-12 במרץ 2024. זהו שינוי שכבר התרחש, ולא מועד עתידי שצריך להיערך אליו.
FID מדד את ההמתנה עד לתחילת העיבוד של האינטראקציה הראשונה. INP בוחן את התגובתיות לאורך הביקור, כולל זמן העיבוד וההמתנה לעדכון הבא של התצוגה. לכן, תוצאת FID ישנה אינה יכולה לקבוע אם האינטראקציות כיום מגיבות במהירות. המשימה המעשית היא לעדכן את המדידה ולבדוק את רכיבי הממשק שבהם המבקרים משתמשים.
שינוי בדוח דורש תגובה אחרת. בתיעוד של Lighthouse מוסבר שמשקלם של המדדים בציון השתנה לאורך השנים. ציון שונה אינו מוכיח כשלעצמו שהקוד שפורסם באתר נעשה איטי יותר. רשמו את גרסת הכלי ובדקו את המדידות שעליהן מבוסס הציון לפני שאתם מעבירים משימה לפיתוח.
עדכון של פלטפורמה עשוי להשפיע על הקוד, ההגדרות או הרכיבים שבהם האתר תלוי. הודעה על חיפוש עשויה לעסוק בדרך שבה תוצאות מוערכות. אף אחת מהן אינה קובעת אוטומטית איזה עמוד צריך לערוך. זהו את התכונה המושפעת, את מועד התחולה ואת מעמד השינוי: הצעה, ניסוי או עדכון שכבר שוחרר.
תנו לכל מקור תפקיד מוגדר
השתמשו ב-Google Search Central כדי לעקוב אחר הנחיות חיפוש והסברים לשינויים שהוכרזו. כשכותרת מרמזת על דרישה חדשה, קראו את התיעוד המקורי. לבדיקת מועדי הפצה ותקלות שדווחו, היעזרו בלוח הסטטוס של Google Search. הפרידו בין תאריך פרסום ההודעה לבין התאריך שבו השינוי נכנס לתוקף.
ב-web.dev תמצאו הסברים על ביצועים והנחיות ליישום. זה המקום להבין מה מדד מסוים מודד לפני שמחליטים איך לשפר אותו. בדקו את התיעוד העדכני של המדד לצד כל מאמר ישן שבו אתם נעזרים, במיוחד אם המאמר הישן עוסק ב-FID.
ב-Chrome for Developers עקבו אחר שינויים בדפדפן, ב-DevTools, ב-Lighthouse ובדוח חוויית המשתמש של Chrome, המכונה CrUX. שאלו אם העדכון משפיע על המדידה, על הבדיקות או על התנהגות של הדפדפן שהאתר מסתמך עליה. אפשרות אבחון חדשה עשויה להצדיק בדיקה נוספת, בלי לחייב עיצוב מחדש של האתר מיד.
לבסוף, עקבו אחר יומן השינויים של מערכת הפרסום, ערכת העיצוב, התוספים החשובים ושירות האחסון שלכם. הגבילו את הרשימה לרכיבים שבשימוש בפועל. מנו אדם שירכז הודעות רלוונטיות, גם אם הוא אחראי במקביל לפרסום התוכן ולתחזוקה. רשימת מקורות ללא אחראי הופכת במהרה לעוד זרם מידע שאיש אינו קורא.
בנו שגרת בדיקה שאפשר להתמיד בה
באתר קטן, סקירה שבועית של המקורות האלה היא נקודת פתיחה מעשית, לא דרישה רשמית של Google. הגדירו התראות נפרדות על השבתות ועל הודעות אבטחה דחופות, כדי שיגיעו אליכם בזמן. בתקופת מעבר אתר או העלאת גרסה משמעותית, הגבירו את תדירות הבדיקה.
בסקירה השבועית אספו רק הודעות שעשויות להשפיע על המערכת שלכם. לכל הודעה ציינו רכיב מושפע, בדיקה נדרשת, אחראי ומועד לבחינה נוספת. אם אינכם מצליחים לזהות קשר לאתר, השאירו את הנושא ברשימת מעקב במקום להפוך אותו מיד למשימה.
פעם בחודש בחנו את הנושאים שטרם נסגרו לצד מגמות הביצועים והחיפוש. סגרו נושאים שאינם רלוונטיים עוד. תעדו גם החלטות לדחות עבודה ואת הסיבות להן, כדי שאותה כותרת לא תפתח מחדש את אותו דיון שוב ושוב.
אחרי כל העלאת גרסה משמעותית, בצעו בדיקות שמתאימות למה שהשתנה. תבנית מאמרים חדשה מחייבת בדיקות אחרות מאלה שנדרשות אחרי ניסוח מחדש של פסקה. השגרה צריכה להפוך עבודה מועילה לצפויה, ובה בעת להשאיר מקום לטיפול בכשל אמיתי.
מיינו את העדכון לפני שמשנים את האתר
הטבלה הבאה מסייעת לקבל החלטה. מועדי הפעולה הם הצעה לשגרת עבודה, אלא אם ההודעה הרשמית קובעת מועד מחייב.
| השינוי | על מי הוא משפיע | מה לבדוק | מתי לפעול |
|---|---|---|---|
| שינוי במדד או בהגדרת המדידה | אתרים שמשתמשים במדד בדוחות או בהתראות | תמיכה במדד, הגדרות ונתונים היסטוריים שאפשר להשוות | לתכנן את המעבר לפי מועד התחולה הרשמי |
| שינוי בציון או בדוח של כלי | מי שמשווים תוצאות בין גרסאות הכלי | גרסה, הגדרות וערכי המדדים עצמם | לחקור הבדל שאפשר לשחזר לפני שינוי קוד |
| עדכון של פלטפורמה, ערכת עיצוב או תוסף | אתרים שמשתמשים ברכיב הרלוונטי | תאימות, הגדרות ברירת מחדל שהשתנו ותבניות חשובות | לבדוק לפני ההפצה ולתעדף תיקונים דחופים שמתועדים בהודעה |
| עדכון חיפוש שאושר רשמית | אתרים שבוחנים שינוי מתמשך בתוצאות החיפוש | מועדי ההפצה, העמודים והשאילתות שהושפעו | לפעול לפי הנחיות הבדיקה הרשמיות ולהימנע משכתוב בגלל כותרת בלבד |
| הרעה אחרי העלאת גרסה באתר | מבקרים שמשתמשים בעמודים או ברכיבים שנפגעו | שחזור הבעיה, שינויים אחרונים ואפשרות חזרה בטוחה לאחור | לחקור במהירות ולהחזיר תחילה לפעולה את התכונות שנפגעו |
לכל נושא הגדירו איזו החלטה צריך לקבל. "לבדוק ביצועים" היא משימה רחבה מדי. "לבדוק אם התפריט החדש מגיב באיחור להקשות בנייד" היא שאלה ברורה עבור מי שיבצע את העבודה. קבעו איזו תוצאה תצדיק תיקון ואיזו תוצאה תאפשר לסגור את הנושא.
תנו לנתוני האתר לקבוע את סדר העדיפויות
קראו נתוני שטח יחד עם היקף המדידה
דוח Core Web Vitals ב-Search Console מקבץ כתובות URL דומות ומפריד בין תוצאות בנייד ובמחשב. השתמשו בקבוצה שסומנה כבעייתית כדי לבחור עמודים לבדיקה. אל תניחו שכתובת הדוגמה היא העמוד היחיד שנפגע, או שתבנית משותפת מוכיחה מה גרם לבעיה.
PageSpeed Insights מציג גם נתוני שטח ממשתמשים אמיתיים וגם בדיקת מעבדה של Lighthouse. נתוני השטח מכסים חלון מתגלגל של 28 ימים. לכן תיקון שעלה היום נמדד באותו חלון לצד ביקורים קודמים; הדוח אינו מספק פסק דין מיידי על הגרסה החדשה.
בדקו אם PageSpeed Insights מציג נתונים של הכתובת שנבדקה או של מקור האתר, origin, הכולל עמודים שחולקים פרוטוקול, שם מארח ופורט. נתוני המקור מתייחסים להיקף רחב יותר מהעמוד שהתבקש. אם אין די נתונים מתאימים באף אחת מהרמות, היעדר תוצאות שטח אינו מעיד על הצלחה או על כישלון.
ההנחיות הרשמיות של web.dev מגדירות ביצועים טובים כ-LCP של 2.5 שניות לכל היותר, INP של 200 אלפיות השנייה לכל היותר ו-CLS של 0.1 לכל היותר, באחוזון ה-75 ובנפרד לנייד ולמחשב. האחוזון מתאר התפלגות של חוויות שימוש, לא ממוצע ולא ביקור בודד שהיה מהיר במיוחד.
הפרידו בין תוצאות חיפוש לבין מדידות מהירות
כשבוחנים שינוי בחיפוש, בדקו קליקים, חשיפות, עמודים ושאילתות ב-Search Console. השוו תקופות דומות ובחנו דפוסים לפי מכשיר ומדינה. המדריך של Google לירידות בתנועת חיפוש מציין גם עונתיות, בעיות טכניות ושגיאות בדיווח כהסברים אפשריים. סמיכות זמנים לבדה אינה מזהה את הסיבה.
אם אתם חושדים בהשפעה של עדכון ליבה, Google ממליצה להמתין לפחות שבוע מלא מסיום ההפצה לפני השוואת הנתונים. ההנחיה מתייחסת להערכת שינויים בחיפוש. היא אינה סיבה להשאיר עמוד מקולקל או חסימת אינדוקס שנוצרה בטעות ללא טיפול.
למשימת ביצועים הגדירו מדד הצלחה שקשור לביצועים. את בדיקת החיפוש תעדו בנפרד. בהנחיות של Google לחוויית עמוד נאמר במפורש שנתוני Core Web Vitals טובים אינם מבטיחים מיקומים מובילים. חיבור שני הדברים להבטחה אחת מקשה להעריך כל תוצאה באופן אמין.
בדקו גרסאות כשהפרטים עדיין טריים
לפני העלאת גרסה בחרו עמודים מייצגים: מאמר, עמוד רשימה ומסלול שימוש אינטראקטיבי חשוב שקיים באתר. רשמו את מדידות הבסיס, פרופיל המכשיר, הגדרות הבדיקה וגרסת התוכנה. חזרו על אותן בדיקות לאחר ההעלאה, כדי שיהיה בסיס מועיל להשוואה.
הריצו בדיקות מעבדה כדי לזהות שינויים שאפשר לחקור מיד. אחר כך השתמשו בעמוד: פתחו את התפריט, שלחו טופס ונסו מסננים רלוונטיים. הרצה רגילה של בדיקת טעינת עמוד ב-Lighthouse אינה מודדת INP, מפני שהיא אינה מבצעת אינטראקציות של משתמש. בדיקת טעינה תקינה אינה פותרת שאלה הנוגעת לתגובתיות.
נהלו יומן שינויים קצר הכולל את שעת ההעלאה ואזור הזמן, הרכיב שהשתנה, התבניות שהושפעו, תוצאות הבדיקות, האחראי ודרך החזרה לאחור. הוסיפו שינויים בסקריפטים של צד שלישי ובהגדרות הסכמה כשיש לכך קשר. ללא הרישום הזה, הבירור הבא יתחיל בניסיון לשחזר מה קרה.
אם תוצאת בדיקה משתנה באופן בלתי צפוי, חזרו עליה בתנאים דומים ובחנו את הקלטת הביצועים או את האבחון. כשאפשר, בודדו את הרכיב החשוד בסביבת בדיקות. כשמתגלה כשל ברור, בחרו תיקון ממוקד או חזרה בטוחה לגרסה קודמת, ואז בדקו שוב את מסלול השימוש שנפגע. עקבו אחר מגמות השטח ככל שמצטברים ביקורים חדשים.
הימנעו מטעויות שמייצרות עבודה נוספת
אל תעצבו מחדש את האתר בגלל תוצאת מעבדה גרועה אחת. בתיעוד של Lighthouse מצוינים תנאים משתנים, ובהם פרסומות, מכשירים ותוספי דפדפן, כמקורות לתנודות. בדיקה חוזרת מסייעת להבחין בין בעיה מתמשכת לבין הרצה שאינה ניתנת להשוואה למדידת הבסיס.
אל תהפכו הסבר שלא אומת ברשתות החברתיות להוראה לכל האתר. מצאו את ההודעה המקורית ובדקו על מי היא חלה. אם ההסבר עדיין בגדר השערה, תעדו אותו ככזה וחפשו ראיות שיכולות לתמוך בו או לסתור אותו.
אל תאגדו שינויים שאינם קשורים זה לזה בתגובה לעדכון. החלפת ערכת עיצוב, שכתוב כותרות ושינוי סקריפטים במקביל משאירים כמה הסברים אפשריים לכל תוצאה שתגיע אחר כך. הגבילו את היקף ההתערבות כך שאפשר יהיה ללמוד מהתוצאה, ובמקביל טפלו בבעיות דחופות ללא עיכוב מיותר.
היכן ClickSyrup משתלב
החדשות והמדריכים של ClickSyrup לבעלי אתרים עוסקים בחיפוש ותנועה, בהכנסות מאתרים ובפלטפורמות וכלים. השתמשו בקריאה הרחבה הזאת כדי לזהות נושאים שכדאי לבדוק, ואז עיינו בתיעוד הרשמי הרלוונטי ובמדידות שלכם לפני ביצוע שינוי. שמרו על ההבחנה הזאת לאורך העבודה: מציאת ידיעה רלוונטית היא תחילתה של החלטה, ולא הוכחה שהאתר זקוק לתיקון מסוים.
רשימת בדיקה קצרה לפני הפעולה
- אמתו את ההודעה המקורית ואת מועד התחולה.
- זהו את הרכיב, העמודים והמבקרים המושפעים.
- בדקו את היקף הנתונים, המכשיר, התקופה ותנאי הבדיקה.
- בחרו פעולה מוגדרת, אחראי ודרך לאימות התוצאה.
- תעדו את התוצאה ואת מועד הבדיקה הבא.
התוצר המועיל של הסקירה הבאה הוא החלטה מנומקת: לתקן משהו, לבדוק אפשרות, לעקוב אחר התפתחות או לא לפעול. שמרו לצד ההחלטה מספיק ראיות כדי שתוכלו להסביר אותה גם כשהעדכון הבא יגיע.
תוכן שותפים. מאמר זה עוסק ב-ClickSyrup ומתפרסם בנפרד מהסיקור המערכתי של WebVitalsDev.
