בצוות Chrome, חוויית המשתמש חשובה לנו וסביבה עסקית משגשגת באינטרנט. אנחנו רוצים שהמשתמשים יהנו מהחוויה הטובה ביותר באינטרנט, לא רק במסמכים סטטיים אלא גם כשהם משתמשים באפליקציות עשירות ואינטראקטיביות.
כלים ומסגרות של קוד פתוח ממלאים תפקיד חשוב בכך שהם מאפשרים למפתחים לבנות אפליקציות מודרניות לאינטרנט, תוך תמיכה בחוויות פיתוח טובות. המסגרות והכלים האלה מעצימים חברות בכל הגדלים וגם אנשים פרטיים שבונים לאינטרנט.
אנחנו מאמינים של-frameworks יש גם תפקיד חשוב בסיוע למפתחים לגבי היבטים מרכזיים של איכות, כמו ביצועים, נגישות, אבטחה ומוכנות לניידים. במקום לבקש מכל מפתח ובעלי אתר להפוך למומחים בתחומים האלה ולהתעדכן בשיטות המומלצות שמשתנות כל הזמן, ה-framework יכול לתמוך בהם בעזרת פתרונות מוטמעים. זה מאפשר למפתחים להתמקד בפיתוח תכונות של מוצרים.
בקיצור, החזון שלנו הוא שרמת איכות גבוהה של חוויית המשתמש הופכת לתופעת לוואי של בניית אתרים.
הזוהר הצפוני (Aurora): שיתוף פעולה בין Chrome לבין מסגרות וכלים בקוד פתוח באינטרנט
במשך כמעט שנתיים עבדנו עם כמה מהמסגרות הפופולריות ביותר כמו Next.js, Nuxt ו-Angular, במטרה לשפר את ביצועי האינטרנט. מימנו גם ספריות וכלים פופולריים כמו Vue, ESLint ו-webpack. היום אנחנו נותנים למאמץ הזה שם - אורורה.
הזוהר הצפוני הוא מופע אור טבעי שמנצנץ בשמיים. מאחר שאנחנו מנסים לעזור לחוויות משתמש שנוצרות באמצעות frameworks, חשבנו שהשם הזה הוא בחירה מתאימה.
בחודשים הקרובים נשתף הרבה יותר פרטים על הזוהר הצפוני. זהו שיתוף פעולה בין צוות קטן של מהנדסי Chrome (WebSDK עם שם פנימי) ועם מחברי framework. המטרה שלנו היא לספק את חוויית המשתמש הטובה ביותר באפליקציות בסביבת הייצור, ללא קשר לדפדפן שבו אתם מריצים.
מהי האסטרטגיה שלנו?
ב-Google למדנו הרבה במהלך השימוש במסגרות ובכלים כדי ליצור ולתחזק אפליקציות אינטרנט בקנה מידה גדול כמו חיפוש Google, מפות Google, חיפוש תמונות, Google Photos וכו'. גילינו ש-frameworks ממלא תפקיד חיוני באיכות האפליקציות הצפויות על ידי אספקת הגדרות ברירת מחדל מתקדמות וכלים ספציפיים.
למסגרות יש נקודת תצפית ייחודית על מנת להשפיע גם על DX וגם על חוויית המשתמש, מכיוון שהן מתפרשות על המערכת כולה: הלקוח והשרת, סביבות הפיתוח והייצור, והן משלבות כלים כמו מהדר (compiler) ב-bundler ו-Linter וכו'.
כשהפתרונות מוטמעים בתוך המסגרת, צוותי המפתחים יכולים להשתמש בפתרונות האלה ולמקד את זמנם בדברים החשובים ביותר למוצר – להציע למשתמשים תכונות מעולות.
אנחנו עובדים על שיפור הכלים שנמצאים בכל שכבה בסטאק, אבל ב-frameworks כמו Next.js, Nuxt ו-Angular CLI, מנהלים כל שלב במחזור החיים של אפליקציה. מהסיבה הזו, בנוסף לעובדה שאימוץ React הוא השינוי המשמעותי ביותר בסביבה העסקית העיקרית של ממשק המשתמש, רוב האופטימיזציות שלנו התחילו עם הצגת תוכן ב-Next.js לפני ההרחבה לשאר הסביבה העסקית.
ה-Aurora תומכת בהצלחה בקנה מידה נרחב באמצעות שילוב הפתרונות השכבה הימנית של סטאק התוכנות הפופולרי. באמצעות גישור על הפער בין הדפדפנים והמסגרות, איכות תוכן גבוהה יכולה להיות תופעת לוואי של בניית אתרים, ובמקביל פועלת כלולאת משוב לשיפור פלטפורמת האינטרנט.
מהו תהליך העבודה שלנו?
העקרונות שלנו לאופן שבו אורורה מקשרת בין הדפדפנים לבין הסביבה העסקית של המפתחים הם: ענווה, סקרנות, חקירה מדעית ופרגמטיזם. אנחנו עובדים ביחד עם מחברי מסגרות על שיפורים, משתפים פעולה עם הקהילה ומבצעים את הבדיקות הדרושות לפני כל שינוי.
סיכום של השלבים שאנחנו נוקטים בכל תכונה חדשה שאנחנו עובדים עליה:
- זיהוי בעיות בחוויית המשתמש בסטאק פופולרי באמצעות אפליקציות מייצגות.
- פתרונות אב-טיפוס שעונים על בעיה זו, עם דגש על "ברירות מחדל חזקות" .
- צריך לאמת את התכונה באמצעות סטאק framework אחרת כדי לוודא שאפשר יהיה להתאים אותה.
- מאמתים את התכונה על ידי ניסויים בכמה אפליקציות ייצור, בדרך כלל עם בדיקת ביצועים בשיעור Lab.
- עיצוב Drive באמצעות תהליך RFC, תוך התייחסות למשוב מהקהילה.
- להציב את הישות במקבץ פופולרי, בדרך כלל מאחורי דגל.
- כדאי להפעיל את התכונה באפליקציית ייצור מייצגת כדי להעריך את האיכות ואת השילוב של תהליך העבודה למפתחים.
- אפשר למדוד את השיפור בביצועים באמצעות מעקב אחרי מדדים באפליקציות מייצגות לסביבת הייצור משתמשות בתכונה או ששודרגו.
- כדאי להפעיל את התכונה כברירת המחדל בסטאק, כך שכל המשתמשים שמשדרגים מפיקים תועלת.
- לאחר האימות, עובדים עם frameworks נוספות כדי לבנות את התכונה.
- זהו פערים בפלטפורמת האינטרנט באמצעות לולאת משוב.
- מעבר לבעיות הבאות.
הכלים ויישומי הפלאגין שבבסיסם (webpack, Babel, ESLint, TypeScript וכו') משותפים ב-frameworks רבות. כך ניתן ליצור אפקטים של גלים, גם כשתורמים לסטאק אחד של framework.
בנוסף, Chrome Framework Fund תומך בספריות ובכלים של קוד פתוח, שיש בהם מימון. אנחנו מקווים שתהיה חפיפה מספקת בין הבעיות ושכבות הפתרונות שלנו למאמצים שהוזכרו למעלה כדי לתרגם למסגרות ולכלים אחרים, אבל אנחנו יודעים שאנחנו יכולים לעשות יותר. לשם כך, אנחנו רוצים לתרום את חלקנו כדי להבטיח שהספריות והמסגרות שיעזרו למפתחים לשגשג. זו אחת מהסיבות שנמשיך להשקיע בקרן Chrome Framework. עד כה, הוא תמך בעבודה עם Webpack 5, Nuxt וביצועים ושיפורים ב-ESLint.
מה פתחנו עד כה?
העבודה שלנו התמקדה באופטימיזציות בסיסיות של משאבים כמו תמונות, JS, CSS וגופנים. שלחנו מספר אופטימיזציות כדי לשפר את ברירות המחדל של מספר מסגרות, כולל:
- רכיב תמונה ב-Next.js שמפרט את השיטות המומלצות לטעינת תמונות, ואחריו מתבצע שיתוף פעולה עם Nuxt. השימוש ברכיב הזה הוביל לשיפורים משמעותיים בזמני הציור ובשינויים בפריסה (לדוגמה: הפחתה של 57% ב-LCP ב-LCP וירידה של 100% ב-Cumulative Layout Shift ב-nextjs.org/give).
- הטמעה אוטומטית של CSS להצהרות גופן אינטרנט בזמן ה-build. הפיצ'ר הזה הפך ל-Angular (Google Fonts) ול-Next.js ( Google Fonts ו-Adobe Fonts), וכתוצאה מכך נוספו שיפורים משמעותיים ל- Largest Contentful Paint (LCP) ול-First Contentful Paint (דוגמה).
- הטמעת CSS קריטי באמצעות Critters גם ב-Angular וגם ב-Next.js כדי לצמצם את זמני הצבע. התוצאה הייתה שיפור של 20-30 נקודות בציוני הביצועים של Lighthouse באפליקציה אופיינית בקנה מידה גדול של Angular, כששילבה את השילוב עם תכונה מוטמעת של CSS בגופן.
- תמיכה מותאמת אישית ב-ESLint ב-Next.js, שכוללת פלאגין מותאם אישית ותצורה שניתן לשתף, כדי להקל על איתור בעיות נפוצות שהן ספציפיות ל-framework בזמן ה-build, וכתוצאה מכך אפשר לחזות את ביצועי הטעינה.
- היכרות עם מסנן ביצועים מובנה ב-Create React App וב-Next.js כדי לאפשר תובנות קלות יותר לגבי ביצועי הדף באמצעות תפקוד האפליקציה ומדדים מותאמים אישית אחרים.
- צ'ונקינג פרטני שנשלח ב-Next.js וב-Gatsby, וכתוצאה מכך הגודל של החבילות קטן ב-30 עד 70 אחוזים, וגם משפר את הביצועים של השמירה במטמון. ההגדרה הזו הוגדרה כברירת המחדל ב-Webpack 5.
- מקטע Polyfill נפרד לדפדפנים ישנים יותר, בשיתוף עם צוות Next.js, כדי לשפר את גודל החבילה בדפדפנים מודרניים.
כל אחת מהתכונות האלה מופעלת כברירת מחדל באופן אוטומטי, או שנדרשת רק הצטרפות פשוטה. כדי שהמפתחים יוכלו לקצור את היתרונות שלהם בקלות, בלי להסתבך בתהליך העבודה.
מה אנחנו מתכננים ל-2021?
עד סוף השנה הנוכחית נתמקד במתן עזרה בסטאקים של framework כדי לשפר את חוויית המשתמש ואת רמת הביצועים שלהם במדדים כמו מדדי הליבה לבדיקת חוויית המשתמש באתר. העבודה תכלול:
- תאימות לאכיפת השיטות המומלצות. למידע נוסף, קראו את הפוסט בבלוג.
- לבצע אופטימיזציה של ביצועי הטעינה הראשונית על ידי הסתמכות על שיתופי הפעולה שלנו לצורך אופטימיזציה של תמונות, גופנים ו-CSS קריטי.
- טעינת סקריפטים של צד שלישי (3P) עם השפעה מינימלית על הביצועים, על ידי הסתמכות על הבסיס העבודה שלנו על רכיב סקריפט וביצוע מחקר מעמיק כדי להבין מהי הדרך הטובה ביותר לסדר ולרצף את הצד השלישי.
- ביצועי JavaScript בקנה מידה רחב (למשל, תמיכה ברכיבי React Server ב-Next.js).
הצוות שלנו ינסה לפרסם מידע קבוע יותר על RFC ומסמכי תכנון עבור הרעיונות האלה, כדי שכל מסגרת או מפתח שירצו להתקדם יוכלו לעשות זאת.
סיכום
צוות Aurora (Shubhie, Houssein, Alex, Gerald, Ralph, Addy, Kara, Keen, Katie, ימשיכו לעבוד בקרוב עם חוויית המשתמש הבאה ו- Nextsource. אנו נגדיל את המעורבות שלנו כדי לכסות עוד מסגרות וכלים עם הזמן. חפשו פוסטים בבלוג, שיחות ו-RFC נוספים מהצוות שלנו במהלך השנה הקרובה :)