מהם הביצועים של מסגרות מודרניות במדד INP החדש

איך המדד החדש של INP משפיע על חוויית השימוש באתרים שנוצרו באמצעות מסגרות וספריות של JavaScript

Leena Sohoni

Addy Osmani

Keen Yee Liau

לאחרונה הוספנו ל-Chrome מדד תגובה ניסיוני חדש בדוח חוויית המשתמש ב-Chrome. המדד הזה, שנקרא עכשיו מהירות התגובה לאינטראקציה באתר (INP), מודד את רמת הרספונסיביות הכוללת לאינטראקציות של משתמשים בדף. היום אנחנו רוצים לשתף תובנות לגבי המיקום של אתרים שנוצרו באמצעות מסגרות JavaScript מודרניות ביחס למדד הזה. אנחנו רוצים להסביר למה INP רלוונטי למסגרות, ואיך Aurora והמסגרות פועלות כדי לבצע אופטימיזציה של תגובה מהירה.

רקע

Chrome משתמש במדד 'מהירות התגובה לאינטראקציה ראשונה' (FID) כחלק מהמדדים הבסיסיים של חוויית המשתמש באתר (CWV) כדי למדוד את הרספונסיביות של טעינת האתרים. ה-FID מודד את זמן ההמתנה מהאינטראקציה הראשונה של המשתמש עד לרגע שבו הדפדפן יכול לעבד את פונקציות הטיפול באירועים שמקושרות לאינטראקציה. הוא לא כולל את הזמן לעיבוד של פונקציות הטיפול באירועים, לעיבוד אינטראקציות עוקבות באותו דף או לציור של המסגרת הבאה אחרי שפונקציות ה-call back של האירועים פועלות. עם זאת, תגובה מהירה היא קריטית לחוויית המשתמש לאורך מחזור החיים של הדף, כי המשתמשים מבלים כ-90% מהזמן בדף אחרי שהוא נטען.

המדד INP מודד את הזמן שלוקח לדף אינטרנט להגיב לאינטראקציות של משתמשים, מהרגע שבו המשתמש מתחיל את האינטראקציה ועד לרגע שבו התמונה הבאה מוצגת במסך. בעזרת INP, אנחנו מקווים שנוכל לספק מדד מצטבר של זמן האחזור המשוער של כל האינטראקציות במחזור החיים של הדף. אנחנו מאמינים ש-INP יספק אומדן מדויק יותר של זמן הטעינה של דפי אינטרנט והתגובה שלהם בסביבת זמן הריצה.

מכיוון ש-FID מודד רק את עיכוב הקלט של האינטראקציה הראשונה, סביר להניח שמפתחי האתר לא ביצעו אופטימיזציה יזומה של האינטראקציות הבאות כחלק מתהליך השיפור של חוויית המשתמש בדפדפן. לכן, בעלי אתרים, במיוחד בעלי אתרים עם רמה גבוהה של אינטראקטיביות, יצטרכו להתחיל לעבוד קשה כדי לשפר את הביצועים שלהם במדד הזה.

התפקיד של המסגרות

מאחר שאתרים רבים מסתמכים על JavaScript כדי לספק אינטראקטיביות, הציון של INP יושפע בעיקר מכמות ה-JavaScript שמעובד ב-thread הראשי. מסגרות JavaScript הן חלק חיוני בפיתוח אינטרנט מודרני לקצה הקדמי, ומספקות למפתחים הפשטות חשובות לניתוב, לטיפול באירועים ולחלוקה למחיצות של קוד JavaScript. לכן, יש להם תפקיד מרכזי בשיפור הרספונסיביות וחוויית המשתמש של אתרים שמשתמשים בהם.

יכול להיות ש-frameworks נקטו פעולות לשיפור התגובה המהירה על ידי שיפור מדד FID לאתרים בשלב מוקדם יותר. עם זאת, עכשיו הם יצטרכו לנתח את נתוני מדדי המהירות בתגובה הזמינים ולעבוד על פתרון הפערים שזוהו. באופן כללי, ל-INP יש בדרך כלל שיעורי אישור נמוכים יותר, וההבדל בתהליך המדידה מחייב אופטימיזציה נוספת של הקוד. הסיבה לכך מפורטת בטבלה הבאה.

צוות Aurora ב-Chrome עובד עם מסגרות אינטרנט בקוד פתוח כדי לעזור למפתחים לשפר היבטים שונים של חוויית המשתמש, כולל מדדי הביצועים ו-CWV. עם ההשקה של INP, אנחנו רוצים להיות מוכנים לשינוי במדדי CWV באתרים שמבוססים על מסגרות. אספנו נתונים על סמך המדד הניסיוני של תגובה מהירה בדוחות CrUX. נשתף תובנות ופעולות שיעזרו לכם לעבור בקלות למדד INP באתרים שמבוססים על מסגרות.

נתוני מדד תגובה מהירה ניסיוני

ערך INP שנמוך מ-200 אלפיות השנייה או שווה לו מציין מהירות תגובה טובה. הנתונים מדוח CrUX ומדוח הטכנולוגיה של CWV ליוני 2023 מספקים לנו את המידע הבא על תאימות לתצוגה במסכים שונים של מסגרות JavaScript פופולריות.

בטבלה מוצג האחוז של מקורות בכל מסגרת עם ציון תגובה מהיר טוב. המספרים מעודדים, אבל הם מראים לנו שיש הרבה מקום לשיפור.

איך JavaScript משפיע על INP?

הערכים של INP בשדה תואמים היטב לזמן החסימה הכולל (TBT) שנצפה במעבדה. המשמעות היא שכל סקריפט שחוסם את ה-thread הראשי למשך זמן רב יפגע ב-INP. ביצוע JavaScript מוגזם אחרי כל אינטראקציה עלול לחסום את השרשור הראשי למשך זמן ממושך ולהשהות את התגובה לאינטראקציה הזו. בין הסיבות הנפוצות לחסימת סקריפטים:

• JavaScript ללא אופטימיזציה: קוד מיותר או אסטרטגיות טעינה ופיצול קוד גרועות עלולות לגרום לקוד JavaScript להיות מיותר ולחסום את הליבה למשך תקופות ארוכות. חלוקת קוד, טעינה פרוגרסיבית ופירוט משימות ארוכות יכולים לשפר את זמני התגובה באופן משמעותי.

• סקריפטים של צד שלישי: סקריפטים של צד שלישי, שלפעמים לא נדרשים לעיבוד אינטראקציה (לדוגמה, סקריפטים של מודעות), עלולים לחסום את השרשור הראשי ולגרום לעיכובים מיותרים. הקצאת עדיפות לסקריפטים חיוניים יכולה לעזור לצמצם את ההשפעה השלילית של סקריפטים של צד שלישי.

• מספר עצירות אירוע: מספר עצירות אירוע שמשויכות לכל אינטראקציה, שכל אחת מהן מפעילה סקריפט אחר, עלולות להפריע זו לזו ולגרום לעיכובים ארוכים. יכול להיות שחלק מהמשימות האלה לא חיוניות, ואפשר לתזמן אותן ב-web worker או כשהדפדפן לא פעיל.

• העלות הנוספת של המסגרת לטיפול באירועים: יכול להיות שלמסגרות יש תכונות או תחביר נוספים לטיפול באירועים. לדוגמה, ב-Vue נעשה שימוש ב-v-on כדי לצרף מאזינים לאירועים לרכיבים, ואילו ב-Angular נעשה שימוש ב-wrap של פונקציות לטיפול באירועים של משתמשים. כדי להטמיע את התכונות האלה, צריך להוסיף קוד מסגרת בנוסף ל-JavaScript רגיל.

• הוספת נתונים: כשמשתמשים במסגרת JavaScript, לא נדיר שהשרת יוצר את ה-HTML הראשוני של דף, ולאחר מכן צריך להוסיף לו פונקציות לטיפול באירועים ומצב האפליקציה כדי שיהיה אינטראקטיבי בדפדפן אינטרנט. אנחנו קוראים לתהליך הזה 'הוספת מים'. זה יכול להיות תהליך כבד במהלך הטעינה, בהתאם למשך הזמן שלוקח ל-JavaScript להיטען ולתהליך ההידרציה להסתיים. היא גם עלולה לגרום לכך שדפים ייראו אינטראקטיביים גם אם הם לא. לעיתים קרובות, ההידרציה מתרחשת באופן אוטומטי במהלך טעינת הדף או באופן עצל (למשל, כתוצאה מאינטראקציה של משתמש), והיא יכולה להשפיע על זמן ה-INP או על זמן העיבוד בגלל תזמון המשימות. בספריות כמו React, אפשר להשתמש ב-useTransition כדי שחלק מהעיבוד של רכיב יופיע בפריים הבא, וכל תופעות לוואי יקרות יותר יועברו לפריימים עתידיים. לכן, עדכונים במעבר שמובילים לעדכונים דחופים יותר, כמו קליקים, יכולים להיות דפוס טוב ל-INP.

• אחזור מקדים: אחזור מקדים אגרסיבי של המשאבים הנדרשים לניווטים הבאים יכול לשפר את הביצועים אם מבצעים אותו בצורה נכונה. עם זאת, אם מבצעים טעינה מראש של מסלולי SPA ורינדור שלהם באופן סינכרוני, יכול להיות שתהיה לכך השפעה שלילית על INP, כי כל תהליך הרינדור היקר הזה מנסה להסתיים בפריים אחד. לעומת זאת, אם לא מבצעים אחסון מראש של המסלול, מתחילים את העבודה הנדרשת (לדוגמה, fetch()) ומבטלים את החסימה של הצביעה. מומלץ לבדוק מחדש אם הגישה של המסגרת שלכם לאחזור מראש מספקת את חוויית המשתמש האופטימלית, ואיך היא עשויה להשפיע על INP (אם בכלל).

מעכשיו, כדי לקבל ציון INP טוב, המפתחים יצטרכו להתמקד בבדיקת הקוד שמופעל אחרי כל אינטראקציה בדף ולבצע אופטימיזציה של אסטרטגיות הטעינה, הקצאת המקטעים, ההחזרה לחיים והגודל של כל עדכון של render() גם בסקריפטים של צד ראשון וגם בסקריפטים של צד שלישי.

איך Aurora והמסגרות מטפלות בבעיות INP?

Aurora עובדת עם מסגרות על ידי שילוב של שיטות מומלצות כדי לספק פתרונות מובנים לבעיות נפוצות. עבדנו עם Next.js,‏ Nuxt.js,‏ Gatsby ו-Angular על פתרונות שמציעים הגדרות ברירת מחדל חזקות בתוך המסגרת כדי לבצע אופטימיזציה של הביצועים. בהמשך מפורטים הדברים העיקריים שעשינו בהקשר הזה:

• React ו-Next.js: רכיב הסקריפט של Next.js עוזר לטפל בבעיות שנגרמות בגלל טעינה לא יעילה של סקריפטים של צד שלישי. חלוקה לקטעים מפורטים הוצגה ב-Next.js כדי לאפשר חלוקה לקטעים קטנים יותר של קוד משותף. כך ניתן לצמצם את כמות הקוד המשותף שלא בשימוש שמוריד בכל הדפים. אנחנו עובדים גם עם Next.js כדי להפוך את נתוני ה-INP לזמינים כחלק משירות Analytics שלהם.

• Angular: צוות Aurora שותף עם צוות Angular כדי לבחון שיפורים ברינדור ובהידרציה בצד השרת. אנחנו גם מתכננים לבדוק שיפורים בטיפול באירועים ובזיהוי שינויים כדי לשפר את INP.

• Vue ו-Nuxt.js: אנחנו בודקים אפשרויות לשיתוף פעולה, בעיקר בנוגע לטעינה ולעיבוד של סקריפטים.

איך ה-frameworks חושבים לשפר את INP?

React ו-Next.js

חלוקת הזמן ב-React.js, שמוטמעת באמצעות startTransition ו-Suspense, מאפשרת לכם להביע הסכמה להידור (hydration) סלקטיבי או הדרגתי. המשמעות היא שההוספה לא היא חסימה סינכרונית. התהליך מתבצע בחלקים קטנים שאפשר להפסיק בכל שלב.

כך תוכלו להגיב מהר יותר למקשות, לאפקטים של עכבר במעבר ולקליקים. הוא גם עוזר לשמור על תגובה מהירה של אפליקציות React גם במעברים גדולים, כמו מילוי אוטומטי.

ב-Next.js הוטמעה מסגרת ניתוב חדשה שמשתמשת ב-startTransition כברירת מחדל למעברים בין נתיבים. כך בעלי אתרים ב-Next.js יכולים להשתמש בחלוקת זמן ב-React ולשפר את הרספונסיביות של מעברי מסלולים.

Angular

צוות Angular בוחן כמה רעיונות שיכולים לעזור גם בנושא INP:

• ללא תחום: צמצום גודל החבילה הראשונית והקוד הנדרש שצריך לטעון לפני שאפליקציה יכולה ליצור עיבוד (רנדור) של משהו.
• הידרציה: הידרציה מסוג איים כדי להגביל את החלק באפליקציה שצריך להעיר כדי לבצע אינטראקציה.
• צמצום התקורה של תהליך עיבוד הנתונים: לדוגמה, הפחתת העלות של זיהוי השינויים, חיפוש דרכים לבדוק פחות חלקים באפליקציה וניצול אותות תגובה לגבי מה שהשתנה.
• פיצול קוד מפורט יותר: הקטנת החבילה הראשונית.
• תמיכה טובה יותר באינדיקטורים של טעינה: לדוגמה, במהלך עיבוד מחדש של SSR, במהלך ניווט במסלול ובפעולות של טעינה איטית.
• כלים ליצירת פרופילים: כלים טובים יותר לפיתוח שמאפשרים להבין את עלות האינטראקציה, במיוחד בנוגע לעלות של זיהוי שינויים באינטראקציות ספציפיות.

בעזרת השיפורים האלה נוכל לטפל בבעיות שונות שגורמות לתגובה איטית ולחוויית משתמש גרועה, ולשפר את מדדי CWV ואת המדד החדש INP באתרים שמבוססים על מסגרות.

סיכום

אנחנו מצפים שציון INP יספק דרך טובה יותר לאתרים לשפר את המהירות והביצועים בעתיד. בשנת 2023 נרחיב את המדריך הקיים שלנו בנושא INP כדי לספק טיפים נוספים למפתחי מסגרות. כדי להשיג את המטרה הזו, אנחנו:

• יצירת ערוצים לגישה קלה לנתוני שדה ב-INP למפתחי מסגרות ולמפתחי אינטרנט.
• עבודה עם מסגרות כדי ליצור תכונות שישפרו את INP כברירת מחדל.

אנחנו מזמינים את המשתמשים במסגרת לשלוח לנו משוב כשהם מתחילים בתהליך האופטימיזציה של ה-INP.