وبلاگ / راهنمای مسیر یادگیری و فناوری
راهنمای مسیر یادگیری و فناوری

Baseline 2026 چیست؟ راهنمای عملی پشتیبانی مرورگر برای تیم‌های فرانت‌اند

راهنمای تصمیم‌گیری برای استفاده از قابلیت‌های جدید وب با Baseline 2026؛ از تفاوت Newly و Widely Available تا انتخاب هدف Browserslist، کنترل CI و طراحی مسیر fallback بر پایه داده کاربران واقعی.

· ۱۶ بازدید

انتخاب یک قابلیت تازه CSS یا JavaScript معمولاً با یک پرسش تکراری شروع می‌شود: «آیا می‌توانیم همین حالا در Production از آن استفاده کنیم؟» پاسخ سنتی، بازکردن چند جدول سازگاری، حدس‌زدن نسخه مرورگر کاربران و ساختن فهرستی بود که خیلی زود قدیمی می‌شد. Baseline 2026 تلاش می‌کند این تصمیم را به یک زبان مشترک تبدیل کند؛ زبانی که طراح، توسعه‌دهنده، مدیر محصول و مسئول QA بتوانند درباره آن توافق کنند.

اما دیدن نشان Baseline کنار یک API به‌تنهایی مجوز استفاده نیست. این مقاله نشان می‌دهد چگونه وضعیت استاندارد وب را با داده کاربران، ریسک مسیر محصول، تنظیمات Build و آزمون واقعی ترکیب کنید. هدف، دنبال‌کردن هر قابلیت تازه نیست؛ هدف این است که بدانیم چه چیزی را، برای کدام کاربر و با چه مسیر بازگشتی وارد محصول کنیم.

Baseline دقیقاً چه مسئله‌ای را حل می‌کند؟

مرورگرها با سرعت‌های متفاوت قابلیت‌های وب را پیاده‌سازی می‌کنند. یک ویژگی ممکن است ماه‌ها در یک موتور موجود باشد، اما در موتور دیگر هنوز پشتیبانی نشود. پروژه Baseline در WebDX وضعیت قابلیت‌ها را روی مجموعه‌ای از مرورگرهای اصلی جمع‌بندی می‌کند: Chrome در دسکتاپ و Android، Edge در دسکتاپ، Firefox در دسکتاپ و Android و Safari در macOS و iOS.

این خلاصه دو مزیت دارد. نخست، تیم به‌جای تکیه بر حافظه افراد، یک مرجع قابل‌ردیابی دارد. دوم، می‌توان هدف سازگاری را وارد ابزارهای توسعه کرد؛ یعنی همان تصمیمی که در سند معماری نوشته‌ایم، در lint، transpile و Build نیز اثر بگذارد. بااین‌حال Baseline سهم استفاده هر مرورگر در سایت شما یا شرایط WebViewهای خاص را اندازه نمی‌گیرد. آن بخش همچنان بر عهده داده محصول است.

سه وضعیت را اشتباه نگیرید

Limited Availability: هنوز قرارداد مشترک نداریم

اگر قابلیت Limited Availability باشد، دست‌کم یکی از مرورگرهای اصلی هنوز آن را ارائه نکرده است. این وضعیت لزوماً به معنی «ممنوع» نیست. شاید قابلیت فقط یک بهبود تزئینی باشد و بتوان آن را با Progressive Enhancement افزود. در مقابل، اگر نبود آن ورود، خرید یا تکمیل فرم را متوقف کند، استفاده مستقیم ریسک بالایی دارد.

Newly Available: امروز هم‌عمل‌پذیر، نه لزوماً روی دستگاه قدیمی

Newly Available یعنی نسخه‌های جاری مرورگرهای اصلی به نقطه پشتیبانی مشترک رسیده‌اند. مسئله اینجاست که همه کاربران آخرین نسخه را ندارند. دستگاه سازمانی، تلویزیون هوشمند، WebView قدیمی یا موبایلی که به‌روزرسانی دریافت نمی‌کند می‌تواند بیرون این محدوده باشد. بنابراین این سطح برای قابلیت‌های غیرحیاتی یا محصولاتی با کاربران به‌روز مناسب‌تر است.

Widely Available: ۳۰ ماه فرصت برای انتشار گسترده‌تر

طبق تعریف WebDX، وقتی ۳۰ ماه از رسیدن قابلیت به وضعیت Newly Available بگذرد، برچسب Widely Available می‌گیرد. این فاصله زمانی باعث می‌شود نسخه‌های پشتیبان در میان کاربران بیشتری پخش شوند. Widely Available هدف محافظه‌کارانه‌تری است، اما باز هم تضمین نمی‌کند هر دستگاه ناشناخته‌ای پشتیبانی شود؛ به‌ویژه اگر قرارداد شما صریحاً مرورگر بسیار قدیمی یا محیط تعبیه‌شده‌ای را پوشش دهد.

Baseline 2026 یک نسخه مرورگر نیست

یادداشت‌های رسمی Baseline در سال ۲۰۲۶ قابلیت‌هایی را ثبت می‌کنند که ماه‌به‌ماه به وضعیت Newly Available یا Widely Available رسیده‌اند. عبارت Baseline 2026 را نباید با «پشتیبانی از مرورگرهای منتشرشده در ۲۰۲۶» یکی دانست. سال Baseline یک مجموعه قابلیت است، نه شماره نسخه واحد برای تمام مرورگرها.

این تفاوت برای معماری مهم است. وقتی تیم می‌گوید «هدف ما Baseline 2024 است»، در واقع مجموعه قابلیت‌هایی را انتخاب کرده که تا پایان آن سال هم‌عمل‌پذیر بوده‌اند. چنین قراردادی از نوشتن فهرست نسخه‌ها خواناتر است و با تغییرات مرورگرها بهتر نگه‌داری می‌شود.

چند نمونه ۲۰۲۶ و روش ارزیابی آن‌ها

فهرست ۲۰۲۶ ثابت نیست و طی سال رشد می‌کند. در زمان دسترسی به منابع، نمونه‌هایی مانند Container Style Queries، تابع contrast-color()، Navigation API، Trusted Types، WebTransport، Reporting API و ماژول‌های JavaScript در Service Worker در فهرست دیده می‌شوند. نام‌بردن از این موارد به معنی توصیه یکسان برای همه پروژه‌ها نیست.

  • قابلیت نمایشی: اگر نبود آن فقط ظاهر را ساده‌تر می‌کند، می‌توان با fallback سبک و تست بصری وارد شد.
  • قابلیت رفتاری: برای Navigation API یا منطق فرم باید مسیر جایگزین و آزمون انتها‌به‌انتها تعریف شود.
  • قابلیت امنیتی: Trusted Types یا گزارش CSP بخشی از دفاع هستند؛ فعال‌سازی ناقص ممکن است هشدارهای کاذب یا شکست Runtime ایجاد کند و به rollout مرحله‌ای نیاز دارد.
  • قابلیت شبکه‌ای: WebTransport فقط مسئله مرورگر نیست؛ زیرساخت، پروکسی، شبکه سازمانی و مدل fallback نیز باید آزموده شوند.

روش درست این است که هر قابلیت را براساس اثر شکست دسته‌بندی کنیم، نه میزان جذابیت آن در خبرها. قابلیت تازه‌ای که مسیر اصلی درآمد یا دسترس‌پذیری را می‌شکند، حتی با نشان Newly Available به بررسی عمیق‌تری نیاز دارد.

ماتریس چهارخانه برای تصمیم Production

پیش از اضافه‌کردن یک قابلیت، دو محور بسازید: «حیاتی‌بودن مسیر» و «امکان fallback». ترکیب این دو، تصمیم را روشن‌تر می‌کند.

  • غیرحیاتی + fallback آسان: کاندید مناسب Progressive Enhancement، حتی در برخی حالت‌های Limited Availability.
  • غیرحیاتی + fallback دشوار: آزمایش محدود، Feature Flag و اندازه‌گیری خطا لازم است.
  • حیاتی + fallback آسان: استفاده ممکن است، اما مسیر جایگزین باید در تست‌های CI پوشش داده شود.
  • حیاتی + fallback دشوار: معمولاً بهتر است تا Widely Available شدن یا روشن‌شدن داده کاربران صبر کنید.

برای مثال، استفاده از یک ویژگی رنگی تازه در کارت تبلیغاتی با جایگزین ثابت، با استفاده از API ناوبری در فرایند پرداخت یکسان نیست. سیاست مرورگر خوب، همین تفاوت کسب‌وکاری را ثبت می‌کند.

اول داده کاربران، بعد هدف Baseline

مستندات رسمی Browserslist هدف‌های Baseline را به نسخه‌های سازگار مرورگر تبدیل می‌کند. برای انتخاب میان هدف‌های موجود باید سهم مرورگرهای کاربران را از Analytics یا داده Real User Monitoring بسنجید. یک سایت آموزشی با کاربران موبایل قدیمی ممکن است هدف محافظه‌کارانه‌تری نسبت به داشبورد داخلی یک شرکت با دستگاه‌های مدیریت‌شده داشته باشد.

در گزارش خود حداقل این موارد را تفکیک کنید: نسخه مرورگر، سیستم‌عامل، WebView یا مرورگر مستقل، مسیرهای پرترافیک، نرخ خطای JavaScript، کشور یا شبکه و نرخ تبدیل. سپس درصد کاربرانی را که بیرون هدف پیشنهادی هستند محاسبه کنید. درصد کوچک در صفحه وبلاگ با همان درصد در پرداخت ارزش یکسانی ندارد.

Browserslist؛ تبدیل سیاست به تنظیمات اجرایی

Browserslist پلی میان تصمیم تیم و ابزارهایی مانند Babel، Autoprefixer، PostCSS، ESLint، Stylelint و webpack است. به‌جای فهرست دستی نسخه‌ها می‌توان یکی از هدف‌های زیر را در تنظیمات پروژه قرار داد:

  • baseline widely available برای رویکرد محافظه‌کارانه و دامنه وسیع‌تر دستگاه‌ها؛
  • baseline newly available برای محصولی که کاربران آن به‌روز هستند و fallback مناسبی دارد؛
  • baseline 2024 یا سال مشخص دیگر برای قرارداد ثابت و قابل‌بازتولید؛
  • افزودن with downstream وقتی مرورگرهای پایین‌دستی مبتنی بر موتورهای اصلی نیز باید در نگاشت دیده شوند.

پس از تغییر هدف، فقط سبزشدن Build کافی نیست. اندازه bundle، تعداد transformها، polyfillهای افزوده یا حذف‌شده و رفتار صفحات اصلی را قبل و بعد مقایسه کنید. هدف جدید ممکن است خروجی را کوچک‌تر کند، اما این سود باید در کنار پوشش واقعی کاربران ارزیابی شود.

Baseline را وارد CI کنید

پروژه web-features داده وضعیت قابلیت‌ها را به‌صورت کاتالوگ مشترک و بسته npm منتشر می‌کند. لازم نیست هر تیم ابزار اختصاصی پیچیده‌ای بسازد؛ هدف می‌تواند از Browserslist به ابزارهای موجود برسد و lint استفاده از قابلیت‌های خارج سیاست را علامت بزند.

یک خط‌مشی سالم CI سه سطح دارد:

  1. خطا برای مسیرهای حیاتی: استفاده بدون fallback از قابلیت خارج هدف Build باید Merge را متوقف کند.
  2. هشدار برای بهبودهای غیرحیاتی: توسعه‌دهنده می‌تواند با توضیح fallback و تست مربوط، استثنا بگیرد.
  3. گزارش دوره‌ای: با تغییر داده Baseline یا ترکیب کاربران، اثر ارتقای هدف بررسی شود؛ هدف پویا نباید بدون Review ناگهان خروجی Production را عوض کند.

برای پایداری، نسخه وابستگی‌های سازگاری را lock کنید و ارتقای آن‌ها را مانند تغییر کد Review کنید. عبارت «widely available» ذاتاً با گذر زمان تغییر می‌کند؛ اگر Build کاملاً تکرارپذیر می‌خواهید، هدف سالانه یا نسخه pin‌شده داده‌ها انتخاب شفاف‌تری است.

Progressive Enhancement را عملی کنید

Progressive Enhancement یعنی تجربه پایه بدون قابلیت تازه کار کند و مرورگر پشتیبان تجربه بهتر بگیرد. این اصل در مسیر یادگیری ساخت اولین وب‌سایت با HTML و CSS نیز مهم است: ساختار معنایی و رفتار اصلی نباید به جلوه‌ای شکننده وابسته شود.

برای CSS، مقدار fallback را پیش از مقدار تازه بنویسید و در صورت نیاز از @supports استفاده کنید. برای JavaScript، وجود API را پیش از فراخوانی بررسی کنید و مسیر جایگزین را کوچک و آزموده نگه دارید. هدف این نیست که دو محصول کامل بسازید؛ هدف این است که نبود یک قابلیت تازه، کار اصلی کاربر را متوقف نکند.

TypeScript مشکل سازگاری Runtime را حل نمی‌کند

TypeScript می‌تواند هنگام توسعه نوع‌ها و قراردادهای API را بررسی کند، اما وجود یک interface در فایل‌های type declaration به معنی پشتیبانی مرورگر نیست. مقایسه TypeScript و JavaScript باید این مرز را روشن نگه دارد: TypeScript ابزار زمان توسعه است، درحالی‌که Baseline و داده سازگاری درباره Runtime کاربر صحبت می‌کنند.

اگر API تازه در TypeScript شناخته شود اما مرورگر هدف آن را نداشته باشد، کد همچنان در اجرا شکست می‌خورد. بنابراین سه کنترل جدا لازم‌اند: Type Check، بررسی سازگاری هدف و تست Runtime. حذف هرکدام یک کلاس متفاوت از خطا را پنهان می‌کند.

آزمون مرورگر هنوز ضروری است

Baseline از جدول‌های پراکنده بهتر است، اما دستگاه واقعی، تنظیمات حریم خصوصی، افزونه‌ها، شبکه و رفتار WebView را شبیه‌سازی نمی‌کند. ماتریس تست را براساس ریسک بچینید:

  • Smoke Test خودکار روی حداقل نسخه‌های حاصل از هدف Browserslist؛
  • تست انتها‌به‌انتها برای ورود، فرم، جست‌وجو، پرداخت و دانلود؛
  • تست صفحه‌کلید، Screen Reader و بزرگ‌نمایی برای دسترس‌پذیری؛
  • نمونه‌برداری دستی روی iOS Safari، Android و WebViewهای پرتکرار؛
  • پایش خطای JavaScript و نرخ شکست مسیر پس از انتشار.

همان منطقی که در چک‌لیست ارتقای امن وردپرس برای Staging و بازگشت به نسخه قبل استفاده می‌شود، اینجا هم کاربرد دارد: قابلیت مرورگر را مرحله‌ای فعال کنید، شاخص سلامت داشته باشید و مسیر Rollback را پیش از انتشار آماده کنید.

هفت گام برای تدوین سیاست پشتیبانی مرورگر

  1. مرورگرها و نسخه‌های واقعی کاربران را از Analytics یا RUM استخراج کنید.
  2. مسیرهای حیاتی محصول و هزینه شکست هرکدام را فهرست کنید.
  3. هدف اولیه مانند Widely Available یا یک سال Baseline را پیشنهاد دهید.
  4. کاربران خارج هدف و اثر تجاری آن را با تیم محصول مرور کنید.
  5. هدف را در Browserslist، lint و Build ثبت و وابستگی داده را pin کنید.
  6. ماتریس تست، fallback و قواعد استثنا را کنار سیاست بنویسید.
  7. هر فصل یا پس از تغییر محسوس کاربران، سیاست را با Pull Request بازبینی کنید.

نتیجه این فرایند باید یک سند کوتاه و اجرایی باشد: هدف اصلی، مرورگرهای استثنا، تعریف مسیر حیاتی، قواعد fallback، ابزارهای کنترل و تاریخ Review بعدی. سندی که فقط نام چند مرورگر را دارد، معمولاً در Build و QA قابل‌اجرا نیست.

چطور تغییرات Baseline را دنبال کنیم؟

Web Features Explorer قابلیت‌های Newly Available و Widely Available را نمایش می‌دهد و خوراک‌های RSS موضوعی و ماهانه دارد. این روش از دنبال‌کردن خبرهای پراکنده بهتر است، اما هر ورودی تازه نباید خودکار وارد Production شود.

یک نفر یا گروه کوچک می‌تواند ماهانه تغییرات را triage کند: آیا قابلیت مسئله واقعی محصول را حل می‌کند؟ وضعیت Baseline آن چیست؟ fallback چقدر هزینه دارد؟ آیا bundle یا پیچیدگی را کاهش می‌دهد؟ پاسخ مثبت، یک Spike کوچک و اندازه‌گیری‌شده می‌سازد؛ پاسخ منفی یعنی قابلیت فعلاً در backlog تحقیق باقی می‌ماند.

خطاهای رایج در استفاده از Baseline

  • تبدیل نشان به تضمین: Baseline وضعیت مجموعه مرورگر اصلی است، نه تضمین برای همه دستگاه‌ها.
  • نادیده‌گرفتن کاربران خود: ترکیب کاربران یک فروشگاه عمومی با پنل داخلی یکسان نیست.
  • هدف پویا بدون Review: به‌روزرسانی داده سازگاری می‌تواند خروجی Build را تغییر دهد.
  • اتکا به TypeScript: Type Check جای آزمون پشتیبانی Runtime را نمی‌گیرد.
  • حذف fallback: Newly Available هنوز به معنی ناپدیدشدن نسخه‌های قدیمی نیست.
  • تست‌نکردن مسیر حیاتی: جدول سازگاری رفتار واقعی محصول را تأیید نمی‌کند.

چک‌لیست نهایی پیش از Merge

  • وضعیت قابلیت در منبع رسمی WebDX بررسی شده است.
  • سهم کاربران خارج هدف اندازه‌گیری شده است.
  • اثر شکست روی مسیر اصلی محصول مشخص است.
  • fallback یا دلیل مکتوب نبود آن وجود دارد.
  • هدف Browserslist و lint با سیاست تیم هماهنگ است.
  • Build قبل و بعد از نظر اندازه و transform مقایسه شده است.
  • تست Runtime روی حداقل مرورگرهای هدف اجرا شده است.
  • پایش و Rollback برای انتشار مرحله‌ای آماده است.

جمع‌بندی

Baseline 2026 پاسخ ساده‌ای به پرسش پیچیده پشتیبانی مرورگر نمی‌دهد؛ ارزش آن در این است که نقطه شروع مشترک و قابل‌ابزارشدن فراهم می‌کند. Newly Available برای تیمی با کاربران به‌روز و fallback خوب می‌تواند مناسب باشد، درحالی‌که Widely Available یا هدف سالانه برای مسیرهای حساس محافظه‌کارانه‌تر است.

تصمیم حرفه‌ای از چهار جزء ساخته می‌شود: وضعیت رسمی قابلیت، داده کاربران واقعی، هزینه شکست محصول و آزمون Runtime. وقتی این چهار جزء در Browserslist، CI و سیاست Review ثبت شوند، تیم به‌جای جنگ بر سر حدس‌ها، یک قرارداد شفاف و قابل‌اندازه‌گیری خواهد داشت.

اگر می‌خواهید سیاست پشتیبانی مرورگر، تنظیمات Build و آزمون‌های فرانت‌اند پروژه‌تان را بر پایه داده واقعی استاندارد کنید، برای یک ممیزی فنی وب با خانه برنامه‌نویسان البرز در تماس باشید.