תאריך פרסום: 20 במאי 2025
כשתכונה של פלטפורמת אינטרנט מיושמת בכל הדפדפנים, היא הופכת ל'בסיסית – זמינה עכשיו'. אחרי 30 חודשים, התכונה הזו תהיה זמינה לרוב האתרים ללא בעיות תאימות. במדריך הזה נסביר איך משתמשים ב-Baseline, ואיך בוחרים יעד Baseline על סמך נתונים שזמינים ממשתמשי האתר.
מהו יעד בסיס?
יעד בסיס הוא קיבוץ של תכונות אינטרנט שמפתחים יכולים לבחור לתמוך בהן, על סמך סטטוס הבסיס שלהן. יש שני סוגים של יעדי בסיס: יעדים נעים ויעדים קבועים.
יעדים דינמיים, כמו 'בסיס זמין באופן נרחב' או 'בסיס זמין לאחרונה', הם יעדים שבהם קבוצת התכונות עשויה להשתנות עם הזמן. כדאי להגדיר יעדי טירגוט דינמיים במקרים שבהם רוצים שקבוצת התכונות הנתמכות תתפתח באופן אוטומטי כשגרסאות חדשות של הדפדפן יושקו.
יעדים קבועים הם יעדים שבהם קבוצת התכונות לא משתנה לאורך זמן. באופן כללי, יעדים קבועים מבוססים על שנות קלנדריות. לדוגמה, בסיס להשוואה 2023 הוא יעד קבוע שמכיל את קבוצת תכונות האינטרנט שהפכו ל'בסיס להשוואה: תכונות חדשות שזמינות' בשנת 2023. בסיס להשוואה 2023 לא יכלול תכונות שהפכו לבסיס להשוואה אחרי 2023, כלומר קבוצת התכונות של בסיס להשוואה 2023 לא משתנה אף פעם.
כדאי להשתמש ביעדים קבועים במקרים שבהם היכולת לחזות את התוצאות והקביעות הן בראש סדר העדיפויות, אבל הם עלולים להיות לא עדכניים לאורך זמן. לכן, כשמשתמשים ביעדים קבועים, מומלץ לבדוק מחדש את היעד באופן קבוע.
למה כדאי לבחור יעד?
אימוץ התכונות באינטרנט מושהה בגלל חששות לגבי תאימות, וזה מונע מהאינטרנט להיות טוב ככל האפשר. קו הבסיס לא רק מבהיר את השאלה לגבי תמיכה בתכונות בדפדפנים, אלא גם עוזר להבין מתי אפשר להשתמש בתכונות מסוימות. אם תבחרו יעד שמשקף את הקהל ואת הדרישות שלכם, תוכלו להשתמש בבטחה בתכונות בתוך קבוצת היעד הזו – בלי שתצטרכו לבדוק כל תכונה בנפרד.
שימוש בנתונים כדי לבחור את היעד של ערך הבסיס
אם אפשר, כדאי לבחור את יעד הבסיס הנכון על סמך נתונים. כשהנתונים מוצגים בפניכם, קל יותר לקבל החלטה מושכלת יותר לגבי היעד שתרצו לבחור.
אם יש לכם נתונים של מעקב אחר משתמשים אמיתיים באתר, תוכלו לבדוק איך היעדים הבסיסיים ממופה למשתמשים שלכם. לדוגמה, אם אתם משתמשים ב-Google Analytics, אתם יכולים לקבל את המידע הזה בחינם באמצעות כלי לבדיקת נתוני הבסיס של Google Analytics.
כדי להשתמש בו, צריך ליצור ניתוח חדש ב-Google Analytics, להוסיף כמה מדדים ומאפיינים לדוח ולייצא את הדוח כקובץ TSV. כאן מפורטות ההוראות. כשמייבאים את קובץ ה-TSV לבקר, הפלט אמור להיראות כך:
אנחנו מתחילים לראות כלים אחרים שמטמיעים תמיכה ב-Baseline, שיכולים לספק לכם תצוגה דינמית של אחוז הקהל שתומך ביעד נתון. לדוגמה, RUMvision כולל מרכז בקרה שבו מוצגת אחוזית הקהל שיש לו תמיכה בכל שנה בסיסית.
מה קורה אם אין לי נתוני תמיכה ממשתמשים אמיתיים?
יכול להיות שתגיעו למצב שבו לא תוכלו לקבל נתוני משתמשים אמיתיים לגבי תכונות ששייכות ל-Baseline. החדשות הטובות הן שאפשר לקבל מושג כללי לגבי התמיכה ביעדים שונים של Baseline דרך תובנות מהארכיון של RUM, ואפילו לסנן עד לרמת המדינה. הנתונים האלה לא יהיו ספציפיים למשתמשים באתר שלכם. זהו כלי מידע כללי שמראה שההנחות הבאות בדרך כלל בטוחות:
- סביר להניח שהיעדים החדשים יותר של קו הבסיס – כמו השנה הנוכחית או השנה הקודמת – יקבלו את מידת התמיכה הנמוכה ביותר בקרב המשתמשים שלכם. עם זאת, כמו כל יעד בסיס, התמיכה בהם תשתפר עם הזמן.
- יהיה תמיכה רבה ביעדים ישנים יותר של Baseline, במיוחד ב-Baseline Widely available. אם אתם לא בטוחים, היעד 'זמין באופן נרחב' הוא יעד מצוין שמשתנה ככל שהחלון של 30 החודשים מתקדם.
- גם ליעדים ישנים יותר של Baseline – יעדים שנמצאים הרבה מעבר לחלון של 30 החודשים של 'זמין באופן נרחב' – תהיה התמיכה הטובה ביותר. 'זמין ברחבי העולם' הוא יעד ברירת מחדל טוב, אבל הוא לא מתאים לתרחישים מיוחדים לדוגמה שבהם נדרשים הסכמי רמת שירות מחמירים.
סביר להניח שגם אם בוחרים יעד בסיס שנוצר לפני יותר מחמש שנים, אפשר להשתמש בתכונות שלא משתמשים בהן כרגע. בתרחיש הטוב ביותר, יכול להיות שכבר אתם משתמשים בתכונות האלה, אבל עם polyfills שאולי לא תצטרכו.
איך אוכפים יעד בסיס שנבחר בפרויקט?
Browserslist היא שיטה נפוצה לטירגוט הדפדפנים שבהם רוצים לתמוך. הוא משמש ב-bundlers ובכלים משויכים אחרים, כמו Babel ו-PostCSS, כדי להחליט אם צריך לשנות קטעי קוד מסוימים או אפילו לבצע להם פוליפיל.
עכשיו אפשר להשתמש ב-Baseline עם Browserslist, כך שכאשר בוחרים יעד Baseline, אפשר לציין אותו כשאילתה תקפה ב-Browserslist. כך מוודאים שהכלים בפרויקט יעבירו את הקוד בהתאם ליעד שבחרתם. מידע נוסף זמין במאמר שימוש ב-Baseline עם Browserslist.
מה קורה אם תכונות מסוימות לא עומדות ביעד הבסיסי?
אחרי שבוחרים יעד בסיס, יכול להיות שיהיו לכם תכונות שאתם רוצים להשתמש בהן, אבל הן לא נכללות ביעד הזה. כלי Baseline לא אומר לכם מה לעשות כאן, וההחלטה אם כדאי לכם להשתמש בתכונות האלה תלויה בסוג האתר שאתם בונים ובקהל הצפוי.
לדוגמה, באתרי מסחר אלקטרוני או באתרים של B2B יכול להיות שיהיו מוכנים להגדיר ערך סף נמוך יותר לתמיכה ולטפל בבעיות ככל שהמשתמשים שלהם יתמכו בהן, בעוד שבאתרים ממשלתיים יכול להיות שיהיה צורך בערך סף גבוה יותר לתמיכה. כלל חשוב אחד הוא שלא כל תכונות האינטרנט נכשלות באותו אופן. יש הרבה דרכים לסווג תכונות לפי האופן שבו הן נכשלות, אבל דרך אחת לקבץ תכונות שעשויות להיות מועילות היא כך:
- שיפור: אם משתמשים בתכונה בדפדפן לא נתמך, חוויית השימוש לא נפגעת. יכול להיות שחוויית המשתמש תיפגע, אבל סביר להניח שהמשתמש לא ישים לב לכך. דוגמה:
loading="lazy". - תוספת: התכונה מספקת כמה יתרונות נוספים שעשויים להיות בולטים – כמו שינויים בסגנון הדף או פונקציונליות מסוימת. יכול להיות שהמשתמשים לא יבחינו בהבדל אם אין תמיכה בתכונה, אלא אם יבדקו את התכונה בדפדפן שבו יש תמיכה בה. דוגמה: Subgrid
- קריטי: אם התכונה לא נתמכת, חוויית המשתמש תהיה שלילית – ואולי אפילו לא תפעל בכלל. דוגמה: File System Access API שמשמש כתכונה מרכזית וחיונית.
יכול להיות גם שתגלו שתכונות מסוימות מחוץ ליעד שלכם נהנות מתמיכה טובה יותר ממה שחשבתם. אפשר להבין כמה מהמשתמשים שלכם מקבלים תמיכה בתכונה מסוימת. התכונה 'האם אפשר להשתמש?' יכולה לבדוק את התמיכה בתכונות ספציפיות על סמך נתוני הניתוח שלכם. ב-RUMvision יש גם אפשרות להתעמק בנתונים ברמת התכונה ולחקור אותם, אם זה עוזר לכם.
כך תוכלו להשתמש ביעד הבסיסי כדי לצמצם את מספר התכונות שעליכם לבחון בקפידה. אין צורך לדאוג לגבי כל מה שנמצא בתוך היעד. אם יש תכונה אחת או שתיים מחוץ ליעד שלכם שיהיו מועילות במיוחד, יש לכם את הכלים כדי להמשיך לבדוק ולהחליט אם להשתמש ב-polyfill או בשיפור הדרגתי.
סיכום
לכל אפליקציית אינטרנט יש דרישות שונות – החל מאתר מסחר אלקטרוני שיכול לסבול בעיות תאימות נוספות, ועד לאתר ממשלתי שחייב להיות זמין ומתפקד לכמה שיותר משתמשים. אלה חישובים שעליכם לבצע בעצמכם. מטרת Baseline היא לא לומר לכם אילו החלטות לקבל לגבי אימוץ תכונות אינטרנט חדשות, אלא יותר להסביר איך.