کروم ۱۳۰ و قابلیت‌های جدید برای توسعه‌دهندگان

Chrome 130 در ۱۵ اکتبر ۲۰۲۴ منتشر شد. اگر امروز این نسخه را بررسی می‌کنیم، هدف فهم تغییراتی است که وارد ابزارهای توسعه و پلتفرم وب شدند؛ نه معرفی آن به‌عنوان مرورگر تازه سال ۲۰۲۶. بعضی خبرهای مربوط به نسخه‌های بعدی، از جمله امکانات جدید دستیار هوش مصنوعی، نباید به این انتشار نسبت داده شوند. برای توسعه‌دهنده، ارزش این تغییرات در حل مسئله مشخص است: پیدا کردن درخواست مشکل‌دار، خواندن بهتر پروفایل عملکرد و نوشتن CSS قابل پیش‌بینی‌تر.

این راهنما بر یادداشت انتشار رسمی Chrome 130 و تغییرات DevTools همین نسخه تکیه دارد. میان قابلیت خود مرورگر و ابزار بررسی آن فرق می‌گذاریم. وجود یک ویژگی در DevTools به معنی تغییر استاندارد CSS نیست؛ همچنین اضافه شدن API به Chrome تضمین نمی‌کند همه مرورگرهای مخاطبان شما هم‌زمان از آن پشتیبانی کنند.

چه تغییراتی واقعاً به این نسخه مربوط‌اند؟

در پلتفرم وب، تغییرهای مربوط به CSS Nesting، رفتار Container Queries در Flat Tree و پشتیبانی بدون پیشوند از box-decoration-break از موارد این انتشار هستند. در DevTools، فیلترهای Network، خروجی HAR، ابزارهای Performance و نمای Detached Elements تغییر کردند. هر مورد، کاربرد و محدودیت خودش را دارد. جمع کردن همه این‌ها زیر عنوان «تحول هوشمند ابزارها» چیزی درباره نحوه استفاده به خواننده نمی‌گوید.

دو ادعای رایج را کنار بگذارید: Chrome 130 نه ::slotted را به‌طور کامل حذف کرده و نه شبیه‌ساز یک شبکه واقعی 5G ساخته است. شبیه‌سازی محدودیت شبکه در ابزار توسعه، تقریب شرایط است. نوع شبکه، فاصله تا سرور، ازدحام و ویژگی دستگاه را نمی‌توان فقط با انتخاب یک نام در منوی ابزار بازسازی کرد. بنابراین نتیجه یک تنظیم آزمایشگاهی را به تجربه تمام کاربران تعمیم ندهید.

CSS Nesting و ترتیب declarationها

CSS Nesting اجازه می‌دهد قواعد وابسته را داخل قاعده والد بنویسید. این شکل نوشتن برای گروه کردن سبک یک کامپوننت کاربرد دارد، ولی باید رفتار parser و ترتیب declarationها را هم بدانید. در Chrome 130، قواعد CSSNestedDeclarations به حفظ جای declarationهایی کمک کردند که بعد از یک قاعده تو در تو می‌آیند. این مسئله درباره ترتیب و مدل پردازش CSS است، نه وعده کاهش خودکار حجم فایل یا افزایش سرعت تمام صفحات.

اگر پیش‌تر از Sass استفاده می‌کردید، شباهت ظاهری Nesting بومی نباید شما را به فرض یکسان بودن تمام رفتارها برساند. خروجی ابزار ساخت و CSS اجراشده در مرورگر را جدا بررسی کنید. همچنین nesting عمیق، selector را سخت‌خوان می‌کند. برای یک کارت ساده، قرار دادن سبک عنوان و لینک زیر قاعده card کافی است؛ لازم نیست کل ساختار صفحه را داخل چند سطح selector بازنویسی کنید.

مثال کامل HTML و CSS

نمونه زیر را در فایلی با نام nesting.html ذخیره کنید و در مرورگری که از CSS Nesting پشتیبانی می‌کند باز کنید. وابستگی بیرونی ندارد. class کارت، عنوان داخل آن و لینک واقعی به بخش توضیحات همگی در HTML آمده‌اند. declaration پس‌زمینه عمداً بعد از قاعده تو در تو نوشته شده تا ساختار مورد بحث را ببینید. برای تولید واقعی، سیاست پشتیبانی مرورگر پروژه را مبنا قرار دهید و در صورت نیاز از ابزار تبدیل CSS استفاده کنید.

<!doctype html>
<html lang="fa" dir="rtl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>نمونه CSS Nesting</title>
  <style>
    body { font-family: sans-serif; margin: 2rem; background: #f4f7f5; }
    .card {
      color: #172b24;
      padding: 1.25rem;
      border: 1px solid #a8bdb1;
      border-radius: 1rem;
      & h2 { margin-top: 0; font-size: 1.25rem; }
      background: white;
      & a { color: #086647; text-underline-offset: .25em; }
    }
  </style>
</head>
<body>
  <article class="card">
    <h2>نمونه یک کارت</h2>
    <p>این کارت از CSS Nesting بومی استفاده می‌کند.</p>
    <a href="#details">دیدن توضیحات</a>
  </article>
  <section id="details">
    <h2>توضیحات</h2>
    <p>قواعد فرزند داخل قاعده card قرار گرفته‌اند.</p>
  </section>
</body>
</html>

در این نمونه، & h2 عنوانی را انتخاب می‌کند که داخل کارت است و & a لینک کارت را هدف می‌گیرد. بخش details بیرون کارت قرار دارد و سبک‌های داخلی کارت روی آن اعمال نمی‌شوند. اگر یک قطعه CSS را به پروژه اضافه می‌کنید، همین رابطه را در markup بررسی کنید. داشتن selector درست روی کاغذ کافی نیست؛ عنصر مورد نظر باید واقعاً در همان محدوده قرار گرفته باشد.

Container Queries در مرز Shadow DOM

Container Queries اندازه یا شرایط یک container را برای اعمال سبک بررسی می‌کنند. در Chrome 130، تغییر lookup در Flat Tree به سناریوهای Shadow DOM و محتوای slotted مربوط می‌شود. برای بیشتر صفحه‌های ساده ممکن است اثر مستقیمی نبینید، اما کتابخانه کامپوننتی که از Shadow DOM استفاده می‌کند باید رفتار خود را در مرزهای کامپوننت بشناسد. تغییر را با حذف ::part یا ::slotted اشتباه نگیرید؛ این ابزارها نقش‌های متفاوتی دارند.

در عمل، نخست مشخص کنید container کدام عنصر است و محتوای قابل مشاهده چگونه در درخت صفحه قرار می‌گیرد. اگر یک کارت در محیط نمایش جدا درست است ولی داخل کامپوننت دیگر شکست می‌خورد، فقط مقدار breakpoint را عوض نکنید. ممکن است container مورد انتظار انتخاب نشده باشد. برای طراحی پایه شبکه و رابطه والد و فرزند، مقاله راهنمای CSS Grid با مثال کامل می‌تواند نقطه شروع مناسبی باشد.

box-decoration-break چه مسئله‌ای را حل می‌کند؟

وقتی یک عنصر در چند خط یا چند بخش تقسیم می‌شود، باید تصمیم گرفته شود پس‌زمینه، border و دیگر decorationهای آن چگونه نمایش داده شوند. box-decoration-break برای همین رفتار است. Chrome 130 پشتیبانی کامل‌تر و بدون پیشوند از این ویژگی را اضافه کرد. مقدار clone برای هر قطعه decoration جدا در نظر می‌گیرد، در حالی که slice رفتار دیگری در تقسیم ظاهر دارد.

نمونه کاربردی، برچسبی است که متن آن در چند خط می‌شکند. نتیجه را با متن کوتاه و بلند، زبان فارسی و عرض باریک بررسی کنید. این ویژگی جای تصمیم درباره فاصله، خوانایی و طول برچسب را نمی‌گیرد. اگر برچسب بیش از حد طولانی باشد، ظاهر زیباتر در چند خط هنوز ممکن است فهم دسته‌بندی را دشوار کند. راهنمای طراحی سیستم Tag و Label به تصمیم محتوایی و بصری این بخش می‌پردازد.

Network: از فهرست درخواست‌ها به سؤال مشخص

پنل Network وقتی مفید می‌شود که یک سؤال روشن داشته باشید. برای مثال، چرا جست‌وجو دیر پاسخ می‌دهد، کدام تصویر بیش از حد بزرگ است یا چرا یک درخواست دوبار ارسال می‌شود؟ بهبود فیلترها در DevTools 130 برای محدود کردن فهرست درخواست‌ها کاربرد دارد. ابتدا نوع درخواست و مسیر مربوط را مشخص کنید، سپس زمان شروع، وضعیت پاسخ و Initiator را بخوانید. صدها ردیف بدون هدف، شواهد قابل استفاده تولید نمی‌کنند.

اگر یک درخواست شکست خورده، status و متن پاسخ را با رفتار رابط مقایسه کنید. خطای CORS با پاسخ خطای برنامه یا قطع اتصال یکسان نیست. همچنین پاسخ موفق سرور تضمین نمی‌کند داده مورد انتظار در آن وجود دارد. از مشاهده یک عدد در ستون Status مستقیم به راه‌حل نپرید؛ مسیر تولید درخواست و مصرف پاسخ را دنبال کنید. اگر ورودی کاربر درخواست‌های زیادی ایجاد می‌کند، مقاله Debounce و Throttle برای کنترل نرخ اجرا مفید است.

خروجی HAR و اطلاعات حساس

در DevTools 130، خروجی معمول HAR به‌صورت پیش‌فرض headerهای Cookie، Set-Cookie و Authorization را کنار می‌گذارد. این تغییر خطر افشای ناخواسته را کاهش می‌دهد، اما تضمین نمی‌کند فایل خروجی هیچ اطلاعات حساسی ندارد. URL، query، بدنه درخواست یا پاسخ هنوز ممکن است داده شخصی یا شناسه داخلی داشته باشند. قبل از ارسال فایل به همکار یا پشتیبانی، محتوای آن را با محدوده همان گزارش هماهنگ کنید.

اگر برای بررسی یک مشکل به اطلاعات حذف‌شده نیاز دارید، ابزار مسیر جداگانه‌ای برای خروجی شامل داده حساس دارد. چنین فایل‌هایی را مانند یک پیوست عمومی منتشر نکنید. در گزارش فنی، معمولاً لازم نیست token واقعی یا اطلاعات حساب کاربر را نمایش دهید؛ زمان درخواست، مسیر و پیام خطای پاک‌سازی‌شده کافی است. حذف headerهای مشخص یک کمک ابزار است و جای مسئولیت تیم در مدیریت اطلاعات گزارش را نمی‌گیرد.

Performance: داده محلی و تجربه کاربران

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

در خواندن trace، دنبال رابطه رویدادها باشید. یک تعامل کاربر ممکن است چند کار پشت سر هم ایجاد کند: handler، تغییر state، پردازش layout و paint. جابه‌جایی میان breadcrumbهای بازه بررسی کمک می‌کند محدوده انتخاب‌شده را بهتر دنبال کنید. با این حال، ابزار علت را به‌جای شما نتیجه‌گیری نمی‌کند. اگر یک task طولانی دیدید، باید مشخص کنید کدام کد و کدام ورودی آن را ایجاد کرده است.

گزارش عملکرد را با یک جمله عملی تمام کنید؛ مثلاً «پردازش فهرست پس از هر حرف ورودی دوباره انجام می‌شود». چنین یافته‌ای به تغییر کد منتهی می‌شود. عبارت «صفحه کند است» فقط مشاهده اولیه است. برای ارتباط بین تحلیل DevTools و معیارهای گزارش سایت، راهنمای PageSpeed Insights را بخوانید؛ امتیاز آزمایشگاهی و تجربه واقعی کاربر را یک عدد واحد فرض نکنید.

Memory و Detached Elements

یک عنصر ممکن است از صفحه حذف شود، ولی به دلیل reference باقی‌مانده هنوز در حافظه نگهداری شود. نمای Detached Elements برای بررسی چنین وضعیت‌هایی کاربرد دارد. مثلاً یک پنجره چندبار باز و بسته می‌شود و هر بار بخشی از داده یا listener آن باقی می‌ماند. مشاهده عنصر detached به‌تنهایی اثبات نشت حافظه نیست؛ ممکن است برنامه آن را عمداً برای استفاده بعدی نگه دارد.

برای یافتن مشکل، یک چرخه مشخص مثل باز و بسته کردن پنجره را تکرار کنید و وضعیت نگهداری عناصر را بررسی کنید. سپس مسیر reference را بخوانید و cleanup را در همان بخش کد اصلاح کنید. تغییر چند بخش نامرتبط هم‌زمان، نسبت میان علت و نتیجه را مبهم می‌کند. مشکل حافظه را هم فقط از مقدار مصرف لحظه‌ای نتیجه نگیرید؛ رفتار در گذر زمان و امکان آزاد شدن داده مهم است.

استفاده درست از یک یادداشت انتشار قدیمی

Chrome 130 بخشی از مسیر تکامل ابزارهای وب است. در پروژه امروز، مرورگر نصب‌شده، نسخه DevTools و ماتریس پشتیبانی کاربران خودتان را بررسی کنید. ابزار یا قابلیت نسخه‌های بعدی را به این انتشار نسبت ندهید و بر اساس نام یک نسخه، فرض نکنید همه مشکلات حل شده‌اند. بهترین استفاده از یادداشت انتشار این است که تغییر مرتبط با مسئله شما را پیدا کنید، رفتار آن را بفهمید و آن را به یک کار مشخص در پروژه وصل کنید.