לעתים קרובות מפתחים אומרים לנו שקשה להתעדכן בשינויים באינטרנט ולהבין את הסיבות לשינויים האלה. היום אנחנו משיקים סדרה חדשה בשם Chrome Dev Insider שבה נשתף (1) מה מגניב ומעניין, (2) תובנות לגבי האופן שבו קיבלנו החלטה בנושא מרכזי (לדוגמה, שינוי FLOC) או שנתייחס לעבודה שלנו עם הסביבה העסקית (לדוגמה Interop 2022), ו-(3) פרטים חשובים באמת שאתם צריכים לדעת לגבי שינויים בנציג.
אנחנו עובדים על מה שאנחנו עובדים עליו בהקשר של ארבעת הנושאים שעומדים בראש סדר העדיפויות שלנו לשנת 2022:
- חוויית משתמש מהנה: כדאי להציע למשתמשים דברים אינטואיטיביים יותר – ביצועים, עסקאות, זהות או מעברים.
- קידום היכולות של האינטרנט: תמכו בפעילות המתפתחת של האינטרנט מפלטפורמה לצריכת תוכן, לפלטפורמה לצריכת תוכן, למגוון רחב של חוויות, כולל כאלה שדורשות שילובים עמוקים של מערכת הפעלה וחומרה.
- פיתוח פשוט יותר של אתרים: קבלת החלטות קלה יותר ושיפור הפרודוקטיביות של המפתחים.
- שיפור הפרטיות באינטרנט: השירות הזה נועד לשרת את הציפיות של משתמשי האינטרנט ליהנות מהגנה טובה יותר על פרטיות הנתונים, לנוכח התחכום ההולך וגדל של מפתחים במעקב ובטירגוט.
בחדשות: פעולות הדדיות בשנת 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 אזורים בעדיפות גבוהה שהמפתחים מגדירים כמפתח לשיפור הפרודוקטיביות שלהם.
סקופ פנימי: עבודה עם דפדפנים עמיתים
בראש סדר העדיפויות של 'שיתוף וסנכרון' 2022, ישבתי עם רוברט נימן ופיליפ יאגנסטדט שהיו מעורבים בשיחות האלה כדי לקבל את הסיפור הפנימי. הנה חיתוך הסיפור של העורך.
מה רעיון היוזמה?
Robert: הכול התחיל ב-2019, כשערכנו את הסקר בנושא MDN DNA 2019. בעיות תאימות בולטו בבירור כהבעיה העיקרית של מפתחים שמפתחים לאינטרנט, ובדוח התאימות לדפדפן MDN משנת 2020 ביצענו מעקב מפורט יותר. נתנו לנו מספיק מידע ונתונים מעשיים כדי להתחיל במאמצים של Compat לשנת 2021, שהובילו גם להמשך העבודה וגם להרחבת ההיקף באמצעות הכלי 'שיתוף וסנכרון' 2022.
פיליפ: אני רוצה לציין גם את web-platform-tests ואת State of CSS 2021. היה לנו שיתוף פעולה חזק עם ספקי דפדפנים אחרים על בדיקות באמצעות WPT כבר שנים רבות, ורצינו מאוד להסתמך על כך. הבדיקות של התכונות האלה כבר נכתבו ברובן, לכן היינו צריכים רק לבדוק את הבדיקות ולהוסיף כיסוי חסר. Google השקיעה רבות ב-wpt.fyi, אבל יש לנו גם את Mozilla כדי להודות על עובדה ש-WPT מצליחה היום. ל-Mozilla הייתה כמובן יד גדולה גם בסקרי ה-DNA ב-MDN. מעבר לזה, יש גם את תמונת המצב של שירות CSS 2021. כדי שנוכל לארגן מאמץ כמו Interop 2022, אנחנו זקוקים למידע עדכני לגבי הצרכים של מפתחי אתרים. לכן עבדנו עם Sacha, אחראי הסקרים, וכללנו כמה שאלות חדשות על בעיות תאימות של דפדפנים. זה מאוד עזר לנו בתהליך התכנון של פעולות הדדיות לשנת 2022.
יש תובנות או משוב לגבי Compat 2021?
Robert: היה מאוד שימושי למדוד ולקבל ציונים ותובנות לגבי הביצועים של כל מנוע דפדפן, כך שיכולנו לעקוב אחרי ההתקדמות ולוודא לדון בבעיות שלא היו ברורות או שצריך לתת להן עדיפות, ולטפל בהן. מהר מאוד הבנו ש-"Interop" הוא שם טוב יותר ליוזמה. המונחים תאימות ויכולת פעולה הדדית נבדלים בדרך כלל על ידי ספקים של דפדפנים. לעומת זאת, 'תאימות' מתייחסת ל'תאימות אתרים', והמונח 'יכולת פעולה הדדית' מתייחס לשני דפדפנים או יותר שמתנהגים באופן זהה. מבחינת המונחים האלה, המאמץ עוסק ביכולת פעולה הדדית, כך שהפרויקט הותאם עם השם הזה.
מהו החזון שלנו?
Robert: כדי שהאינטרנט יישאר פתוח, חשוב מאוד לשמור על מגוון תרבותי של הדפדפן ושל מנוע הרינדור. למרבה הצער, מדובר בשלב זה במחיר גבוה למפתחים שלנו, שצריכים לעמוד ברמות התמיכה השונות בתכונות בכל מנוע חיפוש. החזון שלנו הוא שמפתחים רואים בפלטפורמת האינטרנט את האפשרות הכדאית ביותר ואת האפשרות האטרקטיבית ביותר לצרכים שלהם, והם יכולים להתמקד בבניית החוויות הטובות ביותר שאפשר, במקום להקדיש זמן רב לפתרון בעיות שקשורות ליכולת פעולה הדדית. ברור מאוד שכדי להשיג את המטרה הזו, התכונות המבוקשות ביותר צריכות להגיע לכל מנועי הדפדפנים המובילים כדי לאפשר באמת למפתחים להצליח בפלטפורמת האינטרנט.
איך אנחנו זזים קדימה, כשדפדפנים עם מטרות שונות (לפעמים) נפגשים יחד?
פיליפ: הגישה שלנו הייתה לחפש תחומים שיש בהם עניין משותף, כדי למצוא את שיתופי הפעולה המנצחים שבהם היעדים כבר דומים. כשנותנים עדיפות למספר מוגבל של דברים שאנחנו צריכים לעבוד עליהם בו-זמנית, אנחנו מתמקדים בתחומים האלה, מתקדמים מהר יותר ונהנים איכות גבוהה יותר מאשר אם נעבוד בנפרד. זה הרעיון.
אני חושב שחשוב להכיר בכך שיש גבולות לגישה מבוססת-ההסכמה הזו, כאשר היעדים אינם תואמים מספיק, עלינו להתקדם בדרך אחרת. לפעמים מספיק ראיות לגבי צורכי מפתחי אתרים או משתמשים, אבל בסופו של דבר ספקים של דפדפנים יכולים לשלוח דברים שאין להם הסכמה רחבה. במקרה הטוב ביותר, מפתחי אתרים שמנסים את התכונה מוכיחים את הערך של התכונה, מגלים שהיא עונה על הצרכים שלהם ומבקשים את אותה התכונה בכל הדפדפנים.
בחזרה לתכונה 'שיתוף וסנכרון' 2022, האם בשלב כלשהו יתווספו לצינורות עיבוד הנתונים תכונות שלא קשורות לעיצוב או לפריסה?
פיליפ: בהחלט! בשנת 2022, Interop 2022 לא הייתה מוגבלת לתכונות של עיצוב ופריסה, אבל בסופו של דבר היה הרבה שימוש ב-CSS. אחת הסיבות לכך היא שמצב CSS 2021 היה חדש, אבל גם כי מפתחי אתרים סיפרו לנו שכאן יש להם הכי הרבה בעיות עם הבדלים בין דפדפנים. תחומי התמקדות מרובים, כמו רכיבי טפסים ותיבות דו-שיח, הם מעבר ל-CSS, ואנחנו משקיעים גם כמה חקירות לגבי עריכת ממשקי API ואירועים של 'סמן העכבר' ו'עכבר'. אני מקווה שבמהלך 2023 של Interop 2023 יהיו לנו יותר נתונים עדכניים לגבי צורכי המפתחים באינטרנט, ונוסיף עוד תכונות כאלה למאמץ הזה.
שינויים עיקריים קרובים
אחת מהמטרות של הסדרה הזו היא ליידע את המפתחים לגבי שינויים מרכזיים שיחולו בקרוב – דברים שחשובים לשיפור חוויית המשתמש והיכולות של הפלטפורמה.
לוחות הזמנים שמפורטים בהמשך הם המועדים שבהם אנחנו צופים שהשינויים האלה יתרחשו. עם זאת, יכול להיות שגרסאות הפצה של תכונות ישתנו.
הפחתה בסוכן המשתמש
הכותרת User-Agent – וממשקי ה-JS המשויכים אליה – מעבירים לא רק מידע שימושי על הדפדפן והמכשיר, אלא גם גורמים למורשת של שושלת מידע ומידע לא מדויק. בעייתית יותר מההיצע הכמעט אינסופי של באגים לניתוח מחרוזת UA היא העובדה שהם נשלחים באופן פסיבי לשרתים עבור כל הבקשות לניווט ולמשאבי משנה. נתונים אלה מייצגים אנטרופיה באורך של כ-10 סיביות, שבהן שרתים יכולים להשתמש כדי לבנות מזהי מעקב יציבים כאשר משתמשים מנווטים באינטרנט.
התוכנית הנוכחית שלנו היא לצמצם את מחרוזת ה-UA הקיימת על ידי המשך המשלוח של הגרסה הראשית של הדפדפן, שם הפלטפורמה והניידות שלה עם אנטרופיה נמוכה, תוך הקפאת נתוני האנטרופיה הגבוהים. במקרים שבהם נדרש מידע נוסף מעבר לאלו שבכותרת, החלנו את ממשק ה-API של User-Agent Client Hints API מ-Chrome 89.
הפעלנו גרסת מקור לניסיון למשך 6 חודשים לצורך התנסות ומשוב, ושמחנו שלא קיבלנו משוב שקשור לשיבושים, למרות יותר מ-200 משתתפים.
- ציר הזמן: בגרסה 101 של Chrome, אנחנו מתקדמים בשלב 4: צמצום המידע על
MINOR.BUILD.PATCHבמחרוזת UA ל-0.0.0. בנוסף, נמשיך לתת לאתרים התראה וזמן להתכונן לשלב 5 ואילך. בנוסף, יצרנו מדיניות ארגונית כדי לבטל את ההסכמה לשינויים האלה. במסגרת התוכנית נפעיל גרסת ניסיון להוצאה משימוש עד גרסה 113 של Chrome, כדי לתת לאתרים יותר זמן להתכונן לשינויים האלה. - קריאה לפעולה: מעבירים את האתר ל'רמזים ללקוחות' של UA או משתתפים בתקופת הניסיון להוצאה משימוש.
ממשק API של גישה לגופנים מקומיים
Chrome משיק את Local Font Access API. אמנם אתרים מאז ומתמיד משתמשים בגופנים מקומיים, אבל ה-API הזה כולל ספירה של רשימת הגופנים המקומיים ונותן גישה לנתוני הגופנים עצמם. הפונקציונליות הזו מאפשרת למשתמשים להשתמש בכל הגופנים שלהם בעיצוב מבוסס-אינטרנט ובאפליקציות אחרות.
גופנים מקומיים ידועים כבר זמן רב בתור וקטור של טביעת אצבע דיגיטלית (fingerprinting). ה-API החדש לא משפר את היכולת להשתמש בגופנים ליצירה של טביעת אצבע דיגיטלית (fingerprinting), אבל Chrome דורש מהמשתמש להעניק לאתר "local-fonts" הרשאה חדשה כדי שיוכל להשתמש ב-Local Font Access API.
בעתיד, אנחנו מתכננים לדרוש שתוענק להם אותה הרשאת "גופנים מקומיים" לפני השימוש ב-API אחר שמספק גישה לגופנים מקומיים.
- ציר זמן: טירגוט ל-Chrome 103 (יוני 22)
- קריאה לפעולה: מידע נוסף על ה-API ואיך משתמשים בו כדי להתחיל להטמיע.
שימוש ב-BFCache עם Cache-control: no-store
זיהינו הזדמנות משמעותית לשפר את התדירות שבה מטמון לדף הקודם/הבא יכול לספק ניווט מיידי לדף הקודם/הבא. כדי לעשות זאת, יש לשנות את אופן הפעולה של BFCache בדפים שמוצגים באמצעות כותרת ה-HTTP Cache-control: no-store HTTP. פיתחנו הצעה ציבורית שמטרתה למנוע הפתעות משמעותיות על ידי מעקב אחר אותות שונים (לדוגמה, הסרת דפים מה-BFCache בכל פעם שמשתנה קובץ cookie מסוג HTTP בלבד), והסרת תכנים (לדוגמה, מדיניות קבוצתית ללקוחות Enterprise/Edu) בהקשרים ייחודיים. זוהי הזדמנות מורכבת אבל מלהיבה, ונשמח לבדוק את המשוב והמשוב שלך.
- ציר הזמן: טירגוט ל-Chrome 104 (ב-22 ביולי), בהנחה שלא יהיו הפתעות גדולות.
- קריאה לפעולה: אפשר לקרוא את ההצעה כדי לקבל פרטים נוספים, כולל איך לאפשר הטמעה תוך כדי עבודה ודרכים לשיתוף משוב, כמו תרחישים אמיתיים שבהם הגישה שלנו תיצור מכשולים חדשים.
באמצעות הסדרה הזו, אני מקווה שנוכל להעניק לקהילת המפתחים שלנו תחושת מיקוד וחיבור, באמצעות קירוב הצוות והעבודה שלהם. אז כדאי להמשיך להתעדכן ולהתעדכן בחדשות נוספות.
עד אז, המשך גלישה נעימה.
מה דעתך על המהדורה הראשונה של Chrome Dev Insider? נשמח לקבל משוב.