What does the critical CSS technique actually do?

Extracts the CSS for above-the-fold content, inlines it in the head, and defers the rest of the stylesheet

Deletes all CSS from the page to speed it up

Compresses images so the page paints faster

Blocks the browser from loading any CSS until the page is interactive

How does Google frame critical CSS in its own documentation?

As an advanced, optional technique that most sites don't need to hit their performance targets

As a required optimization every site must implement

As a direct Google ranking factor

Why can critical CSS make a visitor's second page view slower?

Inlined CSS isn't cached, so it's re-downloaded inside every HTML response instead of reused

It permanently disables the browser cache for the whole site

It forces the browser to reload all images on every page

It adds a mandatory redirect before every page

Before implementing critical CSS, what should you confirm first?

That CSS — not render-blocking JavaScript or a slow server response — is actually your rendering bottleneck

That you have inlined every stylesheet on the site

That Bing has a critical CSS guideline you can follow

How does critical CSS relate to SEO rankings?

Only indirectly — faster paint can improve LCP, a Core Web Vitals metric, but CSS itself isn't a direct ranking signal

It's a direct ranking signal because Google reads your CSS class names

It has no connection to SEO at all

It guarantees a first-page ranking if implemented correctly

CSS الحرج

الخلاصة — CSS الحرج حيلة لتحسين السرعة: خذ فقط الأنماط اللازمة للجزء الذي يراه الزائر أولاً من الصفحة، وضعها مباشرة داخل HTML، ثم حمّل بقية ورقة الأنماط لاحقاً. يمكنه أن يجعل الصفحة تبدو أسرع، لكن Google نفسها تقول إن معظم المواقع لا تحتاج إليه، وله سلبيات حقيقية. شخّص المشكلة قبل اللجوء إليه.

ما CSS الحرج؟

عندما يحمّل المتصفح صفحة، لا يرسم شيئاً على الشاشة قبل قراءة CSS. هذا مقصود، وإلا لظهرت الصفحة بلا تنسيق ثم تحركت عناصرها. لكنه يعني أن ورقة أنماط بطيئة أو ضخمة قد تؤخر أول عملية رسم كاملة.

يمثل CSS الحرج إحدى طرق تجاوز ذلك. وتتكون الفكرة من جزأين:

ضمّن الأنماط المهمة. استخرج CSS اللازم فقط للمحتوى الظاهر قبل التمرير (above the fold)، وضعه مباشرة في <head> الصفحة. عندئذ يملك المتصفح ما يحتاجه لرسم أعلى الصفحة من دون انتظار ملف منفصل.
أجّل البقية. حمّل ورقة الأنماط الكاملة بصورة غير متزامنة كي لا تحجب أول رسم. تصل بعد لحظة وتنسق بقية الصفحة.

يعرّفه فريق web.dev لدى Google بأنه تقنية تستخرج CSS الخاص بالمحتوى الظاهر قبل التمرير لعرض المحتوى للمستخدم بأسرع ما يمكن.

ما يخطئ فيه معظم الناس

تعرض معظم المقالات CSS الحرج على أنه شيء ينبغي تنفيذه. لكن وثائق Google نفسها تقول العكس لمعظم المواقع: ينبغي أن تتمكن معظم المواقع من بلوغ جميع أهداف الأداء الموصى بها من دون تنفيذ هذه التقنية. إنه تحسين متقدم يُلجأ إليه أخيراً، لا خانة افتراضية ينبغي تحديدها.

كما أنه ليس مجانياً. عندما تضمّن CSS داخل HTML، لا يستطيع المتصفح تخزينه مؤقتاً لصفحاتك الأخرى كما يفعل مع ورقة أنماط عادية؛ ولذلك قد يكون عرض الصفحة الثاني للزائر أبطأ فعلاً. ويجب أيضاً صيانة الفصل بين «الحرج» و«البقية»، إذ قد يؤدي تغيير القالب إلى تعطيله بصمت.

هل يساعد تحسين محركات البحث؟

بصورة غير مباشرة فقط. لا يُقرأ CSS نفسه بوصفه إشارة ترتيب؛ فقد قال Martin Splitt من Google إن أسماء فئات CSS لا تهمهم. ما قد يحسنه CSS الحرج هو سرعة ظهور الصفحة، وهو ما يغذي مؤشرات أداء الويب الأساسية، وتحديداً LCP، التي تمثل مدخلاً صغيراً للترتيب. لذا فالمسار هو: رسم أسرع ← LCP أفضل ← فائدة متواضعة لتحسين محركات البحث، وليس «CSS الحرج عامل ترتيب».

هل تريد النسخة المتعمقة التي تشرح التنفيذ، وموقف Google الفعلي، والمقايضات، وكيفية معرفة ما إذا كان CSS هو عنق الزجاجة أصلاً؟ انتقل إلى تبويب المتقدم.

الخلاصة — CSS الحرج = استخراج أنماط الجزء الظاهر قبل التمرير، وتضمينها في <head>، وتأجيل بقية ورقة الأنماط بصورة غير متزامنة (تبديل rel="preload" مع onload، أو بديل <noscript>، أو loadCSS). يعمل لأن CSS يحجب العرض افتراضياً. محور الدقة: تقدمه Google بوصفه تقنية متقدمة واختيارية، لا نصيحة افتراضية — “Most sites should be able to achieve all of our recommended performance targets without implementing this technique.” (ترجمة) «ينبغي أن تتمكن معظم المواقع من بلوغ جميع أهداف الأداء الموصى بها من دون تنفيذ هذه التقنية». أبقِ الحمولة المضمنة صغيرة. المقايضات حقيقية: لا يُخزن CSS المضمن مؤقتاً بين تحميلات الصفحات، فيمكن أن تكون الزيارات المتكررة أبطأ؛ وينكسر الفصل بين الحرج وغير الحرج مع تغير القوالب؛ وقد يتسابق التأجيل أو يسبب FOUC/CLS. شخّص أولاً: تأكد أن CSS، لا JavaScript أو زمن الخادم، هو عنق الزجاجة الفعلي. وانتبه لمخاطر لا يكشفها العرض السريع: يمكن لسياسة CSP style-src حجب كتلة <style> المضمنة تماماً، وكون النمط «غير مستخدم وقت الالتقاط» لا يعني أنه «آمن للتأجيل» عبر السمات والتخصيص والحالات، كما أن التضمين لا يحل توقيت تحميل الخطوط. أثر SEO غير مباشر عبر Core Web Vitals/LCP، ولا توجد إرشادات خاصة بـ Bing.

ما CSS الحرج فعلياً؟

المشكلة التي يحلها هي CSS الحاجب للعرض. توضح web.dev من Google: يُعامل CSS افتراضياً بوصفه مورداً حاجباً للعرض، ما يعني أن المتصفح لن يعرض أي محتوى معالج حتى بناء CSSOM. وهذا هو سبب وجود التقنية: يرفض المتصفح الرسم حتى يحصل على الأنماط، لذلك يؤخر كل ما يؤخر CSS أول رسم. ولرؤية المسار الكامل الكامن خلف ذلك، راجع مركز مسار العرض الحرج الذي تندرج تحته هذه الصفحة، ومقاله الشقيق عن الموارد الحاجبة للعرض.

يعالج CSS الحرج ذلك بتقسيم CSS إلى جزأين. وفق تعريف web.dev: “Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible.” (ترجمة) «CSS الحرج تقنية تستخرج CSS الخاص بالمحتوى الظاهر قبل التمرير لعرض المحتوى للمستخدم بأسرع ما يمكن». أما الآلية فهي: يؤدي تضمين الأنماط المستخرجة في <head> مستند HTML إلى إلغاء الحاجة إلى طلب إضافي لجلبها، ويمكن تحميل بقية CSS بصورة غير متزامنة.

تصرح web.dev بنقطة تتجاوزها أدلة ثانوية كثيرة: لا يوجد ارتفاع واحد وعالمي للجزء الظاهر قبل التمرير. فحجم الجهاز واتجاهه، وواجهة المتصفح، ومستوى التكبير، وحالة الصفحة مثل قائمة مفتوحة أو تخصيص محمّل أو حالة خطأ، كلها تغير ما يجب أن يدخل فعلياً في المجموعة «الحرجة». عامل CSS الحرج كقرار بشأن إطار عرض وحالة أوليين مختارين، لا كحد ثابت بالبكسل، واختبره على نقاط التوقف والحالات الحقيقية، لا على لقطة شاشة مكتبية واحدة.

إذن فله مهمتان بالترتيب:

ضمّن الحد الأدنى من CSS الخاص بالجزء الظاهر قبل التمرير في <head>، من دون رحلة شبكة إضافية قبل أول رسم.
أجّل بقية ورقة الأنماط، وحمّلها بصورة غير متزامنة كي لا تحجب أول رسم.

وهكذا تماماً قسمته في محاضراتي عن تجربة الصفحة. ففي عرضي ما التالي لتجربة الصفحة؟ في SMX Next 2021 وضعت عمل CSS في مجموعتين: مسار مبكر/حرج (إزالة CSS غير المستخدم ← تصغير CSS ← تضمين CSS الحرج)، ومسار متأخر/مؤجل (تأجيل CSS غير الحرج). إنه الشكل نفسه لدى web.dev، لكن مرتب بالطريقة التي أفكر بها.

كيفية تنفيذه

الخطوة 1 — ضمّن CSS الحرج. توصي Lighthouse نفسها بتضمين الأنماط الحرجة اللازمة لأول رسم داخل كتلة <style> في رأس صفحة HTML. وهدف Google لحجم تلك الحمولة المضمنة، من الصفحة نفسها، هو إبقاء محتوى الجزء الظاهر قبل التمرير دون 14 KB بعد الضغط كي يلائم أول رحلة عبر الشبكة. عامل هذا الرقم بوصفه إرشاد نقل تاريخياً، لا مواصفة خالدة؛ فالصفحة مؤرخة في 2019 وتسبق الانتشار الواسع الحالي لـ HTTP/2 وHTTP/3، وكلاهما يغير حساب الرحلة الأولى. لا يزال الرقم الذي تستشهد به وثائق Google، لكن عند الضبط الدقيق تحقّق منه مقابل البروتوكول الحالي وسلوك خادمك بدلاً من اعتبار 14 KB حقيقة مطلقة.

الخطوة 2 — أجّل البقية. النمط الذي توصي به web.dev من أجل تأجيل CSS غير الحرج هو تحميل مسبق مع تبديل onload وإضافة بديل <noscript>:

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

تنصح web.dev في الإنتاج باستخدام دوال لتأجيل CSS مثل loadCSS، تغلف هذا السلوك وتعمل جيداً عبر المتصفحات بدلاً من بناء التبديل يدوياً. وإذا أجّلت باستخدام JavaScript، فتشير web.dev إلى أن انتظار تنفيذ JavaScript قبل تحميل CSS غير الحرج قد يؤخر العرض عندما يمرر المستخدم، ولهذا يُستخدم preload لبدء التنزيل في وقت أبكر.

الأدوات. نادراً ما تستخرج CSS الحرج يدوياً. التنفيذ المرجعي لدى Google هو حزمة npm المسماة critical من Addy Osmani، وهي “a tool that extracts, minifies and inlines above-the-fold CSS.” (ترجمة) «أداة تستخرج CSS للجزء الظاهر قبل التمرير وتصغّره وتضمّنه». وتشمل البدائل Penthouse وCriticalCSS ومجموعة من مولدات SaaS والإضافات لـ WordPress وShopify. ولتحديد القواعد الحرجة بنفسك، توجهك Google إلى تبويب Coverage في Chrome DevTools لتحديد CSS وJS غير الحرجين.

إذا كنت تستخدم إضافة أو مولداً مثل WP Rocket أو Autoptimize، فلا تعامل شرح واجهة المورّد أو لقطة درجة قبل/بعد بوصفها ضماناً للمنصة؛ فهذه الصفحات تخلط إصدارات المنتج ونتائج مواقع بعينها، ولم تُعد فروق الدرجات بصورة مستقلة. قبل الوثوق بها في الإنتاج، أكد السلوك مقابل الوثائق الحالية للإضافة ورقم إصدارها، واخضعها لمصفوفة الاختبار نفسها التي تستخدمها لتنفيذ يدوي: تحميلات باردة ومتكررة، ونقاط التوقف والسمات والحالات الحقيقية، وسياسة CSP إن كانت مطبقة.

لاحظ أن CSS الحرج ليس سوى أحد حلول CSS الحاجب للعرض. تشمل الحلول الأخرى تقييد نطاق أوراق الأنماط بسمة media كي تُنزّل من دون حجب الرسم، وشحن CSS أقل من الأصل. بل تميل مقالة web.dev عن حجب العرض إلى نهج سمة media بدلاً من التضمين، ولذلك لدى Google أكثر من وصفة رسمية بحسب الوثيقة التي تقرؤها.

موقف Google الفعلي: محور الدقة

هذا هو الجزء الذي تدفنه معظم المقالات المنافسة، وهو سبب رغبتي في كتابة المقال. لا تقدم Google CSS الحرج بوصفه نصيحة افتراضية. يصرح مختبرها التعليمي بالمخاطر: يشرح هذا المختبر تقنية أداء متقدمة يمكن أن تحسن الأداء، لكنها قد تؤدي أيضاً إلى أخطاء إن لم تُنفذ بصورة صحيحة. وتقول Google مرتين في وثائقها إن معظم المواقع لا ينبغي أن تلجأ إليه: ينبغي أن تتمكن معظم المواقع من بلوغ جميع أهداف الأداء الموصى بها من دون تنفيذ هذه التقنية.

حتى الفائدة تأتي مع تحذير. توضح web.dev أن للتضمين سلبيات لأنه يمنع المتصفح من تخزين CSS مؤقتاً لإعادة استخدامه في تحميلات الصفحات اللاحقة، ولذلك يُفضل استخدامه باعتدال، وعن الإفراط تقول: إذا أُعطيت الأولوية لكل شيء فلن تكون لأي شيء أولوية. يؤدي الإفراط في التضمين إلى تضخيم HTML الذي تحاول إرساله بسرعة.

إذن الصياغة الصادقة هي أن CSS الحرج تقنية حقيقية وموثقة وقد تكون قوية أحياناً، لكنها متقدمة واختيارية ويُلجأ إليها أخيراً، وتقول Google إن معظم المواقع لا تحتاج إليها لبلوغ أهدافها. تعامل معها على هذا الأساس.

المقايضات الحقيقية

كان مهندسو الأداء المستقلون أعلى الأصوات هنا، وتتفق آراؤهم مع تحذيرات Google.

فقدان التخزين المؤقت في الزيارات المتكررة. يصرح Matt Zeunert من DebugBear: لا يمكن إعادة استخدام CSS الحرج بين تحميلات الصفحات المختلفة في موقعك، ولذلك قد تكون عروض الصفحات اللاحقة أبطأ فعلاً مما ستكون عليه من دونه. تُخزن ورقة الأنماط الخارجية العادية مرة واحدة ويعاد استخدامها في كل مكان، بينما يعاد تنزيل CSS المضمن داخل كل استجابة HTML.

خطر الصيانة والانحدار. تعد مقالة Harry Roberts المخالفة للرأي السائد أشهر الآراء، وتحذر من أن إضافة CSS الحرج إلى نظام قائم أمر صعب وعرضة للأخطاء. وبعد تحديد CSS بوصفه عنق الزجاجة، “you need to keep it that way… One wrong decision can undo everything.” (ترجمة) «عليك أن تبقيه كذلك… فقرار خاطئ واحد قد يبطل كل شيء». لا توجد إعادة تحقق تلقائية؛ فقد يكسر تغيير في القالب أو التصميم الفصل بين الحرج وغير الحرج بصمت.

حالات التسابق في التأجيل. يشير Roberts أيضاً إلى أن تبديل preload/onload قد ينقلب ضدك في التوقيت: إذا استغرق تحليل <head> ثانية واحدة وجلب CSS غير الحرج بصورة غير متزامنة 0,5 ثانية، فسيعود CSS ملفاً متزامناً قبل أن تصبح مستعداً بـ 0,5 ثانية. وعندما يصل CSS غير الحرج متأخراً، تخاطر بوميض محتوى غير منسق وتحول في التخطيط.

غالباً لا يكون عنق الزجاجة أصلاً. خلاصة Roberts: لا يساعد CSS الحرج إلا إذا كان CSS أكبر عنق زجاجة حاجب للعرض، وغالباً لا يكون كذلك. ويوافق DebugBear: افحص قبل التضمين ما إذا كان CSS هو المشكلة فعلاً، لأن وجود JavaScript حاجب للعرض يعني أن تضمين CSS لن يساعد على الأرجح، وأن “often it’s not the most impactful optimization.” (ترجمة) «غالباً لا يكون التحسين الأكبر أثراً».

مخاطر الإنتاج: CSP والحالة والخطوط

ثمة ثلاثة أنماط فشل إضافية لا تظهر في عرض سريع، لكنها تؤذيك بعد الإطلاق:

يمكن لسياسة CSP حجب كتلة <style> المضمنة تماماً. قد تحجب سياسة Content-Security-Policy ذات التوجيه style-src كتلة <style> حرجة ومضمنة ما لم تسمح بها صراحة، عادة عبر nonce أو تجزئة مطابقة. توثق MDN حالات الانتهاك وآليات nonce والتجزئة. ويؤدي استخدام unsafe-inline لمجرد إزالة خطأ وحدة التحكم إلى إضعاف السياسة على الموقع كله، وليس حلاً افتراضياً. اربط توليد nonce أو التجزئة بالأداة التي تستخرج CSS الحرج، وافحص وحدة تحكم المتصفح بحثاً عن انتهاكات بعد النشر.

كونه «غير مستخدم وقت الالتقاط» لا يعني أنه «آمن للتأجيل». يخبرك تبويب Coverage بما نُفذ من CSS خلال تشغيل مسجل واحد. يجب أن يحافظ الفصل الآمن على ترتيب التتالي والقواعد اللازمة لنقاط التوقف المتجاوبة، ومتغيرات السمات، والمحتوى المخصص، وحالات التركيز، والقوائم والنوافذ المفتوحة، وحالات الخطأ؛ لا على ما ظهر في تشغيل واحد فقط. ويطرح Roberts السؤال نفسه من زاوية أخرى: أي إطار عرض وأي عناصر خارج الشاشة أو لم يتفاعل معها المستخدم، مثل القوائم المنسدلة، يجب أن يغطيها الاستخراج؟

لا يحل مشكلة الخطوط، وقد يضيف عملاً للعرض. لا يجعل تضمين أنماط العناصر خط الويب قابلاً للاكتشاف في وقت أبكر بذاته، ولا يضمن عرض النص في موعده؛ فاكتشاف الخط و preload وfont-display ومقاييس الخط البديل تبعيات منفصلة لا يمسها CSS الحرج. كما أن تطبيق مجموعة فرعية مضمنة تتبعها ورقة أنماط أكبر قد يعني إعادة حساب إضافية للأنماط والتخطيط والرسم. تقليل تأخير الجلب لا يعني تلقائياً تقليل عمل العرض كله؛ فقِس الاثنين، لا شلال الشبكة وحده.

كيف تشخّص ما إذا كنت تحتاج إليه أصلاً؟

في ضوء ذلك كله، لا تبدأ بعبارة «أضف CSS الحرج»، بل ابدأ بـ «تأكد أن CSS هو عنق زجاجة العرض لدي»، ولا تتوقف هناك. توجد أربع بوابات يجب أن تتحقق كلها قبل أن يستحق التنفيذ:

1. CSS حاجب مثبت، لا تخمين.

افتح تقرير PageSpeed Insights أو Lighthouse. منذ Lighthouse 13، انتقل تدقيق “Eliminate render-blocking resources” إلى مؤشر Render-blocking requests، ولذلك أصبحت المقالات القديمة التي تستخدم اسم التدقيق السابق قديمة.
استخدم تبويب Coverage في Chrome DevTools لمعرفة مقدار CSS وJS غير المستخدم فعلياً عند أول رسم.
افصل الأسباب. إذا كان عنق الزجاجة JavaScript حاجباً للعرض أو استجابة خادم بطيئة (TTFB)، فلن يصلحه تضمين CSS؛ عندها ستحسن الشيء الخطأ.

2. يمكنك بناء تغطية استخراج مستقرة فعلاً عبر نقاط التوقف والسمات والتخصيص والحالات التفاعلية الحقيقية، لا من لقطة شاشة مكتبية واحدة؛ راجع المخاطر أعلاه.

3. تكلفة العرض المتكرر وCSP مقبولة. لا يُخزن CSS المضمن مؤقتاً، فوازن ذلك مع عمق الجلسة المعتاد. وإذا كنت تطبق سياسة CSP style-src، فيجب ربط توليد nonce أو التجزئة بخط المعالجة قبل النشر، لا اكتشاف الحاجة إليه بعده.

4. ستصونه فعلاً. أعد التوليد عند كل تغيير في القالب أو التصميم، وأعد تشغيل مصفوفة الاختبار كاملة: التحميل البارد والمتكرر، وكل مسار وإطار عرض وحالة تدعمها، لا مجرد فحص بصري واحد بعد النشر.

إذا تحققت البوابات الأربع كلها، استحق CSS الحرج تكلفة الصيانة. وإذا فشلت أي واحدة، فالحلول الأرخص، مثل إزالة CSS غير المستخدم وتصغيره وتقييد أوراق الأنماط غير الحرجة بسمة media، هي الخيار الأفضل.

مشكلة راهنة في 2026

هناك تفصيل حي يستحق التنبيه: يوجد بلاغ مفتوح لم يُحل يفيد بأن النمط نفسه <link rel="preload" as="style"> الذي توصي به وثائق Google لتأجيل CSS بدأ يُصنف مجدداً بوصفه حاجباً للعرض بعد تحديث نقطي في Lighthouse/PSI. توثق المشكلة رقم #17031 على GitHub ظهور CSS المحمل مسبقاً باللون الأخضر في Lighthouse 13.0.1 ثم تصنيفه حاجباً للعرض في 13.3.0. وحتى وقت كتابة المصدر لا يوجد حل عام من Google، لذا عاملها كتطور جارٍ. لكن الدرس العملي ثابت: إذا صنف PSI ملف CSS المؤجل بصورة صحيحة على أنه حاجب، فقد يكون التدقيق نفسه مخطئاً؛ اقرأ التقرير نقدياً قبل افتراض أن تنفيذك معطل.

هل يساعد CSS الحرج تحسين محركات البحث؟

بصورة غير مباشرة ومتواضعة. افصل بين أمرين:

CSS ليس إشارة ترتيب مباشرة. قال Martin Splitt من Google عن أسماء فئات CSS: “I don’t think we care because the CSS class names are just that.” (ترجمة) «لا أظن أننا نهتم، لأن أسماء فئات CSS ليست سوى أسماء». يتعلق ذلك بأسماء الفئات تحديداً، لكنه يدحض الخرافة الأوسع بأن اختيارات CSS تُقرأ بوصفها مدخلاً للترتيب.
السرعة إشارة صغيرة عبر Core Web Vitals. قد يحسن CSS الحرج أول رسم، فيحسن LCP، وهو مقياس من مؤشرات أداء الويب الأساسية يغذي إشارات تجربة الصفحة لدى Google. هذه هي صلة SEO كلها: رسم أسرع، لا مكافأة على التقنية نفسها.

إذن قوة حجة CSS الحرج لتحسين محركات البحث تساوي تماماً أثره في LCP على موقعك، وهو أثر أصغر كثيراً، وفق Google ومجتمع الأداء، مما توحي به الأدوات التي تبيعه.

ماذا عن Bing؟

لا توجد إرشادات خاصة بـ Bing. بخلاف Google التي لديها عدة صفحات على web.dev ومختبر تعليمي عن التقنية، لم أجد في المصدر وثيقة مخصصة من Bing أو Microsoft عن CSS الحرج. تنطبق إرشادات Bing العامة لتجربة الصفحة، مثل إبقاء الموقع سريعاً والمحتوى الحرج قابلاً للوصول، لكن لا يوجد نظير لدى Bing لمختبر web.dev. ومن يدّعي وجود توصية محددة من Bing بشأن CSS الحرج يختلقها.

موضع هذه الصفحة

تندرج هذه الصفحة تحت مركز مسار العرض الحرج، إذ يمثل CSS الحرج أحد أساليب تقصير ذلك المسار، وهي الشقيقة العملية لمقال الموارد الحاجبة للعرض. وتظهر الفائدة، حين توجد، في أكبر رسم محتوى (LCP)، وأول رسم محتوى (FCP)، ومجموعة مؤشرات أداء الويب الأساسية الأوسع. وللصورة الأشمل للأداء، راجع مجموعة أداء الويب.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

CSS الحرج = استخراج + تضمين + تأجيل. استخرج CSS الخاص بالجزء الظاهر قبل التمرير، وضمّنه في <head>، وحمّل بقية ورقة الأنماط بصورة غير متزامنة. يعمل لأن CSS حاجب للعرض افتراضياً: “the browser won’t render any processed content until the CSSOM is constructed” (ترجمة) «لن يعرض المتصفح أي محتوى معالج حتى يُبنى CSSOM». لا يوجد ارتفاع عالمي للجزء الظاهر؛ فالجهاز والاتجاه والتكبير وحالة الصفحة تغير ما هو «حرج».
التنفيذ: ضمّن الأنماط الحرجة في كتلة <style>، وأجّل البقية بتبديل rel="preload" وonload مع بديل <noscript> أو loadCSS. أبقِ الحمولة المضمنة دون نحو 14 KB بعد الضغط، وهو إرشاد Google المؤرخ في 2019 الذي ما زال شائعاً لكن يستحق التحقق مقابل سلوك البروتوكول الحالي. الأدوات: critical من Addy Osmani وPenthouse ومولدات الإضافات، مع التحقق المستقل من ادعاءات كل إصدار. حدد القواعد الحرجة باستخدام تبويب Coverage في DevTools.
موقف Google، محور الدقة: التقنية متقدمة واختيارية وليست نصيحة افتراضية. تقول Google: “Most sites should be able to achieve all of our recommended performance targets without implementing this technique,” (ترجمة) «ينبغي أن تتمكن معظم المواقع من بلوغ جميع أهداف الأداء الموصى بها من دون تنفيذ هذه التقنية»، ويحذر المختبر من أنها “can also lead to bugs if not implemented properly.” (ترجمة) «قد تؤدي أيضاً إلى أخطاء إن لم تُنفذ بصورة صحيحة».
المقايضات: لا يُخزن CSS المضمن مؤقتاً بين تحميلات الصفحات، فتكون الزيارات المتكررة أبطأ؛ وينكسر الفصل بين الحرج وغير الحرج مع تغير القوالب أو السمات أو الحالات. ويحذر Harry Roberts: “One wrong decision can undo everything” (ترجمة) «قرار خاطئ واحد قد يبطل كل شيء». وقد تحجب سياسة CSP style-src الكتلة المضمنة بلا nonce أو تجزئة؛ وقد يتسابق تبديل preload/onload أو يسبب FOUC/CLS؛ كما أنه لا يصلح توقيت تحميل الخطوط وحده.
شخّص أولاً عبر أربع بوابات: تأكد أن CSS، لا JavaScript أو زمن استجابة الخادم، هو عنق الزجاجة الحاجب للعرض؛ وأن تغطية الاستخراج مستقرة عبر نقاط التوقف والسمات والحالات؛ وأن تكلفة العرض المتكرر وCSP مقبولة؛ وأنك ستصونه وتعيد اختباره فعلاً. إذا كان JS حاجباً فلن يساعد تضمين CSS.
أثر SEO غير مباشر: CSS ليس إشارة ترتيب مباشرة؛ والرافعة الوحيدة هي رسم أسرع ← LCP ← Core Web Vitals.
لا توجد إرشادات خاصة بـ Bing. وانتبه أيضاً إلى انحدار حي في Lighthouse 13.3.0 خلال 2026، هو المشكلة #17031، يصنف CSS المؤجل بصورة صحيحة على أنه حاجب للعرض.

الوثائق الرسمية

وثائق المصادر الأولية عن CSS الحرج والموارد الحاجبة للعرض.

Google / web.dev

استخراج CSS الحرج — التعريف الأساسي، وآلية التضمين والتأجيل، وهدف 14 KB تقريباً، وتحذير التخزين المؤقت الداعي إلى استخدامه باعتدال.
استخراج CSS الحرج وتضمينه باستخدام Critical: مختبر تعليمي — تطبيق عملي لأداة critical وتحذيرا «تقنية متقدمة… قد تؤدي إلى أخطاء» و«معظم المواقع… من دون تنفيذ هذه التقنية».
تأجيل CSS غير الحرج — نمط تأجيل rel="preload" مع onload والتوصية بـ loadCSS.
التحميل المسبق للأصول الحرجة — سبب التحميل المسبق لـ CSS المؤجل، وتحذير تأخير التمرير عند التأجيل عبر JS.
CSS الحاجب للعرض — سبب حجب CSS للعرض، ويصوغ الحل حول سمة media بدلاً من التضمين.
فهم المسار الحرج — موضع CSS الحرج في الصورة الأوسع لمسار العرض الحرج.

Lighthouse لدى Google / Chrome for Developers

إزالة الموارد الحاجبة للعرض — التدقيق الذي يقف خلف هذا العمل: تضمين الأنماط الحرجة، وتأجيل غير الحرجة، واستخدام تبويب Coverage. ملاحظة: انتقل إلى مؤشر “Render-blocking requests” منذ Lighthouse 13.
تحسين تسليم CSS (قديم/مهمل) — وثيقة PageSpeed Insights الأصلية التي أشاعت نصيحة CSS الحرج؛ مفيدة للتاريخ لا للإرشادات الحالية.

MDN

Content-Security-Policy: style-src — توثق كيف تحجب سياسة CSP style-src كتل <style> المضمنة بلا nonce أو تجزئة مطابقة، ولماذا لا يمثل unsafe-inline الحل. إنها مشكلة إنتاج تتجاوزها معظم أدلة CSS الحرج.

Bing / Microsoft

لا توجد وثائق خاصة بـ Bing عن «CSS الحرج». تنطبق إرشاداته العامة للأداء وتجربة المستخدم، مثل Site Scan في Bing Webmaster Tools، لكن لا يوجد نظير لدى Bing لمختبر web.dev عن CSS الحرج.

اقتباسات من المصادر

تصريحات موثقة من Google وweb.dev وMartin Splitt من Google وخبراء أداء مسمين في المجال. كل رابط من web.dev أو Chrome يدعم مقتطفاً نصياً يقفز مباشرة إلى المقطع المقتبس.

Google / web.dev — ماهيته وكيف يعمل

“Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible.” (ترجمة) «CSS الحرج تقنية تستخرج CSS الخاص بالمحتوى الظاهر قبل التمرير لعرض المحتوى للمستخدم بأسرع ما يمكن». انتقل إلى الاقتباس
“Inlining extracted styles in the <head> of the HTML document eliminates the need to make an additional request to fetch these styles. The remainder of the CSS can be loaded asynchronously.” (ترجمة) «يلغي تضمين الأنماط المستخرجة في <head> مستند HTML الحاجة إلى طلب إضافي لجلبها، ويمكن تحميل بقية CSS بصورة غير متزامنة». انتقل إلى الاقتباس
“By default, CSS is treated as a render-blocking resource, which means that the browser won’t render any processed content until the CSSOM is constructed.” (ترجمة) «يُعامل CSS افتراضياً بوصفه مورداً حاجباً للعرض، ما يعني أن المتصفح لن يعرض أي محتوى معالج حتى يُبنى CSSOM». انتقل إلى الاقتباس

Google / web.dev — تقنية متقدمة واختيارية: محور الدقة

“Most sites should be able to achieve all of our recommended performance targets without implementing this technique.” (ترجمة) «ينبغي أن تتمكن معظم المواقع من بلوغ جميع أهداف الأداء الموصى بها من دون تنفيذ هذه التقنية». — web.dev، مختبر استخراج CSS الحرج وتضمينه. اقرأ المختبر
“This codelab describes an advanced performance technique that can improve performance, but can also lead to bugs if not implemented properly.” (ترجمة) «يشرح هذا المختبر تقنية أداء متقدمة يمكن أن تحسن الأداء، لكنها قد تؤدي أيضاً إلى أخطاء إن لم تُنفذ بصورة صحيحة». اقرأ المختبر
وعن الإفراط في التضمين: “If everything is prioritized then nothing is.” (ترجمة) «إذا أُعطيت الأولوية لكل شيء فلن تكون لأي شيء أولوية». — web.dev، Extract critical CSS. اقرأ المقال

Google / Chrome (Lighthouse) — الوصفة التي يقدمها التدقيق نفسه

“Inline critical styles required for the first paint inside a <style> block at the head of the HTML page.” (ترجمة) «ضمّن الأنماط الحرجة اللازمة لأول رسم داخل كتلة <style> في head صفحة HTML». اقرأ التدقيق

Martin Splitt من فريق Google Search Relations (عبر Search Engine Journal)

عن كون أسماء فئات CSS إشارة ترتيب: “I don’t think it does. I don’t think we care because the CSS class names are just that.” (ترجمة) «لا أظن أنها كذلك. لا أظن أننا نهتم، لأن أسماء فئات CSS ليست سوى أسماء». اقرأ التغطية

Harry Roberts، مستشار مستقل لأداء الويب (csswizardry.com)

“Critical CSS only helps if CSS is your biggest render-blocking bottleneck, and quite often, it isn’t.” (ترجمة) «لا يساعد CSS الحرج إلا إذا كان CSS أكبر عنق زجاجة حاجب للعرض، وغالباً لا يكون كذلك». اقرأ المقال
“Retrofitting Critical CSS is difficult and error prone.” (ترجمة) «إضافة CSS الحرج إلى نظام قائم أمر صعب وعرضة للأخطاء». وعن الصيانة: “One wrong decision can undo everything.” (ترجمة) «قرار خاطئ واحد قد يبطل كل شيء». اقرأ المقال

Matt Zeunert، مؤسس DebugBear

“critical CSS can’t be re-used between different page loads on your website. So subsequent page views can actually be slower than they would be without critical CSS.” (ترجمة) «لا يمكن إعادة استخدام CSS الحرج بين تحميلات الصفحات المختلفة في موقعك، ولذلك قد تكون عروض الصفحات اللاحقة أبطأ فعلاً مما ستكون عليه من دونه». اقرأ المقال
“Before deciding to inline critical CSS, check if it’s actually the bottleneck for rendering content on your website. For example, if you still have render-blocking JavaScript code, inlining CSS is unlikely to help.” (ترجمة) «قبل أن تقرر تضمين CSS الحرج، تحقق مما إذا كان هو بالفعل عنق الزجاجة لعرض المحتوى في موقعك. فإذا ظل لديك JavaScript حاجب للعرض، مثلاً، فمن غير المرجح أن يساعد تضمين CSS». اقرأ المقال

ملاحظة: نُقلت مقاطع web.dev وChrome/Lighthouse وcsswizardry.com وDebugBear من عناوين المصادر الواردة في الملخص؛ وتُعرض بعض صفحات web.dev وChrome عبر JavaScript ولا تدعم الروابط العميقة إلى مقتطفات النص إلا في الصفحات المحددة، لذلك تشير روابط «اقرأ المقال/المختبر» العادية إلى المصدر بلا قفزة #:~:text=. نُقل قول Martin Splitt عبر تغطية Search Engine Journal، لا من نص أولي لدى Google، ويتعلق تحديداً بأسماء فئات CSS. أكد أي اقتباس مقابل مصدره الحي قبل معاملته نهائياً.

هل ينبغي لك تنفيذ CSS الحرج؟

لأن Google وHarry Roberts وDebugBear جميعاً يقولون “most sites don’t need this,” (ترجمة) «معظم المواقع لا تحتاج إليه»، فالأداة المفيدة هنا شجرة قرار تجيب: هل ينبغي أن أنفذه؟ لا دليلاً للتنفيذ. اتبعها من الأعلى إلى الأسفل.

1. هل يشير PageSpeed Insights أو Lighthouse إلى أي موارد حاجبة للعرض؟

لا ← لا تنفذه؛ فأنت تحل مشكلة غير موجودة.
نعم ← تابع.

2. هل المورد الحاجب للعرض هو CSS، أم JavaScript أو خادم بطيء (TTFB)؟

JavaScript أو TTFB ← أصلح ذلك أولاً. لن يساعد تضمين CSS إذا كان JS حاجباً أو الخادم بطيئاً وفق DebugBear. عد فقط إذا بقي CSS عنق الزجاجة بعد ذلك.
CSS ← تابع.

3. هل تستطيع بلوغ أهداف الأداء بإصلاحات CSS أرخص أولاً؟ جرب هذه بالترتيب قبل التضمين:

أزل CSS غير المستخدم باستخدام تبويب Coverage.
صغّر واضغط ورقة الأنماط.
قيّد أوراق الأنماط غير الحرجة بسمة media كي تُنزّل من دون حجب الرسم، وهو الحل المفضل لدى web.dev في وثيقتها عن CSS الحاجب للعرض.
ما زلت لا تبلغ الأهداف؟ ← تابع.

4. هل تستطيع الالتزام بصيانة الفصل بين CSS الحرج وغير الحرج عبر السمات والحالات وCSP؟ ينكسر CSS الحرج بصمت عند تغير القوالب: “one wrong decision can undo everything” (ترجمة) «قرار خاطئ واحد قد يبطل كل شيء». كما أن «غير مستخدم وقت الالتقاط» في تشغيل واحد لا يساوي «آمناً للتأجيل» عبر متغيرات السمات والمحتوى المخصص وحالات الفتح والتركيز والخطأ. وإذا كنت تطبق سياسة CSP style-src، فيجب أن يكون توليد nonce أو التجزئة جزءاً من خط المعالجة، لا فكرة لاحقة.

لا، أو القالب سريع التغير، أو لا يمكنك تغطية مصفوفة الحالات ← من المرجح أن تتجاوز تكلفة الصيانة الفائدة. فضّل الإصلاحات الأرخص أعلاه.
نعم، القالب مستقر، ويمكنك تغطية الحالات الحقيقية وإعادة التوليد عند التغييرات ← تابع.

5. هل لديك زوار كثيرون يشاهدون عدة صفحات في الجلسة؟ لا يُخزن CSS المضمن مؤقتاً، فتفقد مشاهدة الصفحة الثانية والثالثة فائدة التخزين وقد تصبح أبطأ وفق DebugBear.

نعم، جلسات عميقة متعددة الصفحات ← وازن عقوبة الزيارة المتكررة، وفكر في التضمين على قوالب الهبوط أو الدخول فقط.
معظمها دخول إلى صفحة واحدة، مثل المحتوى وصفحات الهبوط ← تابع.

إذا وصلت إلى هنا: فقد أكدت أن CSS هو عنق الزجاجة، واستنفدت الإصلاحات الأرخص، ولديك قالب مستقر وزيارات تدخل صفحة واحدة. الآن يستحق CSS الحرج التنفيذ. ولّده بأداة مثل critical أو Penthouse أو إضافة، وأبقِ الحمولة المضمنة دون نحو 14 KB بعد الضغط، وأعد التحقق بعد كل تغيير في القالب.

قائمة تحقق لتنفيذ CSS الحرج

لا تبدأ إلا بعد أن تؤكد، عبر تبويب Coverage أو PageSpeed، أن CSS هو فعلاً عنق الزجاجة الحاجب للعرض.

أنماط CSS الحرج المضادة

هذه الأخطاء المتكررة يأتي معظمها من معاملة تقنية متقدمة واختيارية كأنها افتراضية.

اللجوء إليه قبل التشخيص. هذا أكثر الأخطاء شيوعاً. إذا كان حاجب العرض JavaScript أو خادماً بطيئاً، فلن يحقق تضمين CSS شيئاً؛ إذ من غير المرجح أن يساعد تضمين CSS إن ظل لديك JavaScript حاجب للعرض. أكد أولاً أن CSS هو عنق الزجاجة.

تضمين كل شيء. يؤدي وضع ورقة الأنماط كلها داخل HTML إلى تضخيم الملف الذي تحاول إرساله بسرعة. تقول web.dev: إذا أُعطيت الأولوية لكل شيء فلن تكون لأي شيء أولوية. CSS الحرج هو الحد الأدنى للجزء الظاهر قبل التمرير، لا «كل شيء مضمناً».

تجاهل تكلفة الزيارة المتكررة. لا يُخزن CSS المضمن مؤقتاً، ولذلك قد تكون عروض الصفحات اللاحقة أبطأ فعلاً مما ستكون عليه من دون CSS الحرج. قد يؤدي تطبيقه على الموقع كله في رحلة عميقة متعددة الصفحات إلى جعل الجلسة أبطأ إجمالاً لا أسرع.

اضبطه وانسه. لا توجد إعادة تحقق تلقائية. يحذر Harry Roberts: قرار خاطئ واحد قد يبطل كل شيء. فقد يكسر تغيير في القالب الفصل بصمت، وتبدأ بشحن CSS خاطئ أو ناقص للجزء الظاهر.

معاملة إشارة PSI كدليل على أن CSS هو المشكلة. يشير التدقيق إلى موارد حاجبة للعرض، لكنه لا يثبت أن CSS هو عنق الزجاجة، وقد يصنف خطأً CSS مؤجلاً بصورة صحيحة؛ راجع انحدار Lighthouse 13.3.0 الحي، المشكلة #17031. اقرأ التقرير ولا تستجب للدرجة وحدها.

توقع دفعة مباشرة لـ SEO. CSS الحرج ليس عامل ترتيب، ولا يُقرأ CSS بوصفه إشارة ترتيب وفق Martin Splitt. الرافعة الوحيدة هي رسم أسرع ← LCP ← Core Web Vitals، وذلك فقط إذا حسنت التقنية LCP في موقعك.

نشره من دون فحص CSP. إذا كان موقعك يرسل ترويسة Content-Security-Policy بتوجيه style-src، فإن كتلة <style> مضمنة بلا nonce أو تجزئة مطابقة تُحجب تماماً. كما أن استخدام unsafe-inline لإسكات الخطأ يضعف السياسة للموقع كله بدلاً من إصلاح خط المعالجة.

الاستخراج من سمة أو حالة أو مسار واحد واعتبار المهمة منتهية. لا يعني «غير مستخدم» في تسجيل واحد لتبويب Coverage أنه «آمن للتأجيل» عبر السمة الداكنة أو المحتوى المخصص أو نافذة مفتوحة. والفصل الذي يراعي الحالة الافتراضية فقط سيشحن أنماطاً مكسورة للجزء الظاهر لدى الآخرين.

أدوات CSS الحرج

الاستخراج والتوليد

critical من Addy Osmani — حزمة npm المرجعية لدى Google؛ “extracts, minifies and inlines above-the-fold CSS.” (ترجمة) «تستخرج CSS للجزء الظاهر قبل التمرير وتصغّره وتضمّنه». وهي المستخدمة في مختبر Google نفسه.
Penthouse — مولد شائع لـ CSS الخاص بالمسار الحرج، ويُدمج كثيراً في خطوط البناء.
CriticalCSS ومولدات SaaS والإضافات المختلفة — للمنفذين غير التقنيين على WordPress وShopify وما شابههما، مثل WP Rocket وcorewebvitals.io وغيرها. إنها مريحة، لكن المقايضات ومخاطر الصيانة نفسها تظل قائمة.

التشخيص: افعله أولاً

Chrome DevTools — تبويب Coverage — توصية Google لتحديد CSS وJS غير الحرجين، ويعرض مقدار الجزء غير المستخدم من كل ملف عند أول رسم.
PageSpeed Insights / Lighthouse — تدقيق حجب العرض، الذي أصبح مؤشر “Render-blocking requests” في Lighthouse 13. يخبرك بوجود مشكلة حجب عرض، لا بأن CSS سببها تلقائياً.
WebPageTest — اقرأ شلال الشبكة وخط “Start Render” لترى بالضبط الموارد التي تؤخر أول رسم.
DebugBear — مراقبة وشرح واضح لمقايضتي التخزين المؤقت وعنق الزجاجة.

تشخيص مشكلات CSS الحرج بحسب العَرَض

تومض الصفحة بمحتوى غير منسق

السبب المرجح: المجموعة الحرجة المستخرجة ناقصة أو تصل ورقة الأنماط المؤجلة متأخرة جداً. الإصلاح: أعد قواعد التخطيط والطباعة اللازمة لأول إطار عرض، ثم أعد التوليد مقابل الحالة الحقيقية للقالب. التأكيد: تُظهر لقطات متتابعة لتحميل بارد مع محاكاة اتصال بطيء أن الصفحة منسقة منذ أول رسم.

يبدو إطار العرض الأول صحيحاً لكن المحتوى السفلي ينكسر

السبب المرجح: فشل تحميل الحزمة غير الحرجة أو تسابق نمط تحميلها مع تهيئة الصفحة. الإصلاح: تحقق من طلب ورقة الأنماط وسلوك البديل من دون الاعتماد على مسار onload وحده. التأكيد: يكشف التمرير والتنقل محتوى منسقاً بالكامل مع تأخير JavaScript.

يساعد CSS الحرج قالباً ويضر قالباً آخر

السبب المرجح: أعيد استخدام مجموعة مولدة واحدة عبر تخطيطات ذات محتوى مختلف في العرض الأول. الإصلاح: قيّد الاستخراج بحسب القالب، أو أزل التحسين حيث تتجاوز تكلفة الصيانة الفائدة. التأكيد: يجتاز كل قالب مدعوم اختبار التحميل البارد نفسه.

تصبح الزيارات المتكررة أبطأ

السبب المرجح: ضُمّن قدر كبير من CSS في كل استجابة HTML، فضاعت فائدة التخزين المؤقت لورقة الأنماط. الإصلاح: قلص المجموعة الحرجة وقارن مكاسب العرض الأول بتكلفة النقل والتحليل عند تكرار تحميل الصفحة. التأكيد: تتحسن عمليات التحميل الباردة والدافئة، أو تُقبل المقايضة صراحة.

كتلة النمط المضمنة مفقودة أو تعرض وحدة التحكم انتهاك CSP

السبب المرجح: تحجب سياسة Content-Security-Policy ذات التوجيه style-src كتلة <style> المضمنة لافتقارها إلى nonce أو تجزئة مطابقة. الإصلاح: اربط توليد nonce أو التجزئة بخط الاستخراج بدلاً من إرخاء السياسة باستخدام unsafe-inline. التأكيد: لا تعرض وحدة تحكم المتصفح انتهاكات CSP، وتعمل الكتلة المضمنة تحت سياسة الإنتاج الفعلية لا سياسة محلية مخففة.

تظهر سمة أو نسخة مخصصة أو حالة تفاعلية بلا تنسيق

السبب المرجح: لم يلتقط الاستخراج سوى سمة واحدة، أو حالة افتراضية لمستخدم غير مسجل، أو مسار واحد، وأسقط قواعد التتالي اللازمة للحالات الأخرى بوصفها «غير مستخدمة». الإصلاح: أعد الاستخراج مقابل حالات ممثلة: السمة الداكنة والفاتحة، والمحتوى المخصص، وحالات التركيز والفتح والخطأ، مع الحفاظ على ترتيب التتالي. التأكيد: تجتاز كل حالة مدعومة اختبار التحميل البارد نفسه، لا الحالة الافتراضية فقط.

استخدم إطار التشخيص والاستخراج والتسليم والصيانة

شخّص: أثبت أن CSS يقع على المسار الحرج باستخدام شلال الشبكة وتسجيل Coverage والتتبع. توقف إذا كان زمن الخادم أو JavaScript هو القيد الأكبر.
استخرج: ضمّن القواعد اللازمة فقط لعرض إطار العرض الأول الفعلي. اختبر الحالات المتجاوبة والمحتوى الديناميكي بدلاً من افتراض أن لقطة واحدة تغطي القالب.
سلّم: ضمّن المجموعة الحرجة الصغيرة وحمّل ورقة الأنماط الكاملة بنمط آمن عند الفشل. حافظ على CSP وترتيب المصدر وسلوك التخزين المؤقت.
صُن: أعد التوليد عند تغير القوالب أو رموز التصميم، ثم شغّل فحوصاً بصرية وفحوص أداء. CSS الحرج المتقادم عيب إنتاج، لا تكلفة إعداد لمرة واحدة.

يجعل هذا الإطار CSS الحرج نظاماً قائماً على الأدلة. وتجاوز خطوة الصيانة هو ما يحول مكسب سرعة أولياً إلى انحدار بصري لاحقاً.

ورقة غش لاتخاذ قرار CSS الحرج

السؤال	الإشارة	الإجراء
هل يؤخر CSS أول رسم؟	تقع أوراق الأنماط على المسار الحرج المقاس	تابع التشخيص
هل توجد مرحلة أخرى أكبر؟	يهيمن TTFB أو JavaScript	أصلحها أولاً
هل المجموعة الحرجة صغيرة ومستقرة؟	قواعد قليلة للعرض الأول يشترك فيها القالب	فكر في الاستخراج
هل يومض أول رسم أو يتحول؟	تكشف لقطات التحميل المتتابعة أو مسار Layout Shifts انحداراً	أعد قواعد التخطيط الحرجة الناقصة
هل تفشل الحزمة المؤجلة بأمان؟	تظل الصفحة قابلة للاستخدام عند تأخير التحميل	تحقق عبر الرحلات المدعومة
هل يستطيع الفريق إعادة التوليد؟	الاستخراج جزء من إصدارات القالب أو CSS	احتفظ بالتحسين
هل الصيانة يدوية وهشة؟	تُشحن مخرجات متقادمة بعد تغييرات التصميم	فضّل تقليل CSS أو تقسيمه بصورة أبسط

أثبت نجاح تغيير CSS الحرج

اختبار بصري لأول رسم

الاختبار: التقط سلسلة لقطات لتحميل بارد مع محاكاة اتصال بطيء قبل التغيير وبعده عند نقاط التوقف المدعومة. النتيجة المتوقعة: يُرسم المحتوى المفيد الظاهر قبل التمرير مبكراً ويكون منسقاً بصورة صحيحة منذ أول إطار. تفسير الفشل: المجموعة الحرجة ناقصة أو لم يكن CSS عنق الزجاجة الفعلي. نافذة المراقبة: فوراً عبر تشغيلات متكررة. محفز التراجع: وميض أو محتوى مفقود أو تحولات تخطيط جديدة.

اختبار ورقة الأنماط المؤجلة

الاختبار: افحص لوحتي Network وPerformance أثناء تحميل ورقة الأنماط الكاملة. النتيجة المتوقعة: لا تعود الحزمة غير الحرجة تحجب أول رسم، وتظل تُطبق بعده بموثوقية. تفسير الفشل: لا يزال نمط التحميل حاجباً أو يتسابق مع التهيئة. نافذة المراقبة: فوراً، بما في ذلك طلب متعمد البطء. محفز التراجع: فشل تطبيق الأنماط الكاملة أو تعذر استخدام عناصر التحكم في الصفحة.

اختبار انحدار القالب

الاختبار: شغّل مقارنات بصرية لكل قالب ونقطة توقف تستخدم المجموعة الحرجة المولدة. النتيجة المتوقعة: لا توجد قواعد مفقودة أو متقادمة للعرض الأول. تفسير الفشل: لا تطابق تغطية الاستخراج متغيرات قالب الإنتاج. نافذة المراقبة: مع كل إصدار ذي صلة لـ CSS أو القالب. محفز التراجع: عرض أي قالب إنتاج بصورة خاطئة.

موارد تستحق وقتك

محاضراتي

ما التالي لتجربة الصفحة؟ — SMX Next 2021 (SlideShare) — حيث قسمت عمل CSS إلى مجموعة مبكرة/حرجة: إزالة غير المستخدم ← التصغير ← تضمين CSS الحرج، ومجموعة متأخرة/مؤجلة مع نمط preload/onload. هذا هو جوهر «كيف تترابط الأجزاء» في الصفحة.
Page Experience Update — TMC June 2021 (SlideShare) — عرض أوسع عن تجربة الصفحة وCore Web Vitals يغطي إعطاء الأولوية للموارد الحرجة والتحميل الكسول وتضمين CSS الحرج.
إشارات بحث Google لتجربة الصفحة — SMX Advanced 2021 (SlideShare) — سياق تجربة الصفحة وCore Web Vitals المحيط بهذه الحقبة من الإرشادات.

كتاباتي ذات الصلة

ما مؤشرات أداء الويب الأساسية وكيف تحسنها؟ — دليلي الواسع لـ CWV، أي LCP وCLS وINP. لا يغطي CSS الحرج بالاسم، وهذه تحديداً الفجوة التي تملؤها الصفحة؛ اقرأهما معاً لفهم جانب LCP الحاجب للعرض.
دليل المبتدئ إلى تحسين محركات البحث التقني — موضع الأداء والعرض في الصورة الأكبر.

رسمية

web.dev — استخراج CSS الحرج، ومختبر Critical، وتأجيل CSS غير الحرج، وCSS الحاجب للعرض.
Chrome for Developers — إزالة الموارد الحاجبة للعرض (Lighthouse).

من أنحاء المجال

Critical CSS? Not So Fast! (Harry Roberts، csswizardry.com) — القراءة المخالفة الأساسية: متى يساعد CSS الحرج ومتى لا يساعد، ومخاطر الصيانة وحالات التسابق.
هل يجعل تضمين CSS الحرج موقعك أسرع؟ (Matt Zeunert، DebugBear) — مقايضة التخزين المؤقت وحجة «شخّص عنق الزجاجة أولاً» مع قياسات.
How To Identify & Reduce Render-Blocking Resources (Abby Hamilton / Dentsu عبر Search Engine Journal) — سير العمل التشغيلي لقراءة تدقيق حجب العرض.
Google Confirms CSS Class Names Don’t Influence SEO (Matt G. Southern، Search Engine Journal) — قول Martin Splitt عن سبب عدم كون CSS إشارة ترتيب مباشرة.
المشكلة #17031 في Lighthouse (GitHub) — تقرير 2026 الحي عن تصنيف CSS المحمل مسبقاً حاجباً للعرض بعد تحديث نقطي في PSI؛ مفيد عندما يُصنف CSS المؤجل بصورة صحيحة خطأً.
فهم CSS الحرج (Smashing Magazine، 2015) — الشرح الكلاسيكي؛ قديم لكنه سياق تاريخي مفيد لكيفية تقديم التقنية أول مرة.

اختبر نفسك: CSS الحرج

خمسة أسئلة سريعة عن ماهية CSS الحرج، ووقت استخدامه، ومقايضاته. اختر إجابة لكل سؤال ثم تحقق منها.

سجل التغييرات

تم التحديث في 14 أغسطس 2026.

ملخص تحريري وتفاصيل التغيير المسجلة.

تفاصيل التغيير

تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.

المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.

تم التحديث في 11 أغسطس 2026.

ملخص تحريري وتفاصيل التغيير المسجلة.

تفاصيل التغيير

تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.

المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.

تم التحديث في 17 يوليو 2026.

ملخص تحريري وتفاصيل التغيير المسجلة.

تفاصيل التغيير

تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.

المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.