Blur Placeholder ve LQIP Nedir?
Bir sayfayı açtığınızda görsel henüz yüklenmemişse ne olur? Tarayıcı o alanı boş bırakır — beyaz ya da gri bir dikdörtgen. Görsel sunucudan gelene kadar içerik orada yokmuş gibi durur. Bağlantı hızı yeterliyse bu süre çoğu zaman fark edilmez; ama yavaş bir mobil ağda ya da büyük bir görsel dosyasında bu bekleme kullanıcıya sayfanın hazır olmadığını hissettirir.
Blur placeholder tam bu boşluğu doldurmak için geliştirilmiş bir yaklaşımdır. Fikir basittir: gerçek görselin yerine geçici olarak çok küçük, düşük kaliteli bir versiyon göster, üzerine CSS blur filtresi uygula, asıl görsel hazır olduğunda yumuşak bir geçişle değiştir. Kullanıcı boş bir kutu görmek yerine içeriğin renk atmosferini ve kabaca formunu önceden görür.
LQIP — Low Quality Image Placeholder — bu mekanizmanın teknik adıdır. Blur efekti isteğe bağlı bir stil kararıdır; LQIP ise altta yatan pratiği tanımlar: asıl görselin hafif, küçük bir kopyasını önceden yüklemek. Bu iki kavram çoğu zaman birlikte anılsa da farklı katmanlarda çalışır. LQIP veriyi tanımlar, blur efekti bu verinin ekranda nasıl göründüğünü belirler. Birleştiklerinde görsel yükleme süreci kullanıcı için çok daha az sarsıcı hale gelir.
Placeholder olmadan sahne nasıl görünür?
Tarayıcı bir <img> etiketiyle karşılaştığında önce HTML ayrıştırmaya devam eder, ardından görsel dosyasını ayrı bir istekle indirir. Bu iki adım arasında genellikle bir gecikme vardır — görsel boyutu HTML'de belirtilmişse alan rezerve edilir ama içi boş kalır; belirtilmemişse görsel geldiğinde sayfa yerinden kayar. Bu kayma Cumulative Layout Shift olarak ölçülür ve hem kullanıcı deneyimini hem Core Web Vitals puanını olumsuz etkiler.
Yüksek hızlı bir bağlantıda bu pencere o kadar kısa olur ki kullanıcı fark etmez. Ama mobil ağlarda veya 400-500 KB'lik büyük dosyalarda bu süre 1-3 saniyeye uzayabilir. Özellikle sayfanın ilk ekranında, yani kullanıcının scroll yapmadan gördüğü alanda, bu boşluk sayfanın henüz yüklenmediği izlenimini kuvvetlendirir.
Placeholder bu aradaki süreci kapatır. Asıl görsel gelmeden önce alanda bir şey bulunur; içerik varmış hissi yerleşir. Bu fark tek başına hız değil algı meselesidir — tarayıcı aynı hızda çalışır, yalnızca kullanıcının gözlemlediği boş süre dolmuş olur.
LQIP teknik olarak nasıl çalışır?
LQIP'in temeli basittir: asıl görselin çok küçük bir kopyasını üret, bu küçük versiyonu sayfaya göm, asıl görsel yüklenince değiştir.
Küçük versiyon genellikle 20-40 piksel genişliğinde bir dosyadır. Bu boyutta JPEG sıkıştırmasıyla dosya boyutu 1-4 KB aralığına iner. Base64 ile encode edildiğinde doğrudan HTML veya CSS içine yazılabilir; ayrı bir HTTP isteği gerekmez. Söz konusu string şöyle görünür:
data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAA...
Bu string <img> etiketinin src niteliğine ya da bir wrapper elemanın CSS background-image değerine yerleştirilir. Sayfa HTML ile birlikte tarayıcıya ulaştığında bu küçük görsel hemen çizilir; sunucudan ayrıca bir istek gitmez. Üzerine CSS filter: blur() uygulandığında bulanıklık, küçük dosyanın piksel kırılmasını da gizler — bu yüzden 20 piksel genişliğinde bir versiyon yeterlidir, 100 piksel kullanmak anlamsızdır.
Asıl görsel arka planda indirilirken JavaScript bir class değişimi ya da src takası yapar. CSS transition ile bu geçiş yumuşatılır; kullanıcı blur'dan netliğe doğru kademeli bir değişim görür. Geçiş genellikle 200-400 ms sürer ve göz bunu doğal bir yükleme hareketi olarak algılar.
Tek dezavantaj üretim adımıdır: her görsel için küçük bir LQIP versiyonu oluşturmak ve bunu base64'e çevirmek gerekir. Bir build pipeline olmadan bu işi elle yapmak hızla ölçeklenemez hale gelir. Bunun için Sharp gibi Node.js kütüphaneleri yaygın olarak kullanılır; birkaç satır kodla görsel küçültülür ve base64 çıktısı HTML şablonuna yazılır.
BlurHash ve Thumbhash: hash tabanlı alternatif
LQIP'in küçük dosya versiyonuna alternatif olarak hash algoritmaları kullanılır. Bu yaklaşımda küçük bir görsel dosyası yerine görselin renk ve ton bilgisini kodlayan kısa bir string üretilir.
BlurHash, 2019'da Wolt tarafından geliştirilen açık kaynaklı bir algoritmadır. Bir görselden 20-30 karakterlik bir hash üretir. Bu hash, client tarafında Canvas veya WebGL ile renk alanına dönüştürülür. Sonuç gerçek görsele benzeyen değil ama renk atmosferini yakalayan yumuşak bir alan olur. Benzer bir yaklaşım olan Thumbhash ise alpha kanalını (şeffaflık) destekler ve görsel içeriğine genellikle biraz daha yakın sonuçlar üretir.
Her iki algoritmanın da ana avantajı depolama maliyetinin neredeyse sıfır olmasıdır. Bir hash string 30-50 karakter yer kaplar; yüzlerce görselin LQIP base64 verisiyle HTML'i şişirmesi yerine kısa hash'ler saklanır. Bu fark özellikle içerik yönetim sistemlerinde ve veritabanı tabanlı yapılarda belirginleşir.
Dezavantajı ise client tarafında işlem gerektirmesidir. Küçük bir JS kütüphanesi yüklenmeli, hash decode edilmeli ve canvas'a çizilmelidir. Düşük belirli eski cihazlarda bu adım algılanabilir bir gecikme yaratabilir. Base64 LQIP ise herhangi bir decode aşaması gerektirmez — HTML yüklenince görsel doğrudan çizilir. Tek bir görselin placeholder'ı için inline base64 daha az karmaşık bir seçimdir; yüzlerce görselin olduğu galeri sayfalarında hash yaklaşımı veri boyutunu ciddi ölçüde küçültür.
Framework desteği: next/image ve otomatik üretim
Next.js Image bileşeni, placeholder="blur" prop'u sayesinde bu mekanizmayı büyük ölçüde otomatikleştirir. Local görsel dosyaları için next/image, build sürecinde küçük bir LQIP versiyonu üretir ve bunu base64 olarak bileşene gömer. Geliştiricinin ayrıca bir araç çalıştırmasına ya da base64 string yazmasına gerek kalmaz:
<Image src="/img/hero.webp" alt="Örnek" width={1200} height={630} placeholder="blur" />
Bu kadar. Build anında next/image görseli 8-10 piksel genişliğine küçültür, base64'e çevirir ve bileşenin iç yapısına yerleştirir. Sayfa render edildiğinde bu küçük versiyon anında görünür; asıl görsel yüklenince geçiş CSS transition ile yumuşatılır.
Uzak kaynaklı görseller için durum farklıdır: next/image build anında uzak URL'leri işleyemez. Bu durumda blurDataURL prop'u elle girilmelidir. BlurHash veya benzeri bir araçla görselden üretilen base64 string bu prop'a yazılır. Büyük içerik sitelerinde bu işlem çoğunlukla CMS tarafında halledilir; görsel yüklendiğinde CMS otomatik olarak LQIP versiyonu üretip veritabanına kaydeder.
Gatsby'de benzer mekanizma gatsby-plugin-image içinde gelir. GatsbyImage bileşeni placeholder prop'uyla blurred, dominantColor ya da none seçenekleri sunar. Dominant color yaklaşımında LQIP üretilmez; bunun yerine görselin baskın rengi düz bir arka plan olarak kullanılır. Bu daha az bilgi taşır ama işlem maliyeti de sıfıra yakındır.
Framework kullanmayan projelerde bu adım manuel pipeline ile karşılanır. Sharp, ImageMagick veya benzeri araçlarla her görsel için LQIP versiyonu üretilir, base64'e çevrilir ve HTML şablonuna enjekte edilir. Küçük bir projeye uygulamak kolaydır; büyük bir içerik sitesinde ise bu adımın CI/CD sürecine entegre edilmesi gerekir.
Ne zaman değer katar, ne zaman karmaşıklığa değmez?
Hero görseli gibi ilk ekranda beliren, büyük boyutlu içerikler LQIP'in en çok değer kattığı alanlardır. Kullanıcının ilk gördüğü bölge yükleme tamamlanana kadar boş kalmak yerine içeriğin renk ve kompozisyon bilgisini önceden sunar. Bu hem algısal performansı iyileştirir hem de kullanıcının sayfayı terk etme olasılığını azaltır.
Lazy loading kullanan galeri ve liste sayfalarında da LQIP belirgin bir fark yaratabilir. Kullanıcı aşağı kaydırırken görsel alanına yaklaştığında önce blur placeholder gösterilir; görsel indirilip çözümlendikçe netleşir. Bu deneyim görsel ağırlıklı sayfalarda — portfolio siteleri, haber akışları, ürün listeleri — yüklemeyi doğal bir hareket gibi gösterir.
Öte yandan her görsele LQIP uygulamak çoğu durumda gereksiz karmaşıklıktır. 32x32 piksel bir ikon için bulanık bir ön görsel anlamsız kalır; thumbnail boyutundaki bir kart görseli de çoğu zaman bu mekanizmadan anlamlı biçimde yararlanamaz. LQIP'in avantajı görsel yüklenmesinin kullanıcı tarafından fark edilebilir bir gecikme oluşturduğu durumlarda ortaya çıkar. Hızlı bir ağda 100 ms içinde gelen küçük bir görsel için placeholder mekanizması neredeyse gösterilmeden geçilir; yavaş bağlantıda ise 1-2 saniye boyunca ekranda kalır ve değeri net biçimde hissedilir.
Bu yüzden LQIP kararını dosya boyutu ve sayfa konumuyla birlikte değerlendirmek gerekir: büyük boyut, ilk ekran, yavaş ağ ihtimali — bu üçü bir araya geldiğinde placeholder kullanımı kolayca savunulur. Bunların dışında kalan durumlarda zaman ve bakım maliyeti çoğu zaman kazanımın önüne geçer.
Blur placeholder ve LQIP, görsel yükleme sürecinin kullanıcı tarafında nasıl deneyimlendiğini yönetir. Teknik olarak görsel ne kadar hızlı gelirse gelsin, yükleme tamamlanmadan önce ekranda bir şeylerin görünmesi sayfanın daha canlı ve hazır hissettirmesini sağlar. Bu fark analitiklere hemen yansımasa da kullanıcının içeriğe olan güvenini ve sayfada kalma süresini etkiler.
Pratik karar net bir çerçeveye oturur: ilk ekranda görünen, yüklenmesi fark edilebilir büyük görseller için bu tekniği değerlendirmek anlamlıdır; geri kalanlar için ek karmaşıklığa girmek çoğunlukla gerekmez. Next.js veya Gatsby gibi bir framework kullanıyorsanız bu mekanizma zaten hazır — tek bir prop ile devreye girer. Vanilla projelerinizde ise görsel pipeline'ınıza bir LQIP adımı eklemek, özellikle içeriğin ağır olduğu sayfalar için gözle görülür bir iyileşme sağlar. LQIP üretiminde görseli base64 dizisine dönüştürmek gerektiğinde base64 encoder bu dönüşümü hızlı yapar.