Taxa de erros<\/strong>: Alerta imediato em qualquer erro 5xx ou erro de console JavaScript em p\u00e1ginas cr\u00edticas<\/li>\n<\/ul>\nConfigure pol\u00edticas de escalonamento de alertas – por exemplo, envie uma notifica\u00e7\u00e3o no Slack ap\u00f3s a primeira falha, acione o engenheiro de plant\u00e3o ap\u00f3s tr\u00eas falhas consecutivas e escale para um gerente ap\u00f3s 10 minutos de degrada\u00e7\u00e3o cont\u00ednua.<\/p>\n
O Dotcom-Monitor suporta alertas por email, SMS, chamada telef\u00f4nica, PagerDuty, Slack e integra\u00e7\u00f5es via webhook, garantindo que as notifica\u00e7\u00f5es alcancem as pessoas certas pelo canal correto.<\/p>\n
Passo 4: Monitore a partir de m\u00faltiplas geografias<\/h3>\n
O desempenho n\u00e3o \u00e9 uniforme. Seu CDN pode ter cobertura total na Am\u00e9rica do Norte e Europa, mas cobertura escassa em Sudeste Asi\u00e1tico, Oriente M\u00e9dio ou Am\u00e9rica Latina. A rede global de n\u00f3s de monitoramento do Dotcom-Monitor permite executar testes id\u00eanticos de locais como S\u00e3o Paulo, Singapura, Mumbai e T\u00f3quio – fornecendo um retrato honesto da experi\u00eancia global do usu\u00e1rio, n\u00e3o apenas da experi\u00eancia a partir da regi\u00e3o AWS mais pr\u00f3xima.<\/p>\n
Quando voc\u00ea perceber que o LCP \u00e9 2,1 segundos em Londres, mas 6,4 segundos em Jacarta, voc\u00ea tem um sinal espec\u00edfico e acion\u00e1vel: adicione um PoP CDN no Sudeste Asi\u00e1tico ou revise a configura\u00e7\u00e3o de roteamento do CDN para aquela regi\u00e3o.<\/p>\n
Passo 5: Capture gr\u00e1ficos de cascata e tempos de recursos<\/h3>\n
O Dotcom-Monitor captura gr\u00e1ficos de cascata detalhados para cada teste sint\u00e9tico executado. Um gr\u00e1fico de cascata mostra cada recurso que o navegador carrega – HTML, CSS, arquivos JavaScript, imagens, fontes, chamadas API – com o tempo de consulta DNS, conex\u00e3o, espera e transfer\u00eancia de cada recurso visualizados como barras horizontais em uma linha do tempo compartilhada.<\/p>\n
A an\u00e1lise da cascata \u00e9 como voc\u00ea diagnostica por que<\/em> uma p\u00e1gina est\u00e1 lenta, n\u00e3o apenas que<\/em> ela est\u00e1 lenta. Constata\u00e7\u00f5es comuns na revis\u00e3o da cascata:<\/p>\n\n- Um arquivo CSS que bloqueia a renderiza\u00e7\u00e3o carrega de um n\u00f3 CDN lento, adicionando 400 milissegundos ao FCP<\/li>\n
- Um script de analytics de terceiros demora 1,8 segundos para responder, bloqueando a thread principal<\/li>\n
- 47 requisi\u00e7\u00f5es de imagens n\u00e3o s\u00e3o agrupadas nem carregadas pregui\u00e7osamente, criando uma cascata de requisi\u00e7\u00f5es sequenciais<\/li>\n
- Uma chamada API, que deveria retornar em 120 milissegundos, est\u00e1 levando 2,4 segundos intermitentemente<\/li>\n<\/ul>\n
Nenhuma dessas constata\u00e7\u00f5es \u00e9 vis\u00edvel a partir de uma m\u00e9trica \u00fanica de “tempo de carregamento da p\u00e1gina”. Elas requerem o gr\u00e1fico de cascata.<\/p>\n
Passo 6: Use testes em navegador real<\/h3>\n
Muitas ferramentas b\u00e1sicas de monitoramento usam verifica\u00e7\u00f5es simples HTTP que confirmam a conectividade do servidor e c\u00f3digos de resposta – elas confirmam que o servidor retornou status 200, mas n\u00e3o executam JavaScript, nem fazem parse de CSS ou renderizam a p\u00e1gina. Essas verifica\u00e7\u00f5es perdem a maioria dos problemas de desempenho frontend em aplica\u00e7\u00f5es web modernas porque medem apenas a resposta do servidor, n\u00e3o a experi\u00eancia completa do navegador. Note que essa \u00e9 uma distin\u00e7\u00e3o metodol\u00f3gica, n\u00e3o de modo de renderiza\u00e7\u00e3o: navegadores headless (como os usados pelo Puppeteer ou Playwright) executam completamente o JavaScript e renderizam o CSS – simplesmente n\u00e3o exibem interface visual. A diferen\u00e7a relevante \u00e9 entre uma verifica\u00e7\u00e3o s\u00f3 HTTP e uma verifica\u00e7\u00e3o completa baseada em navegador, independentemente se o navegador est\u00e1 em modo headless ou n\u00e3o.<\/p>\n
O Dotcom-Monitor usa motores reais de navegador – Chrome e Firefox – para executar seus scripts de monitoramento. Isso significa que captura a experi\u00eancia completa de renderiza\u00e7\u00e3o: tempo de execu\u00e7\u00e3o do JavaScript, carregamento de fontes, tempo de decodifica\u00e7\u00e3o de imagens e deslocamentos de layout. \u00c9 o mesmo dado de desempenho que o navegador real de um usu\u00e1rio gera, n\u00e3o uma aproxima\u00e7\u00e3o.<\/p>\n
Isso \u00e9 particularmente importante para aplica\u00e7\u00f5es Single Page (SPAs) constru\u00eddas em React, Angular ou Vue, onde a resposta HTML pode ser uma concha m\u00ednima que o JavaScript completa. Uma verifica\u00e7\u00e3o HTTP b\u00e1sica em uma SPA React reportar\u00e1 um tempo r\u00e1pido de resposta do servidor enquanto o usu\u00e1rio na verdade espera v\u00e1rios segundos para o JavaScript renderizar o conte\u00fado.<\/p>\n
Passo 7: Integre ao seu fluxo de trabalho de implanta\u00e7\u00e3o<\/h3>\n
Regress\u00f5es de desempenho geralmente t\u00eam origem em implanta\u00e7\u00f5es. Um desenvolvedor adiciona uma nova depend\u00eancia JavaScript. Um designer carrega uma imagem hero de 4MB. Um engenheiro adiciona uma nova chamada API no caminho cr\u00edtico.<\/p>\n
A API do Dotcom-Monitor permite disparar execu\u00e7\u00f5es de testes como parte do seu pipeline CI\/CD. Configure seu processo de implanta\u00e7\u00e3o para:<\/p>\n
\n- Executar a su\u00edte de testes do Dotcom-Monitor contra seu ambiente de staging antes da promo\u00e7\u00e3o para produ\u00e7\u00e3o<\/li>\n
- Falhar a compila\u00e7\u00e3o se qualquer m\u00e9trica de desempenho ultrapassar seus limites definidos<\/li>\n
- Reexecutar automaticamente a su\u00edte completa de testes imediatamente ap\u00f3s cada implanta\u00e7\u00e3o em produ\u00e7\u00e3o<\/li>\n
- Comparar as m\u00e9tricas de desempenho p\u00f3s-implanta\u00e7\u00e3o com a linha de base pr\u00e9-implanta\u00e7\u00e3o<\/li>\n<\/ol>\n
Isso transporta o monitoramento de desempenho para a esquerda – capturando regress\u00f5es antes de chegarem aos usu\u00e1rios, ao inv\u00e9s de depois.<\/p>\n
Passo 8: Acompanhe tend\u00eancias de desempenho ao longo do tempo<\/h3>\n
Dados de desempenho pontuais t\u00eam valor limitado. O que importa \u00e9 a tend\u00eancia. Seu LCP est\u00e1 melhorando trimestre ap\u00f3s trimestre enquanto sua equipe investe em desempenho? Seu TTFB est\u00e1 piorando gradativamente com o crescimento do banco de dados? Uma implanta\u00e7\u00e3o espec\u00edfica em mar\u00e7o de 2024 causou uma mudan\u00e7a abrupta na taxa de erros que nunca foi totalmente resolvida?<\/p>\n
O Dotcom-Monitor mant\u00e9m dados hist\u00f3ricos de desempenho e fornece pain\u00e9is e relat\u00f3rios para an\u00e1lise de tend\u00eancias. Use-os para:<\/p>\n
\n- Acompanhar progresso contra metas de melhoria de desempenho<\/li>\n
- Identificar degrada\u00e7\u00e3o gradual antes que se torne uma crise<\/li>\n
- Correlacionar mudan\u00e7as de desempenho com implanta\u00e7\u00f5es, picos de tr\u00e1fego ou mudan\u00e7as na infraestrutura<\/li>\n
- Reportar tend\u00eancias de desempenho a stakeholders com dados, n\u00e3o anedotas<\/li>\n<\/ul>\n
16 Melhores Pr\u00e1ticas de Desempenho em Aplica\u00e7\u00f5es Web<\/h2>\n
O monitoramento mostra onde est\u00e3o os problemas. Estas melhores pr\u00e1ticas mostram como consertar e preveni-los.<\/p>\n
Melhores pr\u00e1ticas para desempenho frontend<\/h3>\n
Otimize imagens.<\/strong> Sirva imagens nos formatos WebP ou AVIF, dimensione imagens para suas dimens\u00f5es de exibi\u00e7\u00e3o e implemente lazy loading para imagens abaixo da dobra. Use um CDN com otimiza\u00e7\u00e3o autom\u00e1tica de imagens. Essa categoria \u00fanica de otimiza\u00e7\u00e3o geralmente reduz o peso da p\u00e1gina em 30\u201360%.<\/p>\nElimine recursos que bloqueiam renderiza\u00e7\u00e3o.<\/strong> Atrasar Javascript n\u00e3o cr\u00edtico usando os atributos defer ou async. Inline CSS cr\u00edtico (o CSS necess\u00e1rio para renderizar conte\u00fado acima da dobra) e carregue o restante da folha de estilo de forma ass\u00edncrona. Mova CSS n\u00e3o cr\u00edtico para carregar ap\u00f3s a renderiza\u00e7\u00e3o inicial.<\/p>\nImplemente divis\u00e3o de c\u00f3digo.<\/strong> Use importa\u00e7\u00e3o din\u00e2mica (import()) e divis\u00e3o de c\u00f3digo baseada em rotas para garantir que os usu\u00e1rios baixem apenas o JavaScript necess\u00e1rio para a p\u00e1gina atual. Um usu\u00e1rio visitando sua p\u00e1gina inicial n\u00e3o precisa do JavaScript do fluxo de checkout.<\/p>\nPr\u00e9-carregue recursos cr\u00edticos.<\/strong> Use <link rel=”preload”> para fontes, imagens cr\u00edticas e peda\u00e7os de JavaScript que ser\u00e3o necess\u00e1rios imediatamente. Use <link rel=”dns-prefetch”> para dom\u00ednios de terceiros. Use <link rel=”preconnect”> para origens onde voc\u00ea sabe que far\u00e1 requisi\u00e7\u00f5es.<\/p>\nMinimize scripts de terceiros.<\/strong> Audite todos os scripts de terceiros nas suas p\u00e1ginas mais cr\u00edticas. Remova scripts que n\u00e3o entregam valor mensur\u00e1vel. Para scripts que precisa manter, carregue-os de forma ass\u00edncrona e monitore sua contribui\u00e7\u00e3o para o desempenho nos seus gr\u00e1ficos de cascata. Um widget de chat que adiciona 1,5 segundos ao LCP na sua p\u00e1gina inicial pode estar fazendo mais mal do que bem.<\/p>\nUse uma Rede de Distribui\u00e7\u00e3o de Conte\u00fado (CDN).<\/strong> Sirva todos os recursos est\u00e1ticos – JavaScript, CSS, imagens, fontes – de um CDN. CDNs armazenam conte\u00fado em caches pr\u00f3ximos geograficamente dos usu\u00e1rios, reduzindo o tempo de ida e volta para recursos frequentemente baixados.<\/p>\nMelhores pr\u00e1ticas para desempenho backend<\/h3>\n
Otimize consultas ao banco de dados.<\/strong> Revise os logs de consultas lentas regularmente. Adicione \u00edndices nas colunas usadas em cl\u00e1usulas WHERE e condi\u00e7\u00f5es JOIN. Evite consultas N+1 usando batching ou eager loading. Use EXPLAIN ANALYZE para entender planos de execu\u00e7\u00e3o. Configure monitoramento para que consultas lentas disparem alertas.<\/p>\nImplemente cache em todas as camadas.<\/strong> Armazene resultados de consultas em Redis ou Memcached para dados que mudam raramente. Cacheie respostas HTML renderizadas para p\u00e1ginas id\u00eanticas para todos os usu\u00e1rios. Configure cabe\u00e7alhos de cache apropriados no navegador (Cache-Control, ETag) para ativos est\u00e1ticos. Uma aplica\u00e7\u00e3o bem cacheada serve a maioria das requisi\u00e7\u00f5es do cache, reduzindo carga na CPU do servidor e no banco de dados.<\/p>\nUse HTTP\/2 ou HTTP\/3.<\/strong> O multiplexing do HTTP\/2 permite m\u00faltiplas requisi\u00e7\u00f5es sobre uma \u00fanica conex\u00e3o TCP, eliminando bloqueio da fila. HTTP\/3 (QUIC) melhora isso ainda mais para redes inst\u00e1veis ou de alta lat\u00eancia. A maioria dos CDNs e servidores modernos suporta HTTP\/2 com configura\u00e7\u00e3o m\u00ednima.<\/p>\nComprima respostas.<\/strong> Ative compress\u00e3o Brotli ou gzip em todas as respostas baseadas em texto – HTML, JSON, CSS, JavaScript. Brotli geralmente obt\u00e9m 15\u201320% melhor taxa de compress\u00e3o que gzip. Compress\u00e3o reduz o tamanho da transfer\u00eancia e portanto o tempo de transfer\u00eancia para todos os usu\u00e1rios.<\/p>\nEscale horizontalmente com balanceamento de carga.<\/strong> Um \u00fanico servidor de aplica\u00e7\u00e3o tem capacidade finita. Configure um balanceador de carga para distribuir tr\u00e1fego entre m\u00faltiplas inst\u00e2ncias do servidor. Use autoescalamento para adicionar capacidade em picos e remover em per\u00edodos de baixa demanda.<\/p>\nTransfira tarefas demoradas para jobs em background.<\/strong> Opera\u00e7\u00f5es que n\u00e3o precisam ser conclu\u00eddas antes do usu\u00e1rio receber resposta – envio de email, redimensionamento de imagens, gera\u00e7\u00e3o de relat\u00f3rios, sincroniza\u00e7\u00e3o com sistemas de terceiros – devem ser processadas por uma fila de jobs em background (Sidekiq, Celery, AWS SQS) ao inv\u00e9s do ciclo de requisi\u00e7\u00e3o-resposta.<\/p>\nMelhores pr\u00e1ticas de infraestrutura e arquitetura<\/h3>\n
Use uma estrat\u00e9gia de implanta\u00e7\u00e3o multi-regi\u00e3o.<\/strong> Implemente sua aplica\u00e7\u00e3o em m\u00faltiplas regi\u00f5es geogr\u00e1ficas para minimizar lat\u00eancia para usu\u00e1rios em todo o mundo. Redirecione usu\u00e1rios para a regi\u00e3o mais pr\u00f3xima usando GeoDNS ou um balanceador global como AWS Global Accelerator ou Cloudflare Load Balancing.<\/p>\nMonitore depend\u00eancias externas.<\/strong> O desempenho da sua aplica\u00e7\u00e3o depende de todos os servi\u00e7os externos que ela chama – processadores de pagamento, provedores de email, provedores de identidade, fornecedores de analytics, APIs de mapa. Monitore a sa\u00fade e tempo de resposta dessas depend\u00eancias. Quando a API da Stripe desacelera, seu checkout desacelera. Quando o provedor de identidade tem um incidente, o login do usu\u00e1rio falha.<\/p>\nImplemente degrada\u00e7\u00e3o graciosa.<\/strong> Projete sua aplica\u00e7\u00e3o para continuar funcionando – com recursos reduzidos – quando depend\u00eancias falharem ou ficarem lentas. Se a API do motor de recomenda\u00e7\u00f5es estiver indispon\u00edvel, exiba listas est\u00e1ticas de produtos em vez de aguardar timeout. Padr\u00f5es de breaker de circuito previnem que uma depend\u00eancia lenta cause uma queda total da aplica\u00e7\u00e3o.<\/p>\nDefina e aplique or\u00e7amentos de desempenho.<\/strong> Um or\u00e7amento de desempenho define os valores m\u00e1ximos aceit\u00e1veis para m\u00e9tricas-chave – por exemplo, LCP abaixo de 2,5 segundos, tamanho total do bundle JavaScript abaixo de 200KB, peso total da p\u00e1gina abaixo de 1MB. Integre verifica\u00e7\u00f5es de or\u00e7amento de desempenho no seu pipeline CI\/CD para que desenvolvedores sejam notificados imediatamente quando uma altera\u00e7\u00e3o violar o or\u00e7amento.<\/p>\nBenchmarks de desempenho de aplica\u00e7\u00f5es web<\/h2>\n
Como saber se o desempenho da sua aplica\u00e7\u00e3o \u00e9 bom? Benchmarks da ind\u00fastria oferecem um ponto de refer\u00eancia.<\/p>\n
Para LCP, o limite de Core Web Vitals do Google de 2,5 segundos \u00e9 o padr\u00e3o a ser atingido. Segundo dados do Chrome UX Report, o LCP mediano para p\u00e1ginas que passam na avalia\u00e7\u00e3o Core Web Vitals \u00e9 aproximadamente 1,4 segundos em desktop e 2,0 segundos em mobile – embora esses n\u00fameros mudem conforme a web evolui.<\/p>\n
Para TTFB, a pr\u00f3pria orienta\u00e7\u00e3o do Google classifica abaixo de 800 milissegundos como “bom” e acima de 1.800 milissegundos como “ruim”. As aplica\u00e7\u00f5es otimizadas com cache CDN normalmente alcan\u00e7am TTFB na faixa de 200\u2013500 milissegundos para respostas em cache.<\/p>\n
Para tempo total de carregamento da p\u00e1gina, o Web Almanac do HTTP Archive consistentemente reporta tempos medianos na faixa de 3\u20134 segundos no mobile e 1,5\u20132 segundos no desktop para o percentil 50. Aplica\u00e7\u00f5es de alto desempenho que visam o percentil 75 buscam tempos de carregamento abaixo de 2 segundos no desktop.<\/p>\n
Para taxa de erros, uma aplica\u00e7\u00e3o web de produ\u00e7\u00e3o madura deve manter a taxa abaixo de 0,1% (1 em 1.000 requisi\u00e7\u00f5es). Uma taxa acima de 1% representa um problema significativo de experi\u00eancia do usu\u00e1rio e exige investiga\u00e7\u00e3o imediata.<\/p>\n
Para disponibilidade, aplica\u00e7\u00f5es empresariais normalmente visam 99,9% de uptime (8,77 horas de downtime por ano). Aplica\u00e7\u00f5es de alta criticidade t\u00eam metas de 99,95% (4,38 horas por ano) ou 99,99% (52,56 minutos por ano).<\/p>\n
Conclus\u00e3o<\/h2>\n
O desempenho de aplica\u00e7\u00f5es web n\u00e3o \u00e9 um projeto pontual. \u00c9 uma pr\u00e1tica cont\u00ednua. P\u00e1ginas desaceleram \u00e0 medida que aplica\u00e7\u00f5es crescem. Novas depend\u00eancias adicionam lat\u00eancia. Padr\u00f5es de tr\u00e1fego mudam. A infraestrutura envelhece.<\/p>\n
As organiza\u00e7\u00f5es que mant\u00eam aplica\u00e7\u00f5es web r\u00e1pidas e confi\u00e1veis n\u00e3o s\u00e3o aquelas que fizeram uma auditoria de desempenho uma vez e implementaram algumas otimiza\u00e7\u00f5es. S\u00e3o aquelas que monitoram continuamente, detectam regress\u00f5es cedo, acompanham tend\u00eancias ao longo do tempo e tratam o desempenho como uma preocupa\u00e7\u00e3o de primeira classe no processo de desenvolvimento.<\/p>\n
A plataforma de monitoramento de aplica\u00e7\u00f5es web da Dotcom-Monitor<\/a> oferece \u00e0 sua equipe a capacidade pr\u00f3-ativa, em navegador real, multi-localiza\u00e7\u00e3o de monitoramento sint\u00e9tico<\/a> para fazer exatamente isso – medir o que importa, detectar problemas antes que os usu\u00e1rios os encontrem e construir a base de dados de desempenho que toda decis\u00e3o de otimiza\u00e7\u00e3o deveria ter.<\/p>\nComece a monitorar hoje mesmo suas jornadas de usu\u00e1rio mais cr\u00edticas. O desempenho n\u00e3o \u00e9 sentido em milissegundos – \u00e9 sentido em convers\u00f5es realizadas, carrinhos conclu\u00eddos e usu\u00e1rios que retornam em vez de procurar uma alternativa mais r\u00e1pida.<\/p>\n","protected":false},"excerpt":{"rendered":"
O desempenho de aplica\u00e7\u00f5es web n\u00e3o \u00e9 apenas uma preocupa\u00e7\u00e3o t\u00e9cnica – \u00e9 uma necessidade de neg\u00f3cio. Pesquisas do Google mostram que, \u00e0 medida que o tempo de carregamento da p\u00e1gina aumenta de um segundo para cinco segundos, a probabilidade de um visitante m\u00f3vel sair rapidamente aumenta em 90%. O relat\u00f3rio “Milliseconds Make Millions” da […]<\/p>\n","protected":false},"author":39,"featured_media":34014,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5170],"tags":[],"class_list":["post-34076","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nao-categorizado"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/34076","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/comments?post=34076"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/34076\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media\/34014"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media?parent=34076"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/categories?post=34076"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/tags?post=34076"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Ilustra\u00e7\u00e3o](\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/06\/website-monitoring-best-practices-featured-browser-facets.webp\")
O desempenho de aplica\u00e7\u00f5es web n\u00e3o \u00e9 apenas uma preocupa\u00e7\u00e3o t\u00e9cnica – \u00e9 uma necessidade de neg\u00f3cio. Pesquisas do Google mostram que, \u00e0 medida que o tempo de carregamento da p\u00e1gina aumenta de um segundo para cinco segundos, a probabilidade de um visitante m\u00f3vel sair rapidamente aumenta em 90%. O relat\u00f3rio “Milliseconds Make Millions” da Deloitte de 2020 descobriu que uma melhoria de 0,1 segundo na velocidade do site m\u00f3vel aumentou as taxas de convers\u00e3o do varejo em 8,4%.<\/p>\n