Si has buscado «evaluación de las métricas web principales no superada» después de ver una puntuación de velocidad en verde, empieza por comprobar qué datos describe cada resultado. PageSpeed Insights (PSI) combina datos de visitas reales con una prueba controlada independiente. Anota la dirección, el dispositivo, el alcance de los datos y la métrica que falla antes de comprar una herramienta o pedir que rehagan el sitio.
Empezamos por ese registro porque «poner la puntuación en verde» deja demasiadas cuestiones abiertas. Quien desarrolla el sitio necesita saber qué experiencia requiere atención y qué pruebas permitirán considerar útil la corrección.
Evaluación de las métricas web principales no superada: ¿qué midió el informe?
La evaluación describe experiencias registradas de visitantes, mientras que la sección de Lighthouse ejecuta una prueba de diagnóstico. La documentación de Google sobre PageSpeed Insights explica que los datos de campo proceden del informe Chrome User Experience Report, o CrUX, y abarcan un periodo móvil de recopilación de 28 días. Por eso, un diagnóstico recién ejecutado y ese historial pueden mostrar resultados distintos.
Las condiciones de prueba son diferentes. Una ejecución controlada no puede cubrir todos los dispositivos, conexiones y acciones de las visitas reales. Úsala para investigar una posible causa y conserva junto a ella los datos de visitantes al decidir qué sigue sin resolverse.
El resultado puede abarcar más páginas. Si hay pocos datos de la página exacta, PSI puede recurrir al origen: a grandes rasgos, la dirección del sitio con su protocolo y nombre de host. Un resultado del origen combina visitas a distintas páginas. Lee el alcance que muestra el informe antes de tomarlo como prueba sobre una página concreta de producto o servicio.
El periodo incluye visitas anteriores. Un cambio de hoy no reescribe las observaciones de ayer. Guarda la fecha de puesta en producción para distinguir la comprobación inmediata de la corrección de los datos posteriores sobre visitantes.
Estas diferencias asignan una función a cada informe: los datos de visitantes señalan una experiencia que investigar; la prueba controlada ayuda a reproducirla y examinarla.
¿Qué métrica necesita atención?
Revisa LCP, INP y CLS por separado antes de elegir una corrección. La guía de Google sobre Web Vitals distingue entre carga, capacidad de respuesta y estabilidad visual. La tabla recoge los umbrales buenos de esa guía, evaluados en el percentil 75 para la población del dispositivo correspondiente. La guía de umbrales de Google explica ese percentil: al menos el 75 % de las páginas vistas medidas deben cumplir el umbral bueno de la métrica. No equivale a una media ni a la puntuación global de Lighthouse.
| Métrica | Qué describe | Umbral bueno | Qué preguntar a quien mantiene el sitio |
|---|---|---|---|
| LCP, Largest Contentful Paint | Cuándo aparece el elemento de contenido visible más grande | Como máximo 2,5 segundos | ¿Qué elemento se retrasa y en qué punto de su secuencia de carga? |
| INP, Interaction to Next Paint | Con qué rapidez responde la página a las interacciones | Como máximo 200 milisegundos | ¿Qué toque, clic o pulsación tarda en responder en las condiciones afectadas? |
| CLS, Cumulative Layout Shift | Movimientos inesperados del diseño | Como máximo 0,1 | ¿Qué elemento se mueve y en qué momento de la visita? |
Cuando todas estas métricas tienen datos suficientes, PSI exige que sus valores del percentil 75 sean buenos para superar la evaluación. Si no hay suficientes datos de INP, unos valores buenos de LCP y CLS pueden bastar para superarla. Si faltan datos suficientes de LCP o CLS, PSI no puede evaluar esa página ni ese origen.
Trata la falta de datos como incertidumbre. La metodología de CrUX de Google exige visitas que cumplan los requisitos y suficiente popularidad; no publica un número mínimo universal de visitantes. La ausencia de resultado no indica que nadie visite el sitio, que la experiencia sea buena ni que una corrección haya fallado.
¿Qué puedes comprobar antes de pagar por el trabajo?
Guarda un informe de referencia y sigue el mismo recorrido de cliente en un móvil antes de elegir una herramienta. Necesitas una descripción clara del problema: la página, los datos que sustentan el aviso y el comportamiento que puedes reproducir. Si no puedes reproducirlo, anota esa limitación en lugar de cubrirla con una suposición.
- Abre en PSI la página exacta que importa al negocio. Guarda su dirección y la fecha del informe. Incluye la página de destino o plantilla relevante para la consulta o compra que investigas.
- Anota si has elegido móvil o escritorio y el alcance de los datos. Copia si la sección de datos de campo representa la URL, el origen o datos insuficientes. Usa la misma selección en las comparaciones posteriores.
- Identifica la métrica que requiere atención. Usa los resultados individuales de Core Web Vitals y lee después la sección de diagnóstico en busca de pistas. Deja visibles las muestras que faltan.
- Realiza una tarea real en un móvil. Abre el menú, utiliza el filtro correspondiente o completa el formulario pertinente. Anota qué carga tarde, responde despacio o se mueve de forma inesperada.
- Relaciona una pista con una prueba. Pide a quien mantiene el sitio que reproduzca la acción afectada o el retraso de carga y explique qué puede demostrar esa prueba.
Para revisar también imágenes, widgets, caché y alojamiento, consulta nuestra guía sobre las causas habituales de una web lenta. Centra la tarea actual en la evaluación no superada y en las pruebas necesarias para revisar la corrección.
¿Qué debe incluir la corrección?
Elige el cambio más pequeño que respalde el diagnóstico y acuerda cómo lo comprobarás. Empieza con los informes y las funciones que ya tienes. El trabajo técnico resulta más fácil de revisar cuando quien mantiene el sitio identifica la página o plantilla afectada, explica el cuello de botella y conserva condiciones comparables antes y después.
- Relaciona la propuesta con la métrica. La guía de LCP de web.dev distingue los retrasos de respuesta, descubrimiento, carga y renderizado del elemento más grande. La guía de INP centra la investigación en las interacciones lentas. La de CLS incluye desplazamientos posteriores a la carga inicial. Pide las pruebas pertinentes en vez de una promesa general de mejorar la velocidad.
- Corrige la causa identificada y vuelve a probar el comportamiento. Una corrección concreta de un recurso o una plantilla puede formar parte del desarrollo y mantenimiento web. Registra qué cambió y cuándo, y anota cómo revertirlo cuando sea viable.
- Comprueba que la tarea del cliente sigue funcionando. Prueba la navegación, los formularios y los pasos de compra relevantes para la página. Mantén operativos los controles de consentimiento; investiga su comportamiento y diseño preservando un consentimiento conforme a la ley.
- Decide si hacen falta más datos. Si los informes disponibles no permiten identificar la interacción o página afectada, puede ayudar una medición adicional. Antes de añadir un servicio de pago, pregunta qué cuestión responde la monitorización propuesta.
Si la prioridad técnica no está clara, el trabajo de SEO técnico puede empezar con un diagnóstico y una lista de tareas revisable. Un rediseño o un paquete de optimización necesita su propia justificación.
Puedes copiar esta ficha y dejar en blanco los campos desconocidos:
Página y tarea de negocio:
Dispositivo y alcance de los datos de campo:
Métrica que requiere atención:
Comportamiento observado y condiciones de prueba:
Causa y cambio propuestos:
Fecha de puesta en producción:
Comprobación comparable después del cambio:
Observación de campo posterior e incertidumbre restante:¿Cómo compruebas que el trabajo ha servido?
Revisa primero el comportamiento modificado y compara después los datos de campo posteriores dentro del mismo alcance. Según su documentación, PSI actualiza los datos de campo a diario y conserva un periodo móvil de recopilación. Mantén la fecha de puesta en producción en el registro. Ese periodo no es una cuenta atrás garantizada para superar la evaluación.
Compara la métrica elegida y la tarea del cliente en condiciones de prueba similares. Si el síntoma persiste, retoma el diagnóstico. Si la prueba mejora, pero los datos de campo posteriores no respaldan el cambio, vuelve a investigar las páginas y las condiciones de los visitantes afectados. La falta de datos de campo debe seguir constando como limitación explícita.
Cómo podemos ayudarte
Empezamos con el informe, las páginas importantes y una tarea que podamos reproducir. Separamos la corrección propuesta, su comprobación y los datos posteriores de visitantes para que cada decisión tenga una base que puedas revisar. Un brief de rendimiento web puede empezar con la ficha anterior; mantén visibles sus campos desconocidos.
