DEV Community

João Vitor Minosso
João Vitor Minosso

Posted on

Performance no front-end

Recentemente, identifiquei uma lacuna significativa em uma biblioteca extremamente popular para front-end em aplicações hashtag#React.

Essa lacuna pode resultar em uma queda de desempenho de 100% a 500% na sua aplicação.

Mas no que isso implica? Um baixo desempenho pode afetar tarefas intensivas ou que impactam diretamente o usuário, incluindo re-renderizações que são comprovadas através de ferramentas de profiling.
Para corrigir e evitar esse problema no seu projeto, você deve analisar os resultados que obtive e considerar o tamanho da sua aplicação e suas metas de performance. Para isso, desenvolvi um projeto que mensura o impacto de duas bibliotecas de componentes e o hospedei na hashtag#Vercel. Nele, você pode observar o impacto em milissegundos de apenas 5 componentes na tela.

Acesse pelo link: https://lnkd.in/dPRJR6tt

Após visualizar o projeto, você pode pensar: "O desempenho vai de 30ms para 120ms; ninguém percebe isso."
Claro, com apenas 5 componentes, essa diferença pode passar despercebida. No entanto, considere uma tabela com 400 linhas ou uma tela que carrega componentes que utilizam useEffect para buscar e hidratar dados.
Se uma tela já leva 3 segundos para carregar, agora pode levar 12. Isso significa que seu usuário pode desistir, especialmente se estiver acessando pelo celular.

🤝 Deixe seu like para que este conteúdo chegue a mais pessoas e, se você já passou por essa situação, comente neste post para disseminar informações!

Explicação Mais Técnica
Implementei várias bibliotecas de estilo em diferentes tipos de aplicações, como Chakra UI, Tailwind, Material UI, Ant Design, entre outras. Contudo, nunca tinha encontrado uma biblioteca que tornasse o site tão lento quanto a do Ant Design, que leva cerca de 10 segundos para carregar uma página da documentação.
Diante disso, decidi testar. Ao abrir o profiler, percebi que o site que estava desenvolvendo estava sofrendo com re-renderizações excessivas. O desempenho havia caído e, como estava começando a usar a biblioteca e havia pouca informação na tela, isso não era perceptível para mim, mas ferramentas de teste de desempenho como Lighthouse e o profiler mostraram claramente o problema.
Verifiquei que duas bibliotecas diferentes estavam fazendo chamadas à API e recarregando a tela e seus componentes simultaneamente: Ant Design e Iconify. Ambas buscam e armazenam em cache os componentes na primeira carga da tela, ao contrário do Material UI e do código nativo (usando apenas HTML e CSS).
Pesquisei sobre melhorias de desempenho nessas aplicações e, após um tempo, cheguei à conclusão: "Se houvesse uma maneira de melhorar, eles já teriam feito isso na documentação." Assim, decidimos usar menos essas duas bibliotecas para evitar gargalos no futuro!
Se você quiser contribuir com este projeto, sinta-se à vontade para abrir um PR no repositório: https://lnkd.in/d4SDRqk8
Ficarei feliz com sua contribuição!

Image description

Top comments (0)