Next.js Image Bileşeni SEO ve Performansı Nasıl Etkiler?
Next.js'in next/image bileşeni, görsel optimizasyonun önemli bir kısmını framework katmanında çözme iddiasıyla tasarlanmış. Bu iddia büyük ölçüde doğru — otomatik format dönüşümü, boyutlandırma, lazy loading ve srcset üretimi bileşenin varsayılan davranışına dahil. Ama bu otomasyonun tam olarak ne yaptığını, hangi durumlarda devreye girdiğini ve hangi konfigürasyonların sizin sorumluluğunuzda kaldığını bilmeden kullanmak, fark edilmesi güç performans sorunlarına zemin hazırlar.
Pratikte karşılaşılan tablonun büyük kısmı şöyle özetlenebilir: bileşen doğru içe aktarıldı, görsel ekranda görünüyor, herhangi bir hata yok — ama LCP skoru beklenenin altında, ya da CLS ölçümleri tutarsız, ya da hero görselinin önceliği yanlış ayarlanmış. Bu sorunların ortak kaynağı, next/image'ın neyi otomatik yapıp neyi yapmadığının net olmaması.
Aşağıdaki bölümler bileşenin çalışma mantığını pipeline sırasıyla ele alıyor: yükleme anında neler oluyor, boyutlandırma ve layout modları arasındaki fark ne, priority prop'u nasıl kullanılmalı ve blur placeholder hangi senaryolarda gerçek değer taşıyor. Son olarak, next/image'a gerek duyulmayan ya da onun yerine manuel <img> tercih edilebilecek durumlar da ele alınıyor.
next/image otomatik optimizasyonu: yükleme anında ne oluyor
Bir görsel next/image üzerinden yüklendiğinde Next.js, görsel dosyasını Next.js Image Optimization API'si üzerinden sunar. Bu API, gelen isteğin Accept başlığını okur; tarayıcı WebP destekliyorsa WebP, AVIF destekliyorsa AVIF çıktısı üretir. Kaynak dosya JPEG olsa bile çıkıştaki format tarayıcıya göre belirlenir. WebP'nin dosya boyutu avantajı bu aşamada otomatik olarak devreye girer; herhangi bir dönüştürme adımı gerektirmeden.
Boyutlandırma tarafında bileşen, verilen width ve height değerlerine göre srcset üretir. Next.js'in next.config.js dosyasında tanımlanan imageSizes ve deviceSizes dizileri bu üretimin sınırlarını belirler. Varsayılan değerler çoğu proje için yeterli; ama medya yoğun bir site için bu dizilerin özelleştirilmesi anlamlı bir performans farkı yaratabilir. Üretilen her boyut combinasyonu önbelleğe alınır ve sonraki isteklerde doğrudan önbellekten sunulur.
Vercel dışında kendi sunucunuzda Next.js çalıştırıyorsanız bu önbellekleme .next/cache/images dizininde gerçekleşir. Deploy süreçleri bu dizini silerse önbellek sıfırlanır ve tüm görseller yeniden üretilir; yüksek trafikli bir sitede bu durum anlık bir yük artışına neden olabilir. Vercel, bu optimizasyon API'sini kendi altyapısında yönetir ve önbelleği deploy'lardan bağımsız tutar.
Boyutlandırma ve layout: fill ile sabit boyut arasındaki tercih
next/image iki temel kullanım moduna sahip. İlki, width ve height prop'larının açıkça verildiği sabit boyutlu mod. İkincisi, fill prop'uyla etkinleştirilen ve görselin ebeveyn konteynere göre boyutlandığı esnek mod. Bu ikisi arasındaki seçim hem görsel davranışı hem de CLS metriğini doğrudan etkiler.
Sabit boyutlu modda Next.js, verilen değerleri kullanarak görselin placeholder boyutunu önceden belirler. Bu, tarayıcının görsel yüklenmeden önce gereken alanı ayırmasına olanak tanır ve CLS sorununu büyük ölçüde önler. Ancak burada kritik bir nokta var: width ve height görselin gerçek kaynak dosyadaki boyutlarıyla örtüşmeli ya da en azından aynı en-boy oranında olmalı. Farklı oran verildiğinde görsel bozulur ya da beklenmedik şekilde kırpılır.
fill modu ise görselin kapsayıcı elemanı tamamen doldurduğu senaryolar için tasarlanmış — galeri grid'leri, arka plan benzeri hero alanları, oranı dinamik olan konteynerlerde. Bu modda ebeveyn elemana mutlaka position: relative ve belirli bir boyut verilmesi gerekiyor; aksi takdirde görsel görünmez. fill modunda objectFit ve objectPosition CSS prop'larıyla kırpma ve hizalama davranışı kontrol edilebilir. Responsive görsel yapısı açısından değerlendirildiğinde, fill modu doğru kullanıldığında oldukça esnek bir çözüm sunar.
priority ve loading davranışı: LCP görseli nasıl doğru işaretlenir
next/image varsayılan olarak tüm görsellere lazy loading uygular. Bu, sayfa yüklendiğinde viewport dışındaki görsellerin hemen indirilmediği anlamına gelir — doğru bir optimizasyon, ama yanlış uygulandığında LCP'yi doğrudan etkiler. Hero görseli, ilk ekranda görünen büyük bir ürün fotoğrafı ya da sayfa açıldığında hemen görünür olan herhangi bir görsel lazy loading'e tabi tutulmamalıdır.
Bu sorunu çözmek için priority prop'u kullanılır: <Image priority />. Bu prop iki şey yapar: görsel için loading="eager" davranışı devreye girer ve Next.js otomatik olarak sayfanın <head> bölümüne bu görsel için bir <link rel="preload"> etiketi ekler. Sonuç olarak tarayıcı görsel dosyasını mümkün olan en erken aşamada talep eder. Hero görselinin LCP optimizasyonu için priority prop'unu vermek neredeyse her zaman gerekli bir adımdır.
Yaygın bir hata, priority prop'unun gereğinden fazla kullanılmasıdır. Her görsel için priority eklendiğinde tüm görseller preload edilir; bu hem bant genişliğini boşa harcar hem de tarayıcının gerçek öncelikli kaynağı belirleyememesine yol açar. Genel kural olarak sayfa başında yalnızca bir, en fazla iki görsele priority verilmeli. Lazy loading'in ne zaman kullanılmaması gerektiği sorusu, next/image bağlamında tam olarak bu noktaya geliyor: ilk ekranda görünen görseller için kesinlikle priority, diğerleri için bileşenin varsayılan lazy davranışı yeterli.
Blur placeholder ve LQIP: yükleme deneyimi nasıl şekillenir
next/image, görsel yüklenene kadar gösterilen bir placeholder mekanizması sunar. placeholder="blur" prop'u ile etkinleştirilir ve iki şekilde kullanılabilir. Statik olarak içe aktarılan görsellerde Next.js, derleme sırasında otomatik olarak küçük bir bulanık veri URI'si üretir ve bunu placeholder olarak kullanır. Bu yöntemde ekstra bir yapılandırma gerekmez.
Harici URL'lerden gelen ya da dinamik görsellerde ise blurDataURL prop'u aracılığıyla manuel olarak bir LQIP (Low Quality Image Placeholder) değeri verilmesi gerekir. Bu değer tipik olarak base64 kodlanmış küçük bir görsel veya tek düz renk içeren bir veri URI'sidir. plaiceholder gibi kütüphaneler bu değeri otomatik olarak üretebilir; büyük görsel koleksiyonlarında derleme zamanında her görsel için ayrı ayrı hesaplanması mümkün.
Blur placeholder'ın gerçek etkisini değerlendirmek önemli. Görsel dosyası küçük ya da bağlantı hızlıysa placeholder çok kısa süre görünür ve kullanıcı fark etmez. Asıl değeri, büyük ve ağır görsellerin yüklenmesinin zaman aldığı durumlarda ortaya çıkar — özellikle mobil bağlantılarda ve yüksek çözünürlüklü hero görsellerinde. Blur geçişi ham beyaz boşluktan daha iyi bir algısal yükleme deneyimi sağlar, ancak LCP veya diğer Core Web Vitals metriklerini doğrudan iyileştirmez. Bu ayrımı net tutmak, placeholder'ı doğru senaryolarda uygulamayı kolaylaştırır.
next/image ile manuel img etiketi arasındaki trade-off
next/image her görsel için doğru tercih değildir. Bileşen, Next.js'in Image Optimization API'sine bağımlıdır; bu API sunucu tarafında çalışır ve belirli bir işlem yükü oluşturur. Statik export (next export) kullanan projeler bu API'yi kullanamaz; next/image'ın optimizasyon özellikleri bu senaryoda devre dışı kalır. Aynı durum bazı edge runtime konfigürasyonları için de geçerlidir.
Görselin zaten optimize edilmiş olduğu durumlarda bileşenin ek değeri azalır. Örneğin harici bir CDN üzerinden sunulan ve orada sıkıştırılıp WebP'ye dönüştürülen bir görsel, next/image üzerinden geçirildiğinde ikinci kez işlenir; bu hem gereksiz bir API çağrısı hem de önbellek yönetimi karmaşıklığı demektir. Bu tür senaryolarda unoptimized prop'u kullanarak optimizasyon pipeline'ını devre dışı bırakmak ya da doğrudan <img> etiketi tercih etmek daha temiz bir çözüm sunar.
Dekoratif görseller, SVG dosyaları ve küçük ikonlar için de next/image'a gerek yoktur. SVG'ler boyutsuz vektör dosyaları olduğundan boyutlandırma ve format dönüşümü anlamlı değil; ikonlar ise zaten küçük boyutları nedeniyle optimizasyon kazancı sınırlı. next/image'in en belirgin değer katığı alan, gerçekten büyük ve ağır raster görsellerin sunulduğu sayfalardır: ürün fotoğrafları, hero görselleri, blog kapakları ve galeri sayfaları. Bu görseller için bileşenin sunduğu otomatik srcset, format dönüşümü ve önbellekleme zinciri, manuel olarak kurulması oldukça zahmetli bir altyapıyı kutudan çıkar hale getirir.
next/image'ın sihir gibi görünen davranışı aslında iyi tanımlanmış bir pipeline'dan kaynaklanıyor. Otomatik WebP dönüşümü, srcset üretimi ve lazy loading birer varsayılan; bunların üzerine koymanız gereken katmanlar ise daha az ama daha kritik: doğru boyut ve oran bilgisi, LCP görseli için priority prop'u ve dinamik görsellerde blur placeholder için blurDataURL. Bu üç noktayı doğru yapılandırdığınızda bileşen gerçek değerini ortaya koyar.
Hangi görselin priority alması gerektiğini belirlemek için PageSpeed Insights veya Lighthouse'un LCP elemanını raporlamasını beklemek yerine, sayfayı açtığınızda ilk göreceğiniz görseli düşünmek yeterli. O görsel next/image ile render ediliyorsa priority prop'u verilmeli. Geri kalan her şey bileşenin varsayılan davranışıyla iyi yönetilir.