Smashing Podcast Episódio 39 Com Addy Osmani: Otimização de Imagem

Este episódio foi gentilmente apoiado por nossos queridos amigos do Storyblok, que ajudam as pessoas a oferecer experiências de conteúdo poderosas em qualquer plataforma: sites corporativos, sites de comércio eletrônico, aplicativos móveis e telas. Obrigado!

No episódio de hoje do Smashing Podcast, vamos falar sobre otimização de imagem. Quais etapas devemos seguir para imagens de alto desempenho em 2021? Falei com o especialista Addy Osmani para descobrir.

Mostrar notas

• “Otimização de Imagem”, Addy Osmani
• Adiciona no Twitter
• Site pessoal de Addy

Atualização semanal

• Conheça :has, um seletor de pais CSS nativo (e mais)
  escrito por Adrian Bece
• Três ferramentas de auditoria front-end que descobri recentemente
  escrito por Stefan Judis
• Placas de caldeira e kits iniciais úteis
  escrito por Cosima Mielke
• Web Design Bem Feito: Usando Áudio
  escrito por Frederick O'Brien
• Quando CSS não é suficiente: requisitos de JavaScript para componentes acessíveis
  escrito por Stephanie Eckles

Transcrição

Drew McLellan: Ele é um gerente de engenharia que trabalha no Google Chrome, onde sua equipe se concentra na velocidade, ajudando a manter a web rápida. Dedicado à comunidade de código aberto, suas contribuições anteriores incluem Lighthouse, Workbox, Yeoman, Critical e to do NVC. Portanto, sabemos que ele sabe como otimizar o desempenho da web. Mas você sabia que ele quer ganhar o Oscar de melhor atriz em um papel coadjuvante devido a um erro clerical? Meus amigos, por favor, dêem as boas-vindas a Addy Osmani. Olá, Adi. Como você está?

Addy Osmani: Estou arrasando.

Drew McLellan: É bom ouvir isso. Eu queria falar com você hoje sobre imagens na web. É uma área onde houve uma quantidade surpreendente de mudanças e inovações nos últimos anos, e você acabou de escrever um livro muito abrangente sobre otimização de imagem para Smashing. Qual foi a motivação para pensar neste momento: “Agora é a hora de um livro sobre otimização de imagem?”

Addy Osmani: Essa é uma ótima pergunta. Acho que sabemos que as imagens têm sido uma parte muito importante da web há décadas e que nossos cérebros são capazes de interpretar imagens muito mais rápido do que texto. Mas esse tópico geral continua a ficar cada vez mais interessante e com mais nuances ao longo do tempo. E eu sempre digo às pessoas que este é provavelmente, eu acho, meu terceiro ou quarto livro. Eu nunca intencionalmente me propus a escrever um livro.

Addy Osmani: Comecei este livro escrevendo um artigo sobre otimização de imagens e, com o tempo, descobri que acidentalmente escrevi um livro inteiro sobre isso. Estávamos trabalhando neste projeto há cerca de dois anos. E mesmo nessa época, a indústria evoluiu os navegadores e as ferramentas em torno de imagens e formatos de imagem evoluíram.

Addy Osmani: E então escrevi este livro porque achei difícil ficar por dentro de todas essas mudanças. E pensei: “Vou ser um bom cidadão da web e tentar rastrear tudo o que aprendi em um só lugar para que todos possam tirar proveito disso”.

Drew McLellan: É uma daquelas áreas, eu acho, com muita otimização de desempenho no navegador, é um cenário que muda rapidamente, não é? Onde uma técnica que você aprendeu como sendo atual e sendo a melhor prática, alguma mudança de tecnologia acontece, e então você descobre que é realmente um antipadrão e você não deveria estar fazendo isso. E tentar manter seu conhecimento e ter certeza de que você está lendo os artigos certos e aprendendo as coisas certas e não está lendo algo de dois anos atrás é bastante difícil.

Drew McLellan: Então, ter tudo reunido em um livro bem pesquisado de uma fonte autorizada é realmente tremendo.

Addy Osmani: Sim. Mesmo da perspectiva de um autor, uma das coisas mais interessantes e talvez uma das mais estressantes para nossa equipe editorial era que eu entregava um capítulo e dizia que estava pronto. E então, duas semanas depois, algo mudava em um navegador, e eu dizia: “Ah, espere. Eu tenho que fazer outra mudança de última hora.”

Addy Osmani: Mas o panorama da imagem evoluiu bastante, mesmo no ano passado. Vimos o suporte WebP finalmente cruzar a linha de chegada na maioria dos navegadores modernos. O suporte a imagens AVIF está no Chrome, chegando ao Firefox, JPEG XL, carregamento lento. E em geral, vimos melhorias em como você pode usar imagens na web de forma bastante concreta em navegadores. Mas, novamente, muito para as pessoas se manterem no topo.

Drew McLellan: Algumas pessoas podem ver o assunto de otimização de imagem como um tópico bastante sério. Todos nós, em algum momento de nossas carreiras, aprendemos a exportar para a web a partir de nosso software gráfico. E alguns de nós que podem ter o hábito de pegar essas imagens exportadas e executá-las através de algo como ImageOptim.

Drew McLellan: Então, podemos saber que devemos escolher um JPEG quando for uma imagem fotográfica e um PNG quando for uma imagem baseada em gráficos e pensar que “Ok, é isso. Conheço otimização de imagem, terminei.” Mas realmente, essas coisas são apenas apostas de mesa, não são, neste momento?

Addy Osmani: Sim, eles são. Acho que nossa capacidade de exibir imagens e imagens mais detalhadas e nítidas, mesmo em um contexto diferente, dependendo se você se importa com a direção de arte ou não, evoluiu ao longo do tempo. Acho que a necessidade de descobrir como você pode fazer com que essas imagens pareçam tão bonitas quanto o esperado para seus usuários finais, tendo em mente seu ambiente, suas restrições de dispositivo, suas restrições de rede é um problema difícil e algo que conheço muitas pessoas ainda lutar com.

Addy Osmani: E então, quando se trata de pensar em imagens e obter uma visão um pouco mais refinada disso, além de apenas “Ei, vamos usar um JPEG” ou “Vamos usar um PNG”, acho que há algumas dimensões para isso valer a pena. tendo em mente. O primeiro é apenas geralmente a compressão. Você mencionou o ImageOptim, e muitos de nós estão acostumados a apenas arrastar uma imagem para um lugar e obter algo menor na parte de trás dela.

Addy Osmani: Agora, quando se trata de compactação, geralmente estamos falando de codecs diferentes. E os codecs são uma tecnologia de compactação que geralmente possui um componente codificador para codificar arquivos e um componente decodificador para decodificá-los e descompactá-los. E quando você decide se está usando algo, geralmente precisa pensar se as fotos ou as imagens que você está usando são adequadas para você usar uma abordagem de compactação com perdas ou uma abordagem com menos perdas.

Addy Osmani: Caso as pessoas não estejam tão familiarizadas com esses conceitos, uma abordagem sem perdas é aquela em que você reproduz exatamente o mesmo arquivo no final da descompactação. Então você não está realmente perdendo muito em termos de qualidade. Lossless é muito mais colocar sua imagem em uma máquina de fax. Você recebe um fac-símile do original, e não será o arquivo original. Pode haver alguns artefatos diferentes lá. Pode parecer sutilmente diferente. Mas, em termos gerais, quanto mais você compactar, mais qualidade você normalmente perde.

Addy Osmani: E com todos esses codecs de imagem modernos, eles estão tentando ver quanta qualidade você pode extrair enquanto ainda mantém um tamanho de arquivo relativamente decente, dependendo do caso de uso.

Drew McLellan: Realmente, do ponto de vista da tecnologia, você tem uma imagem de origem e, em seguida, o formato de arquivo de destino. Mas o processo de transformar um no outro está aberto ao debate. Contanto que você tenha um arquivo em conformidade, como você faz isso depende de um codec que pode ter muitas implementações diferentes, e algumas serão melhores que outras.

Addy Osmani: Com certeza. Absolutamente. E acho que, novamente, voltando para onde começamos com JPEG e PNG, as pessoas podem saber que o JPEG foi criado para uma compactação com perdas de fotos. Geralmente, você obtém um arquivo menor na parte de trás dele e, às vezes, pode ter diferentes artefatos de banda. PNG foi criado originalmente para uma compressão sem perdas, funciona muito bem em imagens não fotográficas.

Addy Osmani: Mas desde então, as coisas evoluíram. Por volta de 2010, começamos a ter suporte para WebP, que deveria substituir JPEG e PNG e os supera um pouco na compactação. Mas o número de formatos e opções de imagem na mesa disparou desde então. Acho que as coisas estão indo em uma boa direção, especialmente com formatos modernos como AVIF e JPEG XL. Mas demorou um pouco para chegarmos aqui. Mesmo obter suporte WebP em todos os navegadores levou algum tempo.

Addy Osmani: E acho que, em última análise, o que influenciou foi garantir que os desenvolvedores pedissem por isso, eles tinham o apetite de conseguir uma melhor compactação desses formatos modernos e o desejo de ter uma boa compatibilidade entre navegadores para essas coisas também.

Drew McLellan: Sim. O WebP parece realmente interessante para mim, porque além de ter compactação sem perdas e com perdas disponível no formato, obviamente temos um tamanho de arquivo muito reduzido como resultado. E há um bom suporte para navegadores, e vemos a adoção de grandes empresas como Google e Netflix e várias grandes empresas.

Drew McLellan: Mas minha percepção na indústria é que não vemos o mesmo tipo de aceitação nas bases. O WebP ainda está esperando seu dia chegar?

Addy Osmani: Acho que diria que o WebP está chegando. Muitas pessoas estavam esperando o suporte do Safari e do WebKit se materializar, e finalmente temos isso. Mas quando pensamos em novos formatos de imagem, é muito importante entendermos o que realmente significa suporte. Há suporte de navegador para decodificar essas imagens. Também precisamos de um suporte de ferramentas realmente bom para que, se você estiver em um ambiente de nó, CDN de imagem, se estiver em um CMS, tenha a capacidade de usar esses formatos de imagem.

Addy Osmani: Lembro-me de muitos anos atrás quando o WebP foi lançado. Os primeiros usuários tiveram esse problema de você salvar seu arquivo WebP em sua área de trabalho e, de repente, “Ah, espere. Preciso arrastar isso para o meu navegador para visualizá-lo?” ou “Se meus usuários estiverem baixando o WebP, eles ficarão presos e se perguntarão o que está acontecendo?”

Addy Osmani: Portanto, garantir que haja um suporte bastante holístico para o formato de imagem, tanto no nível do sistema operacional quanto em outro contexto, é muito importante, eu acho, para que um formato de imagem decole. Também é importante que as pessoas que estão fornecendo imagens pensem um pouco sobre esses casos de uso para que, se eu estiver salvando ou baixando um arquivo, você tente colocá-lo em um formato portátil que as pessoas geralmente possam compartilhar facilmente. E acho que é aqui que, pelo menos no iOS, o iOS tem suporte para caminhada e hífen. E converter coisas para JPEGs quando necessário permite que as pessoas as compartilhem.

Addy Osmani: Então, pensar nesses tipos de casos de uso em que podemos garantir que os usuários não estejam perdendo enquanto oferecemos uma melhor compactação é importante, eu acho.

Drew McLellan: Tenho um serviço de compartilhamento de slides que administro que, como você pode imaginar, lida com centenas de milhares de imagens. E quando eu estava olhando para o WebP, e isso provavelmente foi há três anos, eu estava procurando principalmente uma maneira de reduzir os custos de largura de banda da CDN, porque se você está servindo um arquivo menor, está sendo cobrado menos por isso. Mas, embora eu ainda precisasse de uma imagem fullback, um formato de imagem herdado também, meus cálculos mostraram que o custo de armazenar todo um outro conjunto de imagens superava os benefícios de servir um arquivo menor. Então, aqui estamos em 2021. Essa é uma decisão que eu deveria reconsiderar neste momento?

Addy Osmani: Acho que é uma consideração muito importante. Às vezes, quando falamos sobre como você deve abordar sua estratégia de imagem, é muito fácil dar às pessoas uma resposta de alto nível: “Ei, sim. Basta gerar cinco formatos diferentes e isso será dimensionado infinitamente.” E nem sempre é o caso.

Addy Osmani: Eu acho que quando você tem que manter o armazenamento em mente, às vezes, tentar encontrar o que é o melhor e mais comum denominador para servir seus usuários vale a pena ter em mente. Hoje em dia, eu diria que vale a pena considerar o WebP como esse denominador comum. Para pessoas que estão acostumadas a usar a tag de imagem para veicular condicionalmente diferentes formatos para as pessoas, normalmente você usaria um JPEG como seu principal substituto. Talvez não haja problema em usar o WebP como seu substituto para a maioria dos usuários, a menos que você tenha pessoas que usam navegadores muito, muito antigos. E acho que estamos vendo muito menos disso hoje em dia. Mas você definitivamente tem alguma flexibilidade lá.

Addy Osmani: Agora, se você está tentando olhar para frente, eu diria que escolha um formato que você sente que funciona muito bem. Se você puder abordar o armazenamento de uma maneira que seja dimensionada e flexível para suas necessidades, o que eu diria que as pessoas deveriam fazer é considerar o JPEG XL. Ainda não está sendo tecnicamente enviado em um navegador. Quando isso acontece, o JPEG XL deve ser uma ótima opção para muitas fotos em casos de uso com ou sem perdas ou também para casos de uso sem fotos. E provavelmente será muito melhor que o WebP V1. Então esse é um lugar.

Addy Osmani: Acho que o AVIF provavelmente será melhor se você precisar usar taxas de bits realmente baixas. Talvez você se importe muito com a largura de banda. Talvez você se importe um pouco menos com a fidelidade da imagem. E com essas taxas de bits, eu poderia imaginá-lo mais nítido do que algumas das alternativas. E até que tenhamos JPEG XL, tentarei dar uma olhada em suas análises e entender se é possível servir AVIF. Caso contrário, eu me concentraria nesse WebP. Se você fosse analítico, acho que a maioria das pessoas pode ser atendida pelo WebP e você se importa um pouco menos com ampla gama ou sobreposições de texto, lugares onde a amostragem de cromossomos pode não ser perfeita no WebP. Isso é certamente algo que vale a pena ter em mente.

Addy Osmani: Então, eu tentaria ter em mente que não haverá um tamanho único para todos. Pessoalmente, hoje em dia, me preocupo um pouco menos com os custos de armazenamento e saída e largura de banda, apenas porque uso uma CDN de imagem. E fico feliz em dizer que uso o Cloudinary pessoalmente. Usamos muitas CDNs de imagem diferentes no local onde trabalho. Mas descobri que não ter que me preocupar tanto com os custos de manutenção de lidar com pipelines de imagens, lidar com como vou dar suporte, como, “Ah, ei, aqui está outro formato de imagem ou novos tipos de fallbacks ou novas APIs da web ”, isso tem sido um bom benefício para investir em algo que apenas cuida disso para mim.

Addy Osmani: E então o custo total para meus casos de uso foi bom. Mas posso imaginar totalmente que, se você estiver executando um serviço de slides nessa escala, isso também pode não ser necessariamente uma opção.

Drew McLellan: Sim. Então, quero voltar a alguns desses formatos futuros. Mas acho que vale a pena investigar, porque com qualquer tipo de ferramenta de desempenho, Lighthouse ou WebPageTests, se qualquer um de nós executar nossos sites por meio dele, uma das principais coisas que ele sugerirá é que usemos um CDN para imagens. E isso é uma coisa muito realista de se fazer para empresas muito grandes. É realista e ao alcance de pessoas que criam sites e aplicativos menores ou é realmente tão fácil de fazer quanto parece?

Addy Osmani: Acho que a pergunta que as pessoas deveriam fazer é: “Para que você está usando imagens?” Se você tem apenas algumas imagens, se você está criando um blog e as imagens que você está adicionando são relativamente simples, você não tem centenas e centenas ou milhares de milhares de imagens, você pode estar bem em apenas abordar isso em tempo de compilação, de uma maneira muito estática, onde você instala alguns pacotes NPM. Talvez você esteja apenas usando a Sharp. E isso cuida de você na maior parte.

Addy Osmani: Existem ferramentas que podem ajudá-lo a gerar vários formatos. Isso aumenta um pouco o tempo de construção, mas isso pode ser bom para muitas pessoas. E então para pessoas que querem ser capazes de alavancar múltiplos

Addy Osmani: E então, para as pessoas que querem ser capazes de alavancar vários formatos, eles não querem lidar com tantas minúcias de ferramentas e querem conseguir uma imagem ou história responsiva realmente rica, eu diria experimentar uma imagem CDN. Eu era pessoalmente bastante reticente em usá-lo para projetos pessoais para as preocupações de custo inicialmente e, com o tempo, ao dar uma olhada no meu faturamento, percebi que estava me economizando tempo que, de outra forma, estaria investindo na resolução desses problemas. Eu não sei o quanto você teve que escrever scripts personalizados para lidar com suas imagens no passado, mas percebi que se eu puder economizar pelo menos alguns dias de depuração por meio desses diferentes pacotes npm por mês, então os custos tipo de cuidar do tempo que estou economizando e então está tudo bem.

Addy Osmani: Mas pode ser algo em que, se você estiver escalando para 100s de 1000s ou milhões de imagens e isso não é necessariamente coberto por sua receita ou não é algo pelo qual você está preparado para pagar, você precisa pensar estratégias alternativas. E acho que temos sorte de termos flexibilidade suficiente com as ferramentas que estão disponíveis para nós hoje para podermos ir em qualquer uma dessas direções, onde fazemos algo um pouco mais personalizado, lidamos com isso ou rolamos nossa própria imagem CDN ou investimos em algo um pouco mais comercial. E estamos em um lugar onde eu diria que para alguns casos de uso, sim, você pode usar uma CDN de imagem e é acessível.

Drew McLellan: Acho que um dos princípios orientadores é sempre ser ágil e estar preparado para a mudança. E você pode começar usando uma CDN de imagem para converter dinamicamente suas imagens conforme elas são solicitadas, e se isso chegar a um ponto em que não é sustentável em termos de custo, você pode procurar outra solução e ter sua base de código em um estado onde será fácil substituir uma solução por outra. Eu acho que geralmente e em qualquer lugar que você está contando com um serviço de terceiros, esse é um bom princípio, não é? Então, esses próximos formatos de imagem, você mencionou JPEG XL. O que é JPEG XL? De onde veio? E o que isso faz por nós?

Addy Osmani: Essa é uma excelente pergunta. Portanto, o JPEG XL é um formato de imagem da próxima geração, deve ser de uso geral e é um codec do comitê de JPEG. Começou com algumas raízes no formato pic do Google e depois no formato FUIF do Cloudinary. Houve muitos formatos ao longo dos anos que foram subsumidos por esse esforço, mas se tornou muito mais do que apenas o tipo de soma de suas partes individuais e alguns dos benefícios do JPEG XL são: é ótimo para alta fidelidade imagens, muito bom para sem perdas, tem suporte para decodificação progressiva, transcodificação JPEG sem perdas, e também é meio sem complicações e livre de royalties, o que é definitivamente um benefício. Eu acho que o JPEG XL poderia ser um candidato muito forte. Estávamos falando anteriormente, se você fosse escolher apenas um, o que você usaria? E acho que o JPEG XL tem potencial para ser esse.

Addy Osmani: Eu também não quero prometer demais, ainda estamos muito no início com o suporte ao navegador. E então acho que devemos realmente esperar e ver, experimentar e avaliar o quão bem ele se alinha na prática e atende às expectativas das pessoas, mas vejo muito potencial no JPEG XL para esses casos com e sem perdas. No momento, acredito que o Chrome é provavelmente o mais avançado em termos de suporte, mas também vi definitivamente interesse do lado da Mozilla e de outros navegadores nisso, então estou animado com o futuro com o JPEG XL. E se disséssemos, qual é o prazo ainda mais curto de interesse para as pessoas? Claro que há AVIF também.

Drew McLellan: Conte-nos sobre o AVIF, este é outro que não conheço.

Addy Osmani: Tudo bem. Então, mencionamos um pouco antes que o AVIF talvez seja um candidato melhor se você precisar ir para baixas taxas de bits e se preocupar mais com a largura de banda do que com a fidelidade da imagem. E JPEG XL, deve se destacar em média a alta fidelidade, mas são formatos ligeiramente diferentes em seus próprios direitos. Estamos em um ponto em que o AVIF tem um suporte cada vez mais bom para navegadores, mas deixe-me dar um passo atrás e falar um pouco mais sobre o formato. Portanto, o próprio AVIF é baseado no codec de vídeo AV1, que foi padronizado pela Alliance for Open Media, e tenta obter às pessoas ganhos significativos de compactação sobre JPEG, sobre WebP, sobre o qual falamos anteriormente. E embora as economias exatas que você pode obter com o AVIF dependam do conteúdo e de suas metas de qualidade, vimos muitos casos em que ele pode oferecer mais de 50% de economia em comparação ao JPEG.

Addy Osmani: Ele tem muitos recursos bons, é capaz de oferecer suporte a contêineres para novos recursos, como alta faixa dinâmica e ampla gama de cores, síntese de grãos de filme. E, novamente, semelhante a falar sobre estar voltado para a frente, uma das coisas boas sobre a tag de imagem é que você pode fornecer aos usuários arquivos AVIF agora e ainda retornará ao seu WebP ou JPEG nos casos em que não for necessariamente suportado . Mas voltando ao seu exemplo sobre o Photoshop Save For Web, você poderia pegar um JPEG com 500 kilobytes de tamanho, tentar capturar uma qualidade similar ao Photoshop Save For Web e com AVIF eu diria que você provavelmente será capaz de chegar a um ponto em que o tamanho do arquivo é de cerca de 90 kilobytes, 100 kilobytes, portanto, muita economia sem perda real discernível na qualidade.

Addy Osmani: E uma das coisas boas sobre isso é que, idealmente, você não verá tanta perda de textura em qualquer imagem que tenha detalhes ricos. Portanto, se você tiver fotos de florestas ou acampamentos ou qualquer um desses tipos de coisas, elas ainda devem parecer muito ricas com AVIF. Então, estou bastante animado com a direção que o AVIF tem. Eu acho que precisa de um pouco mais de trabalho em termos de suporte de ferramentas. Então eu soltei um tweet sobre isso outro dia, temos várias opções para usar AVIF agora, para imagens únicas temos Squoosh, squoosh.app, que foi escrito por outra equipe no Chrome, então grite para Surma e Jake por trabalharem em Squoosh. Avif.io tem uma série de boas opções para pessoas que estão tentando usar AVIF hoje, independentemente da pilha de tecnologia em que estão focados, a Sharp também suporta AVIF.

Addy Osmani: Mas geralmente você pensa em outros lugares onde lidamos com imagens, seja no Figma ou no Sketch ou no Photoshop ou em outros lugares, e eu diria que ainda precisamos fazer um pouco de trabalho em termos de Suporte AVIF lá, porque precisa ser onipresente para desenvolvedores e usuários realmente sentirem que chegaram e voltaram para casa. E essa é uma das áreas de foco para nós com as equipes que trabalham em AVIF no Chrome no momento, tentando garantir que possamos levar as ferramentas a um bom lugar.

Drew McLellan: Então temos HTML, o elemento de imagem agora, que nos dá mais flexibilidade sobre a tag de imagem tradicional. Embora a tag de imagem tenha percorrido um longo caminho também, não é? Mas vimos a imagem sendo adicionada, foi na mesma época que a tag de vídeo nativa, acho que nesse tipo de lote original de alterações HTML5. E isso nos dá a capacidade de especificar várias fontes, certo?

Addy Osmani: Sim, isso mesmo.

Drew McLellan: Então você pode listar diferentes formatos de imagens e o navegador escolherá aquele que ele suporta, e isso nos permite ser bastante experimentais imediatamente sem precisar se preocupar muito em quebrar coisas para pessoas com navegadores mais antigos.

Addy Osmani: Com certeza. Acho que esse é um dos benefícios mais interessantes de usar a tag de imagem fora dos casos de uso em que estamos pensando em nossa direção, apenas poder fornecer uma imagem às pessoas e fazer com que o navegador percorra a lista de fontes em potencial e veja, ok, bem, vou usar o primeiro dessa lista que eu entendo, caso contrário vou voltar atrás, essa é uma capacidade muito poderosa para as pessoas. Acho que, ao mesmo tempo, também ouvi algumas pessoas expressarem alguma preocupação ou preocupação de que estamos regenerando bolhas realmente enormes de marcação agora quando tentamos oferecer suporte a vários formatos e você considera tamanhos diferentes para esses formatos e de repente fica um pouco volumoso.

Addy Osmani: Então, existem outras maneiras de abordar esses problemas? Não quero vender muito para as pessoas em CDNs de imagem, quero que elas se mantenham por conta própria. Mas este é um daqueles lugares onde uma ideia chamada negociação de conteúdo pode realmente oferecer um caminho interessante. Então, falamos um pouco sobre tag de imagem onde você tem que gerar um monte de recursos diferentes e decidir a ordem de preferência, certo, HTML extra. Com a negociação de conteúdo, o que ele diz é que vamos fazer todo esse trabalho no servidor. Assim, os clientes podem informar ao servidor quais formatos ele suporta antecipadamente por meio da lista de tipos MIME por meio do cabeçalho Accept HTTP. Em seguida, o servidor pode fazer todo o trabalho pesado de gerar e gerenciar os recursos finais e decidir quais enviar aos clientes. E uma das coisas poderosas aqui é que, se você estiver usando uma CDN de imagem, poderá apontar para um único recurso.

Addy Osmani: Então, talvez, se tivermos uma imagem de filhote de cachorro como filhote.JPEG, poderíamos fornecer às pessoas um URL para filhote.JPEG e se o navegador deles suportar WebP ou AVIF, o servidor pode ficar muito esperto em servir à direita imagem para esses usuários, dependendo da aparência do suporte, mas, caso contrário, recue sem que você precise fazer muito trabalho extra. Agora, eu acho que é uma idéia poderosa. Há muito que você pode fazer no servidor, às vezes falamos sobre como nem todo mundo tem acesso a uma qualidade de rede realmente forte, seu tipo de conexão efetiva pode ser muito diferente dependendo de onde você está.

Addy Osmani: Mesmo morando no Vale do Silício, eu poderia estar andando de um café para um hotel ou poderia estar no carro e a qualidade do meu wifi ou do meu sinal pode não ser tão boa. Portanto, é aqui que você tem acesso a outras APIs, outras ideias, como a dica do cliente Save-Data para poder atender pessoas com recursos de tamanho ainda menor, se o usuário tiver optado pela economia de dados. Portanto, há muitas coisas interessantes que poderíamos fazer no lado do servidor e acho que devemos continuar pressionando essas ideias de encontrar um bom equilíbrio onde as pessoas que se sentem à vontade para seguir o caminho do mercado tenham toda a flexibilidade para fazê-lo e as pessoas que querem uma solução um pouco mais mágica também têm algumas opções.

Drew McLellan: O conceito desse tipo de abordagem de economia de dados foi algo que aprendi primeiro em seu livro. Quero dizer, vamos entrar um pouco mais nisso porque isso é bastante interessante. Então você está falando sobre o navegador ser capaz de sinalizar uma preferência por querer uma experiência de dados reduzida porque talvez esteja em uma conexão limitada ou tenha bateria fraca ou algo assim.

Addy Osmani: Exatamente. Exatamente. Tenho viajado nos tempos normais ou nos tempos anteriores em que viajaríamos muito mais, experimentei muitos lugares no mundo ou situações em que a qualidade da minha rede pode ser muito ruim ou muito irregular, e mesmo abrindo abrir uma página da Web pode ser uma experiência frustrante ou difícil. Posso estar procurando um cardápio e, se não consigo ver fotos da bela comida que eles têm disponível, posso ir a algum lugar onde posso, ou posso, não sei, preparar alguma comida. Mas acho que uma das coisas interessantes sobre a economia de dados é que ela oferece uma conexão com as preferências do usuário. Então, se como usuário, eu sei que estou tendo dificuldades com minha conexão de rede. Posso dizer: "Ok, bem, vou ativar o modo de economia de dados no meu navegador".

Addy Osmani: E então você pode usar isso como um desenvolvedor como um sinal para dizer: “Ok, bem, o usuário está um pouco limitado, talvez possamos navegar por imagens muito menores ou imagens de qualidade muito inferior”. Mas eles ainda conseguem ver algumas imagens, o que é melhor do que esperar muito tempo para que algo muito mais rico seja servido. Outros benefícios desses tipos de sinais são que você pode usá-los para veicular mídia condicionalmente. Então, talvez haja casos em que o texto seja a coisa mais importante nessa página, talvez você possa desativar essas imagens se descobrir que os usuários estão em um ambiente restrito. Vou gastar apenas 30 segundos nisso, mas você pode realmente levar essa ideia ao extremo. Algumas das coisas interessantes que você pode fazer com o Save-Data talvez sejam até mesmo desativar recursos muito caros implementados em JavaScript.

Addy Osmani: Se você tiver certos componentes que são considerados um pouco mais opcionais, talvez eles não precisem necessariamente ser enviados a todos os usuários se apenas melhorarem a experiência. Você ainda pode oferecer a todos uma experiência muito básica, pequena e rápida e, em seguida, apenas sobrepor com uma boa cobertura para pessoas que têm uma conexão ou dispositivo mais rápido.

Drew McLellan: Potencialmente, acho que isso poderia levar em consideração a paginação e você poderia retornar 10 resultados em uma página em vez de 100 e esse tipo de coisa também. Então, muitos recursos interessantes e interessantes lá. Acho que estamos todos familiarizados com o processo frustrante de preparar um novo site, otimizar todas as suas imagens, entregá-las ao cliente, dar a eles um CMS para gerenciar o conteúdo e descobrir que eles estão apenas substituindo tudo por imagens mal otimizadas. Quero dizer, novamente, uma imagem CDN, eu acho, seria uma solução muito conveniente para isso, mas existem outras soluções, há coisas que o CMS poderia estar fazendo no servidor para ajudar com isso ou é uma imagem CDN provavelmente a caminho a percorrer?

Addy Osmani: Acho que o que descobrimos depois de provavelmente pelo menos seis ou sete anos tentando fazer com que todos otimizassem suas imagens é que é um problema difícil, onde algumas pessoas envolvidas na imagem podem ser um pouco mais experientes tecnicamente e talvez um cenário confortável criar suas próprias ferramentas ou executar o Lighthouse ou experimentar outras ferramentas para que eles saibam se há oportunidades para melhorar. Eu adoraria ver as pessoas usando consistentemente coisas como o Lighthouse para descobrir se você tem oportunidades de otimizar ainda mais ou exibir imagens do tamanho certo, mas além disso, às vezes nos deparamos com casos de uso em que as pessoas que estão enviando imagens podem não necessariamente até mesmo entender o custo dos recursos que estão carregando. Isso geralmente é algo que encontramos, e peço desculpas, não vou chamar muito as pessoas, mas isso é algo que encontramos mesmo com o blog do Google.

Addy Osmani: A cada duas semanas no blog do Google, alguém envia um GIF animado muito grande de 20 ou 30 megabytes. E eu não espero que eles saibam que isso não é uma boa ideia, eles estão tentando fazer o artigo parecer legal e muito envolvente e interativo, mas esses públicos não necessariamente saberão executar ferramentas ou usar o ImageOptim ou usar qualquer uma dessas outras ferramentas no local e documentá-las, de modo que eles devam consultá-las, é certamente uma opção. Mas ser capaz de automatizar o problema, acho muito atraente e nos ajuda a chegar a um ponto em que esperamos equilibrar as necessidades de todos os nossos usuários de CMSs, sejam eles técnicos ou não técnicos, também conforme as necessidades de nossos usuários.

Addy Osmani: So I think the image CDNs can definitely play a role in helping out here. Ultimately, the thing that's important is making sure you have a solution in place between people, stakeholders who might be uploading those images, and what gets served down to users. If it's an image CDN, if it's something you've rolled yourself, if it's a built step, just needs to be something in place to make sure that you are not serving down something that's very, very large and inefficient.

Drew McLellan: Talking about animated GIFs, they're surprisingly popular. They're fun, we love them, but they're also huge. And really, it's a case where a file format that was not designed for video is being used for video. Is there a solution to that with any of these image formats? What can we do?

Addy Osmani: Oh, gosh. The history of GIFs is fascinating. We saw a lot of the formats we know and love or have been around for a while were originated in the late '80s to early '90s, and the GIF is one of those. It was created in 1987. I'm about as old as the GIF.

Addy Osmani: As you mentioned, it wasn't originally created necessarily for use case. I think it was Netscape Navigator which in mid '90s maybe added support for looping GIFs and giving us this kind of crazy fun way to do memes and the like, but GIFs have got so many weaknesses. They're kind of limited in many cases to a very finite color palette; 256 colors, in many cases. They're a bitmapped raster format with pixel value stored in image files.

Addy Osmani: They're very inefficient, for a number of reasons. And you mentioned that they're also quite large. I think that we've gotten into this place of thinking that if we want a short segment of video or animation that's going to be looping, the GIF is the thing that we have to use. And that's just not the case.

Addy Osmani: While we do see that there are modern image formats that have support for animation, I think that the most basic thing you can do these days is make sure you're serving a video down instead of a GIF. Muted auto-play videos combined with HD64, HD65, whatever video you're going to use, can be really powerful, and significantly smaller for use cases where you need to be showing a sequence of images.

Addy Osmani: There are options for this. AVIF has got image sequences in there, potentially. Other formats have explored these ideas as well. But I think that one thing you can do is, if you're using GIFs today, or you have users who are slightly less technical who are using GIFs today, try to see if you can give them tools that will allow them to export a video instead, or if your pipeline can take care of that for them, that's even better.

Addy Osmani: I have plenty of conversations with CMS providers where you do see people uploading GIFs. They don't know the difference between a video and a GIF file. But if you can just, whether it's with an image CDN or via some built process, change the file over to a more efficient format, that would be great.

Drew McLellan: We talked briefly about tools like ImageOptim that manage to strip out information from the files to give us the same quality of result with a smaller file size. I'm presuming that's because the file formats that we commonly deal with weren't optimized for delivery over the Web in the first place, so they're doing that step of removing anything that isn't useful for serving on the Web. Do these new formats take that into consideration already? Is something like ImageOptim a tool that just won't be required with these newer formats?

Addy Osmani: I'm anticipating that some of the older formats… Things that have been around for a while, take a while to phase out or to evolve into something else. And so I can see tools like ImageOptim continuing to be useful. Now, what are modern image formats doing that are much better? Well, I would say that they're taking into account quite a few things.

Addy Osmani: They're taking into account, are there aspects of the picture that the human eye can't necessarily make out a difference around? When I'm playing around with different quality settings or different codecs, I'm always looking for that point where if I take the quality down low enough, I'm going to see banding artifacts. I'm going to see lots of weird looking squares around my buildings or the details of my picture.

Addy Osmani: But once those start to disappear, I really need to start zooming in to the image and making comparisons across these different formats. And if users are unlikely to do that, then I think that there are good questions around is that point of quality good enough? I think that modern image formats are pretty good at being able to help you navigate, filtering out some of those details pretty well. Keeping in mind what are the needs of color, because obviously we've got white gamut as a thing right now as well.

Addy Osmani: Some people might be okay with an amount of changing your color palette versus not, depending on the type of images that you have available, but definitely I see modern formats trying to be resilient against things like generational loss as well. Generational loss is this idea that… We mentioned memes earlier. A common problem on the Web today is you'll find a meme, whether it's on Facebook or Instagram or Reddit or wherever else, you'll save it, and maybe you'll share it around with a friend. Maybe they'll upload it somewhere else. And you suddenly have this terrible kind of copy machine or fax effect of the quality of that image getting worse and worse and worse over time.

Addy Osmani: And so when I see something get reshared that I may have seen three months ago, now it might not be really, really bad quality. You can still make out some of the details, but image formats, being able to keep that in mind and work around those types of problems, I think are really interesting.

Addy Osmani: I know that JPEG XL was trying to keep this idea of generational loss in mind as well. So there's plenty of things that modern codecs and formats are trying to do to evolve for our needs, even if they're very meme focused.

Drew McLellan: Let's say you've inherited a project that has all sorts of images on it. What would be the best way to assess the state of that project in terms of image optimization? Are there tools or anything that would help there?

Addy Osmani: I think that it depends on how much time you've got to sink into the problem. There are very basic things people can try doing, like obviously batch converting those images over to more modern formats at the recommended default quality and do an eyeball check on how well they're doing compared to the original.

Addy Osmani: If you're able to invest a little bit more time, there are plenty of tools and techniques like DSSIM and other ways of being able to compare what the perceptual quality differences are between different types of images that have been converted. And you can use that as a kind of data-driven approach to deciding, if I'm going to batch convert all of my old images to WebP, what is the quality setting that I should be relying on? If I'm going to be doing it for AVIF or JPEG XL, what is the quality setting that I should be relying on?

Addy Osmani: I think that there's plenty of tools people have available. It really just depends on your time sink that's possible. Other things that you can do, again, going back to the image CDN aspect, if you don't have a lot of time and you're comfortable with the cost of an image CDN, you can just bulk upload all of those images. And there are CDNs that support this idea of automatic quality setting. I think in Cloudinary it's q_auto, or something like that.

Addy Osmani: But the basic idea there is they will do a scan of the image, try to get a sense of the type of content that's in there, and automatically decide on the right level of quality that you should be using for the images that are getting served down to users. And so you do have some tooling options that are available here, for sure.

Drew McLellan: I mean, you mentioned batch processing of images. Presumably you're into the area of that generational loss that you're talking about, when you do that. When you take an already compressed JPEG and then convert it to a WebP, for example, you risk some loss of quality. Is batch converting a viable strategy or does that generational loss come too much into play if you care about the pristine look of the images?

Addy Osmani: I think it depends on how much you're factoring in your levels of comfort with lossy versus lossless, and your use case. If my use case is that I've inherited a project where the project in question is all of my family's photos from the last 20 years, I may not be very comfortable with there being too much quality loss in those images, and maybe I'm okay with spending a little bit more money on storage if the quality can remain mostly the same, just using a more modern format.

Addy Osmani: If those are images for a product catalog or any commerce site, I think that you do need to keep in mind what your use case is. Are users going to require being able to see these images with a certain level of detail? And if that's the case, you need to make those trade-offs in mind when you're choosing the right format, when you're choosing the right quality.

Addy Osmani: So I think that batch is still okay. To give you a concrete idea of one way of seeing people approach this at scale, sometimes people will take a smaller sample of the images from that big collection that they've inherited, and they'll try out a more serious set of experiments with just that set. And if they're able to land on an approach that works well for the sample, they'll just apply it to the whole batch. And I've seen that work to varying degrees of success.

Drew McLellan: So optimizing file size is just sort of one point on the overall image optimization landscape. And I'd like to get on to talking about what we can do in our browsers to optimize the way the images are used, which we'll do after a quick word from this episode sponsor.

Drew McLellan: So we've optimized and compressed our large files, but now we need to think about a strategy for using those in the browser. The good old faithful image tag has gained some new powers in recent times, hasn't it?

Addy Osmani: Yeah, it has. And maybe it's useful for folks… I know that a lot of people that ask me about images these days also ask me to frame it in terms of metrics and the Core Web Vitals. Would it be useful for me to talk about what the Core Web Vitals are and maybe frame some of those ideas in those current terms?

Drew McLellan: Absolutely, because Core Web Vitals is a sort of initiative from Google, isn't it, that we've seen more recently? We're told that it factors into search ranking potentially at some level. What does Core Web Vitals actually mean for us in terms of images?

Addy Osmani: Great question. As you mentioned, Core Web Vitals is an initiative by Google, and it's all about trying to share unified guidance for quality signals. That can be pretty key to delivering a great user experience on the Web. And it is part of a set of page experience signals Google Search may be evaluating for ranking purposes, but they can impact the Core Web Vitals in a number of ways.

Addy Osmani: Now, before I talk about what those ways are, I should probably say, what are the Core Web Vitals metrics? There's currently three metrics that are in the Core Web Vitals. There's largest contentful paint, there's cumulative layout shift, and there's first input delay. Now, in a lot of modern Web experiences we find that images tend to be one of the largest visible elements on the page. We see a lot of product pages where we have a big image that's the main product item image. We see images in carousels, in stories and in banners.

Addy Osmani: Now, largest contentful paint, or LCP, is a Core Web Vitals metric that tries to measure when the largest contentful element, whether it's an image text or something else, is in a user's viewport, such that we're able to tell when that image becomes visible. And that really allows a browser to determine when the main content of the page has really finished rendering.

Addy Osmani: Então, se estou tentando acessar um site de receitas, posso me importar com a aparência dessa receita, e nos preocupamos em garantir que essa grande imagem de herói da receita seja visível para mim. Agora, o elemento LCP pode mudar ao longo do tempo. É muito possível que no início do carregamento, a maior coisa seja um título, mas à medida que a página continua a carregar, pode acabar sendo uma imagem muito maior ou um pôster de algum tipo.

Addy Osmani: Então, quando você está tentando otimizar a maior pintura de conteúdo, há cerca de quatro coisas que você pode fazer. A primeira coisa é certificar-se de que você está solicitando sua imagem principal de herói o mais cedo possível. Geralmente, temos uma série de coisas que são importantes na página. Queremos ter certeza de que podemos renderizar o conteúdo e o layout da página principal.

Addy Osmani: Para layout, normalmente estamos falando de CSS. Portanto, você pode estar usando CSS crítico, CSS inline, em suas páginas, deseja evitar coisas que bloqueiam a renderização, mas quando se trata de sua imagem, o ideal é solicitar essa imagem com antecedência. Talvez isso envolva apenas garantir que o navegador possa descobrir essa imagem o mais cedo possível na página, já que muitos de nós hoje em dia confiamos em estruturas.

Addy Osmani: Se você não estiver necessariamente usando SSR, renderização do lado do servidor, se estiver esperando que o navegador descubra alguns de seus pacotes JavaScript, pacotes para seus componentes, se você tem um componente para sua imagem de herói ou imagem de produto, se o navegador tiver que esperar para buscar, analisar, executar, compilar e executar todos esses arquivos diferentes antes de descobrir a imagem, isso pode significar que sua maior imagem com conteúdo levará algum tempo antes de ser descoberta.

Addy Osmani: Agora, se for esse o caso, se você se encontrar em um local onde a imagem está sendo solicitada muito tarde, poderá aproveitar um recurso do navegador chamado link rel preload para garantir que o navegador possa descobrir essa imagem o mais cedo possível que possível. Agora, o pré-carregamento é um recurso realmente poderoso. É também aquele que você precisa tomar muito cuidado. Hoje em dia, é muito fácil chegar a um lugar onde talvez você ouça que estamos recomendando o pré-carregamento para sua chave-

Addy Osmani: Talvez você tenha ouvido que estamos recomendando o pré-carregamento para sua imagem principal de herói, bem como seus scripts principais, bem como suas fontes principais. E torna-se muito grande, massivo, tentar ter certeza de que você está sequenciando as coisas na ordem certa. Portanto, as imagens LCP são definitivamente um local importante que vale a pena ter em mente para isso.

Addy Osmani: A outra coisa, como mencionei quatro coisas, a outra coisa é ter certeza de que você está usando o conjunto de fontes e um formato de imagem moderno e eficiente. Eu acho que esse conjunto de fontes é realmente poderoso. Eu também vejo que, às vezes, quando as pessoas estão usando, elas tentam compensar e talvez enviem 10 versões diferentes de imagens para cada resolução possível. Nós tendemos a descobrir, pelo menos em algumas pesquisas, que além de três por imagens, os usuários têm muita dificuldade em dizer quais são as diferenças para qualidade de imagem, nitidez e detalhes. Portanto, o limite de DPR, limite de proporção de pixel do dispositivo, certamente é uma ideia que vale a pena ter em mente.

Addy Osmani: E para formatos de imagem modernos, falamos sobre formatos anteriormente, mas considere seu WebP, seu AVIF, seu JPEG XL. Evite desperdiçar pixels. É muito importante ter uma boa estratégia de qualidade. E acho que há muitos casos em que até a qualidade padrão às vezes pode ser demais. Então, eu experimentaria tentar diminuir sua taxa de bits, diminuir suas configurações de qualidade e ver até onde você pode levar as coisas para seus usuários, mantendo a nitidez.

Addy Osmani: E quando falamos sobre carregamento, uma das outras coisas que a tag de imagem meio que evoluiu para suportar nos últimos dois anos é o carregamento lento. Portanto, com o carregamento lento, você não precisa mais necessariamente usar uma biblioteca JavaScript para adicionar carregamento lento às suas imagens. Você acabou de soltar isso em sua imagem. E nos navegadores chromium e Firefox, você poderá carregar essas imagens com preguiça sem precisar usar dependências de terceiros. E isso é muito legal também.

Addy Osmani: Então, temos o carregamento preguiçoso no lugar. Temos suporte para outras coisas, como decodificação de sincronização, mas vou manter as coisas funcionando e falar muito rapidamente sobre as outras duas métricas essenciais.

Drew McLellan: Vá em frente, sim.

Addy Osmani: Então, livre-se das mudanças de layout. Ninguém gosta de coisas pulando em suas páginas. Eu sinto que uma das minhas maiores frustrações é abrir uma página da web. Eu passo meu dedo sobre um botão que eu quero clicar e, de repente, um monte de anúncios ou imagens sem definição de dimensão ou outras coisas aparecem. E isso causa uma experiência realmente desagradável.

Addy Osmani: Então, a mudança de layout cumulativa tenta medir a instabilidade do conteúdo. E na maioria das vezes, as coisas comuns que estão empurrando suas mudanças de layout são imagens ou outros elementos em sua página que simplesmente não têm dimensão definida. Acho que esse é um daqueles lugares em que muitas vezes é simples para as pessoas definirem as dimensões da imagem. Talvez não seja algo que historicamente fizemos tanto, mas certamente algo que vale a pena gastar seu tempo. Em ferramentas como o lighthouse tentaremos ajudá-lo a coletar, como qual é a lista de imagens em sua página que requerem dimensões? Então você pode ir e você pode configurá-los.

Drew McLellan: Eu ia dizer, esse é um ponto muito interessante porque quando o web design responsivo se tornou uma coisa, todos nós passamos por nossos sites e eliminamos as dimensões da imagem porque as ferramentas que tínhamos à nossa disposição para fazer esse trabalho exigiam que não não tem atributos de altura e largura em nossas imagens. Mas isso é uma má ideia agora, não é?

Addy Osmani: O que é velho é novo novamente. Eu diria que definitivamente vale a pena definir dimensões em suas imagens. Defina dimensões em seus anúncios, molduras de olhos, qualquer coisa que seja conteúdo dinâmico que possa mudar de tamanho, vale a pena definir dimensões.

Addy Osmani: E para as pessoas que estão construindo experiências realmente divertidas, há a frase errada, experiências de layout realmente divertidas, onde talvez você precise trabalhar mais em cartões responsivos e coisas do gênero; Eu consideraria usar a proporção CSS ou caixas de proporção para reservar seu espaço. E isso pode complementar a configuração de dimensões nessas imagens também para garantir que as coisas sejam o mais fixas possível quando você estiver tentando evitar mudanças de layout.

Addy Osmani: E, finalmente, o último Core Web Vital é o primeiro atraso de entrada. Isso é algo que as pessoas nem sempre pensam quando se trata de imagens. Portanto, é de fato possível que as imagens bloqueiem a largura de banda e a CPU de um usuário no carregamento da página. Eles podem atrapalhar a forma como outros recursos críticos são carregados, em particular em conexões muito lentas ou em dispositivos móveis de baixo custo que podem levar à saturação da largura de banda.

Addy Osmani: Portanto, o atraso na primeira entrada é uma métrica do Core Web Vital que captura a primeira impressão dos usuários sobre a interatividade e a capacidade de resposta de um site. E assim, reduzindo o uso da CPU da thread principal, seu primeiro atraso de entrada também pode ser minimizado. Portanto, em geral, evite imagens que possam causar contenção de rede. Eles não estão bloqueando a renderização. Mas eles ainda podem afetar indiretamente seu desempenho de renderização.

Drew McLellan: Existe alguma coisa que possamos fazer com as imagens para impedir que elas bloqueiem a renderização? Podemos tirar a carga do navegador nessa fase inicial de alguma forma para nos permitir ser interativos mais rapidamente?

Addy Osmani: Acho que hoje em dia é cada vez mais importante ter uma boa compreensão da sequência de imagens ideal para exibir algo acima da dobra. Eu sei que acima da dobra é um termo sobrecarregado, mas como na primeira porta de visualização do usuário. Muitas vezes podemos acabar tentando solicitar uma tonelada de recursos, alguns deles sendo imagens, que não são realmente necessários para o que o usuário verá imediatamente. E esses tendem a ser ótimos candidatos para carregar mais tarde no ciclo de vida da página, ótimas coisas para carregar lentamente no lugar. Mas se você estiver solicitando uma grande quantidade de imagens, como uma fila inteira de coisas muito cedo, elas podem ter um impacto.

Drew McLellan: Sim. Então, quero dizer, você mencionou o carregamento lento de imagens que historicamente exigimos que uma biblioteca JavaScript fizesse, o que tem seus próprios contratempos, eu acho, por causa das maneiras históricas que os navegadores otimizam o carregamento de imagens, onde é quase impossível impedi-los de carregar imagens , a menos que você simplesmente não forneça uma fonte. E se você não fornecer uma fonte e depois tentar corrigi-lo com JavaScript, se esse JavaScript não for executado, você não obterá imagens. Então o carregamento lento, o carregamento lento nativo é uma resposta para tudo isso.

Addy Osmani: Sim, absolutamente. E acho que este é um lugar onde tentamos melhorar nos navegadores, a experiência nativa de carregamento lento no ano passado. Como você sabe, esse é um daqueles recursos em que lançamos algo mais cedo e podemos aproveitar as conversas com líderes de opinião do setor para entender como: "Ah, ei, quais são os limites que você está definindo manualmente se você estiver usando tamanhos preguiçosos ou estiver usando outras bibliotecas de carregamento preguiçoso de JavaScript?” E então ajustamos nossos limites para tentar chegar a um lugar um pouco mais próximo do que você espera que eles sejam.

Addy Osmani: Então, em muitos casos, você pode usar o carregamento preguiçoso nativo. Se você precisar de algo muito mais refinado, se precisar de muito mais controle sobre a capacidade de definir os limites do observador de interseção, o ponto em que o navegador solicitará as coisas, geralmente sugerimos que use uma biblioteca nesses casos , só porque estamos tentando resolver o caso de uso de 90%. Mas os 10% ainda são válidos. Pode haver pessoas que ainda precisam de algo um pouco mais. E assim, para a maioria das pessoas, espero que o carregamento preguiçoso nativo seja bom o suficiente no futuro próximo.

Drew McLellan: Acima de tudo, é grátis. Um atributo simples de adicionar e você obtém toda essa funcionalidade gratuitamente, o que é ótimo. Se houvesse uma coisa que nosso ouvinte pudesse fazer, pudesse ir embora e fazer em seu site para melhorar sua otimização de imagem, o que seria? Por onde eles devem começar?

Addy Osmani: Um bom ponto de partida é entender o quanto isso é um problema para o seu site. Eu iria e checaria o farol ou pagaria insights de velocidade. Vá e execute-o em algumas de suas páginas mais populares e veja o que sai. Se parece que você só tem uma ou duas pequenas coisas para fazer, isso é fantástico. Talvez você possa colocar algum tempo lá.

Addy Osmani: Se houver uma longa lista de coisas para você fazer, talvez dê uma olhada nas maiores oportunidades que você tem lá, coisas que dizem: “Oh, ei, você poderia economizar vários segundos se fizesse isso coisa." E concentre sua energia lá para começar.

Addy Osmani: Como falamos aqui, as ferramentas para formatos de imagem modernos melhoraram com o tempo. CDNs de imagem definitivamente podem valer a pena considerar. Mas além disso, há muitos pequenos passos que você pode dar. Às vezes, se for um site pequeno o suficiente, mesmo abrindo o Squoosh, colocar algumas de suas imagens nele pode ser um ótimo ponto de partida.

Drew McLellan: Esse é um conselho sólido. Agora eu sei que é uma publicação sensacional, mas eu realmente devo parabenizá-lo pelo livro. É tão abrangente e muito fácil de digerir. Acho uma leitura muito valiosa.

Drew McLellan: Estou aprendendo tudo sobre otimização de imagem. O que você tem aprendido ultimamente, Addy?

Addy Osmani: O que tenho aprendido ultimamente? Na verdade, em um tópico um pouco diferente que ainda tem a ver com imagens, então quando eu estava fazendo meu mestrado na faculdade, eu me aprofundei muito em visão computacional e tentei entender, como podemos detectar diferentes partes de uma imagem e fazer coisas selvagens e coisas interessantes com eles?

Addy Osmani: E um problema específico que tenho pesquisado recentemente é que tenho visto fotos minhas quando era bebê ou criança. E naquela época, grande parte da comida que meus pais levavam não era necessariamente em câmeras digitais. Eram Polaroids. Geralmente são imagens de baixa resolução. E eu queria uma maneira de poder escalá-los. E então comecei a investigar esse problema novamente recentemente. E isso me levou a aprender muito mais sobre o que posso fazer no navegador.

Addy Osmani: Então, estou desenvolvendo algumas pequenas ferramentas que permitem que você, usando machine learning, TensorFlow, usando tecnologias existentes, pegue uma imagem ou ilustração de resolução relativamente baixa e, em seguida, melhore-a para algo com qualidade muito maior. Então é melhor do que simplesmente esticar a imagem. É como realmente preencher os detalhes.

Addy Osmani: E isso tem sido divertido. Tenho aprendido muito sobre como a montagem da Web está estável agora no navegador, como você pode usar algumas dessas ideias para casos de uso de aplicativos de desktop. E isso tem sido muito divertido. Então, eu tenho cavado em um monte de montagem da web recentemente. E isso tem sido legal.

Drew McLellan: É engraçado, não é? Quando surge uma tecnologia que transforma tudo o que você sabe em sua cabeça. Sempre dissemos que na web podemos diminuir as imagens. Mas se temos apenas uma imagem pequena, não podemos torná-la maior. É simplesmente impossível. Mas agora temos tecnologia que, em muitas circunstâncias, pode tornar isso possível. É realmente fascinante.

Drew McLellan: Se você, querido ouvinte, gostaria de ouvir mais de Addie, você pode encontrá-lo no Twitter onde ele é @AddieOsmani e encontrar todos os seus projetos vinculados a AddyOsmani.com. O livro “Image Optimization” está disponível fisicamente e digitalmente na Smashing agora em smashingmagazine.com. Obrigado por se juntar a nós hoje, Addy. Você tem alguma palavra de despedida?

Addy Osmani: Alguma palavra de despedida? Eu tenho uma pequena peculiaridade da história que vou compartilhar com as pessoas. Tim Berners-Lee carregou a primeira imagem na internet em 1992. Não tenho certeza se você consegue adivinhar o que era, mas provavelmente ficará surpreso. Drew, você tem algum palpite?

Drew McLellan: Acho que um gato.

Addy Osmani: Um gato. É um bom palpite, mas não. Isso foi no CERN. E a imagem era na verdade de uma banda chamada Les Horribles Cernettes, que era uma banda pop paródia formada por um bando de funcionários do CERN. E a música que eles fariam é como música doo-wop. E eles cantavam canções de amor sobre colisores e peculiaridades e nitrogênio líquido e antimatéria usando roupas dos anos sessenta, que eu achei simplesmente maravilhosas e aleatórias.