قائمة React بتجمّد المتصفح؟ Virtualization بيخلّيها 40× أسرع

import { useRef } from 'react';
import { useVirtualizer } from '@tanstack/react-virtual';

export function VirtualList({ items }: { items: string[] }) {
  const parentRef = useRef<HTMLDivElement>(null);

  const rowVirtualizer = useVirtualizer({
    count: items.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 48,
    overscan: 5,
  });

  return (
    <div ref={parentRef} style={{ height: 600, overflow: 'auto' }}>
      <div
        style={{
          height: rowVirtualizer.getTotalSize(),
          position: 'relative',
        }}
      >
        {rowVirtualizer.getVirtualItems().map((virtualRow) => (
          <div
            key={virtualRow.key}
            style={{
              position: 'absolute',
              top: 0,
              left: 0,
              width: '100%',
              height: virtualRow.size,
              transform: `translateY(${virtualRow.start}px)`,
            }}
          >
            {items[virtualRow.index]}
          </div>
        ))}
      </div>
    </div>
  );
}

الـ estimateSize هو تقدير ابتدائي لارتفاع العنصر. لو الارتفاعات متفاوتة، استخدم measureElement لقياس فعلي بعد الرندر.

الأرقام: قبل وبعد

قياس على Chrome DevTools Performance — قائمة 5000 صف، كل صف فيه نص + button + avatar:

• Initial render: من 4200ms لـ 95ms (تحسّن ~44×).
• عدد DOM nodes: من 25,000 لـ 110.
• Memory usage: من 180MB لـ 18MB.
• Scroll FPS: من 22 إلى 60 ثابت.
• Long Task أطول: من 1800ms لـ 12ms.

الافتراض إن المتصفح Chrome 120 على جهاز متوسط (8GB RAM، Apple M1). على أجهزة أضعف الفرق بيكبر؛ على Intel i3 قديم، التحسّن قاسيته 60–80×.

الـ Trade-offs اللي لازم تعرفها قبل ما تنفّذ

Virtualization بتكسب أداء، بتدفع 4 تكاليف صريحة:

1. الـ scrollbar مش بيمثّل الواقع بدقة لو ارتفاعات العناصر متفاوتة جدًا. الحل: measureElement لكن بيكلّفك reflow صغير على كل عنصر جديد يدخل الشاشة.
2. Search/Find داخل الصفحة (Ctrl+F) مش هيلاقي العناصر اللي مش في DOM. لو ده requirement أساسي لمستخدمينك، Virtualization مش حلّك المباشر.
3. Accessibility: screen readers بتعتمد على الـ DOM. لازم تحط role="grid"، aria-rowcount، و aria-rowindex على كل صف، علشان أدوات المساعدة تعرف الحجم الحقيقي للقائمة.
4. الـ CSS بيتعقّد: أي عنصر فيه position: sticky أو animations معقدة هيحتاج تعديل، لأن العناصر بتتحرّك بـ transform: translateY بدل ما تقعد مكانها.

متى لا تستخدم Virtualization

القاعدة العملية: تحت 200 عنصر مش محتاج Virtualization أصلًا، وممكن تضيف تعقيد بدون فايدة. ركّز على البدائل دي:

• قوائم أقل من 200 عنصر: استخدم pagination أو infinite scroll عادي. التحسّن مش هيظهر للمستخدم.
• عناصر معقدة جدًا داخل كل صف (charts كاملة، فيديوهات): الـ Virtualization مش هتحلّ بطء العنصر نفسه. الحل: قلّل تعقيد العنصر أولًا.
• SEO-critical content: محرّكات البحث بتشوف الـ DOM المرسوم. لو محتواك لازم يتفهرس، Virtualization هيخفي 99% منه عن Googlebot.
• طباعة الصفحة: المستخدم لما يطبع، هيطلع له الـ 20 عنصر اللي في الـ DOM بس. لو فيه print view، اعمل توجل يعطّل الـ Virtualization مؤقتًا.

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

افتح أكبر قائمة في تطبيقك دلوقتي. شغّل Chrome DevTools → Performance → سجّل scroll لمدة 5 ثواني. لو الـ FPS تحت 50 أو فيه Long Tasks فوق 50ms، أنت محتاج Virtualization. ابدأ بـ TanStack Virtual، طبّق المثال فوق على أبسط جدول عندك، وقيس قبل وبعد بنفس الـ DevTools. لو الفرق أقل من 5×، المشكلة مش في عدد العناصر، هي في تعقيد الصف نفسه.

مصادر

• TanStack Virtual Documentation — tanstack.com/virtual/latest
• React docs على Render & Commit — react.dev/learn/render-and-commit
• web.dev — Optimize Long Tasks — web.dev/articles/optimize-long-tasks
• Chrome DevTools Performance Reference — developer.chrome.com/docs/devtools/performance
• MDN — Web Performance: Layout & Paint — developer.mozilla.org/Web/Performance