Web Performance, Mantendo seu Lighthouse Score 100.

A qualidade da experiência dos sites é crucial para atingir as metas comerciais do seu site e a satisfação de seus visitantes.

O Adobe Experience Manager (AEM) é otimizado para fornecer experiências excelentes e desempenho ideal na Web. Com o Monitoramento de uso real (RUM) coletas de dados de operações, as informações são continuamente coletadas a partir do uso em campo e oferecem uma maneira de iterar em medidas de desempenho de uso real sem precisar esperar que os dados CRuX mostrem os efeitos das alterações de código e implantação. É comum que os dados de campo coletados em RUM se desviem dos resultados do laboratório, já que a rede, a geolocalização e o poder de processamento para dispositivos reais são muito mais diversos do que as condições simuladas em um laboratório.

A variável Serviço Google PageSpeed Insight O é comprovadamente uma excelente ferramenta de medição em laboratório. Ele pode ser usado para evitar a deterioração lenta do desempenho e da pontuação de experiência do seu site.

Se você iniciar seu projeto com a chapa como na Tutorial do desenvolvedor, você obterá uma pontuação muito estável do Lighthouse no PageSpeed Insight para dispositivos móveis e desktops em 100. Em cada componente da pontuação do farol há algum buffer para o código do projeto consumir e ainda estar dentro dos limites de um perfeito 100 pontuação do farol.

Testar suas solicitações de pull

Acontece que é difícil melhorar sua pontuação do Lighthouse uma vez que está baixa, mas não é difícil mantê-lo em 100 se você testar continuamente.

Quando você abre uma solicitação de pull (PR) em um projeto, os URLs de teste na descrição do projeto são usados para executar o serviço do PageSpeed Insights. O bot AEM GitHub falhará automaticamente na sua PR se a pontuação for inferior a 100 com um pouco de buffer para levar em conta alguma volatilidade dos resultados.

Os resultados são para a pontuação do farol móvel, pois tendem a ser mais difíceis de alcançar do que o desktop.

Por que o Google PageSpeed Insights?

Muitas equipes e indivíduos usam suas próprias configurações para medir as pontuações do Lighthouse. Diferentes equipes desenvolveram seus próprios equipamentos de teste e usam suas próprias ferramentas de teste com configurações que foram configuradas como parte de suas práticas de monitoramento contínuo e relatórios de desempenho.

O desempenho de um site afeta suas classificações nos resultados de pesquisa, o que é refletido pelos Web Vitals principais no relatório crUX. O Google tem um excelente controle sobre as combinações médias relevantes de informações do dispositivo (por exemplo, tamanho da tela), bem como sobre o desempenho da rede desses dispositivos. Mas, no final, o SEO é o árbitro definitivo do que é bom ou ruim no desempenho da Web. Como a configuração específica é um destino móvel, as práticas de desempenho devem estar alinhadas aos dispositivos médios atuais e às características da rede globalmente.

Portanto, em vez de usar uma configuração específica do projeto para testes do Lighthouse, usamos as configurações atualizadas continuamente vistas como parte das estratégias de dispositivos móveis e desktop referenciadas nas versões mais recentes do Google API de insights do PageSpeed.

Embora possa haver um insight adicional que alguns desenvolvedores sentem que podem coletar de outras maneiras de medir as pontuações do Lighthouse, para poder ter uma conversa de desempenho significativa e comparável entre os projetos, precisa haver uma maneira de medir o desempenho universalmente. O PageSpeed Insight Service padrão é o teste de laboratório mais autorizado e aceito em termos gerais quando se trata de medir seu desempenho.

No entanto, é importante lembrar que as recomendações que você recebe do PageSpeed Insights não levam necessariamente a melhores resultados, especialmente quanto mais perto você chegar de uma pontuação de farol de 100.

Os Vitais da Web principais (CWV) coletados pela coleção de dados RUM integrada desempenham uma função importante na validação dos resultados. No entanto, para pequenas alterações, a variação dos resultados e a falta de pontos de dados suficientes (tráfego) durante um curto período de tempo tornam impraticável obter resultados estatisticamente relevantes na maioria dos casos.

Carregamento trifásico (E-L-D)

Separar o conteúdo de uma página da Web em três fases o torna relativamente direto para atingir uma pontuação mínima e, portanto, definir uma linha de base para uma ótima experiência do cliente.

A abordagem de carregamento em três fases divide o conteúdo e a execução da página em três fases

Fase E: Ansioso

No ansioso fase, tudo o que precisava ser carregado para o verdadeiro LCP a ser exibido é carregado. Em um projeto, geralmente consiste na marcação, nos estilos CSS e nos arquivos JavaScript.

Em muitos casos, a LCP elemento está contido em um bloco (geralmente criado por bloqueio automático), onde o bloco .js e e .css também devem ser carregadas.

O carregador de bloco exibe seções progressivamente, o que significa que todos os blocos da primeira seção devem ser carregados para o LCP para se tornarem visíveis. Por isso, pode fazer sentido ter uma seção menor contendo o mínimo necessário na parte superior de uma página.

É uma boa regra geral manter a carga agregada antes da variável LCP é exibido abaixo de 100 kb, o que geralmente resulta em uma LCP evento mais rápido que 1560 ms (LCP pontuação em 100 no PSI). Especialmente em dispositivos móveis, a rede tende a ter restrições de largura de banda, alterando assim a sequência de carregamento antes LCP tem impacto mínimo ou inexistente.

Carregamento ou conexão de uma segunda origem antes da LCP é altamente desencorajado ao estabelecer uma segunda conexão (TLS, DNS etc.) adiciona um atraso significativo à LCP.

Fase L: Preguiçosa

No preguiçoso , a parte da carga que não afeta o tempo total de bloqueio (TBT) e, por fim, o primeiro atraso de entrada (FID).

Isso inclui itens como carregar blocos (JavaScript e CSS), bem como carregar todas as imagens restantes de acordo com suas loading="lazy" e outras bibliotecas JavaScript que não estão bloqueando. A fase de preguiça é geralmente tudo o que acontece nos vários blocks você criará para atender às necessidades do projeto.

Nesta fase, seria ainda aconselhável que a maior parte da carga útil venha da mesma origem e seja controlada pela primeira parte, para que possam ser feitas alterações, se necessário, para evitar impacto negativo na TBT, TTI e FID.

Fase D: atrasada

No atrasado , as partes da carga útil são carregadas, não têm impacto imediato na experiência e/ou não são controladas pelo projeto e são provenientes de terceiros. Pense em ferramentas de marketing, gerenciamento de consentimento, análise estendida, módulos de bate-papo/interação etc. que geralmente são implantadas por meio de soluções de gerenciamento de tags.

É importante entender que, para minimizar o impacto na experiência geral do cliente, o início dessa fase precisa ser significativamente atrasado. A fase atrasada deve ser de pelo menos três segundos após o evento de LCP para que haja tempo suficiente para que o restante da experiência seja resolvido.

A fase atrasada é geralmente tratada em delayed.js que serve como uma captura inicial para scripts que causam TBT. Idealmente, a variável TBT os problemas são removidos dos scripts em questão carregando-os fora da thread principal (em um web worker) ou apenas removendo o tempo de bloqueio real do código. Quando os problemas forem corrigidos, essas bibliotecas poderão ser facilmente adicionadas à fase de inatividade e carregadas anteriormente.

Idealmente, não há tempo de bloqueio em seus scripts, o que às vezes é difícil de alcançar quando a tecnologia usada com frequência, como gerenciadores de tags ou ferramentas de criação, cria grandes arquivos JavaScript que são bloqueados enquanto o navegador os analisa. Do ponto de vista do desempenho, é aconselhável remover essas técnicas. Certifique-se de que seus scripts individuais não estejam bloqueando e carregando-os individualmente como arquivos menores separados.

Cabeçalho e Rodapé

O cabeçalho e, especificamente, o rodapé da página não estão no caminho crítico para o LCP, que é o motivo pelo qual são carregados de forma assíncrona em seus respectivos blocos. Geralmente, os recursos que não compartilham o mesmo ciclo de vida (o que significa que são atualizados com alterações de criação em momentos diferentes) devem ser mantidos em documentos separados para tornar a cadeia de armazenamento em cache entre as origens e o navegador mais simples e eficaz. Manter esses recursos separados aumenta as taxas de acerto de cache e reduz a invalidação de cache e a complexidade do gerenciamento de cache.

Fontes

Como as fontes da Web geralmente são uma sobrecarga na largura de banda e carregadas de uma origem diferente por meio de um serviço de fontes como https://fonts.adobe.com ou https://fonts.google.com, é praticamente impossível carregar as fontes antes da variável LCP, por isso geralmente são adicionados ao lazy-styles.css e são carregados após a variável LCP é exibido.

Blocos LCP

Há situações em que as circunstâncias LCP o elemento não está incluído na marcação transmitida ao cliente. Isso acontece quando há uma indireção ou pesquisa (por exemplo, um serviço chamado, um fragmento carregado ou uma pesquisa que precisa ocorrer em um .json) para o LCP elemento.
Nessas situações, é importante que o carregamento da página aguarde adivinhando a LCP candidato (atualmente a primeira imagem na página) até que o primeiro bloco tenha feito as alterações necessárias no DOM.
Para identificar quais blocos devem ser aguardados antes de bloquear para o LCP carregar, é possível adicionar os blocos que contêm a variável LCP elemento para o LCP_BLOCKS matriz em scripts.js.

Bônus: velocidade é verde

Criar sites rápidos, pequenos e de fácil renderização não é apenas uma boa ideia para oferecer experiências excepcionais que convertam melhor, mas também uma boa maneira de reduzir as emissões de carbono.