HTML/CSS içinde Base64 olarak görsel gömmek: artıları ve eksileri

Web geliştirmede bir teknik var: <img src="logo.png"> ile bir görsel dosyasına bağlantı vermek yerine, görselin baytlarını doğrudan HTML veya CSS’in içine Base64 dizesi olarak gömüyorsunuz:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." />

Buna data URI deniyor. Sayfa yüklemesini hızlandırabilir ya da yavaşlatabilir. Boyutu küçültebilir ya da büyütebilir. Yanlış kullanıldığında sizi şaşırtıcı miktarda sorunla karşılaştırabilir. Ne zaman dahiyane optimizasyon, ne zaman hata olduğuna bakalım.

Data URI gerçekte nedir

Data URI, başka bir yerdeki veriye işaret eden bir bağlantı değil, verinin kendisini içeren bir URL. Format:

data:<mime-type>;base64,<base64-encoded-data>

PNG görseli için:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

SVG için:

data:image/svg+xml;base64,PHN2ZyB4bWxucz0i...

Veya SVG’ye özel olarak, Base64’ü atlayıp URL-kodlanmış SVG metni kullanabilirsiniz:

data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg'>...</svg>

Tarayıcı URI’yi ayrıştırır, veriyi çözer ve görseli sanki bir dosyadan yüklenmiş gibi render eder.

Neden biri bunu yapsın ki

Klasik argüman: bir HTTP isteği tasarruf edersiniz.

Data URI olmadan tarayıcı image.png ister — 1 HTTP isteği, 1 gidiş-dönüş. Data URI ile görsel zaten HTML’in içinde, ekstra istek yok, HTML ayrıştırıldığı anda render edilir.

HTTP/2 öncesinde her istekte gözle görülür ek yük vardı. Elli küçük ikonu olan bir sayfada bu birikiyordu. Küçük görselleri data URI olarak gömmek sayfa renderını ölçülebilir şekilde hızlandırabiliyordu.

Ama dur —

Neden çoğu zaman iyi fikir değil

1. Gömüldükleri dosyayı şişirir

Base64, ham dosya boyutuna %33 ek yük ekler. 1 KB’lık ikonu gömmek HTML’inize yaklaşık 1,3 KB ekler. Tek ikon için sorun yok. Elli ikon için HTML payload’unuza 65 KB ekliyorsunuz — hiçbir şey render edilmeden önce indirilip ayrıştırılması gereken 65 KB.

2. Ayrı ayrı cache’lenemezler

Bir kez istenen logo.png tarayıcı tarafından cache’lenir, sitenin her sayfasında yeniden kullanılır. Base64 olarak kodlanmış logo ise göründüğü her HTML sayfasının parçası. İlk ziyarette hız farkı yok. Sonraki her sayfada boşa giden bant genişliği.

3. Paralel indirmeleri bloklarlar

Tarayıcılar harici kaynakları paralel indirir. Gömülü data URI’ler HTML’in parçası, yani ilk HTML indirmesiyle rekabet ediyorlar — ve onu geciktiriyorlar. HTML gömülü görseller yüzünden 500 KB’a çıktıysa sayfa daha uzun süre boş görünür.

4. Kod okunabilirliğini bozarlar

HTML veya CSS ortasındaki 200 karakterlik Base64 dizesi kod incelemesini ve debug’ı zorlaştırır. Pek çok geliştirici için bu, gerçekten küçük kaynaklar dışında bu yöntemden kaçınmak için yeterli neden.

5. HTTP/2 ve HTTP/3 orijinal faydayı büyük ölçüde ortadan kaldırıyor

Data URI için ana argüman — “ekstra HTTP isteklerinden kaçın” — HTTP/1.1’de güçlüydü. HTTP/2 birçok isteği tek bağlantıdan çoklayarak neredeyse sıfır ek yükle işliyor. Modern sunucularda yirmi ayrı görsel isteği bir istekten anlamlı ölçüde yavaş değil.

Data URI’nin gerçekten mantıklı olduğu durumlar

Çok küçük, çok sık kullanılan ikonlar

Sayfada defalarca kullanılan 100 baytlık bir CSS ikonu iyi bir aday. Ek yük çok küçük, anında render ediliyor ve tasarruf edilen HTTP isteği HTML şişmesinden daha değerli.

Her sayfada kullanılan CSS arka plan görselleri

CSS dosyaları uzun süre cache’lenir. CSS içindeki data URI CSS ile birlikte cache’lenir — “cache yok” itirazı burada o kadar güçlü değil. Küçük arka plan görselleri için data URI’ler ayrı dosyalardan daha temiz olabilir.

E-posta HTML’i

Pek çok e-posta istemcisi uzaktaki görselleri varsayılan olarak engeller. Görselleri data URI olarak gömmek, engellemeden bağımsız render sağlar. Ama dikkat — bazı e-posta istemcileri (Gmail, Outlook) data URI’leri de engelliyor. Kapsamlı test edin.

Offline-first web uygulamaları

Ağ bağlantısı olmadan çalışması gereken uygulamalar için data URI’ler, uygulama içindeki görsellerin her zaman görünmesini sağlar. Progressive Web Apps için gerçek bir kullanım alanı.

Çalışma zamanında üretilen görseller

Görseli JavaScript’te dinamik olarak üretiyorsanız — mesela <canvas> üzerine çizip sonucu göstermeniz gerekiyor — doğal çıktı zaten Base64 data URL’dir. Önce dosyaya kaydetmenize gerek yok.

Yazdırma stil sayfaları ve izole artifaktlar

Yazdırılacak, e-postayla gönderilecek veya tek dosya olarak kaydedilecek HTML’de ayrı dosyalar sorun yaratabilir. Data URI’ler burada temiz çözüm.

Data URI’nin kesinlikle yanlış seçim olduğu durumlar

Büyük görseller. Yaklaşık 10 KB üzerindeki her şey neredeyse her zaman ayrı dosya olarak daha iyi. HTML şişmesi çok yüksek, cache avantajı çok önemli.

Değişen görseller. Avatar, kapak fotoğrafı, ürün görseli — değişen her şey dosya olmalı, ihtiyaç duyuldukça cache’lenip güncellenebilmeli. Data URI görseli HTML’e kilitler.

SEO açısından önemli görseller. Arama motorları data URI’leri tarayabilir ama ayrı dosyalara göre daha az önem verir.

Birden fazla yerde kullanılan görseller. Aynı ikon on iki yerde görünüyorsa data URI kodlama maliyetini on iki kez ödersiniz. Düzgün bir dosya bir kez cache’lenir, defalarca kullanılır.

Pratik kural

HTTP/2 veya HTTP/3 üzerindeki çoğu modern site için:

Kaynak boyutu	Bir kez kullanılıyor	Birçok kez kullanılıyor
< 1 KB	Data URI uygun	Data URI uygun
1-5 KB	Data URI uygun	Ayrı dosya
5-10 KB	Sınırda	Ayrı dosya
> 10 KB	Ayrı dosya	Ayrı dosya

Emin değilseniz ölçün. Chrome Lighthouse ve WebPageTest gerçek etkiyi ölçer.

Pratik akış

Belirli bir görsel için data URI’nin mantıklı olduğuna karar verdiyseniz:

1. Önce görseli optimize edin. Sıkıştırıcıdan geçirin — 3 KB’a indirilmiş 10 KB’lık PNG, ham versiyondan çok daha iyi data URI olur. Image Compressor aracına bakın.

2. Base64’e çevirin. Dosyayı Base64 aracına bırakın. Base64 dizesini hemen alırsınız.

3. Data URI’yi oluşturun. Dizenin başına data:image/png;base64, (ya da eşleşen MIME type) ekleyin.

4. HTML veya CSS’e yapıştırın. HTML: <img src="data:...">. CSS: background: url(data:...).

5. Birden fazla tarayıcıda ve e-posta istemcisinde test edin. Modern tarayıcılarda destek evrensel, e-postada değişken.

SVG hakkında bir not

SVG özel durum. SVG görselleri metin tabanlı, yani HTML veya CSS’e Base64 yerine ham metin olarak gömülebilirler. Ham SVG genellikle Base64 ile kodlanmış SVG’den daha küçük — çünkü Base64 her zaman %33 ekliyor, ham SVG ise yalnızca özel karakterler için küçük escape gerektirir.

/* Base64 ile kodlanmış SVG (daha büyük) */
background: url('data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3...');

/* URL-encoded SVG metni (daha küçük, genelde %40+) */
background: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg">...');

SVG için Base64 yerine URL-encoded metni tercih edin.

SEO ve erişilebilirlik notu

• alt metni data URI’li <img> üzerinde normal çalışır — kullanın.
• Sağ tık → görseli kaydet çalışır ama dosya adı jenerik olur.
• Görsel tarama data URI’leri işler ama ayrı dosyalara öncelik verir.
• Content Security Policy (CSP) kuralları data: URI’ler için açık izin gerektirebilir.

Deneyin

Hemen bir görseli Base64’e çevirmek istiyorsanız — data URI’leri denemek, e-posta şablonuna yapıştırmak için — Base64 encoder’ımız halleder. Dosyayı bırakın, dizeyi kopyalayın, data URI’yi oluşturun. Her şey yerel çalışır; kurumsal logolar veya özel varlıklar cihazınızdan ayrılmaz.

Data URI hassas bir araç. Doğru yerde doğru kaynak için kullanıldığında bir istek tasarrufu sağlayıp sayfayı hızlandırır. Ayrım gözetmeden kullanıldığında HTML’inizi şişirir ve bant genişliği israf eder. “Bu gerçekten doğru seçim mi?” kararına harcanan otuz saniye kendini fazlasıyla öder.