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

.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 أكبر.