By default, how does CSS loaded via behave on the critical rendering path?

It is render-blocking; the browser won't paint until the CSSOM is built

It never blocks rendering — only JavaScript does

It blocks only on mobile devices

It blocks downloading of the HTML itself

What is the key difference between async and defer on a ?

Both download in parallel, but async executes when ready (unordered) while defer executes after parsing, in order

async blocks the parser; defer does not

defer downloads first, then async downloads

They are identical in modern browsers

Which Core Web Vitals metric is most directly delayed by render-blocking resources?

Interaction to Next Paint (INP)

What does Google warn about inlining CSS to fix render-blocking?

It is an advanced technique that can improve performance but can also cause bugs if done improperly

It is impossible in modern browsers

It only works on WordPress sites

Does render-blocking JavaScript push a page into Google's rendering queue?

No — Google sends all eligible 200-status pages to the rendering queue regardless of whether JavaScript is present

Yes — only render-blocking JavaScript triggers rendering-queue entry

No — Googlebot never uses a rendering queue

Yes, but only for pages over 2 MB

الموارد التي تحجب العرض

الخلاصة — الموارد التي تحجب العرض هي ملفات CSS وJavaScript التي يتعين على المتصفح تنزيلها وتشغيلها قبل أن يعرض أي شيء على الشاشة. ومن أعراض ذلك ظهور صفحة بيضاء فارغة أثناء تحميل هذه الملفات. يحجب CSS العرض افتراضياً؛ كما يحجبه وسم <script> في <head> إذا خلا من async أو defer. والحل هو تحميل العناصر غير الضرورية لاحقاً كي ترسم الصفحة محتواها في وقت أقرب.

ما معنى «حجب العرض»؟

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

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

النوعان

يحجب CSS العرض افتراضياً عندما يكتشف المتصفح وسم <link rel="stylesheet"> في <head> أثناء التحليل، وتكون ورقة الأنماط منطبقة فعلاً (لا قيمة media غير مطابقة ولا disabled). لا يريد المتصفح عرض محتوى بلا تنسيق ثم إعادة تنسيقه، لأن ذلك الوميض يبدو معطلاً، ولذلك ينتظر CSS المنطبق قبل الرسم.
توقف JavaScript تحليل HTML عندما يكون وسم <script> عادياً في <head> بلا async أو defer: إذ يتعين على المتصفح التوقف عن قراءة HTML وجلب النص البرمجي وتشغيله، ثم المتابعة. (تقنياً هذا «حجب للمحلل»؛ أما اعتباره رسمياً «حجباً للعرض» أيضاً فيعتمد على تفاصيل داخلية للمتصفح لا يحتاج إليها معظم القراء؛ راجع قسم المتقدم.)

لماذا يهم؟

كلما طال انتظار المتصفح، طال تحديق الزائر في الفراغ. تقيس Google متى يظهر المحتوى المفيد، بمقياس يسمى Largest Contentful Paint، وهو جزء من Core Web Vitals وإشارة ترتيب صغيرة. ولذلك يمكن للموارد التي تحجب العرض أن تضر تجربة الزوار، وأن تضر SEO بصورة غير مباشرة.

الإصلاحات البسيطة

أضف defer إلى النصوص البرمجية كي تُنزّل بالتوازي مع الصفحة وتعمل بعد رسمها.
لا تضع في <head> من CSS أو JavaScript أكثر مما تحتاج إليه الشاشة الأولى فعلاً.
إذا كنت تستخدم WordPress، تنفذ إضافات مثل WP Rocket أو Autoptimize ذلك عبر مربع اختيار.

هل تريد معرفة الآليات — الفرق بين async وdefer، وCSS الحرج، وزاوية ميزانية الزحف، وما تقوله Google فعلياً؟ انتقل إلى تبويب المتقدم.

الخلاصة — تؤخر الموارد التي تحجب العرض أول رسم للصفحة. تحجب ورقة CSS منطبقة في <head> العرض افتراضياً، أما media غير المطابقة أو disabled أو الإدراج الديناميكي بلا blocking="render" صريح فلا تفعل. ويحجب وسم <script> تقليدي أدرجه المحلل بلا async/defer المحلل افتراضياً، فتوقف تحليل HTML؛ وهذه آلية مرتبطة بنموذج سمة «حجب العرض» الرسمي لكنها متميزة عنه. يحمّل async بالتوازي وينفذ عند اكتمال التنزيل بلا ترتيب وقد يقاطع التحليل؛ ويحمّل defer بالتوازي وينفذ بعد تحليل HTML وبالترتيب؛ وتُؤجل نصوص الوحدات البرمجية افتراضياً. قد تؤخر هذه العوائق FCP وLCP، وتستخدم أنظمة ترتيب Google مقياس LCP، لكنه عامل ترجيح لا عاملاً مهيمناً، ولا توثق Google وزناً مباشراً لحجب العرض. تجلب Google بحد أقصى 2 MB لكل عنوان غير PDF، بما في ذلك الترويسات، وبصورة منفصلة لكل ملف JS/CSS مشار إليه؛ وهذا حد اقتطاع لا عقوبة خاصة بحجب العرض. كما تدخل كل الصفحات المؤهلة ذات الحالة 200 طابور العرض، سواء استخدمت JavaScript أم لا. اعثر على العوائق عبر Insight ‏“Render blocking requests” في Lighthouse 13 وتبويب Coverage في DevTools؛ وأصلحها عبر defer وCSS الحرج فقط عندما يثبت التتبع أنه عنق الزجاجة، وسمات media وإزالة الشيفرة غير المستخدمة، ثم أعد الاختبار بتتبعات متطابقة ومتكررة.

مسار العرض الحرج

لرسم صفحة، ينفذ المتصفح تسلسلاً ثابتاً: يحلل HTML إلى DOM، ويحلل CSS إلى CSSOM، ويجمعهما في شجرة عرض، ثم يحدد التخطيط ويرسم. هذا التسلسل هو مسار العرض الحرج، وكل ما يعطله يؤخر البكسل الأول. وكما صاغه Ilya Grigorik من Google، “optimizing the critical rendering path refers to prioritizing the display of content that relates to the current user action.” (ترجمة): «يشير تحسين مسار العرض الحرج إلى إعطاء الأولوية لعرض المحتوى المرتبط بإجراء المستخدم الحالي.» والموارد التي تحجب العرض هي العناصر الجالسة في ذلك المسار ويدها مرفوعة، فتجعل المتصفح ينتظر.

يحجب CSS العرض افتراضياً — عندما يكون منطبقاً

لا يرسم المتصفح المحتوى المنسق حتى يبني CSSOM من كل ورقة أنماط حاجبة منطبقة، ومرجع <link> لدى MDN صريح في النطاق: “only link elements in the document’s <head> can possibly block rendering. By default, a link element with rel="stylesheet" in the <head> blocks rendering when the browser discovers it during parsing.” (ترجمة): «لا يمكن أن تحجب العرض إلا عناصر link الموجودة في head بالمستند. وافتراضياً، يحجب عنصر link ذي rel=“stylesheet” في head العرض عندما يكتشفه المتصفح أثناء التحليل.» ومن دليل Optimize LCP في web.dev: “Style sheets loaded from the HTML markup will block rendering of all content that follows them.” (ترجمة): «ستحجب أوراق الأنماط المحملة من ترميز HTML عرض كل المحتوى الذي يليها.» وهذا مقصود، لأن رسم HTML بلا تنسيق ثم إعادة تنسيقه ينتج وميضاً قبيحاً، لكن لعبارة «افتراضياً» حدوداً حقيقية:

تُجلب ورقة الأنماط ذات سمة media غير المطابقة، مثل media="print" عند زيارة الشاشة، لكنها لا تحجب.
لا تُحمّل ورقة الأنماط ذات disabled ولا تُطبق حتى تزيل السمة.
لا تحجب ورقة الأنماط المضافة ديناميكياً عبر نص برمجي العرض إلا إذا ضبطت عليها أيضاً blocking="render" صراحة؛ فالإدراج الديناميكي يعطل السلوك الافتراضي.

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

النصوص البرمجية: تحجب المحلل افتراضياً، وتحجب العرض عند الطلب رسمياً

يحجب وسم <script> تقليدي أدرجه المحلل في <head> بلا async أو defer المحلل افتراضياً: يتوقف المتصفح عن بناء DOM، ويجلب النص البرمجي وينفذه، ثم يستأنف. وتوضح وثائق PageSpeed القديمة من Google التكلفة: “whenever the parser encounters a script it has to stop and execute it before it can continue parsing the HTML. In the case of an external script the parser is also forced to wait for the resource to download, which may incur one or more network roundtrips and delay the time to first render of the page.” (ترجمة): «كلما صادف المحلل نصاً برمجياً، يتعين عليه التوقف وتنفيذه قبل متابعة تحليل HTML. وفي حالة نص برمجي خارجي، يُجبر المحلل أيضاً على انتظار تنزيل المورد، مما قد يتطلب رحلة شبكة ذهاباً وإياباً واحدة أو أكثر ويؤخر وقت العرض الأول للصفحة.» وكما يقول دليل Optimize LCP بصراحة: “it is almost never necessary to add synchronous scripts… to the <head> of your pages.” (ترجمة): «يكاد لا يكون من الضروري أبداً إضافة نصوص برمجية متزامنة إلى head في صفحاتك.»

تجدر الدقة هنا: حجب المحلل ونموذج سمة حجب العرض الرسمي في مواصفة HTML آليتان مرتبطتان لكنهما متميزتان. ووفق مرجع <script> لدى MDN، فإن الرمز blocking="render" “explicitly indicates that certain operations should be blocked until the script has executed,” (ترجمة): «يشير صراحة إلى وجوب حجب عمليات معينة حتى تنفيذ النص البرمجي،» كما أن “only script elements in the document’s <head> can possibly block rendering” (ترجمة): «لا يمكن أن تحجب العرض بهذه الطريقة إلا عناصر script الموجودة في head بالمستند»، و*“if such a script element is added dynamically via script, you must set blocking = "render" for it to block rendering.”* (ترجمة): «إذا أضيف عنصر script كهذا ديناميكياً عبر نص برمجي، فيجب ضبط blocking = “render” عليه كي يحجب العرض.» عملياً، تعطل وسم <head> الحاجبة للمحلل افتراضياً خط الأنابيب بما يكفي كيلا يغير التمييز ما تفعله غالباً؛ وتهم المسألة أساساً النصوص المدرجة ديناميكياً، التي تحتاج السمة الصريحة للمشاركة، كما أن دعم المتصفحات لـblocking="render" لا يزال محدوداً ويستحق التحقق قبل الاعتماد عليه.

إعداد افتراضي آخر ينبغي معرفته: تُؤجل نصوص type="module" افتراضياً، ولا تحتاج سمة defer، ما لم تُضف async لتغيير الجدولة.

الفرق بين `async` و`defer` — ليستا متماثلتين

هذا أهم تمييز منفرد لإصلاح JavaScript التي تحجب العرض. ينزل كلاهما النص البرمجي بالتوازي مع تحليل HTML، فلا يحجب أيهما المحلل أثناء التنزيل. لكنهما يختلفان في التنفيذ:

async — تنفذ فوراً عند اكتمال التنزيل، مما قد يقاطع التحليل، وتعمل بلا ترتيب مضمون. تناسب النصوص الخارجية المستقلة حقاً، مثل التحليلات والإعلانات، التي لا تتعامل مع DOM ولا تعتمد بعضها على بعض.
defer — تنفذ بعد اكتمال تحليل HTML، بترتيب المستند. تناسب النصوص التي تعتمد على DOM أو بعضها على بعض، أي معظم شيفرتك.
نصوص الوحدات (type="module") — مؤجلة افتراضياً؛ أضف async إذا أردت تحديداً التنفيذ وفق ترتيب جاهزية الوحدات.

إذا أردت تذكر قاعدة واحدة: استخدم defer لكل ما يعتمد على ترتيب أو على DOM، وasync فقط للنصوص الخارجية المستقلة التي لا يهم انتظارها.

كيف يؤثر ذلك في SEO؟

السلسلة حقيقية، لكن لها حدود حقيقية. لا تبالغ فيها في أي من الاتجاهين:

تؤخر الموارد التي تحجب العرض First Contentful Paint، أي لحظة ظهور أي محتوى أول مرة.
قد تؤخر Largest Contentful Paint، مقياس التحميل الأساسي لدى Google، لكن وجود مورد معلّم لا يثبت أنه عنق الزجاجة المهيمن في البيانات الميدانية، وإزالته لا تضمن تحسن LCP؛ إذ يبلغ Insight في Lighthouse عن تأخير محتمل من تتبع واحد، لا عن أثر ميداني مضمون.
LCP مقياس من Core Web Vitals، يُقاس عند الشريحة المئوية 75 من بيانات ميدانية حقيقية خلال 28 يوماً، وتقول Google إن Core Web Vitals “are used by our ranking systems.” (ترجمة): «تستخدمها أنظمة الترتيب لدينا.» والحد «الجيد» لـLCP هو ≤2٫5 s.
لا تحدد وثائق تجربة الصفحة لدى Google وزناً أو سلسلة أو عامل ترجيح مباشر لحجب العرض، ولا تقدم ضماناً للترتيب بعد إزالة العوائق؛ فهي تقول إن الملاءمة تظل الحاسمة، لكن “having a great page experience can contribute to success in Search” (ترجمة): «قد تسهم تجربة صفحة رائعة في النجاح في البحث» عندما يوجد قدر كبير من المحتوى المفيد المتشابه للاختيار منه.

حافظ على صدق الوزن. تمثل عبارة Martin Splitt المعايرة الصحيحة: “a fast website is a little more helpful than a slow website,” (ترجمة): «الموقع السريع أكثر فائدة بقليل من الموقع البطيء،» لكن “content is still the king.” (ترجمة): «المحتوى لا يزال الملك.» يستحق إصلاح المورد الذي يؤخر LCP فعلاً من أجل تجربة المستخدم وبوصفه مدخلاً من مدخلات عديدة تزنها أنظمة Google؛ وليس رافعة ذات مضاعف ترتيب مخصص وموثق.

زاوية كفاءة الزحف — بعد التصحيح

كنت قد صغت سابقاً JavaScript الثقيلة التي تحجب العرض بوصفها شيئاً «يدفع» الصفحات إلى طابور العرض أو «يجبرها» عليه. هذا غير دقيق، ويستحق تصحيحاً صريحاً: تنص وثائق JavaScript SEO الحالية لدى Google على أن “all pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page.” (ترجمة): «تُرسل كل الصفحات ذات رمز حالة HTTP ‏200 إلى طابور العرض، بصرف النظر عن وجود JavaScript في الصفحة.» تدخل كل صفحة مؤهلة ذلك الطابور، ولا تنشئ الموارد التي تحجب العرض مدخلاً خاصاً إليه.

ما يغيره نوع المورد هو مقدار العمل الذي يحدث عند وصول الصفحة إلى العرض. وجدت تجربة Onely أن Google احتاجت وقتاً أطول 9 مرات للزحف الكامل إلى صفحات معروضة بـJavaScript مقارنة بصفحات HTML مطابقة (313 ساعة مقابل 36 ساعة) في إعداد اختبارهم، لأن “pages that require rendering have to wait in a rendering queue in addition to the crawl queue which applies to all pages.” (ترجمة): «الصفحات التي تتطلب العرض عليها انتظار طابور العرض إضافة إلى طابور الزحف الذي ينطبق على كل الصفحات.» تعامل مع ذلك دليلاً على أن المحتوى الذي يتطلب العرض على جانب العميل يحمل تكلفة حقيقية في وقت الفهرسة في تلك الدراسة، لا دليلاً على أن ملف CSS أو JS حاجباً بعينه هو ما يسبب الدخول إلى الطابور.

في حجم الملف، تصف وثائق الزحف لدى Google حد جلب يبلغ 2 MB لكل عنوان URL غير PDF، بما في ذلك ترويسات HTTP، ويطبق منفصلاً على كل مورد تطلبه؛ فيحصل نص برمجي كبير أو ورقة أنماط كبيرة في <head> على عداد 2 MB خاص به، لا ميزانية مشتركة مع HTML. وهذا حد جلب/اقتطاع لا «حد معالجة»، ولا توثق Google عقوبة خاصة للزحف أو الفهرسة مرتبطة تحديداً بالموارد التي تحجب العرض، عدا خطر الاقتطاع العام.

يجدر تفنيد أمر آخر هنا: لا يملك عارض Google مهلة زمنية ثابتة. وكما وثقت في دليلي إلى JavaScript SEO، “there is no fixed timeout for the renderer. It runs with a sped-up timer to see if anything is added at a later time.” (ترجمة): «لا توجد مهلة ثابتة للعارض. إنه يعمل بمؤقت مسرّع لمعرفة ما إذا كان شيء سيُضاف لاحقاً.» المشكلة ليست مهلة خمس ثوان؛ بل تأخير الطابور قبل بدء العرض.

ويمتد هذا الآن إلى زواحف الذكاء الاصطناعي. قال Gary Illyes عام 2026 إنه “if sites used relatively good HTML and no JavaScript (or SSR), both base model training, and web and agentic RAG would be a piece of cake from raw data processing perspective.” (ترجمة): «لو استخدمت المواقع HTML جيداً نسبياً وبلا JavaScript، أو استخدمت SSR، لكان تدريب النماذج الأساسية وRAG للويب والوكلاء أمراً سهلاً جداً من منظور معالجة البيانات الخام.» تمثل JavaScript الثقيلة على جانب العميل مشكلة تتجاوز Googlebot بكثير.

كيفية العثور عليها

لوحة Performance في Chrome DevTools / ‏Lighthouse 13 — يعرض Insight الحالي “Render blocking requests”، الذي انتقل إليه التدقيق الأقدم “Eliminate render-blocking resources” في Lighthouse 13، النصوص الموجودة في <head> من دون async/defer وأوراق الأنماط من دون disabled أو media غير مطابقة، ويقدر المللي ثواني الممكن توفيرها من تتبع واحد. ويقول Connor Clark: “render-blocking requests are network requests that prevent a page’s initial render, potentially delaying Largest Contentful Paint.” (ترجمة): «طلبات حجب العرض هي طلبات شبكة تمنع العرض الأولي للصفحة، وقد تؤخر Largest Contentful Paint.» إذا كنت تقرأ ناتجاً أقدم من PageSpeed Insights ما زال يقول “Eliminate render-blocking resources”، فهي الإشارة الأساسية نفسها تحت الاسم السابق لـLighthouse 13.
تبويب Coverage في Chrome DevTools — يعلّم البايتات بالأخضر إذا كانت حرجة ومستخدمة في الرسم الأول، وبالأحمر إذا لم تُستخدم حينه. كثرة CSS/JS الأحمر قائمة مرشحيك.
شلال WebPageTest — افحص كل شيء قبل خط Start Render.
شغله أكثر من مرة — يعكس التتبع الواحد حالة مدير الموافقة وتحميل وسوم الطرف الثالث والذاكرة المؤقتة وسلوك CSP في ذلك التشغيل. كرر التتبع بارداً ودافئاً قبل اعتبار المورد المعلّم حقيقة ثابتة.

Read a waterfall from left to right: first paint cannot cross the boundary until every required blocking request has finished.

An illustrative navigation contains HTML from 0 to 180 milliseconds, blocking CSS from 120 to 420 milliseconds, synchronous JavaScript from 210 to 610 milliseconds, a non-blocking analytics request from 250 to 500 milliseconds, and font loading from 420 to 610 milliseconds. First paint occurs at 610 milliseconds. The example explains timing mechanics; it is not a live trace.

كيفية إصلاحها

JavaScript

أجّل النصوص غير الحرجة عبر defer — <script src="app.js" defer></script>. تنزيل متواز وتنفيذ مرتب بعد التحليل. وهذا الإعداد الافتراضي الآمن لشيفرتك.
استخدم async للنصوص الخارجية المستقلة — <script src="analytics.js" async></script>. وذلك فقط عندما لا يهم الترتيب ولا جاهزية DOM فعلاً.
انقل النصوص إلى نهاية <body> — البديل الأقدم عندما يتعذر إضافة السمات؛ يصل إليها المحلل أخيراً.

CSS — قرارات مشروطة، لا أنماطاً شاملة

ضمّن CSS الحرج داخل الصفحة فقط عندما يبين التتبع أن CSS عنق الزجاجة الفعلي — استخرج الأنماط اللازمة للمحتوى الظاهر فوق الطية إلى كتلة <style> داخلية كي لا يحتاج الرسم الأول إلى رحلة شبكة. وينطبق تحذير Google: “inlining CSS is an advanced performance technique that can improve performance, but can also lead to bugs if not implemented properly.” (ترجمة): «تضمين CSS داخل الصفحة تقنية أداء متقدمة قد تحسن الأداء، لكنها قد تؤدي أيضاً إلى أخطاء إن لم تنفذ بصورة صحيحة.» ضمّن المجموعة الحرجة فقط، وعيّن مسؤولاً عن إعادة توليدها عند تغير القوالب، وافحص الانحراف عبر حالات الصفحة؛ فنسخة CSS حرج قديمة تعيد بصمت وميض المحتوى غير المنسق أو الأنماط المفقودة.
أجّل الباقي مع مطابقة الطلب بدقة — حمّل ورقة الأنماط الكاملة بنمط <link rel="preload" as="style" onload="this.rel='stylesheet'">. لا يُعاد استخدام preload للطلب النهائي إلا إذا تطابقت URL وas وtype و crossorigin/نمط CORS؛ ويسبب التلميح غير المطابق جلب المورد مرتين بدلاً من تجاوز رحلة الشبكة.
سمات media — تتيح media="print" أو media="(min-width: 900px)" للمتصفح تنزيل ورقة أنماط دون حجب العرض عندما لا يطابق الاستعلام.
أزل CSS غير المستخدم وصغّره — بيانات أقل للحجب وتنزيل أسرع.
تحقق قبل النشر — أعد فحص الجلبات المكررة/غير المستخدمة وFOUC وأي انزياح تخطيط جديد بعد تغيير CSS الحرج أو preload، عبر تتبع متكرر لا تشغيل محظوظ واحد.

خاص بالمنصة (WordPress) — تنفذ WP Rocket، لتأخير/تأجيل JS وتحسين تسليم CSS، وAutoptimize، لتنفيذ async/defer وتضمين CSS الحرج، وAsync JavaScript كل ما سبق عبر واجهات إضافات. فهي تطبق تقنيات async/defer/CSS الحرج نفسها، وفهم ما يفعله كل إعداد هو ما يجنبك كسر القالب.

قراءات ذات صلة في هذا الموقع

Core Web Vitals — مجموعة المقاييس الأم التي يندرج ضمنها هذا الأثر.
Largest Contentful Paint — المقياس الأشد تأثراً بالموارد التي تحجب العرض.
First Contentful Paint — أول ما تؤخره.
Total Blocking Time — تكلفة JavaScript الثقيلة على الخيط الرئيسي.
PageSpeed Insights — الأداة التي تعرض التدقيق.
العرض وميزانية الزحف — زاوية طابوري الزحف والعرض.

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

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

الموارد التي تحجب العرض هي CSS وJavaScript المتزامنة على مسار العرض الحرج. تحجب ورقة أنماط منطبقة، في <head> وذات media مطابقة وليست disabled ولا مدرجة ديناميكياً، العرض افتراضياً؛ ويحجب وسم <script> أدرجه المحلل بلا async/defer المحلل افتراضياً. وهذا مرتبط بسمة blocking="render" في مواصفة HTML لكنه متميز عنها رسمياً؛ فالسمة خاصة بـhead ومطلوبة للنصوص/الأنماط المدرجة ديناميكياً.
async = تنزيل متواز وتنفيذ عند الجاهزية بلا ترتيب، وقد يقاطع التحليل؛ استخدمها للنصوص الخارجية المستقلة. defer = تنزيل متواز وتنفيذ بعد التحليل بالترتيب؛ استخدمها لشيفرتك أو الشيفرة المعتمدة على DOM. وتُؤجل نصوص الوحدات (type="module") افتراضياً.
سلسلة SEO: قد تؤخر FCP وLCP، ولا يثبت المورد المعلّم أنه عنق الزجاجة المهيمن؛ وتستخدم أنظمة ترتيب Core Web Vitals لدى Google مقياس LCP، والجيد ≤2٫5 s. لا توثق Google وزناً مباشراً أو ضماناً للترتيب بسبب حجب العرض؛ “a fast website is a little more helpful… content is still the king.” (ترجمة): «الموقع السريع أكثر فائدة بقليل… والمحتوى لا يزال الملك.»
زاوية الزحف بعد التصحيح: تدخل كل الصفحات المؤهلة ذات الحالة 200 طابور عرض Google بصرف النظر عن وجود JavaScript؛ فلا تنشئ الموارد الحاجبة مدخلاً خاصاً. تجلب Google بحد أقصى 2 MB لكل URL غير PDF، بما في ذلك الترويسات، ولكل مورد؛ وهذا حد جلب/اقتطاع لا عقوبة معالجة خاصة. وجدت دراسة Onely أن Google احتاجت 9 أضعاف الوقت للزحف الكامل إلى صفحات JS مقارنة بـHTML في اختبارها؛ وهذا دليل على تكلفة خطوة العرض، لا على أن عائقاً بعينه يسبب الطابور. لا توجد مهلة ثابتة للعارض؛ التكلفة في الطابور لا في القطع.
العثور: Insight ‏“Render blocking requests” في Lighthouse 13، واسمه السابق “Eliminate render-blocking resources”؛ وتبويب Coverage، حيث الأخضر حرج والأحمر غير مستخدم؛ وشلال WebPageTest قبل Start Render. كرر التتبع لأن حالة الموافقة والطرف الثالث والذاكرة المؤقتة قد تغير النتائج.
الإصلاح: استخدم defer لـJS غير الحرجة وasync للنصوص الخارجية المستقلة؛ وضمّن CSS الحرج فقط حين يثبت التتبع أنه عنق الزجاجة مع مسؤول عن مزامنته، وأجّل الباقي مع مطابقة as/type/crossorigin في preload بدقة؛ واستخدم media للأوراق المشروطة؛ وأزل CSS غير المستخدم وصغّره؛ ثم تحقق بتتبع متطابق ومتكرر قبل النشر.

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

إرشادات من مصادر أولية لدى Google وBing.

Google / Chrome

طلبات حجب العرض (Chrome DevTools Performance Insights) — الشرح المرجعي الحالي (Connor Clark، أكتوبر 2025)، وInsight في Lighthouse 13 الذي أصبح الموضوع موجوداً تحته: التأجيل والتضمين وتقليل الحمولة.
إزالة الموارد التي تحجب العرض (تدقيق Lighthouse القديم) — ما زال حياً، لكنه يحمل لافتة تقول إنه انتقل إلى Insight أعلاه منذ Lighthouse 13؛ أُبقي هنا لقراء التقارير الأقدم.
تحسين Largest Contentful Paint — كيف تؤخر CSS الحاجبة والنصوص المتزامنة LCP (Philip Walton وBarry Pollard).
مسار العرض الحرج — تسلسل التحليل ← CSSOM ← شجرة العرض ← الرسم الكامن وراء الموضوع (Ilya Grigorik).
إزالة JavaScript التي تحجب العرض (وثائق PageSpeed القديمة) — وثائق PSI v4 مهجورة، لكن آليات حجب المحلل ما تزال دقيقة.
Core Web Vitals وبحث Google — حدود LCP وعلاقة CWV بالترتيب.
فهم أساسيات JavaScript SEO — تؤكد أن كل الصفحات المؤهلة ذات الحالة 200 تدخل طابور العرض بصرف النظر عن وجود JavaScript.
فهم تجربة الصفحة في نتائج بحث Google — اللغة الحالية المحددة عن علاقة Core Web Vitals بالترتيب، من دون وزن مباشر موثق لحجب العرض.

مواصفة HTML / المتصفح (الآليات)

<script>: عنصر Script ‏(MDN) — دلالات async/defer، وتأجيل الوحدات افتراضياً، وسمة blocking="render"، الخاصة بـhead والمطلوبة للنصوص المدرجة ديناميكياً.
<link>: عنصر External Resource Link ‏(MDN) — سلوك media/disabled لأوراق الأنماط، وسمة blocking، ومتطلبات مطابقة as/type/crossorigin للطلب في preload.
معيار HTML — عنصر script (WHATWG) — التعريفات الرسمية لحجب المحلل وحجب العرض التي يستند إليها قسم النصوص البرمجية في المقالة.

Bing / Microsoft

سلسلة bingbot: ‏JavaScript والعرض الديناميكي والحجب — لماذا تصعب JavaScript على نطاق واسع على Bingbot، والعرض الديناميكي بديلاً مقبولاً (Fabrice Canel وFrédéric Dubut).
إرشادات مشرفي المواقع في Bing — سرعة الصفحة عامل ترتيب، وتقليل JavaScript التي تحجب العرض.

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

تصريحات موثقة. ينتقل كل رابط عميق إلى المقطع المقتبس عندما تسمح صفحة المصدر بذلك.

Google / Chrome — الآليات

“The goal is to reduce the impact of these render-blocking URLs by inlining critical resources, deferring non-critical resources, and removing anything unused.” (ترجمة): «الهدف هو تقليل أثر عناوين URL التي تحجب العرض عبر تضمين الموارد الحرجة وتأجيل الموارد غير الحرجة وإزالة كل ما لا يُستخدم.» — وثائق Chrome Lighthouse. انتقل إلى الاقتباس
“Render-blocking requests are network requests that prevent a page’s initial render, potentially delaying Largest Contentful Paint (LCP).” (ترجمة): «طلبات حجب العرض هي طلبات شبكة تمنع العرض الأولي للصفحة، وقد تؤخر Largest Contentful Paint ‏(LCP).» — Connor Clark، ‏Chrome DevTools Performance Insights. انتقل إلى الاقتباس
“Style sheets loaded from the HTML markup will block rendering of all content that follows them.” (ترجمة): «ستحجب أوراق الأنماط المحملة من ترميز HTML عرض كل المحتوى الذي يليها.» — web.dev، ‏Optimize LCP ‏(Philip Walton وBarry Pollard). انتقل إلى الاقتباس
“It is almost never necessary to add synchronous scripts (scripts without the async or defer attributes) to the head of your pages.” (ترجمة): «يكاد لا يكون من الضروري أبداً إضافة نصوص برمجية متزامنة، أي بلا سمتي async أو defer، إلى head في صفحاتك.» — web.dev، ‏Optimize LCP. انتقل إلى الاقتباس
“Optimizing the critical rendering path refers to prioritizing the display of content that relates to the current user action.” (ترجمة): «يشير تحسين مسار العرض الحرج إلى إعطاء الأولوية لعرض المحتوى المرتبط بإجراء المستخدم الحالي.» — Ilya Grigorik، ‏web.dev، ‏Critical rendering path. انتقل إلى الاقتباس
“Avoid and minimize the use of blocking JavaScript, especially external scripts that must be fetched before they can be executed.” (ترجمة): «تجنب استخدام JavaScript الحاجبة وقلله، ولا سيما النصوص البرمجية الخارجية التي يجب جلبها قبل تنفيذها.» — وثائق Google PageSpeed Insights القديمة. انتقل إلى الاقتباس
“All pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page.” (ترجمة): «تُرسل كل الصفحات ذات رمز حالة HTTP ‏200 إلى طابور العرض، بصرف النظر عن وجود JavaScript في الصفحة.» — Google، فهم أساسيات JavaScript SEO.
“Only script elements in the document’s <head> can possibly block rendering” (ترجمة): «لا يمكن أن تحجب العرض إلا عناصر script الموجودة في head بالمستند»، وفي الإدراج الديناميكي، “you must set blocking = "render" for it to block rendering.” (ترجمة): «يجب ضبط blocking = “render” عليه كي يحجب العرض.» — MDN، <script>: عنصر Script.

Bing / Microsoft

“It is difficult for bingbot to process JavaScript at scale on every page of every website, while minimizing the number of HTTP requests.” (ترجمة): «يصعب على bingbot معالجة JavaScript على نطاق واسع في كل صفحة من كل موقع، مع تقليل عدد طلبات HTTP.» — Fabrice Canel وFrédéric Dubut، ‏Microsoft Bing. انتقل إلى الاقتباس

أبحاث المجال — تكلفة طابور الزحف

“Pages that require rendering have to wait in a rendering queue in addition to the crawl queue which applies to all pages.” (ترجمة): «على الصفحات التي تتطلب العرض انتظار طابور العرض إضافة إلى طابور الزحف الذي ينطبق على كل الصفحات.» — Ziemek Bućko، ‏Onely؛ احتاجت Google وقتاً أطول 9 مرات للزحف إلى JS مقارنة بـHTML. انتقل إلى الاقتباس
“You can do this by deferring the loading of non-critical CSS and JavaScript files needed for ‘below the fold’ content until later.” (ترجمة): «يمكنك فعل ذلك عبر تأجيل تحميل ملفات CSS وJavaScript غير الحرجة اللازمة للمحتوى الموجود أسفل الطية إلى وقت لاحق.» — Joshua Hardwick، ‏Ahrefs. انتقل إلى الاقتباس

ملاحظة: نُقل اقتباس Gary Illyes لعام 2026 “JavaScript mess” (ترجمة): «فوضى JavaScript»، وعبارتا Martin Splitt “a fast website is a little more helpful than a slow website” (ترجمة): «الموقع السريع أكثر فائدة بقليل من الموقع البطيء»، و “content is still the king” (ترجمة): «المحتوى لا يزال الملك»، المستخدمتان في النسخة المتقدمة، عبر تغطية ثانوية (إعادة ppc.land نشر منشور Illyes على LinkedIn؛ وتجميع Dean Long). تحقق من الأصول قبل اعتبارها نهائية.

قائمة تحقق لإصلاح حجب العرض

اعمل من أعلى إلى أسفل: شخّص أولاً، ثم أصلح العناصر الأعلى توفيراً.

ورقة مرجعية سريعة لحجب العرض

async مقابل defer مقابل <script> عادية

السمة	هل تحجب المحلل؟	التنزيل	ترتيب التنفيذ	الاستخدام
لا شيء (وسم `<script>` متزامن)	نعم	يوقف التحليل للجلب	فوراً، ويحجب العرض	لا تستخدمه تقريباً في `<head>`
`async`	لا (أثناء التنزيل)	متواز	عند الجاهزية — بلا ترتيب، وقد يقاطع التحليل	نصوص خارجية مستقلة (التحليلات والإعلانات)
`defer`	لا	متواز	بعد تحليل HTML — بترتيب المستند	شيفرتك أو الشيفرة المعتمدة على DOM

هل يحجب هذا المورد العرض؟

المورد	هل يحجب العرض؟	كيفية إلغاء الحجب
`<link rel="stylesheet">` منطبق في `<head>`	نعم (افتراضياً)	`media` غير مطابقة أو `disabled` أو `preload`+`onload`
`<link media="print">` عند زيارة الشاشة	لا	غير حاجب بالفعل
ورقة أنماط مدرجة ديناميكياً عبر نص	لا، إلا مع `blocking="render"`	أضف `blocking="render"` فقط إذا أردتها أن تحجب تحديداً
`<script>` متزامنة في `<head>` بلا `async`/`defer`	تحجب المحلل افتراضياً	أضف `defer`، أو `async` إن كانت مستقلة
`<script defer>` / `<script async>` / `<script type="module">`	لا	—
CSS حرج مضمّن	لا	هذه هي الغاية؛ أبقه صغيراً

حقائق سريعة

حد LCP «الجيد»: ≤ 2٫5 s عند الشريحة المئوية 75 من البيانات الميدانية ضمن نافذة 28 يوماً.
تجلب Google بحد أقصى 2 MB لكل URL غير PDF، بما في ذلك الترويسات، ويُحسب منفصلاً لكل ملف JS/CSS مشار إليه؛ وهذا حد جلب/اقتطاع لا عقوبة موثقة خاصة بحجب العرض.
تدخل كل الصفحات المؤهلة ذات الحالة 200 طابور عرض Google بصرف النظر عن وجود JavaScript؛ ولا تنشئ الموارد الحاجبة مدخلاً خاصاً.
لا يملك عارض Google مهلة ثابتة؛ التكلفة في طابور العرض لا في القطع.
يعلّم Insight ‏**“Render blocking requests”** في Lighthouse 13، واسمه السابق “Eliminate render-blocking resources”، نصوص head المفتقرة إلى async/defer وأوراق الأنماط بلا disabled أو media غير مطابقة، انطلاقاً من تتبع واحد؛ أعد الاختبار للتأكيد.
Coverage في DevTools: الأخضر = حرج، والأحمر = غير مستخدم في الرسم الأول.
تضمين CSS متقدم؛ ضمّن المجموعة الحرجة فقط عندما يبين التتبع أنها عنق الزجاجة؛ فتضمين الكل يقتل التخزين المؤقت ويسبب أخطاء.
لا يعاد استخدام preload إلا إذا تطابقت as/type/crossorigin مع الطلب النهائي؛ وتسبب عدم المطابقة جلباً مكرراً.

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

تظل الصفحة فارغة قبل أن تظهر دفعة واحدة

السبب المرجح: تحجز ورقة أنماط أو نص برمجي متزامن في head الرسم الأول. الإصلاح: افحص سلسلة الطلبات المبكرة للمستند، ثم أجّل JavaScript غير الحرجة وقسم CSS غير الحرج أو قلله. التأكيد: يرسم تتبع جديد محتوى مفيداً قبل انتهاء تلك الملفات.

لم يحسن `defer` الرسم الأول

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

تومض الصفحة بلا تنسيق بعد تأجيل CSS

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

يحسن الإصلاح FCP لكنه ينشئ انزياحات في التخطيط

السبب المرجح: تغير الأنماط المؤجلة أو التهيئة المتأخرة للمكونات الأبعاد بعد الرسم. الإصلاح: حافظ على قواعد الحجم والتخطيط الحرجة في العرض الأولي. التأكيد: يبقى الرسم الأول الأسرع ولا يُظهر مسار Layout Shifts أي عدم استقرار جديد.

يعلّم التدقيق مورداً مختلفاً في التشغيل التالي

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

أمثلة مبسطة على حجب العرض

نص برمجي يحجب المحلل مقابل نص مؤجل

يوقف النص الأول تحليل HTML. أما الثاني فيُنزَّل بالتوازي وينتظر اكتمال التحليل.

<!-- Blocks the parser -->
<script src="app.js"></script>

<!-- Better for a script that depends on the parsed document -->
<script defer src="app.js"></script>

ورقة أنماط واحدة لكل إطار عرض مقابل CSS مشروط

تمنع سمة media ورقة أنماط خاصة بالطباعة من حجب العرض على الشاشة.

<link rel="stylesheet" href="screen.css">
<link rel="stylesheet" href="print.css" media="print">

الأنماط الحرجة قبل الحزمة المؤجلة

يجعل هذا النمط المبسط التخطيط الأولي الصغير متاحاً فوراً. ولا تزال تطبيقات الإنتاج تحتاج إلى اختبار CSP والتخزين المؤقت ووميض المحتوى غير المنسق.

<style>
  .site-header { min-height: 4rem; }
</style>
<link rel="stylesheet" href="site.css">

موجه: صنف الموارد الحرجة

الصق تصديراً من Network في DevTools أو قائمة بطلبات CSS وJavaScript المبكرة للمستند.

Act as a web-performance reviewer. Classify each supplied CSS or JavaScript
resource as required for the first viewport, required after HTML parsing, or
non-critical. For every classification, cite the evidence present in my input.
Recommend only one of: keep blocking, defer, async, conditional media, split,
or remove. Flag anything you cannot decide without inspecting runtime behavior.
Do not assume that every stylesheet or script is safe to delay.

INPUT:
[paste the request list, initiators, timing, and what the resource controls]

موجه: راجع فرق تنفيذ

Review this HTML/CSS/JavaScript diff for render-path regressions. Check script
ordering, DOM dependencies, critical CSS coverage, flashes of unstyled content,
layout-shift risk, duplicate downloads, and failure when JavaScript is delayed.
Return a table with: finding, evidence from the diff, user-visible risk, test to
run, and safest correction. Do not invent page behavior not shown in the input.

DIFF:
[paste the diff]

اسرد موارد head التي يحتمل أن تحجب العرض

الصق هذا في Console ضمن DevTools. الناتج قائمة انتظار للتدقيق، لا تعليمة بتأجيل كل شيء.

const headResources = [...document.head.querySelectorAll('link[rel="stylesheet"], script[src]')]
  .map((element) => ({
    type: element.tagName.toLowerCase(),
    url: element.href || element.src,
    async: element.tagName === 'SCRIPT' ? element.async : undefined,
    defer: element.tagName === 'SCRIPT' ? element.defer : undefined,
    media: element.tagName === 'LINK' ? element.media || 'all' : undefined,
  }));

console.table(headResources);

اعثر على الموارد التي اكتمل تحميلها قبل الرسم الأول

const firstPaint = performance.getEntriesByName('first-contentful-paint')[0]?.startTime;
console.table(
  performance.getEntriesByType('resource')
    .filter((entry) => firstPaint && entry.responseEnd <= firstPaint)
    .map((entry) => ({ name: entry.name, type: entry.initiatorType, end: Math.round(entry.responseEnd) }))
);

استهلكت الموارد في هذه القائمة وقتاً قبل FCP، لكن التوقيت وحده لا يثبت أن المورد حجب العرض. أكد ذلك عبر التتبع وسلسلة الاعتماد.

أدوات للعثور على عوائق العرض

PageSpeed Insights وLighthouse: يحددان فرص طلبات حجب العرض في تشغيل مختبري قابل للتكرار. تعامل مع التوفير المقدر كدليل أولي لا ضمان.
لوحة Performance في Chrome DevTools: اربط الطلبات وتحليل HTML وتنفيذ النصوص وحساب الأنماط وأول إطار مرسوم على خط زمني واحد.
لوحة Network في Chrome DevTools: افحص أولوية الطلبات والجهات التي بدأتها وتوقيتها والبروتوكول وسلوك الذاكرة المؤقتة وترتيب وصول الملفات الحرجة.
لوحة Coverage في Chrome DevTools: اعثر على CSS وJavaScript غير المستخدمة في الرحلة المسجلة. ولا تعني تغطية مسار واحد الإذن بحذف شيفرة مستخدمة في موضع آخر.
WebPageTest: قارن الشلالات وأشرطة الصور عبر مواقع وملفات اتصال مختلفة.

سير العمل المفيد هو Lighthouse للحصول على الدليل الأولي، ولوحتا Performance وNetwork لمعرفة السبب، ثم تسجيل مقيد قبل التغيير وبعده لإثبات النتيجة.

أثبت نجاح إصلاح حجب العرض

اختبار النص البرمجي المؤجل

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

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

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

مقارنة المسار الحرج

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

اختبر نفسك: الموارد التي تحجب العرض

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الموارد التي تحجب العرض

ما معنى «حجب العرض»؟

النوعان

لماذا يهم؟

الإصلاحات البسيطة

مسار العرض الحرج

يحجب CSS العرض افتراضياً — عندما يكون منطبقاً

النصوص البرمجية: تحجب المحلل افتراضياً، وتحجب العرض عند الطلب رسمياً

الفرق بين async وdefer — ليستا متماثلتين

كيف يؤثر ذلك في SEO؟

زاوية كفاءة الزحف — بعد التصحيح

كيفية العثور عليها

كيفية إصلاحها

قراءات ذات صلة في هذا الموقع

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

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

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

قائمة تحقق لإصلاح حجب العرض

ورقة مرجعية سريعة لحجب العرض

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

تظل الصفحة فارغة قبل أن تظهر دفعة واحدة

لم يحسن defer الرسم الأول

تومض الصفحة بلا تنسيق بعد تأجيل CSS

يحسن الإصلاح FCP لكنه ينشئ انزياحات في التخطيط

يعلّم التدقيق مورداً مختلفاً في التشغيل التالي

أمثلة مبسطة على حجب العرض

نص برمجي يحجب المحلل مقابل نص مؤجل

ورقة أنماط واحدة لكل إطار عرض مقابل CSS مشروط

الأنماط الحرجة قبل الحزمة المؤجلة

موجه: صنف الموارد الحرجة

موجه: راجع فرق تنفيذ

اسرد موارد head التي يحتمل أن تحجب العرض

اعثر على الموارد التي اكتمل تحميلها قبل الرسم الأول

أدوات للعثور على عوائق العرض

أثبت نجاح إصلاح حجب العرض

اختبار النص البرمجي المؤجل

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

مقارنة المسار الحرج

اختبر نفسك: الموارد التي تحجب العرض

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

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

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

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

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

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

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

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

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

الفرق بين `async` و`defer` — ليستا متماثلتين

لم يحسن `defer` الرسم الأول