{"id":2366,"date":"2017-11-24T17:03:39","date_gmt":"2017-11-24T19:03:39","guid":{"rendered":"http:\/\/chatbotsbrasil.blip.ai\/?p=2366"},"modified":"2023-07-16T09:32:15","modified_gmt":"2023-07-16T12:32:15","slug":"performance-no-front-end","status":"publish","type":"post","link":"https:\/\/www.blip.ai\/blog\/devs\/performance-no-front-end\/","title":{"rendered":"Performance no front-end: 3 crit\u00e9rios + t\u00e9cnicas para sua aplica\u00e7\u00e3o web voar"},"content":{"rendered":"

A preocupa\u00e7\u00e3o com front-end performance<\/strong> em aplica\u00e7\u00f5es web nem sempre est\u00e1 no topo da lista de prioridades de um projeto. Com tantas demandas e novas features a serem implementadas, acabamos entregando nosso software sem a devida preocupa\u00e7\u00e3o com o seu desempenho.
\nMas por que devemos nos preocupar com performance no front-end? O que devemos levar em considera\u00e7\u00e3o? E por onde come\u00e7ar?
\nVamos analisar 3 crit\u00e9rios essenciais<\/strong> para responder a essas perguntas (e ainda te mostrar 3 t\u00e9cnicas para melhorar sua performance web)!<\/p>\n

1. Usabilidade<\/h2>\n

Por que se preocupar com performance no front-end?
\nBom, ningu\u00e9m gosta de esperar, muito menos quando o assunto \u00e9 web. A falta de front-end performance (popularmente conhecida como lentid\u00e3o) na sua aplica\u00e7\u00e3o pode afastar os usu\u00e1rios do seu produto, dificultar a reten\u00e7\u00e3o de novos clientes, entre outros problemas.
\nUm exemplo interessante \u00e9 o caso da Mozilla: ao diminuir 2,2 segundos do tempo de carregamento da sua landing page, eles observaram um aumento de 15,4% nas convers\u00f5es de acessos em downloads<\/a>, o que resultou em mais de 60 milh\u00f5es de downloads por ano.<\/p>\n

2. Uso massivo de dispositivos m\u00f3veis<\/h2>\n

Outro fator muito importante a ser considerado quando o assunto \u00e9 performance no front-end!
\nSegundo o IBGE, j\u00e1 em 2013, 57,3% das resid\u00eancias acessaram a internet por meio de celulares e tablets, como mostrou a Valor<\/a>. Mas mesmo com o crescente acesso ao 4G, a internet m\u00f3vel no Brasil ainda \u00e9 muito cara. Isso significa que economizar o pacote de dados do seu usu\u00e1rio torna-se um ponto importante a ser considerado ao desenvolver sua aplica\u00e7\u00e3o web.
\nFalando agora um pouco sobre o outro lado da sua aplica\u00e7\u00e3o, o back-end tamb\u00e9m deve entrar na nossa lista de preocupa\u00e7\u00f5es.<\/strong> Costumo dizer o seguinte quando o assunto \u00e9 front-end\/back-end<\/a>: front-end \u00e9 a ponte entre o usu\u00e1rio e o servidor.
\nAssim, filtrar bem as requisi\u00e7\u00f5es feitas no seu back-end \u00e9 um ponto de suma import\u00e2ncia, visto que, hoje, muitos servi\u00e7os de nuvem como Amazon, Azure, Google Cloud e afins cobram por requisi\u00e7\u00e3o.
\nIsso significa que requisi\u00e7\u00f5es desnecess\u00e1rias geram custos desnecess\u00e1rios e tr\u00e1fegos de dados desnecess\u00e1rios. Ou seja, n\u00e3o ligar para a performance no front-end pode doer no bolso.<\/p>\n

3. SEO<\/h3>\n

E para o famigerado SEO<\/strong>? A performance no front-ende influencia em alguma coisa?
\nA resposta \u00e9 sim.
\nVoc\u00eas j\u00e1 ouviram falar em um site chamado PageSpeed Insights<\/a>? Pois ent\u00e3o, o Google, j\u00e1 h\u00e1 algum tempo atr\u00e1s, mencionou que a boa performance de uma p\u00e1gina \u00e9 um dos fatores a serem considerados no ranqueamento de um site.
\nSendo assim, atrav\u00e9s dessa ferramenta, podemos receber uma nota juntamente com um feedback mostrando o que fazer para corrigir os pontos fracos da nossa p\u00e1gina.
\nLegal, n\u00e9? Ent\u00e3o, n\u00e3o deixe de fazer seu dever de casa de performance no front end se n\u00e3o quiser que o google te penalize.<\/p>\n

Como melhorar a front-end perfomance?<\/h2>\n

Existem in\u00fameras t\u00e9cnicas de performance web interessantes que podemos utilizar. Inclusive, no site Browser Diet<\/a>, existe uma lista bem completa de v\u00e1rias t\u00e9cnicas legais que mostram o verdadeiro impacto da tecnologia nas empresas<\/a>.
\nAgora, vou destacar as x que mais uso no dia a dia na Take.<\/p>\n

1. Concatenar + Minificar<\/h3>\n

Nos projetos da Take, optamos por concatenar e minificar todos os assets CSS e JavaScript em um \u00fanico arquivo, economizando assim requisi\u00e7\u00f5es \u201cblocantes\u201d (aquelas que bloqueiam a p\u00e1gina enquanto o download n\u00e3o \u00e9 conclu\u00eddo) feitas no servidor.
\nPara isso, utilizamos uma ferramenta super legal chamada Webpack<\/a>. Pra quem n\u00e3o conhece, essa ferramenta \u00e9 excelente para gerar bundles, processar arquivos (transformando imagens f\u00edsicas em formato base64, por exemplo) e executar uma s\u00e9rie de tarefas como transpilar TypeScript para JavaScript, gerar arquivos programaticamente, entre outras. Tamb\u00e9m existem alternativas interessantes como o GruntJs<\/a> e Gulpjs<\/a>.<\/p>\n

2. Definir larga e altura das imagens<\/h3>\n

Outra coisa legal \u00e9 sempre definir largura e altura das imagens para melhorar a perfomance no front-end.<\/strong>
\nConsiderando uma p\u00e1gina web que possui v\u00e1rias imagens a serem renderizadas, informar o browser com anteced\u00eancia sobre as dimens\u00f5es das imagens \u00e9 interessante, pois caso voc\u00ea n\u00e3o fa\u00e7a isso por si s\u00f3, o navegador ir\u00e1 fazer, e isso gasta um certo processamento (pouco, mas gasta).
\nRecursos externos devem, preferencialmente, ser carregados utilizando as tags async ou defer. Isso significa que, scripts que antes eram carregados de forma sequencial, agora ser\u00e3o carregados de forma ass\u00edncrona. Exemplo:<\/p>\n

<script async src=\u201dhttps:\/\/site.com\/my-script.js\u201d><\/pre>\n
Tenha em mente que carregar scripts de forma sequencial \u00e0s vezes \u00e9 necess\u00e1rio, outras vezes n\u00e3o. De qualquer forma, \u00e9 uma \u00f3tima dica de front-end perfomance.<\/p>\n
3. Service Workers em PWA<\/h3>\n
Por fim, outra t\u00e9cnica interessante e bastante incentivada pelo Google s\u00e3o as chamadas aplica\u00e7\u00f5es web progressivas (PWA)<\/strong>, utilizando os service workers. Essa \u00e9 uma t\u00e9cnica bastante avan\u00e7ada, mas que traz resultados consider\u00e1veis em termos de performance no front-ed.
\n(N\u00e3o vou entrar em detalhes de implementa\u00e7\u00e3o, pois isso exigiria outro post.)<\/em>
\nMas, fazendo um resumo, o que basicamente acontece \u00e9: utilizando os service workers do browser, conseguimos armazenar programaticamente em cache os arquivos necess\u00e1rios para o carregamento da p\u00e1gina (index.html, arquivos javascript, css e etc) e, sempre ao abrir a p\u00e1gina, ao inv\u00e9s de consultar o servidor, o service worker consulta diretamente o cache.
\nIsso tamb\u00e9m acontece em casos em que o usu\u00e1rio est\u00e1 offline<\/strong>.
\nDessa forma, uma vez armazenado os arquivos em cache, mesmo offline voc\u00ea consegue mostrar um conte\u00fado ao seu usu\u00e1rio em vez da p\u00e1gina default de \u201cfalha de conex\u00e3o\u201d. Nesse tutorial em portugu\u00eas<\/a> do Google, eles ensinam um passo a passo de como criar o seu primeiro Progressive Web App.<\/p>\n
Front-end perfomance resolvida?<\/h2>\n
Espero que com esses 3 crit\u00e9rios +3 t\u00e9cnicas de como melhorar sua performance no front-end, voc\u00ea possa entregar uma melhor experi\u00eancia ao usu\u00e1rio.
\nUma forma bem inteligente de coletar esses feedbacks nesse sentido \u00e9 por meio de chatbots e n\u00f3s podemos te ajudar com isso!
\nVeja um exemplo de como criar um na nossa plataforma:
\n