Como a Wake aumentou a performance da B2C Store, do Grupo Ybera Paris

Sabemos que a performance é um fator decisivo para a experiência do usuário. A seguir, compartilharemos como o time de front-end da Wake elevou a pontuação de Core Web Vitals de um projeto de ~25 para ~98, abordando as principais otimizações.

Nesse artigo técnico, abordaremos como algumas ações e boas práticas de desenvolvimento Web podem melhorar significativamente a performance de um site. 

O desafio da B2C Store ao lado da Wake

A B2C Store enfrentava lentidão no carregamento de algumas páginas, o que afetava diretamente suas taxas de conversão. A pontuação de performance no Google PageSpeed era de cerca de 20, abaixo do padrão de mercado.

Diante disso, a equipe de engenharia de front-end da Wake Commerce – tendo o desenvolvedor sênior Matheus Rigote como principal responsável pelas otimizações, com o apoio dos demais membros  – entrou em ação para mapear melhorias e mostrar como nossa solução é capaz de atingir as melhores pontuações de performance. 

Diagnóstico como primeiro passo

Antes de agir o número em questão, foi mapeado os gargalos com as ferramentas que auxiliam na identificação dos possíveis problemas, elas são:

• Google PageSpeed Insights: analisa a pontuação inicial Core Web Vitals e lista as sugestões de melhorias.
• WebPageTest: visualização de _layout shifts_ e vídeos do carregamento.
• Chrome DevTools > Lighthouse Tab: audita performance, acessibilidade e SEO.
• Chrome DevTools > Performance, Network e Coverage Tabs: Análise de scripts bloqueantes, rede e cobertura de código.

Dica: Ferramentas pagas como GTMetrix, DebugBear podem consolidar dados em um único painel, mas o Chrome DevTools  cobre o necessário gratuitamente.

A análise dos dados da B2C, do Grupo Ybera Paris

https://pagespeed.web.dev/analysis/https-www-b2cstore-com-br/0jumw09x1t?form_factor=desktop

Ao analisar a home page — escolhida por ser o ponto de entrada dos usuários — em diversas ferramentas de medição de performance, o time Wake identificou os principais fatores que prejudicavam o carregamento:

LCP (Largest Contentful Paint) em 9,1s

– Ideal < 2,5s

 TBT (Total Blocking Time) elevado

 – Scripts de terceiros e recursos longos na thread principal bloqueando a interatividade.

 CLS (Cumulative Layout Shift) alto

– Imagens não otimizadas (tamanho, formato e priorização), além de troca de fontes durante a renderização.

A pontuação inicial foi de 34 no mobile e 25 no desktop, números baixos para as metas de mercado. Focando primeiro no LCP, obtivemos a seguinte divisão:

Phase	% off LCP	Timing
TTFB	7%	660ms
Load Delay	59%	5.400ms
Load Time	0%	40ms
Render Delay	33%	3.020ms

Os dados mostram que Load Delay e Render Delay são os principais responsáveis pela baixa performance 

• Resource load delay (5.4s): Tempo perdido entre a resposta do servidor (TTFB) e o início do download de recursos críticos, agravado por scripts bloqueantes e limitação de conexões.
• Element render delay (3s): Tempo gasto pelo navegador para processar recursos baixados (CSS, JS) e renderizar a tela, impactado por código não otimizado.

Dica: Recomendo a leitura do post Optimize Largest Contentful Paint do Philip Walton, do time de Web Performance do Google Chrome.

Identificação do problema

Analisando os dados, sabe-se qual métrica atingir primeiro, então como descobrir onde estavam os gargalos? Usando a tab Performance do Dev Tools . Foi gravada a sessão e verificada a linha cronológica com todos os eventos que ocorrem durante o carregamento e a interação inicial com o site Retornará algo como a imagem abaixo.

Essa linha do tempo evidencia, em cada milissegundo, como o navegador:

1. Faz o parsing do HTML

    O HTML recebido do servidor é processado, e o DOM (Document Object Model) começa a ser construído. Nesse momento, o navegador identifica as tags e estabelece a estrutura inicial da página.

2. Identifica e enfileira recursos externos

    Ao finalizar o parsing de cada trecho de HTML, o navegador encontra referências a CSS, fontes, scripts e imagens. Cada um desses recursos é colocado em uma fila de requisições para ser buscado e processado.

3. Bloqueia ou paraleliza o carregamento

    Se um script estiver declarado de forma a bloquear a renderização (sem `async` ou `defer`, por exemplo), o navegador interrompe o parsing até que o script seja baixado e executado. Já arquivos CSS podem bloquear a pintura, pois o navegador precisa saber como estilizar a página antes de exibi-la. Isso tudo aparece na linha do tempo como barras que se sobrepõem, indicando onde o main thread está ocupado.

4. Processa e renderiza elementos na tela

Depois de obter os recursos necessários, o navegador inicia a etapa de pintura (render), transformando a estrutura DOM e o CSSOM (CSS Object Model) em pixels na tela. Durante esse processo, qualquer recurso que atrase a “pintura” principal (por exemplo, um script pesado ou uma imagem muito grande) fica evidente na gravação do Performance, pois gera um pico de uso de CPU ou alonga a barra de carregamento.

Entenda a importância da análise

Se houver scripts não prioritários sendo carregados no início, eles podem atrasar a pintura dos elementos essenciais (como banners e carrosséis no topo da página). Da mesma forma, imagens enormes ou sem `loading=”lazy”` podem congestionar a rede e impactar o LCP 

Na prática, ao analisar o gráfico na aba Performance  (ou mesmo na Network), é possível identificar em que momento cada recurso começa e termina o download e a execução. Assim, pode:

• Verificar se há scripts ou CSS desnecessários carregando antes do que deveriam.
• Priorizar recursos críticos (por exemplo, imagens do viewport) para carregarem primeiro.
• Adiar ou carregar de forma assíncrona recursos que não impactam o primeiro conteúdo visível na tela.

Com esse diagnóstico, é possível otimizar a ordem de carregamento e a estratégia de entrega dos recursos, evitando bloqueios desnecessários e melhorando significativamente métricas como LCP, TBT e FID.

Organizando o carregamento de scripts: a implementação

Com o auxílio de alguns atributos do HTML, conseguimos organizar a ordem da chamada dos recursos.

async: paraleliza o download e executa assim que disponível, sem respeitar a ordem. Bom para scripts que não afetam o layout principal, como tracking ou anúncios.

defer: baixa em paralelo, mas só executa depois que o HTML é completamente pareado. Ideal para scripts que dependem do DOM pronto (sliders, menus etc.). 

Exemplo

Para arquivos  CSS não crítico, pode-se usar media=”print” + onload, assim o navegador trata o CSS como “para impressão” (baixa prioridade), apenas cuidado com FOUC (Flash of Unstyled Content)  e realize testes antes de aplicar.

Exemplo:

Remoção de scripts desnecessários e bundling

Muitos scripts que não eram utilizados na home page, estavam sendo carregados globalmente. Para resolver isso, removemos esses scripts e os realocamos para suas páginas específicas, evitando o carregamento desnecessário no contexto inicial.

Além disso, reunimos os scripts essenciais em bundles utilizando o componente asset do Storefront, que auxilia nessa tarefa de agrupar múltiplos arquivos em um só. Dessa forma, reduzimos o número de requisições, agilizando o TBT e desbloqueando a main thread.

Exemplo:

Por que isso é importante? Os navegadores costumam limitar a  ~6 conexões simultâneas por domínio. Então, se o site fizer 20 requisições (sejam fetch, XMLHttpRequest ou carregamento de scripts/imagens), somente as primeiras 6 serão executadas ao mesmo tempo; as demais ficam na fila até que alguma conexão seja liberada.

Existem outras estratégias avançadas de otimização, mas não as abordaremos neste momento. O uso do componente asset do Storefront já é um passo significativo para melhorar a performance, pois permite centralizar e gerenciar melhor o carregamento dos scripts, tornando o processo mais eficiente.

Atenção ao tamanho final do bundle — nem tudo deve ficar em um único arquivo, pois isso pode aumentar o tempo de parse e bloquear a thread principal.

Carregando script de reCaptcha – somente quando formulário de newsletter é preenchido

Scripts como reCaptcha ou de tracking de redes sociais podem ser carregados apenas quando o usuário interage com o elemento (ex.: clicar/focar em um formulário). Chamamos esta técnica de carregamento condicional.

Exemplo:

Timeline pós organizar os recursos:

✅ Com estas ações a nota subiu para 52 (Mobile) e 63 (Desktop).

https://pagespeed.web.dev/analysis/https-www-b2cstore-com-br/s2xduuzdci?form_factor=desktop

Otimizando imagens da B2C Store

Imagens são vilãs clássicas de performance, e identificamos três problemas críticos, como: dimensões ausentes ou incorretas,  formato e tamanho inadequados e  priorização incorreta.

Para solucionar esses pontos, na Wake Commerce, temos um serviço interno que converte imagens para formato WebP e permite dimensões ajustáveis na própria URL com parâmetros ?w=xx&h=yy, combinado com srcset ou a tag <picture>, é possível entregar a imagem no tamanho e resolução adequados para cada dispositivo.

Exemplo:

Com parâmetros:

https://lojaybera.fbitsstatic.net/media/home-prime-card-5.png?w=175&h=195

Sem parâmetros:

https://lojaybera.fbitsstatic.net/media/home-prime-card-5.png

Utilizamos deste recurso para ajustar as dimensões além de realizar as melhorias necessárias como adição dos atributos width, height e  loading=”lazy”,  para postergar o carregamento das imagens fora do viewport.  Já para o banner principal e quaisquer imagens em destaque na área visível da tela, utilizamos loading=”eager”, garantindo que sejam carregadas antecipadamente e beneficiem diretamente o LCP.

Dica: Leia nosso post sobre Imagens performance no ecommerce

Fontes e banner principal

Ao carregar a tela, percebemos a troca de fontes e o banner principal alterava sua dimensão, penalizando o CLS. Primeiro analisamos como as fontes estavam eram chamadas e se todas precisavam ser carregadas na home page.

A fonte principal vinha do Google Fonts, mas sem o devido cuidado de:

• preconnect ao domínio `fonts.gstatic.com` (economiza de 100~500ms de DNS, TCP, TLS) diminuindo a latência.
• crossorigin=”anonymous” obrigatório para recursos de fontes (CORS)
• display=swap na URL para evitar Flash of Invisible Text
• media=”print” onload=”this.media=’all'” para um carregamento não bloqueante do CSS (quando aplicável)

Existia uma segunda fonte exclusiva para um hotsite que era importada dentro de um arquivo CSS. Então, foi ajustado a importação que estava dentro do CSS para o HTML principal, controlando melhor a ordem e removendo um “encadeamento” desnecessário.

Com isto o CLS e LCP aumentaram, mas não o suficiente para obter uma boa nota. A maior preocupação era o banner principal, então foi tomada a decisão por trocar a biblioteca.

E por que foi feita essa escolha? A B2C Store havia adotado o Glider JS, porém não estava performando como o esperado, ela tinha comportamento que atrasou a montagem do banner, com isto perdemos alguns milissegundos e até segundos conforme a ordem das chamadas e ficava visível a  “quebra” de layout. 

Então alteramos para a biblioteca Swiffy Slider. Nossa loja padrão utiliza esta lib e foi validada e testada pelo nosso time e se destacou nos benchmarks como a melhor escolha, oferecendo maior simplicidade de customização e implementação, além de ser mais leve em comparação com outras. Abaixo um comparativo entre ambas.

Fonte

Com estas ações a nota subiu para 90 (Mobile) e 98 (Desktop).

https://pagespeed.web.dev/analysis/https-www-b2cstore-com-br/h93mi5atp1?form_factor=desktop

Nota sobre o case com B2C Store

Este case demonstra que boas práticas de desenvolvimento web — HTML semântico, otimização de imagens, organização de CSS, uso eficiente de JavaScript e conhecimento de como funcionam o navegador, HTTP, DNS, CDN e UX — são fundamentais para atingir alta performance.

Para quem está desenvolvendo, vale sempre ressaltar:

• Monitore scripts e evite carregamentos desnecessários ou duplicados.
• Preencha todos os atributos importantes para as imagens.
• Mantenha o CSS bem estruturado.
• Utilize as ferramentas mencionadas ao longo deste artigo.

E, claro, conte sempre com a Wake!

Dica: O Storefront possui um modo Preview, disponível no painel administrativo, onde é possível testar suas feature branches em uma URL exclusiva. Isso permite simular o ambiente de produção e utilizar as ferramentas de análise de performance citadas neste post.

Conclusão

O objetivo desta atividade foi demonstrar como algumas ações e boas práticas podem melhorar significativamente a performance de um site. A otimização, no entanto, é um processo contínuo, não um objetivo final. Por isso, monitore constantemente e mantenha suas práticas de desenvolvimento atualizadas.

Por fim, parabenizo o time de front-end da Wake Commerce, do qual sou Tech Lead, e em especial o Matheus Rigote, que liderou as melhorias que nos levaram a esse excelente resultado.