אני פול קינלן, ואני אחראי על קשרי מפתחים ב-Chrome. במסגרת העבודה שלי, אני עובד עם צוות של מומחי אינטרנט נלהבים שתפקידם להביא את נקודת המבט של מפתחים בעולם האמיתי לצוותי המוצר וההנדסה שלנו, תוך שימוש במדד 'כוכב הצפון' לשיפור שביעות הרצון של המפתחים.
אנחנו מבינים ש'שביעות רצון' הוא מדד שאפתני וסובייקטיבי שאפשר לעקוב אחריו ולשפר אותו, ולכן אנחנו כל הזמן פועלים לשיפור האופן שבו אפשר להשפיע תוך התמקדות בצרכים של מפתחים. לפי העיקרון המנחה שלנו, אנחנו פועלים לפי העיקרון "הכירו מפתחים במקום שבו הם נמצאים". מחקר שנערך לאחרונה ב-Stack Overflow הראה ש-75% מהמפתחים מדווחים על שימוש ב-frameworks או בקיצור מסוג כלשהו. לכן שאלנו את עצמנו מהי הדרך הטובה ביותר לתת שירות למפתחים שכבר קיבלו החלטות בנוגע לסטאק התוכנות שלהם, או שאין להם שליטה עליו. איך נוכל לשפר את הפרודוקטיביות שלהם בלי להגדיל את התקורה?
צוות קטן ב-Chrome עובד על פרויקט בשם Aurora, במטרה לעבוד עם פשטות של פלטפורמת האינטרנט של צד שלישי, כמו מסגרות וספריות. המטרה שלהם היא לעזור לשפר את הביצועים ישירות במסגרת הפשטות של אלה, במקום שהנטל יעלה על הלקוחות שלהם - מפתחי אתרים.
למהדורה השלישית של Chrome Dev Insider, שוחחתי עם Addy Osmani, Kara Erickson ו-Hussein Djirdeh מצוות Project Aurora, כדי לקבל מידע נוסף על הגישה שלהם לפרויקט זה ועל מה שמצפה להם.
סקופ פנימי: עבודה עם מסגרות צד שלישי
בואו נתחיל ביצירת הפרויקט. איך זה קרה?
הוספה: Aurora התחילה עם רעיון פשוט: בואו נפגוש מפתחים במקום שבו הם נמצאים ונעזור להם להגיע לאן שהם צריכים. לדוגמה, אפשר לעזור לסטאק התוכנות הפופולרי שהם בחרו לשפר את הביצועים. מפתחי אפליקציות רבים מפתחים כיום באמצעות React, Vue או Angular, או מטא-מסגרות* כמו Next.js ו-Nuxt (וכמובן גם הרבה אחרים... Svelte, Lit, Preact, Astro. הרשימה ממשיכה!). במקום לצפות שהמפתחים האלה יהפכו למומחים עמוקים (למשל, ברמת הביצועים), אנחנו יכולים לוודא שהם ישולבו בשרשרת של הצלחה על ידי שילוב של שיטות מומלצות נוספות כברירת מחדל בקבוצות האלה. כך, אתרים איכותיים יותר הם תופעת הבנייה של האינטרנט בלבד.
אורורה בוחרת כמה מסגרות ומטא-מסגרות נפוצים לשיתוף פעולה, אנחנו מתעדים את התובנות שלנו (למשל, איך ליצור רכיב תמונה טוב), כדי שאחרים יוכלו לעקוב במהירות ולנסות לבצע התאמה לעומס (scaling) באמצעות מסגרות וכלים אחרים דרך Chrome Frameworks Fund. למרות שניתן לשפר את האיכות של חוויות אינטרנט באמצעות הדפדפן, אנחנו מאמינים שניתן להשיג את המטרה הזו (במקרים מסוימים) גם באמצעות מסגרות (frameworks). אנחנו מקווים שזה יעזור לנו להשיג את המטרות שלנו למען איכות אינטרנט משופרת לכולם.
Kara: כדי להרחיב זאת, הרעיון הוא לשפר את הביצועים באינטרנט על ידי שיפור חוויית המפתח. לא מספיק לפרסם שיטות עבודה מומלצות לשיפור הביצועים, מפני שהן משתנות לעיתים קרובות וקשה לחברות לעמוד בקצב. יש להם סדרי עדיפויות עסקיים משלהם שסביר להניח שיהיו לפני הביצועים.
לכן אנחנו שוקלים אם למפתחים יש זמן מוגבל להקדיש לשיפור הביצועים. כדאי שנקל (ומהיר יותר) עליהם לפתח אפליקציה שמניבה ביצועים טובים. אם אנחנו עובדים בשיתוף עם מסגרות אינטרנט פופולריות, אנחנו נמצאים בשכבה הנכונה של יכולת מופשטת לשיפור חוויית המפתחים באמצעות רכיבים ברמה גבוהה יותר, אזהרות תאימות וכו'. כל מי שמשתמש בכלים הפופולריים האלה יקבל גישה ליתרונות האלה. באופן תיאורטי, אם העצות המומלצות ישתנו, נוכל לעדכן את הרכיבים שלנו מאחורי הקלעים והמפתחים לא יצטרכו לדאוג לגבי עדכונים.
חוסיין: הצטרפתי ל-Google כתומך/ת למפתחים לפני שעברתי לתפקיד הנדסת תוכנה כמה שנים מאוחר יותר. חלק גדול מהעבודה הקודמת שלי כללה ללמד מפתחי אתרים את מגוון הדרכים השונות ליצירת חוויות משתמש מעולות. שוב ושוב סופקו גרסאות של אותה הנחיה, כדי להזהיר מפתחים מפני בעיות נפוצות שככל הנראה ישפיעו על הביצועים ונוחות השימוש של האתרים שלהם. כשהתחלנו לחשוב על פרויקט הזוהר הצפוני, שאלנו את עצמנו: האם אנחנו יכולים לפנות אל כיוון שבו לא נצטרך לומר למפתחים מה לעשות, כי שרשרת הכלים שלהם דואגת לכל הצרכים?
אם הבנתי נכון, מדובר בצוות של שישה מהנדסים? בטח לא ניתן לעבוד עם כל framework או ספרייה אפשריים. אז איך בוחרים עם מי לשתף פעולה? ומי הם?
Addy: האינטרנט דומה מאוד למערב הפרוע. אפשר לבחור כמעט כל מסגרת, חבילה, ספריות וספקי צד שלישי שרוצים. התהליך הזה מוסיף כמה שכבות של מורכבות, שיכולות לשפר את הביצועים או לפגוע בביצועים. אחת הדרכים הטובות ביותר להשפיע על הביצועים היא לאפשר לשכבות האלה להתקבע ולהוסיף להן דעות.
לדוגמה, מסגרות אינטרנט (Next.js, Nuxt.js ובמידה מסוימת Angular) מנסות ליצור דעות וברירות מחדל רבות יותר מאשר פתרון עם זרימה ידנית. זו אחת הסיבות שבגללן אנחנו אוהבים לעבוד איתם. במודלים האלה צריך להגדיר ברירות מחדל טובות יותר לטעינת תמונות, גופנים וסקריפטים כדי לשפר את מדדי הליבה לבדיקת חוויית המשתמש באתר.
זו גם דרך טובה לבדוק איפה השיטות המומלצות המודרניות עובדות, או שאולי תצטרכו לחשוב עליהן מחדש, כדי לתת מידע לכל המערכת האקולוגית לגבי האופן שבו צריך לפתור בעיות של אופטימיזציה.
קארה: מבחינה מעשית, צריך גם להביא בחשבון את הפופולריות. אם אנחנו רוצים להשיג את ההשפעה הגדולה ביותר באינטרנט, כדאי לעבוד עם frameworks וספריות שיש להן קהילה גדולה של מפתחים. כך אנחנו יכולים להגיע ליותר מפתחים ואפליקציות. אבל לא רק פופולריות. בסופו של דבר, מדובר בשילוב של פופולריות, עד כמה הספרייה מקובנת ומהו מערך התכונות הזמין שנוכל לעבוד איתה.
לדוגמה, אם אנחנו מסתכלים רק על הפופולריות, React, Vue ו-Angular הם "שלושת הערכים הגדולים" שיש לשקול. אבל אנחנו עובדים הכי הרבה עם Next.js, Nuxt ו-Angular. הסיבה לכך היא שספריות צפייה כמו React ו-Vue מתמקדות בעיקר ברינדור, ולכן לא ניתן ליצור בהן את כל התכונות שאנחנו רוצים באופן ישיר. לכן אנחנו עובדים בצורה הדוקה יותר עם מטא-מסגרות מקובעים המבוססות עליהן: Next.js ו-Nuxt. ברמה כזו של הפשטה, אנחנו יכולים ליצור רכיבים מובנים. יש בהם גם שרתים מובנים, כך שנוכל לכלול אופטימיזציות בצד השרת.
אולי תבחינו ש-Angular נכלל ברשימה של השותפויות העמוקות הזו, אך זו לא מטא-מסגרת. Angular הוא מקרה מיוחד כי הוא די פופולרי, אבל אין לו מטא-מסגרת משלימה כמו React ו-Vue. לכן אנחנו עובדים איתם ישירות ותורמים תכונות דרך ה-CLI שלהם במידת האפשר.
חשוב לציין שיש לנו מספר קשרים מתמשכים עם פרויקטים אחרים כמו גטסבי, שבהם אנחנו מסתנכרנים במידה מסוימת על העיצוב אבל לא תורמים את הקוד באופן פעיל.
איך זה נראה בפועל? מה הייתה הגישה שלכם לפתרון הבעיה הזו?
Kara: בפועל, יש לנו כמה מסגרות שאנחנו עובדים איתן בשיתוף פעולה הדוק. נקדיש זמן כדי ליצור פרופיל לאפליקציות באמצעות המסגרת הזו, ולהבין את הבעיות הנפוצות בביצועים. לאחר מכן אנחנו עובדים עם צוות ה-framework כדי לתכנן תכונות ניסיוניות שיפתרו את הבעיות האלה, ותורמים קוד ישירות למאגר OSS כדי להטמיע אותן.
חשוב לנו מאוד לוודא שההשפעה על הביצועים היא מה שציפינו, לכן אנחנו עובדים גם עם חברות חיצוניות כדי לבצע בדיקות ביצועים בסביבת הייצור. אם התוצאות מעודדות, נעזור לתכונה להפוך ל'יציבה', ואולי נהפוך אותה לברירת מחדל.
קל יותר להשמיע את הסאונד. אילו מהאתגרים או התובנות שצברתם עד עכשיו?
חוסיין: אחד מהדברים החשובים שאנחנו מנסים לנווט אותם כמיטב יכולתנו הוא לתרום למאגרים פופולריים בקוד פתוח שיש להם הרבה עדיפויות מתחרים. העובדה שאנחנו עובדים בצוות של Google לא בהכרח אומרת שהתכונות שלנו יקבלו עדיפות, כך שאנחנו עושים כמיטב יכולתנו כדי ליישר קו עם התהליך האופייני של הצעה ושליחה של תכונות חדשות, בלי לדאוג לכך. שמחנו מאוד לעבוד עם המאבטחים המתאימים במערכות האקולוגיות Next.js, Nuxt ו-Angular. אנחנו אסירי תודה שהם היו מוכנים להקשיב לחששות שלנו לגבי הסביבה העסקית באינטרנט, ומוכנים לשתף איתנו פעולה ביותר מדרך אחת.
יש הרבה מסגרות שאנחנו עובדים איתן. המטרה הכוללת שלנו זהה: איך מפתחים יכולים ליהנות מחוויית משתמש משופרת וליצור חוויית פיתוח מעולה, וגם ליהנות מחוויית פיתוח מעולה? אנחנו מודעים ומכבדים את העובדה שיש מאות, אם לא אלפים, של תורמי תוכן ונושאי מסגרות, שכל אחד מהם עובד על פרויקטים שונים שמשתלבים זה עם זה.
Kara: בנוסף, מכיוון שחשוב לנו לאמת את ההשפעה על הביצועים ולפעול על סמך הנתונים, התהליך נמשך קצת יותר זמן. אנחנו נמצאים באזור לא ממופה, לכן לפעמים אנו עורכים ניסויים עם אופטימיזציה שלא נצליח, ובסופו של דבר לא נבנה תכונה מתוכננת. גם כשתכונה מסוימת פועלת, השלבים הנוספים האלה לבדיקת הביצועים לוקחים זמן ומארכים את לוחות הזמנים.
גם מציאת שותפי הפקה שיבדקו את התכונות שלנו יכולה להיות מאתגרת. כפי שצוין קודם לכן, הם עסקים ויש להם סדרי עדיפויות משלהם, ולכן יכול להיות שהם מתקשים להשתלב ביוזמות חדשות אם הם לא מתאימים לפרויקטים קיימים שצריכים להיות בעדיפות ראשונה. בנוסף, החברות שהכי מעוניינים לעזור נוטות כבר להקדיש את הזמן להשקעה בביצועים, כך שהן לא באמת קהל היעד שלנו. אנחנו מנסים לאסוף משוב ממגוון חברי הקהילה שלא יכולים להשקיע בביצועים, אבל הסבירות שהם יפנו אלינו היא הנמוכה ביותר.
בהמשך, באיזה סוג של אופטימיזציות בחרת להתמקד?
חוסיין: אחרי ניתוח של אלפי אפליקציות, גילינו שהבעיות המשמעותיות ביותר בביצועים נובעות בדרך כלל מתבניות נגד בקוד של האפליקציה, ולא במסגרת ה-framework עצמה. לדוגמה, שליחת תמונות גדולות שלא לצורך, טעינת גופנים מותאמים אישית מאוחר מדי, אחזור יותר מדי בקשות של צד שלישי שחוסמות את ה-thread הראשי, וחוסר טיפול באופן שבו תוכן אסינכרוני יכול לגרום לדברים אחרים לתזוזה בדף. אלה כל הבעיות שעשויות להתעורר, ללא קשר לכלי שבו אתם משתמשים. לכן חשבנו – האם אפשר ליישם כמה אופטימיזציות ברירת מחדל שמטפלות בהן כראוי, אבל עם חוויית פיתוח מסודרת שמתאימה היטב לכלי framework שלהם?
מתוך מחשבה כזו, שלחנו:
- רכיב התמונה Next.js.
- רכיב הסקריפט Next.js.
- הטמעת גופן אוטומטית בתהליך ה-build של Next.js.
- ההנחיה לגבי תמונות אנגוליות.
- פלאגין של ESLint לתאימות Next.js כדי לספק למפתחים הנחיות פרקטיות.
העבודה שלנו העניקה השראה למסגרות ולכלים אחרים שנועדו ליישם אופטימיזציות דומות. הנחיה זו כוללת, בין היתר:
- מודול Nuxt
- שינויים במדדים של גופן Nux
- רכיב סקריפט Nuxt (בתהליך)
- רכיב סקריפט Gatsby
האם אפשר לשתף תוצאות חיוביות של העבודה שלך עם חלק מהשחקנים?
חוסיין: אתרים רבים ראו שיפורי ביצועים בעקבות האופטימיזציות ששלחנו. אחת הדוגמאות האהובות עליי היא Leboncoin, שהפחיתה את ה-LCP מ-2.4 שניות ל-1.7 שניות אחרי שעברו לרכיב התמונה Next.js. יש עוד הרבה שלבי ניסוי ובדיקה בתקופה הזו, ונמשיך לשתף את התובנות ואת ההישגים שלנו מהשלבים האלה כאן.
הבנתי שההתמקדות שלך היא באלה שהפופולריות שלהן היא הגבוהה ביותר, אבל האם יש דרכים שבהן מסגרות או ספריות אחרות שאינך עובד איתן גם עובדות באופן יזום?
הוספה: ניתן לשכפל חלק גדול מהאופטימיזציות של הביצועים ב-Aurora בכל מסגרת. מומלץ לבדוק את המאמצים שלנו לרכיבים עם תמונות או סקריפט. לדוגמה, לעיתים קרובות הם מקבצים יחד קבוצה קיימת של שיטות מומלצות. אנחנו מנסים לתעד איך לבנות רכיבים כאלה ואיך הם נראים בכל מסגרת. אני מקווה שזו התחלה טובה להעתקת הרעיון.
זכינו להצלחה רבה בזכות לקיחת הלקחים מסביבה אחת (לדוגמה, React ו-Next.js) והבאנו אותם למערכות אחרות. לדוגמה, הדירקטיבה החדשה בנושא תמונות ב-Angular (המבוססת על התובנות שלנו על בניית רכיב התמונה Next.js) או על Gatsby שממחישה את הגישה שלנו להגדרה מפורטת של JavaScript.
עם זאת, אנחנו מבינים שלא בכל מסגרת יש את רוחב הפס או המימון לתורמים כדי לפתח תכונות ביצועים דומות או להשקיע באופטימיזציות אחרות שלדעתם חשובות למשתמשים שלהם. הקרן של Chrome Web Frameworks מאפשרת לנו לתת חסות לעבודה על ביצועים בסביבה העסקית של JavaScript, כדי לאפשר לפרויקטים לשלם לתורמים שלהם ולאפשר לפרויקטים להתרחב עוד יותר בסביבה העסקית.
אז מה מתכננים מבחינת הצוות שלך?
קרה: יש לנו הרבה פרויקטים מרגשים בקרוב! הנה כמה הדגשים:
- הפחתת CLS הקשור לגופנים: ניתן לראות תנודות בפריסה כשגופן אינטרנט נטען ומחליף את הגופן החלופי. אנחנו בוחנים שימוש בשינוי מדדי גופנים ובמאפיין 'התאמת גודל' כדי להפחית את ערכי ה-CLS שקשורים לגופנים כברירת מחדל ב-Next.js. בנוסף, התייעצנו עם הצוות של Nuxt בנושא הזה, ואנחנו מתכננים להרחיב את השימוש ברעיון הזה למסגרות נוספות בשנה הבאה.
- ניפוי באגים ב-INP: עכשיו, לאחר שהמדד אינטראקציה אל הצבע הבא (INP) פורסם, אנחנו עובדים עם מסגרות כדי לחקור את הגורמים הנפוצים ביותר לבעיות ב-INP בקהילות שלהם ולהציע פתרונות. אנחנו משתפים פעולה עם Angular באופן הדוק, ומקווים שנוכל לשתף כמה תוצאות בקרוב!
- אופטימיזציה של סקריפטים נפוצים של צד שלישי: טעינת סקריפטים של צד שלישי בזמן שגוי עלולה להשפיע לרעה באופן משמעותי על הביצועים. יש כמה צדדים שלישיים נפוצים מאוד, ולכן אנחנו בודקים אם אנחנו יכולים להציע קובצי wrapper עבורם כדי לוודא שהם נטענים בצורה אופטימלית ב-frameworks ולא חוסמים את ה-thread הראשי. אנחנו משתמשים ברכיב הסקריפט Next.js שפיתחנו כנקודת התחלה לבדיקה זו.
המפתחים יכולים לעקוב אחרי ההתקדמות שלנו באתר הזה.
בחדשות
לפני שנסיים, רציתי לתת לך כמה עדכונים מעניינים מעולם ה-frameworks שמתרחש ב-Google.
בחודש יולי, צוות Chrome הכריז על הסבב האחרון של מימון בסך 500,000 $עבור קרן הכלים והמסגרות שמתמקדת במימון פרויקטים שמטרתם לשפר את הביצועים, חוויית המשתמש וחוויית המפתח באינטרנט. מימון עתידי יכלול פרויקטים חדשים, לכן אל תשכחו לשלוח את הבקשה שלכם.
וכמובן, יש גם המון דברים מדהימים שמתרחשים בקהילה. הסביבה העסקית משגשגת עם frameworks חדשות כמו Fresh של Deno, וחוויות מדהימות כמו המדריך למשתמשים חדשים של Svelte, שאינו רק הדגמה שקיימת בדפדפן, אלא גם משתמשת ב-Web Container API כדי להריץ את Node.js באופן מקורי בדפדפן. כל כך הרבה דברים טובים!
אני ממש מתרגש לראות את הסביבה העסקית שמתאחדת, לקדם את האפשרויות בדפדפן ולעזור למפתחים לבנות מוצרים שמתאימים לכולם. זה זמן מרגש להיות מפתח אתרים.
עד הניוזלטר הבא, Hwyl fawr.
מה חשבת על המהדורה הזו של Chrome Dev Insider? נשמח לקבל משוב.