מפתחים מדווחים לנו לעיתים קרובות שקשה להם לעמוד בקצב השינויים באינטרנט ולהבין למה הם מתרחשים. היום אנחנו משיקים סדרה חדשה בשם Chrome Dev Insider, שבה נשתף (1) דברים מגניבים וחדשותיים, (2) תובנות לגבי האופן שבו קיבלנו החלטה בנושא מרכזי (לדוגמה, שינוי FLOC) או לגבי הגישה שלנו לעבודה עם הסביבה העסקית (לדוגמה, Interop 2022), וגם (3) דברים חשובים מאוד שחשוב לדעת עליהם (לדוגמה, שינויים במחרוזות של סוגי המשתמשים).
כשנשתף את הדברים שאנחנו עובדים עליהם, נתייחס לארבעת העדיפויות שלנו לשנת 2022:
- יצירת חוויות משתמש מהנות: יצירת סביבה אינטואיטיבית למשתמשים, בין אם מדובר בביצועים, בעסקאות, בזהות או במעברים.
- שיפור היכולות של האינטרנט: תמיכה בהתפתחות התפקיד של האינטרנט מפלטפורמה לצריכת תוכן לפלטפורמה למגוון רחב של חוויות, כולל חוויות שדורשות שילובים עמוקים ברמת מערכת ההפעלה והחומרה.
- פיתוח אינטרנט פשוט יותר: קבלת החלטות קלה יותר ושיפור הפרודוקטיביות של המפתחים.
- שיפור הפרטיות באינטרנט: מתן מענה לציפיות של משתמשי האינטרנט להגנה טובה יותר על פרטיות הנתונים, מול המורכבות ההולכת וגוברת של הפיתוח במעקב ובטירגוט.
בחדשות: Interop 2022
כשאנחנו מתכננים את מפות הדרכים שלנו, אנחנו בודקים, בין היתר, את המשוב מהמפתחים כדי להבין את נקודות החולשה והצרכים העיקריים של מפתחי האתרים. אחד מהנושאים העיקריים שמופיעים שוב ושוב הוא תאימות לדפדפנים, שמאפשרת לכם להציג את חוויית השימוש באופן זהה בכל הדפדפנים. במהלך השנה האחרונה, עבדנו עם הסביבה העסקית כדי לטפל בנושא הזה כחלק מהעדיפות שלנו 'לפשט את פיתוח האתרים'.
בשנה שעברה, Microsoft, Chrome וגורמים נוספים בסביבה העסקית הכריזו על Compat 2021, וכתוצאה מכך כל מנועי הדפדפנים הפופולריים (Chromium, Gecko ו-Webkit) השיגו ציון של יותר מ-90% בחמשת תחומי ההתמקדות העיקריים שזוהו לשנה. בין היתר, Compat 2021 הוביל ליצירת תשתית איתנה לתכונות חזקות כמו CSS Grid (שימוש של 12% וגידול מתמיד) ו-CSS Flexbox (שימוש של 77%).
בחודש שעבר, Apple, Bocoup, Google, Igalia, Microsoft ו-Mozilla התאחדו כתומכים כדי לפתור את בעיות התאימות המובילות בדפדפנים שזוהו על ידי מפתחי אתרים, ולהסכים על נקודת ייחוס משותפת. התוצאה היא Interop 2022, פרויקט שמטרתו לשפר את ההומוגניות בפלטפורמה. מדד הביצועים מתמקד ב15 תחומי עדיפות שאותרו על ידי המפתחים כמפתח לשיפור הפרודוקטיביות שלהם.
מידע מהימן: עבודה עם יצרני הדפדפנים האחרים
לקראת כנס Interop 2022, ערכתי שיחה עם רוברט נימן ועם פיליפ יגנשטדט, שהיו מעורבים בשיחות האלה, כדי לקבל את הסיפור מבפנים. זהו העריכה של העורכים של התהליך.
מה המקור של היוזמה הזו?
רוברט: הכל התחיל בשנת 2019, כשערכנו את הסקר MDN DNA 2019. בעיות תאימות היו בבירור הבעיה העיקרית של מפתחים שמפתחים לאינטרנט, ופירוט נוסף על כך זמין בדוח התאימות לדפדפנים של MDN לשנת 2020. כך צברנו מספיק מידע ונתונים פרקטיים כדי להתחיל את המאמצים של Compat 2021, שהובילו להמשך העבודה הזו ולמרחיב את ההיקף שלה באמצעות Interop 2022.
Philip: רציתי גם להזכיר את web-platform-tests ואת State of CSS 2021. במשך שנים שיתוף הפעולה שלנו עם ספקי דפדפנים אחרים בנושא בדיקות באמצעות WPT היה חזק, ורצינו להמשיך בכך. רוב הבדיקות של התכונות האלה כבר נכתבו, אז רק צריך לבדוק את הבדיקות ולהוסיף כיסוי חסר. Google השקיעה הרבה ב-wpt.fyi, אבל אנחנו גם צריכים להודות ל-Mozilla על כך שהפכה את WPT להצלחה שהיא היום. כמובן שגם ל-Mozilla הייתה יד רבה בסקרים של MDN DNA. בנוסף, יש גם את State of CSS 2021. כדי להפיק אירוע כמו Interop 2022, אנחנו זקוקים למשוב עדכני לגבי הצרכים של מפתחי האינטרנט. לכן עבדנו עם Sacha, מנהל הסקר, כדי לכלול כמה שאלות חדשות לגבי בעיות בתאימות לדפדפנים. זה עזר לנו מאוד בתהליך התכנון של Interop 2022.
יש לכם תובנות או משוב מהכנס Compat 2021?
רוברט: היה מאוד שימושי למדוד את הביצועים של כל מנוע דפדפן ולקבל ציונים ותובנות לגבי הביצועים, כדי שנוכל לעקוב אחרי ההתקדמות ולוודא שאנחנו דנים בבעיות לא ברורות או בבעיות שצריך לתת להן עדיפות ומטפלים בהן. מהר מאוד הבנו גם ש-Interop הוא שם טוב יותר ליוזמה. בדרך כלל, ספקי הדפדפנים מבדילים בין המונחים תאימות ויכולת פעולה הדדית. המונח 'תאימות' מתייחס לתאימות לאתר, והמונח 'יכולת פעולה הדדית' מתייחס לשני דפדפנים או יותר שמתנהגים באותו אופן. במונחים האלה, המאמץ הזה מתמקד ביכולת פעולה הדדית, ולכן השם של הפרויקט תואם לכך.
מה החזון שלנו כאן?
רוברט: כדי שהאינטרנט יישאר פתוח, חשוב מאוד שיהיו מגוון דפדפנים ומגוון מנועי עיבוד. לצערנו, המצב הזה כרגע כרוך בתשלום גבוה למפתחים שלנו, שצריכים לעמוד בקצב של רמות התמיכה השונות בתכונות בכל מנוע חיפוש. החזון שלנו הוא שמפתחים יראו בפלטפורמת האינטרנט את האפשרות הכי ריאליסטית והבחירה הכי אטרקטיבית לצרכים שלהם, ושהם יוכלו להתמקד ביצירת חוויות המשתמש הטובות ביותר במקום להשקיע הרבה זמן בפתרון בעיות של יכולת פעולה הדדית. ברור מאוד שכדי להשיג את היעד הזה, התכונות הנפוצות ביותר צריכות להופיע בכל מנועי הדפדפנים העיקריים כדי לאפשר למפתחים להצליח בפלטפורמת האינטרנט.
איך אנחנו מתקדמים יחד כשדפדפנים עם מטרות שונות (לפעמים) פועלים יחד?
Philip: הגישה שלנו היא לחפש תחומים של אינטרסים משותפים, כדי למצוא שיתופי פעולה שמועילים לשני הצדדים, שבהם היעדים כבר תואמים באופן כללי. בנוסף, כשאנחנו נותנים עדיפות למספר מוגבל של דברים שאנחנו עובדים עליהם בו-זמנית, אנחנו מתמקדים בתחומים האלה, מתקדמים מהר יותר ומקבלים איכות גבוהה יותר מאשר אם היינו פשוט עובדים בנפרד. זה הרעיון.
לדעתי חשוב להבין שיש מגבלות לגישה הזו שמבוססת על הסכמה. אם היעדים לא תואמים מספיק, אנחנו צריכים להתקדם בדרך אחרת. לפעמים כדאי להציג ראיות נוספות לגבי הצרכים של מפתחי האינטרנט או המשתמשים, אבל בסופו של דבר, ספקי הדפדפנים יכולים לשלוח תכונות שלא זכו להסכמה רחבה. במקרה הטוב, מפתחי אתרים ינסו את התכונה, יראו שהיא עונה על הצרכים שלהם ויבקשו את אותה תכונה בכל הדפדפנים.
חוזרים ל-Interop 2022. האם תכונות שאינן קשורות לעיצוב או לפריסה ייכנסו לצינור עיבוד הנתונים בשלב כלשהו?
Philip: בהחלט! כנס Interop 2022 לא התמקד רק בתכונות של עיצוב פריסת המסך, אבל בסופו של דבר הוא התמקד מאוד ב-CSS. חלק מהסיבה לכך היא ש-State of CSS 2021 היה עדכני, אבל גם כי מפתחי אתרים אמרו לנו שזו נקודת החולשה העיקרית שלהם ביחס להבדלים בין הדפדפנים. יש כמה תחומי התמקדות, כמו רכיבי טפסים ותיבות דו-שיח, שאינם קשורים ל-CSS. בנוסף, אנחנו מבצעים מאמצים לחקור את עריכת ממשקי ה-API ואת האירועים של הסמן והעכבר. אני מקווה שבכנס Interop 2023 יהיו לנו נתונים עדכניים יותר לגבי הצרכים של המפתחים באינטרנט, ונעסוק בתכונות נוספות כאלה.
שינויים מרכזיים שיחולו בקרוב
אחד מהמטרות של הסדרה הזו היא להודיע למפתחים על שינויים מרכזיים שצפויים בקרוב, שחשובים לשיפור חוויית המשתמש והיכולות של הפלטפורמה.
לוחות הזמנים שמפורטים בהמשך הם התאריכים שבהם אנחנו צופים שהשינויים האלה יתרחשו. עם זאת, יכול להיות שגרסאות המוצר של התכונות ישתנו.
הפחתת סוכני משתמשים
הכותרת User-Agent – וממשקי ה-JS המשויכים לה – מעבירים לא רק מידע שימושי על הדפדפן והמכשיר, אלא גם היסטוריה של ישות קודמת ומידע לא מדויק. הבעיה הגדולה יותר מאשר המלאי כמעט האינסופי של באגים בניתוח מחרוזות של UA היא העובדה שהיא נשלחת פסיבית לשרתים לכל בקשות הניווט והמשאבים המשניים. זה מייצג כ-10 ביטים של אנטרופיה ששרתים יכולים להשתמש בהם כדי ליצור מזהי מעקב יציבים כשמשתמשים מנווטים באינטרנט.
התוכנית הנוכחית שלנו היא לצמצם את מחרוזת ה-UA הקיימת על ידי המשך שליחת נתונים של גרסה ראשית של דפדפן עם אנטרופיה נמוכה, שם פלטפורמה וניידות, ולהקפיא את המידע עם אנטרופיה גבוהה. בתרחישי שימוש שבהם נדרש מידע נוסף מעבר למידע שמופיע בכותרת, אנחנו שולחים את ממשק ה-API של הצעות לקוח של סוכן משתמש מאז Chrome 89.
הרצנו גרסת Origin Trial במשך 6 חודשים לצורך ניסוי ומשוב, והיה לנו נעים לגלות שלא קיבלנו משוב לגבי שיבושים, למרות שהיו לנו יותר מ-200 משתתפים.
- לוח זמנים: ב-Chrome 101 נמשיך לשלב 4: צמצום המידע של
MINOR.BUILD.PATCHבמחרוזת UA ל-0.0.0. בנוסף, נמשיך להודיע מראש לאתרים ולתת להם זמן להתכונן לשלבים 5 ואילך. בנוסף, יצאנו עם מדיניות ארגונית כדי שתוכלו לבטל את ההסכמה לשינויים האלה. בנוסף, נעביר תקופת ניסיון להוצאה משימוש עד לגרסה 113 של Chrome כדי לתת לאתרים יותר זמן להתכונן לשינויים האלה. - קריאה לפעולה: העברת האתר שלכם ל-UA Client Hints או השתתפות בתוכנית הניסוי לקראת ההוצאה משימוש.
Local Fonts Access API
אנחנו משיקים ב-Chrome את Local Font Access API. כבר זמן רב אפשר להשתמש בגופנים מקומיים באתרים, אבל ממשק ה-API הזה מציג את רשימת הגופנים המקומיים ומספק גישה לנתוני הגופן עצמם. הפונקציונליות הזו מאפשרת למשתמשים להשתמש בכל הגופנים שלהם בעיצוב מבוסס-אינטרנט ובאפליקציות אחרות.
גופנים מקומיים מוכרים כבר זמן רב כוקטור ליצירת טביעת אצבע. ממשק ה-API החדש הזה לא מגדיל את היכולת להשתמש בגופנים לצורך יצירת טביעת אצבע, אבל ב-Chrome נדרש מהמשתמש להעניק לאתר הרשאה חדשה מסוג "local-fonts" כדי שיוכל להשתמש ב-Local Font Access API החדש.
בעתיד, אנחנו מתכננים לדרוש את אותה הרשאה 'local-fonts' לפני שימוש ב-API אחר שמספק גישה לגופנים מקומיים.
- לוח זמנים: טירגוט גרסה 103 של Chrome (יוני 2022)
- קריאה לפעולה: מידע נוסף על ה-API ואיך משתמשים בו כדי להתחיל בהטמעה
איך BFCache פועל עם Cache-control: no-store
זיהינו הזדמנות משמעותית לשפר את התדירות שבה המטמון לדף הקודם/הבא יכול לספק ניווטים מיידיים אחורה וקדימה. לשם כך, צריך לשנות את האופן שבו BFCache פועל בדפים שמוצגים עם כותרת ה-HTTP Cache-control: no-store. יש לנו הצעה ציבורית שנועדה למנוע הפתעות משמעותיות על ידי מעקב אחר אותות שונים (לדוגמה, פינוי דפים מ-BFCache בכל פעם שקובץ cookie של HTTP בלבד משתנה) והחרגות (לדוגמה, מדיניות קבוצתית ללקוחות Enterprise או Edu) להקשרים ייחודיים. זוהי הזדמנות מורכבת ומלהיבה, ונשמח לקבל מכם בדיקה ומשוב נוספים.
- לוח זמנים: טירגוט ל-Chrome 104 (יולי 2022), בהנחה שלא יהיו הפתעות גדולות.
- קריאה לפעולה: פרטים נוספים זמינים בבקשה, כולל הוראות להפעלת הטמעה בגרסת 'בטא' ודרכים לשיתוף משוב, כמו תרחישים אמיתיים שבהם הגישה שלנו תיצור מכשולים חדשים.
אני מקווה שהסדרה הזו תאפשר לקהילת המפתחים שלנו להכיר טוב יותר את הצוות שלי ואת העבודה שלו, וכך להרגיש יותר מחוברים לנושא. כדאי לעקוב אחרינו כדי לקבל עדכונים נוספים.
עד אז, שתהיה לך עבודה נעימה.
מה חשבתם על המהדורה הראשונה של Chrome Dev Insider? נשמח לקבל ממך משוב.