Next.js performans optimizasyonu: Core Web Vitals için pratik rehber
Next.js performans optimizasyonu: Core Web Vitals için pratik rehber
Performans, yalnızca yüksek Lighthouse puanı değildir. Ziyaretçinin ilk anlamlı içeriği ne kadar hızlı gördüğü, sayfanın yüklenirken kayıp kaymadığı ve etkileşimlerin ne kadar akıcı hissettirdiğidir. Next.js pek çok optimizasyonu varsayılan olarak sunar; yine de doğru render stratejisi ve doğru varlık kullanımı geliştiricinin kararına bağlıdır.
Önce metriği, sonra çözümü seçin
LCP genellikle en büyük görünür öğenin — çoğu kez hero görseli veya başlık bloğu — ne zaman yüklendiğiyle ilgilidir. CLS, yükleme sırasında öğelerin yer değiştirmesidir. İnceleme yaparken önce gerçek sayfada hangi öğenin LCP olduğunu görün; ardından bu öğenin görsel, font, API isteği veya render beklemesi olup olmadığını ayırın.
Görselleri boyutuyla birlikte servis edin
next/image, farklı cihazlara uygun boyutlar, modern formatlar ve lazy loading ile görsel yüklemeyi iyileştirir. Uzak bir görsel kullanıyorsanız width/height ya da ölçüleri belirlenmiş bir kapsayıcıyla fill verin. Böylece tarayıcı görsel gelmeden alanı ayırır ve CLS azalır.
<Image
src={post.coverImage}
alt={post.title}
width={1200}
height={630}
sizes="(max-width: 768px) 100vw, 768px"
/>
Hero görselini bilinçli seçin; sayfanın altında kalan görseli erken yüklemeye zorlamak LCP'yi iyileştirmez, bant genişliğini tüketir. Remote image alanlarını remotePatterns ile olabildiğince dar tanımlayın.
Server Component varsayılanını koruyun
App Router'da page ve layout'lar varsayılan olarak Server Component'tir. Bir bileşeni sadece küçük bir tıklama davranışı için "use client" yapmak, istemciye gereksiz JavaScript taşıyabilir. Etkileşim gerektiren küçük parçayı client component yapın; veri okuma ve statik sunum katmanını sunucuda bırakın.
Bu yaklaşım hem ilk JavaScript maliyetini hem de karmaşıklığı azaltır. Özellikle blog listeleri, içerik sayfaları ve hakkımda gibi sayfalarda kullanıcı tarayıcısına tüm veri alma mantığını göndermek için güçlü bir neden yoktur.
Cache kararını içerik ömrüne göre verin
Her veri aynı tazelikte olmak zorunda değildir. Sık değişmeyen sayfalar statik üretim ve CDN cache'ten faydalanabilir; yönetim paneli gibi kullanıcıya özel ekranlar ise dinamik olmalıdır. Bir içerik yayımlandığında hangi cache'in ne zaman güncelleneceğini baştan belirleyin.
Production'da Next.js statik ve dinamik rotalar için farklı Cache-Control davranışları üretir. Bu nedenle bir CDN önündeyseniz sadece uygulama cache'ini değil, CDN'nin sürelerini de kontrol edin.
Üçüncü taraf kodu bütçelendirin
Analitik, chat widget'ı ve izleme script'leri kolayca ana iş parçacığını meşgul eder. Her script için şu soruyu sorun: Bu sayfanın ilk görünümünde gerçekten gerekli mi? Gerekliyse uygun yükleme stratejisiyle ekleyin; değilse kullanıcı etkileşimine veya sayfa sonrasına erteleyin.
Yayın öncesi kontrol listesi
- LCP öğesi belirlendi mi ve hızlı yükleniyor mu?
- Her uzak görselin alanı tanımlı mı?
- Gereksiz
use clientsınırları kaldırıldı mı? - Fontlar ve üçüncü taraf script'ler ölçüldü mü?
- Cache süresi, içerik güncellenme sıklığıyla uyumlu mu?
- Mobil ağda gerçek sayfa deneyimi test edildi mi?
Performans çalışması sürekli bir döngüdür: ölç, en büyük darboğazı düzelt, tekrar ölç. Teknik SEO için de aynı disiplin geçerlidir; Next.js SEO rehberindeki metadata ve sitemap katmanları, hızlı bir sayfanın doğru anlaşılmasını sağlar.