Principales Recomendaciones de Core Web Vitals para 2023

Hola a todos. Soy Barry. Esa fue una gran introducción, así que pasaré por alto eso y comenzaré directamente con la charla. Los sitios web lentos son terribles. ¿A quién le gustan los sitios web lentos? Raros. Y, como, hay muchos consejos de rendimiento web por ahí. Tal vez demasiados. Lo sé porque escribo mucho sobre eso. En primer lugar, tienes que averiguar qué tienes que medir. Nos encantan nuestras siglas de tres letras en el rendimiento web. Hay muchas de ellas, toneladas de ellas, y estamos agregando cada vez más continuamente. El tiempo de primera respuesta, por cierto, es una sigla de tres letras. La segunda T no cuenta realmente para nada, dos, ¿a quién le importa? Esto es algo abrumador para personas en particular que no son nerds del rendimiento web como yo. Creemos que hemos resuelto esto. Nosotros, siendo Google, hemos creado tres nuevas siglas de tres letras, los Core Web Vitals. ¿Quién ha oído hablar de los Core Web Vitals? Público mixto aquí. Bien. Estas son tres nuevas métricas que Chrome ha creado como una forma de medir la experiencia del usuario en sus sitios web. Y estas son formas en las que podemos medir cada uno de los sitios web. Entonces, tu propio sitio web puede tener tus propias métricas que deseas usar. Puede que desees ver conversiones, puede que desees ver tasas de rebote, puede que desees ver registros y ese tipo de cosas. Estas son más medidas generales que cualquier sitio web puede usar. Hay tres de ellas. El Pintado del Contenido más Grande, o LCP, mide el tiempo desde que haces clic en un enlace hasta el contenido más grande que hay en la página. Normalmente eso es una imagen de banner. Tal vez tu etiqueta H1 o algo así. El Desplazamiento de Diseño Acumulativo es mi favorito. Es cuando vas a un sitio y comienzas a leer y aparece un anuncio y la cosa se mueve hacia abajo, se mueve hacia los lados y no tienes ni idea y pierdes tu lugar y es realmente, realmente irritante. Tradicionalmente nunca lo medimos antes, así que es realmente interesante tener eso. Y FID, o Primero

Entonces, hicimos eso y creamos recomendaciones para cada una. Así que creamos tres recomendaciones para LCP, tres recomendaciones para CLS, ¿y adivina cuántas recomendaciones para FID? Cinco. No, tres. Así que tenemos tres de cada una. La charla fue de nueve recomendaciones, vamos.

Entonces, empecemos. Recomendaciones para LCP, la primera recomendación y es especialmente relevante para los desarrolladores de JavaScript. Asegúrate de que los recursos de LCP sean descubribles para el HTML. Y para hacer eso, como dije, si observas los recursos de LCP, en su mayoría es una imagen de banner, tal vez una etiqueta H1. El 70% de los sitios web, dependiendo de si estás viendo en móvil o escritorio, es una imagen. Entonces, una imagen tiene un retraso inherente porque tienes que descargar tu HTML. Tienes que analizar ese HTML. Vas a decir, hey, tiene una imagen. Probablemente sea otro recurso. Tienes que obtenerlo. Tenemos que mostrarlo. Todo dentro de esos 2.5 segundos. Entonces, para hacer eso, vamos a hablar un poco sobre cómo el navegador realmente lo hace. El HTML se analiza línea por línea. Esta es una cita de un amigo mío, Harry Roberts, un consultor de rendimiento web. Por cierto, él tiene una gran charla sobre esto. Así que, si esto te gusta un poco, echa un vistazo a su charla en YouTube. Compartiré

Esto no es tu contenido, esto le dice al navegador. Es toda la información para el navegador sobre qué hacer. Tu conjunto de caracteres, quieres que esté cerca de la parte superior. Esto indica en qué código, qué conjunto de caracteres está realmente escrito el código. Si el navegador no tiene esto cerca de la parte superior y ya ha procesado algo y obtiene un conjunto de caracteres diferente al que esperaba, tiene que reiniciar porque piensa: `Oh, tal vez leí eso mal`. Así que ponlo cerca de la parte superior. Tu vista previa, esto es todo bastante estándar. Por cierto, aquellos de ustedes que no usan esta vista previa y deshabilitan el zoom, vengan y hablen conmigo después. Quiero saber por qué. Porque tengo estos ojos malos y me encanta hacer zoom. Así que esta es probablemente la que deberías usar a menos que tengas una muy buena razón. Y obtienes tus títulos. Ahora puedes poner el título de la página en tu pestaña. Esa es la primera retroalimentación visual para el usuario de que algo está sucediendo. Voy a omitir estos

Siguiendo adelante, nuestras recomendaciones para CLS. Como dije, CLS es cuando todo se mueve y es realmente molesto. La razón por la que se mueve es porque en realidad no hemos dejado espacio para eso. Sabemos que vamos a cargar algo ahí. Y tradicionalmente, hablamos de imágenes. Así que nuevamente, esto es para los desarrolladores de JavaScript en la sala. Colocas el ancho y alto en las imágenes, por ejemplo. Una imagen sin ancho y alto, el navegador dirá inteligentemente, esto probablemente es de cero píxeles de alto, cero píxeles de ancho, buena suposición ahí. Y si la cargas, tendrás algo de texto ahí. Cuando la imagen se carga, todo se mueve hacia abajo. Realmente, realmente molesto. Si tienes ese ancho y alto, el navegador dirá, ah, vale, voy a dejar un poco de espacio aquí, sé cuál es el tamaño. Incluso si tienes CSS que dice ancho máximo, lo utilizará para calcular lo que llamamos la relación de aspecto y reservará la altura adecuada. Muy simple, solo asegúrate de que todas tus imágenes tengan ancho y alto. Pero no solo se aplica a las imágenes. Los anuncios son otro factor importante. Entonces, nuevamente, los anuncios a menudo se cargan tarde. Puedes poner una altura mínima y dejar algo de espacio. Incluso si tienes diferentes anuncios para diferentes personas,

IE, el tiempo de bloqueo, antes de que comience a ejecutarse. Y solo para la primera interacción. Eso fue una forma fácil de decir, ¿verdad, tarda mucho tiempo cada vez que una persona hace clic antes de que realmente haga algo? IMP, sin embargo, mide toda la interacción completa. Y mide todas las interacciones y te da la peor como puntuación para tu página. Y eso no significa que toda tu interacción tenga que terminar. Solo tienes que dar una pintura. Entonces, siempre y cuando no estés bloqueando ese hilo principal todo el tiempo. Entonces, si estás ahí sentado haciendo una búsqueda en la red, no te preocupes, siempre y cuando permitas que el navegador se actualice si hacemos clic en otra cosa o si pones un punto, punto, punto de carga en él. Siempre y cuando le des al navegador esa oportunidad de hacerlo, no te penalizaremos por todo el tiempo. Reconocemos que algunas cosas son más lentas de ejecutar que otras. Pero lo que debes hacer es no detener todo el navegador, bloquearlo por completo, para evitar que realmente haga algo. Puedes pensar en IMP en estas fases. El retraso de entrada que es lo que mide FID, tu tiempo de procesamiento, ese es el que probablemente has pensado más, ese es tu código o el código de tu framework en el que estás trabajando, y luego el retraso de presentación. Entonces, vamos a hablar de algunas de estas cosas. Las primeras dos partes son para mejorar tu JavaScript, la última parte es

Lo siguiente, y probablemente esté en la sala equivocada para esto, pero evita JavaScript innecesario. Porque nuestra historia de amor con JavaScript no tiene límites. Estamos agregando más de ese material en nuestras páginas. Pero debes mirar y ver, ¿lo necesitamos? Y en particular, ¿lo necesitamos siempre de inmediato? Hay un gran debate en este momento con las SPAs. ¿Vale la pena esa gran demora hasta que llegue y todo funcione muy rápido? ¿O deberíamos cargar lo mínimo necesario para dibujar la pantalla y luego cargar de forma diferida el resto del contenido a medida que las personas se desplazan, interactúan o utilizando un servicio donde pueda intentar obtenerlo de manera proactiva, precargarlo en segundo plano? Así que echa un vistazo a tu código. ¿Qué puedes dividir? ¿Qué puedes cargar más tarde? ¿Qué puedes hacer? Ese tipo de cosas. Y no solo mires tu código. Google Tag Manager es otro gran problema que acumula muchas cosas. Muchos desarrolladores piensan, bueno, eso es marketing. No me importa eso. El marketing se encargará de eso. Míralo. Observa eso. Pregúntales por qué todavía tienen esa etiqueta de su promoción de verano de 2000. ¿Realmente la necesitan ahora en 2023? Haz que eliminen cosas. Porque incluso si no se activa en ninguna página, sigue siendo un gran bloque. Y cuando lo pones en Lighthouse, está ahí diciendo, ¡vaya! Google Tag Manager es lo peor de tu página. Así que límpialo y échale un vistazo. De manera similar con otro contenido de terceros. Si tienes widgets de chat o vídeos incrustados, diferir su carga o utilizar módulos que se diferirán por naturaleza. Cualquier widget social que comparta esta cosa, a menudo son bastante pesados en JavaScript. Solo son un simple botón, piensas, pero son bastante pesados. Están al final de la página. No necesitas cargarlos en la parte superior. Los iframes son muy fáciles de cargar de forma diferida. Y, ya sabes, si tienes muchos vídeos de YouTube y todos están fuera de la pantalla, cárgalos de forma diferida y el navegador los obtendrá justo antes de que aparezcan en la pantalla. Las fachadas son otra cosa, especialmente para cosas de vídeo como YouTube, donde puedes sentarte allí y mostrará la imagen, pero no descargará el reproductor de vídeo grande y pesado hasta que el usuario realmente haga clic en reproducir. Porque si no van a hacer clic en reproducir, no tiene sentido traerlo abajo. Y por último, evita las actualizaciones de renderizado grandes. Así que mira lo que ofrece tu framework aquí.

Hay mucho sobre renderizado concurrente, usando suspense y React y separando las partes en lugar de decir, esta aplicación completa tiene que renderizarse de una vez o nada, no me importa. Quieres dividirlo y decir, esta parte está lista, renderízala, esta parte no, está bien, solo muestra este pequeño fragmento de texto y continúa. Hay mucho sobre capacidad de recursos y hidratación no destructiva. Si estás haciendo mucho trabajo en el renderizado del lado del servidor, enviarlo en un objeto JSON y luego hacer que el navegador lo vuelva a renderizar todo es bastante costoso y un poco inútil, así que echa un vistazo y ve qué ofrece tu framework allí.

Mantén pequeños los tamaños de tu DOM, eso honestamente es lo más fácil que puedes hacer, porque si estás actualizando, mucho del framework de JavaScript volverá a renderizar todo el DOM, así que nuevamente, si es grande, eso llevará mucho tiempo. Si lo mantienes pequeño, no importa si hace eso. La contención de CSS es un poco más avanzada, puedes decir, esta parte de la página no se ve afectada por esta parte de la página, está bien, si eso cambia, no te preocupes por volver a dibujar así. Y requestAnimationFrame es una API que se ejecuta en cada fotograma de animación, si pones un trabajo grande y pesado allí, se ejecutará en cada fotograma de animación, así que nunca uses eso, solo úsalo para cosas críticas que necesitan ejecutarse justo antes de ser animadas. Y eso es prácticamente todo, esas son nuestras nueve principales recomendaciones. Hemos escrito una publicación en el blog al respecto, con muchos más detalles y enlaces, así que léelo. Y con eso, muchas gracias, si tienes alguna pregunta, avísame.