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