הדגשנו את Microsoft Clarity כמוצר שנבנה תוך מחשבה על מקרי שימוש מעשיים מהעולם האמיתי, על ידי אנשי מוצר אמיתיים שמבינים את האתגרים העומדים בפני חברות כמו Switas. תכונות כמו קליקים של זעם ומעקב אחר שגיאות ב-JavaScript הוכיחו את עצמן כבעלות ערך רב בזיהוי תסכולים ובעיות טכניות של משתמשים, מה שאפשר שיפורים ממוקדים שהשפיעו ישירות על חוויית המשתמש ועל שיעורי ההמרה.
אינטראקציה עם הצבע הבא (INP)
מדד "אינטראקציה לצביעה הבאה" מודד את המהירות שבה דף מגיב ויזואלית לקלט מהמשתמש, ומדווח על ערך המייצג את זמני השהיית האינטראקציה הגרועים ביותר שחוו במהלך ביקור. הוא החליף את "עיכוב הקלט הראשון" כמדד תגובה של Core Web Vitals במרץ 2024, והשינוי היה משמעותי: בעוד שהמדד הישן יותר לכד רק את העיכוב לפני תחילת העיבוד באינטראקציה הראשונה, המדד הזה מודד את משך הזמן המלא מהקלט דרך העיבוד ועד לפריים הבא שצויר, על פני כל האינטראקציות בסשן.
ההבדל הזה חשוב משום שהמדד הקודם החמיא לאתרים רבים. דף יכול היה לרשום עיכוב מצוין של קלט ראשון תוך כדי שהוא נשאר איטי לכל אורכו, משום שהמדד התעלם מזמן הפעולה שלקח ל-event handler ולמשך הזמן שלקח לדפדפן לעבד את התוצאה, ומכיוון שהוא בחן רק אינטראקציה אחת. אתרים שנראו רספונסיביים תחת המדד הישן לעתים קרובות לא עושים זאת תחת המדד החדש, במיוחד יישומים של עמוד בודד וכל ממשק עם לוגיקה כבדה בצד הלקוח.
הערך המדווח נגזר מהאינטראקציות הארוכות ביותר שנצפו, עם התחשבות בתופעות חריגות בדפים עם אינטראקציות רבות, וסף הפעולה שפורסם על ידי גוגל מתייחס ל-200 מילישניות או פחות כאל תוצאות טובות באחוזון ה-75 של חוויות משתמש אמיתיות. מכיוון שהוא לוכד את כל המסלול מהקלט ועד לצביעה, ציונים גרועים יכולים לנבוע מכמה נקודות: משימות ארוכות בשרשור הראשי החוסמות את הדפדפן מלטפל באירוע, מטפלי אירועים שעושים עבודה מוגזמת באופן סינכרוני, פגיעה בפריסה הנגרמת מסגנונות קריאה וכתיבה בצורה משולבת, ורינדור יקר לאחר שינויי מצב.
אבחון בדרך כלל מצביע על ביצוע JavaScript ולא על תנאי רשת, מה שמבדיל מדד זה ממדדי טעינה. סיבות נפוצות כוללות חבילות מונוליטיות גדולות הפועלות על ה-thread הראשי, סקריפטים של צד שלישי המריצים עבודה שרירותית במהלך אינטראקציה, עיבודים מחדש של frameworks שנוגעים בהרבה יותר מהעץ ממה שהשינוי דורש, ומטפלים המבצעים חישוב סינכרוני שעלול להידחות או להזיז מה-thread הראשי. משימות ארוכות הן המנגנון הבסיסי ברוב המקרים, מכיוון שהדפדפן אינו יכול להגיב לקלט בזמן שמשימה פועלת.
תיקון מתבצע לאחר האבחון. פיצול משימות ארוכות לחלקים קטנים יותר עם ייתוק מפורש מאפשר לדפדפן לטפל בקלט ביניהן. דחיית עבודה לא חיונית עד לאחר העדכון החזותי, כך שהמשתמש יראה תגובה באופן מיידי, מטפלת בדפוס הנפוץ ביותר. צמצום כמות ה-JavaScript הנשלח, ביקורת סקריפטים של צד שלישי לאיתור עלות הליך משנה, וירטואליזציה של רשימות ארוכות והעברת חישובים כבדים ל-worker - כל אחד מהם מטפל בגורמים ספציפיים. מתן משוב חזותי מיידי עבור פעולות איטיות אינו משפר את הערך הנמדד, אך משנה את האופן שבו העיכוב נחווה.
סקריפטים של צד שלישי ראויים לבדיקה מיוחדת משום שהם מהווים גורם תכוף ונמצאים מחוץ לשליטתו הישירה של הצוות. ווידג'טים של צ'אט, מנהלי הסכמה, ספריות ניתוח, כלי התאמה אישית וסקריפטים של פרסום, כולם פועלים על השרשור הראשי ויכולים לתפוס אותו בדיוק ברגעים שבהם מבקר מנסה לקיים אינטראקציה. ביקורת על עלות השרשור הראשי של כל צד שלישי, באופן אידיאלי על ידי מדידת הדף עם ובלעדיו, מייצרת רשימה קונקרטית של מה כל ספק עולה מבחינת רספונסיביות. נתון זה הופך את הפשרה לדיון עם הצוותים שביקשו כל כלי, שהיא בדרך כלל דרך פרודוקטיבית יותר מאשר ניסיון לייעל את קוד האפליקציה סביב סקריפט שצורך את רוב התקציב הזמין.
מכיוון שהמדד מונע על ידי קוד האפליקציה ולא על ידי אספקת נכסים, שיפורו דורש בדרך כלל עבודת הנדסה ולא תצורה. בפועל, הוא נמצא על הגבול בין ביצועי אינטרנט ו פיתוח מוצר, וזה משמעותי במיוחד עבור ממשקי מסחר והזמנות אינטראקטיביים, שבהם סינון, תצורה ואינטראקציות של עגלת קניות לא מגיבות יוצרות נטישה שמופיעה בניתוחים כנשירה רגילה ללא סיבה ברורה.
סוויטאס כפי שנראה ב
