Cuando el departamento de marketing habla de Core Web Vitals, normalmente piensa en posiciones en Google. Eso solo es cierto a medias. Para una tienda mid-market la velocidad de la página es sobre todo una palanca de conversión y solo después una señal de ranking. El cliente no ve tu puntuación en Lighthouse. Ve que la página de producto carga en un segundo en lugar de tres, y llega al carrito más a menudo.
Este texto explica las tres métricas de Core Web Vitals en lenguaje sencillo y después profundiza en la cifra que gobierna al resto: el TTFB. Mostraremos qué lo impulsa, por qué apuntamos por debajo de 200 ms y qué hacer concretamente en Shopify Plus, PrestaShop, WooCommerce y Sylius. Al final encontrarás una checklist para repasar en tu tienda hoy mismo.
Core Web Vitals en un párrafo: LCP, INP, CLS
Las Core Web Vitals son las tres métricas con las que Google describe la experiencia real del usuario, medida no en un laboratorio, sino con tráfico real de los navegadores de tus clientes. Conviene conocerlas, porque es el idioma en el que se habla de rendimiento tanto con el equipo técnico como con la dirección.
LCP: en cuánto tiempo se ve el contenido más importante
Largest Contentful Paint mide tras cuánto tiempo aparece en pantalla el elemento de contenido más grande: normalmente la foto del producto o el titular. Es la métrica más cercana a lo que un usuario llamaría simplemente «la página ha cargado». Objetivo: por debajo de 2,5 segundos. Por encima de 4 segundos el cliente empieza a pensar si no volver a los resultados de búsqueda.
INP: con qué rapidez reacciona la página al toque
Interaction to Next Paint mide el retardo entre un clic y una reacción visible de la página: el despliegue de un menú, añadir al carrito, abrir una variante de producto. En 2024 sustituyó a la antigua métrica FID y es bastante más exigente, porque abarca todo el tiempo de procesamiento y no solo la primera reacción. Objetivo: por debajo de 200 ms. Un INP alto es casi siempre culpa de un JavaScript demasiado pesado: un hilo principal del navegador sobrecargado.
CLS: ¿salta el contenido bajo el dedo?
Cumulative Layout Shift mide cuánto se desplaza la maquetación de la página durante la carga. Todo el mundo conoce ese momento: quieres pulsar «comprar ahora» y en el último instante se carga un banner y pulsas otra cosa. Objetivo: por debajo de 0,1. Los culpables suelen ser imágenes sin dimensiones reservadas, anuncios y fuentes que cargan tarde.
Estas tres métricas describen lo que se ve. Pero antes de que el navegador empiece siquiera a renderizar algo, tiene que recibir el primer byte de respuesta del servidor. Y aquí entra una cifra que no está en la lista oficial de Core Web Vitals y que decide si las demás tienen alguna oportunidad de salir bien.
TTFB: la cifra fuera de la lista que gobierna todo lo demás
El TTFB (Time to First Byte) es el tiempo desde el momento en que el navegador envía una petición hasta que vuelve el primer byte de la respuesta del servidor. Se compone de varias etapas: la resolución DNS, el establecimiento de la conexión TCP, la negociación del cifrado TLS y, después —y esa suele ser la parte mayor y controlable—, el tiempo en el que el servidor de aplicaciones construye realmente la respuesta.
El TTFB no es una de las tres métricas oficiales de Core Web Vitals. Es algo más importante: es su cimiento. El LCP no puede ser más rápido que el TTFB, porque no se puede renderizar contenido antes de que llegue el primer byte. Si el backend necesita 900 ms para generar el HTML, un LCP por debajo de 2,5 segundos sigue siendo alcanzable, pero peleas por él con una mano atada a la espalda. Si el backend responde en 150 ms, toda la optimización restante del frontend tiene de dónde tirar.
Cada milisegundo de TTFB es un milisegundo que el LCP ya no recuperará. Optimizar el frontend sobre un backend lento es pintar la hierba de verde.
Por eso en las auditorías técnicas tratamos el TTFB como la primera medición y no como una nota al pie. Es lo que dice si el problema de rendimiento está del lado del servidor o del navegador, y por dónde empezar.
Datos de campo, no del portátil
Una trampa echa a perder la mayoría de las conversaciones sobre TTFB: medirlo en malas condiciones. El resultado de Lighthouse en tu portátil, conectado a la fibra de la oficina y con la caché caliente, son datos de laboratorio: útiles para depurar, pero inservibles como retrato de la realidad. Google evalúa la página a partir de datos de campo (field data), es decir mediciones reales de los navegadores de los usuarios, recogidas en el informe CrUX. Son dos cifras distintas y se separan con regularidad.
La conclusión práctica: mide el TTFB donde están tus clientes, con el hardware y las conexiones que usan realmente, y en el primer impacto sin caché. Una medición aislada es una anécdota: necesitas una distribución, y normalmente se mira el percentil 75, porque es el que decide la valoración y cuántos clientes están esperando de verdad. Una monitorización continua de usuarios reales (RUM) te dirá lo que un test puntual nunca muestra: que el TTFB sube en las horas punta, cuando la base de datos está bajo carga, es decir justo cuando pierdes más carritos.
Qué impulsa realmente el TTFB
Cuando el TTFB es alto, la causa casi siempre cabe en una de cuatro áreas. Conviene conocerlas por su nombre, porque «la página es lenta» es un diagnóstico inservible, mientras que «el backend renderiza la página de producto en 700 ms porque el catálogo hace 40 consultas sin índice» ya no lo es.
Tiempo de backend y consultas a la base de datos
Es el culpable más frecuente en las tiendas mid-market. El código de la aplicación construye la página: obtiene el producto, los precios, la disponibilidad, las recomendaciones, los datos del carrito. Si lo hace de forma ineficiente —el clásico problema N+1, donde un bucle sobre 30 productos dispara 30 consultas separadas, la falta de índices, consultas pesadas sobre tablas de estadísticas— el tiempo de backend crece linealmente con el catálogo. En uno de nuestros proyectos legacy, las consultas a la base monolítica podían durar varios segundos. Ningún CDN arregla eso, porque el problema está en el código y en el esquema de la base.
Caché, en todos los niveles
La caché es la forma más barata de bajar el TTFB, porque la consulta más rápida es la que no ejecutas. Funciona en varios niveles a la vez: el OPcache guarda el bytecode compilado de PHP para no compilar el código en cada petición; la object cache (Redis, Memcached) guarda los resultados de consultas repetitivas a la base; la full-page cache (por ejemplo Varnish) sirve HTML ya hecho para el tráfico anónimo sin tocar la aplicación. Una tienda sin object cache suele repetir las mismas consultas miles de veces al día.
Hosting y versión de PHP
Un hosting compartido de 30 PLN al mes y un servidor dedicado con PHP-FPM bien configurado son dos mundos distintos de TTFB. El número de workers de PHP-FPM, la CPU y la E/S disponibles, y la propia versión de PHP tienen efecto directo. El salto de PHP 7.4 a 8.2 supone a menudo varias decenas de milisegundos recuperadas sin cambiar una línea de código: las versiones nuevas simplemente ejecutan el mismo código más rápido.
TLS, red y CDN
La negociación TLS y la distancia física al servidor también cuestan. Un cliente de Cracovia que se conecta a un servidor de Fráncfort paga un impuesto por cada kilómetro. Un CDN acorta esa distancia sirviendo el contenido desde un nodo más cercano al usuario, y los protocolos modernos (HTTP/2, HTTP/3, reanudación de sesión TLS) reducen la sobrecarga del establecimiento de conexión. Para el contenido estático, y a veces también para todo el HTML, son varias decenas de milisegundos gratis.
Por qué por debajo de 200 ms es el objetivo correcto
¿Por qué precisamente 200 ms? Porque es el umbral en el que el backend deja de ser el cuello de botella. Por debajo de 200 ms el servidor entrega el primer byte casi de inmediato y deja todo el presupuesto de tiempo restante —esos 2,5 segundos para un buen LCP— para aquello en lo que el frontend influye de verdad: imágenes, fuentes, JavaScript. Es un objetivo de ingeniería, no de marketing: da margen al equipo en lugar de obligarlo a recuperar pérdidas desde el primer milisegundo.
La otra cara de la moneda es financieramente dura. En nuestros proyectos y en los datos del sector, un TTFB por encima de 500 ms correlaciona con una caída de la conversión del 5–10%. No es una caída lineal del ranking en Google: son clientes que cierran la pestaña antes de que la página responda. Para una tienda que factura varias decenas de millones de złoty al año, esos pocos puntos porcentuales son una cantidad con la que la inversión en Redis y en optimización de consultas se amortiza en semanas, no en años.
Con honestidad: no toda tienda debería dejarlo todo para bajar de 250 a 180 ms. Si tu problema real es un INP alto por un JavaScript sobrecargado o un LCP flojo por imágenes de cabecera sin comprimir, ahí está tu dinero y no en el backend. Por eso el orden es siempre el mismo: primero mide dónde se escapan realmente los milisegundos y solo después invierte. Pero si el TTFB supera con regularidad los 500 ms, es casi con seguridad tu mejora más barata y de amortización más rápida.
Un TTFB por debajo de 200 ms no es presumir de una cifra en un informe. Es un presupuesto de tiempo que devuelves al cliente y a la conversión.
Bogart Meble: la prueba de que no es teoría
Concreción en lugar de teoría. En la migración de la tienda de muebles Bogart desde un legacy de 12 años (PHP 5.4, framework a medida, base monolítica) a Symfony 6.4, el punto de partida eran consultas a la base que duraban varios segundos. El tiempo de carga de la página de producto, medido como LCP, era de varios segundos.
Tras reescribir la lógica, añadir Redis como capa de caché y de sesiones, sacar la búsqueda de productos a Elasticsearch y optimizar las consultas, el LCP bajó a menos de un segundo: varias veces más rápido. No hubo magia ni una única bala de plata: hubo object cache allí donde se repetían las mismas consultas, consultas corregidas con índices y el alivio de la base de operaciones que no tienen que bloquear el renderizado de la página. El efecto de negocio a los tres meses: un crecimiento claro de la conversión (en combinación con un nuevo checkout). Describimos el caso completo en nuestros proyectos.
Pasos concretos, plataforma por plataforma
El TTFB se optimiza de forma distinta en cada plataforma, porque en cada una controlas cosas distintas. A continuación, un mapa: dónde está normalmente el cuello de botella y por dónde empezar.
PlataformaCuello de botella típico del TTFBPrimer movimiento con mayor retornoShopify PlusApp bloat y Liquid pesado; el servidor no lo controlasAuditoría de aplicaciones y scripts de terceros, simplificar la plantillaPrestaShopFalta de OPcache, hosting flojo, consultas no óptimasOPcache + PHP-FPM + full-page cacheWooCommerceFalta de object cache, plugin bloat, base lentaRedis como object cache + revisión de pluginsSylius / SymfonyConsultas de Doctrine (N+1), falta de caché y de colasRedis + optimización de consultas + Messenger para tareas asíncronas
Shopify Plus
En Shopify no tocas el servidor: el HTML se sirve desde el edge/CDN global de la plataforma, así que el TTFB en bruto suele ser bueno de serie. Tu cuello de botella está en otro sitio: en el app bloat y en la plantilla. Cada aplicación instalada añade su JavaScript, su CSS y a menudo scripts externos; los bucles pesados y anidados en Liquid pueden inflar el tiempo de renderizado. Pasos: revisa la lista de aplicaciones y elimina las que no uses (recordando que las de pago cuestan a menudo 80–300 USD al mes: el bloat cuesta el doble), retrasa los scripts de terceros, simplifica el Liquid y evita bucles sobre colecciones grandes. Cuando la plantilla llega a sus límites, la solución es Hydrogen: un frontend headless en React renderizado en el edge, que da control total sobre qué se carga y cuándo. Un objetivo realista para una implantación bien hecha son unas Core Web Vitals de 90+. Más sobre la arquitectura en la página de la plataforma Shopify Plus.
PrestaShop
PrestaShop lo alojas tú, así que el TTFB está al 100% en tus manos, y esa es una buena noticia. En orden de mayor retorno: activa y configura el OPcache (y comprueba su hit rate), ajusta el número de workers de PHP-FPM a la CPU disponible, activa la caché integrada de plantillas Smarty y la combinación de assets (CCC), y para el tráfico anónimo añade una full-page cache o Varnish. Del lado de la base: encuentra las consultas lentas en el slow query log, añade los índices que falten, limpia las tablas de estadísticas y de conexiones infladas. Por último, asegúrate de estar en PHP 8.x y en un hosting que no esté compartido con mil otras webs.
WooCommerce
En WooCommerce (es decir WordPress más una capa de tienda) la mayor palanca es la object cache. Añadir Redis, que intercepta las consultas repetitivas —opciones, transients, meta de productos—, puede recortar el TTFB de forma drástica, sobre todo porque el carrito y el checkout no se pueden cachear del todo y allí cuenta cada consulta a la base. El segundo frente es el plugin bloat: cada plugin añade consultas y entradas en autoloaded options; revisa la lista sin sentimentalismos y limpia los transients caducados y una wp_options desbordada. El tercero: el hosting. Un hosting gestionado para WooCommerce con PHP 8.x, OPcache y PHP-FPM es otro nivel frente a un paquete compartido genérico. Para el tráfico anónimo añade full-page cache; para los usuarios logueados apuesta por un backend rápido y object cache.
Sylius / Symfony
En desarrollos a medida sobre Symfony lo controlas todo, y toda la caja de herramientas está abierta. Redis como pool de caché y almacén de sesiones es el punto de partida (exactamente el movimiento que hicimos en Bogart). Del lado de Doctrine: caza las consultas N+1, activa la caché de segundo nivel donde tenga sentido, gestiona de forma consciente el eager y el lazy loading. Las operaciones pesadas —envío de correos, indexación, webhooks, sincronización con el ERP— llévalas a colas con Messenger, para que la petición vuelva al cliente de inmediato en lugar de esperar a un trabajo que puede esperar. Y además los fundamentos de producción que es fácil olvidar: APP_ENV=prod, autoloader optimizado, caché precalentada y OPcache con preloading. La búsqueda de productos conviene dejarla a Elasticsearch para no cargar la base principal.
Checklist: qué verificar en tu tienda
Lista de control para repasar independientemente de la plataforma. Si en algún punto la respuesta es «no lo sé», ese es precisamente el lugar por el que empezar.
Mide el TTFB en condiciones de producción, desde las ubicaciones de tus clientes, y no desde la caché del navegador de tu propio portátil.
Comprueba cuánto tarda el renderizado del backend por sí solo. Por encima de 500 ms busca la causa en la base y en la caché, no en el frontend.
Asegúrate de que el OPcache está activado y comprueba su hit rate.
Añade object cache (Redis o Memcached) allí donde se repitan las mismas consultas.
Encuentra las consultas N+1 y las consultas lentas en el slow query log; añade los índices que falten.
Lleva las operaciones pesadas (correos, indexación, webhooks, sincronizaciones) a colas asíncronas.
Sirve los assets estáticos —y si es posible, también el HTML— desde un CDN cercano al cliente.
Comprueba la versión de PHP. El salto de 7.x a 8.x son a menudo varias decenas de milisegundos gratis.
Limita el número de plugins, aplicaciones y scripts de terceros a los que realmente trabajan.
Configura una monitorización continua del TTFB y de las Core Web Vitals con alertas. Medir una vez por trimestre no es monitorizar.
Conclusiones
Las Core Web Vitals no son una casilla de SEO, sino una palanca de conversión, y el TTFB es su cimiento, porque gobierna todo lo que ocurre después en la página. Apunta por debajo de 200 ms, trata los 500 ms como una señal de alarma y busca los mayores retornos donde están siempre: en la base de datos y en la caché. El ejemplo de Bogart demuestra que pasar de varios segundos a menos de uno no es esoterismo, sino trabajo de ingeniería ordenado.
Si quieres saber dónde están concretamente tus milisegundos y cuánto cuestan realmente en conversión, por ahí empezamos cada proyecto: nuestra auditoría de la tienda mide TTFB, LCP, CLS e INP en el contexto de tu sector y de tu competencia, con una previsión del impacto en las ventas. Con gusto te mostramos cómo se ve en tu caso: escríbenos a través de nuestra página de contacto.