1. Introducción a Core Web Vitals
Hola a todos. Soy Barry. Los sitios web lentos son terribles. Hay muchos consejos de rendimiento web por ahí. En primer lugar, tienes que averiguar qué tienes que medir. Creemos que hemos resuelto esto. Nosotros, siendo Google, hemos creado tres nuevas siglas de tres letras, los Core Web Vitals. Estas son tres nuevas métricas que Chrome ha creado para medir la experiencia del usuario en sus sitios web.
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
2. Mejorando el rendimiento web
Entonces, cuando haces clic en un menú y no se abre, y vuelves a hacer clic, y luego de repente registra ambos y se abre y se cierra muy rápidamente y es realmente molesto. Además de crear las métricas, hemos establecido límites recomendados para cada una de ellas. Si estás por debajo de 2.5 segundos para LCP, decimos que está bien. Si estás por encima de 4 segundos, decimos que es pobre. Y en cualquier punto intermedio, está bien. Acabamos de anunciar que FID será reemplazado muy pronto por IMP, una nueva métrica que afecta particularmente a las personas que trabajan con JavaScript. Ahora sabemos qué medir. Te hemos dado pequeñas cosas agradables que creemos que deberías medir allí. La pregunta entonces es cómo utilizar eso para mejorar el rendimiento web. Queremos responder a esta pregunta. Queremos dar una lista más simple y más pequeña y decirte estas son las cosas que debes mirar primero. Queremos enfocarnos especialmente en recomendaciones que creemos tienen el mayor impacto en el mundo real. Queremos analizar recomendaciones que sean relevantes y aplicables a la mayoría de los sitios web.
El Retraso de Entrada, se supone que es la métrica de capacidad de respuesta. Entonces, cuando haces clic en un menú y no se abre, y vuelves a hacer clic, y luego de repente registra ambos y se abre y se cierra muy rápidamente y es realmente molesto. Así que medimos eso. Además de crear las métricas, hemos establecido límites recomendados para cada una de ellas. Si estás por debajo de 2.5 segundos para LCP, decimos que está bien. Si estás por encima de 4 segundos, decimos que es pobre. Y en cualquier punto intermedio, está bien. Una cosa a tener en cuenta es que acabamos de anunciar que FID será reemplazado muy pronto por IMP, una nueva métrica de la que hablaremos un poco más tarde porque afecta particularmente a las personas que trabajan con
JavaScript y creo que podría haber algunas en la sala en este momento. Así que volveremos a eso. De acuerdo. Ahora sabemos qué medir. Te hemos dado pequeñas cosas agradables que creemos que deberías medir allí. La pregunta entonces es cómo utilizar eso para mejorar el rendimiento web. Tenemos muchas herramientas, puedes usar Lighthouse, ejecutará 53 auditorías de rendimiento y te dirá qué puedes hacer. Yellow Lab Tool es otra gran herramienta, te dará 38 pequeñas comprobaciones y te dará una marca de verificación verde o una cruz roja y te dirá qué cosas debes mirar. Web Page Test, para aquellos que han realizado algún análisis de cascada, es fantástico. Son 16 páginas de estadísticas. Y el Panel de Rendimiento de Chrome Dev Tools, si alguno de ustedes lo ha explorado, digamos que hay mucha información detallada allí y pido disculpas a algunos de los miembros del equipo de Dev Tools que veo allí. Así que, volvemos a lo mismo, es un poco abrumador nuevamente. Queremos responder a esta pregunta. Pasé mucho tiempo el año pasado analizando esta pregunta. ¿Cuáles son las recomendaciones más importantes que podemos dar a los desarrolladores para ayudarlos a mejorar el rendimiento para sus usuarios? En lugar de decirte en Lighthouse, estas son 53 cosas que podrías mejorar, pero ¿realmente moverá la métrica o no? Queremos dar una lista más simple y más pequeña y decirte estas son las cosas que debes mirar primero. Especialmente si eres nuevo en el rendimiento web, si aún no lo has mirado, mira estas cosas primero y luego vuelve a mirar el resto. Queremos enfocarnos especialmente en recomendaciones que creemos tienen el mayor impacto en el mundo real. afectar ni un segundo a tu sitio web. Te vas a molestar y dirás, bueno, sí, tal vez técnicamente sea la mejor práctica hacer esto, pero me llevó seis meses y realmente no hizo nada. Muchas gracias. Así que estamos mirando cosas aquí que realmente creemos que tendrán un impacto. Queremos Así que vamos a decirte que hagas esto y vas a pasar mucho tiempo implementándolo y no va a analizar recomendaciones que sean relevantes y aplicables a la mayoría de los sitios web. Así que habrá muchas charlas aquí en esta conferencia sobre
React o Solid JS o lo que sea. Es muy específico para esos casos o si estás en otra conferencia, sobre
WordPress o lo que sea. Así que estamos mirando cosas más generales aquí que todos los sitios web deberían considerar.
3. Recomendaciones de rendimiento web
Existen recomendaciones de rendimiento web que son realistas para que la mayoría de los desarrolladores las implementen. Hemos creado tres recomendaciones para LCP, tres recomendaciones para CLS y tres recomendaciones para FID. Para LCP, la primera recomendación es asegurarse de que los recursos de LCP sean descubribles para el HTML. Esto implica comprender cómo el navegador analiza el HTML línea por línea.
y echar un vistazo. Y queremos analizar recomendaciones que sean realistas para que la mayoría de los desarrolladores las implementen. Así que hay muchas cosas complicadas de rendimiento web. Por ejemplo, la inclusión de
CSS tiene grandes oportunidades de rendimiento. Pero es un poco complicado hacerlo bien. Muchas personas lo hacen mal. Muchas personas lo arruinan y luego no se carga correctamente. Así que estamos tratando de analizar algunas cosas que, ya sabes, si te decimos que hagas esto, la mayoría de las personas realmente podrán hacerlo si quieren.
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é
4. Análisis HTML y metadatos
Hay un código QR para que lo consultes. No es línea por línea, es byte por byte, fragmento por fragmento, símbolo por símbolo. El analizador HTML se encarga de convertir tu código en una hermosa publicación de blog. Recorre el código línea por línea, comenzando con HTML y estableciendo el idioma para la accesibilidad. La cabecera contiene metadatos.
las diapositivas después, por cierto. Hay un código QR para que lo consultes. Donde profundiza en ello con mucho más detalle. Solo voy a tocar la superficie de esto. Tampoco es estrictamente cierto, así que no le digas esto a Harry. No es línea por línea. Es byte por byte, fragmento por fragmento, de cualquier manera que lo hagas. Es símbolo por símbolo. Pero es lo suficientemente cercano. Entonces, tenemos la parte estándar de
HTML. Esto en realidad es de un artículo de web.dev en el que ayudé a mantener. Bastante estándar. He recortado un poco para que quepa en el lado. Y tu navegador va a tomar esto y va a tomar todo este código y convertirlo en una hermosa publicación de blog. Y el proceso encargado de eso es este tipo, el analizador
HTML, me gusta llamarlo el perro grande, el jefe. Se asegurará de que se haga. Él es un poco viejo. Ha estado aquí por un tiempo, al igual que yo. Sus ojos no miran realmente tan lejos, al igual que yo. Pero es un trabajador incansable. Él pasará por ese código y se asegurará de que tu
HTML se convierta en esa hermosa publicación de blog. Y comenzará a recorrerlo línea por línea. Así que comienza,
HTML, genial, eso es en lo que es bueno. Buen comienzo, fantástico. Idioma, siempre establece tu idioma. Genial para la accesibilidad. Y para aquellos que no saben o no les importa la accesibilidad, la forma más fácil de explicarlo es si visitas un sitio web en francés y dice: `¡Hey, hablas inglés, ¿quieres traducir al inglés?`. Eso es porque establecieron el idioma correctamente. Y el navegador sabe que eres inglés, la página web dice que es francés, se traduce automáticamente. Etiqueta simple, hazlo. Luego llega a la cabecera. La cabecera es un poco tus metadatos.
5. HTML Meta Tags and Browser Instructions
Esta sección explica la importancia de establecer el conjunto de caracteres y la vista previa cerca de la parte superior de tu código. También enfatiza el uso de títulos para proporcionar retroalimentación visual al usuario.
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
6. JavaScript and Preload Scanner
Luego llegas a JavaScript. Llama a su compañero, el motor V8, para procesarlo. El cachorro emocionado, un escáner de precarga, busca recursos por adelantado, lo que hace que los sitios web sean más rápidos. No poner recursos para que el cachorro juegue ralentiza tu sitio web.
los siguientes tres. Prometo que volveré a ellos. Luego llegas a
JavaScript. En este punto, ese gran perro se detiene y dice: No sé nada sobre
JavaScript. Llama a su compañero, el motor V8, del que aprendimos en la última charla. Viene, lo procesa. El gran perro vuelve a su caseta, se sienta, agarra un hueso y comienza a roer, dice que volveré a eso más tarde. Después de que ese proceso haga lo que necesite hacer. ¡Oye! Gran perro, vuelve, veo que tengo algo de
CSS. Oh, red, ¿puedes traerme algo de
CSS? Va y obtiene algo de
CSS. Oh, y necesito más. En fin. El punto es que está pasando por eso línea por línea. Y a menudo puede detenerse debido a cosas como
JavaScript esperando recursos de red. Eso puede hacer que los sitios web sean increíblemente lentos. Y como, los sitios web se dan cuenta de esto, Microsoft se dio cuenta de esto primero. Hace unos diez años, se le ocurrió una mejor manera de hacer que fue este tipo. Entonces, si el último tipo era un gran perro. Esto es lo que me gusta llamar el cachorro emocionado. Es un escáner de precarga. Lo que hará es, mientras el gran perro está haciendo el trabajo principal, recorrerá rápidamente y encontrará todos los recursos que necesita y comenzará a buscarlos por adelantado. Y eso lo hace mucho más rápido. Entonces, cada vez que el gran perro llega allí, todo ya está buscado. No sabe cómo analizar el
HTML,
JavaScript, y todo lo que necesitas hacer es buscar rápidamente. Solo lo recorrerá como un pequeño cachorro emocionado. Si le lanzas una pelota, irá a buscarla muy rápidamente. Y eso hace que los sitios web sean realmente rápidos, y puedes ver esto. Si alguna vez ejecutas un waterfall, esto es de WebpageTest. Obtenemos el documento
HTML azul, y luego boom, inmediatamente solicitamos cinco recursos aquí que ya ha encontrado que necesita buscar. Entonces, si no estás poniendo esos recursos allí, entonces estás dificultando mucho eso. Entonces, si no estás obteniendo nada para que juegue este perrito, entonces estás ralentizando tu sitio web. Mi colega Jeremy escribió este artículo fantástico, No luches contra el navegador
7. Fighting the Browser Preload Scanner
Si quieres luchar contra el escáner de precarga del navegador, asegúrate de darle algo para buscar. Utiliza indicadores de recursos para precargar fuentes necesarias y preconectar CDN de imágenes. No luches contra el escáner de precarga, haz que los recursos sean descubribles. Pon más contenido en tu HTML y renderiza en el lado del servidor para mejorar el rendimiento.
Escáner de Precarga. Me encanta el título de esto, por cierto, porque podrías pensar, bueno, ¿cómo lucharía contra el escáner de precarga del navegador? Así es como lo harías. Si esto es todo lo que tienes, ese pequeño app.js, y no hay nada más en tu
HTML hasta que descargues ese app.js, que probablemente tenga varios megabytes de tamaño, analízalo, compílalo y solo entonces comienza a inyectar cosas allí, básicamente no le has dado nada a ese perrito para que juegue con él. No le has dado nada para buscar. Pero, ¿por qué harías eso? Mira su cara. Vamos, le encanta buscar cosas. Así que dale algo que hacer allí. Ahora, es posible que te preguntes, ¿qué pasa si necesito ejecutar
JavaScript para, digamos, contenido personalizado, es una aplicación de fotos y quiero mostrar tus fotos, no las de otra persona. Eso es bastante justo. Entonces, volveremos a estas tres líneas, a las que te dije que volvería. Estos son indicadores de recursos que puedes poner allí y decir, precarga estos. Vas a necesitar estas dos fuentes. No tengo idea de qué vas a mostrar en este texto hasta que ejecute mi
JavaScript o más tarde. Pero confía en mí, vas a necesitar las fuentes, vas a mostrar algo. O web.dev utiliza un CDN de imágenes. Así que estamos diciendo, preconecta este CDN de imágenes. Nuevamente, no sé qué imagen vas a descargar en realidad. Pero es probable que descargues una imagen en la mayoría de los artículos en algún momento. Así que puedes ir allí. Y nuevamente, le da al pequeño perrito algo con qué jugar. Así que no luches contra el escáner de precarga. Haz que los recursos sean descubribles. Y eso es honestamente una de las cosas más importantes que nosotros, los desarrolladores de
JavaScript, hacemos muy mal. Así que pon más contenido en
HTML. Renderiza en el lado del servidor. Dale eso pequeño
8. Prioritizando los recursos LCP
Asegúrate de priorizar el recurso LCP. Los navegadores no priorizan las imágenes inicialmente. Primero obtienen los recursos que bloquean el renderizado, como CSS y JavaScript síncrono. Solo entonces obtienen el contenido en pantalla, como imágenes y videos. Este retraso en la obtención de imágenes puede ser molesto, especialmente para las imágenes LCP que son cruciales. La precarga de imágenes no resuelve completamente este problema porque el navegador aún sabe que es una imagen.
algo con qué jugar al cachorro. Continuando. Asegúrate de priorizar el recurso LCP. Entonces, dijimos anteriormente que los recursos LCP son un 70% imágenes. Voy a revelarte un pequeño secreto sucio aquí, los navegadores no priorizan las imágenes. Al menos inicialmente. No les importa en absoluto. Los navegadores obtienen recursos en varios pasos. En primer lugar, obtienen los recursos que bloquean el renderizado. Por lo tanto, el
CSS está ahí, cualquier
JavaScript síncrono que se ejecute... No puedo ni siquiera comenzar a dibujar la página hasta que haga esto. Y solo entonces obtiene el contenido en pantalla. Tus imágenes, tus
video, o cualquier cosa así. Por eso a menudo ves que las páginas se dibujan. Hay un gran espacio en blanco donde debería estar la imagen, y luego la imagen comienza a aparecer allí, porque no se detiene ese dibujo inicial hasta que obtiene la imagen. Y finalmente obtiene el contenido fuera de pantalla. Mucho contenido. Se habla mucho sobre la carga perezosa. Pero solo lo hago un poco, y ellos descubren qué está en pantalla, dicen, obténme esto muy rápido, y luego nos preocuparemos por el resto y lo obtendremos más tarde. Entonces, las imágenes no bloquean el renderizado. No pueden estar en esa primera etapa. Siempre se retrasarán un poco. Y decimos que las imágenes LCP son tu contenido más importante que queremos mostrar rápidamente al usuario. Entonces el hecho de que no se vaya a obtener hasta dentro de un rato es un poco molesto. Y sé que algunos de ustedes podrían decir, hey, acabamos de escuchar a este tipo muy inteligente llamado Barry Pollard, así que sabemos cómo solucionar esto. Lo que haremos es simplemente precargar la imagen allí. Eso... Él nos lo dijo. Nos dice cómo solucionar las cosas correctamente. Esto en realidad no funciona tan bien como la gente piensa porque el navegador aún sabe
9. Usando la API de Prioridad de Fetch
Existe una nueva API llamada API de prioridad de Fetch, anteriormente conocida como una pista de prioridad. Al agregar un atributo HTML, puedes indicarle al navegador que priorice las imágenes importantes. eBay vio una mejora de 150 milisegundos en LCP al utilizar esta técnica.
es una imagen. Tengo... Oh, mira eso, mi pequeño y elegante controlador. De hecho, se lo hemos dicho, esto es una imagen, trátala como una imagen. Así que va imagen, yo sé de ella. La obtendré más tarde. Primero voy a ocuparme de cosas más importantes. Así que ayuda un poco que la descubra antes, pero aún no la obtiene en esa primera fase. Aún dice que voy a obtener las cosas más importantes primero y solo me ocuparé de esto cuando lo obtenga más tarde. Así que eso no nos ayuda de la manera en que pensamos. Pero hay una nueva API que sí lo hace, se llama API de prioridad de Fetch. Solía ser conocida como una pista de prioridad. Y esta es una API de
JavaScript realmente complicada. Así que te mostraré algo de código en la siguiente página. No te preocupes por ello, no te confundas. Lo vamos a analizar y lo explicaré. Porque para usar esto y decirle al navegador que esta imagen es importante, tienes que hacer esto. Eso es todo. Un atributo
HTML. ¿Alguien aquí sabe
HTML? Vamos, una persona. Así que, te voy a mostrar. No, pero agregas un atributo
HTML a esto. Esto le dice al navegador que no me importa lo que normalmente haces. Esto es importante para mí. Aceléralo, obténlo primero y obténlo porque es importante. Y un representante de eBay dijo, agregamos pistas de prioridad, tuiteamos esto a finales del año pasado. La imagen principal en la página del artículo y vimos una mejora en LCP de 150 milisegundos en Chrome. Fácilmente una de las mejoras de velocidad más sencillas para nosotros, realmente un cambio de una sola línea. Ahora, es posible que estés pensando, ¿150 milisegundos? ¿A quién le importa? Vamos. Pero créeme, eBay es bastante rápido en realidad. Así que para ellos cualquier mejora de rendimiento es importante.
10. Usando la API de Prioridad de Fetch
Para ellos hacerlo con solo un cambio de código de una línea es fantástico. Utiliza la prioridad de fetch para informar al navegador sobre las imágenes importantes, pero no abuses de ello. Úsalo en una, dos, tal vez tres imágenes como máximo.
es bastante bueno. Para ellos obtener 150 milisegundos es brillante. Para ellos hacerlo con solo un cambio de código de una línea es fantástico. Una palabra de advertencia, cada vez que aumentamos explícitamente la prioridad de un recurso, implícitamente disminuimos la prioridad de otro. Es una cita de otro amigo mío, Andy Davis, otro experto en formatos web. Así que no lo apliques a todo. Utiliza la prioridad de fetch para informar al navegador sobre las imágenes importantes, pero no abuses de ello. Si lo aplicas a cada imagen, básicamente estás diciendo que ninguna de ellas es más importante que el resto, todas son importantes y probablemente más importantes que ese
CSS que bloquea el renderizado y cosas así. No abuses de ello. Úsalo en una, dos, tal vez
11. Optimizando Documento y CLS
Por último, utiliza CDNs para optimizar el documento y el TTFP de los recursos. Tener un CDN significa que tu documento se copia en muchos lugares alrededor del mundo, lo que hace que regrese más rápido. Para CLS, asegúrate de que las imágenes tengan atributos de ancho y alto para evitar cambios de posición. Los anuncios también pueden causar cambios de posición, así que utiliza una altura mínima para dejar espacio.
tres imágenes como máximo. Por último, utiliza CDNs para optimizar el documento y el TTFP de los recursos. Hasta que obtengas ese
HTML en la parte superior, no puedes comenzar con el resto de la cascada. No puedes obtener nada. Así que el documento es lo más importante que realmente puedes obtener. Y utilizamos CDNs mucho, pero generalmente no tendemos a utilizarlos para el documento. A menudo los utilizamos para CDNs de imágenes o CDNs de
JavaScript, donde obtenemos el
JavaScript allí. Tendemos a no utilizarlos tanto para documentos. Y ahí es honestamente donde puedes obtener la mayor ventaja. Así que tener un CDN significa que tu documento se copia en muchos lugares alrededor del mundo, regresará más rápido. Incluso si tiene que volver a tu servidor para hacer alguna búsqueda y obtener contenido personalizado, es mucho más rápido hacerlo desde un CDN que hacerlo desde el navegador real. Así que echa un vistazo a eso.
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,
12. Optimizando Min-Height y Back Forward Cache
Créeme, no va a ser cero píxeles. Así que ponle un min-height de al menos 50 píxeles, al menos lo has reducido. De manera similar, si estás usando un archivo app.js y es un div vacío para ver eso, no lo hagas. Ponle un min-height. Sé elegible para la caché BF. La caché BF, o caché de retroceso y avance, es algo muy interesante que hacen los navegadores. Incluso si estás almacenando en caché todos los recursos en el navegador, aún lleva un tiempo para que JavaScript se ejecute y para que se muestre la página y haga algo. Mostramos que aproximadamente el 10% de las páginas en escritorio y el 20% en dispositivos móviles son en realidad navegaciones de retroceso y avance. Hay mucho que ganar con esto.
podría ser de 50 píxeles, podría ser de 75 píxeles, dependiendo del anuncio mostrado. Créeme, no va a ser cero píxeles. Así que ponle un min-height de al menos 50 píxeles, al menos lo has reducido. Todavía es un poco molesto, pero no hacer eso. De manera similar, si estás usando un archivo app.js y es un div vacío para ver eso, no lo hagas. La cantidad de sitios en los que veo que el pie de página está ahí, empujando el encabezado y diciendo, eh, déjame entrar ahí. Luego la app se carga y mueve todo hacia abajo. Sabes que la app va a tardar un poco de tiempo. Ponle un min-height. Es muy fácil. Reserva algo de espacio, menos brusco para el usuario al moverse. Sé elegible para la caché BF. Entonces, la caché BF, o caché de retroceso y avance, es algo muy interesante que hacen los navegadores. Chrome llegó muy tarde, lo lanzamos hace aproximadamente un año y medio. Pero lo que hace es que cuando vas a una página, digamos que vas a buscar en Google, haces clic en un resultado de búsqueda, vas allí, y dices, ese no es el que quiero, haces clic en retroceso. Puedes hacer una nueva búsqueda y puede llevar unos segundos. O lo que hará el navegador es mantener una copia de esa página en memoria durante unos minutos después de que te hayas ido y decir, si vuelves, boom, ahí lo tienes, instantáneo. Porque mejor que cargar rápido es cargar al instante. Así que vamos a ver un
video aquí, si funciona el Wi-Fi. Comenzamos en TechCrunch, a la izquierda, tenemos un navegador con caché de retroceso y avance, y a la derecha, vamos a BBC, tarda un poco en cargar. Si retrocedemos, puedes ver que a la izquierda es instantáneo. Si decimos, oh, en realidad olvidé recoger algo de ese artículo que estoy a punto de leer. Entonces, si avanzas de nuevo, nuevamente, al instante a la izquierda, y tarda un poco de tiempo. Así que incluso si estás almacenando en caché todos los recursos en el navegador, aún lleva un tiempo para que
JavaScript se ejecute y para que se muestre la página y haga algo. Mostramos que aproximadamente el 10% de las páginas en escritorio y el 20% en dispositivos móviles son en realidad navegaciones de retroceso y avance. Nuevamente, hay muchos ejemplos de esto, cuando estás comprando calcetines en Amazon, dices, oh no, no me gustan esos calcetines negros simples. Haz clic en ese en su lugar. Así que hay muchos artículos de periódico de retroceso cuando los estás mirando. Retrocedes y avanzas, y los estás mirando, y haces eso. Así que hay mucho que ganar con esto. Y
13. Optimizando rendimiento y métricas
Escribí un artículo sobre el impacto en el rendimiento de renunciar al rendimiento web gratuito para los usuarios. Hay APIs que pueden desactivar la caché de retroceso y avance, y el uso de controladores de descarga también puede detenerla. Evita las animaciones que utilizan propiedades CSS que inducen al diseño, ya que consumen muchos recursos del navegador. En su lugar, utiliza transform, que requiere menos trabajo para el navegador y no se cuenta en CLS. Hemos introducido una nueva métrica llamada Interacciones Next Paint para reemplazar FADE y medir sitios web más rápidos.
si puedo ser tan audaz como para citar a una persona muy inteligente, yo mismo. Sobre esto, escribí un artículo antes de unirme a Google sobre cómo pensaba que esto era un cambio de juego en el rendimiento y siempre dije que los sitios que renuncian al rendimiento web gratuito para los usuarios, al no hacer esto, se están dificultando innecesariamente con los títulos principales de la web. Porque obtienes esto de forma gratuita, pero hay un par de APIs que puedes usar para desactivar esta caché de retroceso y avance, porque el navegador piensa que no está seguro de si es seguro restaurar esta página. Entonces, si usas control de caché no almacenar o si usas controladores de descarga en escritorio, entonces se detiene. Hay una prueba muy fácil en
DevTools en Chrome. Ve a la pestaña de aplicaciones, ve a la caché de retroceso y avance. Hay un gran botón azul invitador. Carga tu página, presiona eso, irá hacia adelante, a una página aleatoria sobre .chrome o algo así, y volverá, y luego te dirá si eso funciona, y si no funcionó, aquí está CNN, te dirá por qué. Estos son controladores de descarga, y puedes ver si realmente valen la pena los beneficios. Y por último, evita las animaciones que utilizan propiedades
CSS que inducen al diseño. Esto es un poco extraño, porque no estoy completamente seguro de que lo estemos haciendo bien, pero es lo que estamos haciendo en este momento. Así que mira esta animación elegante. Nos encantan las animaciones, nos encanta incorporarlas y cosas así. Pero si estás usando top, left, right, bottom, y estás moviendo cosas con eso en
CSS, eso en realidad consume muchos recursos del navegador. Deben volver a calcular todo y deben mirar y enviar y desplazar, y luego averiguarlo y volver a dibujarlo. Eso incluso si lo mueves a su propia capa, su propio índice Z, y está completamente separado de la página. Aún así, tendrá que hacer esas cosas y hacer eso. Y estos dos fragmentos de código son, serán idénticos para el usuario, pero el de la derecha utiliza transform. Eso ocurre en la capa del compositor, después de que ocurren todas las capas, simplemente hacemos un pequeño truco justo al final justo antes de llegar a la pantalla. Mucho menos trabajo para el navegador, y además no se cuenta en CLS, porque las cosas de CLS ocurren antes que esto. El efecto neto para el usuario es casi el mismo, así que tal vez CLS no debería medirlo, pero hay muchas otras buenas razones por las que estamos haciendo esto. Entonces, si estás ahí sentado y tienes un banner de cookies que aparece, asegúrate de hacerlo con transform, no con top left, porque de lo contrario estarás siendo afectado innecesariamente por ese CLS. Entonces, FADE, como digo, haces clic en un botón, ¿cuánto tiempo pasa hasta que se ejecuta el carrito de
JavaScript? Muchos sitios web pasan esto. No es una medida realmente buena, y eso no significa que solo lo estemos dificultando más, porque ¿podemos decir honestamente que muchos sitios web son rápidos para, ya sabes, interactuar de inmediato y hacer eso y cosas así. No. Entonces, hemos introducido esta nueva métrica el año pasado, Interacciones Next Paint, y en Google IOO a principios de este mes anunciamos que esto reemplazará a FADE el próximo año. Entonces, hay algunos beneficios de clasificación en las búsquedas al tener sitios web más rápidos. Esto será lo que usaremos para medirlo. Entonces, FADE, básicamente, si comienzas a hacer clic en un botón, tienes algún tiempo de bloqueo antes de que suceda algo. Luego tienes la interacción, tu código de
JavaScript se ejecuta, y luego tienes que pintar los resultados de esa ejecución de
JavaScript. FADE mide esta parte.
14. Measuring Interaction and Improving Performance
IE mide el tiempo de bloqueo antes de la primera interacción, mientras que IMP mide la interacción completa para todas las interacciones. Da una puntuación basada en la peor. Siempre y cuando no bloquees el hilo principal, no serás penalizado. IMP tiene tres fases: retraso de entrada, tiempo de procesamiento y retraso de presentación. Discutiremos cómo mejorar JavaScript y el rendimiento de renderizado.
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
15. Optimización del rendimiento de JavaScript
Evita o divide las tareas largas en JavaScript utilizando el método set timeout para darle un descanso al navegador y manejar otros eventos importantes. Busca oportunidades para utilizar puntos de interrupción en tu código y explora las APIs de JavaScript, como set timeout, para optimizar el rendimiento.
tipo de mejora de tu renderizado. Entonces, lo más fácil es evitar o dividir las tareas largas. Una vez más, un gran agradecimiento a Jeremy, quien ha escrito otro documento fantástico sobre esto, tiene muchos documentos en web.dev sobre cómo hacerlo.
JavaScript es codicioso por naturaleza. Tenemos esta función, estamos bastante contentos con ella, la hemos modularizado, tenemos cinco pequeñas subfunciones y es genial para nosotros, nuestro código está escrito de la manera que nos gusta.
JavaScript se aferrará a ese hilo principal y ejecutará cada una de ellas. Entonces, aunque tenemos cinco funciones aquí, simplemente las hará una tras otra. En cierto sentido, no es diferente haberlas escrito como una gran función. Entonces, lo que debes hacer es decirle al navegador, bien, está bien, toma un descanso ahora. La forma más fácil de hacerlo es utilizando set timeout, que ha estado disponible durante un tiempo. Entonces, aquí tenemos un set timeout de cero. Estamos diciendo que estas cosas menos importantes, ejecútalas en cero segundos. En realidad, no las ejecuta en cero segundos, las coloca al final de la cola en cero segundos. Si no hay nada más que hacer, no necesitamos hacer ningún pintado, nadie ha hecho clic en otro botón con cosas más importantes, las ejecutará de inmediato. Si hay otras cosas que deben hacerse, las hará. Estás permitiendo que el navegador vaya y maneje cualquier otro evento que sea importante para él, antes de hacer estas cosas. Es importante revisar tu código y ver dónde puedes colocar estos puntos de interrupción. Hay bonitas APIs de
JavaScript, solo en Chromium por ahora. Pero mantén un ojo en ellas, set timeout está disponible. Y mira tus
frameworks y lo que pueden usar.
16. Optimización de JavaScript y contenido de terceros
Evita JavaScript innecesario y considera cargar contenido de forma diferida a medida que los usuarios interactúan con la página. Limpia Google Tag Manager y elimina contenido de terceros innecesario. Carga de forma diferida los vídeos de YouTube que están fuera de la pantalla y evita actualizaciones de renderizado grandes.
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í.
17. Optimización de Renderizado y DOM
Hay mucho sobre renderizado concurrente, capacidad de recursos, hidratación no destructiva, mantener tamaños pequeños del DOM, contención de CSS y uso de requestAnimationFrame para tareas críticas. Estas son nuestras nueve principales recomendaciones. Lee nuestra publicación en el blog para obtener más detalles y enlaces.
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.
React Summit 2023
