{"id":1371,"date":"2016-10-27T11:23:52","date_gmt":"2016-10-27T13:23:52","guid":{"rendered":"https:\/\/blog.umbler.com\/?p=1371"},"modified":"2018-12-05T18:20:08","modified_gmt":"2018-12-05T20:20:08","slug":"como-aperfeicoar-velocidade-de-seu-site-latencia-e-front-end","status":"publish","type":"post","link":"https:\/\/blog.umbler.com\/br\/como-aperfeicoar-velocidade-de-seu-site-latencia-e-front-end\/","title":{"rendered":"#1 Como aperfei\u00e7oar a velocidade de seu site: lat\u00eancia e front-end"},"content":{"rendered":"<p>Alguns entendem a velocidade de um site como o tempo de carregamento de todo o conte\u00fado presente na p\u00e1gina, outros consideram o tempo de carregamento do primeiro byte de informa\u00e7\u00e3o. Seja qual for sua medi\u00e7\u00e3o, uma coisa \u00e9 certa: seu site precisa ser r\u00e1pido. O tempo de carregamento \u00e9 um dos pontos que mais contribuem para o abandono de p\u00e1ginas. Sim, e os dados podem ser ainda mais assustadores do que voc\u00ea imagina:<\/p>\n<ul>\n<li>40% dos usu\u00e1rios tendem a abandonar uma p\u00e1gina web que leva mais de tr\u00eas segundos para carregar;<\/li>\n<li>47% dos usu\u00e1rios acreditam que uma p\u00e1gina web deve carregar completamente em dois segundos ou menos;<\/li>\n<li>52% dos consumidores online tendem a ser mais leais a sites que carregam mais r\u00e1pido.<\/li>\n<\/ul>\n<p>Ou seja, a lentid\u00e3o no carregamento de um site pode provocar um alto \u00edndice de insatisfa\u00e7\u00e3o de usu\u00e1rio, mas n\u00e3o apenas isso. A demora tamb\u00e9m impede, cada vez mais, que seu site seja encontrado na internet, isso porque, em termos SEO a velocidade de carregamento \u00e9 um item considerado bastante importante. Entre uma infinidade de fatores que o Google utiliza para classificar um site em seus resultados, por exemplo, a velocidade, tamb\u00e9m de sites mobile, aparece na lista &#8211; e n\u00e3o \u00e9 de hoje, esse fator \u00e9 considerado desde 2010.<\/p>\n<p>Se voc\u00ea acha que \u201csegundos\u201d \u00e9 pouco tempo, n\u00e3o esque\u00e7a que, na internet, o carregamento de p\u00e1gina \u00e9 medido em milissegundos, ou seja, mil\u00e9simos de segundo.<br \/>\nFunciona mais ou menos assim:<\/p>\n<table>\n<tbody>\n<tr>\n<th>Tempo de carregamento da p\u00e1gina<\/th>\n<th>Rea\u00e7\u00e3o do usu\u00e1rio<\/th>\n<\/tr>\n<tr>\n<td>0 \u2013 100ms<\/td>\n<td>Nossa, essa p\u00e1gina carrega instantaneamente. Que maravilha \ud83d\ude00<\/td>\n<\/tr>\n<tr>\n<td>100 \u2013 300 ms<\/td>\n<td>Essa p\u00e1gina \u00e9 bastante r\u00e1pida. Perfeito \ud83d\ude09<\/td>\n<\/tr>\n<tr>\n<td>300 \u2013 1000ms<\/td>\n<td>Carregando (&#8230;) Opa, foi! Legal \ud83d\ude42<\/td>\n<\/tr>\n<tr>\n<td>1s+<\/td>\n<td>Ufa, finalmente abriu! Achei que realmente n\u00e3o fosse carregar \ud83d\ude10<\/td>\n<\/tr>\n<tr>\n<td>10s+<\/td>\n<td>\u00c9, melhor eu voltar depois (ou n\u00e3o!) \ud83d\ude41<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>E, se voc\u00ea est\u00e1 pensando que \u201c\u00e9 tudo problema no front-end!\u201d, saiba que n\u00e3o necessariamente. \u00c9 muito comum que m\u00e1s pr\u00e1ticas de front-end sejam as principais respons\u00e1veis pelo tempo de carregamento de um site, mas \u00e9 preciso estar atento tamb\u00e9m ao back-end. Pensando nesses dois cen\u00e1rios, iniciamos hoje uma s\u00e9rie de posts sobre as melhores pr\u00e1ticas para acelerar o carregamento de suas p\u00e1ginas. Para come\u00e7ar, vamos analisar dois pontos bastante importantes: <strong>lat\u00eancia<\/strong> e <strong>front-end<\/strong>.<\/p>\n<h2>Lat\u00eancia<\/h2>\n<p>Sim, esse \u00e9 um fator essencial e que, frequentemente, gera muitas d\u00favidas. Contratar uma hospedagem no Brasil ou no exterior, qual a diferen\u00e7a entre lat\u00eancia e largura de banda. S\u00e3o muitos os questionamentos, mas, vamos por partes. Em primeiro lugar \u00e9 importante esclarecer o que \u00e9 lat\u00eancia. Lat\u00eancia \u00e9 o intervalo de tempo em que uma informa\u00e7\u00e3o (ou um conjunto delas) vai de um ponto a outro. A tabela no in\u00edcio desse post refere-se justamente \u00e0 lat\u00eancia, o tempo que uma solicita\u00e7\u00e3o leva para sair do computador do usu\u00e1rio, chegar ao servidor de origem e voltar para m\u00e1quina do usu\u00e1rio.<\/p>\n<p>\u00c9 importante entender que a lat\u00eancia est\u00e1 delimitada pela velocidade da luz (299.792.458m\/s), velocidade que s\u00f3 \u00e9 atingida no v\u00e1cuo. Hoje, o melhor meio de transmiss\u00e3o \u00e9 a fibra \u00f3ptica (que na verdade \u00e9 um meio e n\u00e3o a aus\u00eancia dele, como no caso do v\u00e1cuo), mas \u00e9 preciso considerar que todo o meio de transmiss\u00e3o tem um \u00edndice de refra\u00e7\u00e3o, que no caso da fibra \u00f3ptica \u00e9 ~1,5.<\/p>\n<p>Por exemplo:<\/p>\n<p>Uma requisi\u00e7\u00e3o feita em Nova York em um site hospedado em Londres (uma dist\u00e2ncia de 5.585km) levaria 19ms se transmitida na velocidade da luz, no v\u00e1cuo. J\u00e1 na transmiss\u00e3o por fibra \u00f3ptica, a lat\u00eancia passa a ser de 28ms, com Round Trip Time (RTT) de 56ms &#8211; o tempo de ida de volta de uma informa\u00e7\u00e3o entre dois pontos.<\/p>\n<p>Seria redundante dizer que quanto mais longe um site estiver hospedado maior ser\u00e1 sua lat\u00eancia, certo? Mas n\u00e3o parece t\u00e3o repetitivo afirmar que a lat\u00eancia e a largura da banda s\u00e3o coisas diferentes. Uma boa analogia \u00e9 a do encanamento de \u00e1gua. Enquanto a primeira (lat\u00eancia) refere-se \u00e0 quantidade de tempo que a \u00e1gua leva para entrar de um lado do cano e sair pelo outro, a segunda (largura da banda) refere-se ao tamanho desse cano ou \u00e0 quantidade de \u00e1gua que pode fluir nele por um per\u00edodo de tempo.<\/p>\n<p>Ap\u00f3s diversos <a title=\"Impacto largura da banda em velocidade de sites\" href=\"https:\/\/docs.google.com\/a\/chromium.org\/viewer?a=v&amp;pid=sites&amp;srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2\" target=\"_blank\" rel=\"nofollow noopener\"> testes <\/a> j\u00e1 realizados, hoje entende-se que a largura da banda pode impactar na velocidade de carregamento de sites, mas que a lat\u00eancia continua sendo um fator bem mais importante.<\/p>\n<h2>Front-end<\/h2>\n<p>Voc\u00ea sabia que <a title=\"Boas pr\u00e1ticas para acelerar a velocidade de carregamento de sites\" href=\"https:\/\/developer.yahoo.com\/performance\/rules.html\" target=\"_blank\" rel=\"nofollow noopener\"> 80% do tempo de carregamento de uma p\u00e1gina <\/a> est\u00e1 no front-end? Seja carregando recursos ou montando tudo na tela, na maioria dos casos o gargalo est\u00e1 na linha de frente.<\/p>\n<p>Um primeiro ponto que devemos prestar aten\u00e7\u00e3o \u00e9 no n\u00famero de requisi\u00e7\u00f5es HTTP da sua p\u00e1gina vs o tamanho dos arquivos que voc\u00ea est\u00e1 carregando. Assim sendo, considere que:<\/p>\n<ul>\n<li>Enviar m\u00faltiplas requisi\u00e7\u00f5es, para arquivos muito pequenos, n\u00e3o vale a pena, pois cada requisi\u00e7\u00e3o ter\u00e1 um overhead do protocolo HTTP, como o <a title=\"A import\u00e2ncia de minimizar requisi\u00e7\u00f5es em p\u00e1ginas\" href=\"https:\/\/www.globaldots.com\/googles-web-performance-best-practices-3-minimize-request-overhead\/\" target=\"_blank\" rel=\"nofollow noopener\"> envio e recebimento de cookies em cada requisi\u00e7\u00e3o <\/a>. Ao inv\u00e9s disso, agrupe v\u00e1rios arquivos pequenos em um s\u00f3, para que cada ida no servidor valha mais \u00e0 pena.<\/li>\n<li>Requisitar arquivos muito grandes n\u00e3o vale a pena, pois o protocolo HTTP limita o n\u00famero de requisi\u00e7\u00f5es simult\u00e2neas a um mesmo servidor em um n\u00famero entre 2 e 8, <a title=\"Conex\u00f5es paralelas\" href=\"https:\/\/www.stevesouders.com\/blog\/2008\/03\/20\/roundup-on-parallel-connections\/\" target=\"_blank\" rel=\"nofollow noopener\"> dependendo de cada navegador<\/a>. Caso uma das requisi\u00e7\u00f5es tenha um arquivo que seja muito grande, ficar\u00e1 consumindo uma preciosa requisi\u00e7\u00e3o deste limite durante muito tempo.<\/li>\n<\/ul>\n<p>Com isso em mente, certifique-se de agrupar pequenos arquivos Javascript em um s\u00f3, bem como pequenos arquivos CSS. J\u00e1 as pequenas imagens devem ser agrupadas em Sprites CSS, uma t\u00e9cnica largamente difundida na web atualmente.<\/p>\n<p>Aproveitando que tocamos no assunto de CSS e JS, n\u00e3o faz mal lembrar a regra de ouro para estes arquivos:<\/p>\n<blockquote><p>CSS no header. JS no footer!<br \/>\n<em>Albert Einstein<\/em><\/p><\/blockquote>\n<p>Coloque seus arquivos CSS (nem precisa dizer que voc\u00ea n\u00e3o deveria usar CSS inline!) no header da p\u00e1gina, para que a estrutura do HTML se monte, juntamente com o estilo, de maneira mais fluida, sem \u201csolavancos\u201d. J\u00e1 os arquivos JS devem ficar no final da p\u00e1gina, uma vez que seu carregamento \u00e9 bloqueante e atrapalha a experi\u00eancia do usu\u00e1rio enquanto est\u00e1 carregando. Ainda sobre CSS e JS, certifique-se de minific\u00e1-los sempre antes de mand\u00e1-los para produ\u00e7\u00e3o, existem muitos plugins que se integram \u00e0s IDEs mais comuns do mercado, bem como automatizadores de tarefas como <a title=\"Gulp\" href=\"https:\/\/gulpjs.com\/\" target=\"_blank\" rel=\"nofollow noopener\"> Gulp <\/a> e <a title=\"Grunt\" href=\"https:\/\/gruntjs.com\/\" target=\"_blank\" rel=\"nofollow noopener\"> Grunt <\/a> que fazem isso para voc\u00ea automaticamente.<\/p>\n<p>Outra dica que sempre \u00e9 v\u00e1lida \u00e9 usar CDN (Content Delivery Network, como o <a title=\"Add-on de CloudFlare na Umbler\" href=\"https:\/\/blog.umbler.com\/acelerando-o-seu-site-com-o-novo-add-on-de-cdn-via-cloudflare\/\" target=\"_blank\" rel=\"noopener\">CloudFlare<\/a>, add-on dispon\u00edvel na Umbler) para guardar todos os seus conte\u00fados est\u00e1ticos do seu site. Lembra do que falamos antes sobre a limita\u00e7\u00e3o de requisi\u00e7\u00f5es simult\u00e2neas do HTTP? Pois \u00e9, o limite \u00e9 por dom\u00ednio, o que podemos facilmente contornar usando mais de um dom\u00ednio para nossos recursos, geralmente um dom\u00ednio que aponte para um CDN. Se seu site \u00e9 <em>meusite.com<\/em>, que tal criar o <em>static.meusite.com<\/em>, ou o <em>img.meusite.com<\/em>? Apenas certifique-se de n\u00e3o usar mais que dois ou tr\u00eas dom\u00ednios, caso contr\u00e1rio a resolu\u00e7\u00e3o de DNS vai cobrar um alto pre\u00e7o da sua aplica\u00e7\u00e3o e a estrat\u00e9gia pode ser um \u201ctiro no p\u00e9\u201d!<\/p>\n<p>Mas, por que um CDN e n\u00e3o apenas um subdom\u00ednio comum? O protocolo HTTP carrega consigo, al\u00e9m das informa\u00e7\u00f5es da requisi\u00e7\u00e3o em si, uma s\u00e9rie de meta-informa\u00e7\u00f5es (cabe\u00e7alhos) e de cookies, que caso n\u00e3o saiba, s\u00e3o informa\u00e7\u00f5es da sess\u00e3o do navegador. Um CDN \u00e9 um ambiente otimizado para entregar os arquivos da maneira mais r\u00e1pida poss\u00edvel, livre de cookies (desnecess\u00e1rios em requisi\u00e7\u00f5es de arquivos est\u00e1ticos como imagens, JS e CSS) e com controle da expira\u00e7\u00e3o do cache desses arquivos. Assim, um arquivo que n\u00e3o muda com frequ\u00eancia, pode ser armazenado em cache no navegador do usu\u00e1rio por um m\u00eas, por exemplo, o que vai economizar muitas requisi\u00e7\u00f5es caso ele (o usu\u00e1rio) acesse seu site com frequ\u00eancia.<\/p>\n<p>Ainda sobre conte\u00fado est\u00e1tico (voc\u00ea notou como eles s\u00e3o muito importantes?), certifique-se de que todas suas imagens est\u00e3o com o tamanho e qualidade apropriados, para evitar redimensionamento via HTML\/CSS ou mesmo imagens com alto n\u00edvel de detalhes e transpar\u00eancias quando apenas queremos um \u00edcone pequeno e pouco vis\u00edvel.<\/p>\n<p>Estas foram algumas dicas que acreditamos que possam fazer uma diferen\u00e7a significativa no desempenho do seu site e certamente existem muitas outras que poder\u00edamos aplicar. Nos pr\u00f3ximos posts vamos abordar temas como melhorias no back-end e no banco de dados. Para isso, contamos com a sua colabora\u00e7\u00e3o. O que voc\u00ea aplica hoje em seus sites para aumento de desempenho e recomenda que os outros fa\u00e7am tamb\u00e9m?<\/p>\n<p>Deixe as suas dicas a\u00ed nos coment\u00e1rios e nos ajude a criar um post ainda mais incr\u00edvel \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Alguns entendem a velocidade de um site como o tempo de carregamento de todo o conte\u00fado presente na p\u00e1gina, outros consideram o tempo de carregamento do primeiro byte de informa\u00e7\u00e3o. Seja qual for sua medi\u00e7\u00e3o, uma coisa \u00e9 certa: seu site precisa ser r\u00e1pido. O tempo de carregamento \u00e9 um dos pontos que mais contribuem [&hellip;]<\/p>\n","protected":false},"author":46,"featured_media":5468,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[196],"class_list":["post-1371","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dev","tag-velocidade-de-sites"],"_links":{"self":[{"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/posts\/1371"}],"collection":[{"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/comments?post=1371"}],"version-history":[{"count":0,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/posts\/1371\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/media\/5468"}],"wp:attachment":[{"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/media?parent=1371"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/categories?post=1371"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.umbler.com\/br\/wp-json\/wp\/v2\/tags?post=1371"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}