اللغات

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

شرح خط أنابيب المتصفح من البايتات إلى البكسلات: DOM وCSSOM وشجرة العرض والتخطيط والرسم، وحجب CSS وJavaScript، ووسائل التحسين وتأثير المسار في FCP وLCP وعرض Googlebot.

نُشر أول مرة: 26 يونيو 2026 · آخر تحديث: 14 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2

مسار العرض الحرج هو العمل المرتب بالتبعيات قبل رسم أول بكسل: HTML إلى DOM، وCSS إلى CSSOM، ثم شجرة العرض والتخطيط والرسم والتركيب. يحجب CSS الرسم حين ينطبق، وتحجب JavaScript المتزامنة تحليل DOM. يعني التحسين تقليل عدد الموارد الحرجة وطول المسار والبايتات الحرجة. يتتبع FCP اكتماله بوصفه محطة لا تشخيصًا كاملًا، وقد يؤخر المسار LCP. وتستخدم WRS لدى Googlebot ‏Chromium بلا حالة وبذاكرة باردة، لذا لا تحجب CSS أو JS الحرج في robots.txt.

الخلاصة — مسار العرض الحرج خط أنابيب من البايتات إلى الرسم الأول: HTML ← DOM، وCSS ← CSSOM، ثم DOM + CSSOM ← شجرة العرض ← التخطيط ← الرسم. يحجب CSS العرض حتى بناء CSSOM، ويعطل برنامج JavaScript النصي المتزامن بناء DOM عند كل برنامج نصي. حسّن المسار بتقليل الموارد الحرجة وطوله، أي جولات الشبكة، وبايتاته. يتتبع FCP اكتماله بوصفه محطة لا تشخيصًا كاملًا؛ ويشير فرق TTFB إلى FCP الكبير إلى موارد حاجبة، وقد يؤخر المسار LCP. تشغل خدمة WRS لدى Googlebot متصفح Chromium بلا حالة وبذاكرة مؤقتة باردة فعليًا، لذا تبطئها الموارد الحاجبة، ويجب ألا يُحجب CSS/JS الحرج في robots.txt. من الأدوات: تضمين CSS الحرج، وتحميل CSS غير الحرج عبر استعلامات الوسائط، واستخدام defer وpreload للموارد المثبتة على المسار.

خط الأنابيب ذي الخطوات الخمس: من البايتات إلى البكسلات

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

1. ‏HTML ← DOM. يصف web.dev البناء هكذا: “Bytes → characters → tokens → nodes → object model.” (ترجمة) «بايتات ← محارف ← رموز ← عُقد ← نموذج كائنات». ويقول إن المتصفح “reads the raw bytes of HTML off the disk or network, and translates them to individual characters,” (ترجمة) «يقرأ بايتات HTML الخام من القرص أو الشبكة ويحولها إلى محارف منفردة»، ثم يحولها إلى رموز وكائنات وشجرة. والناتج النهائي هو “the Document Object Model (DOM) of our simple page, which the browser uses for all further processing.” (ترجمة) «نموذج كائن المستند للصفحة، الذي يستخدمه المتصفح في كل المعالجة اللاحقة».

2. ‏CSS ← CSSOM. يسلك CSS المسار نفسه: “The CSS bytes are converted into characters, then tokens, then nodes, and finally they are linked into a tree structure known as the ‘CSS Object Model’ (CSSOM).” (ترجمة) «تتحول بايتات CSS إلى محارف ثم رموز ثم عُقد، وتُربط أخيرًا في شجرة تسمى CSSOM». والأهم أن “The CSSOM and DOM are independent data structures” (ترجمة) «CSSOM وDOM بنيتان مستقلتان»، تُبنيان بالتوازي.

3. ‏DOM + CSSOM ← شجرة العرض. “The DOM and CSSOM trees combine to form the render tree,” (ترجمة) «تتحد شجرتا DOM وCSSOM لتكوين شجرة العرض»، التي “captures all the visible DOM content on the page.” (ترجمة) «تلتقط كل محتوى DOM المرئي». وهنا يختلف display: none، الذي يزيل العنصر، عن visibility: hidden، الذي يبقيه في التخطيط بلا رسم.

4. التخطيط. “Layout computes the exact position and size of each object.” (ترجمة) «يحسب التخطيط موضع كل كائن وحجمه بدقة». وينتج “a ‘box model,’ which precisely captures the exact position and size of each element within the viewport.” (ترجمة) «نموذج صندوق يحدد موضع كل عنصر وحجمه داخل إطار العرض».

5. الرسم. “The last step is paint, which takes in the final render tree and renders the pixels to the screen.” (ترجمة) «الخطوة الأخيرة هي الرسم؛ تأخذ شجرة العرض النهائية وترسم البكسلات على الشاشة».

6. التركيب والعرض. تُدمج الطبقات المرسومة ويُعرض الناتج على الشاشة. ويمكن لخصائص مثل transform وopacity إعادة هذه الخطوة وحدها بلا تخطيط أو رسم جديد، لذلك هي أرخص تحريكًا.

Evidence for this claim The browser constructs the DOM and CSSOM, combines them into a render tree, performs layout, and paints pixels. Scope: web.dev explanation of the browser's critical rendering path. Confidence: high · Verified: web.dev: Constructing the object model

مسار العرض الحرج هو الجزء الواجب اكتماله قبل الرسم الأول. ويصف web.dev تحسينه بأنه “all about understanding what happens in these intermediate steps between receiving the HTML, CSS, and JavaScript bytes and the required processing to turn them into rendered pixels.” (ترجمة) «فهم ما يحدث بين استلام بايتات HTML وCSS وJavaScript ومعالجتها إلى بكسلات معروضة».

نوعان من الحجب وآليتان مختلفتان

تخلط كتابات SEO غالبًا بينهما، لذا يستحقان الدقة.

يحجب 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». يحجب HTML وCSS العرض حتى وجود DOM وCSSOM، لكن عنصر <link> الذي لا يطابق شرط media، مثل media="print" في شاشة عادية، لا يحجب، وإن نُزل. وقد تبدأ ورقة غير منطبقة في التأثير لاحقًا إذا تغير الوسيط أو إطار العرض أو DOM، فتتكرر أعمال الأنماط والتخطيط والرسم. لذلك قد تحتجز ورقة بطيئة منطبقة في <head> الرسم الأول.

تحجب JavaScript بناء DOM. تقول وثائق PageSpeed: “whenever the parser encounters a script it has to stop and execute it before it can continue parsing the HTML,” (ترجمة) «كلما صادف المحلل برنامجًا نصيًا وجب أن يتوقف وينفذه قبل متابعة تحليل HTML»، ومع البرنامج النصي الخارجي ينتظر التنزيل أيضًا. والنتيجة: “By default JavaScript blocks DOM construction and thus delays the time to first render.” (ترجمة) «تحجب JavaScript افتراضيًا بناء DOM فتؤخر أول عرض». ويواصل ماسح التحميل المسبق اكتشاف الموارد أثناء توقف المحلل. يزيل async حجب التنزيل، لكن التنفيذ قد يقاطع الخيط الرئيسي؛ ويكون defer أكثر أمانًا عادة لأنه ينتظر اكتمال التحليل ويحفظ الترتيب.

Evidence for this claim CSS is render-blocking by default, while parser-blocking scripts stop DOM construction until execution completes. Scope: Default stylesheet and synchronous script behavior in the critical rendering path. Confidence: high · Verified: web.dev: Render-blocking CSS web.dev: Adding interactivity with JavaScript

وسائل التحسين الثلاث

يقول web.dev: “To deliver the fastest possible time to first render, we need to minimize three variables: The number of critical resources. The critical path length. The number of critical bytes.” (ترجمة) «لتحقيق أسرع رسم أول، نقلل عدد الموارد الحرجة وطول المسار الحرج وعدد البايتات الحرجة». و*“A critical resource is a resource that could block initial rendering of the page.”* (ترجمة) «المورد الحرج هو ما قد يحجب العرض الأول».

  • قلل عدد الموارد الحرجة — احذفها أو أجّل تنزيلها أو علّمها async.
  • قلل طول المسار الحرج — وهو “a function of the dependency graph between the critical resources.” (ترجمة) «دالة في مخطط التبعيات بين الموارد الحرجة». قلل جولات الشبكة.
  • قلل البايتات الحرجة — “the fewer critical bytes the browser has to download, the faster it can process content.” (ترجمة) «كلما قلت البايتات الحرجة التي ينزلها المتصفح عالج المحتوى أسرع». صغّر واضغط وقسّم.

عمليًا: ضمّن CSS الحرج فوق الطية في <head> وحمّل الورقة الكاملة بلا حجب؛ وحدد CSS غير الحرج بعنصر <link rel="stylesheet" media="print">؛ واستخدم defer لـJavaScript غير الضرورية؛ وحمّل مسبقًا ما ثبتت حاجتك إليه. وفي دليل LCP لدى Ahrefs أقول: “you want to rearrange the order in which the resources are downloaded and processed” (ترجمة) «أعد ترتيب تنزيل الموارد ومعالجتها»، وإن تضمين CSS الحرج “takes the part of the CSS needed to load the content users see immediately and then applies it directly into the HTML.” (ترجمة) «يأخذ CSS اللازم للمحتوى المرئي فورًا ويضعه مباشرة في HTML».

يؤدي preload وfetchpriority وظيفتين مختلفتين. يجبر preload المتصفح على جلب مورد مبكرًا قبل اكتشافه المعتاد، أما fetchpriority فلا يجلب شيئًا بل يغير أولوية طلب قائم. وقد يهدر preload بعنوان أو قيمة as أو وضع بيانات اعتماد خاطئ، أو يكرر الطلب، كما يمحو تعليم موارد كثيرة بأولوية عالية فائدة الترتيب. استخدمه فقط لمورد أثبت شلال الطلبات وجوده على المسار، ثم تحقق بتتبع آخر.

الصلة بـCore Web Vitals: زاوية SEO

لهذا لا يخص المسار المطورين وحدهم.

  • يتتبع FCP اكتمال المسار، لكنه محطة لا تشخيصًا كاملًا. يحدث عند أول رسم للمحتوى، فيظهر المسار الطويل عادة FCP متأخرًا، لكنه لا يحدد المرحلة المسببة، ولا يضمن FCP السريع انتهاء كل تبعية. تتبع السبب.
  • قد يرث LCP التأخير. تقول Abby Hamilton: “Optimizing the critical rendering path will typically have the largest impact on Largest Contentful Paint (LCP) since it’s specifically focused on how long it takes for pixels to appear on the screen.” (ترجمة) «يؤثر تحسين المسار غالبًا أكثر في LCP لأنه يركز على زمن ظهور البكسلات». ويقول web.dev: “A large delta between TTFB and FCP could indicate that the browser needs to download a lot of render-blocking assets.” (ترجمة) «قد يشير فرق كبير بين TTFB وFCP إلى تنزيل موارد حاجبة كثيرة». إنه مؤشر لا سببًا جذريًا؛ أكده بتتبع.
  • تتأثر TBT وINP بJavaScript. تتنافس البرامج النصية الحرجة على الخيط الرئيسي، وتضر المهام الطويلة بالتفاعل.

يتأثر LCP وFCP بسرعة عبور المسار، وLCP من Core Web Vitals التي تستخدمها Google إشارة ترتيب. لكن النتائج الميدانية وأثر الترتيب المحدد تحتاج إلى دليل CrUX أو Search Console، لا تتبع مختبري سريع وحده.

كيف يتأثر Googlebot؟

تقول Google إن تطبيقات JavaScript تمر بثلاث مراحل: الزحف والعرض والفهرسة، ثم “Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript” (ترجمة) «عندما تسمح موارد Google، يعرض Chromium بلا واجهة الصفحة وينفذ JavaScript» باستخدام إصدار دائم التحديث. اشتراك Chrome وWRS في المحرك يجعل استنتاج تباطؤ العرض بالموارد الحاجبة معقولًا، لكنه لا يثبت تطابق كل تأخير مع المستخدم أو عقوبة فهرسة أو ترتيب؛ يحتاج ذلك إلى دليل Search Console وفهرسة للصفحة.

ثلاث نتائج ينبغي استيعابها:

  • تضيف قائمة العرض تأخيرًا. تنتظر الصفحات “a few seconds, but it can take longer than that” (ترجمة) «بضع ثوان، وقد تطول»؛ ويضاعف المسار البطيء التأخير.
  • WRS بلا حالة وبذاكرة باردة فعليًا. أصفه في دليل JavaScript SEO هكذا: “Google loads each page stateless like it’s a fresh load.” (ترجمة) «تحمل Google كل صفحة بلا حالة كأنها زيارة جديدة». وتؤكد وثائق Google أن WRS لا يحتفظ بالحالة وقد “may ignore caching headers,” (ترجمة) «يتجاهل ترويسات التخزين»، ما “may lead WRS to use outdated JavaScript or CSS resources.” (ترجمة) «قد يجعله يستخدم موارد قديمة».
  • لا تحجب الموارد الحرجة في robots.txt. يحتاج WRS إلى CSS وJS. وكما يقول دليلي: “Don’t block access to resources if they are needed to build part of the page or add to the content.” (ترجمة) «لا تحجب الموارد اللازمة لبناء جزء من الصفحة أو إضافة محتواها».

لا يملك Bing سلسلة وثائق مماثلة، لكن المبدأ عام لأي زاحف يعتمد متصفحًا. وميزانية عرض Bingbot أشد تقييدًا من Google، ما يزيد أهمية المسار الخفيف.

حالة طرفية: الرسم المبكر لا يثبت وجود المحتوى

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

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

أين يلتقي ممارسو SEO بالمسار؟

أكثر نقاط الالتقاء تدقيق PageSpeed Insights/Lighthouse المسمى “Eliminate render-blocking resources” (ترجمة) «إزالة الموارد الحاجبة للعرض». تصف Abby Hamilton سير العمل: “navigate to ‘Eliminate render-blocking resources’ under ‘Diagnostics,’ and expand the content to see a list of first-party and third-party resources blocking the first paint.” (ترجمة) «انتقل إلى التشخيصات وافتح التدقيق لرؤية موارد الطرف الأول والثالث التي تحجب الرسم الأول». وفي WebPageTest اقرأ الشلال قبل خط Start Render، وفي DevTools استخدم Coverage. وقد تغير الاتصالات الخارجية والموافقة وservice worker ودفء الذاكرة نتيجة كل تشغيل؛ التتبع الواحد عينة لا ضمان.

موضوعات مرتبطة: إلى أين تذهب تاليًا؟

هذه الصفحة محور العمل على الموارد الحاجبة، ويأتي الشرح العملي تحتها:

  • الموارد الحاجبة للعرض — دليل عملي للعثور على CSS وJavaScript الحاجبتين في PageSpeed Insights وLighthouse وWebPageTest، وفهم async وdefer، وتضمين CSS الحرج، واستعلامات الوسائط، وإصلاح التحذير خطوة بخطوة.

للمقاييس راجع Core Web Vitals وLargest Contentful Paint ‏(LCP) وFirst Contentful Paint ‏(FCP). ولعرض Googlebot راجع JavaScript SEO ومحور عمل البحث.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.