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