Web Performance Optimization & Lighthouse · درس

الموارد الحاجبة للعرض

حدّد تأثير CSS وJavaScript الحاجبين للعرض في أوقات تحميل الصفحة الأولية وخفّف منه

الموارد الحاجبة للعرض درس مجاني في Web Performance Optimization & Lighthouse على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Web Performance Optimization & Lighthouse، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Web Performance Optimization & Lighthouse 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

What Blocks Your Page?

When a browser loads a webpage, it needs to process various resources like HTML, CSS, and JavaScript. Sometimes, certain resources must be fully processed before the browser can start showing any content to the user.

These are called render-blocking resources. They prevent the browser from rendering the page until they are dealt with, delaying the 'First Contentful Paint'.

Quick Look: Browser Rendering

To display a page, the browser goes through a series of steps called the Critical Rendering Path. Key steps include:

Parsing HTML: Builds the Document Object Model (DOM).
Parsing CSS: Builds the CSS Object Model (CSSOM).
Combining: Creates the Render Tree (DOM + CSSOM).
Layout: Calculates positions and sizes of elements.
Paint: Draws pixels on the screen.

Both the DOM and CSSOM are needed before the Render Tree can be built, making CSS a critical part of rendering.

CSS: The Render Blocker

By default, external CSS files are render-blocking. This means the browser will pause rendering until all external stylesheets linked in the <head> of your HTML are downloaded, parsed, and applied.

This is crucial because the browser needs to know how elements should look before it can paint them correctly. If CSS takes a long time to load, your users will see a blank screen for longer.

Example: Default CSS Blocking

Consider this simple HTML. The browser will stop parsing the HTML and wait for style.css to download and be processed before it can render anything.

<!DOCTYPE html>
<html>
<head>
  <title>Blocking CSS</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <h1>Welcome!</h1>
  <p>This content is waiting.</p>
</body>
</html>

Conditional CSS with `media`

You can make some CSS non-render-blocking by using the media attribute in your <link> tag. This tells the browser that a stylesheet only applies under certain conditions (e.g., for print, or specific screen sizes).

If the media condition doesn't match the current viewing environment, the browser will still download the CSS, but it won't block the initial render.

<link rel="stylesheet" href="print.css" media="print">
<link rel="stylesheet" href="mobile.css" media="(max-width: 600px)">

Inline Essential Styles

Another strategy to mitigate render-blocking CSS is to inline critical styles. These are the minimal CSS rules needed to render the 'above-the-fold' content (what users see first).

By placing these styles directly within a <style> tag in the HTML <head>, the browser doesn't need to make an extra network request, speeding up the initial render. Remaining, non-critical CSS can be loaded asynchronously.

JavaScript Stops Everything

Just like CSS, JavaScript can also be render-blocking. When the browser encounters a traditional <script> tag (without async or defer attributes), it pauses HTML parsing.

It then downloads, parses, and executes the JavaScript file. Only after the script has finished executing will HTML parsing resume. This can significantly delay rendering.

Example: Default JS Blocking

Here, the browser will pause parsing the HTML document when it hits script.js. If script.js is large or slow to load, the <h1> and <p> elements will not be parsed or rendered until the script is done.

<!DOCTYPE html>
<html>
<head>
  <title>Blocking JS</title>
  <script src="script.js"></script>
</head>
<body>
  <h1>Content Below Script</h1>
  <p>This waits for the script.</p>
</body>
</html>

`async` & `defer` for Scripts

HTML offers two attributes for <script> tags to prevent JavaScript from blocking rendering:

async: Downloads the script in parallel with HTML parsing. Executes as soon as it's downloaded, potentially before HTML parsing is complete. Good for independent scripts.
defer: Downloads the script in parallel with HTML parsing. Executes only after HTML parsing is fully complete, but before the DOMContentLoaded event. Preserves execution order.

Code Example: Non-Blocking JS

By adding async or defer, the browser can continue parsing HTML while the scripts download. This improves perceived performance.

<!DOCTYPE html>
<html>
<head>
  <title>Non-Blocking JS</title>
  <script async src="analytics.js"></script>
  <script defer src="main-app.js"></script>
</head>
<body>
  <h1>Page Content</h1>
  <p>This renders without waiting for scripts.</p>
</body>
</html>

Spot the Blocker!

Which of the following resources are commonly considered render-blocking by default?

Key Takeaways

Render-blocking resources delay the display of your webpage. Both external CSS and traditional JavaScript can block the browser's rendering process.

For CSS: Use the media attribute for conditional loading and consider inlining critical styles.
For JavaScript: Leverage async for independent scripts or defer for scripts that depend on the DOM, to allow parallel downloading and non-blocking execution.

Optimizing these resources is a crucial step towards faster web performance!

الأسئلة الشائعة

هل درس «الموارد الحاجبة للعرض» مجاني؟

نعم — نص درس «الموارد الحاجبة للعرض» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Web Performance Optimization & Lighthouse، انتقل إلى CoddyKit PRO. تتضمن دورة Web Performance Optimization & Lighthouse 4 دروس في المجموع.

ماذا ستتعلم في «الموارد الحاجبة للعرض»؟

حدّد تأثير CSS وJavaScript الحاجبين للعرض في أوقات تحميل الصفحة الأولية وخفّف منه تتمرن على Web Performance Optimization & Lighthouse مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Web Performance Optimization & Lighthouse؟

لا تُشترط خبرة سابقة. Web Performance Optimization & Lighthouse على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.

كم من الوقت يستغرق درس «الموارد الحاجبة للعرض»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Web Performance Optimization & Lighthouse هذا؟

نعم. كل درس في Web Performance Optimization & Lighthouse يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى Web Performance Optimization & Lighthouse