Aprendizados para adotar o atributo de carregamento padronizado
Meu objetivo com este post é convencer os desenvolvedores e colaboradores da plataforma de CMS (ou seja, as pessoas que desenvolvem núcleos de CMS) de que agora é o momento de implementar o suporte ao recurso de carregamento lento de imagens no nível do navegador. Também vou compartilhar recomendações sobre como garantir experiências de 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.
Independente de você ser 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 sugestões sobre como incentivar sua plataforma de CMS a implementar o carregamento lento.
Contexto
No último ano,
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 com mais economia de recursos.
Agora, o atributo loading é usado no ecossistema distribuído da Web.
Os sistemas de gerenciamento de conteúdo
alimentam cerca de 60% dos sites,
portanto, essas plataformas desempenham um papel vital na adoção de recursos de navegadores
modernos na Web. Alguns CMSs de código aberto conhecidos, como
WordPress, Joomla e
TYPO3, já
implementaram o suporte ao atributo loading em imagens. Vamos analisar
as abordagens e as conclusões relevantes para adotar o recurso
em outras plataformas de CMS. 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.
O caso para implementar o carregamento lento agora
Padronização
A adoção de recursos de navegador não padronizados em CMSs facilita os testes em grande escala e pode mostrar 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 de preferência na forma de uma extensão ou 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.
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 não tenha efeitos adversos para esses navegadores.
Limites de distância da janela de visualização
Uma preocupação comum com as implementações de carregamento lento é que elas, em princípio, aumentam a probabilidade de uma imagem não ser carregada quando ela fica visível na viewport 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, além disso, podem ajustar a abordagem com base em dados reais de experiência do usuário, minimizando o impacto. Portanto, o carregamento lento no nível do navegador pode ser adotado com segurança por plataformas de CMS.
Recomendações de experiência do usuário
Exigir atributos de dimensão nos elementos
Para evitar mudanças de layout, há uma
recomendação de longa data de 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, independentemente de um elemento
estar sendo carregado de forma lenta ou não. No entanto, devido à
0,1% de probabilidade maior de uma imagem não ser totalmente carregada uma vez na viewport,
o carregamento lento no local se torna um pouco mais aplicável.
Os CMSs devem fornecer atributos de dimensão em todas as imagens e iframes. Se isso não for possível para todos esses elementos, é recomendável pular imagens de carregamento lento que não forneçam esses dois atributos.
Evite o carregamento lento de elementos acima da dobra
No momento, é recomendável que os CMSs adicionem apenas atributos loading="lazy" a
imagens e iframes posicionados abaixo da dobra, para evitar um atraso
na métrica Largest Contentful Paint, que em alguns casos pode ser
significativa , como descoberto em julho de 2021. No entanto, é
importante reconhecer que é complexo avaliar a posição de um elemento
em relação à viewport 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 e proporções
de viewport, precisam ser considerados. Ainda assim, é altamente recomendável omitir imagens principais e outras imagens ou iframes que provavelmente vão aparecer acima da dobra de serem carregadas com lazy load.
Evitar uma substituição do JavaScript
Embora o JavaScript possa ser usado para
fornecer carregamento lento a navegadores que ainda não oferecem suporte ao 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 oferecem suporte ao
atributo. Além disso, o lançamento de uma solução baseada em JavaScript nos
front-ends de um CMS em grande escala aumenta a área de superfície para possíveis problemas,
o que explica por que nenhum CMS importante adotou o carregamento lento no núcleo antes do
recurso do navegador padronizado.
Recomendações técnicas
Ativar o carregamento lento por padrão
A recomendação geral para CMSs que implementam o carregamento lento no nível do navegador é
ativá-lo por padrão. Ou seja, loading="lazy" precisa ser adicionado a imagens e
iframes, de preferência
somente para elementos que incluem atributos de dimensão.
Ativar o recurso por padrão vai resultar em uma economia maior de recursos de rede
do que se ele precisasse ser ativado manualmente, por exemplo, por imagem.
Na medida do possível, o loading="lazy"
só pode ser adicionado a elementos que provavelmente aparecem abaixo da dobra.
Embora esse requisito possa ser complexo de implementar em um CMS devido à falta de consciência do lado do cliente e a vários tamanhos de viewport, é recomendável usar heurísticas aproximadas para omitir elementos, como imagens principais que provavelmente vão aparecer acima da dobra, de serem carregadas de forma lenta.
Permitir modificações por elemento
Embora o loading="lazy" precise ser adicionado a imagens e iframes por padrão, é
importante permitir a omissão do atributo em determinadas imagens, por exemplo, para
otimizar o LCP. Se o público do CMS for, em
média, considerado mais experiente em tecnologia, isso poderá ser um controle de IU exposto para cada
imagem e iframe, permitindo desativar o carregamento lento para esse elemento.
Como alternativa ou complemento, uma API pode ser exposta a desenvolvedores externos
para que eles possam fazer mudanças semelhantes no código.
O WordPress, por exemplo, permite pular o atributo loading para uma
tag ou contexto HTML inteiro
ou para um
elemento HTML específico no conteúdo.
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 dinamicamente ao renderizar conteúdo do banco de dados no front-end.
É recomendável que o CMS opte por adicionar o atributo em tempo real ao renderizar, para trazer os benefícios do carregamento lento a qualquer conteúdo existente. Se o atributo pudesse ser adicionado apenas pelo editor, apenas os conteúdos novos ou modificados recentemente receberiam os benefícios, reduzindo drasticamente o impacto do CMS na economia de recursos de rede. Além disso, adicionar o atributo dinamicamente vai permitir modificações futuras, caso os recursos de carregamento lento no nível do navegador sejam expandidos.
Adicionar o atributo em tempo real precisa atender a um atributo loading
potencialmente existente em um elemento e permitir que esse atributo tenha
precedência. 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 a performance 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 é uma consideração. Dependendo do CMS, o
atributo pode ser adicionado por meio de traversal do DOM ou de expressões regulares, sendo
a última recomendada para performance.
O uso de expressões regulares precisa ser mínimo. Por exemplo, uma única regex
que colete todas as tags img e iframe no conteúdo, incluindo os
atributos, e adicione o atributo loading a cada string de tag, conforme
aplicável. O WordPress, por exemplo, vai até
ter uma única expressão regular geral para realizar várias operações em tempo real em determinados elementos,
sendo 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 é
outra razão pela qual a adoção do carregamento lento no núcleo de um CMS é recomendada em vez de uma
extensão, porque 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@) com perguntas ou comentários ou para incluir seu CMS nesta página se o suporte ao carregamento lento no nível do navegador tiver sido adicionado. Se você encontrar outros desafios, também tenho interesse em saber mais sobre eles para encontrar uma solução.
Se você é um desenvolvedor de plataforma de CMS, estude como outros CMSs implementaram o carregamento lento:
Você pode usar as lições da sua pesquisa e as recomendações técnicas desta postagem para começar a contribuir com código para seu CMS, por exemplo, na forma de patch ou pull-request.
Foto principal de Colin Watts no Unsplash.