Field noteField note de performance
Cómo diagnosticamos una regresión de LCP en 36 URLs
Search Console reportó un solo grupo deficiente de LCP de escritorio en 36 URLs comerciales. Este es el razonamiento exacto que usamos para pasar de una señal agregada a cambios acotados — y por qué no lo declaramos resuelto antes de que la ventana de campo lo confirme.
Actualizado Julio 2026 · 11 min de lectura
Trabajamos típicamente con tiendas Shopify y Shopify Plus que facturan $500k+ al año.
Publicado
La señal: 36 URLs de escritorio fallaron como un solo grupo
Google Search Console agrupó 36 URLs comerciales bajo el mismo problema: Largest Contentful Paint por encima de cuatro segundos en escritorio.
Cuando muchas URLs comparten el patrón, la primera pregunta no es cuál página tiene la imagen más grande. Es qué comportamiento de render, entrega o terceros tienen en común.
Lo que el reporte no probaba
Search Console no identificaba una única causa raíz ni demostraba que cada visita tuviera el mismo elemento LCP. Es evidencia poblacional dentro de una ventana móvil, no un debugger de línea de código.
Convertimos el grupo en una matriz pequeña de pruebas
Probar 36 URLs de forma aislada habría producido más capturas, no necesariamente más certeza. Seleccionamos rutas que ejercitaban los layouts, assets y caminos de servidor compartidos.
- Homepage y una página de servicio de alto valor.
- Una ruta que usa el layout compartido de servicios.
- Un hub y un recurso largo.
- Equivalentes en inglés y español.
- Respuestas con caché fría y caliente.
La meta era separar TTFB, descubrimiento de recursos, render, hydration y terceros.
Las causas compartidas que investigamos primero
Cobertura de edge cache
Varias familias comerciales quedaban fuera de la política pública de caché y repetían SSR y trabajo de datos.
Terceros dentro de la ventana de LCP
Accesibilidad, analítica y session replay eran útiles, pero no necesitaban competir con el primer contenido importante.
Contenido oculto hasta hydration
Un headline o hero dentro de una animación que empieza en opacity cero puede pintarse más tarde aunque ya exista en el HTML.
Métricas sin contexto de elemento
Añadimos ruta, elemento, rating y conexión a los eventos para que una alerta indique también dónde empezar a investigar.
Usa la misma disciplina
Obtén un scope ligado a templates y pruebas comparables
Envía la URL, los templates importantes y tu evidencia actual. Definimos baseline y validación antes de recomendar código.
Solicitar scope de performance →Los cambios acotados que enviamos
- Ampliamos la caché edge pública y mantuvimos privados admin, portal, checkout y API.
- Añadimos headers de caché CDN para Cloudflare.
- Diferimos terceros no críticos hasta consentimiento, load o idle.
- Mantuvimos visibles antes de hydration los candidatos principales de LCP.
- Añadimos contexto por ruta y elemento a LCP, INP y CLS.
No mezclamos este release con un rediseño ni un upgrade amplio de dependencias. Cada cambio correspondía a un failure mode nombrado y conservaba un rollback claro.
Desplegar no equivale a resolver el problema de campo
Los cambios están publicados, pero Search Console usa una ventana móvil de usuarios reales. Las sesiones lentas anteriores siguen dentro del agregado mientras llegan nuevas visitas.
Separamos tres afirmaciones:
- El código y los cambios de entrega salieron correctamente.
- Las pruebas comparables pueden mostrar si mejoraron las causas atacadas.
- Search Console confirmará después si la población salió del grupo deficiente.
Al publicar este field note, la primera está confirmada y la tercera sigue en validación. No declaramos un resultado antes de que la fuente lo soporte.
Qué se transfiere a una investigación de Shopify
Shugert.com.mx corre en TanStack Start y Lovable, no en Shopify. El middleware no se copia directamente a Liquid o Hydrogen, pero la disciplina de diagnóstico sí.
- Empezar con field data y familias de templates.
- Identificar el elemento LCP y su request path.
- Separar theme, imágenes, app embeds, consentimiento y analítica.
- Hacer cambios acotados en staging.
- Repetir el mismo estado, viewport y conexión.
- Esperar la ventana de campo antes de hacer claims poblacionales.
En Shopify, la causa compartida suele estar en JavaScript global del theme, apps cargadas donde no aportan, descubrimiento tardío del hero o herramientas de consentimiento que ocupan el critical path.
Checklist para una regresión multi-URL de LCP
Baseline
- Exportar URLs afectadas y rango de fechas.
- Agrupar por template y estado del storefront.
- Capturar caché fría/caliente, elemento LCP, requests y terceros.
Control del release
- Ligar cada cambio a una causa sospechada.
- Mantener fuera cambios no relacionados.
- Preservar rollback y baseline conocido.
Validación
- Repetir ruta, viewport, conexión y consentimiento.
- Verificar que no aparezcan regresiones de CLS, INP o funcionalidad.
- Monitorear datos reales y esperar la ventana de Search Console.
Preguntas frecuentes
¿Por qué varias URLs pueden compartir el mismo problema?
Porque reutilizan layout, caché, scripts globales, hero loading o herramientas de terceros. Un fallo compartido suele apuntar a una causa compartida.
¿Un Lighthouse mejor significa que Search Console ya está resuelto?
No. Lighthouse es laboratorio; Search Console agrega usuarios reales durante una ventana móvil. Ambos responden preguntas distintas.
¿El método sirve para Shopify?
Sí. Agrupar templates, identificar el elemento LCP, aislar apps y scripts, cambiar en staging y validar estados equivalentes aplica a Shopify. El código exacto depende del theme y el stack.
Lecturas relacionadas en este clúster
Performance Shopify
Arregla la causa compartida, no 36 URLs una por una
Conectamos el problema de campo con theme, apps, assets y delivery path, y devolvemos un plan acotado con staging y validación.
Ver el servicio de performance →