Use este checklist de desempenho para vitrines mobile-first para priorizar Core Web Vitals, otimizar imagens, escolher SSR vs CSR e configurar cache com orçamento apertado.
Uma vitrine mobile rápida não é sobre notas perfeitas em testes laboratoriais. É sobre como ela se comporta em um telefone real com sinal ruim e uma única mão. Algo útil aparece rápido, a página não salta enquanto as imagens carregam e todo toque recebe uma resposta clara.
Velocidade importa porque compradores decidem rápido. Se a primeira vista é lenta ou confusa, as pessoas saem. Se o site parece travado, a confiança cai. E se o carrinho ou checkout hesitam, as taxas de conclusão diminuem. No mobile, até um pequeno atraso parece maior porque a tela é pequena e distrações estão a um swipe.
Com orçamento limitado, o objetivo não é reconstruir tudo. Pense em “grandes ganhos primeiro”: corrija as coisas que mais impactam a experiência e pule mudanças que levam semanas e salvam milissegundos. A maioria das lojas obtém a maior parte do benefício com um punhado de ajustes práticos.
Mantenha estas metas em mente:
Uma falha comum: a imagem principal carrega tarde, o botão “Adicionar ao carrinho” desloca para baixo e os usuários tocam na coisa errada ou desistem. Definir dimensões de imagem e carregar a imagem principal mais cedo frequentemente melhora a experiência mais do que trocar frameworks.
Se você está construindo com Koder.ai, as mesmas prioridades se aplicam: entregue a menor e mais rápida primeira vista possível, depois adicione recursos sem deixar a página pesada.
Trabalhos de desempenho com orçamento vão melhor quando o escopo é pequeno e mensurável. Comece com 1–2 páginas que mais influenciam receita e confiança, depois meça do mesmo jeito sempre.
Escolha páginas onde usuários móveis ou ficam ou saem. Para muitas lojas, isso é a página de produto mais a home (primeira impressão) ou uma página de categoria (navegação). Se o checkout é seu maior ponto de queda, inclua-o, mas mantenha o escopo inicial enxuto.
Depois liste as ações que as pessoas realmente fazem nessas páginas. Pense em toques, não em features: buscar, aplicar um filtro, abrir um produto, mudar variante, adicionar ao carrinho. Isso ajuda a detectar problemas que testes laboratoriais não mostram, como filtros lentos ou feedback atrasado no add-to-cart.
Use dois dispositivos reais consistentemente: um Android de gama média (onde os problemas aparecem rápido) e um iPhone padrão. Teste do mesmo ponto de Wi‑Fi ou mesmo hotspot móvel para que os resultados sejam comparáveis.
Para cada página alvo, capture uma linha de base simples:
Se sua página de produto tem LCP de 5,2s em um Android de gama média e o elemento LCP é a imagem principal do produto, você já sabe onde o trabalho de alto ROI provavelmente começa.
Core Web Vitals são três sinais que mapeiam bem como a página parece rápida em um telefone:
Uma ordem prática: resolva grandes problemas de LCP primeiro, depois trate INP e por fim ajuste CLS. Uma página que demora 5 segundos para mostrar o conteúdo principal ainda vai parecer lenta mesmo se os toques estiverem rápidos. Depois que o LCP melhora, atrasos de input e deslocamentos ficam muito mais notáveis.
Problemas comuns de vitrine que se mapeiam para cada métrica:
Metas úteis para usuários móveis:
Defina metas por tipo de página, não só site-wide. Detalhes de produto e checkout devem ser mais rígidos porque é onde as pessoas decidem e compram. Home pages podem ser um pouco mais flexíveis no LCP, mas mantenha o CLS apertado para que a página pareça estável.
Se você puder consertar apenas uma coisa em uma vitrine com orçamento, corrija imagens. No mobile, imagens dominam o tamanho de download, atrasam o LCP e podem causar shifts quando as dimensões não estão definidas.
Checklist de imagens que cobre a maioria das lojas:
srcset com um valor sizes realista.Uma medida preventiva que evita muita dor: sempre defina width e height (ou aspect-ratio em CSS) para cada imagem. Isso é uma vitória fácil para CLS.
Um resultado típico: uma grade de categoria de 2 MB pode cair para menos de 400 KB ao trocar imagens de grade para WebP, servir no máximo 640px no mobile e reduzir um pouco a qualidade. A maioria dos compradores não vai notar, mas o tempo de carregamento cai bastante.
A primeira tela deve ser barata para renderizar. No mobile, cada fonte extra, regra de CSS e script compete pelo mesmo orçamento pequeno de CPU e rede.
Fontes customizadas são um atraso “silencioso” comum. Se a marca permitir, comece com fontes do sistema e adicione uma fonte customizada depois.
Mantenha enxuto: uma família, um ou dois pesos (por exemplo 400 e 600) e apenas os conjuntos de caracteres necessários. Pré-carregue apenas o único arquivo de fonte usado acima da dobra e garanta que o texto seja exibido imediatamente (sem título em branco enquanto a fonte carrega).
O CSS cresce rápido, especialmente com bibliotecas de UI e componentes repetidos. Mantenha o CSS acima da dobra pequeno e carregue o resto depois que a primeira vista estiver visível. Remova estilos não usados regularmente.
Para scripts, a regra é simples: nada não essencial roda antes do usuário poder ver e começar a ler. Bundles pesados de analytics, chat, A/B testing e sliders podem esperar.
Uma passagem rápida para home e páginas de produto:
Se sua vitrine é em React (incluindo código exportado do Koder.ai), considere dividir a galeria de produtos e avaliações em chunks separados. Carregue primeiro título, preço e imagem primária, depois hidrate o resto após a página já estar utilizável.
Para uma loja com orçamento, o objetivo é fazer as páginas de entrada parecerem instantâneas, mesmo em um telefone fraco. A estratégia de renderização afeta quase todas as outras otimizações.
Uma regra prática:
Um híbrido prático funciona bem: SSR a estrutura da página e o conteúdo crítico (título, preço, imagem principal, botão de compra, primeiras avaliações), depois hidrate widgets mais pesados.
Atenções que frequentemente prejudicam o mobile:
Exemplo: faça SSR da grade de categoria com 12 itens e preços, mas carregue os filtros (tamanho, cor) após o primeiro paint. Compradores podem rolar imediatamente e a UI de filtro pode chegar um momento depois sem deslocar o layout.
Cache economiza dinheiro e segundos, mas também pode prender clientes em preços antigos, JS quebrado ou imagens faltando. Cacheie o que muda raramente por muito tempo e garanta que qualquer coisa que você atualize possa ser substituída rapidamente.
Comece com ativos estáticos: imagens, CSS e bundles JS. Dê tempos longos de cache para que visitas repetidas sejam rápidas, especialmente em dados móveis.
Cache longo só funciona se os nomes de arquivo mudarem quando o conteúdo muda. Use versionamento de arquivos (hashes nos nomes) para que novos builds sejam arquivos novos.
Cacheie coisas de leitura intensa que não mudam por usuário (shell da home, páginas de categoria, listas de produto, sugestões de busca). Evite cachear qualquer coisa que precise estar fresca por usuário (carrinho, checkout, páginas de conta).
Checklist prático:
Se você faz deploy via Koder.ai na AWS, amarre o cache às releases: versionar ativos, manter HTML com frescor curto e tornar rollback previsível associando caches a uma versão de release.
INP é sobre o que acontece depois de um toque. No mobile, atrasos saltam aos olhos. Um botão que parece “morto” por 200–500ms pode perder uma venda mesmo que a página carregue rápido.
Teste em um telefone de baixa gama se puder, não só no laptop. Tente quatro tarefas: abrir uma página de produto, mudar uma variante, adicionar ao carrinho e abrir o carrinho. Se algum toque parecer lento ou a página travar enquanto rola, esse é o trabalho de INP.
Correções que normalmente movem a agulha sem grandes reescritas:
Se a chamada de carrinho demora 1–2 segundos em uma conexão lenta, não bloqueie a página. Mostre o estado pressionado, adicione o item otimisticamente e só interrompa o fluxo se a requisição falhar.
Faça um passe de velocidade em uma única página de alto tráfego primeiro (geralmente home ou uma página de produto principal). Use um telefone real se possível, ou Chrome DevTools com throttling e um perfil Android de gama média.
Escolha uma página e identifique o elemento LCP. Carregue a página uma vez e anote o que vira LCP (imagem hero, imagem do produto ou grande headline). Escreva o tempo do LCP.
Corrija o dimensionamento da imagem e pré-carregue o recurso LCP. Garanta que a imagem LCP tenha width/height corretos (ou aspect-ratio), sirva uma versão menor para mobile, use formatos modernos e pré-carregue apenas essa imagem.
Adie scripts não críticos na primeira vista. Atrase chat widgets, heatmaps, A/B testing e bundles pesados de reviews até a página estar utilizável.
Pare layouts que pulam. Reserve espaço para banners, carrosséis, barras de cookies e estrelas de avaliação. Evite inserir conteúdo acima da dobra depois do load.
Re-teste nas mesmas condições. Compare LCP e CLS. Se o LCP não melhorar, verifique tempo de resposta do servidor ou CSS que bloqueia render.
Se você constrói com uma ferramenta orientada por chat como Koder.ai, torne isso uma rotina repetível: capture um snapshot antes/depois para que possa reverter rapidamente quando uma mudança deixar a página mais lenta.
A maioria das lentidões por orçamento é auto infligida: mais um plugin, mais um slider, mais uma tag. Uma regra útil: mostre conteúdo real rápido, depois melhore.
Erros que aparecem frequentemente:
Um padrão típico: uma página de produto puxa uma biblioteca de carrossel enorme mais vários trackers, e o botão “Adicionar ao carrinho” só fica clicável tarde. Compradores não ligam para motion sofisticado se tocar parece lento.
Correções rápidas que ajudam sem reconstruir:
Se você usa Koder.ai, trate desempenho como um recurso: pré-visualize mudanças em um telefone de gama média e use snapshots para reverter rápido quando um novo widget deixar as coisas lentas.
Um check rápido antes do release vale mais que um grande projeto de desempenho. Trate isso como um gate: se a página parecer lenta em um telefone barato, corrija antes de enviar.
Teste páginas chave (home, categoria, produto, início do checkout) em um Android de gama média real ou em um perfil throttled:
Se algo estiver errado, corrija o maior problema visível primeiro. Uma imagem enorme ou um script cedo pode arruinar um release.
Escolhas de cache e renderização devem fazer páginas de entrada parecerem rápidas sem servir preços velhos ou quebrar carrinho:
Se você usa Koder.ai, manter um simples “snapshot de desempenho” antes dos releases facilita comparar, reverter e retestar.
Uma pequena vitrine vende cerca de 200 produtos. A maioria dos visitantes chega por anúncios sociais em mobile, aterissa numa página de categoria e depois abre uma página de produto. A equipe tem tempo de desenvolvedor limitado, então o plano é direto: deixar as duas primeiras páginas rápidas e estáveis, depois melhorar a velocidade de interação.
Eles monitoram algumas páginas-chave (categoria principal, produto principal, carrinho) e focam em LCP (velocidade do conteúdo principal), CLS (estabilidade do layout) e INP (responsividade do toque).
Começam pelos maiores ganhos nas páginas de categoria e produto: imagens no tamanho certo (sem 2000px em uma tela de 360px), formatos modernos (WebP/AVIF), compressão agressiva para grades e dimensões explícitas para parar shifts. Pré-carregam a imagem hero numa product page e lazy-loadam o resto.
Resultado: menos saltos ao rolar e páginas que parecem mais rápidas mesmo antes de trabalho mais profundo.
Em seguida reduzem trabalho na main-thread:
Resultado: melhor INP. Toques registram rápido e aplicar filtros para de travar durante a rolagem.
Adicionam SSR para páginas de entrada (home, categoria principal, produto) para que o conteúdo apareça mais cedo em conexões lentas. Mantêm CSR para páginas de conta e histórico.
Para decidir se cada mudança vale manter:
Se você constrói no Koder.ai, snapshots e rollback suportam experimentação mais segura ao ajustar renderização, scripts ou estrutura de página.
Um checklist só ajuda se virar hábito. Mantenha simples: meça, mude uma coisa, meça de novo. Se uma mudança piorar a página, desfaça rápido e siga em frente.
Escolha 1–2 páginas que gerem receita (frequentemente home, categoria, produto, início do checkout) e use uma rotina pequena:
Isso evita otimizações aleatórias e mantém foco no que os usuários notam.
Orçamentos evitam que a página vá inchando. Mantenha-os pequenos o suficiente para aplicar em revisões:
Orçamentos não são sobre perfeição. São guardrails que protegem a experiência móvel.
Trate desempenho como um recurso: tenha um plano de rollback seguro. Se sua plataforma suporta snapshots e rollback, use-os antes dos releases para reverter uma mudança lenta em minutos.
Se você quer iterar rápido em trade-offs de renderização e desempenho, Koder.ai (koder.ai) pode ser útil para prototipar e enviar mudanças com exportação de código-fonte quando estiver pronto. O hábito ainda é o mais importante: mudanças pequenas, checagens frequentes e reversões rápidas quando o desempenho cair.
Uma vitrine “rápida” passa uma sensação de rapidez e estabilidade em um telefone real: o conteúdo principal aparece cedo, o layout não pula e os toques recebem feedback imediato.
Priorize velocidade percebida: mostre a imagem/nome/preço do produto e um caminho claro para comprar rapidamente, depois carregue os extras.
Comece com 1–2 páginas “que geram dinheiro” onde usuários móveis decidem ficar ou sair, normalmente:
Inclua checkout apenas se for seu maior ponto de saída, mas mantenha o escopo inicial pequeno para poder medir mudanças claramente.
Registre o básico por página alvo:
Consistência importa mais que a ferramenta perfeita — teste do mesmo jeito sempre.
Siga esta ordem prática:
Se o conteúdo principal aparece tarde, todo o resto ainda vai parecer lento — mesmo que as interações estejam rápidas.
Faça isso primeiro:
Mantenha a primeira visualização leve:
O objetivo: os primeiros segundos do telefone devem desenhar o conteúdo, não rodar extras.
Bom padrão:
Fique atento a atrasos de hydration — muito JavaScript no primeiro carregamento prejudica o INP e faz toques parecerem ignorados.
Cache com segurança:
Assim você acelera visitas repetidas sem deixar usuários presos a preços ou arquivos antigos.
Foque na “sensação” do toque:
Se a rede for lenta, não bloqueie a página — dê feedback imediato e trate falhas depois.
Faça um checklist rápido numa página:
Se construir com Koder.ai, use snapshots e rollback para reverter rapidamente quando uma mudança deixar a página lenta ou com jank.
width/height ou aspect-ratio para evitar shiftsUma imagem principal bem dimensionada e pré-carregada costuma valer mais que semanas de reescrita.