Os voy a explicar esto de CSS porque es muy interesante, ¿vale? Es tremendo.
Es una propiedad que ya hace tiempo que existe, o sea, desde Chrome 85 o así.
Pero ¿qué pasa? Los navegadores ya, tanto Firefox como Safari, tienen soporte.
Y esto hace que esta propiedad no es nueva, ya lleva un tiempo en Chrome,
tome de nuevo relevancia porque todos los navegadores modernos,
y sí, estoy hablando de ti, Internet Explorer, menos mal que no estás,
pero cuando hablamos de navegadores modernos son todos los navegadores menos hijoputa de Internet Explorer, ¿vale?
Para que lo entendamos.
Entonces, y claro, versiones antiguas de Google Chrome, que si tienes Google Chrome 12,
pues igual es que estás escondido en una cueva, no has actualizado nunca tu navegador,
y bueno, pues sigue ahí sufriendo en silencio.
Total, que Content Visibility es una propiedad muy interesante porque lo que hace es que
lo que no ve el usuario, puedes hacer que lo que no ve el usuario no lo renderice el navegador.
¿Qué quiere decir? Imagínate que tenéis una página, y ahora os voy a hacer un ejemplo práctico,
no te preocupes, ¿eh?
Pero imaginad que tenéis una página que es muy larga o con muchos resultados o con muchas cosas,
y el tema es que si lo renderizas todo, aunque el usuario no lo vea,
en este ejemplo, aquí podéis ver que está tardando 232 milisegundos de renderizado.
En cambio, si utilizamos el Content Visibility en auto, solo con una propiedad de CSS,
lo que veis aquí es que está tardando solo 30 milisegundos, o sea, fijaos la diferencia,
que es bastante tremenda, ¿eh? 30 milisegundos, has bajado 200 milisegundos.
Ahora, esto no es como Lazy Load, es parecido, pero no es exactamente lo mismo,
y ahora os explicaré por qué, ¿vale?
El Lazy Load lo que hace es que no renderiza el contenido, no carga el recurso hasta que tú le digas,
¿vale? Y eso lo que hace además es que se dispara esa carga o ese renderizado,
pero más del HTML cuando llega al viewport, ¿vale?
Pero el Content Visibility es algo más interno del navegador,
de forma que tú no te tienes tanto que preocupar de que se recargue el recurso
o incluso de escribir el HTML, sino que el HTML está ahí,
solo que el navegador lo ignora en cuanto a renderizarlo.
Es algo diferente, porque con el Lazy Load lo que haríamos es una carga diferida
a la hora de escribir el HTML para que pueda mostrar ese contenido,
que normalmente pues tiene un pequeño impacto de rendimiento,
porque obviamente cuando el navegador llega,
entonces se ejecuta normalmente algún tipo de JavaScript o algún proceso
que descargue realmente el recurso,
y aquí los recursos realmente ya están,
solo que es el navegador que dice, está ahí, pero lo ignoro,
no voy a cansarme en renderizarlo.
Mira, para que nos hagamos una idea un poco de cómo funciona esto,
aquí tengo esta página de Pokémon, ¿vale? Siempre con Pokémon todo va mejor.
Y con Pokémon, fijaos que claro, este Pokémon, pues ¿cuántos Pokémon hay aquí?
Pues hay un montón. Hay un montón de Pokémon, tú haces aquí scroll, bla, bla, bla, bla.
Un montón, un montón de Pokémon.
¿Qué pasa con esto? Pues que si yo me voy aquí al HTML,
obviamente todo este HTML está ahí, vamos a...
Oh, esto es nuevo, por cierto.
La nueva versión de Chrome han puesto en Performance esta métrica locales
que te dicen cositas interesantes. Está bastante bien.
Entonces, algo que mucha gente haría es el Infinity Scroll, ¿no?
Porque dice, claro, como es todo esto, hay que renderizarlo,
pero el Infinity Scroll tiene un problema.
Y el Infinity Scroll, el problema que hay es que el HTML no se vería.
Por ejemplo, si yo aquí abajo está, yo qué sé, ¿vale?
El Vulu este, tú imagínate que estás aquí arriba y el usuario dice,
vale, pues quiero buscar el Vulu, ¿ves? Ahora sí que lo encuentro.
Con el Infinity Scroll no lo encontraría, porque no lo ha cargado.
Entonces, aunque tú dijeses, ah, pues quiero buscar a Vulu,
no lo encontrarías, porque no está en el HTML.
Por eso, a veces puede ser interesante cargarlos todos,
y además en temas de SEO también es interesante,
porque el Infinity Scroll necesita JavaScript
y no se va a poner a scrollear tampoco.
Entonces, por temas de SEO puede ser interesante tener todo el HTML,
por temas de accesibilidad también puede ser interesante y tal.
Entonces, pues el Infinity Scroll o el Lazy Load no lo funcionaría.
El Lazy Load, cuando vas haciendo scroll,
vas viendo cómo además se van cargando las cosas.
Vamos a utilizar el Content Visibility.
Vamos a ver cuánto carga ahora.
Si vamos al Performance, vamos a poner, obviamente,
porque tengo una máquina muy buena, entonces no lo vamos a ver.
Voy a poner un 20x, para que sea un poco exagerado, ¿vale?
Y voy a recargar la página.
Voy a recargar la página hasta que aparezcan los bichos, ¿vale?
Hostia, igual 20x me he pasado, ¿eh?
Igual 20x me he pasado.
Bueno, pero ahí vais viendo cómo se va.
Ah, encima tiene Lazy Load, de verdad.
Encima sí que tiene Lazy Load, porque veo ahí el loading.
O sea, bueno, 20x igual me he pasado, ¿eh?
Vamos a ponerle un 6x, ¿vale?
Pero tiene ya un Lazy Load ahí.
O sea que ya regulinchis.
Bueno, no pasa nada.
Yo creo que lo veremos igual bien.
Vale, voy a darle otra vez, ¿eh?
Pero con 6x.
Con Lazy Load, lo bueno es que el Content Visibility también funciona con Lazy Load.
Bueno, ya está.
Entonces, si vamos aquí abajo, fijaos aquí que tenemos renderizado 1,2 segundos.
Es una pasada, ¿eh?
Porque esto es trabajo oculto que no te das cuenta que está pasando muchas veces.
Esto es un error que muchas veces os comento y no me hacéis ni puñetero caso, pero yo quiero igual.
El tema es que la gente se cree que todo es gratis.
No solo el JavaScript, sino que 1,2 segundos son 1,236 milisegundos.
1,236 milisegundos es 1,2 segundos.
El tema es, eso es solo 1,2 segundos, es solo renderizar el contenido.
Yo sé que muchas veces la gente dice, ah, qué tontería, que no sé qué, me da igual.
Porque tenemos ordenadores muy potentes.
Cosa que es medio verdad.
O sea, es verdad, mi ordena es muy potente, pero no es lo mismo cuando estás en un móvil,
y estoy seguro que te ha pasado muchas veces que cuando estás en un móvil ves que las cosas cargan a trozos.
Y dices, pero ¿qué es esto?
Eso es porque seguramente la página o tiene muchos nodos HTML, tiene que renderizar mucho y todo este tipo de cosas, ¿vale?
Esto, que parece una tontería, suele pasar en muchas páginas.
Mira, por ejemplo, aquí, Barcelona.
Aquí fíjate todos los resultados que hay.
Hay un montón de resultados, ¿no los ves todos?
¿Cuántos resultados hay aquí?
Hay un montón.
Y además, el usuario no está viendo todos los resultados y son elementos HTML que son bastante complejos.
Fijaos que tienen aquí un slider, botones, no sé qué.
Esto tiene un coste, todo tiene un coste, todo tiene un coste.
Airbnb, es que hay mil millones de ejemplos.
Pues esto, al menos ahora, lo podríamos mejorar.
Para eso, vamos a ir a un elemento, a este mismo.
A ver si somos capaces de hacerlo.
Mira, .gen, este tiene buena pinta.
.gen.
Si ponemos aquí, content visibility auto, vale, espérate porque necesitamos que se guarde y no se va a guardar.
Así que nos vamos a sources.
Esto es otro ducazo que está muy chulo.
En overrides, ¿vale?
Podéis activar los overrides.
Y esto lo que hace es que los cambios que hagáis en el CSS, como por ejemplo este.
Vale, ahora vamos a tener que refrescar con la tontería.
A ver ahora.
Content, no.
No me lo está haciendo.
A ver.
Overrides.
¿Por qué no me lo está haciendo?
Es que me debería guardar con...
Ah, ahora.
Ah, sí que lo ha hecho, sí que lo ha hecho.
Vale, ¿veis aquí que hay un puntito?
Este puntito, lo que está haciendo es que esta línea de código que he puesto aquí, la va a guardar, aunque yo reinicie la página.
A esto se le llama local overrides, que aquí le tenéis que decir en qué carpeta queréis que se guarde vuestros overrides.
Podéis ponerlo en la carpeta que queráis.
Y así, cada vez que entres en esta página, que tenga las herramientas de desarrollo abierta, esta línea de aquí va a estar ahí disponible.
O sea, está súper chulo este truco.
Y si tenéis que probar cosas en vuestro día a día, de decir, ostras, yo qué sé, para que os hagáis una idea,
ponéis un background red, ¿vale?
Que no tiene la idea.
Pero esto, ahora, cuando vayáis a este archivo, siempre va a estar este background red.
En lugar de descargarlo, lo que voy a hacer es utilizar el tuyo local.
¿Ves? Lo tengo aquí, local.
Vale, pues bueno, el background red me lo voy a cargar.
¿Y esto para qué sirve?
Pues justamente para lo que estamos haciendo.
Que lo que estaríamos haciendo ahora mismo sería el hecho de decir, bueno, pues ahora en performance,
que ya hemos visto que eran 1.236 milisegundos, voy a limpiar todo esto y voy a reiniciar, ¿vale?
Y vamos a ver cuánto tarda ahora el renderizado, ¿vale?
Venga.
Y ahora, según esto, ha tardado mucho.
Bueno, 975.
Ha tardado bastante menos.
Ha tardado solo 200 milisegundos.
Pero si bajamos, no vais a notar nada realmente, ¿vale?
Sí que vais a notar que a lo mejor, ¿veis que hay algunas cosas que se ven solo en el caso de que bajemos del todo?
¿Vale?
¿Veis que cuando bajamos del todo es que aparecen?
Pues es justamente por esto.
Vamos a probarlo ahora otra vez.
Voy a probarlo otra vez porque a lo mejor, ¿vale?
Voy a dejarlo un rato y ahora le vamos a quitar la línea.
¿Cuánto tiempo dice?
¿Ves?
Ahora ha renderizado 600 milisegundos.
Si le quitamos la línea, que es la que está haciendo la magia, y le damos otra vez a reiniciar, ¿vale?
600 milisegundos ahora.
Ahora ha quitado más, ¿eh?
¿Vale?
Lo ponemos así.
Lo dejamos así un buen rato, ¿vale?
Porque a lo mejor lo hemos parado antes demasiado pronto.
Y ahí tenéis, 1.200.
O sea, solo con una línea hemos mejorado el rendimiento un 50%.
Con una línea, con eso, con una línea de CSS está brutal porque al final hemos mejorado el rendimiento.
Y aún así, tened en cuenta que, claro, porque muchas veces pensaréis, ah, bueno, pero es que, claro, el problema es que entonces va a notar el usuario.
Bueno, no os creáis porque incluso hay veces que, por ejemplo, imaginad que ahora no tengo la línea.
Pero si va a ir muy rápido, ¿veis que tampoco se ve?
Esto es porque el navegador tampoco ya tiene internamente, ¿veis?
Esto es sin la línea de Content Visibility.
Entonces ya podéis ver que también le pasa el hecho este de que no se cargan porque es que no le da la vida.
Hay tantos elementos en el DOM que no es capaz de pintarlos todos y lo que hace es esperar un poco para pintarlo.
Entonces el Content Visibility este, pues ya os va a salvar la vida.
O sea, normalmente, importante, esta propiedad tiene sentido para cosas que no están en el viewport del usuario.
Imaginad, pues, yo que sé, un vídeo de YouTube que está tres líneas más abajo, una animación brutal que está mucho más abajo, cosas así, ¿no?
En elementos de lista, imagínate que tienes una lista de 5.000 elementos, que no tendría mucho sentido.
Pues lo podéis probar también que puede ser bastante interesante.
He visto gente que lo utilizaba en una lista de elementos de emojis.
Los emojis parecen una tontería, pero si a lo mejor tienes 1.000 emojis para seleccionar, por ejemplo, Discord, Slack y tal, lo utilizan para esto.
Así que ya sabéis, échale un vistazo.
Pero no uséis en todos los sitios, que no tiene sentido, porque también tiene un coste asociado, ¿ok?
Pues ahí tenéis, listas virtuales para mejorar vuestro rendimiento con una línea de código.
Y os dejo este artículo que está muy chulo porque me preguntáis muchas veces de esto, y hay veces que no me creéis nada,
sobre el hecho de optimizar fuentes, porque las fuentes, siento decirte, las carga el diablo.
Las fuentes es uno de los recursos más críticos, más jodidos que hay en las páginas web,
porque son críticos en el sentido de que cuando se carga va a cambiar el layout de la página, más pequeña, más grande y tal.
Suelen ocupar bastante y la gente suele cargar demasiadas.
Entonces, este artículo está muy bien porque no solo os dice cómo lo tenéis que optimizar, cuáles son los consejos,
pero os dice, por ejemplo, el tema de, oye, intenta utilizar fuentes que sean del sistema, que las fuentes del sistema no tardan.
¿Por qué deberías hospedar las fuentes en tu propio servidor y no utilizar, por ejemplo, las fuentes que vengan de Google?
Si vas a utilizar las de Google, ¿qué deberías hacer al menos para que no impacten el máximo?
¿Qué tipo de fuente deberías utilizar? Como por ejemplo, Web2. Esas son las que sí o sí deberías tener.
Tendrías que hacer el inline para mejorar todavía más el rendimiento.
Por ejemplo, esto es bastante buena idea, el hacer un inline de la carga de la fuente en tu HTML,
porque esto va a ir un poquito más rápido.
Si la tienes en el CSS, el problema que tienes es que cuando se carga el CSS, luego se carga la fuente.
Digamos que la distancia es mayor.
Si lo pones en HTML, que es el primer recurso que se descarga, te va a ir más rápido.
Y aquí tendrías, por ejemplo, optimizar tus descargas en el caso que no puedas hospedarlas tú mismo.
Hacer el preload, el preconnect y todo esto.
Y aquí algunas optimizaciones más generales.
Está muy chulo el artículo.
Lo recomiendo porque ya que a mí no me hacéis muchas veces caso,
pues al menos que le hagáis caso al artículo, que saben de lo que hablan.