Cómo Core Web Vitals afectarán el ranking de Google en 2021

¡Hola a todos, muchas gracias por unirse hoy y estoy muy emocionado de hablar sobre cómo Core Web Vitals afectará el ranking de Google en 2021! Mi nombre es Lee y soy un arquitecto de soluciones en Vercel, y lidero DevRel para Next.js.

Si no has oído hablar de Vercel, no te preocupes. Vercel es una plataforma para desarrolladores que les permite construir excelentes sitios web. Si no lo has probado, te recomiendo ir a deploy.new y desplegar una aplicación en cuestión de minutos.

Pero lo que vamos a hablar hoy es un poco sobre estas cosas llamadas Core Web Vitals. Comenzaré con un poco de antecedentes e introducción. Luego profundizaré en estos Core Web Vitals y cómo afectarán tu Optimización para Motores de Búsqueda, o SEO. Daré algunas estrategias prácticas para mejorar el rendimiento. Y finalmente, después de implementar esas estrategias, medir ese rendimiento y ver los cambios que has realizado.

Pero antes de poder hacer todo eso, retrocedamos y hagamos una introducción sobre por qué debemos preocuparnos por el rendimiento web. En 2009, Amazon descubrió que por cada 100 milisegundos de latencia adicional, veían un 1% menos de ventas. Pudieron relacionar directamente el rendimiento con el impacto comercial en sus ventas. Y para reiterar este punto, si miramos unos años después, Walmart, cuando redujo la latencia en 100 milisegundos, obtuvo un 1% más de ingresos, y esto fue en 2012. Idea similar, resultados similares aquí. La conclusión es que un mejor rendimiento conduce a un mejor SEO y tiene un impacto directo en tu negocio.

Me encanta esta captura de pantalla del fundador de Nomad List, que dice: ¿Google Search hizo una actualización del algoritmo? Porque hoy me desperté y, por alguna razón, mi SEO estaba por las nubes. Estaba obteniendo muchas más clics en Google Search Console, viendo la tasa de conversión de las personas que vienen de Google. Entonces, cuando tienes un mejor rendimiento, como lo hacen en Nomad List, al final conducirá a un mejor SEO, especialmente ahora con la introducción de Core Web Vitals.

Entonces, ¿cómo podemos medir esta experiencia de usuario real de las personas que usan nuestro sitio? Google se ha preocupado por el rendimiento durante mucho tiempo y nos ha proporcionado muchas herramientas diferentes para medir ese rendimiento. Pero cuando hay tantas herramientas diferentes, puede ser difícil entender en qué cosas importantes debo enfocarme y cuáles son las medidas cuantitativas para comprender qué es bueno y qué es malo. Por lo tanto, realmente se logró un avance cuando el Grupo de Trabajo de Rendimiento Web trabajó con Google para introducir estas Métricas de Core Web Vitals. Vamos a hablar de ellas en un segundo. Pero realmente te ayudan a comprender qué tan buena es tu experiencia de usuario real al centrarte en el resultado para el usuario final, cómo están percibiendo tu sitio. Qué tan rápido llega frente a sus ojos, si las cosas saltan o no, qué tan rápido reacciona a la entrada, y estamos optimizando la calidad de la experiencia. Google y el Grupo de Trabajo de Rendimiento Web realizaron esta investigación y citaron otras investigaciones sobre HCI, interacción humano-computadora, para comprender cuáles son las métricas más importantes a tener en cuenta. Y eso son los Core Web Vitals. Primero, tenemos Largest Contentful Paint. Esta es la velocidad de carga percibida de tu página. Básicamente, el punto en el que entra el elemento más grande, típicamente algo como una imagen o un video.

Cuando tienes un LCP rápido, ayuda a asegurar que tu página sea útil. Es mostrar la pintura en la pantalla o mostrar el contenido en la pantalla rápidamente. Como mencioné antes, estos Core Web Vitals no solo nos dicen qué, sino que también nos brindan orientación sobre qué es bueno, qué es más o menos, y qué no es muy bueno.

Queremos apuntar a un LCP de menos de 2.5 segundos, idealmente. Hay más información en la parte inferior derecha de estas diapositivas si quieres aprender más y profundizar más. Un ejemplo de esto, solo para mostrar realmente cómo se ve esto, es para la Búsqueda de Google. Digamos que estoy cargando una página que busca a Larry Page. Ves que tengo mi primer Contentful Paint, lo primero que veo en la pantalla, y luego el Largest Contentful Paint llega poco después de eso. Hay muchos más ejemplos de esto en la página de WebDev también.

El siguiente es el primer retraso de entrada. Esto mide la cantidad de tiempo desde que un usuario interactúa por primera vez con la página. Ya sea haciendo clic en un enlace, haciendo clic en un botón o usando algún tipo de control personalizado impulsado por JavaScript. El tiempo entre cuando realmente hacen clic y cuando el navegador comienza a procesar esos controladores de eventos. Creo que todos hemos visto un mal ejemplo de esto. Haces clic en un elemento y no sucede nada cuando haces clic y te frustras y haces clic varias veces más, no es genial. Queremos apuntar a menos de 100 milisegundos, idealmente, para tener esos elementos interactivos. Para mostrar esta imagen, relacionando esto con FCP, sé que hay mucho sucediendo aquí. Entonces, a la izquierda, navegamos a una página esencialmente, y esto avanza de izquierda a derecha cronológicamente. Navegamos a una página, esa navegación comienza. Obtenemos algo de pintura en la pantalla, y nuestro navegador puede interpretar eso y entender eso. Y luego ves en el medio, hay un punto donde el navegador recibe esa primera entrada del usuario. Entonces, el tiempo entre ahí y cuando realmente puede responder es el primer retraso de entrada. La otra métrica en la parte superior es un resumen de todo esto, que es TTI, o tiempo de interacción.

El siguiente y último que vamos a hablar es el desplazamiento acumulativo del diseño o estabilidad visual. Estoy seguro de que has estado en un sitio web en algún lugar y estás leyendo algo y de repente el contenido cambia frente a ti. Hay algún tipo de cambio, tal vez pierdes tu lugar o haces clic accidentalmente en algo. Esto puede ser una experiencia realmente frustrante, y queremos apuntar a tener la menor cantidad de cambios de diseño posible en nuestros sitios web. Entonces, un ejemplo de esto, este es un ejemplo realmente malo. Estás tratando de retroceder, pero cambia en tu diseño y accidentalmente realizas tu pedido. Esta es una experiencia realmente frustrante.

No queremos esto. Esto es lo que queremos evitar. Una idea de cómo podrías reducir CLS sería, como en este ejemplo, mostrar el panel de Vercel. Te darás cuenta de que cuando se recarga, hay esqueletos de carga para todo el contenido. Y esto significa que el diseño no salta en absoluto cuando el contenido realmente termina de resolverse desde alguna API. Estas son las tres Core Web Vitals, LCP, FID y CLS.

Estas son herramientas que nos permitirán medir, comprender y luego mejorar algunos frameworks. Tienes el framework y luego necesitas encontrar este complemento o descargar esta otra cosa para hacer que algo que es bastante estándar en los sitios web funcione, pero tener todas esas cosas integradas, creo que hace que todo el proceso y el ciclo de desarrollo sea mucho más sencillo.

Has estado trabajando con Next.js durante bastante tiempo y has visto los productos, has visto cómo madura con el tiempo? ¿Ha habido alguna diferencia en la forma en que los desarrolladores lo utilizan o cosas que tal vez eran de cierta manera cuando Next.js recién comenzaba y ganaba popularidad, mientras que ahora más desarrolladores lo están adoptando? Sí, así que una cosa que quiero mencionar rápidamente y que me parece muy interesante, y luego responderé a eso, es la fragmentación de la instalación de paquetes npm, especialmente en el ecosistema de React, es en realidad una ventaja y una desventaja al mismo tiempo. Y por eso es tan difícil cuando hablas de esto con la gente, porque el hecho de que puedas instalar npm install react literalmente cualquier cosa, alguien ha construido un paquete, también es lo mejor y lo más confuso para los principiantes. Así que tener esa comunidad y ese ecosistema y también tener soluciones más orientadas es lo mejor de ambos mundos. Es un tema complicado, sin duda. Pero en respuesta a tu pregunta, ¿qué hemos cambiado con Next.js basado en el crecimiento? Bueno, creo que una de las cosas más importantes cuando hablaba de cómo comenzó como renderizado en el servidor, en ese momento comenzamos a darnos cuenta de que mucha gente quería construir HTML completamente estático con sus aplicaciones de React. Ya habían entendido el modelo mental de cómo construir una aplicación de React. Les gustaba construir componentes. Tenía sentido. Así que no querían tener que cambiar a una herramienta completamente diferente solo para construir algunas partes estáticas de sus sitios. Y lo que hicimos fue dar un paso atrás y miramos eso y dijimos, esto es genial. Y ahora queremos hacerlo aún más dinámico, donde podemos elegir a nivel de página cuáles se convierten en HTML estático y cuáles tienen algún tipo de dinamismo incorporado. Así que cuando lanzamos el soporte para sitios estáticos en Next.js, lo hicimos de manera que la opción de optar por ello o no está a nivel de página o de ruta. Eso tiene mucho sentido y poder extender ese caso de uso para otro conjunto de desarrolladores y hacerles la vida mucho más fácil. Definitivamente puedo decir que lo aprecio. Y hablando de cómo ha evolucionado Next.js, ¿qué viene a continuación? ¿Hay algo emocionante? Tal vez soy un fan de Next.js. ¿Hay algo emocionante que se avecina en el futuro? Sí. Sí, la próxima semana, el día 15, tendremos la segunda conferencia de Next.js. Y vamos a presentar algo realmente emocionante que podría cambiar la forma en que las personas desarrollan con Next.js. Me meteré en problemas si te doy un adelanto.