Core Web Vitals: que son, cómo mejorarlas y optimizar tu WordPress

Google anunció un nuevo set de métricas a las que llama Core Web Vitals o Métricas Web Principales (usaré ambos términos indistintamente), como se les conoce en español, que tienen que ver con velocidad, responsividad y estabilidad visual, con miras a que los dueños de los sitios puedan medir la experiencia de usuario que tienen los visitantes en dichos sitios. A su vez, estas nuevas Core Web Vitals se integrarán en un futuro cercano con señales existentes (amigable con móviles, navegación segura, seguridad HTTPS y directrices intersticiales intrusivas, hablaré de ellas al final) en una nueva señal de posicionamiento de experiencia de usuario. Más aún, estas nuevas señales se tomarán en cuenta como criterios de eligibilidad para aparecer en las Top Histories o Noticias principales, que antes tenían como requerimiento tener una versión AMP de la página en cuestión, mismo que ya no será tomado como tal, aunque se le seguirá dando soporte.

Estas nuevas métricas estarán embebidas en toda la oferta de herramientas de medición de Google, es decir en Search Console, PageSpeed Insights, Lighthouse, Chrome DevTools, Chrome UX Report y la extensión Web Vitals. Vamos a repasar que son las tres Core Web Vitals nuevas y después veremos que podemos hacer al respecto en nuestros sitios con WordPress, a modo de preparación en un futuro.

¿Cuales son las nuevas Core Web Vitals?

Son tres y son las siguientes:

• Largest Contentful Paint (LCP), medida para evaluar el tiempo de carga.
• First Input Delay (FID), medida para evaluar el tiempo en que puedes interactuar con el sitio a partir de la carga.
• Cumulative Layout Shift (CLS), determina que tan consistente es la interfaz visual.

Vale la pena que estas Core Web Vitals son las que están por ahorita; Google planea incorporar más señales cada año para responder a las expectativas de usuario, así que habrá más diversión en el futuro cercano.

¿Cuándo entrarán en vigor estas Core Web Vitals?

En 2020 seguro no será; se habla de que en 2021 es cuando empezará la fiesta. Eso si, Google ha dicho que anunciará con seis meses de antelación, así que por ahora eso nos deja o fin de año (que ya dijeron que no será) o 2021, que es el plan supuestamente, así que tienes tiempo de ir viendo que hacer con tu sitio de WordPress para adelantarte y no estar dando patadas de ahogado los primeros meses del próximo año.

Ahora si, vamos a ver las métricas una a una:

¿Qué es la métrica Largest Contentful Paint (LCP)?

La métrica Largest Contentful Paint o LCP (que traducido sería algo así como “Renderizado del mayor elemento con contenido “) reporta el tiempo en mostrar en pantalla el contenido más grande visible dentro del puerto visual. Para considerarse como una buena experiencia, el LCP debe ocurrir dentro de los primeros 2.5 segundos desde que la página empieza a cargar; entre 2.5 y 4 segundos significa que necesita mejoras y de 4 segundos en adelante se considera como una experiencia de usuario pobre.

¿Que significa toda esta palabrería? básicamente esta medición determina cual es el elemento más grande visible en la ventana actual y en cuanto tiempo se muestra en pantalla. Mira este ejemplo (tomado de web.dev):

Como puedes ver, es una carga del sitio de CNN y vemos que hasta el final es cuando se carga el elemento más grande; pero ahora ve que pasa en una página de resultados de Google (buscando al patrón ni más ni menos, igual tomado de web.dev):

Como puedes ver, el elemento más grande es ese bloque grande de texto que se muestra apenas después del primer pintado de contenido (FCP).

¿Que elementos se consideran para evaluar el Largest Contentful Paint?

Los elementos que se consideran para evaluar esta métrica actualmente son:

• Elementos <img>
• Elementos <image> dentro de un elemento <svg>
• Elementos <video> (se usa la imagen de poster)
• Elementos con fondo de imagen cargado con la función url()
• Elementos de bloque que contengan nodos de texto o otros elementos hijos de texto en línea

Esto está descrito en la especificación actual, pero puede cambiar en el futuro.

¿Qué medidas puedo aplicar para optimizar el Largest Contentful Paint en mi sitio con WordPress?

La métrica Largest Contentful Paint se ve afectada por varios factores; en la tabla siguiente se muestran a la izquierda estos factores y que prácticas recomendadas puedes llevar a cabo para contrarrestar dicho factor:

Factor que afecta el LCP	Práctica(s) recomendada(s) para mejorar el LCP	Qué hacer en WordPress
Lentitud en tiempo de respuesta del servidor	– Cambiar a un mejor hosting – Revisar la configuración del servidor – Usar un CDN – Usar caché – Reducir cantidad de plugins -Indicar conecciones a terceros pronto (rel=”preconnect”)	– Usar un plugin todo en uno para optimización o bien utilizar plugins especializados para CDN, caché, minificación y optimización
Bloqueo de representación por CSS o JS	– Optimizar CSS (reducir y minificar) – Optimizar la ruta crítica de CSS – Aplazar la carga de CSS no crítico – Mover el CSS crítico a en línea – Optimizar JavaScript (reducir y minificar) – Reducir el bloqueo por JS con defer o async	– Usar un plugin todo en uno para optimización o bien utilizar plugins especializados para CDN, caché, minificación y optimización
Tiempo de carga de recursos	– Optimizar imágenes (manualmente o con plugins) – Considera usar nuevos formatos (WebP o JPEG XR) – Usar un CDN – Optimizar web fonts – Precarga de recursos importantes – Servir contenido comprimido	– Utilizar plugins especializados para procesamiento de imágenes – Usar un plugin todo en uno para optimización o bien utilizar plugins especializados para CDN, caché, minificación y optimización
Renderizado de lado del cliente	– Optimizar JavaScript – Minificar el JavaScript crítico	N/A

No es que debas aplicar TODAS las buenas prácticas, a veces unas cuantas dan excelentes resultados, pero para ello tendrás que experimentar. Espero escribir guías sobre varios de estos temas pronto. Recomiendo leer el artículo completo de optimización de LCP en web.dev de Google.

Ahora toca el tema al FID, o First Input Delay.

¿Qué es la métrica First Input Delay (FID)?

La métrica First Input Delay o FID (traducido es algo como “Retraso de primera entrada“) mide el tiempo que transcurre desde que el usuario inicia una acción en tu sitio haciendo clic o tap en algún elemento hasta que el navegador puede responder a esa interacción; en pocas palabras, que tan eficientemente responde tu sitio a las acciones que intenta hacer el usuario. Para considerarse como una buena experiencia, el FID debe estar de 100 milisegundos o menos; entre 100 y 300 milisegundos significa que debes mejorarlo, y de 300 milisegundos para arriba es una experiencia de usuario pobre.

Cosideraciones importantes sobre qué es una “primera” entrada

Sin entrar en detalles técnicos, vale la pena precisar algunos detalles importantes de esta métrica: antes que nada, que sólo considera la primera entrada puesto que es la que más efecto tiene en tus usuarios, es lo que muchos de ellos usan para determinar la calidad y confiabilidad de tu sitio.

Otro detalle importante es que para efectos de esta métrica se toman en cuenta eventos de entrada como clics, taps y teclas presionadas, pero no otras interacciones como desplazamientos o acercamientos, puesto que las primeras son discretas y las segunas son contínuas, y tienen diferentes consideraciones de desempeño.

Un tercer detalle que no se debe pasar por alto es que para medir el FID hace falta hacerlo con usuarios reales. En las herramientas de medición se puede correlacionar con otra métrica que es el Total Blocking Time (TBT, traducido como “Tiempo Total de Bloqueo“, métrica usada para determinar el tiempo en que una página es no responsiva), y aplicar técnicas que mejoren el TBT por lo general significa que también mejorará el FID.

¿Qué medidas puedo aplicar para optimizar el First Input Delay en mi sitio con WordPress?

La métrica First Input Delay se ve afectada principalmente debido que tu sitio usa demasiado JavaScript, ahogando al navegador que tiene que procesarlo; en la tabla siguiente se muestran a la izquierda los factores que afectan al FID y que prácticas recomendadas puedes llevar a cabo para contrarrestar dicho factor:

Factor que afecta el FID	Práctica(s) recomendada(s) para mejorar el FID	Qué hacer en WordPress
Tiempo de ejecución de JavaScript	– Minificar y comprimir JavaScript – Aplazar la carga de JavaScript (defer o async) – Minimizar el uso de polyfills no utilizados – Aplicar compresión gzip a JavaScript	– Instalar plugins de optimización de CSS y JS – Habilitar compresión GZIP en el servidor
Tareas largas de JavaScript	– Dividir código largo en fragmentos más pequeños	– Reduce cantidad de plugins
Falta de preparación para la interacción	– Diversos métodos para simplificar el código y reducir carga y tamaño de código a ejecutar – Reducir o evitar solicitudes de datos en cascada (encadenados) – Reducir post-procesamiento de datos del lado del cliente	N/A
Ausencia de un web worker	– Implementar un web worker de modo que se pueda procesar JavaScript como una tarea de fondo	N/A

Debo decir que fuera del primer factor, las medidas propuestas por Google suenan difíciles en un CMS como WordPress, en particular en el tema de la preparación para la interacción, pues por lo general no se tiene mucho control del JavaScript más allá de como fue construido por su diseñador. Recomiendo leer el artículo completo de optimización de FID en web.dev de Google.

Vamos a la tercera métrica.

¿Qué es la métrica Cumulative Layout Shift o CLS?

La métrica Cumulative Layout Shift o CLS (traducido a algo como “Cambio de disposición acumulativo”) mide cualquier cambio no esperado en la disposición de la página durante su tiempo de vida total; un cambio de disposición se refiere al cambio de posición de un elemento de un momento a otro. Para ser considerado como una buena experiencia, un CLS debe ser de 0.1 para abajo; entre 0.1 y 0.25 se considera como que le falta mejora y de 0.25 para arriba es pobre. Vale la pena mencionar que por ahora se considera un cambio de disposición sólo en términos de posición, no de tamaño, excepto que el cambio de tamaño haga que otros movimientos cambien su posición inicial.

Sin temor a equivocarme creo que muchos de nosotros lo hemos experimentado de una u otra forma; el ejemplo clásico es algún elemento al que le quieres dar clic, y de la nada aparece un anuncio que estaba más arriba y del cual no tienes tiempo de cambiar tu decisión y terminas haciendo clic en algo que no querías (por lo general un anuncio), y acabas en algún sitio de dudosa reputación.

¿Qué se considera como un cambio de disposición?

Es de hacer notar y recalcar que esto sólo mide los cambios NO ESPERADOS, es decir, es perfectamente válido que la disposición de los elementos en pantalla cambie debido a que el usuario inicia una interacción. El caso de las animaciones y transiciones requiere cierto cuidado, pues si se emplean bien no habrán problemas, pero si son abruptas podrían ser consideradas como una mala experiencia de usuario.

¿Qué medidas puedo aplicar para optimizar el First Input Delay en mi sitio con WordPress?

Los siguientes factores pueden crear un cálculo alto de CLS (cosa que obviamente no queremos):

Factor que afecta el CLS	Práctica(s) recomendada(s) para mejorar el CLS	Que hacer en WordPress
Imágenes sin dimensiones	– Añadir dimensiones a las imágenes con los atributos width y height	– Usar temas de buena reputación y calidad
Anuncios, embeds e iframes sin dimensiones	– Añadir dimensiones o precalcular tamaño que van a usar	– Usar temas de buena reputación y calidad
Inyección de contenido dinámico	– Reservar el espacio que van a utilizar	– Usar temas de buena reputación y calidad
FOIT/FOUT	– Uso correcto de font-display – Precarga de recursos (rel="preload")	– Usar temas de buena reputación y calidad – Usar un plugin de optimización

FOIT y/o FOUT son comportamientos del navegador que tienen que ver con el momento en que se carga una fuente web: FOIT significa “Flash of Invisible Text” o “Flash de Texto Invisible” y es un comportamiento predeterminado del navegador para hacer el texto invisible mientras se carga la fuente web, y tiene la peculiaridad de que bloquea. Por su parte, FOUT significa “Flash of Unstyled Text” o “Flash de texto sin estilo” y es un comportamiento por defecto para renderizar el texto con la fuente del sistema de reserva mientras la fuente de la web se ha cargado. FOUT es preferible a FOIT pero se debe tener cuidado de minimizar su efecto de reflujo, que como se podrán imaginar, ocasiona que se mueva la disposición de elementos en pantalla y puede ocasionar que afecte negativamente al cálculo del CLS.

El tema del Cumulative Layout Shift es particularmente interesante en cuestión de WordPress, pues hay una optimización que se hace comúnmente y que puede ocasionar que se dispare una calificación de CLS que vaya en detrimento de nuestro sitio; hablo del lazy loading o carga diferida de imágenes (y en general de cualquier cosa), que dependiendo de una combinación de situaciones puede ocasionar lo que antes menciono. Recomiendo leer el artículo completo de optimización de CLS en web.dev de Google.

¿Cómo mide Google las Core Web Vitals?

Los valores que determinan si a un determinada métrica de estas se le asigna el valor “buena”, “necesita mejora” o “pobre” depende de una serie de valores que a su vez vienen de análisis interno de datos de Google. Adicionalmente a esto, para determinar la clasificación general de desempeño de un sitio se toma en cuenta el 75o. percentil de todas las páginas vistas. Todo esto está explicado en un excelente post de web.dev donde encontrarás el razonamiento y los estudios que dieron pie a los umbrales y el manejo de los percentiles adecuados dependiendo de cada métrica. Les aconsejo leerlo pues tiene mucha información y referencias sobre este tema.

¿Dónde puedo obtener mediciones de éstas nuevas Core Web Vitals?

En toda la gama de servicios de Google:

Servicio	LCP	FID	CLS
Page Speed Insights	✔	✔	✔
Chrome UX Report	✔	✔	✔
Search Console	✔	✔	✔
Chrome Dev Tools	✔	Usar TBT	✔
Lighthouse	✔	Usar TBT	✔
Web Vitals Extension	✔	✔	✔

Todos los servicios van a sufrir modificaciones para acomodar estas nuevas métricas. Algunos ya están listos y otros están en camino, pero para ser más precisos:

Page Speed Insights

En Page Speed Insights lo encontrarás debajo de Datos de Campo (con usuarios) y Datos de Experimento (mediciones sintéticas); los ubicarás porque tienen un listón azul a la derecha:

Chrome UX Report

Chrome UX Report contiene los datos de experiencia real de usuarios, cientos de miles de ellos, así que lo que hallarás aquí son mediciones de los Core Web Vitals reales, no de laboratorio. Puedes consultar más información de como accesar Chrome UX Report aquí.

Search Console

Dentro de Search Console en la sección de Mejoras hallarás el nuevo reporte de Métricas Web Principales segmentadas por móvil y escritorio, la cual te ayudará a determinar en que URL de tu sitio tienes problemas de modo que puedas resolverlos eficientemente. Los datos vienen de Chome UX Report, lo que significa que hay datos reales:

Chrome DevTools

Disponible en Chrome Canary por ahora y estarán disponibles en Chrome 84. La integración muestra las tres Métricas Web Principales y también permite obtener datos de desplazamientos en pantalla, de modo que puedas determinar que hacer para repararlos.

Lighthouse

Lighthouse igual tendrá integración con las nuevas Métricas Web Principales y se mostrará en el grupo Métricas.

Web Vitals Extension

Una extensión muy temprana que es de hecho versión alfa y que puedes obtener en este enlace de GitHub, ahí mismo está el instalador.

Core Web Vitals en otras herramientas

Web Page Test ya muestra un par de métricas (LCP y CLS, recordar que FID es sólo medible en campo):

La señal futura de ranking: la experiencia de usuario

Sumando las tres Métricas Web Principales, llegamos a lo que Google evaluará como experiencia del usuario:

Resumiendo, la experiencia de usuario está compuesta por estas señales:

• Largest Contentful Paint: velocidad de carga.
• First Input Delay: interactividad, responsividad del sitio.
• Cumulative Layout Shift: estabilidad visual, la estructura y disposición que ves en cualquier momento no cambia abruptamente.
• Mobile friendly: si tu sitio es amigable con smartphones y tablets.
• Safe browsing: que tu sitio no contenga malware o componentes engañosos, puedes verificarlo en Google Search Console.
• HTTPS: que tu sitio tenga soporte de SSL/TLS.
• No intrusive interstitials: que tu sitio no esté bloqueado por popups agresivos u otros mecanismos que afecten la navegación.

Así que ahí tienes un panorama general de que medirá en conjunto Google en algún momento del 2021. Si de verdad te interesa tu sitio, empieza a trabajar en el para mejorarlo y sigue de cerca el tema de la experiencia de usuario porque esto apenas comienza y habrá mucha tela de donde cortar en el futuro inmediato.

Contenido genial, experiencia horrible: ¿que sucederá en este caso?

Ok, te rompiste el lomo escribiendo ese post de 20K palabras pero tus gráficas con los resultados del análisis muestran que tus métricas están por los suelos, tranquilo: el buen contenido todavía tendrá una cierta prioridad y Google ha dicho que si tu contenido es bueno pero tu experiencia de usuario apesta, aparecerás en los resultados de búsqueda…pero si tienes páginas con contenido similar, la página con mejor experiencia de usuario tendrá la ventaja. Lo que no dicen es hasta cuando será esto, así que por ahora considera que te puedes salir con la tuya si tienes muy buen contenido pero experiencia de usuario regular, aunque no esperes que sea para siempre.

Métricas, inconsistencias y Google

Bien, todo esto suena muy bonito, pero estoy seguro que muchos de ustedes que han optimizado sitios sabrán que al final nos quedamos con los huesos más duros de roer en cuanto a WPO se trata: Google y otros frecuentes como Facebook y Twitter: sus basuras son legendarias por la cantidad de cosas que cargan y que son prácticamente imposibles de optimizar en muchos casos, y que claro que terminan impactando al sitio. Sólo de Google podemos mencionar la analítica, AdSense, Maps, incrustar fuentes…creo que más allá de estar inventando métricas, Google debería darnos más facilidades para optimizar sus productos.

¿Cómo puedo mejorar la experiencia de usuario en mi sitio con WordPress?

Si combinamos todo lo que se puede hacer en tu sitio con WordPress para mejorar en cuanto a las Métricas Web Principales, verás que no hay nada nuevo:

• Contar con hosting sólido.
• Optimizar JS y CSS (sobre todo JS): minificar, reducir cantidad.
• Diferir la carga de JS y CSS.
• Optimizar imágenes y medios en general, es buen momento para pasarse a formatos actuales como WebP.
• Servir contenido comprimido.
• Manejar algún método de caché.
• Reducir la complejidad del sitio.
• Reducir cantidad de plugins usados.
• Tener tu sitio bajo HTTPS.
• Tener un sitio listo para usarse al 100% en móviles.
• Permitir que el usuario use el sitio sin obstrucciones o si tienen que haberlas, que sean mínimas y poco invasivas.
• Mejora la usabilidad y accesibilidad hasta donde te sea posible.
• Tener buenas prácticas de seguridad en el sitio.
• Todos los trucos de ganancia menores, como quitar cosas innecesarias (embeds, emojis, etc), uso de precarga en enlaces externos, y todos aquellos truquillos que si bien por si solos no son gran cosa, son ese centavito que rueda y rueda hasta que un día completan un peso, como dijeran en las películas mexicanas de la Época de Oro.

Para aclarar, esto no se trata de velocidad a lo bruto, como algunos lo han querido hacer ver. Hay cosas que se antojan difíciles de lograr al 100% hablando de WordPress, porque en buena medida lo usamos “como es” tal como lo dice la licencia, y optimizar lo que ya está en el core de WordPress no es tan sencillo. Ahora mismo WordPress está pasando por una transición algo compleja, y hablo de Gutenberg y todo lo que está trayendo consigo, con código, librerías y estilos y recursos que cambian todo el tiempo, así que de la manera que yo lo veo lo que me parece realista es apuntar a lo mejor que podamos hacer, y ejecutando las tareas antes mencionadas tenemos una buena parte de la batalla ganada.

Palabras finales

Pues ahí tienes, en mi opinión las métricas son importantes por un lado, porque nos dan información cuantitativa y también cualitativa para afinar nuestros sitios – aunque irremediablemente terminamos en el círculo vicioso de bailar al son que Google nos toque, hasta que se le ocurra algo nuevo. En el caso de las Core Web Vitals, tenemos tiempo para ir afinando nuestros sitios con WordPress y dejarlo como le gusta a la empresa de las letras de colores.

Imagen de cabecera: lloorraa en Pixabay