O que é renderização progressiva?

A renderização progressiva apresenta partes utilizáveis ou versões cada vez mais completas do conteúdo à medida que os dados ficam disponíveis. Ela evita reter o resultado inteiro até que todos os recursos ou etapas de processamento tenham sido concluídos.

A renderização progressiva é uma estratégia que abrange codificação, transporte, análise e apresentação; não é um formato de mídia específico. No nível do arquivo, um JPEG progressivo armazena a imagem como uma série de varreduras de qualidade crescente, de modo que um decodificador pode exibir uma versão de baixa qualidade da imagem inteira a partir da primeira varredura e refiná-la à medida que outras chegam, e um PNG entrelaçado transmite seus pixels em sete passagens. No nível do documento, um servidor pode transmitir HTML em fluxo para que o navegador exiba a estrutura externa da página e marcadores de posição enquanto as seções mais lentas ainda estão sendo produzidas; por exemplo, o renderizador do React no servidor com transmissão em fluxo envia primeiro o conteúdo alternativo de um limite <Suspense> e depois o conteúdo real. Os dois níveis lidam com esperas diferentes: a decomposição de Largest Contentful Paint feita pelo web.dev considera o tempo até o primeiro byte do documento HTML e o tempo para carregar o próprio recurso de imagem como subpartes separadas. Portanto, enviar o documento mais cedo não reduz a duração do download de uma imagem referenciada por ele, embora o navegador possa iniciar esse download mais cedo quando o HTML que chega antecipadamente já contém a URL da imagem. Nos dois casos, o resultado antecipado só ajuda se realmente chegar à tela mais cedo; reservar espaço para o resultado final evita que a substituição desloque o layout ao redor.

Quais formatos de imagem podem ser renderizados progressivamente? JPEG quando codificado no modo progressivo, PNG e GIF quando entrelaçados e JPEG XL, embora a MDN observe que o Safari renderiza JPEG XL somente após o download completo. O WebP não consegue refinar uma prévia da imagem inteira: as perguntas frequentes sobre WebP do Google informam que ele não oferece atualização progressiva ou entrelaçada no sentido usado para JPEG ou PNG, apenas decodificação incremental que exibe linhas à medida que seus bytes chegam. O AVIF depende da codificação e do visualizador. A especificação do AVIF oferece suporte à decodificação progressiva por meio de imagens em camadas, mas deixa o renderizador livre para exibir apenas a camada mais alta; o avifenc da libavif produz esse tipo de arquivo com --progressive, e o registro de alterações da libavif cita o Chrome como um visualizador que renderiza as camadas progressivamente. O guia de formatos da MDN, por outro lado, afirma que o AVIF não oferece suporte à renderização progressiva e que os arquivos precisam ser baixados por completo antes da exibição, acrescentando que o tamanho menor dos arquivos AVIF costuma compensar essa limitação, exceto no caso de arquivos maiores. Portanto, converter para WebP ou AVIF não preserva, por si só, o efeito de exibir primeiro uma versão de baixa qualidade: para AVIF, verifique a configuração do codificador e os navegadores de destino; caso contrário, um marcador de posição separado precisa fornecer esse efeito.
Qual é o custo de um JPEG progressivo? Principalmente trabalho de decodificação, não tamanho de arquivo. A documentação da libjpeg informa que os arquivos progressivos costumam ser um pouco menores que os arquivos sequenciais de mesma qualidade e que a imagem final é idêntica. Ela também informa que cada varredura exibida exige aproximadamente o mesmo trabalho de decodificação que uma imagem completa do mesmo tamanho e que as varreduras intermediárias são exibidas apenas se a aplicação usa o modo de imagem em buffer da biblioteca; caso contrário, o decodificador lê todas as varreduras e retorna apenas a imagem final. Assim, ver ou não o refinamento depende do decodificador em uso, não apenas do arquivo.
Por que uma página transmitida em fluxo ainda aparece de uma só vez? Geralmente, algo entre o renderizador e o navegador está retendo os bytes. O nginx armazena em buffer as respostas encaminhadas pelo proxy por padrão e só repassa os dados à medida que são recebidos quando proxy_buffering está desativado ou o servidor upstream envia X-Accel-Buffering: no, um cabeçalho que o nginx pode ser configurado para ignorar com proxy_ignore_headers; o guia de hospedagem própria do Next.js acrescenta que alguns balanceadores de carga na nuvem armazenam respostas em buffer por padrão e que os proxies reversos entre o balanceador de carga e a aplicação também precisam repassar as respostas em blocos sem armazená-las em buffer. A compressão mantém uma janela de dados de saída em buffer para obter boa compressão; o README de compression do Express descreve isso para eventos enviados pelo servidor e fornece res.flush() para forçar o envio da resposta parcialmente comprimida ao cliente. A própria aplicação pode anular o efeito: a documentação do React informa que iniciar o fluxo em onAllReady em vez de onShellReady não oferece carregamento progressivo. Quando os bytes de fato chegam antecipadamente, o CSS ou JavaScript carregados previamente ainda podem bloquear a renderização.
O carregamento progressivo causa deslocamento de layout? Pode causar quando o espaço para o conteúdo que chega depois não está reservado. As orientações do Google sobre Cumulative Layout Shift listam imagens sem dimensões e conteúdo injetado dinamicamente entre as causas mais comuns de uma pontuação ruim e recomendam sempre definir width e height em imagens e vídeos ou reservar o espaço usando aspect-ratio do CSS. Uma imagem que é refinada dentro de uma caixa de tamanho conhecido não desloca nada ao redor; um conteúdo substituto com tamanho diferente do seu marcador de posição pode deslocar o conteúdo ao redor, a menos que um contêiner já reserve o espaço.

Planeje a renderização progressiva quando for possível priorizar conteúdo relevante da página ou da mídia antes de detalhes secundários. Dimensões instáveis ou atualizações mal ordenadas podem, por outro lado, causar deslocamentos de layout e mudanças visuais que distraem.

O Robot /image/resize da Transloadit tem um parâmetro progressive que entrelaça a saída para que os navegadores possam mostrar primeiro uma versão de baixa resolução da imagem inteira; ele fica desativado por padrão. Para formatos aos quais isso não se aplica, um Step que produz uma imagem pode extrair um BlurHash ou ThumbHash por meio de output_meta, como marcador de posição compacto a ser exibido enquanto a imagem completa carrega. Os resultados de imagem no Assembly Status também incluem width, height e aspect_ratio em seus metadados, que são as informações de que uma página precisa para reservar o espaço da imagem antes de ela chegar.

A documentação do Robot informa um aumento no tamanho do arquivo para progressive sem especificar a quais formatos de saída ele se aplica, o que difere do que a documentação da libjpeg diz sobre JPEG progressivo acima. Por isso, meça com suas próprias imagens e seu formato de saída. A extração de ThumbHash está sujeita à cobrança de metadados; consulte a documentação do Robot para conhecer as condições atuais.

Explore os recursos de entrega da Transloadit

O que é renderização progressiva?

Como funciona a renderização progressiva

Informações essenciais

Quando a renderização progressiva é importante

Como a Transloadit ajuda com a renderização progressiva

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional