Performance e Core Web Vitals no Magento 2: Guia Técnico Completo

Production mode, static content deploy e DI compilation

O primeiro e mais barato ganho de performance em qualquer loja Magento 2 é simplesmente rodar no modo de produção. No modo developer ou default, o framework gera arquivos sob demanda, escreve logs verbosos e não usa código compilado — algo aceitável para desenvolver, fatal em produção.

Os comandos que importam

Para verificar e alterar o modo de operação:

bin/magento deploy:mode:show
bin/magento deploy:mode:set production
bin/magento deploy:mode:set developer

Ao executar deploy:mode:set production, o sistema dispara automaticamente a compilação de código (setup:di:compile) e o deploy de conteúdo estático (setup:static-content:deploy). O modo produção entrega melhor performance justamente porque os static view files ficam pré-gerados em pub/static e a injeção de dependências (DI) fica pré-compilada. Existe a flag opcional --skip-compilation para pular a compilação quando você quiser controlá-la separadamente.

Production mode has better performance because static view files are populated in the pub/static directory and because of code compilation.

Fonte: Adobe Experience League — Set the operation mode

Static content deploy com estratégia certa

O comando aceita locales e estratégias de deploy via flag -s:

bin/magento setup:static-content:deploy en_US pt_BR -s quick

São três estratégias: quick (padrão, minimiza o tempo de deploy), standard (gera todos os arquivos de todos os pacotes) e compact (economiza espaço em disco). A língua padrão é en_US, então sempre liste explicitamente pt_BR e os demais locales que sua loja usa, ou eles não serão gerados.

Uma observação crítica para quem está em Adobe Commerce Cloud: o conteúdo estático deve ser deployado na fase de build, nunca na fase de deploy. O hook de build padrão do cloud já executa setup:di:compile após o composer install recuperar as dependências. Na prática, isso significa downtime menor e deploys mais previsíveis.

Se você está chegando agora ao Magento 2 vindo de uma loja legada, vale alinhar essa rotina de deploy desde o início — esse é justamente um dos pontos que detalho na migração de Magento 1 para Magento 2, onde o modo de produção e a recompilação são parte do checklist de corte.

Full Page Cache: built-in vs Varnish em produção

O Full Page Cache (FPC) guarda a página HTML inteira em cache, evitando que o PHP reprocesse o catálogo a cada visita. O Magento traz um FPC built-in, mas a Adobe é categórica: em produção, use Varnish, um acelerador HTTP que serve páginas em cache direto da memória.

Adobe strongly recommends Varnish for production environments because it is significantly faster than the built-in full-page cache.

Fonte: Adobe Experience League — Caching overview

Como ativar o Varnish

Pelo Admin: Stores > Configuration > Advanced > System > Full Page Cache, selecione Varnish Caching e defina o TTL. Pela linha de comando, o valor 2 ativa o Varnish (o valor 1 é o built-in):

bin/magento config:set --scope=default --scope-code=0 \
  system/full_page_cache/caching_application 2

Os campos de configuração que você precisa preencher são: Access list, Backend host, Backend port e Grace period. O grace period padrão no Adobe Commerce é de 300 segundos — é o tempo durante o qual o Varnish continua servindo conteúdo stale (levemente desatualizado) caso o backend fique indisponível, evitando que uma queda do PHP derrube a vitrine.

Versões de Varnish suportadas

Como diagnosticar um Varnish que não cacheia

Na minha experiência, a maior causa de "Varnish que não cacheia" é um módulo de terceiros marcando páginas como não-cacheáveis ou cookies sendo setados onde não deveriam. Antes de culpar o Varnish, valide os cabeçalhos de resposta de uma página de categoria com um cliente HTTP e confirme se ela está retornando HIT:

curl -sI https://sua-loja.com.br/categoria.html | grep -i \
  -e x-magento-cache-debug -e x-cache -e age -e set-cookie

Procure por X-Magento-Cache-Debug: HIT (ative o modo developer do Varnish para vê-lo), um header Age maior que zero e a ausência de Set-Cookie na resposta. Qualquer Set-Cookie numa página pública é sinal vermelho: ele torna a resposta privada e fura o cache. Bloco private content mal configurado em algum módulo costuma ser o culpado.

Redis (e Valkey) para cache de página, backend e sessões

O Redis é a peça que tira do disco (ou do banco) o armazenamento de cache e de sessões, colocando tudo em memória. No Magento 2 ele atende três funções distintas: default cache (backend), page cache e session storage. A porta padrão do Redis é a 6379.

Configuração via CLI

bin/magento setup:config:set \
  --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 \
  --cache-backend-redis-db=0

bin/magento setup:config:set \
  --page-cache=redis \
  --page-cache-redis-server=127.0.0.1 \
  --page-cache-redis-db=1

bin/magento setup:config:set --session-save=redis

Sempre prefiro o CLI a editar o env.php na mão: o comando valida a configuração antes de gravar, evitando que um typo derrube a loja.

Separação de bancos: regra de ouro

A recomendação oficial é usar bancos (DB) Redis diferentes para cada função. Conforme a documentação da Adobe, se você usa Redis para mais de um tipo de cache, os números de banco obrigatoriamente precisam ser distintos — caso contrário, um cache:flush no FPC apagaria também as sessões dos clientes logados, esvaziando carrinhos.

Segundo a documentação da Adobe, a recomendação é atribuir o número de banco 0 ao cache padrão, 1 ao page cache e 2 ao armazenamento de sessões; se mais de um tipo de cache usar Redis, os números de banco precisam ser diferentes entre si.

Fonte: Adobe Experience League — Use Redis for the page cache

Em lojas de maior porte, recomendo ir além e usar instâncias Redis separadas para sessão e cache, não apenas DBs diferentes na mesma instância. Assim, picos de tráfego que estressam o FPC não competem por memória com as sessões dos compradores.

Atenção: Redis está sendo substituído pelo Valkey

Um ponto de atualização importante para quem está nas versões mais recentes: na página oficial de System Requirements, a linha 2.4.7-p10 já lista o Redis como não suportado e indica o Valkey 8.1 em seu lugar. A partir do 2.4.8, o Valkey 8 é suportado como alternativa compatível com Redis (a sintaxe dos flags de CLI é idêntica, gerando o mesmo env.php), e no 2.4.9 o Valkey passa a substituir o Redis na própria ferramenta de linha de comando. O Valkey é um fork open-source do Redis, mantido pela Linux Foundation, criado após a mudança de licença do Redis em 2024 — daí a adoção pela Adobe. Na prática, os comandos acima continuam válidos no 2.4.8, mas, ao planejar uma stack nova ou um upgrade, considere o Valkey como caminho de longo prazo. Confirme sempre a opção suportada para a sua linha na página oficial de System Requirements.

Elasticsearch e OpenSearch: o motor de busca obrigatório

Muita gente que migra de versões antigas se assusta: desde o Magento 2.4.0, o MySQL como motor de busca de catálogo foi removido. E, desde o 2.4.4, toda instalação obrigatoriamente precisa usar Elasticsearch ou OpenSearch. Não há mais a opção "sem search engine".

As of Adobe Commerce 2.4, all installations must be configured to use Elasticsearch or OpenSearch as the catalog search solution. (...) OpenSearch support was added in 2.4.4.

Fonte: Adobe Experience League — Search engine overview

Elasticsearch ou OpenSearch?

Hoje recomendo OpenSearch para a maioria dos projetos novos. O motivo é concreto: o fim de suporte do Elasticsearch 7 foi anunciado para agosto de 2023, e o OpenSearch é a alternativa open-source que a Adobe passou a indicar como caminho de migração — a ponto de o 2.4.8 já estar otimizado para OpenSearch 3. Tecnicamente, ambos atendem bem; a decisão é mais de licenciamento e suporte de longo prazo.

Versões suportadas por linha

As versões exatas dependem do patch level e mudam ao longo do tempo — sempre confirme na página oficial de System Requirements para a sua versão. A título de referência:

Um search engine bem dimensionado não impacta só a busca: ele alimenta a navegação por categorias com layered navigation. Uma instância subdimensionada gera timeouts que aparecem como páginas de categoria lentas — outro motivo para tratá-lo como item de performance, não só de funcionalidade. Vale lembrar que a busca também tem peso em SEO técnico: páginas de categoria que respondem rápido e renderizam resultados completos ranqueiam melhor do que vitrines que estouram timeout.

Otimização do Composer e boas práticas de deploy

O autoloader do Composer é um ganho de performance frequentemente ignorado. Por padrão, ele resolve classes seguindo regras PSR-4/PSR-0, consultando o filesystem. Em produção, isso é desperdício.

O comando que deve estar em todo deploy

composer dump-autoload --optimize

A flag --optimize (-o) converte as regras PSR-4/PSR-0 em um classmap estático, deixando o carregamento de classes muito mais rápido. A própria documentação do Composer é direta sobre isso:

There are no real trade-offs with this method. It should always be enabled in production.

Fonte: Composer — Autoloader optimization

As flags avançadas e seus cuidados

• --optimize (-o): seguro e recomendado sempre em produção. Gera o classmap.
• --classmap-authoritative (-a): assume que, se a classe não está no classmap, ela não existe — não consulta o filesystem. Cuidado: classes geradas em runtime não serão carregadas, o que pode quebrar fluxos do Magento.
• --apcu: adiciona um cache APCu como fallback do autoloader. É seguro, mas não pode ser combinado com -a.

Sequência de deploy que uso

Em servidor próprio, a ordem que recomendo para um deploy sem surpresas é:

1. composer install --no-dev (sem dependências de desenvolvimento)
2. composer dump-autoload --optimize
3. bin/magento setup:upgrade --keep-generated
4. bin/magento setup:di:compile
5. bin/magento setup:static-content:deploy pt_BR en_US
6. bin/magento cache:flush

No Adobe Commerce Cloud, boa parte disso já acontece automaticamente: o composer install roda na fase de build e o hook padrão executa setup:di:compile. O ponto de atenção é garantir que o static content seja gerado no build, e não no deploy, para minimizar downtime.

Modo de manutenção para zero surpresa

Quando o deploy precisa rodar com a loja no ar, use o modo de manutenção para que o setup:upgrade não pegue requisições no meio de uma migração de schema:

bin/magento maintenance:enable
# ... roda upgrade/compile/static ...
bin/magento maintenance:disable

Em servidor próprio, prefiro estratégia de blue-green ou symlink atômico para o diretório de release, mantendo o downtime perceptível em zero. Esse rigor de deploy também é o que evita janelas de exposição: trato disso em detalhe no guia de segurança e hardening do Magento 2.

Minificação, merge e bundling de JS/CSS e HTML

Reduzir o número e o tamanho dos arquivos enviados ao navegador ataca diretamente o tempo de carregamento e o INP. O Magento traz controles nativos para isso em Stores > Configuration > Advanced > Developer — lembrando que a aba Developer só aparece em modo developer; em produção, configure via bin/magento config:set.

Configuração nativa recomendada

Internamente, a classe Magento\Framework\View\Asset\Config é quem controla os flags de bundling de JS, merge de JS/CSS e minificação de HTML. Sempre valide a vitrine após ativar o merge: combinações infelizes de módulos de terceiros podem gerar conflitos de JavaScript, e é melhor descobrir em staging.

Baler: o bundler inteligente da Adobe

O Baler é um bundler/preloader de JavaScript mantido no repositório oficial da Adobe (magento/m2-baler) que faz o bundle do JS de forma inteligente, conforme a necessidade de cada página — geralmente superior ao bundling nativo, que tende a empacotar tudo num arquivo gigante. Ativação:

php bin/magento config:set dev/js/enable_baler_js_bundling 1

Atenção a uma regra que muita gente erra: ao usar o Baler, você deve desabilitar a minificação, o merge e o bundling nativos do Magento, porque o Baler não os suporta em conjunto. Ligar os dois ao mesmo tempo causa JS duplicado e quebrado. Os comandos para desligar os recursos nativos são:

php bin/magento config:set dev/js/minify_files 0
php bin/magento config:set dev/js/enable_js_bundling 0
php bin/magento config:set dev/js/merge_files 0

(Observação de transparência: o Baler é mantido no GitHub oficial da Adobe — magento/m2-baler — mas tem cobertura limitada na Adobe Experience League; a documentação mais detalhada está no próprio repositório e em guias de parceiros. A sintaxe acima está correta; ainda assim, teste sempre em staging antes de produção.)

Otimização de imagens, WebP e o impacto no LCP

Na grande maioria das lojas, o elemento que define o LCP (Largest Contentful Paint) é uma imagem — o banner do topo ou a foto principal do produto. Por isso, otimizar imagens é, na prática, otimizar o LCP.

Formatos modernos

O web.dev recomenda formatos modernos como WebP e AVIF, que oferecem melhor compressão que JPEG/PNG e, portanto, downloads mais rápidos. Como referência geral de mercado (não como número cravado pela página de LCP), a economia costuma ficar na faixa de 25% a 50% de tamanho de arquivo, dependendo da imagem — e em uma home com vários banners isso se traduz diretamente em segundos a menos no LCP.

Segundo a documentação do web.dev sobre LCP, usar formatos de imagem modernos como WebP e AVIF é uma das formas recomendadas de reduzir o tamanho dos recursos, porque eles comprimem melhor que PNG e JPEG e resultam em downloads mais rápidos. A página não crava um percentual exato de redução.

Fonte: web.dev — Optimize Largest Contentful Paint

A regra que mais vejo violada: lazy-load na imagem LCP

O Magento 2.4.x suporta lazy loading nativo via atributo HTML loading="lazy". É excelente para imagens below-the-fold (abaixo da dobra), mas existe uma regra inquebrável:

• Nunca aplique lazy-load na imagem LCP: isso sempre causa atraso desnecessário, porque o navegador só busca a imagem depois de calcular o layout.
• Use fetchpriority="high": no elemento <img> que provavelmente será o LCP, para o navegador priorizar o download.
• Garanta a descoberta pelo preload scanner: a imagem LCP precisa estar no HTML inicial, não injetada por JavaScript, para ser descoberta cedo.

Dimensões explícitas evitam CLS

Sempre defina width e height (ou aspect-ratio via CSS) nas imagens. Sem isso, o navegador não reserva o espaço e a imagem "empurra" o conteúdo ao carregar, gerando Cumulative Layout Shift (CLS) — uma das três métricas de Core Web Vitals. Definir dimensões é a correção de CLS mais simples e de maior retorno que existe.

Um exemplo concreto do markup ideal para a imagem do banner principal:

<img src="/media/banner-home.webp"
     width="1280" height="480"
     fetchpriority="high"
     alt="Promoção da semana">

CDN, Fastly, HTTP/2 e compressão

Uma CDN aproxima os assets (imagens, CSS, JS) geograficamente do visitante e tira carga do servidor de origem. Para lojas brasileiras com clientes espalhados pelo país, isso reduz a latência percebida de forma consistente.

Fastly no Adobe Commerce Cloud

Quem está em Adobe Commerce on cloud infrastructure tem uma vantagem: o Fastly vem incluído sem custo adicional. É um CDN baseado em Varnish que faz cache de páginas, assets e CSS na borda. Além do cache, o Fastly entrega:

• WAF: firewall de aplicação web gerenciado, com proteção PCI-compliant para bloquear tráfego malicioso antes que ele chegue à origem.
• Proteção DDoS: mitigação na borda, antes de o tráfego chegar ao servidor de origem.
• Origin cloaking: esconde o servidor de origem do acesso direto.
• Certificados TLS: Let's Encrypt domain-validated.
• Fastly Image Optimization (Fastly IO): faz offload do processamento e resize de imagens e detecta o navegador para servir WebP/AVIF on-the-fly.

Conforme a documentação da Adobe, o Fastly é o serviço de CDN baseado em Varnish para o Adobe Commerce on cloud infrastructure: ele faz cache de páginas, assets e CSS na borda e inclui módulos de Image Optimization e de WAF. Esses serviços vêm incluídos sem custo adicional nos projetos de cloud infrastructure.

Fonte: Adobe Experience League — Fastly CDN

O Fastly está disponível nos ambientes Pro Production/Staging e Starter Production. O Fastly IO, em particular, resolve de uma vez a entrega de WebP/AVIF que discutimos na seção de imagens — sem você precisar gerar variações manualmente. Vale notar que a proteção PCI-compliant é atribuída ao serviço de WAF gerenciado do Fastly, não ao CDN em si — uma distinção importante quando o assunto entra em segurança e hardening.

HTTP/2 e compressão

Habilite HTTP/2 no seu servidor web (Nginx/Apache): ele permite multiplexação de várias requisições numa única conexão, o que reduz o overhead de carregar dezenas de assets. Combine com compressão (gzip ou, preferencialmente, Brotli) para os recursos textuais — HTML, CSS e JS comprimem muito bem e o ganho de banda é imediato. No Nginx, isso é tão simples quanto gzip on; com gzip_types text/css application/javascript application/json;, ou o módulo ngx_brotli para Brotli. Em servidor próprio, essa configuração fica no seu servidor web; não é controlada pelo Magento.

Core Web Vitals: LCP, INP e CLS e seus alvos

Os Core Web Vitals são as três métricas com que o Google quantifica a experiência real de carregamento, responsividade e estabilidade visual. Os limiares "good" são medidos no percentil 75 dos carregamentos, tanto em mobile quanto em desktop.

Segundo a documentação do web.dev sobre Web Vitals, o LCP deve ocorrer em até 2,5 segundos do início do carregamento; o INP deve ser de 200 milissegundos ou menos; e o CLS deve ficar em 0,1 ou menos — sempre avaliados no 75º percentil dos carregamentos, segmentados entre mobile e desktop.

Fonte: web.dev — Web Vitals

INP substituiu o FID

Uma mudança importante e recente: em 12 de março de 2024, o INP tornou-se oficialmente um Core Web Vital e substituiu o FID (First Input Delay). O FID foi removido do Google Search Console nessa data; outras ferramentas (PageSpeed Insights, CrUX) tiveram um período de descontinuação de seis meses. O INP havia sido introduzido como métrica experimental pela equipe do Chrome em maio de 2022.

Conforme o anúncio oficial do web.dev, o INP tornou-se oficialmente um Core Web Vital e substituiu o FID em 12 de março de 2024.

Fonte: web.dev — INP becomes a Core Web Vital on March 12

Como cada CWV se conecta ao Magento

• LCP: resolvido com Varnish/Fastly (TTFB rápido), imagem LCP otimizada em WebP e fetchpriority="high".
• INP: melhora com menos JavaScript no thread principal — daí a importância do Baler e da minificação de JS.
• CLS: resolvido reservando espaço com width/height em imagens e evitando inserções tardias de banners.

Vale lembrar a diferença que abordo na próxima seção: o que o Google usa para ranqueamento são os field data (usuários reais), não o número de lab do Lighthouse. Para entender como esses sinais se somam aos demais fatores de busca, vale cruzar este guia com o de SEO técnico para Magento 2.

MySQL/MariaDB, índices, reindex, cron e flat catalog

O banco de dados é o coração transacional do Magento, e a forma como os indexers operam tem impacto direto na performance — tanto da vitrine quanto do Admin.

Os dois modos de indexação

Cada indexer pode rodar em dois modos:

• Update on Save: reindexa a cada vez que um objeto é salvo. Em produção, com vários administradores salvando produtos simultaneamente, isso gera deadlocks e travamentos.
• Update by Schedule (Mview): reindexa via cron, de forma parcial e incremental — muito mais eficiente. É o modo recomendado pela Adobe em produção.

Os comandos de referência (documentados no Configuration Guide) são:

bin/magento indexer:show-mode
bin/magento indexer:set-mode schedule
bin/magento indexer:reindex

Entre os indexers que você vai gerenciar estão Product Prices, Catalog category/product, Catalog search, Stock status e Customer Grid.

Deixe o cron trabalhar

A melhor prática é deixar o mecanismo de reindexação parcial (Mview) cuidar dos dados automaticamente via cron, executando reindexação manual completa apenas quando estritamente necessário (após import em massa, por exemplo).

Segundo a documentação da Adobe, para evitar problemas quando vários usuários do Admin atualizam objetos que disparam reindexação automática, recomenda-se configurar todos os indexers para rodar agendados como cron jobs (Update by Schedule); do contrário, salvamentos simultâneos de objetos com interdependências podem causar deadlocks, com sintomas como alto uso de CPU e erros de MySQL.

Fonte: Adobe Experience League — Index management

Garanta também que o cron do Magento esteja de fato rodando — uma das causas mais comuns de "indexers invalidados que nunca atualizam" é simplesmente o cron parado. Verifique com bin/magento cron:install no servidor e monitore a tabela cron_schedule.

Flat catalog: pode esquecer

Um mito persistente é que o flat catalog acelera a loja. Não acelera mais — ele não é mais recomendado como best practice. Seu uso continuado é conhecido por causar degradação de performance e problemas de indexação. Se a sua loja ainda tem flat catalog ligado por herança de versões antigas, desligá-lo costuma ser um ganho, não uma perda.

Tuning de MySQL/MariaDB

No nível do servidor de banco, dimensione o innodb_buffer_pool_size para a sua RAM disponível (uma regra prática é 50% a 70% da RAM dedicada ao banco), garanta que as queries pesadas estejam usando índices e monitore o slow query log. O Magento depende de tabelas pesadas como catalog_product_entity e suas EAV — em catálogos grandes, integrações de estoque e preço via ERP e NF-e são uma fonte frequente de carga de escrita que estressa esses indexers, então vale dimensionar o banco pensando também nesse fluxo. Confirme sempre as versões suportadas de MariaDB/MySQL na página oficial de System Requirements para a sua linha do Adobe Commerce, pois elas mudam por patch level.

Ferramentas de medição: lab vs field e APM

Não dá para otimizar o que não se mede. E o erro mais comum aqui é confundir dados de laboratório com dados de campo — eles respondem perguntas diferentes.

Lab data vs field data

O Lighthouse é a ferramenta open-source do Google, executável no Chrome DevTools, na linha de comando ou como módulo Node. Por ser uma ferramenta de laboratório, carrega a página em um único dispositivo com condições de rede fixas e simuladas — ótimo para diagnosticar e comparar antes/depois, mas o número não reflete necessariamente a experiência real dos seus usuários.

Lighthouse is an open-source, automated tool to help you improve the quality of web pages.

Fonte: Chrome for Developers — Lighthouse overview

O PageSpeed Insights (PSI) é o mais completo para Core Web Vitals porque combina field data (dados anonimizados de usuários reais, via Chrome User Experience Report — CrUX) com lab data (Lighthouse). É exatamente por isso que os dois números às vezes divergem: um mede a realidade, o outro a simulação.

Conforme a documentação do PageSpeed Insights, a ferramenta apresenta tanto dados de laboratório quanto dados de campo sobre uma página: o lab data é gerado pelo Lighthouse, simulando o carregamento da página, enquanto o field data de usuários reais vem do conjunto de dados do Chrome User Experience Report (CrUX).

Fonte: Google for Developers — About PageSpeed Insights

APM e profiling para a causa raiz

Quando o gargalo é server-side, ferramentas de APM e profiling apontam a causa raiz:

• New Relic: incluído sem custo nos planos Adobe Commerce Cloud Pro (APM e Infrastructure, com a chave de licença já provisionada). O APM rastreia performance server-side (execução PHP, queries de banco, chamadas de API) e o Browser/RUM captura performance client-side, incluindo Core Web Vitals.
• Blackfire.io: profiler PHP e ferramenta de teste de performance automatizado que rastreia cada chamada PHP, método e query SQL. Atenção: o acesso gratuito ao Blackfire deixou de vir incluído no Adobe Commerce on cloud infrastructure (Pro e Starter) desde 11 de abril de 2020 — desde então, é preciso adquirir a licença diretamente com a Blackfire.io. Deve rodar sob demanda, nunca continuamente em produção, pelo overhead que adiciona.

Atenção (Adobe Commerce on cloud): desde 11 de abril de 2020, o acesso gratuito ao Blackfire deixou de ser incluído nas assinaturas Pro e Starter do Adobe Commerce on cloud infrastructure — para continuar usando a ferramenta é preciso adquirir uma licença diretamente com a Blackfire.io.

Minha rotina: PSI para acompanhar os Core Web Vitals no campo, Lighthouse para validar antes/depois de cada otimização, e Blackfire pontualmente quando um endpoint específico está lento e preciso achar o método PHP culpado.