Imagem em branco. O que usar: Base64 vs imagem 1x1 JPEG


11

Estou construindo um site e quero fazer consultas HTTP o mínimo possível para uma melhor velocidade e SEO do site. A página que acabei de criar mostra imagens em rolagem (as imagens têm um atributo data-scr que é convertido em src quando o usuário rola para baixo na respectiva imagem).

Como todas as imagens têm o data-srcatributo em vez de src, o W3C me mostra erros.

Neste momento, encontrei duas opções para resolver este problema:

  1. O src inicial de todas as imagens é um URL de uma imagem 1x1 em branco
  2. O src inicial de todas as imagens para ser uma imagem em branco da base de dados 64

Quando estou usando um URL de uma imagem 1x1 em branco, (testado com tools.pingdom.com), ele mostra 1 solicitação HTTP. Quando estou usando uma imagem em branco do banco de dados64, ela mostra tantos pedidos quanto o número de imagens na página.

Qual deles é a maneira mais eficiente, para um site ter velocidade mais rápida e fazer menos solicitações HTTP? (suponha que o usuário esteja carregando a página da Web a uma velocidade de 14,4 kbps na Internet - a primeira velocidade da Internet).

Mas para SEO?

Existe alguma outra opção?


8
"Quando estou usando uma imagem em branco do banco de dados 64, ela mostra tantos pedidos quanto o número de imagens na página." - há algo um pouco errado aí? O objetivo de usar um URI de dados é que não há solicitação HTTP externa. (Somente user-agents que não entendem data-URIs pode disparar uma solicitação HTTP.)
MrWhite

Se a imagem em branco for maior que 1x1 px (acho que é), eu recomendaria uma imagem de fundo maior (10x10 px, 100x100 px) porque a renderização será mais rápida .
totymedli

3
Não usa nenhum? Você pode criar a tag img dinamicamente ao mesmo tempo em que converte data-src em src. Em vez de ter uma imagem em branco com um data-src, você pode armazenar a lista de imagens e gerar a tag quando necessário.
precisa saber é o seguinte

@Pharap que não funciona porque o navegador fará o download das imagens, mesmo que estejam ocultas.
usar o seguinte

Qualquer que você escolher para entregar o conteúdo, codificá-lo como png8 provavelmente será mais rápido que o JPEG.
Symcbean

Respostas:


12

A opção de imagem base64 deve ser usada onde você teria apenas um número muito pequeno de imagens e deseja eliminar a sobrecarga da rede ao buscar uma imagem no servidor. No entanto, pelo que você está indicando na pergunta, presumo que isso possa ser dimensionado para um grande número de imagens. Nesse caso, eu usaria uma única imagem transparente de 1 px x 1 px do servidor com uma vida útil longa do cache, pois ela será buscada no servidor uma vez armazenada em cache no navegador e em qualquer servidor proxy intermediário.

Como exemplo, esta imagem teria cerca de 95 bytes de tamanho ( https://commons.wikimedia.org/wiki/File:1x1.png ), para uma sequência de imagens codificadas em base64, você descobriria que o tamanho seria igual a esta imagem tamanho do arquivo, mas seria repetido para todas as imagens adicionadas.

Para 2-5 imagens, o tamanho e a velocidade seriam insignificantes e diminuiriam o tráfego do servidor, eliminando uma busca inteira, mas, além disso, o tamanho da página começaria a ficar muito grande, o que afetaria o tempo de carregamento e, por sua vez, a classificação do SEO.


6
Uma imagem base64 em branco poderia ter 55 bytes: data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=. Se o URL da imagem for um pouco maior (ex: exemplo.com/templates/template-name/files/1x1.png ), a imagem base64 será recomendada porque você não faz consultas HTTP e é menor em bytes do que o URL da imagem (repetido para cada imagem na página) + o tamanho da imagem externa.
NETCreator Hosting

@ NETCreatorHosting-WebDesign Obrigado pelo seu comentário. Comparei o tamanho do site ao usar uma imagem base64 e uma imagem externa, e o tamanho é menor ao usar uma imagem base64. Estou usando cerca de 40 imagens por página.
MM PP

Ou você pode fazer upload da imagem na raiz do site e usar um URL relativo, para que o site seja muito menor.
NETCreator Hosting

3
O gzip cuidará das repetições, portanto, ter 400 imagens codificadas na base 64 na sua página não custará mais largura de banda do que 400 URLs de imagens.
usar o seguinte comando

3
@Aron Se sua página tiver 25,6 MB de largura (400 URIs de dados com 82 bytes de comprimento e 64kB entre eles = 25.568.800 bytes), você terá problemas maiores com que se preocupar com 32,8 kB de imagens codificadas em base64.
usar o seguinte comando

5

Definitivamente, vá com o URI de dados, a menos que você precise de suporte para o IE <8. ( Suporte ao navegador ).

A incorporação de muitas imagens minúsculas diretamente no HTML pode exigir mais largura de banda do que vinculá-las diretamente, mas o aumento será atenuado pelo gzip ; a única diferença no tamanho da página será a diferença de comprimento entre um URI de dados de uma imagem em branco e um URL da imagem no servidor. Um GIF em branco pode ter até 43 bytes. Codificado na base 64, ou seja, 82 bytes. Não há como ter um desempenho pior do que uma solicitação HTTP> 500 bytes , uma resposta de tamanho semelhante e, então, nem estou levando em consideração o tamanho do pacote TCP e outras despesas gerais.

Aqui está a imagem GIF de 43 bytes codificada em Base 64:

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

Quanto ao SEO, consulte o código-fonte de um site do Google, por exemplo, o Google Notícias , e pesquise por data:image/gif,base64


Sua imagem é grande. Verifique o comentário acima para a versão de 55 bytes.
Joshua

1
Esta resposta no StackOverflow com testes relatados (maio de 2014) parece mostrar que a incorporação de grandes números (~ 1800) de imagens de 1px é consideravelmente mais lenta do que vincular repetidamente à mesma imagem externa. A imagem externa é solicitada uma vez e armazenada em cache, enquanto o navegador deve decodificar cada URI de dados separadamente como parte do processo de análise de HTML - esse parece ser o gargalo. Isso parece sugerir que os URIs de dados devem ser limitados a um pequeno número de imagens (pequenas).
precisa saber é o seguinte

@ Joshua Embora essa imagem seja exibida corretamente no meu navegador (Firefox), ela não pode ser aberta por outros programas (por exemplo, Paint), por isso evitaria usá-la.
precisa saber é o seguinte

2

Nesse momento, encontrei duas opções para solucionar esse problema: O src inicial de todas as imagens era uma imagem em branco da base de dados 64

Essa opção não requer apenas um navegador moderno, mas pode ser mais lenta no lado do cliente, pois o navegador deve decodificar com base 64 os dados da imagem para produzir a imagem.

O src inicial de todas as imagens é um URL de uma imagem 1x1 em branco

É uma mudança OK, desde que o URL da imagem em branco para todos os slots de imagem seja exatamente o mesmo URL e que tenha uma vida útil longa do cache definida no cabeçalho HTTP "controle de cache". O problema é que, à medida que os novos arquivos de imagem são carregados, os quadrados da imagem saltam para o novo tamanho, o que pode tornar a experiência do usuário não tão maravilhosa.

A idéia quase perfeita é essa ...

Quando a página for inicializada, apresente uma grade com caixas de tamanho fixo que podem acomodar cada imagem. Tudo bem se a grade inteira não couber na tela. Em seguida, crie o javascript que é executado após o carregamento do HTML e, nesse javascript, crie um novo elemento de imagem e anexe-o a cada célula da grade e defina a origem da imagem no arquivo de imagem correto. Faça isso até que a primeira tela seja exibida. Em seguida, detecte a rolagem no javascript e, quando ocorrer a rolagem, repita o processo acima para as novas células.

Agora, se você deseja o melhor dos melhores, e a qualidade não é uma grande preocupação, o que eu recomendo (que eu também implementei no meu site) é construir uma grade e configurá-la de forma que a imagem de plano de fundo dessa grade seja uma folha de sprite de todas as imagens formatadas como quadrados de imagens. Esse método é flexível e rápido de carregar, pois é necessária uma solicitação para todas as imagens.

Aqui está um modelo de HTML para usar se você quiser seguir o caminho mais rápido. Apenas duas solicitações são feitas. O código HTML e a imagem única. Neste código, presumo que cada imagem da planilha tenha 100 pixels de largura e 200 pixels de altura e que cada imagem esteja perfeitamente alinhada uma com a outra, sem espaços.

<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>

No meu código eu adicionei 3 pontos. Isso significa que você pode continuar adicionando imagens aumentando os números e aumentando a posição em 100 a cada vez, desde que sua planilha de sprites tenha apenas uma linha de imagens. Além disso, em alguns navegadores como o Opera, pode ser necessário adicionar um sinal negativo na frente dos valores da posição de segundo plano para que eles funcionem.


2
A menos que suas imagens tenham meio gigabyte de tamanho, não há como descodificar uma imagem com base64 ter um impacto mensurável no desempenho.
usar o seguinte comando

Também depende do sistema do computador. Se o cliente ainda tiver um computador antiquado, como um pentium 1, poderá ocorrer um impacto no desempenho.
Mike

1

A imagem, porque manutenção.

Na minha experiência , funciona melhor usar a imagem. Isso é mais óbvio no código real e mais fácil de lembrar. Duvido que você se lembre da seqüência codificada de uma imagem transparente e, mesmo que você lembre, de seus sucessores / colégios.
Se você voltar a esse código após algumas semanas, terá perdoado a base64.

Será muito mais fácil manter o código, se você usar a imagem, os profissionais mínimos não pesam até isso.


Muitas pessoas usam scripts para gerar valores de base 64, portanto, o requisito para lembrar esses valores fica fora da janela, a menos que o OP use apenas um conjunto de arquivos HTML para representar o código de seu site.
Mike

1

Que tal apenas ~ 3 bytes extras, 0 solicitações HTTP extras e 0 comprimento extra de img src (ou 0 espaços reservados para imagem de dados não armazenados em cache). Você pode usar um src em branco para imagem?

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

E se eles tiverem alttags, você poderá ocultá-las da imagem de erro / falha:

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

Exibe: nada. Hackear a tag alt tem um leve atraso FOUC da borda do espaço reservado da imagem. Talvez isso possa ser limpo também.


2
Embora um srcatributo vazio ainda gere erros no Validador W3C (o que parece ser a preocupação).
precisa saber é o seguinte

@ w3dk Sim, isso é péssimo, mas novamente muito poucas modernizações passam.
precisa saber é o seguinte

Se você deseja passar as regras do W3C, é necessário especificar algo para o src, mesmo que seja um URL que retorne um erro 404. Também recomendo especificar os valores dos atributos de largura e altura da imagem, para que os usuários vejam os espaços reservados reais primeiro, em vez de pequenas caixas que são infladas no meio do processo de carregamento.
Mike
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.