Rendimiento · Pruebas

Verifica antes de creer: lo que una puntuación de velocidad perfecta no muestra.

En LinkedIn es fácil encontrar puntuaciones de velocidad casi perfectas: una tienda de demostración, una captura de PageSpeed por encima de 95 y la promesa de que cambiar de arquitectura hará volar tu tienda. Algunas de esas afirmaciones son ciertas. Muchas dejan fuera lo que importa. Así que, en lugar de creerlas o descartarlas, puse a prueba la idea: una tienda de demostración headless pública frente a dos grandes tiendas reales, 24 pruebas en condiciones idénticas. Esto es lo que encontré, cómo probar bien y los trucos de velocidad que funcionan, con lo que cuestan.

En resumen

Una demostración con productos de muestra y sin seguimiento casi siempre le gana a una tienda real, porque el peso de una tienda real viene de sus píxeles, aplicaciones, videos y scripts. En mis pruebas, una tienda headless real no fue más rápida que una basada en un tema. Y una prueba no es una medición: la misma página en las mismas condiciones varió hasta 26 puntos entre pruebas. Repite cada prueba, reporta el promedio y la desviación estándar, cuenta lo que carga la página y dale a una persona de tu equipo la responsabilidad del rendimiento.

Por qué las demostraciones son rápidas

Las tiendas headless, un frontend rápido en JavaScript sobre una plataforma de comercio como Shopify, son una arquitectura real y con soporte. Sus demostraciones suelen estar bien construidas. Pero una demostración normalmente tiene productos de muestra y no tiene analítica, píxeles de anuncios, reseñas, chat ni herramientas de pruebas. No es un negocio en funcionamiento. Así que la pregunta útil no es "¿es rápida?", sino "¿rápida comparada con qué?"

Cómo probé: mismas condiciones, seis pruebas por página

Usé GTmetrix, que permite fijar las condiciones de prueba para que cada ejecución sea comparable:

  • Ubicación: Quebec, Canadá
  • Navegador: Chrome, simulando un iPhone 15/16
  • Conexión: LTE (15/10 Mbps, 100 ms de latencia)
  • Pruebas: 6 por página de inicio, el 8 de octubre de 2026, intercaladas para que ningún sitio tuviera un momento "tranquilo"

Probé tres páginas de inicio: una tienda de demostración headless pública en Shopify y dos marcas grandes y conocidas en Shopify, una con un frontend headless en Next.js y otra con un tema de Shopify. No nombro las tiendas, porque lo importante es la comparación, no las marcas, y los números de cualquier tienda cambian de una semana a otra. Una tercera tienda real superó el tiempo límite dos veces porque nunca terminaba de cargar, así que la dejé fuera.

Es una prueba pequeña: solo páginas de inicio, una ubicación, un día. Tómala como un ejemplo de cómo verificar una afirmación, no como un ranking.

Qué encontré

Promedio de 6 pruebas, ± desviación estándar, con el rango de la puntuación. Menos es mejor en todas las métricas excepto la puntuación.

Página de inicio (móvil, LTE)Demostración headlessTienda A (real, headless)Tienda B (real, tema de Shopify)
Puntuación de rendimiento de GTmetrix82 ± 6 (72–87)39 ± 4 (34–44)43 ± 4 (37–47)
Largest Contentful Paint1.9 ± 0.3 s3.6 ± 1.0 s3.0 ± 0.7 s
Total Blocking Time26 ± 42 ms5,159 ± 1,987 ms2,136 ± 819 ms
Cumulative Layout Shift00.030.03
Carga completa3.1 s29.4 s26.9 s
Solicitudes41258440
Peso de la página0.3 MB17.7 MB7.0 MB

Destacan dos cosas.

1. Una demostración no es una tienda. La demostración carga 41 solicitudes y 0.3 MB. Las dos tiendas reales cargan 258 y 440 solicitudes, y de 7 a 18 MB: analítica, píxeles de anuncios, reseñas, chat, personalización y, en la página de inicio de la Tienda A, un video de 7.8 MB. Casi nada de eso viene del tema, y no desaparece al cambiar el frontend.

2. Ser headless no hizo más rápida a la tienda real, en mis pruebas. La Tienda A, con la misma arquitectura que la demostración, promedió 39. La Tienda B, con un tema, promedió 43. La diferencia es menor que su variación entre pruebas. Con dos tiendas no puedo decir qué es cierto en general, pero aquí lo que decidió la velocidad fue lo que cargaba cada página, no cómo estaba construido su frontend.

Pasar a headless también añade trabajo que una demostración no muestra: un frontend que alojar y mantener, analítica y seguimiento que reconstruir y verificar, y aplicaciones que se conectan al tema y hay que reconectar o reemplazar. Nada de esto hace que headless sea un error. Para algunas marcas es la decisión correcta. Significa que la puntuación de una demostración no es evidencia para tu tienda.

Una prueba no es una medición

Mira los rangos. En condiciones idénticas:

  • La demostración obtuvo entre 72 y 87.
  • El Largest Contentful Paint de la Tienda A fue de 2.6 a 5.0 segundos.
  • También pasé este sitio por la misma configuración seis veces. Obtuvo entre 71 y 97, y su Total Blocking Time pasó de 58 ms a 675 ms entre dos pruebas hechas con pocos minutos de diferencia.

Si pruebas una sola vez, puedes "demostrar" casi cualquier cosa. Una prueba de mi sitio (71) salió peor que una de la demostración (87). Al repetir cada una seis veces se ve que sus puntuaciones se solapan, así que ninguna ha demostrado ser más rápida en puntuación.

No todos los números varían igual. El número de solicitudes y el peso de la página casi no cambiaron (menos de 5% de variación). La mayoría de los tiempos variaron entre 10% y 35%. El Total Blocking Time fue el que más varió, porque depende de lo que esté haciendo la CPU cuando llegan los scripts. Eso te dice dónde tener cuidado.

Cómo probar bien:

  1. Fija las condiciones. Misma herramienta, misma ubicación, mismo dispositivo, misma conexión. GTmetrix permite fijar las cuatro. PageSpeed Insights no te deja elegir, así que repítelo más veces.
  2. Prueba cada página al menos cinco veces, intercalando las páginas que comparas.
  3. Reporta el promedio y la desviación estándar, no la mejor prueba. El promedio dice dónde suele quedar una página. La desviación estándar dice cuánto confiar en un resultado aislado.
  4. Solo llámalo diferencia si es mayor que el ruido. Si los rangos de dos páginas se solapan, no has demostrado que una sea más rápida.
  5. Revisa también los datos de usuarios reales. PageSpeed muestra lo que vivieron los usuarios de Chrome cuando un sitio tiene suficiente tráfico. Las pruebas de laboratorio dicen por qué. Los datos de campo dicen si importa.

Cinco comprobaciones antes de creer cualquier afirmación sobre velocidad

  1. Prueba la página real, no la captura, y repítela, como arriba.
  2. Cuenta lo que carga. En las DevTools de Chrome, abre la pestaña Network y recarga. Mira las solicitudes, el tamaño total y cuántos dominios aparecen.
  3. Busca las etiquetas. Busca en el código de la página lo que necesita un negocio real: analítica, píxeles de anuncios, reseñas, chat, pruebas A/B. Si faltan, la puntuación mide una página que tus clientes nunca verán.
  4. Compara cosas comparables. Una demostración frente a una tienda con cientos de solicitudes no es una prueba de la arquitectura.
  5. Pregunta qué quedó fuera. Una puntuación sin condiciones, sin pruebas repetidas y sin datos de usuarios reales es un punto de partida, no una evidencia.

Trucos de velocidad que funcionan, y lo que cuestan

Apliqué estos en este sitio. Algunos eliminan trabajo. Uno sobre todo lo retrasa, y esa diferencia importa.

CambioQué ganaQué cuesta
Fuente alojada en el propio sitio y precargada, en lugar de Google FontsEl texto aparece sin esperar dos conexiones extraTú mismo actualizas los archivos de la fuente
Las etiquetas de analítica, anuncios, consentimiento y mapas de calor cargan con el primer desplazamiento, toque, tecla o movimiento del ratón, o a los 4 segundosNada de terceros compite con la primera pinturaLos visitantes que se van en unos 4 segundos sin interactuar no se cuentan en la analítica y no ven anuncios
Un botón de terceros carga solo cuando el visitante se acerca a élNingún script ni cookie extra en la primera cargaEl botón aparece un momento después
El texto principal entra con una animación sin empezar invisibleCuenta como pintado en cuanto apareceUna animación un poco menos llamativa
Los efectos de desplazamiento miden el diseño antes de cambiar estilos, y las animaciones solo usan transformSin recálculos forzados, desplazamiento más fluidoCódigo más cuidadoso que mantener
Quitar los scripts que nadie usaMenos que descargar y ejecutar, para cada visitanteAlguien tiene que preguntar para qué sirve cada script

La segunda fila merece honestidad. Mis etiquetas siguen cargando, solo que más tarde. GTmetrix espera lo suficiente para verlas, por eso su tiempo de "carga completa" para mi sitio fue de unos 10 segundos, mientras que el contenido principal apareció en alrededor de 1. Es también la razón más probable de que mi Total Blocking Time subiera en algunas pruebas: las etiquetas llegaron mientras la prueba seguía midiendo. Una prueba que no espera, o un visitante que se va en menos de 4 segundos, nunca las carga.

Para un sitio personal, es un intercambio aceptable. Para una tienda, normalmente no. Si un píxel de anuncios no se dispara, la plataforma no puede atribuir la venta y la campaña parece peor de lo que es. Las herramientas de pruebas A/B suelen necesitar ejecutarse antes de que aparezca la página, o los visitantes ven la versión original un instante antes de la variante. Retrasarlas para ganar puntuación hace que la tienda parezca más rápida y que cada decisión basada en sus datos sea menos precisa. A veces, más lento y preciso es la mejor decisión de negocio.

No hay píldora mágica: dale el trabajo a alguien

El patrón que veo son empresas esperando el único cambio que arregle la velocidad de una vez: una nueva plataforma, un nuevo tema, un plugin. En mis pruebas, dos tiendas reales con arquitecturas distintas quedaron más o menos en el mismo lugar, porque las dos cargan el mismo tipo de peso. Lo que funciona es más lento y más fiable: alguien que se haga cargo del problema, mida bien, cambie una cosa y vuelva a medir.

Si tienes un equipo técnico, haz que una persona sea la experta en rendimiento, y dale IA para multiplicar sus pruebas:

  • Más pruebas, más rápido. Un asistente de IA puede lanzar pruebas repetidas, reunir los resultados y calcular promedios y desviaciones estándar. Las 24 pruebas de este artículo se hicieron y resumieron así.
  • Leer los informes por ti. Cada informe lista los scripts, imágenes y solicitudes que más cuestan. Un asistente puede compararlos entre pruebas y páginas.
  • Verificar las afirmaciones antes de que el equipo actúe. Una hora de pruebas bien hechas vale más que un mes en la migración equivocada.
  • Mantener el criterio humano. La IA es rápida midiendo y puede equivocarse con seguridad. Decidir qué intercambio conviene al negocio sigue siendo trabajo de la persona.

Las reglas también cambian: las métricas, cómo los buscadores ordenan las páginas y cómo los asistentes de IA eligen qué fuentes citar. Escribí sobre cómo seguir esos cambios con IA en Las buenas prácticas caducan.

Una persona especialista que prueba mucho le ganará siempre a una píldora mágica, porque sabrá qué mide la puntuación y cuánto se mueve por sí sola.

Erwin MonguiDirector de Tecnología en Cedar Planters e ingeniero certificado en Inteligencia Artificial, en Toronto.

Recibe mis próximos casos y artículos en la Búsqueda de Google.