Checklist first-byte para SEO y PPC

Una buena mañana, un usuario decide acceder a tu web. Puede haber sido porque ha visto un reel y ha decidido buscarte, o porque ha hecho una búsqueda en Google y visto tu enlace, sobre el que hace clic de manera instintiva sin pensar demasiado. O porque Perplexity se lo ha recomendado, que estamos en 2026 y no todo es Google.

Pasan 900 milisegundos y todavía no hay nada en su pantalla. Es una persona nerviosa y casi 1 segundo sin ser entretenido de manera artificial se le antoja una eternidad.

Durante ese rato, su navegador está con un mono con platillos en la cabeza. No hay imagen que descomprimir, ni CSS crítico que priorizar. Ni mucho menos JavaScript que aplazar.

Solo queda esperar 🧘

Por supuesto, el usuario no espera.

El TTFB marca cuándo puede empezar todo lo demás. Si el primer byte llega tarde, el LCP arranca tarde. En orgánico ese LCP entra en Core Web Vitals. En Ads afecta a la experiencia de la página de destino, que es uno de los componentes del Quality Score. La misma latencia acaba en dos tareas diferentes: visibilidad orgánica y eficiencia de la inversión.

En mi envío anterior explicaba cómo interpreta un agente el HTML mediante el DOM, el árbol de accesibilidad y las capturas; esta empieza un paso antes, mientras ese HTML todavía está retenido en el servidor.

En este tutorial, os hablaré de los consejos que expuse en mi charla en el Performance Observer sobre optimización de WPO server-side:

El servidor más rápido es el que no ejecuta.

La mejor situación a la que se puede aspirar es a dar una respuesta desde el edge, evitando depender del origen.

Un resultado en Redis evita repetir una consulta. Un índice adecuado evita recorrer una tabla entera. Comprar más CPU recorta una parte del tiempo, pero mantiene el mismo trabajo y añade capacidad a la factura.

Personalmente, uso 700 ms de TTFB como umbral de acción. web.dev sitúa alrededor de 800 ms el límite de un resultado bueno en datos de campo. Para una landing con tráfico de campaña prefiero margen: cuando llega el pico, una respuesta que ya partía cerca del límite tiene poco espacio para absorber cachés frías, conexiones nuevas o créditos de CPU agotados.

Antes de ampliar tus contratos de infraestructura o servidor, o abrir un ticket ambiguo a tu sysadmin de turno o proveedor de hosting al uso, mide el tiempo hasta el primer byte:

Ejecuta el comando desde tu red y repítelo desde dos regiones más (con VPN, una shell remota o WebPageTest... o pedírselo a ese compañero que trabaja en remoto desde Sri Lanka). Anota el mejor resultado, el peor y la IP que ha respondido. Si entre regiones aparecen más de 300 ms de diferencia, empieza por el edge y la geografía. Por ahora, descarta problemas de aplicación web.

Esa prueba es una brújula. El diagnóstico necesita datos de campo:

• CrUX o el RUM que tengas montado: TTFB en el percentil 75 móvil, por tipo de página y por mercado.

• Crawl Stats de Search Console: el tiempo medio de respuesta que ha recibido Googlebot.

• APM: el reparto del tiempo dentro de la aplicación, con endpoints y llamadas externas.

Durante mucho tiempo, la herramienta elegida por gran parte del sector ha sido Lighthouse: creada por Google, sencilla de entender, manejable. Pobre, en realidad, cuando la usas desde su interfaz gráfico.

¿Por qué? Porque los resultados que da los saca de un espacio de pruebas controlado. CrUX, RUM y APM recogen tráfico real. Un Lighthouse rápido junto a un percentil 75 móvil lento indica que parte de los usuarios pasa por otra región, por una caché fría o por una ruta distinta.

El TTFB también pone suelo al LCP. Con 700 ms consumidos antes del HTML, el navegador empieza a descubrir el elemento principal después de esos 700 ms, y aún faltan la descarga, el procesamiento y el render. Por eso la optimización del servidor va por delante de muchas mejoras visibles en el waterfall.

“El servidor va lento”. La frase. LA FRASE. Eso que dicen en ciertos entornos para lavarse las manos.

Yo ordeno el problema en 7 capas, tal y como lo expuse en mi presentación:

1. Surface: navegador, RUM y Web Vitals. Aquí medimos.

2. Global Edge: CDN, POP y caché distribuida.

3. Gateway: balanceador, TLS, WAF y limitación de peticiones.

4. Logic: runtime, framework, middleware y aplicación.

5. Memory: caché en proceso, Redis, Memcached y page cache.

6. Deep Storage: base de datos, planificador, índices y buffer pool.

7. Bare Metal: CPU, RAM, almacenamiento e hipervisor.

El corte importante está entre Logic y Memory:

• En Logic intentas ejecutar más deprisa.

• En Memory decides si esa ejecución tiene que repetirse. Precomputar al escribir, cachear una respuesta anónima o guardar una consulta frecuente saca trabajo de la ruta crítica.

Para no pedir una migración de arquitectura cuando bastaba con leer un header, aplica tres niveles de triaje, que es justo lo que yo hago cuando trabajo en este tipo de problemas:

• DO: comprobaciones que puedes hacer hoy con el acceso disponible.

• ASK: preguntas concretas para desarrollo, plataforma o proveedor.

• DEMAND: evidencia recurrente, responsable y umbral exigible en un SLA o en el informe mensual.

Empieza por DO y escala cuando la medición justifique la siguiente conversación. “El servidor está lento” da poco juego. “Estas diez landings responden con MISS cuando llevan gclid, suman 420 ms de más y se llevan el 64 % de la inversión” ya permite actuar.

Si el edge entrega el HTML, el origen puede quedarse dormido. Si cada URL baja hasta la aplicación, el CDN solo está sirviendo los estáticos y el coste principal sigue intacto.

DO:

✅ Medir el TTFB desde al menos tres geografías y guardar la diferencia entre la mejor y la peor.

✅ Revisar cf-cache-status, x-cache o cache-status en las diez URLs con más tráfico orgánico o más inversión.

✅ Cruzar el TTFB por país con los mercados que generan conversiones.

✅ Comparar esas rutas con el tiempo de respuesta de Crawl Stats.

✅ Probar la misma landing con parámetros de campaña y sin ellos.

ASK:

❓¿Qué cookies o query strings fuerzan el bypass de caché?

❓ gclid y los UTM forman parte de la clave de caché?

❓¿Qué HTML anónimo puede servirse con stale-while-revalidate?

Un gclid incluido en la clave de caché crea una variante distinta por cada clic. La campaña multiplica los MISS, el origen recibe más trabajo y el TTFB empeora justo cuando cada visita cuesta dinero.

Te pongo un caso especial. Un cliente con el que trabajamos desde hace años tiene un proyecto de venta en todo el mundo. Sus principales mercados están en Europa, África y Norteamérica. Su servidor está basado en Madrid.

El caso. Imagina que un usuario accede desde Barcelona a una URL cacheada. Todo en orden: se computa una latencia que casi depende más de la velocidad de la luz que otra cosa: 180ms para responder.

Ahora otro accede desde Marruecos. Como hay cables submarinos entre España y el norte de África y la caché está configurada en el servidor de Madrid, la respuesta es casi igual que para Barcelona: 190ms.

Finalmente, otro usuario accede desde Seattle, en la costa oeste de US. Su señal tiene que atravesar todo un continente, un océano, llegar a un servidor de cacheado y que este decida qué servir. Como la caché está en Madrid, ¿quién responde? Pues Madrid. 320ms de ida y vuelta.

Sí, la app no ha sido tocada, pero, si tu público está también al otro lado del Atlántico, ¿por qué no configurar una caché de ese lado y responder por debajo de los 200ms?

Las respuestas edge son clave. Y el coste es más bajo de lo que crees.

Antes de ejecutar la aplicación, la petición atraviesa TLS, balanceador, WAF y límites de tráfico. El bloque es corto porque su diagnóstico suele consistir en aislar tiempos, no en revisar toda la plataforma.

DO:

✅ Pasar SSL Labs sobre el hostname de producción.

✅ Comparar conexión fría y conexión repetida en WebPageTest o en DevTools.

✅ Confirmar que la compresión Brotli o gzip está activa en HTML, CSS y JavaScript.

ASK:

❓¿Cuándo se auditaron por última vez las reglas del WAF?

❓¿El pool hacia el origen mantiene las conexiones abiertas?

❓¿Hay errores de certificado o una política HSTS incompleta en las landings de campaña?

El WAF puede sumar pocos milisegundos o varios cientos con conexión fría y reglas pesadas. Comparar la primera petición con las siguientes ayuda a separar ese impuesto del tiempo de la aplicación.

Aquí el APM deja de ser una gráfica decorativa. Necesitas endpoints, percentiles y desglose del tiempo para saber si el retraso está en el runtime, en un middleware o en una llamada de entrada y salida que bloquea.

DO:

✅ Anotar la versión del runtime en producción php -v, Node o Python).

✅ Sacar el top de endpoints por percentil 75 y percentil 95, separando bots cuando se pueda.

✅ Listar los plugins y middlewares que atraviesan las landings de Ads y las plantillas SEO principales.

✅ Comparar una petición caliente con la primera petición tras un despliegue.

ASK:

❓¿Qué impide actualizar el runtime?

❓¿Qué llamada síncrona bloquea la ruta crítica?

❓¿Qué parte del endpoint puede calcularse fuera de la petición?

Un salto de runtime puede mejorar el rendimiento sin tocar la lógica de negocio, aunque las cifras dependen del código y de la carga. La prueba que vale es un benchmark propio, con la misma petición y con datos representativos.

La segunda consulta más repetida merece más atención que otra discusión sobre CPU. La primera suele tener caché porque era obvia. La segunda conserva volumen suficiente para doler y anonimato suficiente para sobrevivir años.

DO:

✅ Medir el hit ratio de la caché por ruta, no solo el promedio global.

✅ Localizar la segunda query más ejecutada y comprobar si su resultado se reutiliza.

✅ Confirmar que hay Full Page Cache para tráfico anónimo en páginas SEO y en landings sin personalización.

✅ Excluir carrito, checkout y cualquier respuesta que dependa del usuario.

ASK:

❓¿Qué TTL tiene cada tipo de dato?

❓¿Cómo se invalida un precio, el stock o un menú?

❓¿Qué cálculo puede precomputarse al escribir en vez de repetirse al leer?

El precio y el stock pueden necesitar minutos. Un menú que cambia dos veces al año admite otra cadencia. La política tiene que distinguirlos, y con esa pregunta basta: la frescura ya tiene su propia entrega en la serie.

El APM enseña a menudo una barra grande etiquetada como “database”. Para convertirla en una tarea hacen falta la consulta, el plan real y el volumen de filas.

DO:

✅ Abrir el listado de slow queries y ordenarlo por tiempo total, además de por peor ejecución.

✅ Ejecutar EXPLAIN ANALYZE sobre la consulta prioritaria en un entorno seguro.

✅ Buscar Seq Scan en tablas grandes.

✅ Revisar los índices compuestos para los filtros y las ordenaciones que aparecen juntos.

✅ Comprobar cuántas filas estima el planificador y cuántas procesa de verdad.

ASK:

❓¿El slow query log está activo y tiene responsable?

❓¿PgBouncer o el pool disponible está dimensionado para el pico real?

❓¿Las estadísticas de la tabla están actualizadas?

En estos casos siempre me gusta presentar una historia personal para ilustrar la gravedad del problema. Si no eres muy técnico, no te preocupes: este es el típico caso que puedes usar para acojonar a tu proveedor técnico.

Imagina que tienes un ecommerce. Como buena tienda online, tienes categorías con productos. Para que un producto aparezca en una categoría, tendrás que vincularlo a la misma. El problema surge cuando un mismo producto puede estar en más de una categoría a la vez: eso requiere una tabla intermedia en la base de datos.

Pues bien. En un proyecto bastante grande, me topé con un caso como este donde la tabla intermedia no estaba indexada por la combinación de categoría y producto. Esto obligaba a la aplicación de base de datos a recorrer la tabla entera para saber si un producto estaba en una categoría concreta.

¿Te parece una tontería? Una tontería que costaba 5 segundos de ejecución para una llamada hecha desde el checkout.

Una vez arreglado y reindexado, el valor descendió de 5 segundos a 200 ms. Un 4 % del total.

¿Te sigue pareciendo una tontería? Dale a responder a este email y dímelo 🙂

Una comprobación basta para decidir si esta capa merece investigación:

✅ Revisar si la instancia es burstable y si la degradación coincide con los picos de campaña.

ASK: porcentaje de CPU steal, créditos de CPU e IOPS disponibles durante el pico. Añadir CPU y RAM mantiene el cuello de botella cuando el límite real está en el almacenamiento. Importa la forma de la instancia, además del tamaño.

Antes de investigar el 10 % raro, descarta estas tres causas:

1. Caché ausente o mal configurada. Un hit ratio por debajo del 80 % deja demasiado tráfico en el origen.

2. Una query sin límite, o con un filtro que ha perdido selectividad al crecer la tabla. El TTFB sube mes a mes aunque el tráfico se mantenga estable.

3. Geografía incorrecta. CrUX o las pruebas regionales muestran entre 200 y 500 ms de diferencia según el país.

El orden también importa. Caché, query y geografía tienen mediciones concretas y arreglos comprensibles. Si las tres están limpias, ya merece la pena abrir el abanico hacia WAF, pools, IOPS, pausas del runtime o problemas del hipervisor.

La factura de la nube compra capacidad, no velocidad.

Sin TTFB de campo, cambiar la infraestructura es una apuesta que llega con cargo mensual. Con el TTFB por ruta, mercado y estado de caché, puedes asignar la siguiente comprobación a la capa correcta.

Este envío condensa el material que preparé para Performance Observer. La versión completa tiene 96 ítems, siete capas, glosario y herramientas por bloque:

• Repositorio en GitHub con el marco Do / Ask / Demand y el checklist.

• Checklist operativo en Google Sheets, preparado para usar Archivo, Hacer una copia y marcar el estado por capa.

Tu trabajo puede terminar mucho antes que el arreglo. Mide, localiza la capa y formula la petición con número, ruta y responsable. El lunes, “no lo sabía” ya no vale como respuesta.