Como Reduzir o LCP em Lojas de E-commerce
O LCP (Largest Contentful Paint) e a metrica mais visivel dos Core Web Vitals. Mede quanto tempo leva para o maior elemento na viewport ser renderizado completamente. Para e-commerce, isso quase sempre e a hero image na homepage ou a imagem principal do produto na PDP. Um LCP acima de 2.5 segundos e considerado ruim pelo Google e impacta diretamente o ranqueamento. Em lojas online, LCP lento significa que o usuario fica esperando o conteudo principal aparecer. Se a imagem do produto demora para carregar, a primeira impressao e de lentidao. O usuario nao sabe (nem se importa) se o problema e a imagem, o servidor ou o JavaScript. Ele so sabe que a pagina e lenta. E vai embora. Reduzir o LCP exige atacar multiplas frentes simultaneamente: server response time, caminho critico de renderizacao, carregamento de recursos e priorizacao correta. Este artigo detalha cada causa e apresenta solucoes praticas testadas em lojas reais de VTEX, Shopify e headless.
O que causa LCP alto em e-commerce
O LCP e composto por quatro subfases. Cada uma pode ser o gargalo. TTFB (Time to First Byte): o tempo entre a requisicao do browser e o primeiro byte da resposta. Inclui DNS, TCP, TLS e processamento do servidor. Se o TTFB e 1.5s, voce so tem 1 segundo para todo o resto se quiser ficar dentro do limite de 2.5s. Resource load delay: tempo entre o TTFB e o inicio do download do recurso LCP. Causado por cadeias de dependencia. O browser precisa baixar o HTML, parsear, encontrar o CSS, baixar o CSS, parsear, e so entao descobrir que precisa da imagem. Resource load duration: tempo para baixar o recurso LCP em si. Imagens grandes em conexoes lentas. Uma hero image de 500KB em 3G pode levar 3-4 segundos so para baixar. Render delay: tempo entre o download do recurso e a renderizacao na tela. Causado por JavaScript bloqueante, CSS que esconde o elemento ou fontes que atrasam a renderizacao de texto. Em lojas de e-commerce, os culpados mais comuns sao: hero images nao otimizadas (formato, tamanho, ausencia de preload), fontes web que bloqueiam renderizacao, CSS nao critico no head, server response time lento (backend pesado, ausencia de cache), JavaScript que bloqueia renderizacao e carroseis com lazy loading incorreto na primeira imagem.
Otimizacao de hero image e imagem principal de produto
A hero image e o elemento LCP em 70% das homepages de e-commerce. A imagem principal do produto e o LCP em 90% das PDPs. Otimiza-las e a acao de maior impacto. Preload: adicione link rel preload para a imagem LCP no head do HTML. Isso diz ao browser para comecar a baixar a imagem imediatamente, sem esperar o CSS ser parseado. Para imagens responsivas, use imagesrcset no preload. Formato e compressao: sirva WebP ou AVIF. Uma hero image que seria 400KB em JPEG fica 250KB em WebP e 180KB em AVIF. A reducao de tamanho se traduz diretamente em menor tempo de download. Tamanho correto: nao sirva uma imagem de 1920x1080 para um celular de 375px. Use srcset com breakpoints que cobrem os tamanhos reais dos dispositivos do seu publico. Analise o Google Analytics para saber as resolucoes mais comuns. Fetchpriority high: adicione fetchpriority high na tag img da imagem LCP. Isso instrui o browser a priorizar o download dessa imagem sobre outros recursos. Funciona em Chrome e Edge. Evite lazy loading no LCP: a imagem LCP nunca deve ter loading lazy. Isso atrasa o inicio do download ate a imagem entrar na viewport, adicionando centenas de milissegundos ao LCP. Apenas imagens abaixo do fold devem ter lazy loading. Inlining de imagens pequenas: para imagens LCP menores que 10KB, considere inline como base64 no HTML. Elimina um roundtrip de rede. Util para logos e icones criticos, nao para hero images grandes.
Font loading e impacto no LCP de texto
Quando o LCP e um elemento de texto (heading, paragrafo), fontes web podem atrasar significativamente a renderizacao. O browser so renderiza texto com a fonte custom depois que ela e baixada. Se a fonte demora 800ms, o texto fica invisivel (FOIT) ou muda de aparencia (FOUT) por 800ms. font-display swap: a propriedade CSS font-display swap instrui o browser a mostrar texto com uma fonte fallback imediatamente e trocar para a fonte custom quando ela carregar. O texto aparece rapido (bom para LCP) mas pode causar um flash visual (impacto no CLS). E o trade-off mais aceito. Preload de fontes: adicione link rel preload para os arquivos de fonte mais criticos. Limite a 1-2 fontes no maximo. Cada fonte preloaded compete por bandwidth com outros recursos. Subconjunto de fontes: se voce usa uma fonte apenas para headings em portugues, gere um subset que inclui apenas caracteres latinos. Uma fonte completa pode ter 200KB. Um subset latino fica abaixo de 30KB. Ferramentas como glyphhanger e subfont automatizam isso. Self-hosting vs CDN: hospedar fontes no mesmo dominio elimina a necessidade de conexao a dominios externos (fonts.googleapis.com). Isso remove DNS lookup, TCP e TLS handshake. Self-hosting com cache agressivo e sempre mais rapido que Google Fonts. Variable fonts: uma unica variable font substitui multiplos arquivos (regular, bold, italic). Reduz requisicoes e permite cache mais eficiente. Se voce usa 3+ pesos da mesma familia, variable font e a escolha certa.
CSS critico e eliminacao de bloqueio de renderizacao
CSS e render-blocking por padrao. O browser nao renderiza nada ate todo o CSS no head ser baixado e parseado. Se o CSS total e 200KB mas apenas 15KB sao necessarios para renderizar o conteudo above-the-fold, os outros 185KB estao bloqueando a renderizacao desnecessariamente. Critical CSS inline: extraia o CSS necessario para o conteudo above-the-fold e coloque inline no head do HTML. O restante carrega de forma assincrona. Ferramentas como Critical, Critters e PurgeCSS automatizam a extracao. Carregamento assincrono do CSS restante: use a tecnica do link rel preload com onload para carregar CSS nao-critico sem bloquear renderizacao. O padrao e: link rel preload href styles.css as style onload this.rel stylesheet. Isso inicia o download imediatamente mas so aplica o CSS quando carregado, sem bloquear. Remova CSS nao utilizado: lojas que usam frameworks CSS como Bootstrap ou Tailwind frequentemente carregam o framework inteiro quando apenas 10-20% e usado. PurgeCSS, UnCSS e o purge nativo do Tailwind removem classes nao utilizadas. Em Tailwind 4, o tree-shaking e automatico. Evite @import em CSS: cada @import cria uma requisicao sequencial. O browser baixa o primeiro CSS, parseia, encontra o @import, e so entao comeca a baixar o segundo. Use link tags paralelas ou concatene os arquivos. Minificacao: sempre minifique CSS em producao. Remove espacos, comentarios e shorthand properties. Reducao tipica de 15-25%. Ferramentas como cssnano e lightningcss fazem isso automaticamente no build.
Server response time e TTFB
O TTFB (Time to First Byte) e o fundamento do LCP. Se o servidor demora 2 segundos para responder, e matematicamente impossivel ter LCP abaixo de 2.5s. O TTFB ideal e abaixo de 200ms para a maioria dos usuarios. Cache de pagina: a forma mais eficaz de reduzir TTFB. Paginas de produto, categoria e homepage raramente mudam a cada requisicao. Cache na CDN com invalidacao por webhook quando dados mudam. Stale-while-revalidate para nunca servir uma pagina fria. SSR com streaming: em vez de esperar toda a pagina ser gerada no servidor, envie o HTML progressivamente. React 18 com Suspense e streaming SSR permite enviar o shell imediatamente e preencher o conteudo conforme fica pronto. O browser comeca a renderizar antes. Edge rendering: mova a geracao de paginas para a edge (Cloudflare Workers, Vercel Edge, Deno Deploy). Elimina a latencia de rede entre usuario e servidor. Uma pagina gerada no edge de Sao Paulo chega em 20-50ms para usuarios brasileiros vs 200-400ms de um servidor nos EUA. Otimizacao de banco de dados: queries lentas sao causa comum de TTFB alto em lojas com catalogo grande. Indices adequados, cache de query results, e read replicas reduzem o tempo de resposta do backend. Reduzir redirects: cada redirect adiciona um roundtrip completo (100-300ms). Audite redirects desnecessarios. O canonical deve ser servido diretamente. Redirects de HTTP para HTTPS e de www para non-www devem acontecer na edge, nao no servidor de origem.
Preconnect, preload e priorizacao de recursos
Resource hints sao instrucoes no HTML que dizem ao browser quais recursos serao necessarios em breve, permitindo que ele comece a busca-los antecipadamente. preconnect: estabelece conexao (DNS + TCP + TLS) com dominios de terceiros antes que o browser descubra que precisa deles. Use para CDN de imagens, APIs e fontes externas. Exemplo: link rel preconnect href cdn.shopify.com. Economia tipica: 100-300ms por dominio. dns-prefetch: versao mais leve do preconnect que so faz o DNS lookup. Use para dominios que talvez sejam usados mas nao com certeza. Custo zero se nao for usado. preload: forca o download imediato de um recurso especifico. Use para a imagem LCP, fonte principal e CSS critico. Cuidado: preload demais dilui o beneficio. Limite a 3-5 recursos realmente criticos. Priority Hints (fetchpriority): atributo que permite definir prioridade alta, baixa ou automatica para recursos. fetchpriority high na imagem LCP. fetchpriority low em imagens abaixo do fold. Browsers modernos usam essa informacao para reordenar a fila de downloads. Estrategia pratica para e-commerce: preconnect para CDN de imagens e API de precos. preload para hero image e fonte principal. fetchpriority high na imagem do produto. defer em todos os scripts nao criticos. async no script de analytics. Essa combinacao tipicamente reduz LCP em 300-800ms.
Dicas por plataforma: VTEX, Shopify e headless
Cada plataforma tem suas particularidades para otimizacao de LCP. VTEX Store Framework: o maior vilao e o bundle JavaScript. Remova apps nao utilizadas (cada app adiciona JS). Use treeshaking no tema. Configure o Image Server da VTEX para servir WebP automaticamente. Evite custom CSS pesado no tema. O prefetch nativo do VTEX ja faz preload de rotas. Para lojas VTEX que nao conseguem LCP abaixo de 3s no Store Framework, considere migrar o frontend para FastStore ou deco.cx mantendo o backend VTEX. VTEX FastStore: ja vem otimizado por padrao. Next.js com Image component faz lazy loading e responsive images automaticamente. Garanta que a hero image tem priority true. Use next/font para otimizacao automatica de fontes. Configure headers de cache na Vercel ou provider de deploy. Shopify: o Shopify CDN faz conversao automatica para WebP. Use section rendering API para lazy load de sections abaixo do fold. Preload a hero image no theme.liquid. Cuidado com apps do Shopify App Store que injetam JavaScript pesado. Cada app pode adicionar 50-200KB. Audite regularmente. Shopify Hydrogen: controle total sobre o carregamento. Use Remix defer para streaming. Configure cache headers granulares por rota. Image component do Hydrogen otimiza automaticamente. Headless (Next.js, deco.cx): maximo controle. Use next/image ou componente equivalente. Configure ISR para cache. Implemente streaming SSR. Faca code splitting agressivo. O LCP em headless bem implementado fica consistentemente abaixo de 1.5s.