بهینه سازی CSS: چرا کاهش حجم فایل همیشه جواب نمی‌دهد؟

یک بار در یک پروژه‌ی فروشگاهی، بعد از یک ماه کار روی بهینه‌سازی سرعت، حجم CSS سایت را از ۴۸۰ کیلوبایت به ۱۲۰ کیلوبایت رساندیم. همه‌چیز روی کاغذ عالی بود اما سرعت واقعی صفحه فقط ۱۵٪ بهبود پیدا کرد. وقتی پروفایلر مرورگر را باز کردم، فهمیدم مسئله اصلاً حجم فایل نبود؛ مسئله این بود که در هر رندر، مرورگر برای محاسبه‌ی استایل‌های صدها عنصر، انتخابگرهای پیچیده‌ای را اجرا می‌کرد که همان ۱۲۰ کیلوبایت را هم بی‌فایده می‌کردند. آن تجربه، نگاه من به بهینه سازی CSS را برای همیشه تغییر داد: این کار، یک فرآیند دو لایه است — لایه‌ی حجم و لایه‌ی رفتار runtime — و بیشتر پروژه‌ها فقط لایه‌ی اول را می‌بینند.

بهینه‌سازی CSS (CSS Optimization) برخلاف تصور رایج، فقط minify و فشرده‌سازی نیست. یک تصمیم معماری است که از اولین خط CSS شما شروع می‌شود و تا رفتار موتور رندر در مرورگر کاربر ادامه دارد. اگر در مسیر آموزش CSS از صفر هستید یا مقالات فلکس باکس در CSS و گرید در CSS را خوانده‌اید، این نوشته مرحله‌ای است که کد شما را از «کار می‌کند» به «سریع کار می‌کند» می‌رساند.

چرا کاهش حجم، تنها بخش کوچکی از ماجراست؟

در پروژه‌های زیادی دیده‌ام که تیم‌ها بخش عمده‌ی وقت خود را صرف فشرده‌سازی می‌کنند: minify، gzip، Brotli، حذف کامنت‌ها. همه‌ی این‌ها لازم‌اند اما کافی نیستند. تجربه‌ی میدانی من سه واقعیت را نشان می‌دهد:

در سایت‌های کوچک، حجم فایل گلوگاه اصلی نیست. یک فایل ۵۰ کیلوبایتی و یک فایل ۲۰۰ کیلوبایتی روی اینترنت ۴G، تفاوتشان کمتر از ۱۰۰ میلی‌ثانیه است. اما اگر آن فایل ۵۰ کیلوبایتی شامل انتخابگرهای پیچیده باشد، می‌تواند سه برابر کندتر رندر شود.
در سایت‌های بزرگ، توزیع حجم مهم‌تر از حجم کل است. سایت شما می‌تواند در مجموع ۳۰۰ کیلوبایت CSS داشته باشد؛ اما اگر ۵۰ کیلوبایت از آن برای صفحه‌ی اول حیاتی باشد و بقیه پایین‌تر لود شود، تجربه‌ی کاربر با ۵۰ کیلوبایت شروع می‌شود.
در همه‌ی سایت‌ها، هزینه‌ی محاسباتی استایل هم مهم است. هر بار که مرورگر یک عنصر جدید به DOM اضافه می‌کند یا کلاس آن را تغییر می‌دهد، باید تمام قواعد CSS مطابق با آن عنصر را پیدا، اولویت‌بندی و اعمال کند. اگر انتخابگرهای شما پیچیده باشند، این کار می‌تواند به‌طور محسوس کند شود.

یک مثال واقعی از پروژه‌ی بازبینی‌شده: قالبی که در مجموع فقط ۸۵ کیلوبایت CSS داشت اما در هر بازدید، Time to Interactive آن بالای ۴ ثانیه بود. پس از پروفایلینگ، معلوم شد بیش از ۴۰٪ زمان پردازش، صرف پیدا کردن قواعد مطابق با انتخابگرهای عمیق می‌شود. کاهش حجم به ۷۰ کیلوبایت، تفاوت محسوسی نداشت؛ اما بازنویسی انتخابگرها، TTI را به ۱.۸ ثانیه رساند.

در بهینه سازی CSS، ترتیب اهمیت این است: اول رفتار، بعد توزیع، آخر حجم. اکثر پروژه‌ها به‌طور معکوس عمل می‌کنند.

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

مسیر رندر: کجا CSS وقت می‌خورد؟

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

Style Calculation: مرورگر تمام قواعد CSS را می‌خواند و برای هر عنصر DOM، مجموعه‌ی استایل‌های مطابق را پیدا و اولویت‌بندی می‌کند. این مرحله شامل تطبیق انتخابگرها با عناصر است و در پروژه‌های با CSS پیچیده، پرترددترین مرحله است.
Layout: مرورگر موقعیت و ابعاد هر عنصر را محاسبه می‌کند. CSS تعیین‌کننده‌ی این است که آیا عنصر باید در layout شرکت کند یا نه (مثلاً display: none حذف می‌کند، visibility: hidden حفظ می‌کند).
Paint و Composite: مرورگر هر عنصر را رنگ‌آمیزی می‌کند. CSS مشخص می‌کند کدام عناصر به لایه‌ی compositor جداگانه ارتقا یابند (مثلاً با transform یا will-change).

در سایت‌های معمولی، هزینه‌ی مرحله‌ی اول (Style Calculation) غالب است. در سایت‌های با انیمیشن‌های زیاد، مرحله‌ی سوم. اما تجربه‌ی من نشان می‌دهد که در ۹۰٪ پروژه‌ها، اگر مرحله‌ی اول بهینه شود، سود محسوس در تجربه‌ی کاربر دیده می‌شود. برای درک عمیق‌تر این سه مرحله، انیمیشن در CSS و ترنزیشن در CSS را در کنار این بخش ببینید.

Critical CSS و اولین ثانیه‌ی حیاتی

یکی از پرقدرت‌ترین تکنیک‌های بهینه‌سازی CSS، مفهوم Critical CSS است. ایده ساده است: CSS مورد نیاز برای رندر اولین بخش قابل‌مشاهده‌ی صفحه (above-the-fold) را مستقیم داخل HTML قرار دهید و بقیه‌ی CSS را به‌صورت async بارگذاری کنید:

<head>
  <style>
    /* CSS بحرانی - فقط چیزهایی که برای بالای صفحه لازم است */
    body { font-family: system-ui; margin: 0; }
    .header { display: flex; padding: 1rem; }
    .hero { font-size: clamp(1.5rem, 4vw, 3rem); }
  </style>

  <link rel="preload" href="/styles/main.css" as="style"
        onload="this.rel='stylesheet'">
  <noscript>
    <link rel="stylesheet" href="/styles/main.css">
  </noscript>
</head>

این الگو به مرورگر اجازه می‌دهد صفحه را سریع‌تر رندر کند، چون منتظر دانلود فایل اصلی CSS نمی‌ماند. تجربه‌ی من از پیاده‌سازی این تکنیک در چند پروژه: کاهش محسوس در FCP و LCP. اما نکات مهم:

Critical CSS باید کوچک باشد. هدف این است که در چند کیلوبایت اول، تجربه‌ی اولیه‌ی صفحه کامل باشد. اگر خودش ۳۰ کیلوبایت شود، مزیتش از بین می‌رود.
استخراج دستی زمان‌بر است. ابزارهایی مثل Critical و Penthouse این کار را خودکار می‌کنند، اما همیشه نیاز به بازبینی دستی دارند.
مدیریت چرخه‌ی آپدیت سخت است. هر بار که CSS اصلی تغییر می‌کند، باید Critical CSS بازتولید شود. بدون CI/CD مناسب، این یکی از بزرگ‌ترین منابع ناهماهنگی است.

در پروژه‌های وردپرسی، افزونه‌های بهینه‌سازی (مثل WP Rocket) قابلیت تولید Critical CSS را دارند. اما قبل از فعال‌سازی، مطمئن شوید که قالب شما با آن سازگار است. قالب سبک معمولاً با این ابزارها بهتر کار می‌کند.

حذف CSS بلااستفاده: چالش واقعی

ابزارهای مدرن می‌توانند تشخیص بدهند کدام قواعد CSS در صفحه استفاده نمی‌شوند. اما حذف آن‌ها در پروژه‌های واقعی چالش‌های جدی دارد:

استایل‌های داینامیک: اگر از جاوااسکریپت برای افزودن کلاس استفاده می‌کنید (مثلاً .is-open یا .has-error)، ابزار تشخیص، این‌ها را به‌عنوان بلااستفاده در نظر می‌گیرد چون در HTML اولیه نیستند.
وضعیت‌های تعاملی: :hover، :focus، :active فقط در زمان تعامل فعال می‌شوند و ابزار ممکن است آن‌ها را نبیند.
صفحات مختلف سایت: CSS مشترک ممکن است در صفحه‌ی فعلی استفاده نشود اما در صفحات دیگر حیاتی باشد. حذف آن، بقیه‌ی سایت را می‌شکند.

روش عملی که در پروژه‌ها به‌کار می‌برم، سه مرحله دارد:

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

در پروژه‌ای که با قالب آماده‌ی هفت‌ساله کار می‌کردیم، این فرآیند حجم CSS را از ۲۲۰ کیلوبایت به ۹۰ کیلوبایت رساند بدون از‌دست‌دادن ظاهر. اما آن پروژه سه روز کار زمان برد. اگر با قالب‌های آماده کار می‌کنید، معمولاً ابزارهایی مثل PurgeCSS یا قابلیت‌های قالب‌های مدرن این کار را ساده‌تر کرده‌اند. بررسی کنید که قالب شما چه ابزارهایی دارد.

هزینه‌ی پنهان انتخابگرها

موتور CSS از راست به چپ انتخابگرها را تطبیق می‌دهد. یعنی برای .sidebar li a، مرورگر ابتدا تمام aهای صفحه را پیدا می‌کند، سپس آن‌هایی که داخل li هستند، و در نهایت آن‌هایی که داخل .sidebar هستند. اگر صفحه شما ۲۰۰۰ لینک داشته باشد، این تطبیق می‌تواند گران شود.

سه نوع انتخابگر که در پروژه‌ها اثر محسوس داشته‌اند:

نوع انتخابگر	هزینه	جایگزین پیشنهادی
عمومی (`*`)	بالا در ساختارهای بزرگ	استفاده‌ی هدفمند در ریست سراسری
عمیق (چندین سطح تودرتو)	بالا	یک کلاس مستقیم روی عنصر هدف
ویژگی عمومی (`[class*="btn"]`)	متوسط	کلاس‌های مشخص
کلاس ساده (`.button`)	پایین	استاندارد پیشنهادی
شبه‌کلاس‌ها (`:hover`)	پایین تا متوسط	استفاده‌ی معمولی مشکلی ندارد
`:has()` و `:nth-child()` پیچیده	بالا	استفاده‌ی محدود و هدفمند

در پروژه‌ای که بازبینی کردم، فایل CSS شامل بیش از ۸۰ قاعده با انتخابگرهای سه یا چهار سطحی بود. پس از ساده‌سازی به کلاس‌های مستقیم، زمان Style Calculation محسوس کاهش پیدا کرد. اگر می‌خواهید اصول انتخابگرها را در سطح پایه مرور کنید، انتخابگرهای CSS نقشه‌ی کامل را می‌دهد.

انتخابگر پیچیده، یعنی پیدا کردن یک سوزن در انبار کاه؛ انتخابگر ساده یعنی خودِ سوزن با آدرس مشخص. تفاوت هزینه در ساختارهای بزرگ، غیرقابل چشم‌پوشی است.

بدهی specificity و راه‌های کاهش آن

specificity یک مفهوم بنیادین در CSS است که در پروژه‌های طولانی به یک بدهی فنی تبدیل می‌شود. هر چه بیشتر از انتخابگرهای با specificity بالا استفاده کنید، در آینده برای override کردن آن‌ها به !important یا انتخابگرهای پیچیده‌تر نیاز دارید و این چرخه ادامه پیدا می‌کند.

سه رویکرد عملی که در پروژه‌ها به‌کار برده‌ام:

استفاده از :where() برای ریست‌های سراسری: :where() specificity صفر دارد، بنابراین می‌توانید ریست‌های سراسری با آن بنویسید بدون اینکه بعداً نیاز به override داشته باشید.
کلاس‌های معنادار به‌جای انتخابگرهای مبتنی بر ساختار: .card__title بهتر از .card > h3 است، چون در صورت تغییر ساختار HTML، خراب نمی‌شود.
مدیریت specificity در سطح معماری: از همان اول یک سلسله‌مراتب مشخص تعریف کنید. در پروژه‌های خودم معمولاً از الگوی زیر استفاده می‌کنم: ریست‌ها ← لایه‌ی پایه ← کامپوننت‌ها ← یوتیلیتی‌ها ← اورایدها. هر لایه‌ی بالاتر می‌تواند لایه‌ی پایین‌تر را با اطمینان override کند.

برای مشاهده‌ی این مفهوم در چارچوب متغیرهای CSS و interaction آن با معماری، CSS مدرن از Flexbox تا Grid دید وسیع‌تری می‌دهد.

layout، paint و composite: انتخاب‌های درست

یکی از اصلی‌ترین عوامل مؤثر بر کارایی CSS، نوع خاصیتی است که تغییر می‌دهید. خاصیت‌ها به سه دسته تقسیم می‌شوند:

Composite-only: transform و opacity. سریع‌ترین نوع تغییر؛ روی GPU اجرا می‌شوند و main thread را درگیر نمی‌کنند.
Paint-triggering: color، background، box-shadow. مرورگر ناحیه‌ی مربوطه را دوباره رنگ می‌کند، اما layout تغییر نمی‌کند.
Layout-triggering: width، height، margin، padding، top، left، font-size. این‌ها در هر تغییر، کل چیدمان درخت DOM را تحریک می‌کنند و در سایت‌های بزرگ می‌توانند به‌شدت کند شوند.

در پروژه‌ای که داشبورد مدیریتی با انیمیشن‌های زیاد داشتیم، بیش از ۶۰٪ انیمیشن‌ها روی خاصیت‌های دسته‌ی سوم اجرا می‌شدند. بازنویسی آن‌ها با transform و opacity باعث شد در گوشی‌های میان‌رده، تجربه به‌طور محسوس روان‌تر شود. جزئیات این بازنویسی در انیمیشن در CSS و ترنزیشن در CSS آمده است.

تکنیک‌هایی که در پروژه‌ها اثر گذاشتند

پنج تکنیک که در ده‌ها پروژه به‌طور مکرر نتیجه داده‌اند:

توزیع CSS بر اساس نیاز صفحه: به‌جای یک فایل غول سراسری، فایل‌های CSS را بر اساس نوع صفحه تقسیم کنید (خانه، محصول، سبد خرید). ابزارهایی مثل WP Rocket این کار را خودکار انجام می‌دهند.
تعویق CSS غیر‌حیاتی: استایل‌های پایین صفحه را با media="print" و onload به‌صورت async لود کنید.
حذف فونت‌های بلااستفاده: اگر از فونت آیکون استفاده می‌کنید، فقط گلیف‌های استفاده‌شده را نگه دارید. فونت آیکونی با ۵۰۰ گلیف که فقط ۲۰ تای آن‌ها استفاده می‌شود، ۹۵٪ حجم اضافه است.
ترکیب متغیرهای CSS با فایل‌های theme.json در وردپرس: در پروژه‌های جدید، تنظیمات رنگ و فاصله را در theme.json می‌گذارم و در قالب فقط از متغیرهای CSS استفاده می‌کنم. نتیجه، حجم CSS کمتر و انعطاف بیشتر.
پیش‌بارگذاری فونت‌های حیاتی: با <link rel="preload">، فونت اصلی سایت را سریع‌تر آماده کنید.

برای اینکه این تکنیک‌ها روی چیدمان شما اثر منفی نگذارند، پیشنهاد می‌کنم فلکس باکس در CSS، گرید در CSS و ریسپانسیو با CSS را در کنار این بخش مرور کنید. اگر روی وردپرس هستید، این تکنیک‌ها را در قالب چایلد پیاده کنید تا با آپدیت قالب اصلی از دست نروند.

اشتباهاتی که بهینه‌سازی را خنثی می‌کنند

تکیه فقط بر minify و gzip: این‌ها لازم‌اند اما اثرشان در برابر بهینه‌سازی معماری، ناچیز است.
استفاده از چند ابزار بهینه‌سازی هم‌زمان: Autoptimize + WP Rocket + افزونه‌ی minify قالب = ترکیب مخرب. یکی را انتخاب کنید و بگذارید کارش را بکند.
حذف CSS بلااستفاده بدون بررسی کد جاوااسکریپت: این یکی از پرتکرارترین اشتباهات است. قواعدی که به کلاس‌های داینامیک تعلق دارند، ممکن است حذف شوند و بعداً در حین تعامل، باگ‌های عجیب ایجاد کنند.
نادیده گرفتن رفتار واقعی مرورگر: بهینه‌سازی روی DevTools دسکتاپ، با بهینه‌سازی برای گوشی میان‌رده یکی نیست. همیشه روی دستگاه واقعی تست کنید.
فشرده‌سازی تهاجمی که خوانایی را از بین می‌برد: minify خوب است اما Obfuscate و کوتاه کردن افراطی نام‌ها، نگهداری را در بلندمدت به کابوس تبدیل می‌کند. در پروژه‌های خودم، بین فشرده‌سازی و خوانایی، معمولاً توازن را حفظ می‌کنم.

بخشی از این اشتباهات در اشتباهات رایج طراحی ریسپانسیو و دلایل کندی قالب هم آمده است.

اندازه‌گیری و پروفایلینگ واقعی

بدون اندازه‌گیری، هر بهینه‌سازی حدس است. سه ابزار که در پروژه‌هایم به‌کار می‌برم:

Performance Tab در Chrome DevTools: ضبط کامل چرخه‌ی بارگذاری صفحه، سپس بررسی بخش‌های «Recalculate Style» و «Layout». هر نوار زرد یا بنفش، یک فرصت بهینه‌سازی است.
Coverage Tab در Chrome DevTools: نشان می‌دهد چه مقدار از CSS و JS بارگذاری‌شده استفاده نشده است. این ابزار نقطه‌ی شروع خوبی برای حذف CSS بلااستفاده است.
Lighthouse: برای ارزیابی کلی و کشف مسائل پنهان. اما برای عیب‌یابی عمیق، Performance Tab برنده است.

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

لایه‌ای پایین‌تر: موتور رندر و CSS شما

اینجا وارد لایه‌ای می‌شوم که در پروژه‌های معمولی به آن نگاه نمی‌شود اما برای مهندسان پلتفرم و توسعه‌دهنده‌های ارشد اهمیت دارد. آنچه موتور رندر با CSS شما می‌کند، در پنج مفهوم خلاصه می‌شود:

Selector Matching Algorithm و Bloom Filter: مرورگرها برای بهینه‌سازی تطبیق انتخابگرها، از ساختارهای داده مثل Bloom Filter روی کلاس‌ها و IDها استفاده می‌کنند. این ساختار به سرعت می‌گوید «این عنصر اصلاً این کلاس را ندارد»، اما اگر جواب مثبت باشد، هنوز باید دقیق بررسی کند. نتیجه‌ی عملی: انتخابگرهایی که روی کلاس‌های پرکاربرد (مثل .container یا .row) کار می‌کنند، باعث می‌شوند Bloom Filter کمکی نکند و موتور مجبور شود برای هر عنصر، تطبیق را کامل انجام دهد. راه‌حل: کلاس‌های هدفمند و خاص در کنار کلاس‌های عمومی.
Style Invalidation و Impact Scope: وقتی یک کلاس به یک عنصر اضافه یا حذف می‌شود، مرورگر باید تعیین کند کدام عناصر دیگر ممکن است تحت تأثیر قرار بگیرند. اگر انتخابگرهای شما عمیق و ساختار-محور باشند، دامنه‌ی invalidation گسترده می‌شود. در پروژه‌ای که روی جدول بزرگ کار می‌کردیم، تغییر یک کلاس روی body باعث می‌شد مرورگر برای تمام عناصر داخل، style را دوباره محاسبه کند؛ در حالی که اگر کلاس روی خود عنصر هدف بود، فقط همان محدوده تحت تأثیر قرار می‌گرفت. برای درک موازی این لایه با جاوااسکریپت، بهینه سازی جاوااسکریپت را ببینید.
Computed Style و Layout Cache: مرورگرها نتایج محاسبات style و layout را کش می‌کنند. اما این کش وقتی نامعتبر می‌شود که یک تغییر، در محدوده‌ی وابستگی‌های آن کش قرار بگیرد. کلاس‌هایی که وابستگی‌های زیادی ایجاد می‌کنند (مثل تغییر متغیرهای CSS در سطح :root) می‌توانند این کش را در دامنه‌ی وسیعی بی‌اعتبار کنند. به همین دلیل، در پروژه‌های پرتعامل، تغییر متغیر در سطح :root را محدود به تغییرات واقعاً سراسری می‌کنم و برای تغییرات جزئی، از سطح کامپوننت استفاده می‌کنم. اگر می‌خواهید این مفهوم را در چارچوب متغیرهای CSS عمیق‌تر ببینید، به آن مقاله مراجعه کنید.
Animation Performance Model: هر انیمیشنی که از transform و opacity استفاده کند، به‌طور خودکار به یک لایه‌ی compositor ارتقا می‌یابد. اما هر لایه‌ی اضافه، حافظه‌ی GPU مصرف می‌کند و تعداد بالای لایه‌ها می‌تواند خودش به گلوگاه تبدیل شود. در پروژه‌ای که بیش از ۲۰۰ عنصر انیمیت‌شده داشتیم، محدود کردن لایه‌های compositor به عناصر واقعاً حیاتی، مصرف حافظه‌ی GPU را محسوس کاهش داد. مطالعه‌ی این تعادل در انیمیشن در CSS آمده است.
Interaction با فریم‌ورک‌ها و CSS-in-JS: اگر در React از Styled Components یا Emotion استفاده می‌کنید، هر رندر ممکن است کلاس‌های جدیدی تولید کند که باعث invalidation سبک می‌شود. این هزینه در پروژه‌های بزرگ با کامپوننت‌های تکراری، به‌طور محسوس بالاست. راه‌حل‌های مدرن: تعریف یک لایه‌ی متغیر در :root و تغییر آن با JS، بدون تولید کلاس جدید. برای مطالعه‌ی موازی با کارایی کلی، بهینه‌سازی سرعت سایت و مفاهیم پیشرفته جاوااسکریپت را در کنار این بخش ببینید.

یک تجربه‌ی واقعی از پروژه‌ی فروشگاهی که با مسئله‌ی Style Invalidation مواجه شدیم: در یک صفحه‌ی لیست محصولات با بیش از ۵۰۰ آیتم، هر بار که کاربر فیلتری را فعال می‌کرد، کلاس‌ها روی body تغییر می‌کردند. نتیجه: مرورگر مجبور بود برای تمام ۵۰۰ محصول، محاسبه‌ی استایل را از نو انجام دهد. با انتقال این کلاس‌ها به سطح container محصولات و محدود کردن دامنه‌ی invalidation، زمان پاسخ فیلتر از ۸۰۰ میلی‌ثانیه به ۲۵۰ میلی‌ثانیه کاهش پیدا کرد. اگر روی پروژه‌های وردپرسی هستید، پیشنهاد می‌کنم دلایل کندی قالب و قالب سبک را در کنار این بخش ببینید؛ چون مهاجرت به یک بستر سبک‌تر، امکان اعمال این نوع بهینه‌سازی‌ها را بیشتر می‌کند. برای درک این لایه در چارچوب استانداردها، استانداردهای HTML و CSS و CSS مدرن از Flexbox تا Grid دید وسیع‌تری می‌دهند. اگر روی انتخابگرها و interaction آن‌ها با موتور رندر متمرکز هستید، انتخابگرهای CSS را هم ببینید.

بهینه سازی CSS دو مرحله دارد: در مرحله‌ی اول فایل را سبک می‌کنید، در مرحله‌ی دوم به مرورگر یاد می‌دهید چطور سریع‌تر آن را بفهمد. اکثر پروژه‌ها در مرحله‌ی اول می‌مانند و فکر می‌کنند کار تمام شده است.

آخرین کلمه این مسیر

بهینه سازی CSS را می‌توان در یک جمله خلاصه کرد: «لایه‌ی اول کاهش حجم، لایه‌ی دوم رفتار runtime، لایه‌ی سوم اندازه‌گیری مداوم.» سه درس که از این مسیر با خودم بردم:

همیشه اول اندازه بگیرید. بدون پروفایلر، هر بهینه‌سازی حدس است. Performance Tab و Coverage Tab دو ابزاری هستند که در هر پروژه باید باز باشند.
به رفتار موتور رندر فکر کنید، نه فقط به حجم فایل. یک فایل سبک با انتخابگرهای عمیق، می‌تواند کندتر از یک فایل سنگین با انتخابگرهای ساده باشد. انتخاب‌های معماری، همیشه برنده‌اند.
Critical CSS و توزیع هوشمند، بزرگ‌ترین بردها هستند. اگر قرار است فقط یک سرمایه‌گذاری انجام دهید، روی این دو تمرکز کنید. در پروژه‌های من، این دو تکنیک بیشترین اثر را بر تجربه‌ی واقعی کاربر گذاشته‌اند.

مسیر یادگیری CSS با این نوشته تمام نمی‌شود. اگر می‌خواهید مرحله‌ی بعدی را بردارید، متغیرهای CSS، ریسپانسیو با CSS و مدیا کوئری در CSS سه قدم منطقی بعدی هستند. اگر هم به سمت بستر و زیرساخت می‌روید، بهینه‌سازی سرعت سایت، افزایش سرعت وردپرس و تأثیر هاست بر سرعت دید وسیع‌تری می‌دهند.

اگر در پروژه‌ای با یک مورد عجیب روبرو شده‌اید — مثلاً قالبی که حجم CSS آن کم است اما در پروفایلر زمان Style Calculation بالایی دارد، یا صفحه‌ای که فقط در فیلتر کردن محصولات کند می‌شود — جزئیات سناریو را در دیدگاه بنویسید. مخصوصاً اگر با تفکیک دامنه‌ی invalidation یا انتقال کلاس‌ها به سطح container به نتیجه‌ی محسوسی رسیده‌اید، همان تجربه برای خواننده‌ی بعدی از هر توضیح کلی ارزشمندتر است. ⚡