Proposta previewsrc traz pré-visualizações borradas de imagens na web

A proposta

Patrick Brosset propõe adicionar à plataforma web um novo atributo para o elemento <img>, chamado previewsrc, que tornaria nativo o padrão de pré-visualização borrada de imagens: uma versão pequena e desfocada aparece imediatamente e é substituída pela imagem final quando ela termina de carregar. O padrão já é amplamente usado, e muitos CDNs de imagem, frameworks e bibliotecas o suportam, mas hoje cada implementação precisa, por conta própria, buscar as duas imagens, exibir a pré-visualização, fazer a troca e limpar depois da transição.

Como se faz hoje

Não há forma padrão de fornecer uma pré-visualização de imagem; a solução depende do framework ou biblioteca. O Next.js pode gerar um placeholder borrado na importação da imagem, com a propriedade placeholder="blur". Bibliotecas como o blurhash codificam uma pré-visualização minúscula como uma string curta, decodificada em tempo de execução para exibir a prévia. Também é possível fazer implementações próprias, como gerar prévias em tempo de build e enviá-las como data URLs em imagens de fundo CSS. As abordagens diferem, mas todas precisam coordenar manualmente a prévia e a imagem final.

O que a proposta cobre

A proposta inicial se concentra apenas em carregar, exibir e substituir a imagem de prévia. Com previewsrc, o navegador:

• carregaria a prévia e a imagem final, sempre dando prioridade à final;
• exibiria a prévia;
• a substituiria pela imagem final quando ela estiver pronta.

Isso elimina a necessidade de escrever código para carregar a prévia, tratar casos em que ela falha ou não existe antes da imagem final, e fazer a troca manualmente.

Possíveis extensões futuras

A versão inicial não permite personalizar a transição entre prévia e imagem final (como um efeito de fade) nem oferece suporte nativo a formatos compactos como blurhash. Ambos são considerados melhorias opcionais que poderiam ser adicionadas no futuro, e o feedback dos desenvolvedores ajudaria a priorizá-las.

Perguntas comuns

Segunda requisição? Sim, se previewsrc apontar para outra URL, haverá uma requisição extra que pode consumir banda. Porém, o carregamento da imagem final nunca seria atrasado pela prévia, o carregamento seria "best effort", com prioridade menor para busca e decodificação da prévia - e o navegador poderia pular completamente prévias improváveis de serem úteis. Também seria possível continuar usando strings blurhash ou data URLs, evitando a segunda requisição.

Evita abuso? Não. Não há mecanismo de enforcement no proposta; ela depende da disciplina dos desenvolvedores, como nas técnicas atuais. Ainda assim, o navegador pular prévias inúteis ou em condições de recursos restritos é um avanço em relação às soluções de hoje.

E imagens progressivas? O JPEG progressivo pode ser preferível quando fidelidade importa mais que uma prévia instantânea e borrada, mas, em geral, placeholders borrados parecem favorecidos por darem indicação visual rápida, responsividade e estabilidade de layout - e nem todos os sites geram versões progressivas.

Imagens responsivas? Continuam funcionando como antes: um <img> dentro de <picture> pode usar previewsrc, e os algoritmos de <picture>, srcset e sizes seguem selecionando a imagem final.

Por que não background-image em CSS? A técnica comum de pintar a prévia como fundo do <img> tem desvantagens frente ao atributo: com previewsrc, ambas as URLs ficam associadas ao elemento, o atributo seria refletido como propriedade de HTMLImageElement, e o navegador cuidaria de tratamento de erros, dimensionamento, posicionamento, sincronização de atualizações e agendamento best-effort.

Conclusão

O autor enfatiza que o atributo não substitui a otimização adequada de imagens e não é um recurso de performance. Ele pede feedback, via issues no GitHub, sobre se a adição vale a pena, qual seria o escopo mínimo viável para adoção e se as extensões opcionais seriam requisitos antes do uso.