صفحة طويلة بطيئة؟ content-visibility ينزل الرندر من 232ms لـ 30ms

مستوى القارئ: متوسط

هتكسب تحميل أولي أخف في الصفحات الطويلة، بدون ما تغيّر API أو تفكّر في Virtual Scrolling من أول يوم.

المشكلة باختصار

لو عندك صفحة فيها 80 كارت منتج، أو صفحة مقالة طويلة فيها صور وجداول وتعليقات، المتصفح غالبًا بيعمل style وlayout وpaint لأجزاء المستخدم لسه مش شايفها. الطريقة دي بتفشل لما المحتوى تحت الشاشة يبقى كبير، لأن الـ main thread بيتشغل في شغل غير مرئي بدل ما يجهز الجزء الأول بسرعة.

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

مثال بسيط قبل التعريف العلمي

ركز في المثال ده. عندك صفحة pricing فيها 60 بطاقة. المستخدم أول ما يفتح الصفحة شايف أول 8 بطاقات فقط. بدل ما المتصفح يرندر الـ 60 بطاقة كلها، خليه يرندر الظاهر الآن ويؤجل الباقي لحد ما يقرب من الشاشة.

.pricing-section,
.product-row,
.comment-block {
  content-visibility: auto;
  contain-intrinsic-size: auto 420px;
}

اللي بيحصل فعلاً: `content-visibility: auto` يسمح للمتصفح يتخطى رندر subtree خارج الشاشة. و`contain-intrinsic-size` يديله حجمًا تقديريًا مؤقتًا، بدل ما الصفحة تنهار أو يحصل قفز مزعج في السكول.

التعريف الأدق: الخاصية بتضيف containment مناسب للرندر، وبالنسبة للعناصر خارج viewport المتصفح يقدر يؤجل layout وpaint والـ hit testing لأبنائها. لما العنصر يقرب من الشاشة، يرجع يرندره في الوقت المناسب.

خطوات التطبيق على صفحة حقيقية

1. قسّم الصفحة لأقسام مستقلة: كارت منتج، block تعليقات، أو section من المقال.
2. لا تضف الخاصية على عنصر صغير جدًا مثل زر أو عنوان. المكسب هناك شبه صفر.
3. ابدأ بالأقسام التي ارتفاعها معروف تقريبًا، مثل 300 إلى 600px.
4. قِس قبل وبعد من Chrome Performance panel أو Lighthouse timespan.

<main class="catalog">
  <section class="product-row">... أول مجموعة منتجات ...</section>
  <section class="product-row">... ثاني مجموعة منتجات ...</section>
  <section class="product-row">... ثالث مجموعة منتجات ...</section>
</main>

.product-row {
  content-visibility: auto;
  contain-intrinsic-size: auto 520px;
}

@media (max-width: 768px) {
  .product-row {
    contain-intrinsic-size: auto 760px;
  }
}

لو عندك موقع بـ 50K زائر يوميًا وصفحة category فيها 120 منتج، ده ممكن يقلل وقت الرندر الأولي من مئات المللي ثانية لعشرات المللي ثانية في الأجهزة المتوسطة. في مثال web.dev المنشور عن الخاصية، الرندر نزل من 232ms إلى 30ms عند تقسيم المحتوى وتطبيق `content-visibility: auto`. الرقم مش وعد ثابت، لكنه اتجاه ممتاز للقياس.

الـ trade-off هنا

المكسب واضح: main thread أهدأ في بداية التحميل، والجزء المرئي يظهر أسرع. الثمن: لازم تختار `contain-intrinsic-size` بذكاء. لو الرقم أصغر أو أكبر من الواقع جدًا، المستخدم ممكن يشوف قفزة في السكول لما العنصر يدخل الشاشة.

فيه trade-off تاني: لو كود JavaScript عندك بيقرأ layout لأجزاء خارج الشاشة باستخدام `getBoundingClientRect` أو قياسات متكررة، ممكن تجبر المتصفح يعمل جزء من الشغل المؤجل. أفضل طريقة هنا إنك تقلل قياسات DOM غير الضرورية، أو تستخدم `IntersectionObserver` لو محتاج تعرف العنصر قرب من الشاشة.

متى لا تستخدم هذه الطريقة

لا تستخدمها بدل Virtual Scrolling لو عندك آلاف العناصر في نفس الصفحة. `content-visibility` يقلل تكلفة الرندر، لكنه لا يقلل حجم الـ DOM نفسه. لا تستخدمها أيضًا على محتوى لازم يكون مقاسه دقيق من أول frame، مثل hero مرئي، sticky header، أو عنصر تعتمد عليه حسابات layout حساسة.

ولو الصفحة عندك قصيرة أصلًا، مثل landing page من 3 أقسام، غالبًا المكسب أقل من تكلفة التفكير والقياس. ابدأ بالصفحات الطويلة: catalog، documentation، comments، dashboards فيها panels كثيرة.

مصادر اعتمد عليها

• web.dev: شرح content-visibility وتأثيره على الرندر
• MDN: contain-intrinsic-size
• MDN: Intersection Observer API

الخطوة التالية

افتح أثقل صفحة طويلة عندك، اختَر 5 أقسام خارج أول شاشة، وطبّق `content-visibility: auto` مع `contain-intrinsic-size`. قِس rendering time قبل وبعد. لو الفرق أقل من 50ms، سيبها ودوّر على bottleneck أكبر.