Auditoria técnica · 06/11/2026

ShopMax LP — connect rate, gate de 12 min e migração pra código

sabrinanunes.com/shopmax-lp · medido em Chromium headless com perfil 4G (1,6 Mbps, 150 ms de latência), viewport iPhone

Veredito em 4 linhas

1. O que a página é hoje

ItemEstado
PlataformaWordPress + Elementor Pro 4.3.5 + WP Rocket
EstruturaVSL pura: 1 hero com player vertical VTurb (14 min 03 s) + 8 containers escondidos
CheckoutLastLink /p/C01E2D987/checkout-payment/ nos 3 CTAs — sem UTM/fbclid no link
TrackingGTM-TKNTJMGX (self-hosted em /bd3c/) → 3 pixels Meta + TikTok + Clarity + Google Ads 810179376
PreçoR$ 197 (de R$ 482) · garantia 7 dias · 8 itens de FAQ — tudo dentro do bloco escondido
SEOindex,follow · zero H1 (só H2)

2. Números medidos

0,10 sTTFB do HTML (Cloudflare)
0,46 sFirst Contentful Paint
9,4–11,2 sPageView Meta chega ao FB
11,3 sevento load
78 / 1,11 MBrequisições / transferido
~730 KBJavaScript (jQuery+Elementor+Swiper)
370 KBGTM carregado 2×
720 sgate do conteúdo

Detalhe dos requests que importam (tempo em relação ao início da navegação, mesma simulação 4G):

tRequestPeso
0,47 sgoogletagmanager.com/gtm.js?id=GTM-TKNTJMGX180 KB
4,62 ssabrinanunes.com/bd3c/ + 2 chunks (GTM self-hosted)190 + 374 KB
5,35 sconnect.facebook.net/en_US/fbevents.js começa a carregar111 KB
7,93 ssignals/config/150249430332023985 KB
9,45 s1º beacon facebook.com/tr/?ev=PageView—
9,45 ssignals/config/132382626241636105 KB
10,57 ssignals/config/1873889120187819 + PageView38 KB
11,15 sPageView repetido no pixel 132382626241636—

3. Connect rate: por que está caindo

Connect rate = Landing Page Views ÷ cliques no link. O LPV só existe quando o PageView do pixel carrega e sai do navegador. Nesta página esse evento depende de uma corrente inteira:

HTML → gtm.js remoto (0,5 s) → /bd3c/ local (4,6 s) → fbevents.js (5,4 s)
     → signals/config (7,9–10,6 s) → PageView (9,4–11,2 s)

Em tráfego frio de Meta no celular, uma sessão curta cabe inteira nesses 10 s. O usuário foi cobrado como clique, navegou, não converteu em LPV. Conectividade não é problema de rede nem de servidor — é ordem de carregamento.

As 4 causas medidas

#CausaProvaImpacto
1Pixel Meta dentro do GTMfbevents.js só é pedido em 5,35 s; PageView em 9,4 sAlto
2GTM carregado duas vezes (remoto + self-hosted)gtm.js 180 KB e /bd3c/ 190 KB + 374 KB de chunksAlto
33 pixels Meta disparando PageView no mesmo pageview132382626241636 · 1502494303320239 · 1873889120187819 (um deles dispara 2×)Médio (atribuição)
4~730 KB de JS + 4 famílias de fonte (Roboto, Roboto Slab, Sora, TikTok Sans) com range 100–900peso total 1,11 MB em 78 requestsMédio

Correção que resolve o grosso (sem migrar nada)

Pixel do Meta inline no <head>, independente do GTM. Testei na própria página, mesma rede, com o GTM bloqueado: fbevents.js sai em 0,52 s em vez de 5,35 s — PageView na casa de 1 s em vez de 9–11 s. O GTM continua existindo só pro TikTok, Clarity e Google Ads.

Junto: matar o GTM duplicado (fica só o de 1º domínio, 190 KB, e some o gtm.js remoto), deixar 1 pixel Meta (o da conta que roda as campanhas) e adicionar preconnect pra connect.facebook.net, scripts.converteai.net e lastlink.com.

4. O achado maior: 12 minutos de porta fechada

<style>.esconder{display:none}</style>
var delaySeconds = 720;
player.displayHiddenElements(720, [".esconder"], { persist: true });

O vídeo tem 842 s (14 min 03 s). O conteúdo só aparece aos 720 s (12 min). Antes disso, o que existe na página é: título + player. Nada mais. Ficam invisíveis:

Consequências práticas:

Recomendação mínima (não mexe no roteiro): CTA fixo visível desde o primeiro frame pra quem já decidiu + liberar garantia/FAQ a partir de 3–5 min. Se o pitch da VSL acontece antes dos 12 min, o delaySeconds está liberando a oferta depois da hora — nesse caso o número correto é o timestamp do pitch.

5. Migrar pra código? Sim — e o ganho é mensurável

Hoje a página carrega ~730 KB de JS e 370 KB de GTM pra renderizar um vídeo e blocos de texto. Um HTML estático com CSS inline faria o mesmo trabalho com ~35–45 KB de documento.

Hoje (WP+Elementor)Estático (Pages)
Documento113 KB / 22 KB br~40 KB / ~9 KB br
JS~730 KB (12 arquivos)~0 (só o player VTurb)
CSS18 arquivos, 63 KB só do post-25101 bloco inline
Fontes4 famílias, range 100–9001–2 famílias, só os pesos usados
PageView Meta9,4–11,2 s< 1 s (pixel inline)
Custo de editar copyElementorHTML (ou componente de seção)

O que precisa ser preservado na migração

Dois pontos de tracking que precisam de decisão

6. Checklist priorizado

#AçãoOndeGanho
P0Pixel Meta inline no <head> (sai do GTM)WP: header script ou functions.phpPageView 10 s → ~1 s
P0Remover GTM duplicado — manter só 1 containerplugin self-hosted / functions.php−370 KB e −4 s até o 1º beacon
P0Confirmar autoplay do vídeo no desktop (hoje abriu "parado" no teste)player / Elementorsem isso a página não vende
P0Arrumar www → 301 pro apexCloudflareelimina risco de 403
P1CTA fixo desde o início + liberar garantia/FAQ aos 3–5 minElementorconversão, não connect
P1Deixar 1 pixel Meta (hoje 3 IDs, um dispara 2×)GTMatribuição limpa
P1Passar UTM/fbclid na URL do LastLinkCTAsrastreio de venda por campanha
P1preconnect: connect.facebook.net, scripts.converteai.net, lastlink.comhead−0,2 a −0,4 s
P2Reduzir para 1–2 famílias de fonte, só pesos usadosElementor−200 KB aprox.
P2Adicionar H1 (hoje zero)Elementorsemântica/SEO
P2Migrar pra HTML estático no Pagesbuild novoP0+P1 de peso somem de uma vez

Sobre migrar: minha leitura

Vale, mas não como primeiro passo. P0 resolve connect rate em uma tarde dentro do WordPress — sem risco de perder a página que está no ar. Migrar entrega o mesmo resultado de rede e ainda tira 700 KB de JS, porém custa mais e mexe no que já converte.

Se a decisão for migrar, o caminho é: 1 HTML + CSS inline, player VTurb igual, gate igual, pixel inline, GTM só se sobrar TikTok/Clarity/Ads, deploy no Cloudflare Pages em URL de teste e comparação de PageView/lado a lado antes de trocar o tráfego. A copy passa a ser editada em código — o que é ganho pra mim e perda pra quem edita no Elementor.

Metodologia: curl + Chromium headless via Playwright, viewport 390×844, UA iPhone, throttling CDP 1,6 Mbps / 150 ms. Timestamps de performance.getEntriesByType('resource'). Gate confirmado por getComputedStyle + leitura da propriedade duration do vturb-smartplayer (842 s).