Temel kural
Ayrı bir isteğin maliyeti fazladan baytların maliyetinden büyükse görseli göm. Günümüzün HTTP/2 ve HTTP/3 bağlantılarında ek istekler ucuzdur, bu yüzden o nokta erken gelir: görsel başına 2 ile 4 KB iyi bir çalışma sınırıdır. Yaygın build araçları da aynı fikirde; Vite varsayılan olarak 4 KB altındaki dosyaları, webpack'in asset modülleri de 8 KB altındakileri gömer.
Aşağıdaki araç PNG'yi (ya da herhangi bir görseli) data URI'ye çevirir. Görseli bırak ya da aç, sonra Kopyalama biçimi'nden birini seç: Data URI, düz Base64, hazır bir CSS background-image satırı, genişlik ve yükseklikli bir HTML img etiketi ya da Markdown. Araç data URI boyutunu ve dosyadan ne kadar büyük olduğunu gösterir, sonuç sayfayı yavaşlatacak kadar büyükse uyarır. Görseller tarayıcında çevrilir, hiçbir yere yüklenmez.
Burada dene: PNG'den Base64'e
Aracın tam sayfasını açGörseli gömünce ne olur
data:image/png;base64,iVBORw0KGgo... gibi bir data URI, görselin baytlarını ona başvuran HTML, CSS ya da JSON'un içine koyar. Tarayıcı görseli o dosyayla birlikte alır, ayrı bir indirme olmaz. Bütün fayda budur. Maliyetler de aynı gerçekten doğar:
- Boyut: Base64 3 baytı 4 karakterle yazar, görsel yaklaşık üçte bir büyür. Sunucudaki gzip ya da Brotli sıkıştırması aktarımda bunun bir kısmını geri kazanır ama tamamını değil; zaten sıkıştırılmış görsellerde (PNG, JPG, WebP) kazanç azdır.
- Önbellek: ayrı bir görsel dosyası bir kez önbelleğe alınır ve her sayfada yeniden kullanılır. Gömülü görsel ise sadece içinde durduğu dosyanın parçası olarak önbelleğe girer. CSS'te tek satır değiştir, gömülü bütün ikonlar yeniden iner.
- Görüntülemeyi bekletme: CSS ilk boyamayı bekletir. Stil dosyasına gömülen her kilobayt görsel, o görseller sayfanın çok aşağısında olsa bile ekranda bir şey görünmesini geciktirir.
- Tembel yükleme yok: loading="lazy" ve srcset ile cihaza göre görsel seçmenin anlamı kalmaz, çünkü baytlar sayfayla birlikte zaten gelmiştir.
- Bakım: uzun bir Base64 metni kod incelemesinde okunmaz ve hatalı bir kopyalamayla kolayca bozulur.
Boyut rehberi: gömmeli mi, ayrı dosya mı?
| Görsel | Tipik dosya boyutu | Base64 olarak | Öneri |
|---|---|---|---|
| 16 ile 24 px arayüz ikonu (PNG ya da SVG) | 200 bayt ile 1 KB | yaklaşık 0,3 ile 1,4 KB | Göm, ideal durum |
| Küçük logo ya da rozet | 2 ile 5 KB | yaklaşık 2,7 ile 6,7 KB | Tek sayfada ya da e-posta imzasında kullanılıyorsa göm, yoksa dosya |
| Fotoğraf için bulanık yer tutucu | 300 bayt ile 1 KB | yaklaşık 0,4 ile 1,4 KB | Göm, gerçek fotoğrafı dosya olarak yükle |
| Her sayfada kullanılan logo | 10 ile 30 KB | yaklaşık 13 ile 40 KB | Ayrı dosya, bir kez önbelleğe alınsın |
| Ürün fotoğrafı ya da büyük kapak görseli | 50 ile 500 KB | yaklaşık 67 ile 670 KB | Tembel yüklemeli ya da preload'lu ayrı dosya |
Base64 görselin işe yaradığı yerler
- CSS'teki küçük ikonlar: oklar, onay işaretleri, özel bir onay kutusu ya da açılır listedeki ok gibi, stillerle birlikte görünmesi ve sonradan belirmemesi gereken parçalar.
- Tek dosyalık çıktılar: diskten açıldığında ya da tek ek olarak gönderildiğinde çalışması gereken bir HTML rapor, dışa aktarılmış bir fatura, bir doküman sayfası ya da prototip.
- API'ler ve veritabanları: JSON'da ikili veri türü yoktur; bu yüzden API istek ve yanıtlarındaki görseller (imzalar, profil fotoğrafları, taranmış belgeler, bazı pazaryeri entegrasyonlarındaki ürün görselleri) çoğu zaman Base64 metni olarak gönderilir.
- Düşük kaliteli yer tutucular: HTML'e gömülen minik bulanık bir sürüm, asıl görsel yüklenirken anında görünür.
- SVG ikonlar: SVG zaten metindir, çoğu zaman Base64'e hiç gerek yoktur. Araçtaki Base64 yerine URL kodlama seçeneği SVG'yi okunur tutar ve genelde daha kısa sonuç verir.
Ne zaman kaçınmalı
- Fotoğraflar ve web sayfasında kabaca 10 KB'ı geçen her görsel. WebP ya da AVIF biçiminde normal bir dosya kullan; genişlik ve yükseklik ver, ilk ekranın altındakileri tembel yükle.
- Sayfanın en üstündeki en büyük görsel (LCP öğesi). Büyük bir gömülü görsel HTML'in kendisini ağırlaştırır ve içindeki her şeyi geciktirir; ayrı bir dosyayı preload etmek genelde daha hızlıdır.
- Sayfalar arasında tekrar eden görseller, örneğin site logosu ya da arka plan deseni. Burada önbellek, bir istek kazanmaktan daha değerlidir.
- Geniş kitleye giden HTML e-postalar. Birçok e-posta istemcisi data URI görselleri göstermez; en bilinenleri Gmail ve Windows için Outlook. Bunun yerine sunucuda barındırılan görseller ya da içerik kimliğiyle (CID) başvurulan ekler kullan. Gömülü data URI'ler çoğunlukla Apple Mail'de ve bazı mobil uygulamalarda çalışır; bülten için bu yeterli değil.
- Genel olarak çok büyük data URI'ler. Eski Internet Explorer 8 bunları 32 KB ile sınırlıyordu; güncel tarayıcılar çok daha büyüklerini kabul eder ama performans herhangi bir sınıra gelmeden çok önce bozulur.
Doğru yapmanın yolu
Görseli çevirmeden önce küçült. Kazandığın her bayt data URI'de 4/3 ile çarpılır; PNG ikonları sıkıştır, gösterildiği boyuttan büyük görselleri yeniden boyutlandır, JSON verisi gibi gömmek zorunda olduğun fotoğraflarda makul kalitede JPG ya da WebP kullan. Bu sitedeki görsel sıkıştırıcı ve boyutlandırıcı bunu tarayıcıda yapar, küçülen dosyayı buraya geri getirebilirsin.
Boyutları ekle. Genişliği ve yüksekliği olmayan bir img etiketi, görsel göründüğünde sayfanın zıplamasına yol açar. Bu aracın HTML çıktısı bu yüzden görselin gerçek genişlik ve yüksekliğini içerir.
Kaynak dosyayı sakla. Asıl PNG ya da SVG'yi projende tut, data URI'yi ondan üret; ister build aracınla, ister bir şey değiştiğinde bu araçla. Base64 metnini asla ana kopya sayma.
Ölç. Sayfayı gömülü görsellerle ve onlarsız, tarayıcının Ağ (Network) panelinde ya da Lighthouse ile karşılaştır. CSS ya da HTML dosyası belirgin büyüyor ama hiçbir şey hızlanmıyorsa ayrı dosyaya dön.