Como realizar uma auditoria técnica de um aplicativo front-end usando o exemplo de um portal de informações de alta carga

Uma auditoria de site é geralmente entendida como uma análise abrangente dos fatores que afetam sua visibilidade nos mecanismos de busca, ou seja, uma auditoria de SEO. Também estão começando a ganhar popularidade as auditorias de UX, que medem a eficácia, usabilidade e lógica das interfaces de usuário.



Há uma auditoria técnica para verificar a velocidade do site e identificar as causas dos atrasos. Recomenda-se conduzi-lo mesmo que o sistema pareça estar funcionando corretamente e não haja problemas de desempenho. O fato é que ele ainda pode ser melhorado: a otimização da infraestrutura irá acelerar a entrega do código e a refatoração da base de código ajudará a reduzir os custos de manutenção.



Neste artigo, mostraremos como uma auditoria técnica de um website segue o exemplo de um recurso de notícias popular que é visitado por dezenas de milhares de usuários por hora. Vamos considerar as etapas independentes de verificação e análise, como resultado, mostraremos claramente como é possível melhorar o projeto e eliminar gargalos que retardam o carregamento da página.

Coleta de métricas e análise de recursos estáticos do site



Certifique-se de coletar métricas e medir tudo o que puder usando ferramentas prontas como Google Page Speed, Lighthouse e Web.dev. Essa é a maneira mais rápida de obter métricas que servirão de ponto de partida para sua pesquisa. Com a ajuda deles, você entenderá o que vale a pena prestar atenção em primeiro lugar, o que pode ser otimizado.



Aconselhamos que você execute a análise com o bloqueador de anúncios ligado e desligado. Como resultado, você descobrirá a rapidez com que ocorre a primeira renderização de conteúdo e quantos scripts de terceiros estão conectados ao site.







Nesta fase, você também verá quantas operações básicas ocorrem ao renderizar o site:







As métricas coletadas provavelmente indicam espaço para melhorar os ativos estáticos do site: imagens, vídeos, scripts, estilos e fontes. Analise esses dados e certifique-se de seguir as práticas gerais de recursos estáticos. No entanto, lembre-se de que essas são apenas diretrizes, não requisitos rígidos.



Em nosso exemplo, todas as imagens são armazenadas no formato jpg. Se você usar o webp, que é perfeitamente compatível com os navegadores, o tamanho do arquivo será reduzido em 20% em média. Você pode configurar a compactação webp automática apenas para imagens de alta resolução. Recomenda-se que os vídeos de alta resolução sejam convertidos para webm para navegadores que suportem este formato. Para reduzir a carga na rede, é aconselhável desabilitar a reprodução automática de vídeos que não são visíveis. Isso pode ser feito usando a API Intersection Observer.



Certifique-se de que seu site tenha downloads progressivos e adicione compactação em todos os lugares, se possível. Certifique-se de usar técnicas modernas de compressão de script, como brotli, gzip e deflate.



Não carregue o que não é usado. Isso pode se aplicar a código, estilos, símbolos, imagens. Se, por exemplo, um site possui um botão que aparece em mil casos, então o script que o processa deve ser conectado apenas sob demanda.







No exemplo acima, você pode ver que ~ 93% do código total não é usado (~ 340 kb.) Um pacote com um código é considerado ideal se sua cobertura for 100% enquanto cobre todos os casos sem recarregar a página. Isso pode acontecer se o código não for usado de todo ou se a divisão do código estiver configurada incorretamente, ou for usada, mas em outras páginas, ou quando um determinado cenário for alcançado.



A solução para esse problema é mover os componentes reutilizáveis ​​para arquivos separados (blocos), que são conectados apenas nos locais onde são necessários.



Como dissemos, esses requisitos são opcionais, mas a otimização dos recursos estáticos é importante, pois o usuário os percebe primeiro.



Vamos pegar as fontes como exemplo - neste projeto, elas demoraram muito para carregar. Como não queremos que o usuário veja as fontes padrão, nós as carregamos bem no início, na seção critical-css. Como resolver este problema? Você pode otimizar fontes no nível de código, alterar a ordem de conexão, substituir ttf por woff2.



Você também pode tentar reduzir o número de fontes usadas, o que implica redesenhar o design, mas nem sempre isso se justifica. Se o site usa a biblioteca Google Fonts, remova os caracteres não usados ​​dos arquivos, isso não é proibido por direitos autorais.



Mas às vezes é mais fácil deixar as coisas como estão e se concentrar em outras possibilidades.



Examinando solicitações HTTP



Nesta fase, verificamos se o front-end interage com o back-end corretamente, a saber:



  • compressão configurada para solicitações de API;
  • não há consultas parasitas que carregam a conexão, cujos resultados não são usados ​​em nenhum lugar;
  • não há solicitações retornadas com erro sem que o usuário conclua um caso de negócios específico;
  • quando a página é carregada inicialmente, o navegador não envia solicitações à API (se o site usar renderização do lado do servidor, como em nosso exemplo);
  • não há solicitações duplicadas. Se for feito um pedido ao ir a qualquer página, é melhor enviar uma vez e salvar os dados para reutilização;
  • pending , . , , , . , — , .






As solicitações bloqueadas são destacadas em vermelho, mas o site continua funcionando.



Além disso, ao analisar as solicitações, você pode encontrar bugs. Foi assim que encontramos a operação incorreta do aplicativo front-end, que poderia enviar mais de 100 solicitações por segundo, o que carregou muito o servidor. A tela piscou, o carregador girou sem parar, etc. O motivo estava oculto em um pergaminho implementado incorretamente. O navegador manteve sua posição na parte inferior da página quando novos elementos apareceram. Ou seja, ao rolar pela página, um loader foi lançado, devido ao qual a página desceu. O manipulador Javascript reenviou a solicitação, que por sua vez acionou a animação do carregador novamente, devido à alteração do tamanho da página e assim por diante, ad infinitum.





Devido ao funcionamento incorreto do carregador, o número de solicitações cresce infinitamente



Análise de scripts e recursos externos



Nesse estágio, você deve determinar quais recursos de sites de terceiros demoram mais para carregar.



A web moderna permite que você priorize qualquer download. Freqüentemente, métricas e anúncios são carregados antes de a página ser exibida, o que por si só não faz sentido, já que o usuário ainda não conseguirá ver o anúncio, mas o site demorará mais para carregar. Recomendamos exibir os anúncios imediatamente após renderizar o site, o que não afetará as estatísticas de forma alguma - caso contrário, o usuário verá uma tela branca por algum tempo.



Perfis de páginas



Use as ferramentas de desenvolvimento do Chrome para criar o perfil das páginas do seu site para rastrear solicitações longas e aumentar o uso da CPU. Como resultado, você verá o que está carregando claramente o site.







A imagem mostra que leva 19 milissegundos para carregar o Jquery, o que não é necessário no momento. Melhor carregar jquery após os recursos principais, de preferência após um evento de carregamento bem-sucedido (por exemplo, onload, domcontentloaded.)



Análise do número e duração das solicitações



Neste estágio, exploraremos como o front-end interage com o back-end. Para fazer isso, você precisa analisar o número e a duração de todas as solicitações.Para obter uma imagem mais completa, você precisa medir o tempo médio de resposta para uma solicitação e para as paralelas.



Para maior clareza, combine os dados obtidos em um gráfico de resumo. Dessa forma, você pode identificar rapidamente quais consultas estão demorando muito mais do que outras.



Se o site estiver instalado em um servidor poderoso, o tempo de execução de 100 solicitações paralelas não deve exceder muito o tempo de execução de uma solicitação. No exemplo, vemos uma diferença de 30 vezes. As consultas de execução mais longa devem ser investigadas primeiro.







Neste projeto, para algumas requisições, ocorreu o timeout do gateway, ou seja, a resposta do servidor não veio.



Sobrecarga em projetos de alta carga é normal. No entanto, se possível, você deve tentar dividir as solicitações em suas partes componentes, nos casos em que uma solicitação é responsável por várias ações. Execute essas peças em roscas paralelas.



O que pode ser feito para melhorar o servidor? Conecte a biblioteca para monitorar o servidor e reiniciar o aplicativo (no caso de node.js, este é pm2). Também é recomendado conectar uma ferramenta de monitoramento de erros, como Sentry. Configure a saída de erro e o registro de desligamento de emergência. Dessa forma, você pode rastrear o tempo de inatividade do seu aplicativo.



Idealmente, configure um registrador assíncrono para monitorar qualquer atividade no site (solicitações de API, solicitações ao banco de dados, APIs externas, ao sistema de arquivos ou serviços para trabalhar com o sistema de arquivos), que os registrará em um banco de dados separado.



Análise estática do código-fonte



Essa análise é realizada por utilitários que irão apontar o código errado e ajudar a se livrar do "código morto". É importante notar que essas ferramentas devem ser usadas automaticamente durante o desenvolvimento, mas você nem sempre precisa contar com a integridade dos desenvolvedores, portanto, é melhor não pular esta verificação.



Para fazer análise estática, você precisa usar linters eslint e outros utilitários de formatação de código, como o mais bonito e o sonar, que rastreiam violações de código.



Como resultado, com base nas violações identificadas, você pode redigir um documento:







Normalmente, essas violações não afetam o desempenho do site, mas complicam a leitura e a escrita do código, o que significa que sua manutenção será mais cara. Por exemplo, neste projeto, encontramos uma função em que havia três argumentos, um dos quais não foi utilizado - essas ninharias juntas aumentam o débito técnico do projeto.



Análise semântica do código fonte



Neste ponto, o programador precisará examinar manualmente os arquivos do projeto. Vale ressaltar que só será possível avaliar erros óbvios no comportamento do código-fonte; para uma análise mais aprofundada, é necessário conhecer bem a lógica do projeto. Nesta fase, você pode encontrar códigos repetitivos que podem ser colocados em um único lugar (classe, função ou constante) para reduzir o número de linhas e reduzir a possibilidade de bugs.



Às vezes, essa análise ajudará a determinar se a equipe de desenvolvimento está tendo problemas. A partir de linhas de código do Git, você pode determinar quem é o autor e determinar o desempenho de cada funcionário. Você pode descobrir que mais da metade dos comentários se referem a um desenvolvedor.



Por exemplo, aqui identificamos dez operações assíncronas que atualizam o banco de dados, mas foram realizadas uma a uma, sem estar conectadas entre si. Isso significa que seu desempenho pode ser duplicado executando-os em paralelo. Use o paralelismo sempre que possível, porque mesmo nas versões atuais do PHP, você pode ajustar o paralelismo artificial para melhorar o desempenho do sistema.



Resultado



O desenvolvimento de software envolve muitos riscos e, na realidade, muitas vezes você precisa fazer concessões para colocar um projeto em execução no prazo. Portanto, a documentação costuma ser preparada retroativamente, e a otimização do site é adiada para o último momento.



Mas nunca é tarde para fazer melhorias no desempenho. Acelerar o seu site vai melhorar a experiência do usuário e dar uma resposta positiva ao público. Com a ajuda de uma auditoria técnica, você pode determinar o que causa atrasos no trabalho do site - um aplicativo front-end ou back-end. Aqui foram coletadas recomendações sobre como conduzir uma auditoria de front-end. Eles são de natureza geral e adequados para testar qualquer site.



Em breve, informaremos como conduzir uma auditoria técnica do back-end em nossa próxima publicação.



All Articles