LA LISTA DE VERIFICACIÓN DE CWV
Los doce controles que ejecuto antes de dar por lista una web o plantilla para lanzamiento. Lo suficientemente corto para usar, lo suficientemente estricto para detectar fallos reales.
← Todas las guías Todas las guías de este tema
Por qué funcionan las listas cortas
Los auditorías de desempeño largas se ignoran. Una lista de doce elementos que un desarrollador líder puede ejecutar en una tarde se usa. Esta es la lista que ejecuto antes del lanzamiento, antes de un cambio de plantilla importante, y después de cualquier sorpresa de "añadimos un pequeño script".
Asume que ya conoces las métricas. Si necesitas la historia del diagnóstico, lee por qué tu sitio web es lento. Si necesitas cirugía en una métrica, lee la guía de LCP, INP, CLS. Esta página es la puerta.
Punto clave: Una lista de verificación que terminas vence a una auditoría de 40 páginas que nadie abre dos veces.
Los 12 elementos
| # | Verificación | El resultado se ve bien |
|---|---|---|
| 1 | Datos de campo extraídos | CrUX o RUM para las plantillas clave, percentil 75 móvil |
| 2 | Elemento LCP identificado | Puedes nombrar el elemento y su URL en la página de conversión |
| 3 | Presupuesto de medios LCP | Hero con peso sensato, formato moderno, dimensionado, precargado si es necesario |
| 4 | TTFB sensato | HTML en caché o estático mantiene TTFB fuera de la zona de peligro |
| 5 | JS en ruta crítica | Sin chat, A/B o hidratación pesada antes de la primera interacción necesaria |
| 6 | Verificación puntual de INP | Los toques primarios se mantienen responsivos en un teléfono de gama media |
| 7 | Fuentes | Subconjunto, alojado localmente o CDN controlado, sin texto invisible de múltiples segundos |
| 8 | Espacio reservado para CLS | Las imágenes, incrustaciones y anuncios tienen dimensiones o cajas de relación de aspecto |
| 9 | Terceros listados | Cada etiqueta tiene un propietario y una razón de ser |
| 10 | Encabezados de caché | HTML y activos tienen una política de caché intencional, no accidental |
| 11 | Paridad de plantillas | Página de inicio, hub y plantillas de artículos, cada una revisada, no solo la principal |
| 12 | Regla de parada | Paras cuando CWV pasa, no cuando Lighthouse llega a 100 |
Imprímela, pégala en el ticket de lanzamiento, o úsala como lista de verificación de PR. El punto es aprobado o reprobado binario por fila, no respuestas en ensayo.
Punto clave: Si no puedes marcar el elemento 1 y el elemento 2, no estás listo para los elementos 3 al 12.
Cómo usarlo realmente
Ejecuta la lista en las plantillas que generan dinero o posiciones: página de inicio, página de destino principal, categoría o hub, y una página de artículo o producto representativa. Una página de inicio verde con una plantilla de artículo roja sigue siendo un lanzamiento fallido.
Asigna un responsable por cada fallo. El trabajo de desempeño sin propietario se convierte en un hilo de Slack. Vuelve a ejecutar los datos de campo una semana después del lanzamiento, no solo en staging. Staging miente sobre terceros, temperatura de caché, y dispositivos reales.
Cuando todo aprueba, detente. La optimización adicional es pulido de marca opcional a menos que una prueba de conversión específica diga lo contrario.
Concepto clave: Usa la lista de verificación como filtro en las plantillas que importan, luego retírate cuando los datos de campo se validen.
Por qué repruebo equipos
Marcar verde un laboratorio como aprobado cuando Search Console aún muestra un grupo de URL deficiente. Enviar una página de marketing nueva que nunca estuvo en la lista de verificación. Dejar widgets de chat en la ruta crítica porque ventas lo pidió. Corregir CLS en staging con espacios publicitarios vacíos que fallan en producción.
También: tratar la lista de verificación como algo único. Las plantillas se desvían. Una reejecución trimestral en las páginas clave detecta la degradación lenta por "solo una etiqueta más".
Si más de tres filas fallan, no paralelices doce micro-tareas. Corrige LCP y terceros primero, luego reejecutate. La mayoría de los boards se limpian más rápido así que con un sprint sin enfoque.
Concepto clave: Reprueba el lanzamiento cuando falten datos de campo o cobertura de plantillas, no cuando una puntuación de laboratorio de vanidad es 89.
Dónde se ubica esta lista de verificación en el cluster
Usa por-qué-mi-sitio-es-lento cuando aún necesites la historia de servidor versus frontend. Usa la guía de LCP, INP, CLS cuando una única métrica está en rojo y necesitas palancas. Usa el pilar de rendimiento cuando la pregunta es roadmap e inversión, no un filtro de lanzamiento.
Esta lista de verificación es el medio aburrido: binaria, repetible, lo suficientemente corta para que la gente realmente la ejecute.
Concepto clave: Filtra lanzamientos con la lista de verificación. Diagnostica con las otras guías de rendimiento.