תוכלו להבין איך מדד INP החדש משפיע על החוויה באתרים שנוצרו באמצעות ספריות ומסגרות JavaScript.
לאחרונה הושק מדד רספונסיביות חדש וניסיוני ב-Chrome בדוח חוויית המשתמש ב-Chrome. המדד הזה, שידוע עכשיו גם בשם אינטראקציה עד השלב הבא (INP), מודד את רמת התגובה הכוללת לאינטראקציות של משתמשים בדף. היום אנחנו רוצים לשתף תובנות לגבי המיקום של אתרים שנוצרו באמצעות מסגרות JavaScript מודרניות ביחס למדד הזה. אנחנו רוצים להסביר למה INP רלוונטי למסגרות ואיך Aurora ו-frameworks פועלות כדי לשפר את הרספונסיביות.
רקע
דפדפן Chrome משתמש בעיכוב קלט ראשון (FID) כחלק ממדדי הליבה לבדיקת חוויית המשתמש באתר (CWV) כדי למדוד את מהירות התגובה של הטעינה באתרים. FID מודד את זמן ההמתנה מהאינטראקציה הראשונה של המשתמש ועד לרגע שבו הדפדפן יכול לעבד את הגורמים המטפלים באירועים שמחוברים לאינטראקציה. הוא לא כולל את הזמן לעיבוד של הגורמים המטפלים באירועים, לעיבוד האינטראקציות הבאות באותו הדף או לצביעה של הפריים הבא אחרי הרצת הקריאות החוזרות של האירוע. עם זאת, הרספונסיביות היא קריטית לחוויית המשתמש לאורך מחזור החיים של הדף, כי משתמשים מבלים כ-90% מהזמן בדף לאחר שהוא נטען.
המדד INP מודד את הזמן שלוקח לדף אינטרנט להגיב לאינטראקציות של משתמש מהרגע שבו המשתמש מתחיל את האינטראקציה ועד לרגע שהפריים הבא מוצג על המסך. באמצעות INP, אנחנו מקווים להפעיל מדד מצטבר לגבי זמן האחזור הנתפס של כל האינטראקציות במחזור החיים של הדף. אנחנו מאמינים ש-INP יספק הערכה מדויקת יותר לגבי דפי אינטרנט טעינה ומהירות תגובה של סביבת זמן ריצה.
מכיוון ש-FID מודד רק את עיכוב הקלט של האינטראקציה הראשונה, סביר להניח שמפתחי אתרים לא ביצעו באופן יזום אופטימיזציה של האינטראקציות הבאות כחלק מתהליך שיפור CWV. לכן, אתרים, בייחוד אתרים שבהם יש הרבה אינטראקטיביות, יצטרכו להשקיע מאמצים רבים כדי להשיג תוצאות טובות במדד הזה.
התפקיד של frameworks
הרבה אתרים מסתמכים על JavaScript כדי לספק אינטראקטיביות, ולכן ציון ה-INP יושפע בעיקר מכמות ה-JavaScript שמעובדת ב-thread הראשי. JavaScript frameworks הן חלק חיוני בפיתוח אתרים מודרני בממשק הקצה, ומספקות למפתחים הפשטות חשובות לגבי ניתוב, טיפול באירועים ומחלוקת קוד JavaScript. לכן, יש להן תפקיד מרכזי באופטימיזציה של הרספונסיביות ושל חוויית המשתמש באתרים שמשתמשים בהן.
יכול להיות ש-Frames נקטו פעולות לשיפור הרספונסיביות על ידי שיפור FID באתרים קודם. עם זאת, הם יצטרכו לנתח את הנתונים של מדדי הרספונסיביות הזמינים ולטפל בפערים שזוהו. באופן כללי, ל-INP יש בדרך כלל שיעורי מסירה נמוכים יותר, וההבדל בתהליך המדידה דורש אופטימיזציה נוספת של הקוד. הטבלה הבאה מסכמת את הסיבה לכך.
צוות Aurora ב-Chrome עובד עם מסגרות אינטרנט של קוד פתוח כדי לעזור למפתחים לשפר היבטים שונים של חוויית המשתמש, כולל ביצועים ומדדים של CWV. עם השקת ה-INP, אנחנו רוצים להיות מוכנים לשינוי במדדים של CWV באתרים מבוססי-framework. אספנו נתונים על סמך מדד הרספונסיביות הניסיונית בדוחות CrUX. אנחנו נשתף תובנות ופעולות לביצוע כדי להקל על המעבר למדד INP באתרים שמבוססים על framework.
נתונים ניסיוניים של מדדי רספונסיביות
ערך INP שווה ל-200 אלפיות שנייה או פחות מציין תגובה טובה. הנתונים בדוח CrUX ודוח הטכנולוגיה של CWV לחודש יוני 2023 מספקים את המידע הבא לגבי רספונסיביות למסגרות JavaScript פופולריות.
בטבלה מוצג אחוז המקורות בכל מסגרת עם ציון תגובה טוב. הנתונים מעודדים, אבל הם מציינים שיש מקום לשיפור רב.
איך JavaScript משפיע על INP?
ערכי INP בשדה תואמים היטב לזמן החסימה הכולל (TBT) שנצפה בשיעור ה-Lab. המשמעות היא שכל סקריפט שחוסם את ה-thread הראשי למשך זמן רב עלול לפגוע ב-INP. הפעלה מוגזמת של JavaScript לאחר כל אינטראקציה עלולה לחסום את ה-thread הראשי למשך זמן רב ולעכב את התגובה לאינטראקציה הזו. הנה כמה מהסיבות הנפוצות לחסימת סקריפטים:
JavaScript לא מותאם: קוד עודף או אסטרטגיות טעינה ופיצול קוד לא טובות, עלולים לגרום לניפוח של JavaScript ולחסום את ה-thread הראשי למשך פרקי זמן ארוכים. פיצול קוד, טעינה הדרגתית ופיצול של משימות ארוכות יכולים לשפר משמעותית את זמני התגובה.
סקריפטים של צד שלישי: סקריפטים של צד שלישי, שלפעמים לא נדרשים לעיבוד אינטראקציה (למשל, סקריפטים של מודעות), יכולים לחסום את ה-thread הראשי ולגרום לעיכובים מיותרים. ניתן לתת עדיפות לסקריפטים חיוניים כדי לצמצם את ההשפעה השלילית של סקריפטים של צד שלישי.
גורמים מטפלים באירועים מרובים: מספר גורמים מטפלים באירועים שמשויכים לכל אינטראקציה, כאשר כל אחד מהם מפעיל סקריפט שונה, עלולים להפריע זה לזה ולגרום לעיכובים ארוכים. יכול להיות שחלק מהמשימות האלה לא חיוניות, ואפשר לתזמן אותן מול Worker אינטרנט או כשהדפדפן לא פעיל.
תקורת מסגרת בטיפול באירועים: מסגרות עשויות לכלול תכונות או תחביר נוספים לטיפול באירועים. לדוגמה, Vue משתמש ב-v-on כדי לצרף פונקציות event listener לרכיבים, ואילו Angular כולל handlers של אירועים של משתמשים. כדי להטמיע את התכונות האלה, נדרש קוד framework נוסף מעל JavaScript וניל.
הידרציה: כשמשתמשים ב-framework של JavaScript, לעיתים קרובות השרת יוצר את ה-HTML הראשוני של דף, שאותו צריך לשפר באמצעות גורמים מטפלים באירועים ומצב אפליקציות, כדי שהוא יוכל להיות אינטראקטיבי בדפדפן אינטרנט. אנחנו מכנים את התהליך הזה 'התייבשות'. התהליך הזה עשוי להיות תהליך כבד במהלך הטעינה, בהתאם לזמן הטעינה של JavaScript ולסיום טעינת ה-JavaScript. הדבר יכול גם להוביל לדפים שנראים כאילו הם אינטראקטיביים, כשהם אינם אינטראקטיביים. בדרך כלל מאזן הנוזלים מתרחש באופן אוטומטי במהלך טעינת הדף או באופן מדורג (לדוגמה, באינטראקציה של המשתמש), ועשוי להשפיע על ה-INP או על זמן העיבוד עקב תזמון המשימה. בספריות כמו React, אפשר להשתמש ב-
useTransitionכך שחלק מרינדור של רכיב יופיע בפריים הבא, ותופעות לוואי יקרות יותר יישארו בפריימים עתידיים. לאור זאת, עדכונים במעבר שנובעים מעדכונים דחופים יותר, כמו קליקים, יכולים להתאים ל-INP.שליפה מראש (prefetch): שליפה מראש אגרסיבית של המשאבים שנדרשים לניווטים הבאים יכולה להוביל לשיפור בביצועים אם תבצעו את הפעולה בצורה נכונה. עם זאת, אם תבצעו שליפה מראש (prefetch) ועיבוד של מסלולי SPA באופן סינכרוני, יכול להיות שזה ישפיע לרעה על ה-INP, כי כל הרינדור היקר הזה יתבצע במסגרת אחת. לעומת זאת, לא צריך לאחזר מראש את המסלול, ובמקום זאת להתחיל את העבודה הדרושה (לדוגמה,
fetch()) ולבטל את החסימה של צבע. מומלץ לבדוק מחדש אם הגישה של ה-framework לאחזור מראש מספקת את חוויית המשתמש האופטימלית ואיך (אם בכלל) זה משפיע על INP.
מעכשיו, כדי לקבל ציון INP טוב, המפתחים יצטרכו להתמקד בבדיקת הקוד שמופעל אחרי כל אינטראקציה בדף ולבצע אופטימיזציה של החלוקה למקטעים, ההתייבשות, אסטרטגיות הטעינה והגודל של כל עדכון Rep() עבור סקריפטים של צד ראשון ושל צד שלישי,
איך Aurora ו-frameworks מטפלות בבעיות INP?
אורורה עובדת עם frameworks על ידי שילוב שיטות מומלצות שמספקות פתרונות מובנים לבעיות נפוצות. עבדנו עם Next.js, Nuxt.js, Gatsby ו-Agular על פתרונות שמציעים ברירות מחדל מוצקות בתוך המסגרת כדי לבצע אופטימיזציה של הביצועים. אלו עיקרי העבודה שלנו בהקשר הזה:
React ו-Next.js: רכיב הסקריפט Next.js עוזר לטפל בבעיות שנגרמות עקב טעינה לא יעילה של סקריפטים של צד שלישי. הוספנו ל-Next.js חלוקה מפורטת של נתונים כדי לאפשר שימוש במקטעי נתונים קטנים יותר בקוד משותף. כך אפשר לצמצם את כמות הקוד המשותף שאינו בשימוש, שמורד לכל הדפים. אנחנו גם עובדים עם Next.js כדי שנתוני INP יהיו זמינים כחלק משירות Analytics שלהם.
אנגלר: חברת Aurora פועלת בשיתוף עם צוות Angular כדי לבחון שיפורים בעיבוד בצד השרת ובשתייה. אנחנו מתכננים גם לבחון שיפורים בטיפול באירועים ובזיהוי שינויים כדי לשפר את INP.
Vue ו-Next.js: אנחנו בוחנים דרכים לשיתוף פעולה, בעיקר בכל מה שקשור לטעינה ולרינדור של סקריפטים.
מה דעתך על frameworks לשיפור של INP?
תגובה ו-Next.js
פילוח הזמן של React.js, שמוטמע באמצעות startTransition ו-Suspense, מאפשר להביע הסכמה לתיבול סלקטיבי או הדרגתי. המשמעות היא ששתיית מים היא לא בלוק סינכרוני. היא מיוצרת בפרוסות קטנות שאפשר להפריע להן בכל שלב.
כך תוכלו לשפר את ה-INP ולהגיב מהר יותר להקשות על המקשים, לאפקטים של העברת העכבר במהלך המעבר ולקליקים. הוא גם עוזר שאפליקציות React יהיו רספונסיביות גם במעברים גדולים כמו השלמה אוטומטית.
Next.js יישם מסגרת ניתוב חדשה שמשתמשת ב-startTransition כברירת מחדל למעברי מסלולים. כך בעלי האתרים ב-Next.js יכולים לפרוס את חיתוך הזמן ב-React ולשפר את הרספונסיביות למעבר בין נתיבים.
Angular
הצוות של Angular בודק כמה רעיונות שיכולים לעזור גם ב-INP:
- ללא אזור: צמצום גודל החבילה הראשוני והקוד הנדרש שצריך להיטען כדי שהאפליקציה תוכל לעבד פריט כלשהו.
- התייבשות: שתייה בסגנון איים שמגבילה את כמות המים שהאפליקציה צריכה להתעורר לצורך אינטראקציה.
- הפחתת התקורה של CD: לדוגמה, אפשר להפחית את עלות זיהוי השינויים, למצוא דרכים לבדוק פחות תוכן של האפליקציה ולהשתמש באותות תגובתיים לגבי השינויים.
- חלוקת קוד מפורטת יותר: הקטנה של החבילה הראשונית.
- תמיכה משופרת במחווני טעינה: לדוגמה, במהלך עיבוד מחדש של SSR, במהלך ניווט במסלול ובפעולות טעינה מדורגת.
- כלים ליצירת פרופילים: כלי פיתוח טובים יותר להבנת העלות של אינטראקציות, במיוחד בנושא עלות זיהוי השינויים של אינטראקציות ספציפיות.
בעזרת השיפורים האלה אנחנו יכולים לטפל בבעיות שונות שמובילות לתגובה נמוכה ולחוויית משתמש גרועה, ולשפר את מדדי CWV ואת מדד INP החדש באתרים שמבוססים על framework.
סיכום
אנחנו צופים שציון INP יספק מצפן טוב יותר לאתרים לשיפור הרספונסיביות והביצועים בעתיד. אנחנו נתבסס על מדריך ה-INP הקיים כדי לספק עוד טיפים פרקטיים למפתחי framework ב-2023. אנחנו מקווים לעשות זאת באמצעות:
- יצירת ערוצים לגישה נוחה לנתוני שדות ב-INP ל-frameworks ולמפתחי אתרים.
- כדאי לעבוד עם frameworks כדי לפתח תכונות שישפרו את ה-INP כברירת מחדל.
אנחנו מקבלים משוב ממשתמשי framework כשהם מתחילים את תהליך האופטימיזציה של INP.