Auditoría de rendimiento y Core Web Vitals

Fase P3 · Etapa A — Comprender
Tiempo estimado: 4–8 horas para una auditoría representativa; 2–5 días hábiles para una investigación a nivel de plantillas con trazados de ingeniería. La validación de campo de 28 días ocurre después de las correcciones y no extiende el tiempo inicial de la auditoría.
Responsable: el líder técnico de SEO define el alcance y la aceptación. Un ingeniero de rendimiento o ingeniero front-end sénior es responsable del diagnóstico; los propietarios de plataforma, CDN, analítica, diseño y producto contribuyen cuando sus sistemas generan retardo o inestabilidad.

Esta fase convierte la evidencia de campo de usuarios reales y las pruebas de laboratorio repetibles en un registro de remediación vinculado a URL, plantillas, métricas, responsables y pruebas de verificación, no en una puntuación genérica de velocidad.

Por qué esta fase, y por qué aquí

El rendimiento pertenece a la Etapa A porque una página que se agota por tiempo de espera es un problema de rastreo antes de ser un problema de experiencia de usuario. Un rastreador o agente de recuperación tiene un presupuesto finito de solicitudes. Si el origen se detiene, redirige repetidamente o devuelve una respuesta incompleta, el cliente puede abandonar la página antes de poder evaluar el contenido. Los encabezados más rápidos, un mejor texto y un esquema más sólido no pueden ayudar a un contenido que no se recupera de forma fiable.

La P3 consume los hosts canónicos, las plantillas indexables previstas, los recorridos prioritarios, la evidencia de códigos de estado y los hallazgos de infraestructura no resueltos de la auditoría técnica de referencia . Ese orden evita diagnósticos falsos. Por ejemplo, una «carga de página» de cinco segundos causada por un bucle de redirecciones no es una tarea de optimización de imágenes, y una prueba rápida de una página de error en caché no es un aprobado. La P2 establece que la URL correcta puede ser solicitada y seleccionada; la P3 establece que puede ser entregada y utilizada dentro de límites de tiempo y estabilidad aceptables.

Realizar esta fase tarde genera retrabajo. Un equipo de contenido puede publicar en una plantilla cuyo héroe es siempre el elemento más lento, o aprobar un espacio promocional que desplaza cada tarjeta de producto. El defecto se multiplica entonces en las nuevas páginas.

Entradas y salidas

Las entradas hacen que la muestra sea representativa. Las salidas forman el contrato con la siguiente fase: exactamente qué páginas están disponibles de forma fiable, qué condiciones siguen siendo débiles y qué limitaciones de rendimiento deben calificar las mediciones posteriores.

Los datos de campo y los datos de laboratorio son evidencia diferente

Los datos de campo describen lo que los usuarios elegibles de Chrome realmente experimentaron. El Chrome User Experience Report, normalmente abreviado como CrUX, agrega mediciones de visitas reales e informa el percentil 75: el valor en o por debajo del cual se encuentra el 75% de las experiencias registradas. Incluye la complejidad de dispositivos reales, redes, ubicaciones, cachés, herramientas de consentimiento, sesiones e interacciones. Úsalos para decidir si los usuarios superan los umbrales publicados y si un cambio implementado mejoró eventualmente a la población.

Los datos de laboratorio describen una carga de página o interacción controlada bajo condiciones declaradas. Lighthouse es una prueba de laboratorio que aplica simulación de dispositivo y red, captura un trazado y explica las causas probables. Úsalo para reproducir un problema, comparar dos versiones bajo la misma configuración, inspeccionar cadenas de solicitudes e identificar trabajo. Una puntuación de laboratorio es evidencia útil, pero no demuestra que los usuarios reales aprueben.

Las dos fuentes pueden discrepar sin que ninguna esté equivocada. Una ejecución de laboratorio rápida puede usar una ubicación cercana, CDN en caliente y ninguna interacción significativa, mientras que los visitantes de campo incluyen teléfonos más antiguos y redes distantes. Registra la discrepancia e investiga sus condiciones; nunca promedies los valores ni elijas el que parezca más saludable.

La lista de verificación

Completa estas comprobaciones en orden. Cada elemento indica la acción, el motivo, el método, la herramienta y la condición de aceptación para que pueda asignarse y volverse a probar.

1. Congela la matriz representativa de URL y condiciones

Qué: define las URL, plantillas, perfiles de dispositivo, geografías, estados de consentimiento y estados de caché a probar. Por qué: una auditoría solo de la página de inicio puede aprobar mientras la plantilla de producto, artículo o proceso de pago falla. Cómo: combina el inventario de la P2 con datos de tráfico y prioridad comercial; selecciona ejemplos típicos, pesados y críticos para la conversión. Herramienta: analítica, inventario de rastreo, registro de lanzamientos y una hoja de prueba compartida. Hecho cuando: cada plantilla prioritaria tiene una muestra de producción aprobada por el responsable y cada prueba registra las suposiciones de dispositivo, red, ubicación, inicio de sesión, consentimiento y caché.

2. Captura la línea base de campo de CrUX

Qué: registra las métricas de campo p75 disponibles a nivel de URL y, por separado, a nivel de origen. Por qué: el origen puede ocultar una plantilla débil, mientras que una URL individual de bajo tráfico puede no tener datos publicables. Cómo: usa la misma fecha de observación y ventana de 28 días, etiqueta explícitamente URL versus origen, y registra los valores en blanco como «datos insuficientes». Herramienta: AmICited Web Vitals y CrUX. Hecho cuando: cada URL muestreada tiene valores de LCP, INP, CLS, FCP y TTFB, o un estado desconocido documentado; el nivel de origen y la ventana son inequívocos.

3. Verifica la fiabilidad de la respuesta antes de puntuar píxeles

Qué: repite las solicitudes y registra el estado, las redirecciones, el Time to First Byte (TTFB), los tiempos de espera y las respuestas inconsistentes. TTFB es el intervalo desde el inicio de la solicitud hasta que llega el primer byte de respuesta. Por qué: una página no puede pintar antes de que su HTML comience a llegar, y un fallo intermitente es más grave que una ralentización cosmética. Cómo: prueba el comportamiento de caché en frío y caliente desde regiones relevantes, inspecciona los tiempos del servidor y correlaciona anomalías con los registros de CDN y origen. Herramienta: monitor de solicitudes, panel de red del navegador, observabilidad de CDN/origen y waterfall de Lighthouse. Hecho cuando: las URL prioritarias devuelven la respuesta 200 esperada sin saltos inesperados ni tiempos de espera, y cada respuesta lenta o fallida tiene un hallazgo registrado con un responsable.

4. Diagnostica el Largest Contentful Paint

Qué: identifica el elemento de Largest Contentful Paint (LCP) y desglosa su tiempo en retardo del servidor, descubrimiento del recurso, descarga del recurso y retardo de renderizado. LCP mide cuándo termina de renderizarse el bloque de texto o imagen visible más grande. Por qué: comprimir una imagen hace poco cuando el navegador la descubre tarde, y los cambios de front-end no pueden borrar una espera lenta en el origen. Cómo: inspecciona el trazado y el waterfall, compara ejecuciones en caché y sin caché, verifica la prioridad de precarga, el tamaño responsivo de imágenes, los recursos que bloquean el renderizado, el comportamiento de las fuentes y el renderizado del lado del cliente. Herramienta: Lighthouse, herramientas de rendimiento del navegador, waterfall de solicitudes e inspección de imágenes. Hecho cuando: el elemento LCP real y la subparte dominante están identificados para cada plantilla con fallos, con una medición inicial reproducible y una hipótesis de corrección específica.

5. Diagnostica el Interaction to Next Paint

Qué: prueba el camino del Interaction to Next Paint (INP) para acciones reales como abrir menús, filtrar, añadir al carrito, entrada de formularios y cierre de consentimiento. INP mide el retardo desde una interacción del usuario hasta que el navegador muestra la siguiente actualización visual, utilizando una interacción de alta latencia de la visita. Por qué: una página puede parecer completa pero seguir ignorando al usuario mientras JavaScript ocupa el hilo principal. Cómo: reproduce acciones importantes, inspecciona tareas largas y manejadores de eventos, prueba scripts de terceros, y separa el retardo de entrada, el tiempo de procesamiento y el retardo de presentación. Herramienta: CrUX, trazado de rendimiento del navegador, perfilado de interacciones y un dispositivo realista. Hecho cuando: cada interacción importante ha sido ejercitada, la interacción lenta y la tarea responsable están identificadas para las plantillas con fallos, y la corrección tiene una prueba de interacción repetible.

6. Diagnostica el Cumulative Layout Shift

Qué: localiza el movimiento inesperado que contribuye al Cumulative Layout Shift (CLS). CLS es una puntuación adimensional que representa el movimiento visual inesperado durante la vida de la página. Por qué: un banner tardío, una imagen sin dimensiones, una fuente intercambiada, un anuncio o un componente hidratado pueden mover el enlace que el usuario está a punto de hacer clic y pueden cambiar dónde encuentra la extracción automatizada el contenido. Cómo: usa regiones de cambio de diseño y un filmstrip, prueba activos retrasados y estados de consentimiento, e inspecciona elementos sin dimensiones reservadas. Herramienta: CrUX, trazado de Lighthouse, diagnóstico de renderizado del navegador y captura de regresión visual. Hecho cuando: cada cambio material tiene un elemento fuente, un desencadenante y una corrección de espacio reservado o renderizado; el movimiento esperado causado inmediatamente por una acción del usuario se documenta por separado.

7. Usa FCP para separar el retardo de pantalla en blanco

Qué: mide el First Contentful Paint (FCP), el tiempo hasta que el navegador renderiza el primer texto, imagen, lienzo o contenido SVG. Por qué: FCP distingue una señal temprana de progreso de una página que permanece en blanco, aunque no demuestra que el contenido principal esté listo. Cómo: compara FCP con TTFB y LCP, luego inspecciona CSS, fuentes, scripts que bloquean el renderizado, marcado renderizado en servidor y comportamiento de streaming. Herramienta: CrUX, Lighthouse y el trazado de red/rendimiento. Hecho cuando: cada FCP lento se asigna a retardo del servidor, bloqueo de renderizado, renderizado exclusivo del lado del cliente u otra causa evidenciada, en lugar de describirse meramente como «la página se siente lenta».

8. Clasifica los hallazgos por gravedad, alcance y dependencia

Qué: ordena el backlog por banda de fallo, tráfico y plantillas afectados, criticidad comercial y dependencia upstream. Por qué: corregir cinco puntuaciones amarillas puede consumir el sprint mientras que un fallo TTFB rojo retrasa cada página del origen. Cómo: coloca primero los fallos de fiabilidad, luego las métricas deficientes antes que las que necesitan mejora; dentro de la misma gravedad, corrige las causas compartidas de plataforma y TTFB antes que el trabajo downstream de LCP. Herramienta: registro de hallazgos, analítica, inventario de plantillas y estimación de ingeniería. Hecho cuando: cada hallazgo tiene una gravedad, un número de URL afectadas o alcance de plantilla, evidencia, responsable, esfuerzo, dependencia y prioridad explícita.

9. Valida la implementación en el laboratorio

Qué: compara la versión modificada con la línea base registrada bajo condiciones idénticas. Por qué: los datos de campo no pueden proporcionar retroalimentación inmediata del lanzamiento, y una ejecución «posterior» no repetible no puede establecer que el cambio de código causó la diferencia. Cómo: ejecuta múltiples muestras controladas, compara medianas en lugar de la mejor ejecución única, inspecciona el trazado en busca de regresiones y prueba interacciones y diseños críticos. Herramienta: Lighthouse, herramientas de rendimiento del navegador, entorno de pruebas o lanzamiento controlado a producción, y monitoreo de solicitudes. Hecho cuando: la causa prevista se elimina, la métrica objetivo supera el presupuesto de laboratorio acordado en ejecuciones repetidas, ninguna otra métrica crítica regresa, y la evidencia se adjunta al hallazgo.

10. Anota el lanzamiento y espera la confirmación de campo

Qué: registra el momento del despliegue, el alcance, la métrica esperada y las fechas de validación. Por qué: CrUX es una ventana móvil de 28 días, por lo que las visitas previas al lanzamiento permanecen en el percentil informado después de que la corrección se publique. Cómo: monitorea los errores inmediatamente, verifica el movimiento direccional de campo a medida que llegan nuevos datos, y realiza la comparación final solo cuando suficientes días posteriores al lanzamiento representen la ventana. Herramienta: registro de despliegue, AmICited Web Vitals, CrUX y monitoreo. Hecho cuando: las comprobaciones técnicas inmediatas pasan, la anotación del lanzamiento es visible, y existe un responsable designado y una fecha para la confirmación de campo; el hallazgo no se marca como «verificado» solo con evidencia de laboratorio.

Herramientas en AmICited

Abre https://app.amicited.com/audit/web-vitals para comparar tu dominio con competidores monitoreados utilizando datos de usuarios reales de CrUX. La auditoría coloca LCP, INP, CLS, FCP y TTFB en una sola tabla, marca tu dominio y hace visible la falta de datos de campo en lugar de convertirlos en un cero engañoso. Usa la comparación para responder dos preguntas: si el dominio supera los umbrales publicados y si un competidor que atiende a la misma audiencia ha demostrado un resultado de campo materialmente mejor.

La función Performance Impact conecta el rendimiento a nivel de página con la posición y probabilidad de citación. Trata la relación como evidencia de priorización, no como prueba de que la velocidad por sí sola causó un cambio en la citación. Si una página lenta citada y una página rápida no citada difieren en autoridad, relevancia o contenido, el rendimiento es solo una variable. La señal útil es que una página afectada tiene suficiente valor como para corregirla y monitorearla.

Para la operación del producto, sigue Cómo verificar tus Core Web Vitals en AmICited . Este manual define el alcance de la auditoría, las decisiones y la transferencia; el tutorial cubre los clics y las lecturas, por lo que duplicarlo aquí crearía dos instrucciones que podrían divergir.

Reglas de decisión: cómo se ve lo malo

Evalúa los Core Web Vitals a partir de datos de campo en el percentil 75. «Bueno» significa que el valor p75 está en o por debajo del límite de bueno. Un valor en el límite pertenece a la banda mejor; por ejemplo, un LCP de exactamente 2.5 segundos es bueno. Los umbrales de apoyo de FCP y TTFB guían el diagnóstico y la aceptación, pero no forman parte de la evaluación de aprobación de los tres Core Web Vitals.

Usa estas reglas de prioridad:

1. Las solicitudes fallidas, los tiempos de espera y las respuestas inválidas están por encima de las puntuaciones. La fiabilidad es la puerta de entrega.
2. Corrige las bandas deficientes antes que las bandas que necesitan mejora. Rojo es una experiencia deficiente demostrada, no una oportunidad de pulido.
3. Corrige TTFB antes que LCP cuando TTFB está fallando. LCP no puede ocurrir antes de que comience la respuesta, por lo que el retardo del backend consume el presupuesto de LCP antes de que el navegador pueda renderizar nada.
4. Prefiere las causas compartidas sobre los síntomas aislados. Una reparación de política de caché en cuatro plantillas supera a cuatro ajustes de imagen separados con menor alcance.
5. Usa el tráfico y el valor del recorrido dentro de la misma gravedad. Un INP deficiente en el proceso de pago o un LCP de artículo de alto tráfico supera a un archivo de bajo tráfico en la misma banda.
6. No llames bueno a un valor de CrUX en blanco. Es desconocido. Usa evidencia de laboratorio repetible y una plantilla comparable hasta que exista volumen de campo.
7. No prometas movimiento de campo inmediato. Valida el despliegue ahora, luego permite que la ventana móvil reemplace las experiencias anteriores antes de aceptar o rechazar el resultado de campo.

Entregable: el registro de remediación de rendimiento

Entrega a ingeniería un registro más su carpeta de evidencia. Una hoja de cálculo, un gestor de incidencias o una tabla de proyecto estructurada son aceptables si conservan estos campos y permiten filtrar por plantilla, gravedad, responsable y estado:

ID y hallazgo:
URL y plantillas afectadas:
Recorrido prioritario y contexto de tráfico:
Métrica y banda de campo:
Nivel de CrUX, valor p75 y ventana de 28 días:
Configuración de laboratorio y línea base repetida:
Causa observada y referencia de evidencia:
Condición esperada y objetivo:
Cambio recomendado:
Gravedad y justificación de prioridad:
Responsable, dependencia y esfuerzo:
Fecha de lanzamiento y anotación:
Resultado de aceptación inmediata en laboratorio:
Fecha y resultado de confirmación de campo:
Estado: Abierto | Planificado | Aceptado en laboratorio | Verificado en campo | Riesgo aceptado

Adjunta la matriz de URL, la exportación de CrUX, los trazados de laboratorio, los waterfalls, los filmstrips, las grabaciones de interacción, la evidencia de cambios de diseño y las anotaciones de lanzamiento. Desduplica por causa: si la misma consulta de origen sin caché crea un TTFB deficiente en tres plantillas, crea un hallazgo padre con tres alcances afectados en lugar de tres diagnósticos en competencia.

«Riesgo aceptado» necesita un aprobador designado, motivo, alcance afectado, fecha de vencimiento o revisión y condición de monitoreo. No es un sustituto de un responsable. La transferencia está completa cuando un ingeniero puede reproducir el fallo y el responsable de la siguiente fase puede identificar qué resultados siguen limitados por el rendimiento.

Qué sale mal

Tratar a Lighthouse como el veredicto. Una puntuación de 100 en una ejecución de laboratorio no anula unos datos de campo p75 deficientes. Conserva Lighthouse como evidencia diagnóstica y CrUX como evidencia poblacional.

Probar solo la página de inicio. Muestrea cada plantilla de alto valor más un ejemplo pesado, o los defectos de las plantillas escaparán de la auditoría.

Optimizar la imagen LCP antes de verificar TTFB. El activo puede ser pequeño mientras el origen gasta dos segundos generando HTML. Desglosa LCP en sus componentes y corrige primero el tiempo upstream.

Usar la ejecución más rápida. El calor de caché, la actividad en segundo plano y la variación de red pueden crear un valor atípico halagador. Mantén la configuración fija y compara las medianas de ejecuciones repetidas.

Declarar victoria el día después del lanzamiento. El laboratorio puede demostrar que el código y la entrega cambiaron inmediatamente; la ventana de campo de 28 días no puede. Anota el lanzamiento y programa la aceptación de campo.

Marcar los datos faltantes de CrUX como cero. Sin datos significa que no se alcanzó el umbral de elegibilidad o tráfico. No dice nada sobre la calidad del rendimiento.

Perseguir la puntuación compuesta en lugar de la experiencia fallida. Una puntuación resumida puede mejorar mientras una interacción de pago sigue estancada o un héroe sigue desplazándose. Acepta métricas y recorridos nombrados, no un movimiento cosmético de puntuación.

Eliminar funcionalidad útil para ganar una prueba. Eliminar el consentimiento, la personalización, la analítica o la accesibilidad de la variante de laboratorio produce un resultado que los usuarios nunca reciben. Optimiza el requisito de producción o toma una decisión explícita de producto.

Ignorar regresiones fuera de la métrica objetivo. Diferir scripts puede mejorar LCP pero crear un INP deficiente en la primera interacción; reservar las dimensiones incorrectas puede reemplazar un retardo de carga con CLS. Vuelve a probar las cinco métricas y el recorrido crítico.

Siguiente fase: Accesibilidad para IA y preparación para agentes

La fase de accesibilidad para IA y preparación para agentes recibe la matriz de URL representativa, la evidencia de fiabilidad de respuesta, la distribución de TTFB, los hallazgos de rendimiento no resueltos y una declaración de qué contenido está presente en la respuesta inicial. Su responsable utiliza esa evidencia para distinguir un fallo de política de acceso de un fallo de entrega y para reproducir las condiciones reales bajo las cuales un agente obtiene la página.

La siguiente fase puede continuar cuando las URL críticas responden de forma fiable y ningún defecto de rendimiento no resuelto hace que la evidencia de recuperación sea ininterpretable. Puede continuar con una limitación por escrito cuando una métrica que necesita mejora afecta a los usuarios pero no impide el acceso estable. Debe pausarse para las plantillas afectadas cuando las solicitudes se agotan por tiempo de espera, devuelven errores intermitentes o la respuesta principal supera regularmente el umbral crítico acordado.

La transferencia está completa cuando el siguiente responsable sabe qué URL representan cada plantilla, las condiciones de prueba, los fallos de entrega restantes y si la evidencia de P3 ya explica una recuperación lenta por parte de un agente.

FAQ

Preguntas frecuentes