Checklist de desempenho para vitrines mobile-first com orçamento limitado

O que uma vitrine mobile “rápida” realmente significa

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:

• Mostrar uma primeira vista útil rápido (imagem, nome, preço e um caminho claro para comprar).
• Manter o layout estável enquanto o conteúdo carrega.
• Tornar a rolagem suave em listas e galerias.
• Fazer o add-to-cart parecer instantâneo, mesmo em redes lentas.
• Manter os passos do checkout simples e previsíveis.

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.

Escolha suas páginas alvo e métricas de linha de base

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:

• LCP, INP e CLS (da sua ferramenta de desempenho)
• Qual é o elemento LCP (imagem principal, imagem do produto, título)
• Uma nota de 10 segundos sobre a “sensação”: o que parece tarde, o que está lento, o que pula
• O dispositivo e a rede usados

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: o que priorizar primeiro

Core Web Vitals são três sinais que mapeiam bem como a página parece rápida em um telefone:

• LCP: quão rápido o conteúdo principal aparece (frequentemente imagem hero ou título do produto).
• INP: quão rápido a página reage quando alguém toca.
• CLS: quanto o layout se desloca enquanto carrega.

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:

• LCP: imagens hero gigantes, carregar um carrossel primeiro, resposta lenta do servidor, scripts que bloqueiam a renderização.
• INP: tags de terceiros pesadas, muito JavaScript para filtros, re-renderizações caras em React.
• CLS: barras promocionais que aparecem depois, dimensões de imagem ausentes, troca brusca de fontes.

Metas úteis para usuários móveis:

• LCP: abaixo de 2,5s para páginas-chave; abaixo de 3,0s pode ser aceitável em páginas menos críticas.
• INP: abaixo de 200ms; até 300ms se você tiver muitas tags e ainda estiver arrumando o básico.
• CLS: abaixo de 0,1 em todos os lugares.

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.

Imagens: o checklist de maior ROI

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:

• Sirva tamanhos responsivos para que telefones nunca baixem imagens de desktop. Gere algumas larguras (por exemplo 320, 640, 960, 1280) e use srcset com um valor sizes realista.
• Use formatos modernos com fallback. Prefira AVIF ou WebP onde suportado, mantendo JPEG/PNG para navegadores antigos.
• Comprima mais para grades e thumbnails. Cards de categoria raramente precisam de qualidade “foto‑perfeita”.
• Lazy-load abaixo da dobra, não a imagem chave. Mantenha o hero e a imagem principal do produto como eager, depois carregue o resto preguiçosamente.
• Pré-carregue apenas a única imagem que provavelmente será seu LCP.

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.

CSS, fontes e scripts: mantenha a primeira vista leve

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: ficar bonito sem reduzir a velocidade

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).

CSS e scripts: envie menos, depois

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:

• Limite fontes e pré-carregue apenas o que a primeira vista usa.
• Mantenha o CSS acima da dobra mínimo e remova estilos não usados.
• Defer scripts não críticos e adie widgets de terceiros até depois do primeiro render.
• Faça split de código para que o mobile carregue só o necessário para a primeira vista.

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.

Decisões SSR vs CSR para uma vitrine

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:

• Use SSR (server-side rendering) para páginas de produto e categoria. São pontos de entrada comuns vindos de busca, anúncios e redes sociais. SSR entrega conteúdo real na tela mais rápido e facilita atingir um bom LCP.
• Use CSR (client-side rendering) para páginas acessadas depois que alguém já está navegando, como configurações de conta, histórico de pedidos, listas salvas e dashboards internos.

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:

• Delays de hydration: muito JavaScript no primeiro carregamento faz toques parecerem ignorados e piora o INP.
• Estados de loading: skeletons que mudam de tamanho podem causar CLS.
• Widgets de terceiros: avaliações, chat e trackers podem bloquear a main thread.
• Fetch de dados: duplicar chamadas no servidor e no cliente desperdiça tempo e bateria.
• Personalização: mantenha “Olá, João” e recomendações apenas no cliente se não forem necessários para comprar.

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.

Checklist de cache que não quebra atualizações

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.

1) Cache do navegador: vida longa para arquivos verdadeiramente estáticos

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.

2) Cache-busting: tornar atualizações seguras

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.

3) Cache de servidor e API: cacheie leituras, não surpresas

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:

• Ativos estáticos: cache longo (por exemplo, 30–365 dias) e marque como immutable somente se os nomes de arquivo forem versionados.
• Páginas HTML: cache curto ou stale-while-revalidate para que atualizações apareçam rapidamente.
• Respostas de API: cache breve (30–300s) para endpoints de leitura e chave por parâmetros de query.
• Invalidação: tenha um passo claro de purge no deploy (ou aumente a versão do build) para forçar refresh.
• CDN: se o orçamento permitir, coloque imagens e arquivos estáticos atrás de um CDN e compare métricas reais (TTFB, LCP móvel) antes e depois.

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.

Velocidade de interação: melhorar INP em dispositivos reais

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:

• Faça o add-to-cart parecer instantâneo: atualize a UI primeiro (estado do botão, contador do carrinho), depois sincronize em background.
• Corte trabalho na main-thread ao tocar e rolar: evite parsing pesado ou re-renderizar a página inteira quando um componente muda.
• Debounce em busca e filtros: não dispare requisição a cada keystroke; dê feedback claro “Atualizando…”.
• Use skeletons que combinem com o layout final para não causar movimento.
• Dê a cada botão um estado claro de pressionado para que o usuário receba feedback imediato.

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.

Passo a passo: uma passada de 60 minutos em uma página

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.

A passada de 60 minutos

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Erros comuns que deixam vitrines econômicas lentas

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:

• Lazy-loading da imagem hero ou do primeiro produto (frequentemente seu LCP).
• Carrosséis que carregam tarde e empurram o conteúdo para baixo.
• Carregar múltiplas ferramentas de analytics, chat e A/B antes da página ser legível.
• Over-caching de HTML de forma a servir preços ou inventário obsoletos.
• Enviar UI de desktop para mobile e escondê-la com CSS (o telefone ainda baixa tudo).

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:

• Eager-load apenas a primeira imagem significativa, depois lazy-load o resto.
• Substitua grandes carrosséis por uma imagem única mais uma pequena galeria.
• Mova tags não essenciais para depois do consentimento ou após a primeira interação.
• Cacheie ativos longamente, cacheie HTML por pouco tempo e revalide dados de produto com frequência.
• Construa um layout verdadeiramente móvel em vez de esconder blocos de desktop.

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.

Checklist rápido que você pode rodar antes de cada release

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.

O gate pré-release de 10 minutos

Teste páginas chave (home, categoria, produto, início do checkout) em um Android de gama média real ou em um perfil throttled:

• LCP: conteúdo principal aparece rápido e permanece estável.
• INP: toques (adicionar ao carrinho, seletor de tamanho, checkout) respondem rápido sem sensação de “travado”.
• CLS: layout não pula quando imagens, banners ou fontes carregam.
• Imagens: tamanhos corretos, formato moderno, comprimidas; lazy-load só abaixo da dobra.
• Scripts: apenas tags de terceiros essenciais carregam cedo; todo o resto espera.

Se algo estiver errado, corrija o maior problema visível primeiro. Uma imagem enorme ou um script cedo pode arruinar um release.

Checagem de cache e renderização

Escolhas de cache e renderização devem fazer páginas de entrada parecerem rápidas sem servir preços velhos ou quebrar carrinho:

• Ativos estáticos: cache longo para arquivos com hash e confirme que um novo build muda os nomes.
• HTML e APIs: TTL curto ou revalidação; nunca cache conteúdo por usuário como carrinho e conta.
• Renderização: a primeira tela mostra sem travamentos; evite spinners para conteúdo básico de entrada.
• Atualizações: confirme que você pode reverter rápido se um deploy piorar o LCP ou quebrar o checkout.

Se você usa Koder.ai, manter um simples “snapshot de desempenho” antes dos releases facilita comparar, reverter e retestar.

Exemplo: melhorar uma pequena loja em 3 semanas

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).

Semana 1: imagens e estabilidade de layout

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.

Semana 2: scripts de terceiros e filtros mais suaves

Em seguida reduzem trabalho na main-thread:

• Carregam analytics e chat após a primeira vista.
• Removem trackers duplicados e pixels não usados.
• Simplificam filtros e adicionam pequeno delay antes de aplicar.
• Fazem split de código para que cada página carregue só o necessário.

Resultado: melhor INP. Toques registram rápido e aplicar filtros para de travar durante a rolagem.

Semana 3: SSR onde compensa, CSR onde é aceitável

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:

• Meçam CWV e façam um teste rápido em dispositivo real.
• Mantenham mudanças que melhorem LCP/CLS/INP sem quebrar tracking ou checkout.
• Revertam mudanças que prejudiquem conversão ou aumentem erros.

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.

Próximos passos: torne desempenho parte da sua rotina de build

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.

Transforme seu checklist em um loop repetível

Escolha 1–2 páginas que gerem receita (frequentemente home, categoria, produto, início do checkout) e use uma rotina pequena:

• Baseline: registre Core Web Vitals e um rápido teste em dispositivo real em 4G lento.
• Mudança: envie uma melhoria clara (um conjunto de imagens, um delay de script, um ajuste de cache).
• Re-teste: compare no mesmo dispositivo e rede.
• Decida: mantenha só se a métrica importante melhorar.
• Log: anote o que mudou para repetir em outras páginas.

Isso evita otimizações aleatórias e mantém foco no que os usuários notam.

Mantenha um orçamento de desempenho simples

Orçamentos evitam que a página vá inchando. Mantenha-os pequenos o suficiente para aplicar em revisões:

• Imagens: limite o peso da primeira vista e exija tamanhos responsivos.
• Scripts: limite tags de terceiros e defina um JS máximo para páginas-chave.
• Fontes: permita 0–1 famílias customizadas; use fontes do sistema para o texto do corpo.
• Layout: nada de banners que carregam tarde e empurram conteúdo para baixo.

Orçamentos não são sobre perfeição. São guardrails que protegem a experiência móvel.

Torne seguro mover rápido

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.