תאריך פרסום: 7 בנובמבר 2025
ניהול תאימות דפדפנים עבור יותר מ-38,000 לקוחות ארגוניים ביפן הוא לא דבר פשוט. כש-Kintone מפעיל יותר מ-1.5 מיליון אפליקציות מדי יום, כל החלטה לגבי תמיכה בדפדפן חשובה.
Cybozu, חברה מובילה ביפן בתחום תוכנות קבוצתיות, התמודדה עם אתגר מהותי: איך לשמור על סטנדרטים עקביים של אינטרנט בכל המוצרים שלה, בלי לשאת בנטל התחזוקה של מטריצות תמיכה בדפדפנים בהתאמה אישית.
הפתרון? אימוץ Baseline כסטנדרט פיתוח – מהלך ששינה את הגישה שלהם לאימוץ תכונות של פלטפורמת אינטרנט.
האתגר: תמיכה בדפדפן בלי ניחושים
לפני Baseline, חברת Cybozu שמרה על קריטריונים משלה לתמיכה בדפדפנים על סמך יומני גישה ומעקב ידני אחר גרסאות. הסטנדרט שלהם היה לתמוך בדפדפנים שכיסו את 98% מיומני הגישה – ולמשתמשים בדפדפנים שלא עמדו בסף הזה הוצגה הנחיה לעדכן את הדפדפן.
בכל רבעון, צוותי ההנדסה של Cybozu משקיעים בערך שעה בסך הכול בעדכוני קריטריונים. עם זאת, השילוב של הקריטריונים עם צוות הפיתוח לא היה חלק, והיו הרבה שאלות: מתי אפשר להשתמש בתכונות חדשות של CSS? מתי אפשר להסיר רכיבי Polyfill עבור ממשקי API חדשים של JavaScript? אילו תכונות אפשר להשתמש בהן עכשיו?
הקריטריונים המותאמים אישית של Cybozu לא היו רק קשים לתחזוקה ולשימוש עבור מפתחים, אלא גם לא יכלו לעמוד בקצב של התפתחות האינטרנט המודרני, כי הם התבססו על זיהוי של סוכן משתמש ומעקב ידני אחרי גרסאות.
האם אפשר להסתמך על המחרוזת User-Agent
הגישה הקודמת של Cybozu הייתה להפיק שמות וגרסאות של דפדפנים ממחרוזות User-Agent, ואז לצבור את התוצאות האלה כנתוני 'משתמשים'. אבל האם זה באמת משקף את המציאות של המשתמשים?
User-Agent היא כותרת של בקשת HTTP – מידע שכל לקוח יכול לטעון שהוא כל דבר. יומני הגישה למוצרים מכילים נפחים עצומים של בקשות מבוטים, מסורקים, מתוקפים וממקורות אחרים. לקוחות מסוימים שולחים בכוונה מחרוזות ישנות של User-Agent למטרות שונות, כמו סריקת פגיעויות. לכן, יומני הגישה לא יכולים לייצג את המשתמשים שצריך לתמוך בהם.
ה-User-Agent לא יכול לשקף את התכונות הזמינות
גרסאות הדפדפן לא ממופות לתכונות. יכול להיות שלגרסה עם אותו מספר יהיו יכולות שונות בהתאם לערוץ (יציב/בטא/פיתוח/Canary), דגלי תכונות, ניסויים של Finch או מדיניות ארגונית, למשל. בנוסף, דפדפנים שונים מטמיעים תכונות בלוחות זמנים שונים – CSS Nesting הושק ב-Safari 16.5 (מאי 2023) אבל ב-Chrome 112 (אפריל 2023). המחרוזת User-Agent לא מציינת את הזמינות של התכונה.
האחריות שלנו לתמוך בגרסאות של דפדפנים
עדכוני דפדפן לא כוללים רק תכונות חדשות – גרסאות דפדפן רגילות כוללות תיקוני באגים ותיקוני אבטחה קריטיים לצד יכולות חדשות. כשגרסאות מיושנות נתמכות, הבעיה היא לא רק הימנעות משימוש בתכונות חדשות – זו החלטה שמשפיעה ישירות על בטיחות המשתמשים. בסביבות ארגוניות, חלק מהמשתמשים עלולים להיתקל במגבלות לגיטימיות. לדוגמה:
- יכול להיות שבאירגונים יש מדיניות דפדפן מחמירה שמונעת עדכונים.
- חומרה מדור קודם לא תומכת בעדכון דפדפנים מודרניים.
- משתמשים בתעשיות מפוקחות עם תהליכי אישור שינויים איטיים.
עם זאת, תמיכה במשתמשים האלה גם מאפשרת להם להישאר פגיעים.
אם תקרית אבטחה התרחשה כתוצאה מניצול של פגיעות מוכרת בגרסה ישנה של דפדפן, לא יהיה זה הסבר סביר לומר "הדפדפן הזה נתמך כי המשתמשים ביקשו זאת". אם המתקפה מתפשטת למשתמשים אחרים שמקפידים לעדכן את הדפדפנים שלהם, האחריות לכך שדפדפנים לא בטוחים לא נתמכים מוטלת על המפתחים ועל בעלי עניין אחרים בפרויקט.
חברת Cybozu הבינה שהגישה הזו יוצרת סיכונים לרוב המשתמשים שמקפידים לעדכן את הדפדפנים שלהם. הסתמכות על מספרים ביומן כדי לתמוך בדפדפנים לא מספקת אימות אבטחה מתאים. זה לא רק עניין של פספוס תכונות חדשות – זה עניין של כשל באחריות להגנה על המשתמשים.
השאלה משתנה מ "כמה משתמשים משתמשים בגרסה הזו?" ל "האם אנחנו צריכים לתמוך במשתמשים על סמך גרסאות הדפדפן בכלל?"
למה Baseline היא התשובה הנכונה ל-Cybozu
חברת Cybozu הייתה צריכה גישה חדשה שתתייחס לא רק להוצאות התפעוליות של שמירה על קריטריונים לתמיכה בדפדפן, אלא גם לפגמים הבסיסיים במתודולוגיה הישנה. Baseline סיפק ל-Cybozu בדיוק את זה.
קריטריונים שמתעדכנים ומתפתחים באופן חיצוני
במקום להעריך מחדש באופן ידני את גרסאות הדפדפן בכל רבעון, Baseline מספק יעד משתנה שמתוחזק על ידי קבוצת הקהילה WebDX של W3C – ולא על ידי חברות בודדות שמקבלות החלטות שרירותיות. כלומר, הקריטריונים מתפתחים באופן אוטומטי בהתאם לנתונים שמתקבלים מספקי דפדפנים ומגופי תקנים.
לא היה יותר צורך ב-Kintone כדי לנהל את ספי הגרסה בעצמו – הגרסה הבסיסית מתעדכנת בלי שום פעולה. הסטטוס של התכונות ב-Baseline מספק תשובות חד-משמעיות לשאלות לגבי הזמינות, והתשובות מתעדכנות ככל שהפלטפורמה מתפתחת.
דיוק ברמת התכונה
במקום לנסות לעקוב אחרי המצב של דפדפן ספציפי, Baseline נוקט גישה שונה באופן מהותי.
המונח Baseline Widely available (זמינות בסיסית) מייצג תכונות אינטרנט שזמינות במשך 30 חודשים או יותר בדפדפנים מובילים. המסגרת הזו נקבעה כדי "לספק קירוב לאותות של מפתחים, לשימוש בגרסאות של דפדפנים לאורך זמן, לאמוד את התמיכה בנתח שוק כולל גבוה ולשקף את ההערכה הטובה ביותר של קבוצת הקהילה WebDX". הגדרת סף כזה מאפשרת ל-Baseline לבטל את הצורך במעקב אחרי מצבים לא ניתנים לצפייה בדפדפן.
עם Baseline, מפתחים מקבלים תשובה ישירה לגבי הזמינות של התכונה הספציפית הזו בדפדפנים שונים. עכשיו אפשר לקבל תשובה לשאלה 'האם אפשר להשתמש בשאילתות של מאגרי CSS?'. מפתחים יכולים לבדוק את סטטוס הבסיס ב-MDN או במסמכים אחרים באופן מיידי, בלי להשוות עם מטריצות תאימות.
אבטחה במרכז
כדי להתאים את מדיניות התמיכה שלנו לפרק הזמן שקשור באופן טבעי למחזורי החיים של התמיכה של ספקי דפדפנים, אימצנו את Baseline Widely available כסטנדרט שלנו. דפדפנים שעדיין מתבצעת בהם תחזוקה פעילה יתמכו בכל התכונות שזמינות לכולם, וגם יקבלו עדכוני אבטחה קריטיים.
לקריטריונים שמבוססים על יומן גישה יש פוטנציאל להצמיד את התמיכה לדפדפנים מיושנים, וכך לבטל את התמריץ של המשתמשים לעדכן. השימוש ב-Baseline מאפשר לנו להשתמש בביטחון בתכונות מודרניות, וגם גורם למשתמשים בדפדפנים מיושנים להבין שהם צריכים לעדכן את הדפדפן שלהם ככל שהפלטפורמה של האינטרנט מתקדמת.
ההגדרה 'בסיסית' לא שוללת באופן מפורש דפדפנים פגיעים – היא מספקת תמריצים טבעיים למשתמשים לעדכן את הדפדפנים שלהם.
אימוץ של Baseline
המעבר ל-Baseline דרש שינוי מניהול הגרסאות מדור קודם של Cybozu. לכן, חברת Cybozu הייתה צריכה להיות בטוחה ש-Baseline תפעל בלי חסרונות משמעותיים. הידיעה מהו אחוז המשתמשים שיושפעו מהשינוי הייתה חיונית לאימוץ ברמת הארגון.
Google Analytics Baseline Checker הוא כלי שמנתח נתונים שמיוצאים מ-Google Analytics כדי להציג את אחוז המשתמשים שתומכים בתכונות מכל שנה של Baseline. הכלי הזה עזר ל-Cybozu לבדוק את ההשפעה בפועל של בחירת יעד בסיסי על המשתמשים שלהם. אחרי הפעלת הכלי לבדיקת תאימות, חברת Cybozu גילתה משהו יוצא דופן:
כלי הבדיקה של תצורת הבסיס חשף ש-98.8% מהמשתמשים של Cybozu השתמשו בדפדפנים שתומכים ביעד של תצורת הבסיס שזמינה באופן נרחב. הכיסוי הזה רחב יותר מהתקן הפנימי הקודם של Cybozu, שהיה לפחות 98% מהמשתמשים. אפשר לנתח שלוש נקודות עיקריות על סמך הנתונים שסופקו:
- דפדפנים שנתמכו בעבר לא יושפעו.
- דפדפנים שלא נתמכו בעבר: מייצגים כ-0.8% מהדפדפנים שעומדים בקריטריונים של Baseline Widely available, אבל כבר לא רואים את ההצעה לעדכון הדפדפן.
- בדפדפנים הנותרים, ההנחיה לעדכון הדפדפן תמשיך להופיע כמו קודם.
המשמעות היא שאפשר היה לבטל את התוצאות החיוביות השגויות – כ-0.8% מהמשתמשים שהוצגו להם אזהרות שלא לצורך, למרות שהם השתמשו בדפדפנים מתאימים. במקביל, לא יכול להיות שיוצגו תוצאות שליליות שגויות למשתמשים שנתמכו בעבר.
בעזרת הנתונים האלה, חברת Cybozu יכלה לאמץ בביטחון את הבסיס הזמין באופן נרחב כיעד.
ההשפעה של נתוני הבסיס בפועל
הטמעה של Baseline כמדיניות הייתה דבר אחד, אבל כדי להפוך אותה למבצעית היה צריך לבנות כלים ותהליכים. היה חשוב לוודא שמפתחים לא יוכלו להשתמש בטעות בתכונות לא נתמכות בלי לבדוק ידנית את סטטוס הבסיס.
ניתוח סטטי שמבוסס על הגדרת ESLint
@cybozu/eslint-config הוא קובץ הגדרה מבוסס-OSS שמשמש במוצרי Cybozu. התמיכה החלה עם ההגדרה הקבועה מראש css-baseline שבודקת את תכונות ה-CSS מול Baseline בזמן הבנייה:
// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';
export default [
...cybozuEslintConfigBaseline.map((config) => ({
...config,
files: ['**/*.css']
})),
];
כשמפתחים משתמשים בתכונות שעדיין לא זמינות באופן נרחב ב-Baseline, הם מקבלים משוב מיידי מ-ESLint:
כך אפשר למנוע בעיות תאימות בייצור. מפתחים יכולים לקבל החלטות מושכלות בשלב מוקדם בתהליך הפיתוח: הם יכולים לחכות שהתכונה תהיה זמינה לכולם, או להטמיע שיפורים הדרגתיים כשהם יודעים בדיוק אילו משתמשים יושפעו. (מידע נוסף על התמיכה של ESLint ב-CSS וב-Baseline)
הגדרת קומפיילרים לטירגוט של Baseline Widely available
כלי בנייה מודרניים התחילו לתמוך ב-Baseline כיעד. לדוגמה, Vite מכוון אוטומטית ל-Baseline Widely Available בייצור ללא הגדרה נוספת. הכלי Browserslist תומך עכשיו גם ב-Baseline.
שימוש בהגדרות שונות של קומפיילר מבטיח שה-JavaScript וה-CSS שלנו יעברו טרנספילציה רק כשצריך, וכך נמנעות טרנספורמציות ורכיבי Polyfill מיותרים לתכונות שכבר נתמכות באופן נרחב.
ביטול התחזוקה הידנית של הקריטריונים ומערכת זיהוי הדפדפן לקבלת משוב מהמשתמשים
היתרון הכי גדול של התחזוקה הוא ביטול הצורך במעקב ידני אחרי גרסאות הדפדפן. במקום לקיים פגישות רבעוניות כדי לדון באילו גרסאות של דפדפנים כדאי לתמוך, ב-Cybozu מסתמכים עכשיו על חבילת @web-platform-dx/baseline-browser-mapping שמתעדכנת באופן פתוח כדי לקבל תשובות לשאלות האלה.
בנוסף, חברת Cybozu יצרה זיהוי אוטומטי של דפדפנים כדי להציג למשתמשים בדפדפנים מיושנים הנחיות לשדרוג.
הזיהוי של הדפדפן מאחזר גרסאות דפדפן תואמות ישירות מחבילת @web-platform-dx/baseline-browser-mapping.
הבדיקה הזו מופעלת במהלך תהליך הבנייה שלנו, והיא יוצרת באנרים עם אזהרות שמשותפים לכל צוותי המוצרים. ככל שחלון הזמינות של Baseline מתרחב וכולל דפדפנים חדשים יותר, המערכת שלנו מזהה את השינויים באופן אוטומטי, ללא צורך בהתערבות ידנית.
תקשורת יעילה
אחד היתרונות המשמעותיים ביותר, והבלתי צפויים, היה האופן שבו Baseline פישט את התקשורת בין הצוותים. בעבר, כדי לדון בתאימות לדפדפנים היה צריך ידע ספציפי בדומיין של החברה – אילו דפדפנים אנחנו תומכים, אילו גרסאות ואילו תכונות זמינות עכשיו. עובדים חדשים צריכים זמן כדי ללמוד את הסטנדרטים הפנימיים שלנו. עם Baseline, אנחנו מתייחסים עכשיו לאותם קריטריונים של תאימות שמוכרים בקהילת האינטרנט.
בנוסף, אנחנו יוצרים אוצר מילים משותף בקרב צוותי ההנדסה שלנו וקהילת האינטרנט הרחבה. כשדנים בהטמעה של תכונות, כולם מתייחסים לאותם נתונים מאותו מקור, כך שאין צורך להסביר מדיניות פנימית או לתרגם בין מסגרות תאימות שונות.
גם כלי הפיתוח התעדכנו: עכשיו מוצג מידע על תאימות בסיסית ישירות ב-Visual Studio Code ובחלונית Style בכלי הפיתוח ל-Chrome. מפתחים כבר לא צריכים לבדוק כל הזמן ב-MDN או ב-Can I use כדי לוודא שאפשר להשתמש בתכונה מסוימת. הם מקבלים את המידע הזה באופן מיידי מהכלי.
המוצר פועל לטובת כולם
בעזרת Baseline, יכולנו לשנות מהיסוד את הגישה שלנו לתאימות דפדפנים – ממטלה שאנחנו מנהלים לבסיס שאנחנו סומכים עליו. אסטרטגיית ההטמעה שלנו התמקדה באוטומציה בכל שלב:
- משוב בזמן הפיתוח: ניתוח סטטי וכרטיס סטטוס של קו בסיס.
- אימות בזמן בנייה: טרנספיילרים מכוונים אוטומטית ל-Baseline Widely available.
- זיהוי בזמן ריצה: אזהרות שמוצגות למשתמשים בדפדפנים לא נתמכים באמצעות
baseline-browser-mapping. - עדכונים רציפים: סנכרון אוטומטי עם נתוני הבסיס מבטל את הצורך בתחזוקה ידנית.
התוצאות מדברות בעד עצמן:
- אפס שעות שהוקדשו לתחזוקת גרסת הדפדפן.
- כיסוי של יותר מ-98.8% מהמשתמשים נשמר ברמת ודאות של התכונה.
- תשובות מיידיות וספונטניות לשאלות נפוצות, שעונות על השאלה "האם אפשר להשתמש בתכונה הזו בגרסה הזו של הדפדפן?"
- לקסיקון משותף לכל צוותי ההנדסה.
- דרך ברורה יותר לאימוץ תכונות – הנחיות לצוותים לגבי שילוב של תכונות חדשות ותזמון ההסרה של polyfills, אם יש צורך.
לארגונים ששוקלים להשתמש ב-Baseline, חשוב לדעת איך המעבר ישפיע על המשתמשים. כלים כמו Google Analytics Baseline Checker הופכים את המדידה הזו לפשוטה יותר ומספקים הסברים. אחרי שתהיו בטוחים בנתונים ותחליטו להשתמש ב-Baseline, תוכלו להשתמש במערכת האקולוגית המתפתחת של Baseline כדי לארגן את תהליך הפיתוח.
פלטפורמת האינטרנט חזקה יותר, עקבית יותר, אמינה יותר ומתפתחת מהר יותר מבעבר. בעזרת Baseline, אנחנו יכולים לרתום את הכוח הזה בסביבת הייצור בביטחון.
משאבים
- מאמר מקורי ביפנית: プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
- הגדרת Cybozu ESLint:
@cybozu/eslint-configב-GitHub - כלי לבדיקת נתוני בסיס ב-Google Analytics: כלי לבדיקת נתוני בסיס ב-Google Analytics
- מיפוי בסיסי של דפדפנים:
@web-platform-dx/baseline-browser-mapping - מידע על Baseline: Baseline ב-MDN