Carregamento lento no nível do navegador para CMSs

Aprendizados para adotar o atributo de carregamento padronizado

Felix Arntz

Meu objetivo com esta postagem é convencer os desenvolvedores e colaboradores de plataformas de CMS (ou seja, as pessoas que desenvolvem os núcleos de CMS) de que agora é o momento de implementar o suporte ao recurso de carregamento lento de imagens no navegador. Também vou compartilhar recomendações sobre como garantir experiências do usuário de alta qualidade e permitir a personalização por outros desenvolvedores ao implementar o carregamento lento. Essas diretrizes vêm da nossa experiência em adicionar suporte ao WordPress e ajudar o Joomla, o Drupal e o TYPO3 a implementar o recurso.

Seja você um desenvolvedor de plataforma de CMS ou um usuário de CMS (ou seja, uma pessoa que cria sites com um CMS), use esta postagem para saber mais sobre os benefícios do carregamento lento no nível do navegador no seu CMS. Confira a seção Próximas etapas para ver sugestões de como incentivar sua plataforma de CMS a implementar o carregamento lento.

Contexto

No ano passado, o carregamento lento de imagens e iframes usando o atributo loading passou a fazer parte do padrão HTML do WHATWG e foi adotado por vários navegadores. No entanto, esses marcos apenas estabelecem as bases para uma Web mais rápida e que economiza mais recursos. Agora, cabe ao ecossistema da Web distribuída usar o atributo loading.

Os sistemas de gerenciamento de conteúdo alimentam cerca de 60% dos sites. Por isso, essas plataformas desempenham um papel fundamental na adoção de recursos de navegadores mais recentes na Web. Com alguns CMSs de código aberto conhecidos, como WordPress, Joomla e TYPO3, que já implementaram suporte ao atributo loading em imagens, vamos dar uma olhada nas abordagens e nas conclusões que são relevantes para adotar o recurso em outras plataformas de CMS também. O carregamento lento de mídia é um recurso importante de desempenho da Web que os sites devem aproveitar em grande escala. Por isso, é recomendável adotá-lo no nível principal do CMS.

Por que implementar o carregamento lento agora

Padronização

A adoção de recursos de navegador não padronizados em CMSs facilita testes generalizados e pode revelar possíveis áreas de melhoria. No entanto, o consenso geral entre os CMSs é que, enquanto um recurso do navegador não for padronizado, ele deve ser implementado como uma extensão ou um plug-in para a respectiva plataforma. Somente após a padronização, um recurso pode ser considerado para adoção no núcleo da plataforma.

Sucesso : o carregamento lento no navegador agora faz parte do padrão HTML do WHATWG para os elementos img e iframe.

Suporte ao navegador

O suporte do navegador ao recurso é uma preocupação semelhante: a maioria dos usuários do CMS precisa se beneficiar do recurso. Se houver uma porcentagem considerável de navegadores em que o recurso ainda não é compatível, ele precisa garantir que, pelo menos, não tenha efeitos adversos para eles.

Sucesso : o carregamento lento no nível do navegador é amplamente aceito pelos navegadores, e o atributo loading é simplesmente ignorado por aqueles que ainda não o adotaram.

Limites de distância da janela de visualização

Uma preocupação comum com as implementações de carregamento lento é que, em princípio, elas aumentam a probabilidade de uma imagem não ser carregada quando se torna visível na janela de visualização do usuário, porque o ciclo de carregamento começa em um estágio posterior. Ao contrário das soluções anteriores baseadas em JavaScript, os navegadores abordam isso de forma conservadora e podem ajustar a abordagem com base em dados reais da experiência do usuário, minimizando o impacto. Assim, o carregamento lento no nível do navegador deve ser seguro para adoção por plataformas de CMS.

Sucesso : experimentos usando o Chrome no Android indicaram que, em redes 4G, 97,5% das imagens com lazy loading abaixo da dobra foram totalmente carregadas em até 10 ms após ficarem visíveis, em comparação com 97,6% das imagens sem lazy loading. Em outras palavras, praticamente não houve diferença (0,1%) na experiência do usuário entre as imagens carregadas de forma antecipada e as carregadas de forma lenta.

Recomendações de experiência do usuário

Exigir atributos de dimensão em elementos

Para evitar mudanças de layout, há muito tempo recomendamos que conteúdos incorporados, como imagens ou iframes, sempre incluam os atributos de dimensão width e height, para que o navegador possa inferir a proporção desses elementos antes de carregá-los. Essa recomendação é relevante se um elemento está sendo carregado lentamente ou não. No entanto, devido à probabilidade 0,1% maior de uma imagem não ser totalmente carregada uma vez na janela de visualização, ela se torna um pouco mais aplicável com o carregamento lento.

Os CMSs devem fornecer atributos de dimensão em todas as imagens e iframes. Se isso não for possível para todos os elementos, recomendamos pular o carregamento lento de imagens que não fornecem esses dois atributos.

Atenção : se o CMS não puder fornecer os atributos width e height em imagens e iframes em grande escala, você precisará avaliar as vantagens e desvantagens entre economizar recursos de rede adicionais e uma chance um pouco maior de mudanças de layout para decidir se o carregamento lento vale a pena.

Evite o carregamento lento de elementos acima da dobra

No momento, recomendamos que os CMSs adicionem atributos loading="lazy" apenas a imagens e iframes posicionados abaixo da dobra para evitar um atraso na métrica Largest Contentful Paint, que, em alguns casos, pode ser significativo, conforme descoberto em julho de 2021. No entanto, é preciso reconhecer que é complexo avaliar a posição de um elemento em relação à janela de visualização antes do processo de renderização. Isso se aplica especialmente se o CMS usa uma abordagem automatizada para adicionar atributos loading, mas mesmo com base na intervenção manual, vários fatores, como os diferentes tamanhos de janela de visualização e proporções, precisam ser considerados. Ainda assim, é altamente recomendável omitir imagens principais e outras imagens ou iframes que provavelmente vão aparecer acima da dobra do carregamento lento.

Observação : dependendo dos recursos e do público do CMS, tente definir estimativas razoáveis para saber se uma imagem ou um iframe provavelmente estará na janela de visualização inicial. Por exemplo, nunca use o carregamento lento em elementos de um modelo de cabeçalho ou na imagem principal do conteúdo principal. Além disso, ofereça uma interface ou API que permita modificar a existência do atributo loading nos elementos.

Evitar um substituto de JavaScript

Embora o JavaScript possa ser usado para fornecer carregamento lento para navegadores que (ainda) não são compatíveis com o atributo loading, esses mecanismos sempre dependem da remoção inicial do atributo src de uma imagem ou iframe, o que causa um atraso para os navegadores que são compatíveis com o atributo. Além disso, implementar uma solução baseada em JavaScript nos front-ends de um CMS de grande escala aumenta a área de superfície para possíveis problemas, o que é parte do motivo pelo qual nenhum CMS importante havia adotado o carregamento lento em seu núcleo antes do recurso padronizado do navegador.

Atenção : evite fornecer um substituto baseado em JavaScript no CMS. Com a crescente adoção do atributo loading e sem efeitos adversos nas versões de navegador que ainda não o aceitam, é mais seguro não fornecer o recurso a esses navegadores e, em vez disso, incentivar a atualização para uma versão mais recente.

Recomendações técnicas

Ativar o carregamento lento por padrão

A recomendação geral para CMSs que implementam o carregamento lento no navegador é ativá-lo por padrão, ou seja, loading="lazy" precisa ser adicionado a imagens e iframes, de preferência apenas para os elementos que incluem atributos de dimensão. Ativar o recurso por padrão resulta em uma economia maior de recursos de rede do que se ele tivesse que ser ativado manualmente, por exemplo, para cada imagem.

Sempre que possível, loading="lazy" deve ser adicionado apenas a elementos que provavelmente aparecem abaixo da dobra. Embora esse requisito possa ser complexo de implementar para um CMS devido à falta de reconhecimento do lado do cliente e aos vários tamanhos de janela de visualização, recomendamos pelo menos usar heurísticas aproximadas para omitir elementos como imagens principais que provavelmente vão aparecer acima da dobra do carregamento lento.

Permitir modificações por elemento

Embora loading="lazy" deva ser adicionado a imagens e iframes por padrão, é fundamental permitir a omissão do atributo em determinadas imagens, por exemplo, para otimizar a LCP. Se o público do CMS for, em média, considerado mais experiente em tecnologia, esse poderá ser um controle de interface exposto para cada imagem e iframe, permitindo desativar o carregamento lento para esse elemento. Como alternativa ou além disso, uma API pode ser exposta a desenvolvedores terceirizados para que eles possam fazer mudanças semelhantes por meio de código.

O WordPress, por exemplo, permite pular o atributo loading para uma tag HTML ou contexto inteiro ou para um elemento HTML específico no conteúdo.

Atenção : se um elemento não precisar ser carregado de forma lenta, exija ou incentive que o atributo loading seja ignorado. Embora o uso de loading="eager" seja uma alternativa compatível, isso informaria explicitamente ao navegador para sempre carregar a imagem imediatamente, o que impediria possíveis benefícios se os navegadores implementassem mais mecanismos e heurísticas para decidir automaticamente quais elementos carregar de forma lenta.

Adaptar o conteúdo atual

De modo geral, há duas abordagens para adicionar o atributo loading a elementos HTML em um CMS:

• Adicione o atributo no editor de conteúdo no back-end, salvando-o de forma persistente no banco de dados.
• Adicione o atributo imediatamente ao renderizar o conteúdo do banco de dados no front-end.

É recomendável que os CMSs adicionem o atributo dinamicamente durante a renderização para que os benefícios do carregamento lento também sejam aplicados ao conteúdo atual. Se o atributo só pudesse ser adicionado pelo editor, apenas as partes novas ou modificadas recentemente do conteúdo receberiam os benefícios, reduzindo drasticamente o impacto do CMS na economia de recursos de rede. Além disso, adicionar o atributo em tempo real vai permitir modificações futuras com facilidade, caso os recursos de carregamento lento no navegador sejam expandidos.

No entanto, a adição do atributo em tempo real precisa atender a um atributo loading potencialmente existente em um elemento e permitir que esse atributo tenha prioridade. Dessa forma, o CMS ou uma extensão dele também pode implementar a abordagem orientada pelo editor sem causar um conflito com atributos duplicados.

Otimizar o desempenho do lado do servidor

Ao adicionar o atributo loading ao conteúdo em tempo real usando, por exemplo, um middleware do lado do servidor, a velocidade é um fator importante. Dependendo do CMS, o atributo pode ser adicionado por meio de travessia de DOM ou expressões regulares, sendo que a última é recomendada para performance.

O uso de expressões regulares precisa ser mínimo, por exemplo, uma única regex que coleta todas as tags img e iframe no conteúdo, incluindo os atributos, e adiciona o atributo loading a cada string de tag, conforme aplicável. O WordPress, por exemplo, tem uma única expressão regular geral para realizar várias operações em tempo real em determinados elementos, em que a adição de loading="lazy" é apenas uma, usando uma única expressão regular para facilitar vários recursos. Além disso, essa forma de otimização é outro motivo pelo qual a adoção do carregamento lento no núcleo de um CMS é recomendada em vez de uma extensão, já que permite uma melhor otimização de desempenho do lado do servidor.

Próximas etapas

Verifique se há um tíquete de solicitação de recurso para adicionar suporte ao recurso no seu CMS ou abra um novo, se ainda não houver. Use referências a esta postagem conforme necessário para apoiar sua proposta.

Envie um tweet para mim (felixarntz@) se tiver dúvidas ou comentários ou para listar seu CMS nesta página se o suporte ao carregamento lento no navegador tiver sido adicionado. Se você encontrar outros desafios, também quero saber mais sobre eles para encontrar uma solução.

Se você é desenvolvedor de uma plataforma de CMS, estude como outros CMSs implementaram o carregamento lento:

• WordPress Core
• Joomla
• TYPO3

Você pode usar os aprendizados da sua pesquisa e as recomendações técnicas desta postagem para começar a contribuir com o código do seu CMS, por exemplo, na forma de um patch ou uma solicitação de pull.