Cómo auditar y mejorar el rendimiento de una web paso a paso

“Vamos a optimizar el rendimiento” suele significar, en la práctica, “vamos a comprimir imágenes y a poner defer en algún script hasta que Lighthouse se ponga en verde”. Eso funciona a veces, por casualidad. Auditar rendimiento en serio es otra cosa: es un proceso repetible que empieza por medir de forma correcta, sigue por diagnosticar la causa raíz y termina priorizando por impacto real, no por lo primero que aparece en un informe.

Este artículo describe ese proceso completo, con un ejemplo de auditoría de principio a fin. Si necesitas antes repasar qué mide exactamente cada métrica, esa base está en el artículo sobre Core Web Vitals: INP, LCP y CLS; aquí nos centramos en el método para encontrar y arreglar los problemas reales de tu web.

Campo vs laboratorio: por dónde hay que empezar

Existen dos tipos de datos de rendimiento y confundirlos es la causa número uno de auditorías mal enfocadas:

• Datos de campo (field data): mediciones reales de usuarios reales, agregadas durante una ventana de 28 días. La fuente pública de referencia es el Chrome UX Report (CrUX), que solo incluye sitios con tráfico suficiente en Chrome para generar una muestra representativa. Es lo que Google usa como señal de ranking para Core Web Vitals.
• Datos de laboratorio (lab data): una ejecución simulada, en un entorno controlado, de una sola visita bajo condiciones fijas (dispositivo, red, ubicación). Lighthouse y WebPageTest son datos de laboratorio.

El orden correcto de una auditoría es, por tanto: primero campo (para saber si hay un problema real y de qué tamaño), después laboratorio (para diagnosticar la causa).

graph TD
A[1. Campo: CrUX / Search Console / PageSpeed Insights] --> B{¿Hay una métrica en rojo o ámbar?}
B -->|No| C[Monitorizar, no hay nada urgente que arreglar]
B -->|Sí| D[2. Laboratorio: Lighthouse / WebPageTest / DevTools trace]
D --> E[3. Priorizar por impacto x tráfico afectado]
E --> F[4. Aplicar el cambio de mayor impacto]
F --> G[5. Re-medir en campo tras ventana de 28 días]
G --> B

Paso 1: diagnóstico con datos reales

Antes de abrir Lighthouse, revisa qué dice el tráfico real:

• Informe de Core Web Vitals en Search Console: agrupa URLs por métrica y estado (bueno, necesita mejora, malo), separado por móvil y escritorio. Es la vista más directa de qué está afectando a ranking hoy.
• PageSpeed Insights: para una URL o un origen concreto, muestra el resumen de campo (CrUX) junto al informe de laboratorio de Lighthouse en la misma pantalla, lo que permite comparar ambos de un vistazo.
• Origin fallback: si una página concreta no tiene tráfico suficiente para tener datos propios en CrUX, PageSpeed Insights muestra el agregado de todo el origen como aproximación. Tenlo en cuenta: una página muy pesada puede estar “escondida” detrás del promedio del resto del sitio.

En este paso no se optimiza nada todavía. Solo se responde a una pregunta: ¿qué métrica está mal, en qué segmento de dispositivo, y en qué URLs o plantillas concretas?

Paso 2: laboratorio para encontrar la causa raíz

Con el problema acotado, toca reproducirlo en condiciones controladas y mirar dentro:

• Lighthouse (DevTools, CLI o CI): da una puntuación y, más importante, una lista de “oportunidades” con una estimación de ahorro. Trátalas como pistas, no como cifras exactas: son estimaciones de laboratorio bajo throttling simulado, no una promesa de mejora en campo.
• WebPageTest: permite elegir ubicación geográfica real, tipo de conexión y dispositivo, y genera un waterfall de la carga completa, además de vídeo comparativo entre antes/después de un cambio.
• Panel de Performance de Chrome DevTools: para diagnósticos finos de INP y tareas largas —qué función exacta está bloqueando el hilo principal durante cuánto tiempo—, es la herramienta más precisa porque muestra la traza real, no un resumen agregado.

# Lighthouse por CLI, útil para integrarlo en CI y detectar regresiones
npx lighthouse https://tuweb.com/categoria/ \
  --output=json --output-path=./reporte.json \
  --throttling-method=simulate \
  --only-categories=performance

Paso 3: priorizar por impacto, no por lo primero que aparece

No todas las oportunidades pesan igual. Antes de tocar código, ordénalas por una combinación de tres factores: impacto estimado en la métrica, volumen de tráfico o páginas afectadas, y coste de implementación. Un cambio que ahorra 200ms en una página con el 80% del tráfico vale más que uno que ahorra 800ms en una página que casi nadie visita.

Ejemplo de auditoría de principio a fin

Tomemos un caso representativo: la página de categoría de un e-commerce.

1. Campo. El informe de Core Web Vitals en Search Console marca la plantilla de categoría como “necesita mejora” en móvil: LCP en el percentil 75 de 3.8s (el umbral bueno es ≤2.5s), INP en 240ms (umbral bueno ≤200ms), CLS en 0.06 (bueno, sin problema aquí). El problema está acotado: LCP e INP en móvil, CLS no es prioridad.

2. Laboratorio. Un Lighthouse con throttling de red móvil y un trace en DevTools revelan tres causas concretas:

• El elemento LCP es la imagen del primer producto del listado, pero se carga a través de un carrusel en JavaScript que la inyecta tras hidratar el componente, en vez de estar en el HTML inicial.
• El TTFB es de 600ms porque esa página se renderiza en servidor sin caché de CDN, recalculando la consulta a base de datos en cada petición.
• Hay tareas largas de hasta 180ms disparadas por dos scripts de analítica de terceros que se ejecutan de forma síncrona nada más cargar la página, compitiendo por el hilo principal justo cuando el usuario empieza a interactuar.

3. Priorizar. Por impacto y esfuerzo, el orden es: primero la imagen LCP (afecta al 100% del tráfico de la plantilla, cambio de bajo esfuerzo), después la caché de TTFB (impacto alto, esfuerzo medio: configurar caché de edge para esa ruta), y por último diferir los scripts de analítica (impacto medio en INP, esfuerzo bajo).

4. Aplicar. La imagen LCP pasa a estar en el HTML inicial con fetchpriority="high" en lugar de esperar a la hidratación del carrusel —el detalle técnico completo de esta técnica está en el artículo sobre optimización de imágenes en la web moderna—. La ruta de categoría se sirve tras una caché de CDN con invalidación al actualizar el catálogo. Los scripts de analítica se cargan tras el evento de interacción principal, delegando el trabajo no crítico a un momento en que el hilo principal está libre, como se explica en detalle en la sección de optimización de INP del artículo de Core Web Vitals.

5. Re-medir. El Lighthouse post-cambio confirma la mejora inmediata en laboratorio, pero la validación real llega con la siguiente ventana de 28 días de CrUX: solo entonces se puede confirmar si el percentil 75 de campo se ha movido de verdad.

Cadencia: cuándo volver a auditar

Una auditoría no es un evento único. Lo razonable es combinar dos ritmos: monitorización continua con herramientas de RUM (Real User Monitoring) o el propio informe de Search Console para detectar regresiones tan pronto aparezcan, y presupuestos de rendimiento automatizados en CI (por ejemplo, Lighthouse CI fallando el build si una métrica empeora por encima de un umbral) para no depender de acordarte de auditar manualmente después de cada despliegue grande.

El rendimiento no se arregla una vez: se protege continuamente contra la entropía natural de añadir features, scripts de terceros y contenido nuevo sin que nadie vuelva a mirar el impacto acumulado.