Prática de construção de monitoramento de desempenho da página inicial do carro

1. Introdução

Focar na experiência do usuário e melhorar o desempenho da página é uma das tarefas diárias de todo aluno de P&D de front-end. Embora não seja fácil medir a ajuda de melhorar o desempenho da página para o negócio, as vantagens devem superar as desvantagens. Como medir o desempenho da página? Como ajudar os alunos de P&D a localizar rapidamente o gargalo do desempenho da página? Sempre foi uma das principais tarefas do front-end. Este artigo compartilha parte do trabalho da Autohome na construção do monitoramento de desempenho da página, que inclui principalmente três aspectos:

Seleção de tecnologia

Quais soluções de tecnologia de monitoramento de desempenho de página devo escolher?
Sob a premissa de não afetar o desempenho da página tanto quanto possível, ele pode não apenas medir o desempenho da página de forma objetiva e abrangente, mas também ajudar os alunos de pesquisa e desenvolvimento a localizar rapidamente o gargalo de desempenho Quais indicadores devem ser coletados?
Como avaliar o desempenho da página não inicial de aplicativos SPA?
Com a premissa de não afetar ao máximo o desempenho da página e garantir a precisão dos dados coletados, coletar e relatar o máximo de dados possível Como escolher o tempo adequado e o método de relatório dos indicadores?

projeto de arquitetura geral

Integre as soluções técnicas selecionadas, crie uma estrutura sistemática de monitoramento de desempenho, forneça uma cadeia de ferramentas de monitoramento e análise de desempenho e apoie os alunos de produção e pesquisa para descobrir e localizar problemas de desempenho de página em cada estágio do DevOps.

Estabeleça um sistema de julgamento

Com dados, podemos medir; com pontuação, a tecnologia pode ser aprimorada.

Usando os indicadores coletados, de acordo com as características do aplicativo, de acordo com a importância de cada indicador de desempenho, defina diferentes linhas de base e pesos e obtenha a pontuação do aplicativo na forma de média ponderada. Por meio da pontuação, diga intuitivamente aos alunos de pesquisa e desenvolvimento se a página do aplicativo é rápida ou lenta? O desempenho do aplicativo é alto ou baixo? Precisa de melhorias?

A pontuação do aplicativo pode refletir apenas o desempenho de um único aplicativo e atende principalmente aos alunos em produção e pesquisa. Uma empresa tem vários departamentos, cada departamento tem várias equipes e uma equipe tem vários aplicativos. Precisamos de pontuações de desempenho nos níveis de empresa, departamento e equipe para que os líderes de todos os níveis possam entender intuitivamente o desempenho da página de suas equipes responsáveis ​​e é conveniente O líder superior julga o nível de desempenho entre as equipes subordinadas, então ainda usamos o algoritmo de média ponderada para obter as pontuações de desempenho da equipe, departamento e empresa de acordo com o número de PV do aplicativo e o nível do aplicativo.

2 Seleção de tecnologia

De acordo com o ambiente operacional ao monitorar o desempenho da página, dividimos as soluções técnicas em dois tipos: Monitoramento Sintético (SYN) e Monitoramento de Usuário Real (RUM).

Monitoramento sintético (doravante denominado SYN)

Refere-se à execução da página no ambiente de simulação para avaliar o desempenho da página. As primeiras ferramentas representativas incluem os conhecidos YSlow e PageSpeed. Conforme a tecnologia avança, as três ferramentas SYN mais maduras são: Lighthouse, WebPageTest e SiteSpeed. Embora o Lighthouse suporte apenas o navegador Chrome e tenha altos custos de implementação, ele tem as vantagens de suporte do Google, fácil expansão, indicadores avançados e pontuação. Ele substituiu gradualmente o WebPageTest e se tornou a ferramenta preferida para SYN. A seguir, o Lighthouse é um exemplo para apresentar o processo de operação, vantagens e desvantagens do SYN.

processo de trabalho

Na página de resultados em execução, além de fornecer os principais valores e pontuações dos indicadores de desempenho, o Lighthouse também nos fornece sugestões de otimização e resultados de diagnóstico. A versão 10.1.0 do Lighthouse possui desempenho 94 e 16 incorporado e especificações ou sugestões de melhores práticas, entre as quais existem muitas especificações mais significativas que são menos notadas na pesquisa e desenvolvimento diários, como: minimizar o trabalho do thread principal (mainthread -work- repartição), a página da web impediu a restauração do cache de ida e volta (bf-cache), reduzindo o JavaScript não utilizado (unused-javascript) no arquivo js, ​​etc.

Recomenda-se usar o Node Cli ou o Node Module para executar o Lighthouse e gerar os resultados nos formatos html e json ao mesmo tempo. Os dados em json são mais abrangentes, incluindo informações detalhadas como: o elemento de pintura de maior conteúdo, tarefas de thread principal de execução longa que devem ser evitadas (tarefas longas), etc.

Vantagens e desvantagens

De acordo com nossa prática, o Lighthouse tem as seguintes vantagens e desvantagens:

Melhorar

Em resposta às deficiências e requisitos do produto acima, fizemos algumas melhorias:

• Para resolver o problema de que o ambiente padrão não é benchmark, a mesma página é executada em diferentes clientes e os resultados são diferentes devido a diferentes ambientes operacionais e recursos de hardware, fizemos duas melhorias:

Primeiro, forneça o ambiente operacional de linha de base SYN. Use o Lighthouse Node Module para autodesenvolver a versão web do serviço SYN e implantá-lo no contêiner. Ao adicionar uma política de fila no lado do servidor Node, é garantido que um único contêiner só pode executar uma tarefa SYN a qualquer momento, e os recursos de hardware (4 núcleos + 4G) e configuração de velocidade de rede de cada contêiner são os mesmos (Aplicativos do lado M usam uniformemente velocidade de rede de 10M), de modo a garantir que os resultados da execução e as pontuações finais sejam relativamente justos e confiáveis.

Em segundo lugar, suporta a execução de tarefas SYN como tarefas agendadas em intervalos de 6, 12 ou 24 horas. Conte os valores AVG e TP dos indicadores de resultado de várias execuções e exclua o desvio de resultado de algumas execuções anormais.

• Visando o problema de rodar devagar e consumir muitos recursos. Acreditamos que na mesma página, se não houver revisão, não há necessidade de continuar testando com muita frequência. É recomendável adicionar uma tarefa agendada para ser executada uma vez a cada 12 horas ou mais para páginas com grande quantidade de PV ou páginas importantes Isso pode não apenas refletir objetivamente o desempenho da página, mas também economizar recursos.
• Integre o SYN ao pipeline de CI e use o SYN como uma ferramenta de implementação para testes de desempenho de página de pré-lançamento ou comparação de produtos concorrentes.

Cena aplicável

• Integre o SYN como uma ferramenta de teste de desempenho de página em aplicativos de back-office de monitoramento de front-end, conjuntos de controle de qualidade e CI. Recomenda-se que os alunos de P&D avaliem o desempenho da página por meio do SYN antes de entregar a página e melhorem os defeitos de qualidade da página e a qualidade da entrega com base em sugestões de otimização e resultados de diagnóstico.
• Use SYN para comparar produtos concorrentes.
• Usando o SYN como ferramenta preferencial para análise de páginas lentas capturadas pelo RUM, combinado com o Chrome DevTools, a maioria dos problemas pode ser localizada na prática.

Instruções

Resumir

SYN tem baixo custo de implementação e é fácil de unificar padrões.Comparado com RUM, é menos afetado pelo ambiente de execução, e os resultados são mais comparáveis ​​e reprodutíveis.É uma parte importante do monitoramento de desempenho. Com base no Lighthouse, com a ajuda do K8S e outras tecnologias de orquestração de contêineres, a criação rápida de um serviço da Web SYN que fornece um ambiente de referência é o primeiro estágio da criação de um sistema de monitoramento de desempenho de página. Este estágio fornece principalmente funções-chave, como avaliar o desempenho da página e analisar páginas lentas. Embora o Lighthouse ainda tenha dois problemas: ele suporta apenas o Google Chrome, não é representativo o suficiente e não pode refletir verdadeiramente o desempenho do cliente real. Ao mesmo tempo, resolveremos esses dois problemas adicionando outra solução técnica: monitoramento de usuário real (RUM).

Monitoramento de usuário real (RUM para abreviar)

Como o nome indica, refere-se ao monitoramento e execução em terminais de usuários reais (navegadores), coletando indicadores reais de desempenho quando os usuários executam páginas. Existem duas soluções técnicas principais na indústria:

1. Contando com a organização W3C e vários fornecedores de navegadores, oferecemos amplo suporte a soluções técnicas: PerformanceTiming e PerformanceNavigationTiming. Ele prefere medir o consumo de tempo de cada nó e cada estágio quando a página está sendo executada da perspectiva do processamento do navegador.
2. Cada fábrica desenvolve suas próprias soluções técnicas de acordo com as necessidades reais. O Google web-vitals é o melhor representante entre eles. Do ponto de vista da experiência do usuário, ele usa indicadores mais fáceis de entender para mostrar o desempenho da página.

Além das duas soluções técnicas comuns acima, um pequeno número de fornecedores comerciais de serviços de monitoramento de front-end, além de oferecer suporte a W3C e web-vitals, também fornece um pequeno número de indicadores de desempenho personalizados, como: FMP em Ali ARMS, SPA_LOAD em Byte WebPro. O SPA_LOAD é usado para avaliar o desempenho da página não inicial do SPA, que é bastante inovador e será mencionado posteriormente.

Seleção de tecnologia

A seleção de tecnologia resolve principalmente dois problemas: 1) As especificações PerformanceTiming e PerformanceNavigationTiming do W3C, qual deve ser a principal? 2) Como devem cooperar a especificação W3C Timing e os web-vitals?
Especificações PerformanceTiming e PerformanceNavigationTiming do W3C, qual deve ser a principal?
PerformanceTiming: Foi abandonado pelo padrão W3C mais recente, mas os navegadores convencionais atuais ainda o suportam, e os navegadores antigos o suportam bem e têm alta compatibilidade.

PerformanceNavigationTiming: O padrão mais recente foi introduzido em 2019 com o Navigation Timing Level 2, que se destina a substituir o Navigation Timing Level 1, que abrange o PerformanceTiming.
Ponto de mudança:
Integre as funções de PerformanceTiming e PerformanceNavigation.
Abandone o nó domLoading que não é suficiente para guiar por causa das diferentes implementações dos fornecedores de navegadores.
Adicione nós relacionados ao ServiceWorker.
O tempo de cada nó de atributo usa um tempo relativo de alta precisão a partir de startTime.
Vantagens:
Use o tempo relativo de alta precisão para evitar valores de nó subseqüentes imprecisos devido a alterações no tempo do sistema do lado do usuário.
Suporta estatísticas relacionadas ao ServiceWorker.
Contras:
Falta de compatibilidade do navegador.
para concluir:
De acordo com as estatísticas Can I Use, a diferença de compatibilidade entre os dois é de apenas 2,67%, mas de nossa distribuição real de usuários, usando PerformanceNavigationTiming, a compatibilidade do usuário cai 12%, o que é inaceitável. Portanto, focamos no PerformanceNavigationTiming, se o navegador não for compatível, use o PerformanceTiming. Há pouca diferença no formato de dados entre os dois, apenas ignore o nó domLoading no PerformanceTiming e considere que o navegador não é compatível com o nó workStart ao usar o PerformanceTiming.
Como a especificação W3C Timing e os web-vitals devem funcionar juntos?
PerformanceNavigationTiming (doravante referido como Timing): Com base na especificação W3C, concentra-se em medir o desempenho da página sob a perspectiva do processamento do navegador, doravante referido como Timing.
vantagem:

• Boa compatibilidade do navegador Boa compatibilidade do navegador.
• Dados ricos e indicadores abrangentes. Ou seja, inclui o tempo de consumo de cada estágio, como: Unload, Redirect, DNS, TCP, SSL, Response, DomContentLoadedEvent e LoadEvent; também suporta exibir o tempo de consumo quando a página é executada em cada nó, como: workStart , fetchStart, requestStart, domInteractive e domComplate; Também é possível calcular o consumo de tempo de DCL ( DomContentLoaded ), evento window.load ou PageLoad (carregamento de página) de acordo com o valor do nó fornecido.

deficiência:

• As principais métricas estão ausentes. Embora existam muitos e abrangentes indicadores, eles não são intuitivos o suficiente para expressar o efeito da experiência do usuário.

web-vitals: atualmente contém 6 indicadores: TTFB, FCP, LCP, FID, INP e CLS, onde o FID será substituído pelo INP. TTFB, FCP e LCP refletem o desempenho de carregamento da página, FID e INP representam a experiência de interação da página e CLS representa a estabilidade visual da página. Apenas 6 métricas suportam a avaliação do carregamento da página, interação e estabilidade visual. No entanto, alguns indicadores de web-vitals vêm de especificações como LargegestContentfulPaint, LayoutShift, PerformanceEventTiming e PerformancePaintTiming formuladas pelo W3C, mas são mais compatíveis e mais integradas.

vantagem:

• Os indicadores são concisos, concisos e fáceis de entender.
• Com sua própria linha de base, ele pode julgar o desempenho da página de acordo com os indicadores.

Desvantagens:
Compatibilidade insuficiente do navegador, especialmente no lado do IOS.
O LCP pode ser falsificado. Método: adicione uma imagem de fundo branco de tamanho grande à página. O tempo de carregamento dessa imagem provavelmente será o valor LCP, mas o valor LCP não tem nenhum significado comercial. Limitado pelos princípios de LCP e CLS,
existem certos requisitos para o calendário de recolha de indicadores, que serão introduzidos em detalhe mais tarde.
Requisitos:
Medição real, objetiva e abrangente do desempenho da página.
Conclusão
A coleta de dados de tempo e dados vitais da web ao mesmo tempo traz os seguintes benefícios:
indicadores ricos e dados abrangentes. Ele pode não apenas usar o tempo para refletir o processamento demorado de cada nó e cada estágio da perspectiva do navegador, mas também expressa intuitivamente a visão do usuário por meio da experiência do web-vitals. Recomenda-se julgar visualmente o desempenho da página por meio de web-vitals primeiro e, em seguida, analisá-lo por meio do Timing para obter consideração e análise abrangentes e reduzir erros de julgamento do desempenho da página devido à compatibilidade insuficiente do navegador e fraude de LCP.
A combinação de dados de tempo e dados vitais da web facilita a localização de problemas. Por exemplo, se o TTFB coletado pelo web-vitals for lento, você pode usar o Timing para localizar a lentidão específica em Descarregar, Redirecionar, DNS, TCP e SSL.
Resolva o problema de compatibilidade insuficiente de navegadores antigos do Web-vitals. Se o navegador não suportar web-vitals, você pode avaliar o desempenho da página por DCL, evento window.load ou PageLoad (carregamento de página) demorado.
Seção: seleção de tecnologia RUM, enquanto coleta PerformanceNavigationTiming e web-vitals. Se o navegador não for compatível com PerformanceNavigationTiming, use PerformanceTiming.

Quais indicadores coletar

Nosso requisito é não apenas afetar o desempenho da página o máximo possível, mas também medir o desempenho da página de forma objetiva e abrangente e ajudar os alunos de P&D a localizar rapidamente os gargalos de desempenho. Especificamente, inclui três requisitos: 1) Os indicadores devem ser abrangentes e objetivos; 2) Os pontos de gargalo de páginas lentas podem ser encontrados; 3) Sob a premissa de atender aos dois primeiros requisitos, o desempenho da página não deve ser tão afetado que possível.

Os indicadores devem ser abrangentes e objetivos
Primeiro, coletamos seis indicadores de web-vitals, e os resultados são os seguintes:

O Google planeja substituir o FID pelo INP em 2024. O FID reflete o tempo de atraso da primeira interação e o INP representa o tempo de atraso mais longo entre todas as interações. Acreditamos que tanto o FID quanto o INP possuem seus próprios cenários de uso, e não é contraditório mantê-los ao mesmo tempo.

Em segundo lugar, processamos PerformanceNavigationTiming, o efeito é o seguinte: é

diferente do diagrama de exemplo do W3C abaixo:

o motivo é:

• Durante a operação real da página, os estágios não são necessariamente executados em série, conforme mostrado na figura acima. Há casos em que responseEnd leva mais tempo que domLoading.
• A fase HTTP Cache não possui nós de horário inicial e final, ela pode apenas indicar que ocorre entre os nós fetchStart e domainLookUpStart.
• As fases ServiceWorkerInit, ServiceWorkerFetchEvent e Request
  têm apenas nós iniciais e nenhum nó final, portanto, as fases demoradas não podem ser contadas. Para o estágio Request, responseStart não pode ser usado
  como nó final, porque o conteúdo é transmitido em quadros na rede e todo o conteúdo da página pode não ser transmitido de uma só vez.
• A etapa Processing começa com domInteractive, que não obedece à lei objetiva.Quando a página executa para domInteractive, o DOM
  está pronto, portanto a etapa Processing não pode representar o processo de processamento da página.

Assim, combinamos o diagrama de amostra do W3C para mostrar o processo real de execução da página na forma de pontos, segmentos e linhas:

• Ponto: Refere-se ao nó que não possui nó terminal, incluindo: workStart, fetchStart, requestStart, domInteractive e
  domComplete, representado por um ponto branco.
• Segmento: Refere-se ao estágio de processamento onde realmente existem os nós inicial e final, por exemplo, o valor do estágio de descarregamento é: descarregarEnd - descarregarInício. O mesmo vale para redirecionamento, DNS, TCP, SSL, Response, domContentLoadedEvent e loadEvent, representados por um histograma azul.
• Linha: contém eventos acionados durante o carregamento da página, como DCL (DomContentLoaded), window.load. Além disso, personalizamos
  o evento PageLoad para indicar o carregamento demorado de toda a página e o valor é: loadEventEnd-loadEventStart. Indicado por um histograma amarelo.
  Algoritmos específicos para segmentos e linhas:
• UnloadEvent = descarregarEventEnd - descarregarEventStart
• Redirecionar = redirecionarEnd - redirecionarInício
• DNS = domainLookupEnd - domainLookupStart
• TCP = connectEnd - connectStart
• SSL = connectEnd - SecureConnectionStart
• Resposta = respostaEnd - respostaInício
• loadEvent = loadEventEnd - loadEventStart
• DCL = domContentLoadedEventStart - startTime
• WindowLoad = loadEventStart - startTime
• PageLoad = loadEventEnd - startTime
  Além disso, para refletir mais completamente o desempenho da página, as seguintes entradas também são coletadas e contadas:
• Dados completos de PerformanceEntry são coletados com uma pequena probabilidade (1%). PerformanceEntry contém dados como LargegestContentfulPaint, LayoutShift, PerformanceEventTiming, PerformanceLongTaskTiming, PerformanceNavigationTiming, PerformancePaintTiming, PerformanceResourceTiming, PerformanceServerTiming etc. eventos de execução lenta e outros aspectos da informação. É útil para avaliar o desempenho da página e determinar os gargalos das páginas lentas. Considerando que a maioria das páginas tem muito conteúdo, o número de coleções PerformanceEntry é muito grande. Se 100% for coletado e reportado, terá um grande impacto na largura de banda, armazenamento e desempenho da consulta, portanto, só poderá ser coletado com um pequena probabilidade.
• O tipo de navegação da página, que assume o valor de PerformanceNavigationTiming.type, determina se a página é carregada pela primeira vez ou atualizada e recarregada.
• De acordo com o tipo de recursos, são feitas estatísticas sobre o número de vários recursos, o volume total de transmissão e o consumo total de tempo.
• De acordo com o nome de domínio, são contabilizados o número de recursos, o volume total de transmissão e o consumo total de tempo de cada nome de domínio.
  
  Podemos encontrar gargalos de páginas lentas.
  Referimo-nos à linha de 50 pontos do Lighthouse e às estatísticas do site HTTP Archive e formulamos padrões de páginas lentas de acordo com o tipo de aplicativo: PC ou M. Os limites específicos são os seguintes: para páginas lentas,
  
  coletamos o PerformanceNavigationTiming mencionado na seção anterior, além de web-vitals, dados completos de PerformanceEntry e dados estatísticos com pequena probabilidade, também coletaremos:
• TOP N recursos lentos, método: pegue N
  PerformanceEntry do tipo PerformanceResourceTiming com o maior valor de duração.
• Tarefas longas referem-se a tarefas que ocupam o thread de interface do usuário por mais de 50 milissegundos. Método: colete todos os PerformanceEntry do tipo PerformanceLongTaskTiming. No entanto, a maioria dos navegadores atualmente não pode fornecer o endereço do script (containerSrc) e o nome do método (containerName) onde a tarefa longa está localizada. A coleta dessa parte dos dados pode apenas determinar se a tarefa longa ocorreu? o número de ocorrências. O conteúdo de PerformanceLongTaskTiming é o seguinte:
  
• Eventos lentos referem-se a eventos interativos cujo tempo de processamento excede 104ms. Método: coletar todos os PerformanceEntry do tipo PerformanceEventTiming.
• O número de saltos de página, o valor é: PerformanceNavigationTiming.redirectCount, o que pode auxiliar na análise do motivo pelo qual a fase Redirect demora muito.
• Registra o elemento associado quando os valores CLS e LCP são maiores que o limite de página lenta.
  Não afeta o desempenho da página
  O RUM deve ser implementado invadindo a página e introduzindo o JS SDK na página, o que inevitavelmente afeta o desempenho da página. Como uma ferramenta para descobrir e analisar o desempenho da página, não deve agravar os problemas de desempenho da página. Para minimizar o impacto no desempenho, fizemos duas coisas:
• Carregamento assíncrono do JS SDK: a página importa apenas um arquivo de cabeçalho JS de função única e tamanho pequeno e, depois que a página atinge o evento DomContentLoaded, carrega de forma assíncrona o arquivo principal JS com todos os recursos na forma de script dinâmico.
• Reduzir o uso de largura de banda:
  • Relatório de amostragem: as páginas lentas devem ser relatadas, as páginas não lentas são amostradas e relatadas, a taxa de tabagismo padrão é de 30%, reduza o número de relatórios.
  • Reduza o volume de dados relatados: a quantidade total de dados PerformanceEntry pode refletir totalmente o desempenho da página. Muitas páginas geralmente excedem os dados performanceEntry da barra branca e o volume é muito grande, portanto, a quantidade total de dados PerformanceEntry só pode ser coletados com uma pequena probabilidade e as estatísticas de PerformanceEntry podem ser calculadas e coletadas.

Para resumir, coletamos duas categorias principais de indicadores: PerformanceEntry e web-vitals.
Como avaliar o desempenho da página não inicial de aplicativos SPA?
Ao coletar os indicadores acima, podemos avaliar de forma objetiva e abrangente o desempenho da página regular e a página inicial do aplicativo SPA. No entanto, a página não inicial do aplicativo SPA não é um padrão do navegador. Durante o processo de troca de roteamento do SPA:

O navegador executará apenas o método History.replaceState(), não irá e não deve gerar novamente os dados PerformanceNavigationTiming.
A maioria dos dados de PerformanceEntry contém os indicadores de desempenho de todas as páginas de comutação de roteamento desde a primeira página do SPA. Tomando PerformanceResourceTiming como exemplo, é impossível obter o tempo real de troca de rota através do método History.replaceState() e excluir os dados históricos na coleção PerformanceResourceTiming para obter os dados PerformanceResourceTiming da rota atual. Como a maioria dos frameworks de front-end executa primeiro sua lógica interna no processo de troca de rota SPA e, em seguida, aciona o método History.replaceState(), portanto, o tempo de acionamento do método History.replaceState() é posterior ao tempo de execução da rota comutação.
web-vitals não oferece suporte à coleta de indicadores de desempenho após a troca de rotas fora da página inicial do SPA por enquanto.
Portanto, é impossível ou impossível obter com precisão os indicadores acima para a não página inicial do SPA, portanto, não avaliamos o desempenho da página não inicial do SPA por enquanto.

Visando a dificuldade de avaliar o desempenho da página não inicial do SPA na indústria, a Byte WebPro introduziu de forma criativa o conceito de SPA_LOAD. A lógica básica é: a partir do acionamento do método history.replaceState(), monitoramento de alterações de dom, carregamento de recursos, envio de solicitação e outros eventos de alteração por meio do MutationObserver Para encontrar o tempo para uma página atingir um estado estável como o ponto final e medir o desempenho da página não inicial do SPA calculando o tempo entre os pontos inicial e final. SPA_LOAD é semelhante ao evento onload de página regular, mas o horário de início é posterior ao horário real de troca de rota e a página pode ter sido carregada no horário de término, o que é um pouco insuficiente, mas atualmente é a melhor solução, e nós pode apresentá-lo mais tarde.

Hora de coletar indicadores

Somente coletando valores de índice reais e precisos podemos realmente refletir o desempenho da página. Caso contrário, isso pode enganar os alunos na produção e pesquisa e avaliar erroneamente o desempenho real da página. Portanto, existem vários princípios para escolher o momento da coleta de indicadores:

• Referenciando os padrões, o mais importante é garantir que os indicadores sejam precisos, e é melhor não usá-los se não forem permitidos.
• Existem muitas amostras e relatórios confiáveis. Para alguns indicadores, como CLS, INP, PerformanceEventTiming,
  etc., quanto mais tarde o valor da coleta, mais preciso é o valor, mas quanto mais tarde a coleta, menos tempo resta para o relatório , e a probabilidade de falha no relatório de dados é maior. Para coletar o máximo de dados possível Para amostras, não podemos esperar até que a página seja fechada para coletar indicadores e enviar relatórios.
• Para ser justo, alguns indicadores, como CLS, INP, LCP,
  etc., podem aumentar de valor à medida que a página é aberta por mais tempo. Para tais indicadores, podemos apenas escolher um tempo de coleta relativamente razoável que seja justo para "todos os projetos" sob a premissa de garantir que os dados tenham "grandes amostras".
• Um relatório, alguns indicadores em web-vitals,
  como: LCP, CLS, INP, cada alteração acionará sua função de retorno de chamada, o Google recomenda oficialmente coletar e relatar cada alteração de valor do indicador. Esse tipo de lógica de processamento, o valor do índice é mais preciso, mas ocupa muita conexão de front-end, largura de banda e
  recursos de CPU, e também aumenta seriamente a dificuldade de processamento do programa de recebimento de back-end, o que não é razoável e escolha equilibrada. Portanto, precisamos encontrar uma oportunidade de coleta adequada, coletar e relatar todos os indicadores de desempenho de uma só vez.

Então, como determinar o tempo de coleta? Temos que analisar o tempo exato de geração de dois tipos de dados do indicador, PerformanceEntry e web-vitals:

Para dados de PerformanceEntry, quando o evento onload é acionado, a página está quase carregada e a maioria dos dados indicadores em PerformanceEntry que afetam o carregamento da primeira tela foram gerados. Os dados não gerados têm pouco impacto na avaliação do desempenho da página, como o valor do indicador loadEventEnd em PerformanceNavigationTiming. Portanto, pensamos que quando o evento onload é acionado, o indicador PerformanceEntry pode ser coletado.
Os princípios de geração de indicadores em web-vitals são diferentes. Quando o evento onload é acionado:

• Os indicadores TTFB e FCP foram gerados e não serão alterados e podem ser coletados.
• O maior elemento correspondente ao LCP foi carregado com alta probabilidade, portanto, acreditamos que o valor do LCP tem grande probabilidade de ser preciso neste momento e pode ser coletado.
• A precisão do valor CLS não pode ser determinada. A lógica de cálculo é: a cada 5s após a página ser aberta é usada como uma janela de sessão, e o valor de deslocamento gerado nesta janela é acumulado para ser o valor CLS. Se o valor CLS de a janela da próxima sessão for maior que a da janela da sessão anterior
  , então substitua. Portanto, para indicadores CLS,
  é mais adequado coletar 5S após a abertura da página, preferencialmente 5S ou seu múltiplo inteiro, sendo mais justo para "todos os projetos".
• A precisão de FID e INP não pode ser determinada. Eles são gerados somente após as operações de interação do usuário. As operações de interação incluem: clique, entrada, arrastar e soltar, toque e outros eventos. FID
  é o tempo de atraso da primeira interação e INP assume o valor com o maior tempo de atraso entre várias operações interativas. Ambos os indicadores dependem das operações do usuário, e o
  valor do INP pode aumentar à medida que o número de operações do usuário aumenta, portanto, é impossível garantir a aquisição precisa desses dois indicadores a qualquer momento.

Com base nas considerações acima, acreditamos que pelo menos uma das condições de acionar o evento onload ou abrir a página 5s pode ser garantida para garantir a precisão do PerformanceEntry ou alguns indicadores vitais da web, e a coleta é significativa. Sob o princípio de buscar "múltiplas amostras", combinado com a situação real de que o RUM SDK é carregado de forma assíncrona após o evento onload, definimos um total de três tempos de coleta com base em se a página é fechada normalmente. As características são as seguintes : Para evitar o impacto dos


indicadores de coleta Para o desempenho da página, carregamos o RUM JS SDK de forma assíncrona. Os indicadores em web-vitals suportam apenas retorno de chamada assíncrono por padrão. O carregamento assíncrono e o retorno de chamada assíncrono ainda podem falhar ao obter o valor de cada indicador no momento da coleta, então fizemos uma Transformação para suportar a aquisição síncrona de cada valor do indicador.

Método de relatório

Depois de coletar os indicadores, você precisa escolher um método de relatório apropriado para enviar os indicadores de forma confiável para o back-end. O método de relatório inclui duas partes: mecanismo de relatório e tempo de relatório.

Para escolher um mecanismo de relatório apropriado, em primeiro lugar, ele deve atender aos requisitos funcionais, ter alta compatibilidade com o navegador e, de preferência, não ter limite para o tamanho dos dados; segundo, ser capaz de detectar solicitações de relatórios anormais, facilitar novas tentativas de relatórios e melhorar os relatórios confiabilidade; por fim, o suporte ao cliente definindo o período de tempo limite para evitar ocupação de longo prazo e esquecimento de conexão, aumentando a pressão sobre os serviços de back-end. Existem quatro mecanismos de relatórios comuns, a saber: Image, XMLHttpRequest, sendBeacon e Fetch API. Suas características são as seguintes:

	Imagem	XMLHttpRequest	enviarBeacon	Buscar
Fundamental	Crie um img DOM oculto de 1 pixel e inclua o endereço e o conteúdo do relatório no src do img. Se o relatório for bem-sucedido, um código de status 200 será retornado	Use o objeto interno do navegador XMLHttpRequest para relatar dados	Use o método navigator.sendBeacon() especialmente projetado para enviar dados de análise para enviar dados de análise ao back-end enviando solicitações HTTP POST de forma assíncrona	fetch é uma API moderna baseada em Promise para enviar solicitações HTTP
compatibilidade do navegador	alto	alto	, não suporta IE	Moderadamente baixo, não suporta IE
limite de tamanho de dados	Menos de 8 K O limite de tamanho de cada navegador é diferente e está sujeito a CDN, proxy de back-end e servidor da Web. O valor padrão geralmente é 8 K. 8K refere-se ao comprimento codificado pelo URI	Pedido com POST, ilimitado	Sim, alguns navegadores têm menos de 64K	Pedido com POST, ilimitado
Anormalidade do relatório percebido	Parcialmente suportado. O evento img onerror será acionado quando a solicitação retornar um código de status 404 ou 204. Se o código de status for maior ou igual a 400, o evento onerror não será acionado, como 400, 500, 502 e 504.	apoiar	não suporta. O valor de retorno de sendBeacon() só pode indicar se o navegador envia uma solicitação	apoiar
tempo limite pode ser definido	Não, depende das configurações do servidor	Pode	Não pode	Pode
vantagem	Fácil de usar e alta compatibilidade	Potente, flexível e fácil de expandir; sem limite de tamanho, alta compatibilidade	Fácil de usar, alta confiabilidade; quando a página é fechada, ela ainda pode ser enviada	Comparado com XMLHttpRequest, é mais simples de usar e mais poderoso
deficiência	O tamanho dos dados é limitado e é difícil perceber e relatar exceções	A escrita de código é um pouco complicada, então preste atenção ao processamento entre domínios	Incapaz de perceber e relatar exceções, o valor de retorno da função true, false só pode representar se o envio foi bem-sucedido	Compatibilidade de navegador mais baixa com XMLHttpRequest
Cena aplicável	Os dados relatados são pequenos e os requisitos de confiabilidade não são altos	Existem muitos requisitos funcionais, é recomendável relatar no formato text/plain ou application/x-www-form-urlencoded por POST, CORS pré-autenticação	Precisa relatar dados quando a página é fechada	Igual ao XMLHttpRequest, mais adequado para terminais com distribuição de navegador mais recente

A conclusão acima: depende do chrome114

Comparado com Fetch, XMLHttpRequest tem quase a mesma função e maior compatibilidade; comparado com Image, XMLHttpRequest tem as vantagens de alta compatibilidade, tamanho de dados ilimitado, capacidade de perceber exceções e tempo limite pode ser definido; XMLHttpRequest é normal (não fechado) página Em seguida, o mecanismo de relatório preferido para enviar dados de métrica. Quanto ao sendBeacon, embora existam muitas deficiências, os dados ainda podem ser relatados quando a página é fechada e a taxa de sucesso é relativamente alta. É adequado como um mecanismo de relatório para enviar dados de indicadores não enviados quando a página é fechada.

Agora que o sendBeacon está selecionado como o mecanismo de relatório para enviar dados do indicador quando a página é fechada, como julgar que a página está fechada? A solução tradicional é ouvir o evento descarregar ou antes de descarregar, que tem duas deficiências:

Os requisitos funcionais não podem ser atendidos. Quando os usuários de celular saem da página, eles estão mais acostumados a ocultar o navegador em vez de fechá-lo. Quando a página está oculta, os eventos descarregar e antes de descarregar não são acionados.
O desempenho sofre. Alguns navegadores não podem usar o bfcache depois de ouvir os eventos de descarregamento ou antes do descarregamento, resultando na redução do desempenho da página.
Uma solução mais adequada e moderna é ouvir os eventos pagehide ou visibilidadechange===hiden, evitando os dois inconvenientes das soluções tradicionais e com maior grau de compatibilidade. Para projetos SPA, não coletamos indicadores de desempenho fora da página inicial, e o acionamento do método History.replaceState() também é contabilizado como saída da página.

Resumindo, o mecanismo geral de relatórios é o seguinte: 1) A página está normal (não fechada) e, quando chega a hora da coleta, o SDK coleta os dados do índice de desempenho e os relata usando o mecanismo XMLHttpRequest; 2) Ouvindo o evento pagehide ou visibilidadechange===hiden, quando a página estiver desativada, se qualquer condição de tempo de coleta for atendida, os indicadores serão coletados imediatamente e relatados usando o mecanismo sendBeacon.

programa geral

Resumindo, organizamos o esquema de implementação do RUM da seguinte forma:

No processo de codificação real, o fluxo de processamento específico é o seguinte:

Vantagens e desvantagens

Durante o processo de implementação, resumimos as vantagens e desvantagens do RUM da seguinte forma:

O desenho da arquitetura RUM é complexo, e o custo de implementação é relativamente alto.Devido às rígidas necessidades técnicas, só podemos investir recursos e trabalhar duro para fazê-lo bem.

Para as deficiências de nenhum resultado de diagnóstico e sugestões de otimização, você pode usar SYN para aprender uns com os outros e usar SYN para diagnosticar a distribuição de gargalos de desempenho de página lenta.

Para o problema em que não há pontuação e é impossível julgar o desempenho da página, seguiremos três etapas: primeiro, formule um padrão de página lenta para julgar se uma única página é rápida ou lenta, e o valor padrão tem descrito acima; em segundo lugar, conte os indicadores importantes dos valores AVG, TP50, TP90, TP99 da página, avalie de forma abrangente a distribuição de desempenho de todas as solicitações na página; finalmente, pontuaremos o aplicativo onde a página está localizada e informaremos diretamente Para os alunos de pesquisa e desenvolvimento, o desempenho do aplicativo é bom ou ruim, e o método específico de pontuação do aplicativo será descrito no capítulo seguinte "Estabelecendo um sistema de classificação" explicado em detalhes.

3 projeto de arquitetura geral

O artigo anterior analisou profundamente as respectivas características, métodos de uso, vantagens e desvantagens de SYN e RUM. Descobrimos que SYN e RUM têm suas próprias vantagens e não podem ser substituídos. A cadeia de ferramentas de análise oferece suporte a estudantes de produção e pesquisa para descobrir e localizar o desempenho da página problemas em cada etapa do devpos.

Nos estágios de codificação, construção e teste, os alunos de P&D podem usar o SYN para fazer testes de desempenho da página para determinar se o desempenho da página está de acordo com o padrão? Se houver um problema com o desempenho da página, use SYN para diagnosticar problemas de desempenho e obter sugestões de otimização. Essa mudança resolve os pontos problemáticos de longa data da página de front-end, como a dificuldade do teste de desempenho na página de front-end e a qualidade fora do padrão da página entregue. Depois que o aplicativo for implantado, use RUM para coletar o desempenho real da página do usuário e avaliar o desempenho real da página. Se ainda existirem páginas lentas, você ainda poderá usar SYN para localizar gargalos de desempenho de página lenta e usar resultados de diagnóstico e sugestões de otimização para melhorar a eficiência da otimização. Além disso, o SYN também pode ser usado para comparar produtos concorrentes para atingir o objetivo de conhecer a si mesmo e ao inimigo e um passo à frente dos concorrentes.

Com SYN e RUM, podemos construir um loop fechado para otimizar continuamente as páginas online lentas, conforme mostrado na figura acima. O RUM é responsável por coletar páginas lentas geradas por usuários reais. Após o armazenamento e agregação em segundo plano, ele cria automaticamente um SYN JOB para as páginas lentas do TOPN. Após a conclusão do trabalho, ele notifica os alunos de pesquisa e desenvolvimento sobre os resultados do diagnóstico e otimização sugestões como um alarme. Os alunos de P&D usam as sugestões de otimização SYN e, em seguida, usam devtools, webpack e outras ferramentas para melhorar a página, entregar páginas de alta qualidade e reduzir a frequência de páginas lentas. Esse ciclo é repetido continuamente para otimizar o desempenho da página do aplicativo e, finalmente, o aplicativo pode atingir o desempenho máximo.

4 Estabeleça um sistema de julgamento

Apresentando SYN, RUM SDK autodesenvolvido, e depois de coletar muitos dados de indicadores SYN e RUM, começaremos a estabelecer um sistema de avaliação para avaliar o desempenho de cada aplicativo, equipe, departamento e até mesmo de toda a empresa, e produzir alguns principais indicadores e pontuações, que são intuitivos Informe aos funcionários em todos os níveis e funções o desempenho da página de suas organizações e organizações no mesmo nível e julgue se deve otimizar o desempenho da página comparando as pontuações com os colegas?

Ao estabelecer o sistema de avaliação, aderimos ao princípio de não apenas destacar pontos-chave e indicadores-chave, mas também refletir de forma abrangente, abrangente, objetiva e verdadeira o desempenho da página. Portanto, dividimos o sistema de julgamento em duas partes, uma das quais mostra os indicadores de desempenho mais críticos. Em segundo lugar, gere as pontuações e os níveis de desempenho de cada indicador, aplicativo, equipe, departamento e nível da empresa.

Exiba os indicadores de desempenho mais críticos

Selecionamos um indicador que melhor representa o desempenho da página de web-vitals e performanceNavigationTiming, respectivamente: DCL e LCP. O LCP não é altamente compatível e pode ser falsificado. O DCL pode substituir o LCP para refletir parcialmente o desempenho da primeira tela e tem alta compatibilidade e é difícil de falsificar. Ele complementa o LCP e pode refletir melhor o desempenho da página.

TP90 representa o limite inferior da experiência do usuário para 90% dos usuários. Comparado com AVG, TP50 e TP75, ele cobre e conta uma gama mais ampla de usuários e também pode bloquear uma pequena quantidade de dados sujos gerados pela página sob o ambiente de rede especial do telefone móvel, que é mais representativo.

Classificações de saída em todos os níveis

Pontuação de desempenho do aplicativo
Para avaliar de forma abrangente, abrangente e objetiva o desempenho da página do aplicativo. Vamos selecionar indicadores representativos de cada dimensão, consultar a distribuição de indicadores no setor fornecida pelo HTTP Archive e configurar diferentes Calcule a pontuação de cada indicador. Em seguida, defina o peso de acordo com a importância de cada indicador e obtenha a pontuação de desempenho do aplicativo por meio do algoritmo de média ponderada. O processo é como se segue:

O processo de obtenção de pontuações de desempenho de aplicativos envolve vários processos importantes: 1) triagem de indicadores e definição de peso; 2) seleção de algoritmos de pontuação; 3) estabelecimento de linhas de base de indicadores; 4) cálculo de pontuações de desempenho de aplicativos usando algoritmos de média ponderada. Os seguintes são apresentados um a um.

Triagem de índice e definição de peso
Neste processo, considero principalmente dois pontos:

Consideração abrangente. O desempenho da página abrange muitos aspectos. Tradicionalmente, é medido apenas por alguns indicadores, como primeiro byte, tela branca e tempo da primeira tela, que é relativamente unilateral e não objetivo o suficiente. Acreditamos que julgar o desempenho da página deve abranger indicadores de várias dimensões, como: carregamento da página, experiência interativa e experiência visual. Além disso, também apresentamos o conceito de proporção de API lenta. A proporção de solicitação de API refere-se à proporção de solicitações de API que demoram mais de 3 segundos após a página ser aberta. A API lenta pode afetar o tempo de carregamento da primeira tela e a experiência do usuário durante o processo de interação. Para permitir que os alunos de P&D prestem atenção às páginas lentas e usem o SYN online como uma ferramenta de avaliação de desempenho de desenvolvimento diário, também usamos a pontuação SYN como um índice de peso. O sistema em segundo plano contará as páginas lentas com o número de visitas TOP10 todos os dias e criar automaticamente uma tarefa cronometrada SYN Aguarde a execução e análise da tarefa Após a conclusão, as sugestões de otimização e os resultados do diagnóstico serão notificados aos alunos de P&D. Itens de pontuação SYN, incluindo pontos de desempenho e pontos de melhores práticas, ambos baseados em um sistema de 100 pontos.

Destaque os pontos-chave. Aumente a proporção de peso de indicadores importantes. Por exemplo, o indicador de carregamento é usado para medir se a página pode ser usada e é o mais crítico, por isso é atribuído o maior peso. O LCP é o indicador de carga mais importante e a relação de peso também é aumentada de acordo. Como o próprio LCP não é necessariamente totalmente razoável e pode ser falsificado, indicadores de carga como DCL, FCP, TTFB, WindwLoad e PageLoad também são introduzidos ao avaliar o desempenho do carregamento da página. Vantagens deste método: muitos indicadores, amplas dimensões, amplos ângulos, mais abrangente e mais objetivo e preciso; desvantagens: aumenta a complexidade e dificuldade do sistema de avaliação.

Com base nas duas considerações acima, definimos os resultados da triagem de índice e as configurações de proporção de peso, conforme mostrado na figura abaixo:

cada índice participa do cálculo de pontuação com base em seu valor estatístico TP90.

Seleção do algoritmo de pontuação O
algoritmo de pontuação refere-se principalmente ao modelo de curva de pontuação Lighthouse. O princípio básico é: definir dois pontos de controle, geralmente TP50 e TP90, ou seja, os pontos de valor do índice quando 50 ou 90 pontos são obtidos e, em seguida, gerar um par de pontos com base nesses dois pontos de controle A curva numérica normal, por meio da qual pode ser obtida a pontuação correspondente a qualquer valor do índice. A figura a seguir é a curva de pontuação do LCP do terminal M:

m representa a mediana e o valor de m na figura é 4000ms, o que significa que quando o valor LCP é 4000ms, 50 pontos são atribuídos; da mesma forma, quando p10 é 2520ms e o valor LCP é 2529ms, 90 pontos são obtidos. Depois de definir m e p10, o modelo de curva de pontuação à direita será gerado, de acordo com o qual a pontuação quando o valor LCP for de 0 a infinito positivo pode ser obtida.

Estabelecendo a linha de base métrica
O objetivo de estabelecer a linha de base métrica é fornecer ao algoritmo de pontuação dois pontos de controle, os valores de m e p10. Existem três maneiras de estabelecer:

• Empreste a configuração do Lighthouse diretamente. Considere os limites de 50 e 90 pontos dos indicadores correspondentes do Lighthouse como valores de ponto de controle m e p10, como os
  indicadores em web-vitals.
• Consulte os dados estatísticos do Arquivo HTTP e use os valores p10 e p75 nos dados estatísticos como os valores de ponto de controle m e p10. Tais como
  indicadores de performanceNavigationTiming.
• Construa sua própria linha de base. Um pequeno número de linhas de base de indicadores não pode ser estabelecido a partir dos dois métodos acima e só pode ser construído. Método específico: pegue os dados obtidos pelo sistema de fundo atual como uma amostra e use os valores tp75 e tp95 da amostra como os
  valores do ponto de controle m e p10. Aplica-se a métricas de escala de API lentas.

No processo de estabelecimento da linha de base, a diferença no valor do aplicativo e nos requisitos de P&D deve ser considerada, e as configurações direcionadas devem ser feitas de acordo com as características do aplicativo. Em primeiro lugar, os aplicativos do lado do PC e do lado M precisam definir diferentes linhas de base de índice. Felizmente, o Lighthouse e o HTTP Archive fornecem referências de configuração para o lado do PC e do lado M. Aplicações C-side e B-side geram diretamente valor de negócio, e seus requisitos de desempenho são maiores que os das aplicações internas, portanto os valores dos dois pontos de controle devem ser menores.

Use o algoritmo de média ponderada para calcular a pontuação de desempenho do aplicativo.
De acordo com o valor tp90 do indicador, a linha de base do indicador e o algoritmo de pontuação, a pontuação percentual do indicador é obtida.
Use o algoritmo de média ponderada para calcular a pontuação de desempenho do aplicativo e o resultado = (Σ (valor do índice tp90 × peso do índice)) / (peso Σ), onde: Σ significa a soma.

Pontuações da organização em todos os níveis
Quanto às pontuações de desempenho de organizações em todos os níveis, incluindo equipes, departamentos e empresas, o algoritmo de média ponderada ainda é usado para obter pontuações da organização com base no número de aplicativos sob sua jurisdição, pontuações de desempenho de aplicativos e pesos de aplicação. O processo é o seguinte:

A dificuldade em obter a pontuação de desempenho organizacional é: como definir o peso do aplicativo? Referimo-nos principalmente ao intervalo PV e ao nível de aplicação da aplicação. Quanto maior o nível de PV e quanto maior o nível de aplicação, maior o peso. A referência de configuração específica é a seguinte:

O valor PV no intervalo PV refere-se ao PV, não ao PV real, e PV=taxa de volume/amostragem de dados RUM coletados.
Após as etapas acima, podemos obter pontuações de desempenho de aplicativos, bem como pontuações de desempenho de organizações em todos os níveis, como pontuações de desempenho de equipes, pontuações de desempenho de departamentos e pontuações de desempenho doméstico.

Uma pontuação acima é considerada excelente.

5 resumo

Por meio da construção do sistema de monitoramento e avaliação do desempenho da página, temos não apenas os dados originais do desempenho da página, mas também valores estatísticos agregados, bem como a pontuação final. Por meio de pontuação, estatísticas e dados brutos, o link para descobrir, localizar e analisar problemas de desempenho é aberto. Os alunos de P&D podem julgar intuitivamente se o desempenho do aplicativo precisa ser otimizado por meio de pontuação. Se a otimização for necessária, analise os gargalos do aplicativo agregando dados estatísticos; ao localizar gargalos específicos, você pode visualizar dados detalhados para auxiliar na análise das causas específicas dos gargalos; após a melhoria, você pode verificar o efeito da otimização por meio de estatísticas e, finalmente, refletir a melhoria pontuação superior.

Devido a limitações de espaço, este artigo pode apenas apresentar práticas relacionadas ao monitoramento de desempenho de páginas e construção de sistemas de avaliação. Um sistema completo de monitoramento de desempenho de página também deve incluir: monitoramento, alarme, otimização, governança e outros módulos, não apenas indicadores, mas podem medir o desempenho da página, encontrar gargalos de desempenho, ajudar os alunos de P&D a melhorar a eficiência da otimização e curar a causa raiz, por meio do Build uma série de cadeias de ferramentas de front-end, melhore o processo de entrega, melhore a qualidade da entrega da página da fonte por meio de especificações, ferramentas e processos, evite trazer problemas online e descubra problemas de desempenho antes dos usuários.
Referências
vitals-spa-faq
Métricas vitais da Web para aplicativos de página única
Beaconing na prática
O HTTP Archive
é um projeto para coletar e analisar dados de desempenho do site, com o objetivo de ajudar os desenvolvedores da Web a entender as tendências da tecnologia da Internet e as melhores práticas para otimização de desempenho.