פורסם: 20 במאי 2025
כשמטמיעים תכונה של פלטפורמת אינטרנט בכל דפדפן, היא הופכת לזמינה ב-Baseline. אחרי 30 חודשים, התכונה הזו הופכת לזמינה באופן נרחב כ-Baseline, שהוא סף שרוב האתרים יכולים להשתמש בתכונות בלי לדאוג לגבי תאימות. במדריך הזה נסביר איך להשתמש בתכונה 'בסיס להשוואה', ואיך לבחור יעד להשוואה באמצעות נתונים שזמינים לגבי המשתמשים באתר.
מהו יעד בסיסי?
יעד בסיסי הוא קבוצה של תכונות אינטרנט שמפתחים יכולים לבחור לתמוך בהן, על סמך סטטוס הבסיס שלהן. יש שני סוגים של יעדי בסיס: יעדים משתנים ויעדים קבועים.
יעדים משתנים, כמו 'תכונות בסיסיות שזמינות לכולם' או 'תכונות בסיסיות שזמינות לכולם', הם יעדים שבהם קבוצת התכונות עשויה להשתנות עם הזמן. הגדרת יעדים משתנים מתאימה למקרים שבהם רוצים שהתכונות הנתמכות יתעדכנו אוטומטית כשגרסאות חדשות של הדפדפן יפורסמו.
יעדים קבועים הם יעדים שבהם קבוצת התכונות לא משתנה לאורך זמן. באופן כללי, יעדים קבועים מבוססים על שנים קלנדריות. לדוגמה, Baseline 2023 הוא יעד קבוע שמכיל את קבוצת תכונות האינטרנט שהפכו לזמינות ב-Baseline בשנת 2023. בסיס להשוואה 2023 לא יכלול תכונות שהפכו לבסיס להשוואה אחרי 2023, כלומר קבוצת התכונות של בסיס להשוואה 2023 לא משתנה אף פעם.
הגדרת יעדים קבועים מתאימה למקרים שבהם חשובים במיוחד יכולת חיזוי ודטרמיניזם, אבל הם עלולים להתיישן עם הזמן, ולכן מומלץ להעריך מחדש את היעד באופן קבוע.
למה כדאי לבחור יעד?
השימוש בתכונות באינטרנט מוגבל בגלל בעיות תאימות – והדבר הזה מונע מהאינטרנט להיות טוב ככל האפשר. התכונה Baseline לא רק מספקת תשובה ברורה לשאלה אם דפדפנים תומכים בתכונות מסוימות, אלא גם עוזרת להבין מתי אפשר להשתמש בתכונות מסוימות. אם תבחרו יעד שמשקף את הקהל והדרישות שלכם, תוכלו להשתמש בתכונות של קבוצת היעד הזו בביטחון – בלי שתצטרכו לבדוק כל תכונה בנפרד.
שימוש בנתונים כדי לבחור את יעד הבסיס
כדאי לבחור את יעד הבסיס הנכון על סמך נתונים, אם אפשר. אחרי שרואים את הנתונים, קל יותר לקבל החלטה מושכלת לגבי קהל היעד שרוצים לבחור.
אם יש לכם נתונים של מעקב אחרי משתמשים אמיתיים באתר, תוכלו לראות איך יעדי הבסיס משתקפים אצל המשתמשים. לדוגמה, אם אתם משתמשים ב-Google Analytics, אפשר להשתמש בכלי לבדיקת נתוני בסיס של Google Analytics כדי לקבל את המידע הזה בחינם.
כדי להשתמש בו, תצטרכו ליצור ניתוח חדש ב-Google Analytics, להוסיף כמה מדדים ומאפיינים לדוח ולייצא את הדוח כקובץ TSV. ההוראות האלה מסבירות את התהליך בפירוט. כשמייבאים את קובץ ה-TSV לכלי הבדיקה, אמור להתקבל פלט שנראה כך:
אנחנו רואים שכלים אחרים מתחילים להטמיע תמיכה בנתוני קו בסיס, שיכולים לספק לכם תצוגה דינמית של חלק הקהל שתומך ביעד נתון. לדוגמה, ב-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. החדשות הטובות הן שאפשר לקבל מושג כללי לגבי התמיכה ביעדי בסיס שונים באמצעות תובנות מארכיון RUM, ואפילו לסנן לפי מדינה. הנתונים האלה לא יהיו ספציפיים למשתמשים באתר שלכם. זהו כלי מידע כללי שמראה שההנחות הבאות הן בדרך כלל בטוחות:
- יעדי בסיס חדשים יותר – כמו השנה הנוכחית או השנה הקודמת – צפויים לקבל את הכי פחות תמיכה בקרב המשתמשים שלכם. עם זאת, כמו כל יעד בסיסי, התמיכה בהם תשתפר ככל שיעבור הזמן.
- תהיה תמיכה טובה ביעדים בסיסיים ישנים יותר, במיוחד ביעד 'בסיסי וזמין לכולם'. אם לא בטוחים, כדאי לבחור בטירגוט 'זמין באופן נרחב', שמשתנה לאורך הזמן בהתאם לחלון של 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 או להשתמש בהן כשיפור מתקדם.
סיכום
לכל אפליקציית אינטרנט יש דרישות שונות – מאתר מסחר אלקטרוני שיכול לסבול יותר בעיות של חוסר תאימות, ועד לאתר ממשלתי שחייב להיות זמין ופעיל לכמה שיותר משתמשים. אלה חישובים שאתם צריכים לבצע בעצמכם, והמטרה של Baseline היא לא להגיד לכם אילו החלטות לקבל כשמטמיעים תכונות חדשות לאתרים, אלא יותר איך לעשות את זה.