El rendimiento empeora. Una página que cargaba en dos segundos ahora carga en cuatro. Algo ha cambiado.
El diagnóstico responde: qué cambió. Por qué empeoró el rendimiento.
Causas raíz: una función nueva añadió un paquete grande de JavaScript. Una consulta a la base de datos se volvió lenta. Se añadió un script de terceros. Aumentó el tamaño de las imágenes. El servidor se sobrecargó.
Un diagnóstico sistemático encuentra la causa raíz. Una corrección sistemática la elimina.
Método de diagnóstico
Paso uno: identifica el síntoma. El LCP subió de dos a cuatro segundos. El CLS subió de cero coma cero cinco a cero coma dos. El INP subió de cien a cuatrocientos milisegundos.
Paso dos: la cronología. Cuándo empezó el empeoramiento. La semana pasada. Ayer. Hace una hora. La cronología acota la búsqueda.
Paso tres: relaciona con los cambios. Qué código cambió. Qué funciones se lanzaron. Qué cambió en la infraestructura. La correlación señala la causa.
Paso cuatro: aísla la causa. El rendimiento empeoró. Hipótesis: el nuevo paquete de JavaScript. Prueba: mide el LCP con el nuevo paquete desactivado. El LCP vuelve a dos segundos. Hipótesis confirmada.
Paso cinco: corrige o revierte. Corrige la causa (optimiza el paquete) o revierte (deshaz el cambio). La decisión depende de la gravedad.
Ejemplo real: empeoramiento del rendimiento en una tienda online
Síntoma: el LCP subió de dos segundos a tres coma cinco segundos. Lo detectó una alerta de monitorización.
Cronología: el empeoramiento ocurrió el martes por la mañana. El equipo lanzó un nuevo motor de recomendaciones el lunes por la noche.
Correlación: la coincidencia sugiere que el motor de recomendaciones causó el empeoramiento.
Prueba de aislamiento: se desactiva el motor de recomendaciones. El LCP vuelve a dos segundos. Se confirma que el motor de recomendaciones es la causa.
Investigación: el motor de recomendaciones carga imágenes de producto para las recomendaciones. Las imágenes no están optimizadas (tamaño original, sin compresión). Cargar cincuenta imágenes de producto añade dos megabytes a la página.
Corrección: optimizar las imágenes del motor de recomendaciones. Comprimir las imágenes y usar carga diferida para las que quedan fuera de la primera pantalla. El peso de las imágenes baja a quinientos kilobytes. El LCP mejora a dos coma dos segundos.
Despliegue: se revierte el motor de recomendaciones y se despliega la versión optimizada. El LCP vuelve a dos coma dos segundos.
Problemas de rendimiento habituales y soluciones
Problema uno: paquete de JavaScript grande
- Síntoma: LCP lento, INP lento
- Causa: una función nueva añade código y el paquete crece
- Solución: dividir el código de la función y cargarla de forma diferida
- Mejora esperada: el LCP mejora cero coma cinco segundos
Problema dos: consultas lentas a la base de datos
- Síntoma: TTFB lento
- Causa: una consulta a la base de datos se vuelve lenta (falta un índice, la consulta une muchas tablas)
- Solución: añadir un índice, optimizar la consulta, guardar los resultados en caché
- Mejora esperada: el TTFB mejora doscientos milisegundos
Problema tres: imágenes sin optimizar
- Síntoma: LCP lento, mucho consumo de ancho de banda
- Causa: las imágenes son grandes (sin comprimir, formato equivocado)
- Solución: comprimir las imágenes, convertirlas a WebP, usar imágenes adaptables
- Mejora esperada: el LCP mejora un segundo
Problema cuatro: scripts de terceros
- Síntoma: LCP lento, la página deja de responder
- Causa: la analítica, el seguimiento y los anuncios de terceros ralentizan la página
- Solución: cargar de forma diferida los scripts de terceros, usar un web worker, cargarlos de forma asíncrona
- Mejora esperada: el LCP mejora cero coma cinco segundos, el INP mejora cien milisegundos
Problema cinco: CLS por anuncios o contenidos incrustados
- Síntoma: el diseño salta mientras se lee
- Causa: los anuncios cargan y ocupan espacio, el contenido se desplaza
- Solución: reservar espacio para los anuncios, cargar de forma diferida los anuncios que quedan más abajo
- Mejora esperada: el CLS mejora de cero coma dos a cero coma cero cinco
Monitorización para detectar a tiempo
Alerta por empeoramiento: si el LCP supera los dos coma cinco segundos, avisa al equipo.
Alerta por retroceso: si el LCP sube más de cero coma cinco segundos respecto al punto de partida, avisa al equipo.
Alerta por impacto en el negocio: si la finalización del registro baja un uno por ciento, avisa al equipo (puede indicar un problema de rendimiento).
Ejemplo real: alertas en una empresa SaaS
- Alerta uno: si el LCP supera los dos coma cinco segundos
- Alerta dos: si se detecta un retroceso de rendimiento (el LCP sube un cincuenta por ciento en un día)
- Alerta tres: si las Core Web Vitals pasan de buenas a necesitan mejoras para más del cinco por ciento de los usuarios
- Alerta cuatro: si la finalización del registro baja del objetivo (puede indicar un problema de rendimiento en la página de pago)
Cuando salta una alerta: el equipo técnico investiga en una hora. Se identifica la causa raíz. La corrección se despliega el mismo día.
Ejemplo real: problema de rendimiento en el procesamiento de pagos
Síntoma: la tasa de abandono del pago subió del quince por ciento al veinticinco por ciento. Empezó el jueves.
Investigación: empeoró el rendimiento de la página de pago. El tiempo de interacción del botón de pago subió de doscientos milisegundos a un segundo.
Cronología: el procesador de pagos hizo un cambio de infraestructura el jueves por la mañana.
Causa raíz: el procesador de pagos pasó de California a Europa. La latencia de red entre el usuario y el procesador de pagos subió doscientos milisegundos. El tiempo total de procesamiento del pago subió a un segundo.
Solución: usar una ubicación de borde de la CDN cercana al usuario. Enviar la petición de pago a través del borde local de la CDN. El borde de la CDN la transmite al procesador de pagos europeo. La latencia de red baja. El tiempo de procesamiento del pago vuelve a doscientos milisegundos.
Resultado: la tasa de abandono del pago vuelve al quince por ciento.
Impacto en el negocio: cinco mil pagos al mes con un quince por ciento de abandono son setecientas cincuenta conversiones fallidas. Con un valor de pedido de cien dólares, son setenta y cinco mil dólares perdidos al mes. Corregir la latencia le ahorró a la empresa setenta y cinco mil dólares al mes.
Preguntas frecuentes
¿Cómo diagnosticamos si el problema de rendimiento viene del código o de la infraestructura?
Prueba ambos. Desactiva el código nuevo (revierte). Si el rendimiento vuelve a la normalidad, la causa es el código. Si sigue lento, la causa es la infraestructura. Aísla de forma sistemática. No culpes a la infraestructura si la causa es el código (ni al revés). Con el creador de webs de WEMASY, puedes configurarlo directamente en tu web.
¿Debemos revertir o corregir cuando el rendimiento empeora?
La gravedad decide. Si el empeoramiento es grave (el LCP sube de dos a cinco segundos), revierte de inmediato. La experiencia del usuario sufre. Corrige después. Si el empeoramiento es leve (el LCP sube de dos a dos coma tres segundos), corrige sobre la marcha. El riesgo de revertir es menor que el de desplegar una corrección incompleta.
¿Cómo evitamos que los problemas de rendimiento lleguen a producción?
Haz pruebas de rendimiento en el flujo de CI/CD. Antes de cada despliegue, mide el rendimiento. Si se supera el presupuesto de rendimiento, bloquea el despliegue. Evita los retrocesos antes de que ocurran.
¿Y si el problema de rendimiento es intermitente?
Los problemas intermitentes son más difíciles de diagnosticar. Recoge más datos. Monitoriza durante más tiempo. Lo intermitente puede indicar: un problema de red (ocurre en redes lentas), un problema de tráfico (ocurre en horas punta), un problema de navegador (ocurre en navegadores concretos). Acota el alcance. Prueba la hipótesis en una red, una hora y un navegador concretos.
¿Cómo comunicamos los problemas de rendimiento a los usuarios?
La transparencia genera confianza. Si el problema de rendimiento se conoce y se está corrigiendo, díselo a los usuarios. Ejemplo: empeoramiento del rendimiento en la página de pago por la migración del procesador de pagos. Se espera la corrección para mañana. Estamos investigando. La transparencia reduce la frustración.
¿Debemos tener un ingeniero de guardia para el rendimiento?
En webs críticas para el negocio (tiendas online, SaaS), sí. El ingeniero de guardia responde a las alertas de rendimiento en treinta minutos. Investiga. Despliega una corrección o revierte. Evita que el problema afecte a los usuarios a largo plazo.