React Render Performans Optimizasyonu

Bu makale Frontend alanındaki deneyimlerimi ve yazılım geliştirme metodolojimi aktarmaktadır.

Genel Bakış

React Suspense, Lazy Loading ve RSC (React Server Components) konseptleri ile gereksiz re-render problemlerinin nasıl önüne geçilir? UseMemo ve UseCallback hook'larının doğru zamanda kullanımı üzerine case studyler inceledik.

React'in popülerliği arttıkça, sıkça karşılaşılan performans darboğazlarının başında "gereksiz tekrar render edilme" (unnecessary re-renders) sorunu geliyor. Dashboardlarında 2000'den fazla DOM node'u barındıran Elly admin panelimizde bu problemi bizzat yaşadık: bir filtreleme input'una her karakter yazıldığında tüm tablo satırları yeniden render ediliyordu ve Chrome DevTools Profiler'da 300ms+ render süreleri görüyorduk.

Çözüm sürecinde React DevTools Profiler ile render waterfall'ları analiz ettik ve darboğaz noktalarını tespit ettik. React.memo, useMemo ve useCallback fonksiyonlarını her yerde değil, yalnızca profiler'da kırmızı işaretli olan bileşenlerde uyguladık. Premature optimization tuzağına düşmeden, veri odaklı karar aldık.

// ❌ Anti-pattern: Her render'da filtre fonksiyonu yeniden oluşur
function Dashboard({ items }) {
  const filtered = items.filter(i => i.active) // Her render'da çalışır
  return <DataTable data={filtered} />
}
 
// ✅ Doğru yaklaşım: Sadece items değiştiğinde hesapla
function Dashboard({ items }) {
  const filtered = useMemo(() => items.filter(i => i.active), [items])
  return <DataTable data={filtered} />
}
 
// Ağır liste bileşenlerini memo ile sarmalama
const TableRow = memo(function TableRow({ row }: { row: RowData }) {
  return (
    <tr>
      <td>{row.name}</td>
      <td>{row.status}</td>
    </tr>
  )
})

10.000+ satırlık tablolar için ise @tanstack/react-virtual (eski adıyla react-window) ile virtualization uyguladık. Ekranda yalnızca görünen 20-30 satır DOM'a yazılıyor, geri kalanı viewport dışında kalıyor. Bu teknikle initial render süremiz 300ms'den 18ms'ye düştü.

React Server Components (RSC) ile bu optimizasyonların bir kısmı artık sunucu tarafında çözülüyor: veri çekme ve filtreleme sunucuda yapılıp istemciye sadece render-ready HTML gönderiliyor. Bu da JavaScript bundle boyutunu küçültürken, Time to Interactive (TTI) metriğini dramatik biçimde iyileştiriyor. Sonuç olarak Lighthouse Performance skoru 62'den 94'e yükseldi.

Bu içerik kişisel geliştirme laboratuvarımdan ve prodüksiyon maceralarımdan derlenmiştir.