המדד 'מהירות התגובה לאינטראקציה באתר' הוא עכשיו מדד יציב של Core Web Vitals, שמחליף את 'עיכוב קלט ראשון'.
מה היום? אחרי שנים של עבודה, אנחנו מוכנים סוף סוף להפוך את Interaction to Next Paint (INP) למדד יציב של Core Web Vitals. זוהי התקדמות משמעותית בדרך שבה אנחנו מודדים את התגובה לאינטראקציה חוזרת, תוך התייחסות לחלק מהחסרונות של עיכוב קלט ראשון (FID).
בפוסט הזה נסכם בקצרה מה בדיוק עומד להשתנות היום, נגדיר לוח זמנים ספציפי יותר להוצאה משימוש ולהסרת FID מהכלים של Chrome, ונשתף מקורות מידע שיעזרו לכם לאתר ולפתור בעיות ב-INP.
מה עומד להשתנות היום
בצד Chrome, כל הכלים של מדדי הליבה לבדיקת חוויית המשתמש באתר ישקפו עכשיו את הסטטוס היציב של INP, בכל מקום רלוונטי. לדוגמה, כלים כמו PageSpeed Insights, CrUX Dashboard ותוסף Web Vitals, ידגימו באופן בולט יותר את INP בשלישיית מדדי הליבה לבדיקת חוויית המשתמש באתר. ב-PageSpeed Insights באופן ספציפי, לוגיקת ההערכה של Core Web Vitals תעריך את ביצועי ה-INP במקום את FID. מידע נוסף על השינויים הצפויים ב-Search Console זמין בפוסט בבלוג של צוות החיפוש.
בנוסף, החל מהיום, כלים מסוימים עשויים להציג הודעה על הוצאה משימוש של FID כאזהרה על כך שהמדד כבר לא משמש כמדד ליבה לבדיקת חוויית המשתמש באתר, והוא יוסר. בקטע הבא של לוח הזמנים להוצאה משימוש של FID מתוארים התאריכים שבהם אפשר לדעת כדי להבטיח שהמעבר מ-FID יהיה מלא.
ציר הזמן להוצאה משימוש של FID
עכשיו, אחרי שמדד INP החליף את FID כמדד ליבה לבדיקת חוויית המשתמש באתר, התמיכה ב-FID תופסק באופן רשמי ב-Chrome. המשמעות היא שהכלים של Chrome לא יבטיחו יותר את זמינות FID, והמפתחים יוכלו לעבור ל-INP עד 9 בספטמבר 2024.
האפשרות הזו חשובה במיוחד לצרכנים של ממשקי ה-API של דוח חוויית המשתמש ב-Chrome (CrUX) או של PageSpeed Insights. כדי למנוע תקלות או שיבושים בשירות, אפליקציות שמעבדות נתוני FID מאחד מממשקי ה-API האלה צריכות לעבור ל-INP עד 9 בספטמבר. לשם הבהרה, מדובר בשינוי תוכנה שעלול לגרום לכשל בגרסאות האחרונות של ממשקי ה-API, ולא תהיה עלייה במספרי הגרסאות העיקריות!
משאבים לאופטימיזציה של INP
לא משנה אם זו הפעם הראשונה שאתם בודקים את INP או שאתם מומחים לתגובה מהירה – אוסף מקורות המידע לאופטימיזציה של INP הוא נקודת התחלה מצוינת למציאת מה שאתם מחפשים. אוסף המסמכים תמיד רלוונטי, החל מהגדרת המדד עצמו, טכניקות למדידה מקומית ועם משתמשים אמיתיים, עצות מעשיות לאופטימיזציה של מגוון תרחישים לדוגמה ורשימה של מקרים לדוגמה מהעולם האמיתי שמראים את ההנחיות בפעולה.
במסמכים הבאים תמצאו הסבר כללי על תהליך העבודה הכללי שאפשר להיעזר בו כדי למצוא ולתקן בעיות INP באתר:
במסמכי ה-INP הקנוניים (רשמיים), חשוב לקרוא איך INP מודד את הרספונסיביות לאינטראקציות של משתמשים.
בוחנים נתונים ממשתמשים אמיתיים כדי להעריך את ביצועי ה-INP של האתר. לפחות 75% מחוויות ה-INP צריכות להגיב לקלט של משתמשים בתוך פחות מ-200 אלפיות השנייה כדי להיחשב כאיכותיות. אם לאתר כבר יש INP טוב, לא צריך לזכור אותו!
מחברים את כתובת ה-URL ל-PageSpeed Insights או בודקים את דוח מדדי הליבה לבדיקת חוויית המשתמש באתר ב-Search Console, אם האתר שלכם נכלל במערך הנתונים של CrUX.
מומלץ לברר עם ספק ניתוח הנתונים אם הוא תומך במעקב אחר INP.
מנסחים פתרון INP משלכם באמצעות web-vitals.js.
במקרה הצורך, אפשר להגדיר שהאתר יאסוף מידע אבחון לגבי חוויות המשתמש. אלו מטא-נתונים חשובים, כמו הרכיב בדף שאיתו המשתמש ביצע אינטראקציה והסיבה לכך שהוא היה איטי, וגם נתונים שימושיים נוספים. במצטבר, המידע הזה יעזור לכם להבין מהן ההזדמנויות המשמעותיות ביותר לשיפור.
לשחזר את האינטראקציות האיטיות באופן מקומי באמצעות כלי הפיתוח ל-Chrome. פעולה זו תעזור לך לראות בדיוק מה קורה מאחורי הקלעים ומהו הקוד הפוגעני.
ביצוע אופטימיזציה של הקוד כדי לצמצם ככל האפשר את הטיפול באינטראקציה של המשתמש:
כדאי למדוד את השינויים באופן מקומי ולעקוב אחרי חוויות המשתמשים האמיתיים כדי לוודא שביצועי ה-INP מתקדמים (ונשארים!).
אני מקווה שההנחיות האלה יעזרו לכם לבצע אופטימיזציה של INP. אם תיתקלו בבעיות בדרך, תמיד תוכלו לקבל עזרה על ידי פרסום שאלה שמתויגת ב-interaction-to-next-paint ב-Stack Overflow.
כבר זמן רב השקנו את INP כמדד ליבה לבדיקת חוויית המשתמש באתר, כמו הפוסט הראשון שלנו בנושא יצירת מדד רספונסיבי טוב יותר בשנת 2021. מאז, לקחנו בחשבון את כל המשוב המדהים מהקהילה ופיתחנו מדד שלדעתנו ינחה את המפתחים לשפר תחום של חוויות משתמש שלא מקבלים שירות, ובסופו של דבר – לשפר את האינטרנט. תודה על העזרה בעיצוב המדד הזה ועל כל המאמצים שהשקעת כדי לשפר את מהירות התגובה.