Google ha publicado notas sobre Core Web Vitals, sus tres nuevos elementos principales para medir la velocidad cuando examina tu sitio.
No es sorpresa que asegurar que el rendimiento de tu sitio web sea rápido, es vital para su éxito en la web. Hemos escrito sobre este tema varias veces a lo largo de los años. Lo que a menudo es menos obvio es cómo cuantificar adecuadamente el rendimiento del sitio web. A través de los años, Google y otras empresas han lanzado diversas herramientas que pueden ayudarte a medir el rendimiento de tu sitio, pero a menudo estas herramientas suelen medir cosas diferentes y puede ser difícil saber realmente si tus esfuerzos de optimización están funcionando adecuadamente ya que herramientas diferentes dan resultados diferentes.
La semana pasada, Google anunció en su Chromium Blog (en inglés) una nueva iniciativa conocida como la iniciativa Web Vitals, la cual tiene como objetivo unificar la orientación en cuanto a las señales que debes medir para brindar la mejor experiencia al usuario.
📢Introducing Web Vitals, an initiative by Google to provide unified guidance for quality signals that are essential for great user experiences on the web. More at https://t.co/7vnUDaeaBz pic.twitter.com/aR86FrS9r0
— Chrome Developers (@ChromiumDev) May 5, 2020
Core Web Vitals
Para empezar, la iniciativa Web Vitals ha identificado un conjunto de tres métricas que consideran Core Web Vitals. Google admite que estas tres métricas evolucionarán con el tiempo (en inglés), pero por ahora, estos son los tres signos vitales que recomiendan medir cuando se trata de cuantificar el rendimiento. Cuando pensaron en estos signos vitales, se enfocaron en métricas que capturan los resultados en torno al usuario, son medibles en el campo (en inglés), y ya tienen diagnósticos y herramientas de laboratorio equivalentes.
Ve este video para saber más sobre Core Web Vitals (en inglés).
Largest Contentful Paint (LCP) Mide la Velocidad de la Carga
Medir qué tan rápido se carga el contenido principal de una página web ha sido siempre uno los más importantes indicadores de la rapidez de una página. Cuando un usuario visita una página de tu sitio, si hay un tiempo de espera antes de que el contenido principal sea visible, puede ser frustrante.
Desafortunadamente, medir esto ha sido de alguna forma el Santo Grial entre desarrolladores web ya que puede ser difícil para las herramientas automatizadas identificar adecuadamente cuál es el contenido principal de una página, a menudo hasta que el resto de la página ya esté cargada.
En el pasado, la carga se medía mediante el seguimiento de eventos como DOMContentLoaded (en inglés), que se dispara cuando se ha renderizado todo el HTML, pero antes de que se hayan recuperado y renderizado recursos adicionales, como hojas de estilo, imágenes, y javascript. Lamentablemente, si bien esto era relativamente fácil de medir, no daba una imagen completa de cuándo el contenido de la página pareciera haber terminado de cargarse.
Las mediciones posteriores, como las de First Contentful Paint (FCP) (en inglés) y First Meaningful Paint (FMP) (en inglés), intentaron mejorar esto rastreando cuándo comienza a mostrarse el contenido real (completo con estilos e imágenes) en la página, pero detener las mediciones en el momento en que se muestra el primer contenido de la página no es particularmente útil porque este contenido no es utilizable por el usuario.
Largest Contentful Paint (LCP) (en inglés) resuelve este problema al reportar el tiempo en el cual el elemento de contenido más grande en la página es renderizado. Esto es más útil porque el elemento de contenido más grande es generalmente el cuerpo de contenido principal de la página, por lo que el momento en que este elemento es visible es un buen indicador de la percepción del tiempo de carga de la página por parte del usuario.
La LCP se mide en segundos desde el comienzo de la carga de la página. Una puntuación de 2.5 segundos o menos para LCP se considera “Buena”, una puntuación entre 2.5 segundos y 4 segundos se considera que “Necesita Mejorar”, y una puntuación de LCP mayor de 4 segundos se considera “Mala”. Siempre debes esforzarte para asegurarte de que la LCP se dispare en menos de 2.5 segundos desde el inicio de la carga de la página.
First Input Delay (FID) Mide la Interactividad
La segunda de las tres métricas de Cobre Web Vitals es el First Input Delay (FID) (en inglés), que mide el tiempo desde que el usuario interactúa por primera vez con una página hasta el momento en que el navegador es capaz de responder a esa interacción. Los retrasos en la entrada pueden ser frustrantes para los usuarios que tratan de interactuar con su contenido, y cuanto más retrasada sea la respuesta a la entrada del usuario, más frustrado se sentirá.
El FID se mide en milisegundos, y como el LCP, cuanto más pequeño sea el número, mejor. Las puntuaciones del FID por debajo de 100 milisegundos se consideran “Buenas”, las puntuaciones del FID entre 100 milisegundos y 300 milisegundos se consideran que “Necesita Mejorar”, y las puntuaciones superiores a 300 milisegundos se consideran “Pobres”.
Cumulative Layout Shift (CLS) Mide la Estabilidad Visual
Otra frustración del usuario relacionada con el rendimiento se da cuando los elementos de la página cambian de posición debido a que otros elementos se cargan y empujan el contenido hacia abajo en la página. Aunque normalmente esto es simplemente frustrante, es posible que un cambio de diseño inesperado pueda hacer que las acciones previstas por el usuario resulten en algo muy diferente. Por ejemplo, puede que estés a punto de hacer clic en un enlace concreto, sólo para que el enlace se mueva justo cuando intentas hacer clic en él y acabes haciendo click en algo muy diferente.
La métrica Cumulative Layout Shift (CLS) (en inglés) tiene como objetivo medir cuánto se desplaza el diseño de tu página debido a la carga. A diferencia del LCP y el FID, el CLS no es una medida de tiempo, sino un porcentaje. Más exactamente, es una combinación de dos métricas diferentes, ambas medidas en porcentaje como una porción fraccionaria de la pantalla.
Fracción de Impacto
La Fracción de Impacto se mide cuando los objetos se mueven. Toma un elemento antes y después de que se mueva y suma la cantidad total de la vista afectada por el cambio. Por ejemplo, si un elemento ocupa el 50% de la pantalla, y se mueve hacia abajo en un 25% de la pantalla, la Fracción de Impacto es del 75% (ó 0.75 en decimal).
Fracción de Distancia
Una versión anterior de esta métrica sólo utilizaba la fracción de impacto, pero descubrieron que el cálculo penalizaba excesivamente las situaciones en las que los elementos grandes se desplazaban sólo en una pequeña cantidad. Para resolver este problema, añadieron una segunda fracción, la Fracción de Distancia, que mide la distancia más lejana que cualquier elemento individual (independientemente de su tamaño) se mueve. En el ejemplo anterior, este sería el 25% mencionado anteriormente (ó 0.25 en decimal).
Puntaje del CLS
Para obtener el puntaje final del CLS, multiplique la Fracción de Impacto por la Fracción de Distancia, y el resultado será el puntaje final. Para el ejemplo anterior, esto sería 0.75 * 0.25 = 0.1875 (18.75%)
El CLS se presenta como un número decimal. Las puntuaciones inferiores a 0.1 se consideran “Buenas”, las puntuaciones entre 0.1 y 0.25 se consideran que “Necesita Mejorar”, y las puntuaciones superiores a 0.25 se consideran “Pobres”.
Medición de Core Web Vitals
Google trabaja intensamente en herramientas y servicios que ayudarán a los desarrolladores web a medir estas diversas puntuaciones para determinar la salud general de sus sitios. Estos cálculos se incorporarán a las demás herramientas de prueba de rendimiento de Google, entre las que se encuentran Lighthouse, PageSpeed Insights, Google Search Console, y Chrome DevTools.
Sin embargo, por ahora hay API y SDK disponibles para que los desarrolladores puedan utilizarlos para integrar los cálculos a sus propias pruebas, y Google además ha publicado el código fuente de una versión alfa de una extensión de Chrome que puede calcular estas puntuaciones sobre la marcha para cualquier sitio web.
La extensión Chrome se considera alfa y podría cambiar considerablemente antes de que se publique en la Tienda Web de Chrome, pero por el momento, los desarrolladores (incluidos nosotros en Justia) podemos empezar a medir los Core Web Vitals ahora mismo.
AMP y Core Web Vitals
El día después de la publicación del blog de Chromium, el proyecto de AMP publicó sobre lo que Web Vitals significa para el proyecto de AMP (en inglés). Afortunadamente, las mismas cosas que el Core Web Vitals mide como cosas que deben ser reparadas están alineadas con lo que el proyecto de AMP busca abordar.
This week @ChromiumDev announced the Web Vitals Initiative 🌐
Read our latest blog post to learn how AMP⚡ can help site owners meet the recommended performance targets outlined by Web Vitals, and easily maintain them over time 👇 https://t.co/2x9ikl8FSg
— AMP Project (@AMPhtml) May 6, 2020
Largest Contentful Paint
El proyecto de AMP fue diseñado desde el principio para minimizar el paint del contenido. Al descargar la carga en un caché de AMP que puede pre-cargar y pre-renderizar el contenido, las páginas se cargan instantáneamente sin demora cuando se enlazan desde los resultados de la búsqueda. Y con la carga inteligente de recursos de AMP, las imágenes y los recursos externos que se encuentran debajo del pliegue se retrasan automáticamente, lo que permite que el contenido que el usuario verá primero se renderice rápidamente sin tener que esperar a recursos que ni siquiera verá hasta que se desplace hacia abajo por la página.
Para las cargas de páginas de la Búsqueda de Google, el LCP estará muy por debajo del umbral de 2.5 segundos definido en Core Web Vitals, asegurando una puntuación “Buena”.
First Input Delay
Dado que los recursos vitales, como la biblioteca de AMP, son precargados por el navegador incluso antes de que el usuario haga clic en su página, el procesamiento que causaría un retraso en la entrada se minimiza en la mayor medida posible, lo que significa que el navegador estará listo para responder a la entrada del usuario inmediatamente. Además, las limitaciones incorporadas en el contenido de terceros nativo de AMP impiden que otros recursos de la página bloqueen el navegador y detengan la interacción del usuario.
Las limitaciones en el contenido de terceros y la biblioteca precargada de AMP aseguran que la primera demora en la entrada siempre estará muy por debajo del umbral de los 100 milisegundos para garantizar una puntuación “Buena”.
Cumulative Layout Shift
AMP requiere que todos los elementos de la página tengan un tamaño estático, lo que requiere que las imágenes, iframes, e incrustaciones tengan una altura y un ancho estáticos definidos en el código HTML. Esto le permite a AMP colocar un espacio inteligente entre todos los contenidos de la página. Esto significa que incluso en una situación en la que un elemento de contenido no se cargue inmediatamente, el espacio para ese elemento ya ha sido asignado. Esto elimina por completo el cambio de diseño porque los elementos que se cargan más tarde simplemente rellenan el espacio en blanco del marcador de posición que se definió previamente, sin necesidad de mover contenido.
Gracias a los elementos de disposición estática, las páginas AMP deben obtener fácilmente una puntuación de CLS inferior al 0.1 necesario para obtener una puntuación “Buena” en esto también.
El Futuro Rápido
La iniciativa Web Vitals es nueva y está creciendo, pero se basa en la cimentación de las métricas y el análisis que Google ha estado impulsando con herramientas como PageSpeed Insights y Google Search Console durante años. Los desarrolladores deben estar atentos a los nuevos desarrollos de Web Vitals y a otros estándares que están en cambio constante para asegurar la mejor experiencia de los usuarios, tanto para sus propios usuarios como para los motores de búsqueda que usan el rendimiento como factor de desempeño.
Cuando se anunció el Core Web Vitals, nuestro equipo inmediatamente tomó la versión alfa de la futura extensión de Chrome y la puso a trabajar en nuestros navegadores Chrome para poder probar los sitios de nuestros clientes y asegurarnos de que obtuvieran buenos resultados. Afortunadamente, nuestra dedicación a la creación de páginas web de alto rendimiento nos da una ventaja temprana, y estamos viendo resultados fantásticos al probar nuestros propios sitios en esta primera versión de Core Web Vitals.
También proporcionamos versiones de AMP (en inglés) para todos los sitios web y blogs de nuestros clientes sin cargo adicional, por lo que se benefician automáticamente de la optimización del rendimiento de AMP.
Si el sitio web de tu firma de abogados necesita una revisión de rendimiento, contacta a nuestros especialistas en Justia. Nuestro equipo está compuesto de profesionales experimentados que siempre están al tanto de las últimas tendencias en rendimiento. Nuestros clientes pueden estar seguros de que cuando trabajan con Justia, están trabajando con una empresa que se dedica a proporcionar sitios optimizados tanto para los motores de búsqueda como para el rendimiento de los usuarios, sin dejar de tener un diseño moderno y profesional. No demores, llama a Justia (en inglés) para actualizar el sitio web de tu firma de abogados hoy mismo.
Si te interesa saber más sobre Core Web Vitals, no dejes de consultar las publicaciones de Google en los blogs Chromium (en inglés) y AMP Project (en inglés), o consulta estos artículos de SearchEngineJournal (en inglés) y 9to5 Google (en inglés), que también han resumido la iniciativa.
