1. Definir el resultado y el alcance
Nombra a un responsable y escribe el resultado antes de abrir una herramienta de auditoría. Declara la audiencia, el recorrido, las páginas o rutas, la ventana temporal y la decisión que debe soportar el trabajo. Un objetivo útil describe una tarea, por ejemplo completar un flujo móvil de producto a carrito, no un deseo vago de hacer el sitio más rápido.
Enumera los elementos no negociables: flujo de compra o consulta funcional, acceso a cuenta, comportamiento de consentimiento, accesibilidad, rastreabilidad por buscadores y contenido aprobado. Un aumento sintético en una puntuación no es una victoria si un formulario falla, el contenido queda oculto a la búsqueda o el uso por teclado se vuelve más difícil.
Escribe la página de inicio, la acción del usuario y el estado final exitoso en una sola frase.
Elige un resultado que no deba empeorar, como el envío correcto de un formulario o la ausencia de un nuevo obstáculo de accesibilidad.
2. Capturar una línea base comparable
Antes de cambiar código, contenido, configuración o etiquetas, guarda la lista de URLs, la fecha, las condiciones de prueba, la versión publicada, los informes o trazas y el resultado de las comprobaciones manuales. web.dev recomienda registrar el estado del sitio antes de los cambios y probar varios tipos de página; para aplicaciones de una sola página, incluye rutas, componentes y flujos y no solo la primera carga.
Usa más de una lente. Lighthouse proporciona auditorías automatizadas de rendimiento, accesibilidad, SEO y otras. Prueba la primera carga con almacenamiento borrado o un perfil limpio y luego completa la tarea objetivo. Cuando exista suficiente dato de usuario real, compara grupos de páginas y clases de dispositivo importantes. Core Web Vitals son medidas de campo: LCP cubre carga, INP interactividad y CLS estabilidad visual.
Los datos de campo reflejan visitas reales; las pruebas de laboratorio facilitan reproducir un problema. Usa ambos cuando estén disponibles.
Una carga simulada no puede medir INP porque no hay interacción de usuario; Total Blocking Time en laboratorio es solo un proxy.
3. Auditar el recorrido de extremo a extremo
Agrupa los hallazgos por recorrido y por mecanismo. Revisa tamaño de petición, tiempos y dependencias de los recursos de la página y terceros. Comprueba el viewport móvil, la ruta por teclado, el foco visible, las etiquetas, los mensajes de error, los encabezados, el propósito de los enlaces, el zoom y qué pasa si una imagen, script o servicio dependiente del consentimiento es lento o no está disponible.
Trata la salida automatizada de accesibilidad como triage. W3C indica que ninguna herramienta por sí sola puede determinar si un sitio cumple las normas de accesibilidad; se requiere evaluación humana experta. Para búsqueda, asegúrate de que los recursos renderizados importantes sigan accesibles para los rastreadores tanto como para los usuarios. Incluye redirecciones, canonicales, enlaces internos, directivas robots, mapas de sitio y datos estructurados cuando el cambio les afecte.
Lista gestores de etiquetas, analítica, chat, pago, fuentes, CDNs, APIs y herramientas de consentimiento de las que depende la tarea.
Para pago, autenticación, datos de usuario, cabeceras o controles de seguridad, obtén revisión cualificada de seguridad y de pagos.
4. Construir un backlog priorizado
Escribe una hipótesis pequeña para cada elemento: en esta página o flujo, cambia este mecanismo porque la evidencia sugiere que causa este problema; mide el resultado esperado y protege los guardrails nombrados. Mantén la observación distinta del diagnóstico. Una traza guardada puede mostrar una imagen grande retrasando contenido, pero la solución aún necesita revisión de diseño y contenido.
Prioriza los elementos según el impacto, la confianza, el esfuerzo y el riesgo. El impacto es el recorrido prioritario afectado. La confianza indica si coinciden el laboratorio, el campo y la evidencia manual. El esfuerzo incluye la coordinación, no solo el código. El riesgo incluye dependencias, seguridad, complejidad de despliegue y reversibilidad. Un problema crítico de funcionalidad o seguridad puede tener prioridad sobre este modelo y requiere una evaluación especializada.
Mantén propietario, enlace a la evidencia, hipótesis, páginas, medida, guardrails, dependencias, método de despliegue y disparador de reversión.
No combines refactorizaciones no relacionadas en un cambio medido, salvo que la seguridad lo requiera.
5. Publicar de forma segura y mantener una vía de regreso
Antes del despliegue, registra qué cambia, quién aprueba, ventana de publicación, verificador, condición de éxito, disparador de reversión y método de restauración. Prueba en un entorno no productivo representativo cuando sea posible, incluyendo contenido, permisos, integraciones, redirecciones, opciones de consentimiento y caminos de fallo comunes. Producción aún puede diferir por datos, caché, configuración y terceros.
Usa un despliegue gradual, feature flag, activo versionado o configuración reversible cuando la plataforma lo permita. Confirma el comportamiento de caché y CDN antes de comparar resultados. OWASP trata la gestión de configuración y despliegue como área de pruebas de seguridad; cabeceras, permisos, exposición de ficheros y configuraciones de dominio o nube no deberían ser cambios de optimización casuales.
Define un disparador observable, como fallo en el checkout, navegación rota, error cliente inesperado o regresión de accesibilidad.
Un plan de reversión puede reducir el tiempo de recuperación pero no eliminar todo riesgo; prueba la restauración antes de depender de ella.
6. Verificar, decidir y repetir
Tras la publicación, repite las comprobaciones funcionales de la línea base y las pruebas de laboratorio comparables. Vuelve a comprobar los dispositivos, navegadores, estados e integraciones relevantes. Compara condiciones equivalentes: URL, estado de caché, tipo de dispositivo, región cuando sea factible y ventana de medición. Confirma las condiciones de protección además de la métrica objetivo.
Da tiempo a que la evidencia madure. Google señala que los cambios de búsqueda pueden tardar de horas a meses en aparecer y recomienda esperar semanas para evaluar si ayudaron. Los datos de rendimiento real son evidencia agregada, no un veredicto instantáneo de publicación. Registra si mantener, ajustar, investigar o revertir, luego vuelve a tomar una línea base después de cambios significativos de plantilla, plataforma, etiquetas, contenido o dependencias.
El resultado del recorrido esperado mejora y los guardrails acordados permanecen intactos.
Actúa cuando la evidencia de campo o de la tarea entre en conflicto con el resultado de laboratorio, o cuando se produzca una regresión en un guardrail crítico.