Next.js 16 ile milisaniyeleri kovalamak: bir performans günlüğü

Bir müşteri projesinde LCP 2.8 saniyeydi ve herkesin bir teorisi vardı: 'Fontlar yavaş', 'CDN kötü', 'React fazla ağır'. Kimse ölçmemişti. Bu yazı, iki haftada 0.9 saniyeye inerken tuttuğumuz günlüğün özetidir.

Önce ölç, sonra dokun

İlk kural: hissederek optimizasyon yapılmaz. Chrome DevTools'un performans paneli ve gerçek kullanıcı verisi (CrUX) olmadan attığımız her adım kumar olurdu. İlk ölçüm bize sürpriz bir gerçek söyledi: en büyük maliyet fontlar değil, hero görselinin ta kendisiydi.

Görsel 1.4MB'lık bir PNG'ydi ve preload edilmemişti. next/image'e geçirip priority işaretledik, AVIF'e çevirdik: tek başına 1.1 saniye kazandırdı.

Font stratejisi: swap yetmez

next/font ile self-hosting'e geçtik, display: swap ayarladık ve fallback fontun metriklerini gerçek fonta yaklaştırdık. Böylece font yüklendiğinde layout shift oluşmuyor — CLS 0.11'den 0.01'e indi.

Edge cache ve sonuç

Statik üretilebilen her sayfayı statik ürettik; kişiselleştirilmiş parçaları küçük client adalarına ayırdık. Sonuç: LCP 0.9s, TTFB 98ms, Lighthouse 100.

En önemli ders teknik değil kültürel: performans bir sprint görevi değil, her PR'da korunan bir bütçedir. Bütçeyi CI'a koyduk — eşiği aşan PR kırmızı yanıyor.