پرفورمنس Selector ها و CSS بلااستفاده؛ آیا واقعاً سرعت اجرا مهمه؟
تو درس قبل بیشتر روی حجم فایل و روش بارگذاری CSS تمرکز کردیم. یه سؤال دیگه که خیلی وقتها پیش میاد اینه: آیا نوشتن selector های پیچیدهتر یا داشتن CSS بلااستفاده، خودِ سرعت اجرای مرورگر (نه فقط حجم دانلود) رو هم کند میکنه؟ جواب کوتاه اینه: بله، ولی احتمالاً نه بهاندازهای که فکر میکنید. تو این درس میخوایم دقیقتر ببینیم مرورگر چطور selector ها رو پردازش میکنه و کجا واقعاً باید نگران باشیم.
مرورگر selector ها رو از راست به چپ میخونه
یه نکتهی فنی مهم که خیلیها ازش خبر ندارن: وقتی مرورگر میخواد بفهمه یه selector به کدوم المنتها match میشه، از سمت راست شروع میکنه، نه چپ:
.sidebar ul li a {
color: blue;
}مرورگر اول همهی a های تو صفحه رو پیدا میکنه (چون آخرین بخش selector، یعنی «key selector»، همینه)، بعد برای هر کدوم چک میکنه آیا واقعاً داخل یه li، که داخل یه ul، که داخل یه .sidebar هست یا نه. این یعنی هرچی تعداد a های تو صفحه بیشتر باشه، این selector هزینهی بررسی بیشتری داره، حتی اگه فقط چندتاشون واقعاً تو sidebar باشن.
پس چرا نگرانش نباشیم؟
موتورهای CSS مدرن مرورگرها فوقالعاده بهینه شدن و این محاسبات معمولاً در حد میکروثانیه انجام میشن، حتی برای صفحاتی با هزاران selector. تو اکثریت قریببهاتفاق پروژههای واقعی، تفاوت پرفورمنس بین یه selector ساده مثل .btn و یه selector تو در توی عمیق مثل .sidebar ul li a، عملاً غیرقابلاندازهگیریه و هیچ کاربری متوجهش نمیشه. به همین دلیل، امروزه توصیهی اصلی برای selector ها بیشتر بر مبنای خوانایی و قابلنگهداری بودن کده، نه پرفورمنس خام.
کجا selector واقعاً میتونه مشکلساز بشه؟
یه استثنای واقعی وجود داره: selector هایی که با هر تعامل کاربر (مثل اسکرول یا حرکت ماوس) مرتب دوباره محاسبه میشن. مثلاً اگه یه قانون پیچیده با :hover روی هزاران المنت تو یه صفحهی خیلی شلوغ باشه و با هر حرکت ماوس دوباره ارزیابی بشه، اونجا میتونه محسوس بشه. ولی این یه سناریوی خیلی خاص و نادره، نه چیزی که تو اکثر پروژههای معمولی روش تمرکز کنید.
CSS بلااستفاده: مشکل واقعی کجاست؟
برخلاف پرفورمنس selector، CSS بلااستفاده یه مشکل واقعی و قابلاندازهگیریه، ولی هزینهاش بیشتر از جنس حجم دانلوده تا سرعت اجرا؛ همون چیزی که تو درس قبل دیدیم. یه فایل CSS با هزاران خط قانون بلااستفاده، باعث میشه مرورگر مجبور بشه حجم بیشتری رو دانلود و پارس کنه، حتی اگه تأثیرش رو محاسبهی نهایی استایل هر المنت خیلی کوچیک باشه.
چطور CSS بلااستفاده رو پیدا کنیم؟
DevTools مرورگرها (مثل تب Coverage تو Chrome) میتونه نشون بده چه درصدی از یه فایل CSS واقعاً روی صفحهی فعلی استفاده شده. یه نکتهی مهم: این ابزار فقط برای همون صفحهی خاصیه که الان بازه؛ یه selector که تو صفحهی اصلی بلااستفاده به نظر میرسه، ممکنه دقیقاً همون CSSای باشه که تو صفحهی دیگهای از سایت لازمه. به همین دلیل، تصمیم حذف واقعی یه بخش از CSS باید بر اساس بررسی کل سایت باشه، نه فقط یه صفحه.
Specificity بالا: مشکل نگهداری، نه پرفورمنس
یه نکتهی تکمیلی مهم: وقتی تو فصلهای اول دوره از specificity بالا (مثل زنجیره کردن چند کلاس یا استفادهی زیاد از id) پرهیز میکردیم، دلیلش پرفورمنس نبود؛ دلیلش سختی override کردن و نگهداری کد تو آینده بود. این یه سوءتفاهم رایجه که فکر کنیم selector های «سنگین» کند هستن؛ در واقع مشکل اصلی همیشه قابلیت نگهداری کد بوده، نه سرعت مرورگر.
اشتباه رایج: صرف زمان زیاد روی میکرو-بهینهسازی selector بهجای مشکلات واقعی
یه اشتباه رایج (خصوصاً بین توسعهدهندههای تازهکاری که تازه با مفهوم پرفورمنس آشنا شدن) اینه که وقت زیادی صرف بازنویسی selector های ساده به فرم «بهینهتر» میکنن، در حالی که مشکلات واقعی پرفورمنس (مثل حجم کل فایل، عدم کش شدن، فونتهای سنگین، یا انیمیت کردن ویژگیهای Layout-محور که تو فصل ۲۰ دیدیم) جای دیگهای هستن و تأثیر خیلی بزرگتری دارن. اولویتبندی درست، یعنی اول سراغ چیزهایی برید که واقعاً قابلاندازهگیری و قابلحسکردن هستن.
جمعبندی
مرورگر selector ها رو از راست به چپ ارزیابی میکنه، ولی موتورهای CSS مدرن آنقدر بهینهن که این تفاوت تو اکثر پروژهها عملاً بیاهمیته؛ اولویت انتخاب selector باید خوانایی و specificity پایین باشه، نه سرعت خام. CSS بلااستفاده یه مشکل واقعیه، ولی از جنس حجم دانلود و پارس، نه سرعت اجرا؛ برای پیداکردنش از ابزارهایی مثل تب Coverage استفاده کنید، ولی همیشه بر اساس کل سایت تصمیم بگیرید، نه یه صفحهی تنها.