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