Empieza por el síntoma, no por un plugin
Una página puede responder rápido y aun así sentirse lenta. El Time to First Byte (TTFB) mide cuánto espera una navegación el primer byte de la respuesta; el Largest Contentful Paint (LCP) tiene que ver con el contenido visible más grande; el Interaction to Next Paint (INP), con la respuesta a clics, toques y teclado. Mejorar uno no arregla automáticamente los demás.
Esta es una guía de diagnóstico, no el informe de un trabajo medido con un cliente. Usa tu propia evidencia de antes y después para decidir si un cambio funcionó.
Construye una línea base comparable
- Elige plantillas representativas: un artículo, una categoría, un producto y un checkout. Incluye sesiones con usuario identificado y anónimas.
- Registra el dispositivo, la red, la ubicación, la URL, el estado de la caché y la versión desplegada. Repite las pruebas de laboratorio en las mismas condiciones en lugar de quedarte con la mejor puntuación.
- Revisa los datos de campo en PageSpeed Insights o Search Console. Una URL con poco tráfico puede no tener datos propios; los datos del origen son más generales y deben etiquetarse como tales.
- Separa los aciertos de caché de los fallos. Una respuesta rápida en caliente puede ocultar un origen lento durante una invalidación o un pico de tráfico.
Reduce el trabajo del servidor de forma segura
Revisa la solicitud del documento en el panel de red del navegador y luego analiza PHP, las consultas a la base de datos y las llamadas a APIs externas. Las consultas lentas, las llamadas remotas repetidas, la saturación de procesos y un origen lejano requieren soluciones distintas. La caché de objetos persistente puede reducir el trabajo repetido en la base de datos, pero no es lo mismo que guardar en caché una respuesta HTML completa.
La caché de página completa puede ayudar en las páginas editoriales anónimas. No guardes en una caché pública páginas de cuenta, carritos, checkouts, respuestas autenticadas ni respuestas con información personal. Revisa con tu proveedor de hosting las cookies, los métodos de solicitud, los parámetros de consulta y las claves de caché. Prueba con dos sesiones independientes antes de desplegar y confirma que las ediciones de contenido invalidan la caché correspondiente.
Mejora lo que dibuja el navegador
Identifica el elemento LCP real en una traza de rendimiento. Si es una imagen, expón su URL en el HTML inicial, ofrece variantes del tamaño adecuado y no la cargues de forma diferida. Si es texto, revisa los estilos que bloquean el renderizado y la carga de fuentes. Reserva espacio para imágenes y contenidos incrustados para reducir los desplazamientos de diseño.
Para el INP, reproduce la interacción lenta y revisa el hilo principal. Reduce el trabajo innecesario, divide las tareas largas y agrupa las lecturas del diseño antes de las escrituras. Mover trabajo a una tarea posterior solo ayuda si esa tarea no se convierte en otro gran bloque.
// Yield between bounded chunks; feature-detect the scheduling API.
async function yieldToBrowser() {
if (globalThis.scheduler?.yield) {
await globalThis.scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
}
// Process a small, measured batch, yield, then process the next batch.Verifica la experiencia después del despliegue
Los umbrales buenos de las Core Web Vitals son un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos y un CLS de 0,1 o menos, evaluados en el percentil 75 de las visitas. El TTFB ayuda al diagnóstico, pero no es en sí una Core Web Vital. Una prueba de carga de Lighthouse no mide el INP de sesiones reales.
Vuelve a probar el checkout, la navegación, las herramientas de consentimiento y los widgets de terceros. Sigue las mediciones de campo a lo largo del tiempo; la ventana de recolección móvil no reflejará un lanzamiento de inmediato. Registra el cambio y cualquier regresión junto a tus mediciones.
Preguntas frecuentes
¿Aprobar las Core Web Vitals garantiza un mejor posicionamiento?
No. Una experiencia más rápida ayuda a los lectores y puede favorecer el rendimiento en búsqueda, pero la relevancia, el contenido útil y otras señales siguen importando. Trata la velocidad como una mejora de producto medible, no como una promesa de posicionamiento.
¿El TTFB es una de las Core Web Vitals?
No. El TTFB mide la demora hasta el primer byte de la respuesta y ayuda a diagnosticar el camino del servidor y de la red. Las Core Web Vitals son el LCP, el INP y el CLS. Usa el TTFB para investigar una respuesta lenta y luego comprueba por separado cuándo aparece el contenido útil y cómo se comportan las interacciones.
¿Por qué mi página de inicio en caché es rápida pero el checkout es lento?
Una página de inicio pública puede reutilizar HTML en caché, mientras que el checkout necesita trabajo nuevo y específico de cada sesión. Mide la solicitud sin caché y revisa las consultas a la base de datos, las extensiones y los servicios externos. No hagas que el checkout sea cacheable públicamente solo para mejorar una prueba; verifica la privacidad y la corrección de las transacciones.
¿Cómo comparo el rendimiento antes y después de un cambio?
Mantén comparables la URL, el dispositivo, el perfil de red y el estado de la caché, y repite la prueba. Registra el rango de resultados y prueba la misma acción del cliente. Usa los datos de campo a medida que estén disponibles; una sola prueba rápida en laboratorio no describe a todos los visitantes. La checklist de rendimiento ofrece una secuencia de verificación más amplia.
Fuentes y lecturas recomendadas
Sigue explorando
Usa la checklist de velocidad para WordPress de 47 puntos para ampliar la auditoría, o conoce el servicio de rendimiento web.
Leave a Reply