Boş resim. Ne kullanılır: Base64 vs 1x1 JPEG görüntüsü


12

Bir web sitesi inşa ediyorum ve daha iyi bir web sitesi hızı ve seo için mümkün olduğunca az HTTP sorgusu yapmak istiyorum. Yeni oluşturduğum sayfa kaydırmada görüntüleri gösteriyor (görüntüler, kullanıcı ilgili görüntüde aşağı kaydırdığında src'ye dönüştürülen bir öznitelik veri scr değerine sahip).

Tüm resimler data-srcyerine niteliğe sahip olduğundan src, W3C bana hatalar gösteriyor.

Şu anda bu sorunu çözmek için iki seçenek buldum:

  1. Tüm görüntülerin ilk src'si boş bir 1x1 görüntünün url'si olur
  2. Tüm görüntülerin ilk src'si veri tabanı 64 boş resim olmalıdır

Boş bir 1x1 resmin URL'sini kullandığımda (tools.pingdom.com ile test edildi) 1 HTTP isteği gösterir. Bir veri base64 boş görüntü kullanırken, sayfadaki görüntü sayısı kadar istek gösterir.

Bir web sitesi için hangisi daha verimli ve daha az HTTP isteği yapıyor? (diyelim ki kullanıcı web sayfasını 14,4 kb / sn'lik bir İnternet hızında yükledi - ilk İnternet hızı).

Ama SEO için mi?

Başka seçenek var mı?


8
"Bir veri tabanı 64 boş görüntü kullanırken, sayfadaki görüntü sayısı kadar istek gösterir." - orada biraz yanlış bir şey mi var? Bir veri URI'sı kullanmanın asıl amacı, harici HTTP isteğinin olmamasıdır. (Yalnızca veri URI'lerini anlamayan kullanıcı aracıları bir HTTP isteğini
tetikleyebilir

Boş resim 1x1 pikselden daha büyükse (sanırım), oluşturma daha hızlı olacağından daha büyük bir arka plan görüntüsü (10x10 piksel, 100x100 piksel) öneririm .
totymedli

3
Hiçbirini kullanmıyor musunuz? Data-src dosyasını src'ye dönüştürürken img etiketini dinamik olarak oluşturabilirsiniz. Data-src ile boş bir görüntüye sahip olmak yerine, görüntü listesini depolayabilir ve gerektiğinde etiketi oluşturabilirsiniz.
the_lotus

@Pharap çalışmıyor çünkü tarayıcı gizli olsalar bile görüntüleri indirecek.
DisgruntledGoat

İçeriği iletmek için hangisini seçerseniz seçin, onu bir png8 olarak kodlamak muhtemelen JPEG'den daha hızlı olacaktır.
symcbean

Yanıtlar:


12

Base64 image seçeneği, çok az sayıda görüntünüzün olduğu ve sunucudan bir resim getirmenin ağ yükünü ortadan kaldırmak istediğiniz yerde kullanılmalıdır. Ancak soruda belirttiğinizden, bunun çok sayıda görüntüye ölçeklenebileceğini varsayıyorum. Bu durumda, sunucudan tek bir 1px x 1px şeffaf görüntü, bir kez tarayıcıdan ve ara proxy sunucularından önbelleğe alındıktan sonra sunucudan alınacağı için uzun bir önbellek ömrüne sahip olurdum.

Örnek olarak, bu görüntü yaklaşık 95 bayt boyutundadır ( https://commons.wikimedia.org/wiki/File:1x1.png ), base64 kodlu bir resim dizesi için boyutun bu resimle aynı olacağını görürsünüz. ekleyin ancak eklediğiniz her resim için tekrarlanır.

2-5 görüntü için boyut ve hız ihmal edilebilir ve bir bütün getirmeyi ortadan kaldırarak sunucu trafiğini azaltacaktır, ancak daha fazla sayfa boyutu yükleme sürelerini ve sırayla SEO sıralamasını etkileyecek kadar büyük olmaya başlayacaktır.


6
Boş base64 görüntü 55 bayt olabilir: data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=. Görüntünün URL'si biraz daha uzunsa ( örnek : örnek.com/ templates/template-name/files/ 1x1.png ), HTTP sorguları yapmadığınız ve bayt cinsinden daha küçük olduğu için base64 resmi önerilir. resim URL'sinden (sayfadaki her resim için tekrarlanır) + harici resim boyutu.
NETCreator Hosting

@ NETCreatorHosting-WebDesign Yorumunuz için teşekkür ederiz. Bir base64 resmi ve harici bir görüntü kullanırken web sitesi boyutunu karşılaştırdım ve base64 resmi kullanırken boyut daha küçük. Sayfa başına yaklaşık 40 resim kullanıyorum.
MM PP

Ya da resmi web sitenizin kök dizinine yükleyebilir ve göreli bir URL kullanabilirsiniz, böylece web sitesi çok daha küçük olur.
NETCreator Hosting

3
gzip tekrarlarla ilgilenir, bu nedenle sayfanızda 400 temel 64 kodlu resme sahip olmak, 400 URL resimden daha fazla bant genişliğine mal olmaz.
user2428118

3
@Aron Sayfanız 25,6 MB büyükse (aralarında 64kB olan 400 82 bayt uzunluğunda veri URI'leri = 25,568,800 bayt), 32,8 kB'den fazla base64 kodlu görüntüyle ilgili endişelenmeniz gereken büyük sorunlar var.
user2428118

5

IE <8 desteğine ihtiyacınız olmadığı sürece kesinlikle veri URI'sine gidin. ( Tarayıcı desteği .)

Çok sayıda küçük görüntüyü doğrudan HTML'ye gömmek, doğrudan bağlantı oluşturmaktan daha fazla bant genişliği alacak gibi görünebilir, ancak artış gzip tarafından hafifletilecektir ; sayfanın boyutundaki tek fark, boş bir görüntünün bir veri URI'si ile sunucunuzdaki görüntünün bir URL'si arasındaki uzunluk farkından kaynaklanır . Bir boş GIF 43 byte kadar küçük olabilir. Temel 64 kodlu, bu 82 bayt. 500 baytlık bir HTTP isteğinden , benzer boyutta bir yanıttan daha kötü performans göstermenin hiçbir yolu yoktur ve daha sonra TCP paket boyutunu ve diğer ek yükü bile dikkate almıyorum.

İşte Temel 64 kodlu 43 bayt GIF görüntüsü:

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

SEO'ya gelince, bir Google sitesinin kaynak koduna bir göz atın, örneğin Google Haberler ve data:image/gif,base64...


Resminiz büyük. 55 baytlık sürüm için yukarıdaki açıklamaya bakın.
Joshua

1
Bildirilen testlerle (Mayıs 2014) StackOverflow'daki bu yanıt, 1px görüntülerin çok sayıda (~ 1800) gömülmesinin, aynı harici görüntüye tekrar tekrar bağlanmasından çok daha yavaş olduğunu gösteriyor . Harici görüntü bir kez istenir ve önbelleğe alınır, ancak tarayıcı HTML veri ayrıştırma işleminin bir parçası olarak her veri URI'sını ayrı olarak çözmelidir - bu darboğaz gibi görünecektir. Bu, veri URI'lerinin az sayıda (küçük) görüntü ile sınırlı olması gerektiğini düşündürmektedir.
DocRoot

@Joshua Bu resim tarayıcımda (Firefox) doğru bir şekilde görüntülenmesine rağmen, diğer bazı programlar (örneğin Paint) tarafından açılamıyor, bu yüzden kullanmaktan kaçınırım.
user2428118

2

Şu anda bu sorunu çözmek için iki seçenek buldum: Tüm resimlerin ilk src'si veri tabanı 64 boş resim olacak

Bu seçenek sadece modern bir tarayıcı gerektirmez, aynı zamanda istemci tarafında daha yavaş olabilir, çünkü tarayıcının görüntüyü üretmek için görüntü verilerini temel alması gerekir.

Tüm görüntülerin ilk src'si boş bir 1x1 görüntünün url'si olur

Tüm resim alanları için boş resim URL'sinin tam olarak aynı URL olması ve HTTP üstbilgisi "cache-control" içinde tanımlanmış uzun bir önbellek ömrüne sahip olması şartıyla, bu bir TAMAM hareketidir. Buradaki sorun, yeni görüntü dosyaları yüklendikçe, görüntü karelerinin yeni boyuta atlayacağı ve bu da kullanıcı deneyimini harika değil.

Neredeyse mükemmel fikir şudur ...

Sayfa başladığında, her görüntüyü barındırabilecek sabit boyutlu kutular içeren bir ızgara sunun. Tüm ızgara ekrana sığmıyorsa sorun değil. Ardından, HTML yüklendikten sonra yürütülen javascript'i oluşturun ve bu javascriptte yeni bir görüntü öğesi oluşturun ve bunu kılavuzun her hücresine ekleyin ve ardından görüntünün kaynağını doğru görüntü dosyasına ayarlayın. İlk ekran dolana kadar bunu yapın. daha sonra javascript içinde kaydırmayı tespit edin ve sonra kaydırma gerçekleştiğinde, yeni hücreler için yukarıdaki işlemi tekrarlayın.

Şimdi en iyinin en iyisini istiyorsanız ve kalite büyük bir endişe değilse, o zaman önerdiğim (siteme de uyguladığım) bir ızgara oluşturmak ve bu ızgaranın arka plan görüntüsü bir görüntülerin kareleri olarak biçimlendirilmiş tüm görüntülerin sprite sayfası. Tüm görüntüler için bir istek gerektiğinden bu yöntem esnek ve hızlıdır.

Hızlı rotaya gitmek istiyorsanız kullanabileceğiniz bir şablon HTML'si. Sadece iki istek yapılır. HTML kodu ve tek resim. Bu kodda, sayfadaki her görüntünün 100 piksel genişliğinde ve 200 piksel yüksekliğinde olduğunu ve her görüntünün boşluk olmadan mükemmel bir şekilde hizalandığını varsayıyorum.

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

Koduma 3 nokta ekledim. Bu, sayıları arttırarak ve hareketli grafik sayfanızda yalnızca bir satır görüntü olması koşuluyla konumu her seferinde 100 oranında artırarak görüntü eklemeye devam edebileceğiniz anlamına gelir. Ayrıca, Opera gibi bazı tarayıcılarda, çalışması için arka plan konumu değerlerinin önüne negatif bir işaret eklemeniz gerekebilir.


2
Resimleriniz yarım gigabayt boyutunda değilse, bir görüntünün base64 kodunun çözülmesinin performans üzerinde ölçülebilir bir etkisi olmayacak bir yol yoktur.
user2428118

Ayrıca bilgisayar sistemine de bağlıdır. İstemcinin hala pentium 1 gibi eski moda bir bilgisayarı varsa, bir performans isabeti olabilir.
Mike

1

Görüntü, çünkü sürdürülebilirlik.

Benim içinde deneyim o resim kullanmak daha iyi çalışır. Bu gerçek kodda daha belirgindir ve hatırlanması daha kolaydır. Şüphesiz, saydam bir görüntü için kodlanmış dizeyi hatırlarsınız ve bunu yapsanız bile, başarılarınız / meslektaşlarınız.
Birkaç hafta sonra bu koda geri dönerseniz, base64'ü unuttunuz.

Görüntüyü kullanırsanız kodu korumak çok daha basit olacaktır, minimal pro'lar buna ağırlık vermez.


Birçok kişi temel 64 değerleri oluşturmak için komut dosyaları kullanır, bu nedenle OP, web sitesinin kodunu temsil etmek için yalnızca bir dizi HTML dosyası kullanmazsa, bu değerleri hatırlama gereksinimi pencereden dışarı çıkar.
Mike

1

Sadece ~ 3 ekstra bayt, 0 ekstra http isteği ve 0 ekstra img src uzunluğu (veya 0 önbelleğe alınmamış veri görüntü yer tutucusu) hakkında. Resim için boş bir src kullanabilir misiniz?

<img src data-src="banannanannas.jpg" />

Onlar varsa altetiketler yanlışlıkla gelenler gizleyebilir / resmi başarısız:

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

Görüntüler: hiçbir şey. Alt etiketi kesmek, resim yer tutucu sınırından hafif bir FOUC gecikmesine sahiptir. Belki de temizlenebilir.


2
Her ne kadar boş bir srcözellik W3C Validator'da hala hatalar atsa da (endişe gibi görünüyor).
MrWhite

@ w3dk Evet, bu berbat, ama yine de çok az modernizasyon geçiyor.
dhaupin

W3C kurallarını iletmek istiyorsanız, bir 404 hatası döndüren bir URL olsa bile, src için bir şey belirtilmelidir. Ayrıca, kullanıcıların yükleme işleminin yarısında şişen küçük kutular yerine gerçek yer tutucuları görmeleri için resmin genişlik ve yükseklik özelliklerinin değerlerini belirtmenizi de öneririm.
Mike
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.