El pasado 10 de Noviembre de 2020 Google publicó un post llamado «Plazos para incluir la experiencia en la página en la Búsqueda de Google» donde actualizó la información que comentaba el 5 de mayo de 2020 desde su blog de Chromium y después el 28 de Mayo de 2020 donde presentaban las conocidas como Core Web Vitals, las métricas esenciales a tener en cuenta para tener una «buena salud» del sitio web.
Recordemos que, la calidad y relevancia del contenido siguen siendo los criterios que prevalecen para clasificar una página en las SERPs, y que la velocidad de página (como parte de la Experiencia de Página ranking factor) puede ser utilizada por Google como «desempate» para decidir el posicionamiento entre dos páginas a «igualdad de condiciones de contenido» …
Además de las 3 CWV definidas de base, Google deja abierta la posibilidad de incluir alguna otra métricas relevante como evaluar la fluidez en cuanto a las animaciones por ejemplo servidas en una página.
Estructura del contenido
MIDUDEV – EXPLICACIÓN EN TWITTER Y VIDEO EN TWITCH SOBRE WEB PERFORMANCE Y CWV
Os recomiendo leer este hilo en twitter de midudev, experto en desarrollo web, que analiza una a una, las diferentes métricas de performance que se pueden analizar a través de la herramienta de desarrolladores de Chrome. Te recomiendo además seguirle en su canal de Youtube.
Todas las métricas de Web Performance: TTFB, FCP, LCP, Speed Index, FID, Max Potential FID , TBT, TTI , CLS .
Consejo maestro: «Crearte una nueva cuenta en Chrome para hacer un análisis limpio y evitar que las extensiones que puedas tener instaladas afecten en las métricas».
Otras recomendaciones: empezar a grabar una sesión de performance desde una pestaña de about:blank para después acceder a la web que quieras.
08/03/2022 – «Responsiveness» nueva-futura-posible métrica CWV
El pasado 8 de marzo de 2022, aprovechando la release de los datos de febrero 2022 sobre CrUX, Google anunció que en esa release se empieza a tener en cuenta la métrica «Responsiveness».
La métrica en cuestión trata de analizar de forma más precisa la interacción del usuario (clicks, etc.) durante su navegación a través de eventos relacionados con la experiencia de página. De alguna forma vienen a medir la «latencia de interacción» del usuario.
Para ello, se plantean dos posibles formas de medirlo: la duración de la interacción más larga, o la suma de la duración de todos los eventos.
22/02/2022 – Page Experience ya aplica a resultados en DESKTOP
Tal y como afirmaron el pasado verano de 2021, la experiencia de página que empezó a aplicarse en dispositivos móviles, desde el 22 de febrero ya se empieza a aplicar en los resultados para escritorio tal y como han afirmado en su post de Twitter.
El pasado 04 noviembre Google confirmó en su blog que empezarían a aplicarlo sobre dispositivos de escritorio para febrero de 2022 con un final de despliegue para marzo y así ha sido.
Ya en enero 2022 confirmaron que dentro de Search Console se habilitaba desde el reporte «Experiencia» -> «Experiencia en la página» una nueva gráfica para ordenador donde se mostraba el porcentaje de urls que ofrecen una buena experiencia en la página para desktop.
A partir de febrero del 2022, empezaremos a tener en cuenta la experiencia en la página a la hora de posicionar páginas para ordenadores. El lanzamiento terminará a finales de marzo del 2022. Este cambio en el posicionamiento se basará en los mismos indicadores de experiencia en la página que implementamos para móviles este año
Centro de la Búsqueda de Google – Blog Post
Todas las métricas CWV que se estaban aplicando a mobile, pasan a aplicarse en desktop, sólo que una de las señales de experiencia de página «Mobile Friendly» en este caso no aplicaría.
05/11/2021 «Reduce el impacto de código de terceros» en Vídeos Youtube [TBT/FID]
Una de las soluciones que desde WebDev Google recomienda para optimizar la llamada de terceros, en este caso los iframes de vídeo de Youtube, en tus páginas, es utilizando un lazy load en la carga, sin embargo esto puede generar problemas con la interacción del usuario.
Es por ello que en la página de WebDev recomiendan el uso de la técnica conocida como «Facade» que consiste en sustituir esa carga dinámica del tercero en un elemento estático (muy similar a un embebido externo como pueda ser Youtube) el cual no será funcional hasta que el usuario no interactúe con él, al contrario que un embebido normal, que sí hace la petición externa independientemente el usuario clique o no sobre él. Así lo explican desde el pasado hangout.
Puedes ver el resto de recomendaciones sobre Facade y esta noticia al detalle en el siguiente enlace.
19/10/2021 – CÓMO MEJORAR CLS
En este último video de la serie CWV, nos cuentan en qué consiste la métrica CLS y cuáles son las formas de poder corregir esos cambios de layout en la página. Interesante a partir del minuto 11:13 donde explican las formas de hacerlo y que básicamente todas se basan en un mismo patrón : «configurar las medidas ancho y alto del espacio que ocuparán en la página».
05/10/2021 – CÓMO MEJORAR LCP
LCP es la métrica que mide la rapidez con la que se carga el contenido principal de una página y se muestra (o pinta). En este video, Google ofrece toda la información al detalle sobre esta métrica CWV y sobre todo acciones para ayudar a optimizarla.
21/09/2021 – CÓMO MEJORAR FID
FID es una de las tres métricas que conforman las Core Web Vitals y lo que mide en concreto, es el tiempo que tarda el navegador en responder a una interacción del usuario en la página. En este vídeo de Google ofrece podrás ver más información sobre cómo mejorarla.
10/08/2021 – CONSEJOS PARA VALIDAR SI TUS PÁGINAS CUMPLEN CON UNA BUENA EXPERIENCIA
Google compartió en su canal de Youtube (bajo la playlist de «Getting Started with Page Experience» un vídeo explicativo con algunos consejos básicos para validar el cumplimiento de tus páginas en el nuevo factor de posicionamiento llamado «Experiencia de Página». El vídeo se centra exclusivamente en la parte de los factores de «Experiencia de Página» que tienen que ver con: HTTPS, Mobile-Friendly e Insterstitials; la otra parte es Core Web Vitals.
Habla de cómo validar nuestras páginas para cumplir con esos factores de ranking que hablamos anteriormente. De forma que:
- HTTPS: su validación es booleana, es decir, está en https la página, o no. No hay más interpretaciones. Además, insiste en unificar las señales de la página hacia su versión securizada indicándosela desde la etiqueta rel canonical. Asegúrate de redireccionar con 301 tu versión no segura.
- Mobile Friendly: asegúrate que el contenido mostrado en tus páginas está disponible y adaptado a todos los dispositivos en los que el usuario aterriza para verlo (que el texto no sea demasiado pequeño, los enlaces cuesten clicarse, etc). Se recomienda el diseño responsive ya que el coste de mantenimiento está centrado en una única versión de url, y no en varias como m.dominio.com o dominio.com/m , etc. Algunas meta etiquetas en el código como meta viewport ayudan al navegador a entender las dimensiones del contenido de la página y reescalar. Puedes validar si tu página cumple con Mobile-Friendly test desde la propia tool de Google.
- Anuncios Intersticiales: no existe una herramienta específica (y estable) para validar que el aterrizaje que se produce del usuario desde Google a la página destino no esté interrumpida (al menos durante los primeros 5s) por un anuncio en formato pop-up por ejemplo que bloquee el consumo o lectura del contenido destino sin perjudicar la experiencia de usuario.
- Validando páginas AMP: si dispones de un formato de página adicional exclusiva para móviles (por ahora) como es AMP, se recomienda pasar esa url por el validador de «AMP Pape Experience» y comprobar cuáles son las recomendaciones a nivel técnico disponible para mejorar CWV y la experiencia de página en global, pese a que este framework se encuentra de base ya bastante optimizado…
04/08/2021 – «SAFE BROWSING» fuera del Page Experience
El pasado 4 de agosto Google comunicó en su blog que el informe de «Experiencia en la página» quedaría simplificado al no tener en cuenta el factor de Safe Browsing (que no HTTPS). La justificación viene a decir que, teniendo en cuenta que los propietarios de los sitios no siempre pueden controlar ataques de hackers que ponen en compromiso la navegación segura del usuario, tiene sentido no incluir esa parte dentro del informe de «Experiencia en la página». Aunque si Google detecta que la navegación no es segura en tu sitio, se te notificará en Search Console dentro del apartado «Seguridad y acciones manuales«.
Otro recordatorio importante es el de «Experiencia de anuncios», y es que de acuerdo con Google:
También hemos quitado el widget de experiencia de anuncio para no mostrar la misma información en dos secciones distintas de Search Console. Seguirás teniendo disponible la herramienta independiente de experiencia de anuncios para consultar el estado de tu sitio e identificar las experiencias de anuncio que infringen los estándares Better Ads. Para que quede claro: nunca se ha tenido en cuenta la experiencia de anuncio a la hora de evaluar la experiencia en las páginas de un sitio, por lo que este cambio no afectará a tu sitio en ese sentido.
15/06/2021 – PAGE EXPERIENCE RANKING FACTOR ROLLOUT
Llegó el día, tal y como lo había anunciado Google después del retraso de Mayo, ha sido justo a mediados de Junio (15) y finalizó en Septiembre (2) cuando finalmente la nueva señal de experiencia de página entra en el algoritmo para evaluar las página que, por una lado ofrecen resultados CWV óptimos, y por otro se les suma los factores que ya venía aplicando (https, mobile friendly, safe browsing e intersticials).
Actualizaciones con esta nueva señal:
- AMP deja de ser requisito obligatorio para aparecer en Top Stories y Google News.
- Desaparece el icono de AMP de los resultados móvil (¿nuevo icono en el futuro?).
- Entra en juego el nuevo cálculo de CLS (de 1 a 5s).
- Compatibilidad con los intercambios firmados (SXG) para páginas web y AMP para dar más seguridad a la información entre server y user.
Esta nueva señal justo se enlaza casi con el final del despliegue del core update de Junio (finalizó el 12) y que se completó en Julio con otra parte del core update que comenzó el 1 de julio (y acabó el 12 de julio). Recordemos que del último core update de Diciembre 20 a este han pasado 6 meses, algo poco habitual entre core y core.
10/06/2021 – FID «no data» en PSI field data
El pasado mes de junio de 2021, Rick Viscomi (desarrollador de Google en CWV) confirmó en twitter un comportamiento en la métrica FID que tendría su impacto en PSI.
En concreto, habla de que, a la hora de reportar PSI los datos de field data, es posible que algunas urls no muestren ningún dato en FID porque por ejemplo, al analizarse según el comportamiento del usuario a la hora de interactuar con la página, es posible que no haya ninguna acción requerida al navegador como clic en enlace, etc porque quizás el usuario simplemente a hecho scroll y ha salido. En ese caso, FID no reportaría ningún dato.
Por tanto, en esos casos en los que FID no resuelva ningún tiempo en ms, lo que se hará para calcular el CWV de la página, es tener en cuenta sólo las otras dos métricas de CWV, en concreto LCP y CLS. Si FID tuviera dato, tendría que ser con un buen valor para que entre los tres tengan una valoración de buena.
19/05/2021 – Novedades de Google I/O 2021 – Enlace SEOsly recopilatorio
CWV comenzará a tenerse en cuenta también en Escritorio después de la salida inicial en Junio (no sólo en Móvil como de inicio). Vídeo
17/05/2021 – EN QUÉ CONSISTE PAGE EXPERIENCE
En la serie de vídeos explicativos sobre la nueva señal Page Experience, Google, en su canal de Youtube «Google Search Central», sube diferentes vídeos al respecto para aclarar algunas de las muchas dudas que tienen los webmasters.
En concreto una que me parece muy interesante es si la aplicación de esta señal es de SÍ o NO, es decir, ¿sólo páginas con «buena experiencia» pueden conseguir el boost o hay algún tipo de grado en cómo la señal de experiencia de página afecta en ranking?. Google apunta que tener una muy buena puntuación de CWV frente a otra página que no, no es garantía de posicionar mejor, entre otras cosas porque se sigue teniendo en cuenta la relevancia del contenido como un factor muy fuerte en el ranking (ver esta parte del vídeo concreta).
Por otro lado, apuntar que, la experiencia de página además combina otras señales, que en este caso sí son de check o no, como si tu sitio tiene HTTPS, es mobile friendly, lleva anuncios intersticiales y la navegación es segura (vídeo de abajo).
Un tweet que me pareció muy bueno de JohnMu fue el que publicó el 21/05/2021 donde «gráficamente» viene a explicar que, en realidad, donde se nota el impacto de las CWV en las tres métricas clave, es a partir de que pasas el tramos de urls pobre a urls que necesitan mejorar y se aproximan a las urls buenas. A partir de ahí, que tu puntuación en performance medido en Lighthouse esté entre 90-100, no va a tener apenas efecto.
19/04/2021 – NOVEDADES «EXPERIENCIA DE PÁGINA» – CWV – Enlace
Se añaden nuevas opciones en Google Search Console
- «Experiencia» – donde se unifica todo lo relacionado con la señal de Experiencia de Página, es decir, los apartados de: Core Web Vitals (Métricas web principales»), Usabilidad móvil y «Experiencia en la página». Ésta última muestra estadísticas sobre el volumen de impresiones que las urls consideradas como «buenas» han tenido y el porcentaje que representan.
- Tráfico que empiezan a generar las páginas consideradas como «buenas» desde Rendimiento -> Apariencia en el buscador -> «Buena experiencia en la página».
¿Cuáles son los criterios por los que Google considera un URL como buena en el estado de experiencia en la página de Búsqueda?
13/04/2021 – CLS afina su cálculo en Chrome
Desde la página de desarrolladores WebDev se publica una actualización a la hora de medir y calcular la puntuación de la métrica CLS. En este artículo hace oficial su aplicación desde el 02/06/2021 y entra en vigor para las herramientas de Google: Lighthouse, PSI y CrUX. *También se ha hecho a partir del 01 de junio la actualización del CLS dentro de la herramienta Search Console – métricas web principales. En cualquier caso, empezó a tener efecto desde mediados de abril, aunque con la nueva señal se ha ido aplicando de forma estable en las diferentes tools.
En concreto se refieren a lo que llaman «Window» donde se producen cambios de layout, y al tiempo o gap que pasa entre una ventana y otra …teniendo en cuenta así a las páginas que ofrecían por ejemplo un tiempo de carga largo, scroll infinito o SPA. De tal forma que se reporta el mayor valor de CLS que se produce en esas ventanas.
Cada ventana es un periodo de tiempo que tiene una duración máxima de 5s. Cada cambio de layout dentro de la window se produce en un periodo de tiempo <1s. En la herramienta de WebPageTest.org ya es posible ver esa diferenciación visual en el filmstrip del renderizadao de la página y analizar las distintas ventanas de layout así como el impacto en el CLS que tiene cada cambio. Así lo explican en su entrada del blog.
En ningún caso se verá una peor puntuación del CLS en GSC, en todo caso mejores puntuaciones de «urls buenas». (Fuente: Data anomalies in Seach Console).
31/03/2021 – Core Web Vitals & Page Experience FAQs
Google ha actualizado la página de FAQs relacionada con las CWV y la Experiencia de Página (la anterior es de Dic2020):
- Si hay varias páginas de calidad y contenido similares, las que tengan una mejor experiencia en la página podrían tener un mejor rendimiento que las que no las tienen.
- Si bien todos los componentes de la experiencia de la página son importantes, daremos prioridad a las páginas con la mejor información en general, incluso si algunos aspectos de la experiencia de la página son insatisfactorios.
- AMP no es un factor de posicionamiento (aunque si bien es cierto que su framework aporta muchos beneficios en cuanto a rendimiento). Más información sobre la optimización de las páginas AMP para CWV aquí.
- Además, coincidiendo con la salida de esta nueva señal de posicionamiento «Experiencia de Página», Google anunció que las páginas No-AMP entrarán a competir en el módulo de Noticias Destacadas en Móvil con páginas AMP siempre y cuando cumplan con las señales de experiencia de página (ver enlace).
- La aplicación de las CWV salió de inicio con aplicación sobre mobile pero en Noviembre Google mencionó su aplicación también en desktop a partir de Febrero 2022. Por tanto, los resultados desktop no sufrirán cambios por ello.
Por tanto, se recomienda al menos para sites ya establecidos y no nuevos, que, se centre en las funcionalidades de la web a nivel usuario y el contenido, antes que en la velocidad. Ya que puedes tener una página muy rápida pero poco útil para el usuario y por tanto posicionar peor que la competencia, que pese a servir una página más lenta, sí que responde mejor a la intención de búsqueda del usuario. Enlace Vídeo.
17/02/2021 – Nuevos límites de puntuación para las métricas LCP, CLS y FID
El pasado 17 de febrero de 2021 Google anunció en su registro de incidencias en Search Console «Data anomalies» en la parte de Core Web Vitals que, la forma en la que agrupar las puntuaciones de las tres métricas, se actualiza, dando un poco de «manga ancha» a los sitios web.
La forma en la que actualiza los criterios de puntuación es que, en lugar de que los valores a cumplir sean «menores que» en las urls válidas y necesitan mejorar, pasen a ser «menores o iguales que». De esta manera las gráficas en Search Console asociadas a estas métricas en éstas páginas verán seguramente reflejados mejores datos.
10/02/2021 – ¿Qué tan útil es tu sitio web?
Quizás por error (sin una comunicación previa), se indexó esta página de Google donde avanzaban la opción de añadir un nuevo apartado en Search Console específicamente enfocado en la Experiencia de Página.
En este nuevo informe se unifican los apartados de Usabilidad Móvil, Métricas Web Principales (CWV), HTTPS (o avisos de contenido mixto), Problemas de seguridad y Experiencia publicitaria. La mayoría de ellas incluidas ya en Search Console (nueva versión) salvo HTTPS.
En concreto, Google lo desglosa y especifica en:
Usabilidad móvil: si la página se ve y funciona bien en un dispositivo móvil. Más del 50% de todas las búsquedas se realizan en un dispositivo móvil. Haga clic en la evaluación de usabilidad móvil de su sitio para abrir el informe de usabilidad móvil, que proporciona detalles sobre qué páginas tienen problemas de usabilidad móvil.
Core Web Vitals: la velocidad y la estabilidad visual de una página durante la carga de la página. Las páginas deben cargarse rápidamente y estar disponibles para las interacciones, y no deben saltar visualmente a medida que se cargan las partes más lentas de la página. Haga clic en su evaluación de Core Web Values para abrir el informe Core Web Values, que proporciona detalles sobre cualquier problema en su sitio.
Uso de HTTPS: si la mayoría de su sitio utiliza HTTPS, en lugar de HTTP. HTTPS proporciona una experiencia de usuario mucho más segura que HTTP, por lo que solo las páginas que usan HTTPS se consideran elegibles para la acreditación de buena experiencia de página.
Los problemas de seguridad en un sitio pueden causar una experiencia mala o incluso dañina. Si su sitio ha sido pirateado para mostrar spam o distribuir descargas dañinas, o tiene malas prácticas como facturación poco clara, esto puede descalificar sus páginas para que no se consideren una buena experiencia. Informe «Problemas de Seguridad».
Experiencia publicitaria: las páginas web con ventanas emergentes que roban el foco y otros comportamientos publicitarios que distraen son una mala experiencia para el usuario. Aunque aún no se muestra en el informe de experiencia de página, puede visitar el informe vinculado para ver la evaluación de su sitio. Informe de experiencia de anuncio (antigua versión de Search Console)..
El informe Page Experience muestra sus métricas de usabilidad móvil y Core Web Vitals, y puede mostrar el número aproximado de páginas que se considera que tienen una buena experiencia de página. Se considera que las páginas que superan todas las métricas tienen una buena experiencia de usuario y pueden obtener una insignia, y en el futuro serán elegibles para un aumento de clasificación en los resultados de búsqueda.
Página Support Google – Archivado en WaybachMachine
ACTUALIZACIÓN 19/04/2021 – Efectivamente, Google acabó publicando esta unificación de señales enfocadas en la Experiencia de Página tal y como se filtró en febrero 2021. En realidad la url que recoge esa información a fecha de hoy es la de Informe «Experiencia en la página» en GSC.
Señales de Experiencia de Usuario Core Web Vitals
Nuevas métricas de experiencia de usuario:
- Largest Contentful Paint (LCP) – experiencia de carga – muestra la rapidez con que un usuario puede ver realmente el contenido principal una página. Un valor LCP por debajo o igual a 2.5 segundos se considera ‘Bueno’. Algunas de las soluciones pasan por: probar nuevas tecnologías de renderizado de la página como por ejemplo el uso de SSR; optimización de imágenes de nueva generación (WebP) y compresión de las mimas; precarga de imágenes preload; aplicar LazyLoad en imágenes que no son LCP, etc. Caso de ejemplo visto por Takopedia&Vodafone
- First Input Delay (FID) – interactividad – mide la capacidad de respuesta y cuantifica la experiencia que sienten los usuarios cuando intentan interactuar por primera vez con la página; por debajo o igual a los 100ms se considera ‘Bueno’. mide la capacidad de respuesta de tu página cuando tienes un usuario real que interactúa con ella. Esta métrica ocurre cuando el usuario está intentando por ejemplo interactuar con el menú, pero el hilo principal (main thread) de la página está bloqueado por el JavaScript que se ejecuta en la página, por lo que el navegador tiene que esperar hasta que todo el JavaScript esté finalizado. Eso hace que el menú tarde mucho en abrirse. Como alternativa de medición en herramientas de laboratorio o entorno simulado, estaría Total Blocking Time (TBT) que mediría la cantidad total de tiempo que transcurre entre el primer pintado del contenido en la página (FCP) y el tiempo en el que el usuario puede interactuar con la página (TTI). Cuando una tarea tarda más de 50ms, TBT es malo y si tarda <50ms, estará ok. Total Blocking Time (TBT): que viene a sustituir a la métrica FID en Lighthouse como métrica de laboratorio y que se explica más abajo.
- Cumulative Layout Shift (CLS) – estabilidad – se trata de una métrica centrada en la experiencia de usuario, y que viene a medir cuánto cambia visualmente el contenido de una página. Una puntuación baja de CLS es una señal de que los usuarios no están experimentando cambios de contenido indebidos; por lo que un valor de CLS por debajo o igual a 0,10 se considera ‘Bueno’. Si realizas una auditoría con PSI verás que ésta métrica difiere según si el resultado procede de lab data o field data. Y es que: en lab data (Lighthouse) el análisis de la ventana CLS termina cuando la página completa su carga bajo esas condiciones simuladas, mientras que en field data (PSI) la ventana de observación de CLS se extiende a toda la carga completa de la página incluyendo la actividad post carga. Sin embargo con el nuevo ajuste de Junio, sto queda resuelto por ejemplo para páginas con scroll infinito, etc. – Enlace
Y es que éstas tres métricas no tiene el mismo peso sobre el total de las métricas de rendimiento en Lighthouse. Esto se puede ver claramente en la calculadora de peso de Core Web Vitals y que constantemente los ingenieros actualizan en el % de peso para ajustarse a las necesidades del usuario.
Así por ejemplo, se ha publicado recientemente que la versión 8 de Lighthouse aplica desde la versión de Chrome 93, llega con algunas actualizaciones, entre la que destaca el cambio de peso que se les otorga a las diferentes métricas de rendimiento, quedando de la siguiente forma: CLS aumentaría su peso x3, otras métricas como FCP, SI o TTI (bajan un 5%), TBT (FID) sube un 5% y LCP se mantiene en un 25%.
Métricas No Core Web Vitals (por ahora)
Como se muestra en la imagen superior a la hora de calcular los valores en Lighthouse, es importante tener en cuenta el papel que juegan otras métricas de rendimiento como:
- First Contentful Paint (FCP) o Start Render: mide la velocidad de carga percibida por el usuario, ya que marca el primer elemento/s que se carga y visualiza en el renderizado de la página y que el usuario puede ver. Para esta métrica, «contenido» se refiere a texto, imágenes (incluidas imágenes de fondo) «svg» logo, elementos o elementos que no son blancos «canvas». Se puede medir tanto en laboratorio como campo. Más información.
- Speed Index (SI): mide la rapidez con la que se muestra visualmente el contenido del viewport durante la carga de la página.
- Time to Interactive (TTI): mide el tiempo que le lleva a una página a ser interactuable por el usuario de una forma estable sin latencias, lags, etc. Se trata de una métrica de laboratorio.
Midiendo Core Web Vitals
El informe de UX de Chrome permite evaluar ese rendimiento tal y como lo experimentarían los usuarios de Chrome.
Diferencias entre información «Lab. vs Field Data»
Dos tipo de información, la simulada («Lab») y la real («Field»):
- Lab Data (simulada): está basado en datos de rendimiento recogidos en un entorno controlado, simulando un tipo de dispositivo concreto y unas conexiones de red específicas. Ésta información es la que utilizan herramientas como Lighthouse o WebPageTest.
- Field Data (real user metrics RUM): está basado en las estadísticas reales de cómo los usuarios navegan e interactúan con el sitio web. Ésta información es la que utilizan herramientas como el informe de UX de Chrome, Page Speed Insights y GSC en el apartado de «Core Web Vitals». Es por tanto un indicador más real.
¿Por qué Lighthouse no ofrece datos de la métrica FID?
Porque FID requiere medir un usuario real, y Lighthouse es una herramienta de simulación (lab data), por tanto si usas Lighthouse en tus validaciones CWV, la métrica que según la documentación de Google, mejor sustituye a la métrica FID es TBT (Total Blocking Time).
Total Blocking Time (TBT) : mide la cantidad de tiempo total entre First Contentful Paint (FCP) y Time to Interactive (TTI). Es una métrica complementaria de TTI. Lo recomendable es tener un tiempo de bloqueo total de menos de 300 milisegundos.
SEJ: Google Explains Why Field Data is More Reliable Than Lab Data
Google: How To Think About Speed Tools
Debuggeando CLS
Cuando se analiza con PSI una url existe una diferencia entre la información por ejemplo que se ofrece para CLS entre field y lab data. Esta diferencia puede ocurrir cuando la página tiene mucho contenido interactivo que no está siendo usado cuando se testea por ejemplo en Lighthouse sobre un entorno simulado.
La idea es detectar el elemento que más impacto tiene en layout sobre el resto de elementos. Más información.
Otras herramientas para medir el rendimiento de tus páginas
El futuro de las Core Web Vitals
- La métrica actual (no-cwv) llamada FCP se postula como candidata a ser añadida en un futuro como CWV principal (viendo el último Chrome Dev Summit de Feb 2021 y la charla de 2020 sobre el futuro de las CWV).
- CLS aumentará de peso en importancia (actualmente 5% – enlace a charla en Youtube).
- Medir el rendimiento de animaciones en la página. Google piensa añadir una medición específica, teniendo en cuenta el uso de animaciones.
- FID será más estricta, y bajará su nivel de puntuación en ms en la parte «buena» de la métrica, de 100ms a 75 o 50ms.
- Mejor medición del rendimiento en Single Page Application (SPAs) – vídeo.
Fuente: ContentKing
Optimizing Web Vitals using Lighthouse (Web.Dev)
Quick facts about Core Web Vitals (Ahrefs)
