O recurso mais rápido e melhor otimizado é aquele que não é enviado. Elimine os recursos desnecessários do seu aplicativo. É uma boa prática questionar e revisitar periodicamente as suposições implícitas e explícitas com sua equipe. Veja alguns exemplos:
- Você sempre incluiu o recurso X nas suas páginas. No entanto, o custo de fazer o download e mostrá-lo compensa o valor agregado ao usuário? É possível medir e provar seu valor?
- O recurso (especialmente de terceiros) oferece desempenho consistente? Esse recurso está no caminho crítico, ou precisa estar? Se o recurso estiver no caminho crítico, pode ser um ponto único de falha para o site? Ou seja, se o recurso não estiver disponível, o desempenho e a experiência do usuário das suas páginas serão afetados?
- Este recurso precisa ou tem um SLA? Esse recurso segue as práticas recomendadas de desempenho: compactação, armazenamento em cache etc.?
Muitas vezes, as páginas contêm recursos desnecessários, ou pior, que prejudicam o desempenho da página sem oferecer muito valor ao visitante ou ao site onde ele está hospedado. Isso se aplica igualmente a recursos e widgets próprios e de terceiros:
- O site A decidiu mostrar um carrossel de fotos na página inicial para permitir que o visitante confira várias fotos com um clique rápido. Todas as fotos são carregadas quando a página é carregada, e o usuário avança por elas.
- Pergunta:você mediu quantos usuários visualizam várias fotos no carrossel? Você pode estar gerando uma sobrecarga alta com o download de recursos que a maioria dos visitantes nunca visualiza.
- O site B decidiu instalar um widget de terceiros para exibir conteúdo relacionado, melhorar o envolvimento com redes sociais ou fornecer algum outro serviço.
- Pergunta:você rastreou quantos visitantes usam o widget ou clicam no conteúdo fornecido pelo widget? O engajamento que o widget gera é suficiente para justificar a sobrecarga dele? Além disso, é viável usar uma estratégia de carregamento para garantir que o script não seja carregado até que seja necessário?
Determinar a eliminação ou não de downloads desnecessários muitas vezes requer muita reflexão e medição cuidadosas. Para melhores resultados, faça um inventário e revise periodicamente essas perguntas para cada recurso nas suas páginas.
Efeitos nas Core Web Vitals
O guia "Core Web Vitals" foi apresentado pelo Google para oferecer um conjunto de métricas que refletem a experiência dos usuários na Web. Embora existam muitas estratégias de otimização para as Core Web Vitals, questionar se é preciso carregar determinado recurso em uma página pode ajudar a melhorar essas métricas no seu site. Abaixo estão alguns exemplos, agrupados por cada Core Web Vitals, que valem a pena considerar. Embora esta não seja uma lista completa de exemplos (e haja muitos!), lê-los pode ajudá-lo a refletir.
Maior exibição de conteúdo (LCP)
A Maior exibição de conteúdo (LCP) mede quando o maior conteúdo (por exemplo, uma imagem principal ou um título) é carregado. Ela é considerada uma métrica de percepção importante que dá ao usuário a impressão de que o site está sendo carregado rapidamente.
Em geral, fazer o download de menos recursos significa que a largura de banda que o usuário tem será alocada para menos recursos, o que pode resultar em uma melhoria na LCP. Um exemplo clássico é o do carregamento lento, em que as imagens fora da janela de visualização durante o carregamento da página não serão transferidas até que o navegador determine que o usuário está mais propenso a vê-las. Se você tem uma grande galeria de miniaturas com, digamos, 50 imagens, o carregamento lento de todas, exceto as dez principais significa que o navegador pode fazer um uso mais eficiente da largura de banda disponível, e as primeiras imagens que o usuário verá serão carregadas mais rapidamente.
No entanto, a questão não é apenas carregar menos imagens, necessariamente. O navegador tem um esquema de priorização interna que determina quanta largura de banda cada recurso deve receber. No entanto, mesmo com todos os recursos, especialmente aqueles transferidos por download com prioridade alta, há o potencial de privar um possível recurso dependente de um elemento da LCP. Isso é ainda mais relevante em conexões de rede lentas. Esse recurso dependente pode ser um arquivo de imagem que representa o elemento LCP da página, mas também pode ser um recurso de fonte da Web de que o navegador precisa para renderizar um nó de texto que pode ser determinado como o elemento LCP da página.
Se o site tiver muito texto, talvez o elemento da LCP de uma página seja um nó de texto. Embora existam muitas boas estratégias de otimização e carregamento de fontes, pode valer a pena considerar se uma fonte do sistema é suficiente para as necessidades do seu site. Assim, os elementos LCP, que são nós de texto, podem ser carregados sem dependência de um recurso de fonte da Web e pintados quase imediatamente quando o CSS e o HTML chegam do servidor.
Cumulative Layout Shift (CLS)
Cada recurso que você carrega tem o potencial de contribuir para uma Mudança de layout cumulativa (CLS) de uma página, especialmente se o download não tiver sido concluído no momento da exibição inicial. No caso de imagens, evite práticas de CLS, como definir dimensões explícitas. Para fontes, gerenciar o carregamento e a possível correspondência de fontes substitutas pode minimizar as mudanças durante o período de troca de uma fonte da Web. Para JavaScript, pode ser como o script manipula o DOM para que as mudanças de layout sejam reduzidas a um valor aceitável.
Todo recurso que contribui para a CLS de uma página exige trabalho para garantir que o layout da página seja estável o suficiente. Ao questionar se você precisa ou não de um recurso específico, não está apenas acelerando o carregamento de páginas, mas também reduzindo o esforço cognitivo necessário para preservar a estabilidade do layout. Isso resulta não apenas em uma experiência do usuário muito menos frustrante, mas também em uma experiência do desenvolvedor menos frustrante, já que você terá mais tempo para buscar outras metas em seus projetos.
Interação com a próxima exibição (INP) e a latência na primeira entrada (FID, na sigla em inglês)
Interaction to Next Paint (INP) e Latência na primeira entrada (FID, na sigla em inglês) são métricas que medem a capacidade de resposta às entradas do usuário. Embora o INP esteja previsto para substituir o FID como Core Web Vitals em março de 2024, as estratégias de otimização para FID também tendem a se aplicar a ele. Além disso, o INP é geralmente mais difícil de otimizar do que o FID, porque ele rastreia a latência completa de todas as interações de página, e não apenas o atraso de entrada da primeira interação como medida da FID.
O INP e a FID tendem a ser os mais afetados pelo JavaScript, já que ele é o que impulsiona a maior parte da interatividade na Web. Para INP e FID, a quantidade de recursos de script transferidos por download durante o carregamento da página inicia um trabalho potencialmente caro envolvido na avaliação e compilação de scripts. Quanto menos JavaScript você carregar durante a inicialização, menos trabalho o navegador terá que realizar naquele ponto crítico da experiência na página.
Embora existam estratégias para reduzir o tamanho dos recursos JavaScript transferidos por download durante a inicialização, como divisão de código e tree shaking, vale a pena auditar os pacotes usados nos seus projetos para ver se eles são necessários. Por exemplo, lodash tem muitos métodos que ainda são úteis, mas vem com métodos prontos para uso que o navegador oferece, como funções específicas de Array para mapeamento, redução, filtragem e muitos outros.
O aprimoramento progressivo também é uma abordagem útil em relação ao JavaScript, porque permite oferecer uma experiência básica (mas ainda funcional) aos usuários, que pode ser complementada por usuários com dispositivos mais avançados e conexões de rede mais rápidas. Independentemente de você aderir ou não ao princípio de aprimoramento progressivo, o ponto é o mesmo: todo recurso JavaScript que pode ser evitado pode resultar em uma experiência que responde mais rapidamente às interações do usuário, que é um aspecto vital do desempenho na Web.
Conclusão
Auditar seu site em busca de downloads desnecessários pode ser apenas um aspecto da oferta de experiências do usuário rápidas, mas é aquele com potencial de alto impacto. Recapitulando:
- Faça um inventário de seus próprios recursos e de recursos de terceiros em suas páginas.
- Meça o desempenho de cada recurso: o valor e o desempenho técnico dele.
- Determine se os recursos oferecem valor suficiente.
- Entenda o efeito de downloads desnecessários nas Core Web Vitals e nas métricas de suporte.
Ao otimizar a eficiência do conteúdo dessa forma, você não está apenas melhorando o desempenho geral, também toma cuidado para não desperdiçar a largura de banda dos usuários, além de melhorar as métricas centradas no usuário e proporcionar uma experiência melhor.