Lista de verificação de desempenho de front-end 2021

O desempenho na web é complicado, não é? Como realmente entendemos onde estamos em desempenho e qual é o nosso gargalo de desempenho? É JavaScript caro, entrega lenta de fontes da web, muitas imagens ou renderização lenta? tudo isso implica em um bom desempenho front-end.

Passamos por trepidação de árvore, pesquisa de escopo, divisão de código e todos os padrões de carregamento complexos (por meio de visualizador cruzado, hidratação progressiva, solicitações ao cliente, HTTP / 3, prestadores de serviço e – meu Deus dos funcionários) Totalmente otimizado?

desempenho

E, o mais importante, por onde começamos a melhorar o desempenho e como construímos uma cultura de desempenho de longo prazo?

No passado, o desempenho era algo secundário. Geralmente adiado até o final do projeto, ele se resume a redução, cascateamento, otimização de ativos e possivelmente alguns pequenos ajustes na configuração do arquivo do servidor. Olhando para trás agora, a situação parece ter mudado muito.

O desempenho não é apenas uma questão técnica: ele afeta tudo, desde a acessibilidade e usabilidade até a otimização do mecanismo de pesquisa e, quando é incorporado ao fluxo de trabalho, as decisões de design devem ser informadas de acordo com suas implicações de desempenho.

O desempenho deve ser medido, monitorado e melhorado continuamente, e a complexidade da rede continua aumentando, trazendo novos desafios, dificultando o rastreamento de indicadores, pois os dados variam de acordo com dispositivo, navegador, protocolo, tipo de rede e latência (CDN, ISP, cache, proxy, firewall, balanceador de carga e servidor, todos desempenham um papel no desempenho.

Portanto, se criarmos uma visão geral, o que devemos ter em mente ao melhorar o desempenho (desde o início do projeto até o lançamento final do site)?

Abaixo, você encontrará uma lista de desempenho de front-end para 2021 (esperançosamente e objetivamente) – talvez seja necessário considerar uma visão geral atualizada dos problemas para garantir tempos de resposta rápidos, interações suaves do usuário e seu site não consome a largura de banda dos usuários.

Preparação: Planejamento E Métricas

Aumentando o desempenho.

A micro-otimização é muito importante para manter o desempenho sob controle, mas é importante ter em mente metas claramente definidas (metas mensuráveis ​​influenciarão qualquer tomada de decisão ao longo do processo). Existem vários modelos diferentes, e os modelos discutidos abaixo fazem sentido – certifique-se de priorizar a si mesmo desde o início.

Estabeleça uma cultura de desempenho.

Em muitas organizações, os desenvolvedores de front-end sabem exatamente quais são os problemas potenciais comuns e quais estratégias devem ser usadas para resolvê-los.

No entanto, enquanto não houver reconhecimento de uma cultura de desempenho, cada decisão se torna um campo de batalha departamental, dividindo a organização em várias ilhas.

Você precisa do envolvimento das partes interessadas da empresa e, para atingir esse objetivo, precisa construir um estudo de caso ou uma prova de conceito para a velocidade (especialmente Core Web Vitals, que descreveremos em detalhes posteriormente), velocidade de receita e indicadores-chave. Os indicadores de desempenho (KPIs) com os quais eles se preocupam.

Se não houver uma forte cooperação entre a equipe de desenvolvimento / design e a equipe de negócios / marketing, o desempenho não será sustentável a longo prazo.

Pesquise as reclamações comuns que chegam ao atendimento ao cliente e à equipe de vendas, analise a análise da alta taxa de rejeição e da taxa de conversão em declínio.

Explore como melhorar o desempenho pode ajudar a aliviar alguns desses problemas comuns. Ajuste os parâmetros de acordo com o grupo de partes interessadas que deseja discutir.

Realize experimentos de desempenho e avalie os resultados em dispositivos móveis e computadores desktop (por exemplo, usando o Google Analytics). Isso o ajudará a construir um estudo de caso personalizado para sua empresa usando dados reais.

Além disso, o uso de dados de estudos de caso e experimentos publicados no WPO Stats ajudará a aumentar a sensibilidade da empresa sobre por que o desempenho é tão importante e seu impacto na experiência do usuário e nas métricas de negócios.

Não é suficiente determinar que o desempenho em si é importante – você também precisa estabelecer algumas metas mensuráveis ​​e rastreáveis ​​e observá-las ao longo do tempo.

Objetivo: ser pelo menos 20% mais rápido que seu concorrente mais rápido.

De acordo com pesquisas psicológicas, se você deseja que os usuários sintam que seu site é mais rápido do que os sites de seus concorrentes, você precisa ser pelo menos 20% mais rápido.

Pesquise seus principais concorrentes, colete suas métricas de desempenho em dispositivos móveis e desktops e defina limites para ajudá-lo a vencer a concorrência.

No entanto, para obter resultados e metas precisos, você deve primeiro compreender a experiência do usuário por meio de pesquisa e análise. Em seguida, você pode simular o experimento do 90º percentil para teste.

Para causar uma boa primeira impressão sobre o desempenho de seus concorrentes, você pode usar os relatórios do Chrome UX (CrUX, conjunto de dados RUM pronto, introdução em vídeo escrita por Ilya Grigorik e guia detalhado escrito por Rick Viscomi) ou Treo (ferramenta de monitoramento)

Os relatórios do Chrome UX são compatíveis com RUMs. Os dados são coletados dos usuários do navegador Chrome, então os relatórios serão específicos para o navegador Chrome, mas eles fornecerão uma alocação de desempenho bastante completa para uma ampla gama de visitantes, mais importante a pontuação Core Web Vitals.

Observe que o novo conjunto de dados CrUX é lançado na segunda terça-feira de cada mês.

Se você usar a API Page Speed ​​Insights ou a API Page Speed ​​Insights (não, não está desatualizada!), Você pode obter dados de desempenho CrUX para páginas específicas, não apenas agregados.

Esses dados podem ser mais úteis para definir metas de desempenho para “páginas de destino” ou “listas de produtos” de ativos. E, se você usar CI para testar seu orçamento, se você usar CrUX para definir metas, você precisa ter certeza de que seu ambiente de teste corresponde a CrUX (graças a Patrick Meenan!).

Se você precisar de ajuda para mostrar os motivos por trás da prioridade de velocidade, ou quiser ver onde a velocidade está lenta, ou o desempenho está lento, ou se precisar defender a solução RUM em sua organização, Sergey Chernyshev pode criar uma calculadora UX Speed, uma ferramenta de código aberto, Pode ajudar a simular dados e visualizá-los para orientar seu ponto de vista.

Às vezes, você pode querer ir um pouco mais fundo e combinar os dados CrUX com quaisquer outros dados que você já tenha para encontrar rapidamente quedas de velocidade, pontos cegos e ineficiências para usar para seus concorrentes ou projetos.

Em seu trabalho, Harry Roberts usou uma planilha de terreno de velocidade do site, que ele usou para dividir o desempenho em vários tipos de páginas principais e rastrear diferentes métricas principais entre as páginas principais. Você pode baixar a planilha como uma planilha do Google, Excel, OpenOffice ou documento CSV.

Colete dados, monte planilhas, economize 20% e estabeleça metas (orçamento de desempenho) desta forma.

Agora você pode testar algumas coisas. Se você mantiver seu orçamento em mente e tentar enviar apenas a menor carga útil para um tempo de interação rápido, você estará no caminho certo.

Depois de definir o orçamento, combine-o com Webpack Performance Hints and Bundlesize, Lighthouse CI, PWMetrics ou Sitespeed CI no processo de construção para aplicar solicitações de extração de orçamento e fornecer histórico de pontuação para comentários de RP.

A consciência de desempenho não deve vir apenas do orçamento de desempenho. Assim como no Pinterest, você pode criar uma regra eslint personalizada que proíba a importação de arquivos e diretórios que são conhecidos por serem muito relevantes, aumentando assim os pacotes. Configure uma lista de pacotes “seguros” que podem ser compartilhados por toda a equipe.

Além disso, considere as principais tarefas do cliente que são mais benéficas para o seu negócio. Pesquise, discuta e estabeleça limites de tempo aceitáveis ​​para as principais operações e estabeleça um carimbo de data / hora do usuário “pronto para UX” aprovado para toda a organização.

Em muitos casos, a jornada do usuário afetará o trabalho de muitos departamentos diferentes, portanto, o ajuste para um tempo aceitável ajudará a apoiar ou evitar futuras discussões sobre desempenho. Garanta visibilidade e compreensão dos recursos e custos adicionais dos recursos agregados.

Alinhe os esforços de desempenho com outras iniciativas tecnológicas, desde novos recursos de produto desenvolvidos para refatoração até atrair novos públicos globais. Portanto, sempre que há um diálogo sobre o desenvolvimento, a performance também faz parte do diálogo. Quando a base de código é nova ou acaba de ser refatorada, é muito mais fácil atingir as metas de desempenho.

Além disso, como Patrick Meenan sugeriu, vale a pena planejar uma série de carregamento e compensação durante o processo de design.

Se você priorizar as peças mais críticas e definir a ordem em que devem ser exibidas, também saberá o que pode ser atrasado.

Essa ordem também reflete a ordem das importações de CSS e JavaScript, portanto, será mais fácil de manipular durante o processo de construção. Além disso, considere a experiência visual de estar em um estado “intermediário” quando a página é carregada (por exemplo, quando a fonte da web ainda não foi carregada).

Depois de estabelecer uma forte cultura de desempenho em sua organização, tente torná-la 20% mais rápida do que antes para garantir que as prioridades permaneçam intactas ao longo do tempo (obrigado Guy Podjarny!). No entanto, considere os diferentes tipos e comportamentos de uso dos clientes (Tobias Baldauf denomina cadência e similares), bem como o tráfego de robôs e os efeitos sazonais.

Planeje, planeje, planeje. Pode ser tentador fazer alguma otimização rápida de “frutos do mar” o mais cedo possível – pode ser uma boa estratégia para lucro rápido – mas sem planos e definições da empresa realistas – personalizar metas de desempenho, será muito difícil priorizar o desempenho.

Escolha as métricas certas.

Nem todos os indicadores são igualmente importantes. Investigue quais métricas são mais importantes para o seu aplicativo: elas geralmente são definidas pela velocidade em que você pode começar a renderizar os pixels mais importantes na interface e a velocidade na qual você pode fornecer respostas de entrada para os pixels renderizados.

Esse conhecimento fornecerá as melhores metas de otimização para seus esforços contínuos.

No final, o que determina a experiência não é o evento de carregamento ou o tempo de resposta do servidor, mas a percepção de quão rápida a interface parece.

O que isto significa? Não é necessário focar no tempo de carregamento de toda a página (por exemplo, por meio do tempo onLoad e DOMContentLoaded), mas priorizar o carregamento da página de acordo com a percepção do cliente. Isso significa focar em um conjunto ligeiramente diferente de indicadores. Na verdade, escolher o indicador certo é um processo em que não existe um vencedor claro.

Segundo a pesquisa de Tim Kadlec e as notas de Marcos Iglesias em sua fala, os indicadores tradicionais podem ser divididos em vários grupos. Geralmente, precisaremos de todas essas ferramentas para obter uma descrição completa do desempenho e, em sua situação particular, algumas delas serão mais importantes do que outras.

As métricas baseadas em quantidade medem o número de solicitações, pesos e pontuações de desempenho. Ótimo para definir alertas e monitorar mudanças ao longo do tempo, mas não para entender a experiência do usuário.

Os indicadores de marcos usam o estado durante a vida do processo de carregamento, por exemplo, o tempo do primeiro byte e o tempo da interação. Ótimo para descrever a experiência do usuário e monitoramento, mas não para compreender a situação entre marcos.

O índice de renderização fornece uma estimativa da velocidade de renderização do conteúdo (por exemplo, hora de início da renderização, índice de velocidade). É adequado para medir e ajustar o desempenho de renderização, mas não para medir quando um conteúdo importante aparece e pode interagir com ele.

Métricas personalizadas podem medir eventos específicos para usuários, como a primeira postagem do Twitter e o PinnerWaitTime do Pinterest. Isso ajuda a descrever com precisão a experiência do usuário e não é adequado para dimensionar métricas e comparar com concorrentes.

Para completar o quadro, normalmente procuramos métricas úteis entre todos esses grupos. Normalmente, os mais específicos e relevantes são:

O layout é estável, as principais fontes da web são visíveis e o thread principal disponível é suficiente para processar a entrada do usuário – basicamente um carimbo de data / hora em que o usuário pode interagir com a IU. Entenda o principal indicador de quanto tempo os usuários estão esperando para usar o site sem demora. Boris Schapira escreveu um artigo detalhado sobre como medir o TTI de maneira confiável.

O momento em que o usuário interage pela primeira vez com seu site até quando o navegador pode realmente responder a essa interação. Complementa bem o TTI porque descreve a parte que faltava na imagem: o que acontece quando o usuário realmente interage com o site.

É apenas um indicador de RUM. Existe uma biblioteca JavaScript para medir o FID no navegador.

Marque os pontos de tempo na linha do tempo de carregamento da página onde o conteúdo importante da página pode ser carregado. Suponha que o elemento mais importante da página seja o maior elemento visível na janela de visualização do usuário. Se o elemento for renderizado acima e abaixo da dobra, apenas a parte visível será considerada relevante.

Uma métrica que ajuda a quantificar a gravidade do estado não interativo da página antes que ela se torne interativa de maneira confiável (ou seja, o thread principal não executou uma tarefa por pelo menos 50 milissegundos (tarefas longas) por pelo menos 5 segundos).

A métrica mede o tempo total desde o primeiro desenho até o tempo de interação (TTI), durante o qual o encadeamento principal é bloqueado por tempo suficiente para evitar respostas de entrada. Portanto, não é surpreendente que um baixo TBT seja um bom indicador de bom desempenho. (Obrigado Artem, Phil)

Este indicador destaca a frequência de alterações inesperadas de layout (refluxos) quando os usuários visitam o site. Ele examina os fatores instáveis ​​e seu impacto na experiência geral. Quanto menor a pontuação, melhor.

Meça a velocidade de preenchimento visual do conteúdo da página; quanto menor a pontuação, melhor. A pontuação do índice de velocidade é calculada com base na velocidade do progresso visual, mas este é apenas um valor calculado. Também é sensível ao tamanho da janela de visualização, portanto, você precisa definir várias configurações de teste que correspondam ao seu público-alvo. Observe que conforme o LCP se torna um indicador mais relevante, ele se torna cada vez menos importante (graças a Boris e Artem!).

Um indicador que mostra com que frequência e quando o thread principal é bloqueado, usado para pintura, renderização, script e carregamento. O alto tempo de CPU é uma indicação clara de uma experiência instável, ou seja, quando os usuários experimentam um atraso significativo entre suas operações e respostas. Com WebPageTest, você pode selecionar “Capture Dev Tools Timeline” na guia “Chrome” para expor a divisão do thread principal, já que o thread é executado em qualquer dispositivo que usa WebPageTest.

Assim como o tempo gasto da CPU, este indicador foi proposto por Stoyan Stefanov para explorar o impacto do JavaScript na CPU. A ideia é usar as instruções da CPU para contar por componente para entender seu impacto na experiência geral de forma isolada. Isso pode ser feito usando Puppeteer e Chrome.

Embora muitas das métricas descritas acima indiquem quando um evento específico ocorreu, o FrustrationIndex de Tim Vereecke verifica as lacunas entre as métricas, em vez de verificá-las individualmente.

Ele analisa os principais marcos percebidos pelo usuário final, como “Título visível”, “Primeiro conteúdo visível”, “Visual pronto” e “A página parece pronta”, e calcula uma pontuação que indica o quão frustrada a página está quando carrega.

Quanto maior a lacuna, maior a chance de frustração do usuário. Potencialmente, um bom KPI pode trazer a experiência do usuário. Tim postou um artigo detalhado sobre FrustrationIndex e como ele funciona.

Como o engenheiro da Wikipedia apontou, os dados sobre o quanto os resultados mudaram podem dizer a você sobre a confiabilidade do instrumento e a importância que deve ser dada aos desvios e outliers. Grandes diferenças indicam que a configuração deve ser ajustada.

Também ajuda a entender se certas páginas são mais difíceis de medir de forma confiável, por exemplo, devido a grandes mudanças causadas por scripts de terceiros. Também é uma boa ideia rastrear a versão do navegador para entender os ganhos de desempenho quando uma nova versão do navegador é lançada.

Definido por suas necessidades de negócios e experiência do cliente. Exige que você identifique pixels importantes, scripts principais, CSS necessários e ativos relacionados e meça a rapidez com que são entregues aos usuários.

Para fazer isso, você pode monitorar o Hero Rendering Times ou usar a API Performance para marcar carimbos de data / hora específicos para eventos que são importantes para seu negócio. Além disso, você pode usar o WebPagetest para coletar métricas personalizadas, executando JavaScript arbitrário no final do teste.

Observe que “Primeira pintura importante (FMP)” não aparece na visão geral acima. É usado para obter informações sobre a velocidade com que o servidor gera dados. FMP longo geralmente significa que o JavaScript está bloqueando o thread principal, mas também pode estar relacionado a problemas de backend / servidor.

No entanto, este indicador foi descontinuado recentemente porque parece ser impreciso em aproximadamente 20% dos casos. Ele foi efetivamente substituído pelo LCP mais confiável e fácil de entender.

Não é mais compatível com o Lighthouse. Verifique novamente os indicadores e recomendações de desempenho centrados no usuário mais recentes para ter certeza de que está em uma página segura (graças a Patrick Meenan).

Steve Souders explicou muitos desses indicadores em detalhes. É importante observar que, embora o tempo de interação seja medido pela execução de uma auditoria automatizada em um ambiente de laboratório, o primeiro atraso de entrada representa a experiência real do usuário, enquanto o usuário real experimentou um atraso significativo. Em geral, pode ser uma boa ideia sempre medir e rastrear ambos.

Dependendo do contexto de seu aplicativo, as métricas preferidas podem variar: por exemplo, para a interface do usuário do Netflix TV, a resposta de entrada principal, o uso de memória e TTI são mais críticos, enquanto para a Wikipedia, a primeira / última mudança visual e o O tempo gasto da CPU é mais importante.

Meça e otimize o Core Web Vitals .

Por um longo tempo, os indicadores de desempenho são muito técnicos, com foco em como o servidor responde rapidamente e carrega a visão de engenharia do navegador.

Com o passar dos anos, as métricas mudaram, tentando encontrar uma maneira de capturar a experiência real do usuário em vez do tempo do servidor. Em maio de 2020, o Google anunciou Core Web Vitals, um conjunto de novos indicadores de desempenho centrados no usuário, cada um dos quais representa um aspecto diferente da experiência do usuário.

Para cada um deles, o Google recomenda algumas metas de velocidade aceitáveis. Pelo menos 75% de todas as visualizações de página devem estar fora da faixa adequada para passar nesta avaliação.

Essas métricas se desenvolveram rapidamente e, à medida que Core Web Vitals se tornou um sinal de classificação para a pesquisa do Google em maio de 2021 (uma atualização do algoritmo de classificação da Experiência da Página), muitas empresas voltaram sua atenção para suas pontuações de desempenho.

Dividiremos cada ponto principal da Web um por um e combinaremos tecnologias e ferramentas úteis para considerar esses indicadores e otimizar sua experiência. (Deve-se observar que seguindo as recomendações gerais neste artigo, você terminará com uma pontuação mais alta para Core Web Vitals.)

Meça o carregamento da página e relate o tempo de renderização da maior imagem ou bloco de texto visível na janela de visualização.

Para aprender mais, faça uma consultoria com a b20.

Gostou desse post ?

Compartilhar no facebook
Share on Facebook
Compartilhar no twitter
Share on Twitter
Compartilhar no linkedin
Share on Linkdin
Compartilhar no pinterest
Share on Pinterest

Deixe um comentário