Contexto
Em sites TanStack (@decocms/tanstack), cada navegação real do browser dispara 2 worker requests/isolates separados para o mesmo path:
- Body request — rota principal (
/$ ou /), chama loadCmsPage serverFn → roda todos os loaders de seções (PDP/PLP).
- Meta/head request — via
decoMetaRouteConfig() em src/routes/deco/meta.ts → dispara uma 2ª resolução completa da mesma página, incluindo re-execução de todos os loaders de Magento (ex: ResolveURL, GetCompleteProduct, GetPLPItems).
Confirmado via New Relic no projeto granadobr-tanstack (issue #131):
ResolveURL → 2× MISS por navegação (mesmo segundo, mesmo origin_host)
GetCompleteProduct (PDP) → 2× MISS por navegação
GetPLPItems (PLP) → 2× (1 HIT / 1 MISS) por navegação
- Com
curl único → apenas 1× de cada
Causa
decoMetaRouteConfig() resolve a página (incluindo SEO/head metadata) em um request separado do body. Cada request roda em seu próprio isolate de worker — sem memória compartilhada — então os caches in-memory (SWR Map, dedup de in-flight) não deduplicam entre as duas passadas.
Resultado: 2× queries ao Magento por navegação mesmo com SWR/STALE configurado nos loaders, porque os dois isolates não se enxergam.
Proposta de fix
A passada de SEO/head deveria reusar os dados já resolvidos do corpo em vez de re-rodar os loaders do Magento. Algumas alternativas:
- Compartilhar o resultado do
loadCmsPage com o decoMetaRoute — passar loaderData (que já contém seo) para o handler de meta, evitando uma 2ª chamada ao serverFn.
- Fundir as duas passadas em uma única request — body + SEO/head resolvidos em um único worker request, retornando ambos.
- Garantir HIT de edge-cache na 2ª passada — se a 2ª request for inevitável, ao menos garantir que ela bata no CF Cache API (e não no Magento) para os dados que o body já resolveu.
Impacto
- Dobra o número de queries ao origin (Magento/VTEX) por navegação.
- Aumenta latência percebida na 2ª passada.
- Aumenta carga no backend mesmo com cache configurado no site.
Referências
- Issue no site: deco-sites/granadobr-tanstack#131
- PR que eliminou o cross-fetch PDP+PLP (mas não o double-resolve): deco-sites/granadobr-tanstack#130
src/routes/deco/meta.ts usa decoMetaRouteConfig() de @decocms/tanstack
Contexto
Em sites TanStack (
@decocms/tanstack), cada navegação real do browser dispara 2 worker requests/isolates separados para o mesmo path:/$ou/), chamaloadCmsPageserverFn → roda todos os loaders de seções (PDP/PLP).decoMetaRouteConfig()emsrc/routes/deco/meta.ts→ dispara uma 2ª resolução completa da mesma página, incluindo re-execução de todos os loaders de Magento (ex:ResolveURL,GetCompleteProduct,GetPLPItems).Confirmado via New Relic no projeto
granadobr-tanstack(issue #131):ResolveURL→ 2× MISS por navegação (mesmo segundo, mesmoorigin_host)GetCompleteProduct(PDP) → 2× MISS por navegaçãoGetPLPItems(PLP) → 2× (1 HIT / 1 MISS) por navegaçãocurlúnico → apenas 1× de cadaCausa
decoMetaRouteConfig()resolve a página (incluindo SEO/head metadata) em um request separado do body. Cada request roda em seu próprio isolate de worker — sem memória compartilhada — então os caches in-memory (SWR Map, dedup de in-flight) não deduplicam entre as duas passadas.Resultado: 2× queries ao Magento por navegação mesmo com SWR/STALE configurado nos loaders, porque os dois isolates não se enxergam.
Proposta de fix
A passada de SEO/head deveria reusar os dados já resolvidos do corpo em vez de re-rodar os loaders do Magento. Algumas alternativas:
loadCmsPagecom odecoMetaRoute— passarloaderData(que já contémseo) para o handler de meta, evitando uma 2ª chamada ao serverFn.Impacto
Referências
src/routes/deco/meta.tsusadecoMetaRouteConfig()de@decocms/tanstack