איך בוחרים את היעד הבסיסי

Jeremy Wagner

Rachel Andrew

תאריך פרסום: 20 במאי 2025

כשמטמיעים תכונה של פלטפורמת אינטרנט בכל דפדפן, היא הופכת לזמינה ב-Baseline. אחרי 30 חודשים, התכונה הזו הופכת לזמינה באופן נרחב כ-Baseline, שהוא סף שרוב האתרים יכולים להשתמש בתכונות בלי חששות לגבי תאימות. במדריך הזה נסביר איך להשתמש ב-Baseline, ואיך לבחור יעד Baseline באמצעות נתונים שזמינים מהמשתמשים באתר.

מהו יעד בסיסי?

יעד Baseline הוא קבוצה של תכונות אינטרנט שמפתחים יכולים לבחור לתמוך בהן, על סמך סטטוס ה-Baseline שלהן. יש שני סוגים של יעדי בסיס: יעדים משתנים ויעדים קבועים.

יעדים משתנים, כמו 'זמינות בסיסית' או 'זמינות חדשה בסיסית', הם יעדים שבהם קבוצת התכונות עשויה להשתנות עם הזמן. הגדרת יעדים משתנים מתאימה למקרים שבהם רוצים שהתכונות הנתמכות יתעדכנו אוטומטית כשגרסאות חדשות של הדפדפן יפורסמו.

יעדים קבועים הם יעדים שבהם קבוצת התכונות לא משתנה לאורך זמן. בדרך כלל, יעדים קבועים מבוססים על שנים קלנדריות. לדוגמה, Baseline 2023 הוא יעד קבוע שמכיל את קבוצת תכונות האינטרנט שהפכו לזמינות ב-Baseline בשנת 2023. בסיס להשוואה 2023 לא יכלול תכונות שהפכו לבסיס להשוואה אחרי 2023, כלומר קבוצת התכונות של בסיס להשוואה 2023 לא משתנה לעולם.

הגדרת יעדים קבועים מתאימה למקרים שבהם חשובים במיוחד יכולת חיזוי ודטרמיניזם, אבל הם עלולים להתיישן עם הזמן, ולכן מומלץ להעריך מחדש את היעד באופן קבוע.

למה כדאי לבחור יעד?

השימוש בתכונות באינטרנט מוגבל בגלל בעיות תאימות, והדבר מונע מהאינטרנט להיות טוב ככל האפשר. ‫Baseline לא רק מספק הבהרה לגבי השאלה אם דפדפנים תומכים בתכונות מסוימות, אלא גם עוזר להבין מתי אפשר להשתמש בתכונות מסוימות. אם תבחרו יעד שמשקף את הקהל והדרישות שלכם, תוכלו להשתמש בתכונות של קבוצת היעד הזו בביטחון – בלי שתצטרכו לבדוק כל תכונה בנפרד.

שימוש בנתונים לבחירת יעד בסיסי

כדאי לבחור את יעד הבסיס הנכון על סמך נתונים, אם אפשר. כשיש לכם את הנתונים, קל יותר לקבל החלטה מושכלת לגבי קהל היעד שתרצו לבחור.

אם יש לכם נתונים של מעקב אחרי משתמשים אמיתיים באתר, תוכלו לראות איך יעדי הבסיס משתקפים אצל המשתמשים. לדוגמה, אם אתם משתמשים ב-Google Analytics, אפשר להשתמש בכלי לבדיקת נתוני בסיס ב-Google Analytics כדי לקבל את המידע הזה בחינם.

כדי להשתמש בכלי הזה, צריך לאמת את הזהות באמצעות חשבון Google ולאפשר לכלי הרשאת קריאה בלבד כדי להציג את נתוני Google Analytics. משם, בוחרים את נכס Google Analytics שרוצים ליצור עבורו נתוני יעד של נקודת בסיס. אחרי שתשלימו את השלבים האלה, תקבלו פלט שדומה לזה שמופיע כאן:

אנחנו רואים שכלים אחרים מתחילים להטמיע תמיכה ב-Baseline, שיכולה לספק לכם תצוגה דינמית של חלק הקהל שתומך ביעד נתון. לדוגמה, ב-RUMvision יש לוח בקרה שמראה כמה מהקהל שלכם תומך בכל שנה של Baseline.

מה קורה אם לספק הניתוח או ה-RUM שלי עדיין אין דוח של יעדי בסיס?

אם אתם משתמשים בכלי לניתוח נתונים או בכלי RUM שלא מספק עדיין דוח על יעדי בסיס, אבל כן כולל נתונים על גרסאות דפדפן, אתם יכולים לשלב את הנתונים מהעולם האמיתי עם מיפוי של גרסאות הדפדפן מהמודול baseline-browser-mapping. המודול מספק פונקציית JavaScript‏ – getAllVersions() – שממפה דפדפנים לפי שם וגרסה לשנת הבסיס ולסטטוס התמיכה שלהם ב'זמינות נרחבת'. אפשר לספק את המיפויים האלה כמערכים, כאובייקטים עם מפתחות או כקובץ CSV. לדוגמה, המודול הזה משמש את הכלי לבדיקת נקודות בסיס ב-Google Analytics כדי לצרף נתוני Analytics ליעדי נקודת הבסיס.

הפלט של הפונקציה הזו זמין גם כקבצי JSON או CSV שמתארחים ומתעדכנים מדי יום. קובץ all_versions_with_supports.csv מכיל נתונים שאפשר להתאים לנתוני גרסת הדפדפן של ספקי ניתוח הנתונים שלכם באמצעות השדות הבאים:

• ‫browser: שם הדפדפן כפי שמופיע ב-baseline-browser-mapping
• ‫version: גרסת הדפדפן. בדפדפנים מסוימים משתמשים רק במספר גרסה ראשי, ובדפדפנים אחרים משתמשים במספר גרסה major.minor.
• ‫year: קבוצת התכונות של שנת הבסיס שגרסת הדפדפן הזו תומכת בה. אם גרסת דפדפן פורסמה לפני שניתן היה לקבוע את התמיכה ב-Baseline ביולי 2015, השדה הזה יכיל את הערך pre_baseline
• ‫supports: השדה הזה מכיל את הערך widely או newly לגרסאות דפדפן שתומכות בקבוצות התכונות האלה, והוא ריק לגרסאות שלא תומכות באף אחת מקבוצות התכונות האלה. כל גרסאות הדפדפנים שתומכות ב'זמינות חדשה' תומכות גם ב'זמינות רחבה'.
• release_date: התאריך שבו הגרסה הזו של הדפדפן פורסמה, אם יש כזה.
• ‫engine: שם המנוע לדפדפנים שנמצאים במורד הזרם של דפדפן בסיסי. הדפדפנים שכלולים הם רק דפדפנים שמבוססים על Blink, אבל יכול להיות שבעתיד יתווספו דפדפנים שמבוססים על מנועי דפדפן אחרים.
• ‫engine_version: גרסת Chromium שמוטמעת בגרסת הדפדפן הזו. המידע הזה משמש כדי לקבוע אילו תכונות בסיסיות נתמכות בגרסה שלמטה.

הקובץ הזה מתעדכן לעיתים קרובות כשיש גרסאות חדשות של דפדפנים, וכשסטטוס התמיכה בדפדפנים שונים משתנה. חשוב לרענן את הנתונים מדי יום.

מה קורה אם אין לי נתוני תמיכה ממשתמשים אמיתיים?

יכול להיות שתיתקלו במצב שבו לא תוכלו לקבל נתונים אמיתיים של משתמשים לגבי תכונות שהן Baseline. החדשות הטובות הן שאפשר לקבל מושג כללי לגבי התמיכה ביעדים שונים של Baseline באמצעות RUM Archive Insights, ואפילו לסנן לפי מדינה. הנתונים האלה לא יהיו ספציפיים למשתמשים באתר שלכם. זהו כלי מידע כללי שמראה שההנחות הבאות הן בדרך כלל בטוחות:

• יעדי בסיס חדשים יותר – כמו השנה הנוכחית או השנה הקודמת – סביר להניח שיקבלו את הכי פחות תמיכה בקרב המשתמשים שלכם. עם זאת, כמו כל יעד של Baseline, התמיכה בהם תשתפר ככל שיעבור הזמן.
• תהיה תמיכה טובה ביעדים בסיסיים ישנים יותר, במיוחד ביעד 'זמינות נרחבת'. אם אתם לא בטוחים, 'זמינות נרחבת' היא יעד מצוין שמשתנה ככל שהחלון של 30 חודשים מתקדם בזמן.
• גם יעדים ישנים יותר של Baseline – כאלה שחלפו הרבה יותר מ-30 חודשים מאז שהם היו זמינים באופן נרחב – יקבלו את התמיכה הטובה ביותר. אמנם 'זמינות נרחבת' הוא יעד ברירת מחדל טוב, אבל יש תרחישי שימוש מיוחדים שבהם נדרשים הסכמי רמת שירות (SLA) מחמירים.

גם אם תבחרו יעד בסיסי שגילו יותר מחמש שנים, סביר להניח שתוכלו להשתמש בתכונות שאתם לא משתמשים בהן כרגע. במקרה הטוב, יכול להיות שאתם כבר משתמשים בתכונות האלה, אבל עם polyfills שאולי לא נחוצים לכם.

איך אוכפים יעד בסיסי שנבחר בפרויקט?

‫Browserslist היא שיטה נפוצה לטירגוט הדפדפנים שרוצים לתמוך בהם. הוא משמש בחבילות ובכלים משויכים אחרים כמו Babel ו-PostCSS כדי להחליט אם צריך לבצע טרנספורמציה של קטעי קוד מסוימים או אפילו להוסיף להם polyfill.

עכשיו אפשר להשתמש ב-Baseline עם Browserslist, כך שאם בוחרים יעד Baseline, אפשר לציין אותו כשאילתת Browserslist תקינה. כך תוכלו לוודא שהכלים בפרויקט ישנו את הקוד בהתאם ליעד שבחרתם. מידע נוסף זמין במאמר בנושא שימוש ב-Baseline עם Browserslist.

מה קורה לגבי תכונות שלא עומדות ביעד של תצורת הבסיס?

אחרי שבוחרים יעד בסיסי, יכול להיות שיהיו תכונות שרוצים להשתמש בהן אבל הן לא נכללות ביעד הזה. המאמר הזה לא מסביר מה צריך לעשות, וההחלטה אם להשתמש בתכונות האלה תלויה בסוג האתר שאתם בונים ובקהל הצפוי.

לדוגמה, אתרים של מסחר אלקטרוני או B2B עשויים להסכים לסף תמיכה נמוך יותר ולטפל בבעיות כשהמשתמשים תומכים בהם, בעוד שאתרים ממשלתיים עשויים לדרוש סף תמיכה גבוה. כלל חשוב שכדאי לזכור הוא שלא כל התכונות באינטרנט נכשלות באותו אופן. יש הרבה דרכים לסווג תכונות לפי אופן הכשל שלהן, אבל דרך אחת לסווג תכונות שעשויה להיות שימושית היא כזו:

• שיפור: אם משתמשים בתכונה בדפדפן שלא נתמך, חוויית השימוש לא נפגעת. יכול להיות שהחוויה תהיה פחות טובה, אבל סביר להניח שהמשתמש לא יבחין בכך. דוגמה: loading="lazy".
• תוספת: התכונה מספקת יתרונות נוספים שאפשר להבחין בהם – כמו שינויים בסגנון הדף או בפונקציונליות מסוימת. יכול להיות שהמשתמשים לא יבחינו בהבדל אם התכונה לא נתמכת, אלא אם הם יבצעו השוואה בדפדפן שכן תומך בה. דוגמה: Subgrid
• קריטי: אם התכונה לא נתמכת, חוויית המשתמש תהיה שלילית – יכול להיות שאפילו לא תהיה אפשרות להשתמש בתכונה בכלל. דוגמה: File System Access API משמש כתכונה מרכזית והכרחית.

יכול להיות גם שתגלו שתכונות מסוימות מחוץ ליעד שלכם נתמכות טוב יותר ממה שחשבתם. אפשר להבין כמה מהמשתמשים תומכים בתכונה מסוימת. באתר Can I Use אפשר לבדוק את התמיכה בתכונות ספציפיות בהשוואה לנתוני הניתוח שלכם. בנוסף, אם זה יעזור לכם, תוכלו להשתמש ב-RUMvision כדי להתעמק בנתונים ברמת התכונה.

כך תוכלו להשתמש ביעד הבסיסי כדי לצמצם את מספר התכונות שצריך לבחון בקפידה. לא צריך לדאוג לגבי כל מה שנמצא בתוך היעד. אם יש תכונה אחת או שתיים מחוץ ליעד שלכם שיהיו שימושיות במיוחד, יש לכם את הכלים להמשיך לחקור ולהחליט אם להשתמש ב-polyfill או להשתמש בהן כשיפור הדרגתי (progressive enhancement).

סיכום

לכל אפליקציית אינטרנט יש דרישות שונות – מאתר מסחר אלקטרוני שיכול לסבול יותר בעיות של חוסר תאימות, ועד לאתר ממשלתי שחייב להיות זמין ופעיל לכמה שיותר משתמשים. אלה חישובים שצריך לבצע לבד, והמטרה של Baseline היא לא להגיד לכם מה לעשות כשמטמיעים תכונות חדשות באתר, אלא יותר איך לעשות את זה.