Si buscas «core web vitals» en Google Trends, descubrirás que el término no existía antes de la primavera de 2021. El interés se disparó de repente, y la gente sigue buscando más información útil sobre Core Web Vitals hasta el día de hoy. La razón es que, en mayo, Google anunció que el Core Web Vitals pronto tendría un efecto significativo en la clasificación de su sitio web en las búsquedas en línea.
Cuando Google habló por primera vez de los próximos cambios en sus algoritmos principales, afirmó que los efectos no se notarían hasta el próximo año. El gigante de los motores de búsqueda prometió avisar a todo el mundo con seis meses de antelación, y cumplió su promesa al entregar ese aviso en noviembre de 2020.
Hoy, te ayudaremos a descubrir qué son los Core Web Vitals y cómo podemos utilizarlos en nuestro beneficio.
¿Qué es Core Web Vitals?
La iniciativa Core Web Vitals (CWV) de Google proporciona directrices simplificadas que promueven una experiencia de usuario de calidad en la Web. Las Core Web Vitals son un conjunto de métricas estandarizadas de Google con el propósito de ayudar a los desarrolladores a entender mejor cómo los usuarios experimentan una página web. Las Core Web Vitals pueden ser creadas para los desarrolladores, pero estas herramientas también pueden ser utilizadas por todos los propietarios de sitios web, principalmente porque desglosan la experiencia real del usuario en una página web.
Ya en noviembre de 2020, Google Search Central tuiteó que la clasificación de la experiencia de la página para la Búsqueda de Google se lanzará en mayo de 2021.
Además, el 19 de abril de 2021, Google anunció que el factor de clasificación de la experiencia de la página se desplegaría gradualmente, a partir de mediados de junio de 2021.
Core Web Vitals identifica la experiencia del usuario (UX) a través de la generación de una métrica para tres áreas principales de UX, incluyendo:
- Rendimiento de la carga de la página.
- Facilidad de interacción
- Estabilidad visual de una página desde la perspectiva del usuario.
Todas estas métricas proporcionan su perspectiva específica sobre diferentes elementos que tienen un impacto en cómo los usuarios se comprometen e interactúan con un sitio web. Sí, los desarrolladores deben pensar en la experiencia del usuario desde una perspectiva holística. Sin embargo, las métricas independientes mencionadas anteriormente ayudan a desglosar las diferentes variables en piezas más pequeñas, lo que permite a los propietarios de sitios web identificar y solucionar problemas técnicos en su sitio.
Hay que tener en cuenta que esas métricas no cuentan toda la historia sobre la experiencia del usuario en un sitio web. Cada métrica puede unirse y ayudar a los desarrolladores a solucionar los problemas de forma eficiente y metódica.
Echemos un vistazo a las principales métricas incluidas en Core Web Vitals que le ayudarán a mejorar su(s) sitio(s) web de inmediato.
Largest Contentful Paint (LCP)
La pintura de mayor contenido (Largest Contentful Paint en inglés) es una métrica de Core Web Vitals que los propietarios de sitios web pueden utilizar para evaluar la UX, y comprobar si un usuario encontraría útil una página web basándose en el tiempo de renderización de los bloques más grandes visibles para la audiencia.
Como propietario de un sitio web, necesita que las páginas de su sitio se carguen lo más rápido posible para crear una experiencia de usuario agradable. El tiempo de carga es un factor crítico para la experiencia positiva de sus visitantes. Además, una página que se carga rápidamente tiene más probabilidades de ocupar un lugar destacado en Google, algo que todo propietario de un sitio web pretende. Adicionalmente, se ha demostrado que los tiempos de carga cortos tienen un impacto en las tasas de compromiso y conversión, especialmente cuando se comparan con las páginas de carga lenta.
¿Por qué se mide el LCP?
Largest Contentful Paint ha sido elegida como métrica crítica para la puntuación de Core Web Vitals principalmente porque mide con precisión la rapidez de uso de una página web.
Además, el LCP es fácil de medir y optimizar.
¿Qué mide el LCP?
El Largest Contentful Paint mide el tiempo que tardan los diferentes bloques de contenido en cargarse dentro del viewport del usuario (pantalla actual). La métrica LCP solo indica al propietario del sitio web la rapidez con la que se renderizan las secciones de contenido en la pantalla visible, y no se tiene en cuenta nada por debajo del pliegue.
- Imágenes
- Imágenes del cartel de vídeo
- Imágenes de fondo
- Texto a nivel de bloque.
Como propietario de un sitio web, su objetivo debe ser que el LCP esté dentro de los 2,5 segundos siguientes al inicio de la carga de una página web.
Cómo maneja LCP las imágenes servidas desde otro dominio
Las imágenes servidas desde otro dominio, como por ejemplo desde una CDN, no suelen contarse en el cálculo de la pintura de mayor contenido. Los editores que deseen que esos recursos formen parte del cálculo deben establecer lo que se denomina cabecera Timing-Allow-Origin.
Añadir esta cabecera a tu sitio web puede ser complicado porque si utilizas un comodín (*) en la configuración, podría abrir tu sitio a eventos de hacking. Así que, para hacerlo correctamente, tendrías que añadir un dominio específico para el rastreador de Google para ponerlo en la lista blanca y que pueda ver la información de sincronización de tu CDN.
Por lo tanto, los recursos (como las imágenes) cargados desde otro dominio (como desde una CDN) no se contarán como parte del cálculo de LCP.
Cómo obtener la puntuación LCP
Hay dos tipos de herramientas de puntuación. El primer tipo se llama herramientas de campo y el segundo, herramientas de laboratorio.
Las herramientas de campo son mediciones reales de un lugar.
Las herramientas de laboratorio dan una puntuación virtual basada en un rastreo simulado mediante algoritmos que se aproximan a las condiciones de Internet que podría encontrar un usuario típico en un teléfono móvil.
Herramientas de campo para la puntuación LCP
Google enumera tres herramientas de campo:
El último, el Informe de la experiencia del usuario de Chrome, requiere una cuenta de Google y un proyecto de Google Cloud. Los dos primeros son más sencillos.
Herramientas de laboratorio para la puntuación LCP
Las medidas de laboratorio son puntuaciones simuladas.
Google recomienda las siguientes herramientas:
Google proporciona las dos primeras herramientas. Un tercero proporciona la tercera.
Más adelante hablaremos de las herramientas de puntuación con más detalle.
Cómo optimizar la pintura de mayor contenido
Hay tres áreas principales para optimizar (más una más para los Frameworks de JavaScript):
- Servidores lentos
- Bloqueo de la renderización de JavaScript y CSS
- Tiempos de carga de recursos lentos
Un servidor lento puede ser un problema con los niveles DDOS de hacking y tráfico de scraper en un host compartido o VPS. Puedes encontrar alivio instalando un plugin de WordPress como WordFence para averiguar si estás experimentando un ataque masivo y luego bloquearlo.
Otros problemas podrían ser la mala configuración de un servidor dedicado o VPS. Un problema típico puede ser la cantidad de memoria asignada a PHP. Si tiene problemas con estos, no dude en ponerse en contacto con sus expertos de soporte técnico a través de un ticket de soporte y espere una respuesta rápida.
Otro problema podría ser un software anticuado, como una versión antigua de PHP o un software CMS que esté desfasado.
El peor escenario es un servidor compartido con múltiples usuarios que ralentizan su caja. En ese caso, la solución es trasladarse a un host mejor, como FastComet. Normalmente, la aplicación de correcciones como la adición de caché, la optimización de las imágenes, la corrección de CSS y JavaScript que bloquean la renderización, y la precarga de ciertos activos puede ayudar.
Google tiene algunos consejos para tratar el CSS que no es esencial para la representación de lo que ve el usuario:
«Elimine por completo cualquier CSS que no se utilice o muévalo a otra hoja de estilos si se utiliza en una página distinta de su sitio.
Para cualquier CSS que no sea necesario para la representación inicial, emplee loadCSS para cargar los archivos de forma asíncrona, que aprovecha rel=»preload» y onload.
<link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">«
Cumulative Layout Shift (CLS)
Los propietarios de sitios web deben facilitar al máximo la interacción de los usuarios con los enlaces y botones de un sitio web, lo que a su vez impulsa las ventas y las conversiones. Desplazamiento acumulado de la composición (Cumulative Layout Shift en inglés) es una métrica que identifica los enlaces o botones que se desplazan después de que se haya cargado una página web.
Refleja el nivel de dificultad que experimentarán los usuarios cuando intenten interactuar con los elementos de su sitio una vez que se haya renderizado la página.
La UX y el diseño son dos componentes vitales de una buena UX, y el usuario medio se sentirá frustrado si una página web cambia de elementos mientras está leyendo. CLS ayuda a los desarrolladores a determinar si las imágenes o los enlaces se desplazan en la página para que los propietarios de los sitios web puedan mejorar la usabilidad, impulsar las tasas de clics y maximizar los ingresos.
Por qué ocurre el CLS
Según Google, hay cinco razones por las que se produce un cambio de diseño acumulativo:
- Imágenes sin dimensiones
- Anuncios, incrustaciones e iframes sin dimensiones
- Contenido inyectado dinámicamente
- Fuentes web que causan FOIT/FOUT
- Acciones que esperan una respuesta de la red antes de actualizar el DOM.
Las imágenes y los vídeos deben tener las dimensiones de altura y anchura declaradas en el HTML. Cuando se trata de imágenes responsivas, asegúrate de que los diferentes tamaños de imagen para los diferentes viewports utilizan la misma relación de aspecto.
Google recomienda utilizar AspectRatioCalculator para calcular las relaciones de aspecto.
Los anuncios pueden causar CLS
Una forma de lidiar con los anuncios que causan CLS es estilizar el elemento donde se va a mostrar el anuncio. Por ejemplo, si se estiliza el div para que tenga una altura y una anchura específicas, el anuncio se limitará a ellas.
Hay dos soluciones si hay falta de inventario y un anuncio no aparece. Si un elemento que contiene un anuncio no muestra un anuncio, puede configurarlo para que se utilice un anuncio de banner alternativo o una imagen de marcador de posición para rellenar el espacio.
Por otra parte, para algunos diseños en los que un anuncio llena toda una fila en la parte superior de una columna en el canalón derecho o izquierdo de una página web, si la página no se muestra, no habrá ningún desplazamiento. No habrá diferencia ni en móvil ni en escritorio. Sin embargo, eso depende del diseño del tema. Tendrás que probarlo si el inventario de anuncios es un problema.
Contenido inyectado dinámicamente
El contenido inyectado dinámicamente es un contenido que se inyecta en la página web. Por ejemplo, en WordPress, puede enlazar a un vídeo de YouTube o a un tuit, y WordPress mostrará el vídeo o el tuit como un objeto incrustado.
Fuentes basadas en la web
Las fuentes web descargadas pueden causar lo que se conoce como Flash de texto invisible (FOIT) y Flash de texto sin estilo (FOUT).
Una forma de evitarlo es utilizar rel=»preload» en el enlace para descargar esa fuente web.
Lighthouse puede ayudarle a diagnosticar la causa del síndrome de fatiga crónica.
El CLS puede colarse durante el desarrollo
El cambio de diseño acumulativo puede colarse durante la fase de desarrollo. Muchos de los activos necesarios para renderizar la página pueden cargarse en la caché de un navegador. Si esto ocurre, la próxima vez que un desarrollador o editor visite la página en desarrollo, no notará un cambio de diseño porque los elementos de la página ya se han descargado.
Por eso es útil tener una medición en el laboratorio o en el campo.
Cómo se calcula el desplazamiento acumulado de la composición
El cálculo implica dos métricas/eventos. La primera se llama Fracción de Impacto, y la segunda es Fracción Distante.
Fracción de impacto
La fracción de impacto es una medida de cuánto espacio ocupa un elemento inestable en la ventana gráfica. Un viewport es lo que se ve en la pantalla del móvil.
Cuando un elemento se descarga y luego se desplaza, el espacio total que ocupó el elemento, desde la ubicación que ocupaba en la ventana gráfica cuando se renderiza por primera vez hasta la ubicación final cuando se renderiza la página.
Fracción distante
La fracción de distancia es la cantidad de espacio que el elemento de la página ha desplazado desde la posición original hasta la posición final.
La puntuación es una forma de medir un importante factor de la experiencia del usuario.
¿Qué mide el CLS?
CLS examina las métricas básicas para determinar la estabilidad visual de una página desde la perspectiva del usuario teniendo en cuenta varios factores:
- Cambio de composición
- Fracción de impacto
- Fracción de distancia
Los propietarios de los sitios deben mantener un CLS de 0,1 o menos.
Cómo medir el CLS
Hay dos formas de medir el CLS. Google llama a la primera forma en el Laboratorio. La segunda forma se llama en el Campo.
En el laboratorio significa simular que un usuario real descarga una página web. Google utiliza un Moto G4 simulado para generar la puntuación CLS dentro del entorno del laboratorio.
Las herramientas de laboratorio son las mejores para entender cómo puede funcionar una composición antes de ponerla a disposición de los usuarios. Ofrecen a los editores la oportunidad de probar un diseño para detectar problemas.
Como hemos mencionado, las herramientas de laboratorio consisten en Chrome Dev Tools y Lighthouse.
Cómo mantener las cosas quietas en las páginas de su sitio web
No hay nada más molesto que el texto se mueva por la página web mientras intentas leerlo. Para ayudarte a lidiar con las imágenes y el texto que rebotan, he aquí algunas cosas que tu desarrollador web debería tener en cuenta:
- Añadir la altura y la anchura de las imágenes al código del sitio web. Así, el navegador sabrá exactamente el espacio disponible para cargar la imagen y evitará que cambie continuamente mientras se carga.
- Utilizar contenedores, que son básicamente cajas designadas para que los anuncios se carguen en tu página web. He visto esto muchas veces, particularmente en sitios web de noticias, donde un artículo es empujado hacia abajo después de que he empezado a leerlo para hacer espacio para los anuncios de pantalla.
First Input Delay (FID)
Los consumidores en la web quieren páginas que sean rápidas y fáciles de usar. First Input Delay mide la latencia de entrada (el tiempo que tarda un elemento de la página en responder a la entrada de un usuario) para identificar las páginas que podrían causar la frustración de su audiencia.
Los sitios web modernos utilizan una variedad de tecnologías avanzadas y widgets de contenido dinámico para servir el contenido a su audiencia. Este tipo de contenido puede mejorar la entrega de contenidos. Sin embargo, estas mejoras pueden provocar tiempos de retardo que obligan a los usuarios a esperar a que su navegador actúe sobre su entrada.
Lo que los desarrolladores tienen que hacer es reducir el tiempo que cualquier usuario pasa esperando a que el navegador responda a su entrada. De este modo, se mejora el compromiso y la usabilidad del sitio.
La causa del retraso de la primera entrada
El primer retardo en la entrada suele estar causado por imágenes y scripts que se descargan de forma desordenada. Esta codificación desordenada hace que la descarga de la página web se detenga excesivamente, se inicie y se vuelva a detener, provocando un comportamiento poco receptivo para los visitantes del sitio que intentan interactuar con la página web.
Todo esto se asemeja a un embotellamiento provocado por una batalla campal en la que no hay señales de tráfico. Arreglar el FID es poner orden en el caótico «tráfico»,
Google describe así la causa de la latencia de entrada:
«En general, el retraso en la entrada (también conocido como latencia de entrada) se produce porque el hilo principal del navegador está ocupado haciendo otra cosa, por lo que no puede (todavía) responder al usuario.
Una razón común para que esto ocurra es que el navegador está ocupado analizando y ejecutando un gran archivo JavaScript cargado por su aplicación.
Mientras lo hace, no puede ejecutar ningún escuchador de eventos porque el JavaScript que está cargando podría indicarle que haga otra cosa».
Ilya Grigorik, Web Performance Engineer (Google Blog)
¿Qué mide el FID?
El FID mide la capacidad de respuesta de una página al cargar las entradas de elementos de un usuario. Esto significa que FID solo registra eventos como clics y pulsaciones de teclas.
Los propietarios de sitios web deben procurar ofrecer una buena experiencia de usuario con un FID inferior a 100 milisegundos.
Hay que tener en cuenta que el FID es difícil de medir porque estos datos sólo pueden medirse sobre el terreno. Esto significa que su puntuación dependerá de variables que están fuera de su control, como la capacidad de los dispositivos de los usuarios y las velocidades de Internet que experimenta su audiencia.
Cómo solucionar la latencia de entrada
Dado que la causa principal del Retraso de la Primera Entrada es la descarga desorganizada de scripts e imágenes, la forma de solucionar el problema es poner orden en la forma en que esos scripts e imágenes se presentan al navegador para su descarga.
Resolver el problema del FID consiste generalmente en utilizar atributos HTML para controlar cómo se descargan los scripts, optimizar las imágenes (el HTML y las imágenes) y omitir cuidadosamente los scripts innecesarios.
El objetivo es optimizar lo que se descarga para eliminar la típica pausa e inicio de descarga de páginas web desordenadas.
Por qué los navegadores no responden
Los navegadores son programas que realizan tareas con el objetivo final de mostrar una página web concreta. Las tareas consisten en descargar el código, las imágenes, las fuentes, la información de estilo y los scripts, y luego ejecutar los scripts y construir la página web de acuerdo con las instrucciones HTML. Este complejo proceso se denomina renderización. La palabra renderizar significa «hacer», y eso es lo que hace un navegador al ensamblar el código y las imágenes para renderizar una página web.
Las tareas individuales de renderizado se denominan hilos, abreviatura de «hilo de ejecución». Esto significa una secuencia de acción individual. En un navegador, hay un hilo llamado hilo principal y es el responsable de crear la página web que ve el visitante del sitio. El hilo principal puede visualizarse como una autopista en la que los coches simbolizan las imágenes y los scripts que se descargan y ejecutan una vez que una persona visita un sitio web.
Si algún código es grande y lento, hará que las otras tareas se detengan y esperen a que el código grande y lento salga de la autopista (termine de descargarse y ejecutarse).
Los desarrolladores deben procurar codificar la página web de manera que se optimice qué código se descarga primero y luego se ejecuta el código de manera ordenada. De este modo, la página web se descarga de la manera más rápida posible.
Primer retardo de entrada y código de terceros
Cuando se trata de Core Web Vitals y especialmente con First Input Delay, encontrará que hay algo de código sobre el que no puede hacer mucho. Sin embargo, es probable que este sea el caso de sus competidores, también.
Por ejemplo, si su negocio depende de Google AdSense (un gran script que bloquea la renderización), el problema va a ser el mismo para su competidor. Soluciones como el lazy loading con Google Ad Manager pueden ayudar.
En algunos casos concretos, puede bastar con hacerlo lo mejor posible porque es posible que sus competidores tampoco lo hagan mejor. En esos casos, es mejor que acepte las victorias donde pueda encontrarlas. No piense en las pérdidas en las que simplemente no puede hacer un cambio.
Impacto de JavaScript en el retraso de la primera entrada
JavaScript es una reminiscencia de un pequeño motor que hace que las cosas sucedan. Cuando se introduce un nombre en un formulario, JavaScript puede estar ahí para asegurarse de que se introducen tanto el nombre como el apellido. Cuando se pulsa un botón, JavaScript puede estar ahí para decirle al navegador que genere un mensaje de agradecimiento en una ventana emergente.
El problema con JavaScript es que no solo tiene que descargarse, sino también ejecutarse, dos cosas que contribuyen a la latencia de entrada.
Si un archivo JavaScript grande se encuentra cerca de la parte superior de la página, ese archivo va a bloquear el resto de la página por debajo de él de la representación hasta que ese script grande se termine de descargar y ejecutar. Esto se llama bloquear la página web.
La solución obvia es reubicar este tipo de scripts de la parte superior de la página y colocarlos en la parte inferior, para que no interfieran con todos los demás elementos de la página que están esperando a ser renderizados. Sin embargo, esto puede ser un problema si, por ejemplo, se coloca al final de una página web muy larga.
Razón: una vez que la página grande se ha cargado y el usuario está listo para interactuar con ella, el navegador seguirá señalando que se está descargando porque el gran archivo JavaScript se está retrasando al final. La página puede descargarse más rápido, pero luego se detiene mientras espera a que se ejecute el JavaScript.
Por suerte, hay una solución para eso.
Atributos de aplazamiento y asíncrono
Los atributos Defer y Async HTML tienen el papel de señales de tráfico que controlan el inicio y la detención de la descarga y ejecución de JavaScript.
En este caso, los atributos Defer y Async indican al navegador que no bloquee el análisis sintáctico del HTML mientras se descarga. Estos atributos le dicen al navegador que mantenga el hilo principal en marcha mientras se descarga el JavaScript.
Atributo asíncrono
Los archivos JavaScript con el atributo Async se descargarán y se ejecutarán tan pronto como se descarguen. El punto en el que el archivo JavaScript bloquea el hilo principal es cuando comienza a ejecutarse.
Normalmente, el archivo bloquearía el hilo principal cuando empieza a descargarse. Pero no con el atributo async (o defer). Esto se llama una descarga asíncrona, donde se descarga independientemente del hilo principal y en paralelo con él. El atributo async es útil para archivos JavaScript de terceros, como los de publicidad y los de intercambio social, archivos en los que el orden de ejecución no importa.
Atributo de diferimiento
Los archivos JavaScript con el atributo «defer» también se descargarán de forma asíncrona. Sin embargo, el archivo JavaScript diferido no se ejecutará hasta que se descargue y renderice toda la página. Los scripts diferidos también se ejecutan en el orden en que se encuentran en una página web. Los scripts con el atributo de aplazamiento son útiles para los archivos JavaScript que dependen de la carga de los elementos de la página y cuando el orden de ejecución es importante.
En general, utilice el atributo defer para las secuencias de comandos que no son esenciales para la representación de la página en sí.
Latencia de entrada – Diferente para todos los usuarios
Es crucial ser consciente de que las puntuaciones de la primera entrada son variables e inconsistentes. Las puntuaciones varían de un visitante a otro. Esta variación en las puntuaciones es inevitable porque la puntuación depende de las interacciones que son particulares del individuo que visita un sitio.
Algunos visitantes podrían distraerse y no interactuar hasta un momento en que todos los activos estén cargados y listos para ser interactuados.
Así es como lo describe Google:
«No todos los usuarios van a interactuar con su sitio cada vez que lo visiten. Y no todas las interacciones son relevantes para la FID…
Además, las primeras interacciones de algunos usuarios se producirán en malos momentos (cuando el hilo principal está ocupado durante un largo periodo de tiempo), y las primeras interacciones de algunos usuarios se producirán en buenos momentos (cuando el hilo principal está completamente inactivo).
Esto significa que algunos usuarios no tendrán valores FID, otros tendrán valores FID bajos y otros probablemente tendrán valores FID altos».
Web.dev
Por qué la mayoría de los sitios fracasan en el FID
Desgraciadamente, muchos sistemas de gestión de contenidos (CMS), temas y plugins no se crearon para cumplir con esta métrica relativamente nueva. Por eso, muchos editores se sienten consternados al descubrir que sus sitios web no superan la prueba del First Input Delay.
Sin embargo, esto está cambiando a medida que la comunidad de desarrollo de software web responde a las demandas de diferentes estándares de codificación de la comunidad editorial. No es que los desarrolladores de software que fabrican sistemas de gestión de contenidos tengan la culpa de producir productos que no dan la talla en estas métricas. Por ejemplo, WordPress abordó una deficiencia en el editor de sitios web Gutenberg que estaba causando que obtuviera menos puntuación de la que podría.
En caso de que no estés familiarizado, Gutenberg es una forma visual de construir sitios usando la interfaz o metáfora de los bloques. Hay un bloque de widgets, un bloque de formulario de contacto y un bloque de pie de página, etc. Así que el proceso de creación de una página web es más visual y se hace a través de la metáfora de los bloques de construcción, construyendo literalmente una página con diferentes bloques.
Hay varios tipos de bloques que se ven y se comportan de diferentes maneras. Cada bloque individual tiene su correspondiente código de estilo (CSS), que en gran parte es específico y único para ese bloque individual. La forma estándar de codificar estos estilos es crear una hoja de estilo que contenga los estilos exclusivos de cada bloque. Tiene sentido hacerlo de esta manera porque tienes una ubicación central donde existe todo el código específico de los bloques.
El resultado es que en una página que podría consistir en, por ejemplo, veinte bloques, WordPress cargaría los estilos para esos bloques más todos los demás bloques que no se están utilizando. Antes de Core Web Vitals, esto se consideraba la forma estándar de empaquetar el CSS. Desde la introducción de Core Web Vitals, esa práctica ha sido considerada como un exceso de código.
Esto no pretende ser un ataque contra los desarrolladores de WordPress. De hecho, han hecho un trabajo fantástico.
No es más que un reflejo de la rapidez con la que los estándares cambian, que puede suponer un cuello de botella en la fase de desarrollo del software antes de integrarse en el ecosistema de codificación.
Si recuerdas, pasamos por lo mismo con la transición al diseño web mobile-first.
Mejora del rendimiento de Gutenberg 10.1
WordPress Gutenberg 10.1 introdujo una forma mejorada de cargar los estilos, ya que solo se cargan los estilos que se necesitan y no se cargan los estilos de bloque que no se van a utilizar. Esto puede contar como una gran victoria para WordPress, los editores que confían en WordPress y, por supuesto, los usuarios que visitan sitios web creados con WordPress.
En el futuro, podemos esperar que cada vez más desarrolladores de software responsables del CMS, los temas y los plugins realicen la transición a las prácticas de codificación respetuosas con el Primer Retraso de Entrada.
Sin embargo, hasta que eso ocurra, la carga de la responsabilidad recae en el propietario del sitio para tomar medidas para mejorar el Retraso de la Primera Entrada. El primer paso es entender cómo funciona, algo que esperamos que esté más claro que el agua.
Otras métricas de rendimiento
Como ya hemos comentado, Core Web Vitals ofrece una gran cantidad de información que los desarrolladores pueden utilizar para mejorar los sitios web para la experiencia del usuario. Junto con las principales métricas que hemos cubierto, los propietarios de sitios web también pueden entender cómo su código impacta en la forma en que los usuarios consumen el contenido en su sitio.
Puede que las siguientes métricas no se consideren parte de las métricas de la experiencia del usuario, pero cuantifican los tiempos de retraso u otros factores técnicos que pueden tener un impacto negativo en la forma en que una audiencia en línea se involucra con una página web. Así pues, echemos un rápido vistazo a otras métricas que puede utilizar para entender la experiencia que tienen los visitantes en su sitio.
First Contentful Paint (FCP)
En primer lugar, Contentful Paint mide el tiempo que tarda el navegador de un usuario en renderizar los elementos del DOM (imágenes, elementos
- 0-2 segundos: Verde (rápido)
- 2-4 segundos: Naranja (moderado)
- 4+ segundos: Rojo (lento).
Índice de velocidad
Los sitios web rápidos ofrecen una mejor experiencia en línea. El índice de velocidad (Speed Index, «SI» por sus siglas en inglés) muestra el tiempo medio que el contenido de su sitio tarda en mostrarse a un usuario. Esta métrica identifica el exceso de JavaScript en una página y se mide en milisegundos, con un rango de puntuaciones SI:
- 0-4,3 segundos: Verde (rápido)
- 4,4-5,8 segundos: Naranja (moderado)
- 5,8+ segundos: Rojo (lento).
Time to Interactive (TTI)
El tiempo de interactividad es la cantidad de tiempo que tarda el contenido de una página en ser funcional para que esa página sea totalmente interactiva. El TTI le ayuda a identificar las páginas web con JavaScript innecesario y se mide en segundos, con un rango de puntuaciones TTI:
- 0-3,8 segundos: Verde (rápido)
- 3,9-7,3 segundos: Naranja (moderado)
- 7,3+ segundos: Rojo (lento).
Total Blocking Time (TBT)
El tiempo total de bloqueo ayuda a los propietarios de sitios web a evaluar el tiempo que una determinada página responde a una entrada específica del usuario. Esta métrica identificará las páginas con JavaScript innecesario y se mide en milisegundos con un rango de puntuaciones TBT:
- 0-300 ms: Verde (rápido)
- 300-600 ms: Naranja (moderado)
- 600+ ms: Rojo (lento).
Puntuaciones de rendimiento de la página
La puntuación del rendimiento de la página es una métrica única que tiene en cuenta todas las métricas importantes de la experiencia del usuario en Core Web Vitals. Esta puntuación utiliza un sistema de puntuación agregada en todas las visitas móviles y de escritorio. Toma la media ponderada para ofrecer una única puntuación que permita comprender rápidamente las páginas que necesitan un examen más detallado.
Estas métricas pueden simplificarse en la métrica de puntuación del rendimiento de la página, pero los desarrolladores pueden hacer referencia a las puntuaciones de cada categoría basándose en la puntuación específica de 90 (bueno), 50-90 (necesita mejorar) y menos de 50 (pobre).
Cómo medir los Core Web Vitals
Google ofrece seis formas completamente gratuitas de medir sus puntuaciones de Core Web Vitals; las dos más accesibles para los principiantes son PageSpeed Insights y Google Search Console.
Con la definición de estas «Core Web Vitals», Google pretende ofrecer una guía unificada para las señales de calidad que considera esenciales para ofrecer una gran experiencia de usuario en la web.
«Optimizar la calidad de la experiencia del usuario es clave para el éxito a largo plazo de cualquier sitio en la web.
Tanto si es propietario de un negocio, como si es comercializador o desarrollador, Web Vitals puede ayudarle a cuantificar la experiencia de su sitio e identificar las oportunidades de mejora.»
Google destaca la importancia de las Core Web Vitals por encima de otras métricas, ya que son fundamentales para todas las experiencias web. Las expectativas de los usuarios respecto a las experiencias web pueden variar según el sitio web y el contexto, pero algunas permanecen constantes independientemente del lugar en el que se encuentren en la web.
Como ya hemos mencionado al principio del post, las Core Web Vitals son las necesidades de experiencia del usuario que todos los sitios web deberían tratar de satisfacer. En concreto, Google identifica las necesidades básicas de la experiencia del usuario como la carga, la interactividad y la estabilidad visual.
Google explica por qué son tan importantes las tres métricas principales (Mayor pintura de contenido, Desplazamiento de diseño acumulado y Retraso en la primera entrada):
«Todas estas métricas recogen importantes resultados centrados en el usuario, son medibles sobre el terreno y cuentan con herramientas y equivalentes de métricas de diagnóstico de laboratorio.
Por ejemplo, si bien la mayor pintura de contenido es la métrica de carga más relevante, también depende en gran medida de la primera pintura de contenido (FCP) y del tiempo hasta el primer byte (TTFB), que siguen siendo fundamentales para controlar y mejorar».
Herramientas que le ayudarán a medir los aspectos vitales de la web
Google incorpora las capacidades de medición de Core Web Vitals a muchas de sus herramientas existentes. Core Web Vitals ahora se puede medir utilizando:
- Search Console;
- PageSpeed Insights;
- Lighthouse;
- Chrome DevTools;
- Chrome UX Report;
- Web Vitals Extension;
Como hemos prometido, a continuación trataremos estas herramientas con más detalle.
Search Console
Hay un nuevo informe Core Web Vitals en Search Console para ayudar a los propietarios de sitios a evaluar las páginas de todo el sitio. Este informe identifica grupos de páginas que requieren atención basándose en datos reales del informe Chrome UX. Con este informe, tenga en cuenta que las URL se omitirán si no tienen una cantidad mínima de datos de informe.
PageSpeed Insights
PageSpeed Insights se ha actualizado para utilizar Lighthouse 6.0, lo que hace que sea capaz de medir Core Web Vitals en las secciones de laboratorio y de campo del informe. Las Core Web Vitals se anotan con una cinta azul, como se muestra a continuación.
Lighthouse
Lighthouse se ha actualizado recientemente a la versión 8.3.0, que ya utiliza GTmetrix. Sin embargo, desde Lighthouse 6.0, la herramienta incluye nuevas auditorías, nuevas métricas y una puntuación de rendimiento recién compuesta. Dos de estas nuevas métricas añadidas son exactamente lo que necesitamos: Largest Contentful Paint y Cumulative Layout Shift.
Chrome UX Report
También conocido como CrUX, este informe es un conjunto de datos públicos de la experiencia real del usuario en millones de sitios web. El informe Chrome UX mide las versiones de campo de todas las Core Web Vitals, lo que significa que informa de datos del mundo real en lugar de datos de laboratorio.
Chrome DevTools
Chrome DevTools ayuda a los propietarios de sitios web a encontrar y solucionar los problemas de inestabilidad visual de una página que pueden contribuir al CLS. Selecciona un cambio de diseño para ver sus detalles en la pestaña Resumen. Para visualizar dónde se ha producido el cambio, pasa el ratón por encima de los campos Movido desde y Movido hasta. Chrome DevTools también mide el tiempo total de bloqueo, que resulta útil para mejorar el retardo de la primera entrada.
El TBT se muestra ahora en el pie de página del panel de rendimiento de Chrome DevTools cuando se mide el rendimiento de la página. Las optimizaciones de rendimiento que mejoran el TBT en el laboratorio también deberían mejorar el FID.
Web Vitals Extension
Una nueva extensión, que ya se puede instalar desde la Chrome Web Store, mide las tres métricas de Core Web Vitals en tiempo real.
Puede descargar e instalar la extensión desde aquí.
Por qué todo esto es importante para su sitio web
El usuario moderno no quiere esperar a que un sitio web se cargue para obtener la información que busca, y Google ha hecho esta conexión. A estas alturas, todo el mundo sabe que los objetivos de Google son mostrar no sólo el resultado más relevante para una consulta de búsqueda, sino también el más rápido. Ya no puedes clasificar bien si tu velocidad de página y otras métricas de experiencia de usuario son deficientes.
Este cambio para dar prioridad a la experiencia del usuario junto con los factores de clasificación existentes, como el contenido y los backlinks, tiene un gran impacto en la forma en que los propietarios de sitios web piensan en el SEO. Hay elementos adicionales en su lista de control que necesita marcar si su objetivo es clasificar en la primera página de Google para sus consultas de destino.
¿Está listo para pasar la prueba de Core Web Vitals para su sitio de WordPress?
Últimas palabras
Las métricas de Core Web Vitals y la forma en que se puntúan pueden cambiar con el tiempo. Google ha ido cambiando las métricas utilizadas para medir la velocidad e indexar los sitios web a lo largo de los años. Dar protagonismo a la experiencia de la página no significa que Google vaya a dejar de buscar un contenido de página excelente. Estamos siendo testigos de que la experiencia del usuario adquiere mayor importancia cada día, y más vale que estés preparado. Al fin y al cabo, todos trabajamos juntos por una web mejor.
