Lista de verificación para la corrección de Core Web Vitals

Lista de verificación: Corrección de Core Web Vitals. Tiempo asignado: un día hábil para confirmar el alcance y el diagnóstico; de uno a diez días hábiles para una corrección y lanzamiento típicos, dependiendo de si la causa reside en un activo, plantilla compartida, script de terceros, origen o CDN. La verificación de campo sigue la ventana de datos móvil de 28 días y se programa por separado. Responsable: un ingeniero de rendimiento o ingeniero front-end senior es el responsable. El líder técnico de SEO es el dueño de los criterios de aceptación de campo; los responsables de plataforma, diseño, analítica y producto aprueban los cambios en sus sistemas.

Esta lista de verificación convierte un hallazgo de rendimiento diagnosticado en una corrección lanzada y verificada en campo. Core Web Vitals son las medidas de Google basadas en usuarios reales sobre carga, capacidad de respuesta y estabilidad visual: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Time to First Byte (TTFB) y First Contentful Paint (FCP) son métricas de diagnóstico complementarias. Se incluyen porque una respuesta lenta o una pantalla en blanco consume el tiempo disponible para lograr un buen LCP.

Por qué esta lista de verificación, y por qué aquí

Esta lista de verificación consume el registro de correcciones de la auditoría de rendimiento y Core Web Vitals . Esa fase anterior identifica la métrica que falla, la URL y plantilla afectadas, la línea base del usuario real, la condición de laboratorio repetible, la causa sospechada, la prioridad y el responsable. La corrección comienza solo después de que esos campos existen. De lo contrario, se le pide a un desarrollador que “haga el sitio más rápido” y cambiará naturalmente lo que una herramienta destaque primero, independientemente de si causa la falla en campo.

El diagnóstico debe reducirse a tres niveles antes de actuar: qué métrica, qué plantilla y qué elemento o tarea. Una falla de TTFB en todo el origen necesita una corrección de plataforma; el LCP que falla solo en páginas de artículos puede provenir de su componente hero; el INP después de abrir un filtro de producto puede provenir de un manejador de eventos; el CLS en páginas promocionales puede provenir de un banner sin espacio reservado. Tratar estos como un solo problema produce cambios amplios y responsabilidades poco claras.

El orden importa dentro de la corrección. TTFB está upstream: hasta que llegue el primer byte de respuesta, el navegador no puede descubrir recursos HTML normales ni pintar el contenido de la página. Si TTFB es deficiente, corrija la generación de respuesta, el almacenamiento en caché, las redirecciones y la entrega en el borde antes de comprimir la imagen de LCP. Una vez que el tiempo de respuesta esté dentro del presupuesto, avance a través del descubrimiento de recursos, descarga de recursos, renderizado, interacciones y estabilidad de diseño.

Saltarse esta lista de verificación deja la auditoría como un informe. Ejecutarla antes del diagnóstico invita a perseguir síntomas: comprimir una imagen cuando el descubrimiento tardío domina, o diferir scripts cuando el origen es lento.

Entradas y salidas

Las salidas permiten que un futuro responsable reproduzca la falla, identifique qué se implementó y distinga la aceptación de laboratorio de la confirmación en campo.

La lista de verificación

Complete los elementos 1–4 antes de cambiar producción. Los elementos 5–8 implementan la corrección ordenada por dependencias. Los elementos 9–11 separan la aceptación inmediata del lanzamiento de la verificación en campo.

1. Fije la métrica, plantilla y elemento que fallan

Qué: reduzca el hallazgo a una métrica, un conjunto de plantillas afectadas y un elemento, solicitud, tarea o intervalo de servidor nombrado. Por qué: una puntuación general del sitio no identifica trabajo implementable, y dos URLs pueden fallar por diferentes razones. Cómo: vincule la falla p75 con traces y compare plantillas afectadas y no afectadas; nombre el elemento LCP y su retraso, la interacción INP y su tarea, el elemento CLS y su desencadenante, o la ruta de solicitud TTFB y el estado de caché. Herramienta: evidencia de CrUX, trace del navegador, waterfall, tiempos de servidor, inventario de plantillas y rastreador de incidencias. Hecho cuando: la evidencia respalde que “la métrica X falla en la plantilla Y porque Z crea retraso o movimiento bajo la condición C”.

2. Confirme el alcance con páginas representativas

Qué: pruebe el hallazgo en una URL típica y una en el peor caso para cada plantilla implicada, más un control no afectado. Por qué: una corrección de una sola página puede ocultar un defecto compartido, mientras que un cambio global puede ser innecesario cuando una variante de contenido causa el problema. Cómo: mantenga constantes el dispositivo, la red, la ubicación, el consentimiento, el inicio de sesión y las condiciones de caché; compare el uso de componentes, el peso de los activos, los tiempos de respuesta, la actividad de terceros y la longitud del contenido. Herramienta: analítica, inventario de plantillas, herramientas de rendimiento del navegador, monitor de solicitudes y una matriz de prueba. Hecho cuando: cada plantilla dentro del alcance esté marcada como afectada o control, cada una tenga evidencia reproducible, y el alcance del lanzamiento nombre el componente, la ruta, la familia de activos o la capa de plataforma que debe cambiar.

3. Establezca el presupuesto y proteja el comportamiento requerido

Qué: defina el objetivo numérico, los guardarraíles de regresión y las funciones que deben sobrevivir. Por qué: “más rápido” no tiene un límite de aceptación, y eliminar un gestor de consentimiento, una etiqueta de analítica, un comportamiento de enfoque accesible o una funcionalidad del producto puede crear un resultado positivo engañoso. Cómo: establezca el objetivo desde la tabla de decisiones a continuación, agregue un margen interno más estricto donde las pruebas repetidas varíen, y enumere los recorridos críticos y las métricas no objetivo para volver a probar. Herramienta: registro de hallazgos, requisitos del producto, plan de analítica, verificaciones de accesibilidad y presupuesto de rendimiento. Hecho cuando: el ticket indique la métrica objetivo y su valor, el método de aceptación de laboratorio, el método de aceptación de campo, los comportamientos protegidos, las compensaciones permitidas, la condición de reversión y los aprobadores designados.

4. Verifique TTFB antes del trabajo front-end

Qué: mida TTFB en condiciones de caché fría y caliente desde ubicaciones relevantes para la audiencia. Por qué: TTFB está incluido en cada tiempo de pintura posterior; el trabajo front-end no puede recuperar el tiempo ya gastado esperando el HTML. Cómo: divida la solicitud en DNS, conexión, redirecciones, espera de CDN, cómputo de origen, tiempo de base de datos o API upstream, y comportamiento de streaming donde la instrumentación lo permita. Compare las respuestas con y sin caché y confirme que la personalización o las cookies no deshabilitan el caché inesperadamente. Herramienta: waterfall de solicitudes, tiempos de servidor, registros de CDN y origen, perfilado de aplicaciones y monitoreo sintético de solicitudes. Hecho cuando: TTFB esté dentro del presupuesto acordado o exista un hallazgo de plataforma bloqueante separado, con responsable y programación. No comience el pulido de LCP mientras un TTFB deficiente permanezca sin explicación.

5. Elimine primero el retraso del servidor y la entrega

Qué: corrija la respuesta lenta del origen, las fallas de caché, las redirecciones o la entrega distante. Por qué: estas causas retrasan cada elemento y a menudo afectan múltiples plantillas. Cómo: elimine redirecciones evitables; almacene en caché HTML y datos seguros; reduzca el trabajo lento de base de datos o API; mueva el trabajo fuera de la ruta crítica; ajuste el enrutamiento de CDN y las claves de caché. Nunca almacene en caché respuestas privadas sin un diseño aprobado. Herramienta: perfilador de aplicaciones, traces de consultas, configuración de CDN, cabeceras de respuesta, monitoreo y pruebas de carga. Hecho cuando: las pruebas repetidas en frío y caliente cumplan con el presupuesto, las variantes de caché sigan siendo correctas, los errores no hayan aumentado y las URLs prioritarias devuelvan la respuesta prevista sin un salto adicional.

6. Corrija el retraso de descubrimiento, transferencia y renderizado de LCP

Qué: acorte Largest Contentful Paint , cuando se renderiza el bloque de texto o imagen visible más grande. Por qué: los héroes sobredimensionados son comunes, pero el descubrimiento tardío, la prioridad baja, el CSS bloqueante, JavaScript o las fuentes pueden dominar. Cómo: sirva una imagen responsiva del tamaño correcto; no cargue de forma diferida el activo LCP que está sobre el pliegue; expóngalo en el HTML inicial; priorice o precargue solo con evidencia; elimine el bloqueo de renderizado; y use fuentes subconjuntadas y almacenables en caché con un respaldo adecuado. Herramienta: desglose de LCP, waterfall, inspección de imágenes, informe de cobertura, trace y comparación visual. Hecho cuando: el elemento LCP previsto sea consistente, su retraso dominante disminuya, las páginas representativas cumplan con el presupuesto, y el ancho de banda, la visibilidad del texto y el renderizado no empeoren.

7. Corrija INP en la interacción responsable

Qué: reduzca la interacción responsable de un Interaction to Next Paint deficiente, la métrica de capacidad de respuesta. Por qué: eliminar JavaScript arbitrario puede no tocar el evento lento. Cómo: separe el retraso de entrada, procesamiento y presentación; divida tareas largas; elimine trabajo síncrono; difiera terceros no esenciales; evite diseños repetidos; reduzca rerenderizados; y ceda el control para la pintura. Pruebe en hardware realista con terceros de producción. Herramienta: trace de interacción, perfil del hilo principal, entradas de tareas largas, perfilador de framework y dispositivo realista. Hecho cuando: las interacciones críticas funcionen, la tarea responsable cumpla con el presupuesto de pruebas repetidas, el proxy de campo esté documentado, y el comportamiento de analítica, consentimiento, teclado y lector de pantalla no empeore.

8. Corrija CLS reservando el diseño final

Qué: evite el movimiento que contribuye a Cumulative Layout Shift , la puntuación de inestabilidad visual. Por qué: las imágenes, fuentes, anuncios, banners, embebidos y componentes asíncronos pueden desplazar la interfaz. Cómo: establezca dimensiones intrínsecas o aspect-ratio; reserve espacios para módulos dinámicos; use respaldos de fuente compatibles; y anime con transformaciones. Herramienta: regiones de cambio de diseño, trace, filmstrip, pruebas de regresión visual y navegador limitado. Hecho cuando: cada grupo de cambio material tenga una fuente nombrada, las páginas cumplan con el presupuesto de CLS durante la carga e interacciones críticas, y el espacio reservado no oculte ningún control.

9. Vuelva a probar todo el conjunto de métricas y los recorridos protegidos

Qué: compare el candidato de lanzamiento con la línea base congelada bajo condiciones idénticas, luego pruebe en producción. Por qué: mejorar una métrica puede dañar otra: diferir JavaScript puede mejorar LCP pero empeorar la primera interacción, mientras que un cambio agresivo de fuente puede mejorar el tiempo de pintura pero crear cambios de diseño. Cómo: realice varias muestras controladas, compare una estadística declarada en lugar de la mejor ejecución, inspeccione traces, ejercite los recorridos protegidos, verifique la corrección de la respuesta, y pruebe las plantillas afectadas y de control. Herramienta: Lighthouse o un ejecutor de laboratorio equivalente, herramientas de rendimiento del navegador, monitor de solicitudes, pruebas visuales y funcionales, y lista de verificación de lanzamiento. Hecho cuando: la métrica objetivo cumpla con su presupuesto de laboratorio según el método de ejecución repetida declarado, TTFB/FCP/LCP/INP/CLS no muestren regresión crítica, el comportamiento protegido pase, producción sirva el cambio previsto y la reversión no se haya activado.

10. Anote el lanzamiento y programe la revisión de campo

Qué: registre la marca de tiempo de implementación, el alcance cambiado, la métrica objetivo, la dirección esperada y las fechas de revisión de campo. Por qué: CrUX usa una ventana móvil de 28 días, por lo que las experiencias previas al lanzamiento permanecen en el p75 reportado después de la implementación. Sin una anotación, el equipo puede considerar una buena corrección como ineficaz demasiado pronto o atribuir un movimiento posterior al lanzamiento equivocado. Cómo: adjunte la versión de producción al hallazgo, verifique errores inmediatamente, registre lecturas de campo tempranas sin tratarlas como definitivas, y programe a un responsable para revisar una ventana suficientemente actualizada. Herramienta: registro de implementación, rastreador de incidencias, CrUX, AmICited Web Vitals y monitoreo. Hecho cuando: el ticket esté marcado como Aceptado en laboratorio, la anotación de lanzamiento y la evidencia inmediata estén adjuntas, y existan un responsable designado y una fecha de calendario para la verificación de campo.

11. Verifique contra los datos de campo y cierre o reabra

Qué: compare datos de campo p75 comparables después de que la ventana móvil se haya actualizado suficientemente. Por qué: los dispositivos, redes, geografía, comportamiento de caché, estados de consentimiento e interacciones de usuarios reales no pueden ser representados por una sola ejecución de laboratorio. Cómo: use el mismo nivel de CrUX —URL u origen—, la misma métrica y un alcance de audiencia comparable; considere la implementación parcial y otros lanzamientos; inspeccione representantes de plantilla en lugar de depender solo de un agregado de origen. Si el resultado no alcanza, compare el trace actual con la declaración de causa original y reabra el diagnóstico en lugar de acumular ajustes no relacionados. Herramienta: AmICited Web Vitals, historial de CrUX, anotaciones de lanzamiento, segmentos de analítica y el paquete de evidencia. Hecho cuando: el objetivo cumpla con el umbral p75 acordado y el alcance con limitaciones registradas, momento en el cual el estado pasa a Verificado en campo; o el ticket se reabra explícitamente con nueva evidencia, responsable y siguiente hipótesis.

Herramientas en AmICited

Abra AmICited Web Vitals para ver LCP, INP, CLS, FCP y TTFB de CrUX para su dominio y competidores rastreados. Úselo en el diagnóstico para capturar la línea base de campo y después de la implementación para verificar el resultado de campo continuo. Un valor en blanco significa datos de campo elegibles insuficientes, no cero ni una calificación aprobatoria. La vista de producto respalda el veredicto; los traces, los tiempos de servidor y los perfiles del navegador aún identifican la causa.

Use Performance Impact para conectar la evidencia de rendimiento a nivel de página con la posición de citación e identificar páginas lentas valiosas. Esa asociación ayuda a priorizar la corrección pero no demuestra que el rendimiento por sí solo causó un resultado de citación. Preserve el contexto de relevancia, contenido, autoridad y lanzamiento al interpretar movimientos.

Para el flujo de trabajo del producto, siga Cómo verificar sus Core Web Vitals en AmICited . El tutorial explica dónde aparecen las métricas y cómo funcionan las comparaciones con competidores; esta lista de verificación rige el diagnóstico, la implementación y la aceptación.

Reglas de decisión: cómo se ve un mal resultado

Use el percentil 75, abreviado p75, para decisiones de campo: el 75% de las experiencias registradas elegibles están en o por debajo de ese valor. Un valor límite pertenece a la banda mejor. LCP, INP y CLS determinan el estado de Core Web Vitals; TTFB y FCP son medidas de apoyo utilizadas para secuenciar y diagnosticar el trabajo.

Aplique estas reglas en orden:

1. Un tiempo de espera, error de servidor, respuesta incorrecta o recorrido crítico roto bloquea el lanzamiento independientemente de la puntuación de la métrica.
2. Un TTFB deficiente está upstream de LCP y se corrige primero. No afirme una solución solo de imagen mientras el servidor ya ha consumido la mayor parte del presupuesto de pintura.
3. Las métricas de campo deficientes tienen prioridad sobre las métricas que necesitan mejorar. Dentro de una misma banda, priorice las causas de plantillas compartidas, el tráfico y los recorridos críticos para el negocio.
4. Un valor de campo a nivel de URL en blanco es desconocido. Use evidencia de laboratorio y un proxy documentado, pero no etiquete desconocido como bueno.
5. Una sola ejecución de laboratorio aprobatoria es insuficiente. Declare el perfil de dispositivo/red y el método de ejecución repetida antes de probar.
6. Una corrección está Aceptada en laboratorio cuando el comportamiento implementado y las pruebas controladas pasan. Está Verificada en campo solo después de que los datos de campo continuos comparables cumplan con el umbral acordado.
7. Si los datos de origen pasan pero una plantilla de alto tráfico falla, el resultado de la plantilla prevalece para ese alcance. La agregación no debe borrar un problema de usuario concentrado.

Entregable: el paquete de corrección y verificación

Entregue un ticket o una entrada de registro por causa raíz, con alcances secundarios cuando una causa afecte varias plantillas. Use una hoja de cálculo, rastreador de incidencias o documento de ingeniería, pero conserve estos campos:

ID del hallazgo y métrica principal:
Fuente de campo: URL | Origen
p75 de campo, banda y ventana de 28 días:
Plantillas afectadas y URLs representativas:
Plantilla de control y URL:
Elemento, interacción, solicitud o intervalo de servidor:
Declaración de causa y enlaces de evidencia:
Perfil de laboratorio y línea base de ejecución repetida:
Objetivo, guardarraíles y recorridos protegidos:
Corrección elegida y alternativas rechazadas:
Responsable de ingeniería, aprobadores y dependencias:
ID de versión/lanzamiento y marca de tiempo de implementación:
Resultados inmediatos de producción y laboratorio:
Responsable de revisión de campo CrUX y fecha:
Resultado de campo comparable y limitaciones:
Umbral de monitoreo y regla de reapertura:
Estado: Abierto | Implementando | Aceptado en laboratorio | Verificado en campo | Reabierto | Riesgo aceptado

Adjunte traces, waterfalls, intervalos de servidor, grabaciones de desplazamiento, perfiles de interacción, resultados de pruebas y anotación de lanzamiento. Riesgo aceptado necesita alcance, motivo, aprobador, vencimiento y disparador de monitoreo; no es una aprobación.

El paquete se acepta cuando otro ingeniero puede reproducir el problema original, identificar por qué este cambio lo aborda, confirmar qué llegó a producción y repetir la comparación de campo sin preguntar al investigador original que reconstruya el trabajo.

Qué sale mal

Optimizar antes de aislar la causa. La compresión genérica y la eliminación de scripts reemplazan al diagnóstico. Exija primero evidencia de métrica-plantilla-elemento.

Comprimir el hero mientras el origen es lento. Una imagen más pequeña no puede renderizarse antes de que llegue el HTML. Mida y corrija TTFB primero cuando esté fuera del presupuesto.

Corregir el desplazamiento equivocado. El CLS puede provenir de un anuncio, banner de consentimiento, fuente, embed o componente hidratado. Nombre la fuente del desplazamiento.

Diferir todos los scripts. El diferimiento indiscriminado puede romper el orden del consentimiento, la analítica, la navegación, los formularios o la primera interacción. Cambie la ruta de ejecución responsable y haga pruebas de regresión del comportamiento requerido.

Verificar una sola URL después de un lanzamiento de plantilla compartida. El ejemplo seleccionado puede pasar mientras una variante de contenido más pesada o otra configuración de componente aún falla. Pruebe páginas típicas, pesadas y de control.

Leer datos a nivel de origen como una aprobación de plantilla. Las páginas saludables de alto volumen pueden ocultar una categoría, artículo o plantilla de producto débil. Mantenga el diagnóstico y la aceptación en el alcance confiable más estrecho.

Cerrar el día de la implementación. Las pruebas inmediatas establecen la aceptación de laboratorio. No reemplazan la ventana de datos de campo continuos.

Esperar 28 días para descubrir un lanzamiento roto. La confirmación de campo toma tiempo, pero los códigos de estado, errores, recorridos, estabilidad visual y métricas controladas se verifican de inmediato. Los datos continuos no son una excusa para saltarse el control de calidad del lanzamiento.

Siguiente fase: monitoreo e iteración continua

Entregue el registro de verificación de campo, la anotación de lanzamiento, las plantillas afectadas, las limitaciones y los umbrales a actualización e iteración continua . Necesita una línea base estable para que los cambios posteriores de contenido, medios, plantillas, campañas y terceros puedan compararse en lugar de redescubrirse como movimiento inexplicado.

El siguiente responsable registra quién monitorea cada umbral, dónde vive la evidencia, con qué frecuencia se revisa y qué reabre la corrección. Una métrica recientemente deficiente, una tendencia repetida de necesita mejorar en toda la ventana completamente actualizada, un cambio en el elemento LCP, una nueva interacción lenta o un lanzamiento de plantilla que altere la ruta diagnosticada deberían reabrir la lista de verificación en el elemento 1. No repita automáticamente la corrección anterior: la misma métrica puede fallar por un elemento diferente después de un rediseño.

La transferencia está completa cuando el estado de campo es explícito, cada limitación aceptada tiene un responsable y fecha de revisión, y el monitoreo puede conectar una regresión con una plantilla y un lanzamiento. Si la verificación de campo sigue pendiente, el siguiente responsable recibe la fecha de revisión programada y el ticket permanece como Aceptado en laboratorio, no cerrado.

Preguntas frecuentes

Preguntas frecuentes sobre la corrección de Core Web Vitals