Construyendo un Sitio Web Rápido para Cada Visitante

Hola a todos. Es muy bueno estar aquí por primera vez hablando en el Reino Unido. Así que hola, Londres. Y hola a las personas que nos ven en línea y a las personas que van a vernos más tarde en la grabación también.

Esta charla, como advertencia, es un poco más larga. Así que si quieren encontrarme para hacer preguntas más tarde, si no pude recoger algo en el escenario, por favor encuéntrenme de todos modos, no solo después, durante el día estaré disponible.

Esta charla trata sobre construir un sitio web rápido para cada visitante. Y cada visitante es una parte que voy a enfatizar hoy. Y comenzaré con una pregunta rápida. ¿Qué hace que un usuario web sea tan especial, tan desafiante? Responderé a esta. Así que tenemos algunas cosas que no podemos controlar como desarrolladores web o ingenieros, especialmente dónde van a navegar por su sitio web, en qué tamaño de pantalla, qué conexión a Internet, incluso sin conexión a Internet a veces, qué navegador, ni siquiera qué navegador, qué versión del navegador, no podemos controlar eso. Y también qué dispositivo están usando, qué tan fuerte o débil es el dispositivo que están usando. Ni siquiera podemos controlar cómo están sentados navegando por su sitio web, ¿verdad?

Por otro lado, los desarrolladores somos muy privilegiados. Deberíamos sentir eso porque siempre usamos la última tecnología, los últimos dispositivos, y lo necesitamos. Hay una razón para eso. Estamos ejecutando muchas cosas difíciles y usualmente estamos usando el mejor Internet, digamos. Y tendemos a usar la última versión de cualquier navegador para poder aprovechar cualquier UI. Sin embargo, hay solo una cosa para la que estamos simulando al usuario, y no deberíamos, que es la posición de sentado. Esta es la única cosa que no necesitamos, pero ahí lo tienes.

Así que no solo necesitamos construir un sitio web rápido para cada visitante, también necesitamos que sea más accesible. Todo se trata de accesibilidad aquí. No se trata solo de ser rápido. Rápido es solo un factor de eso.

Así que permítanme presentarme. Gracias Matim por dar una introducción. Mi nombre es Mehtad Dawood. Soy un ingeniero de software senior trabajando para Miro. Y también soy un experto desarrollador de Google en rendimiento. Si les gusta lo que ven hoy, pueden seguirme en Twitter o encontrar algunos artículos que estoy escribiendo en mi blog. Así que volvamos a lo que hacemos.

El rendimiento solo depende de la percepción del usuario. No hay nada que puedas percibir similar a lo que yo puedo percibir. Así que imagina que estás en un monopatín y has visto a alguien con una bicicleta. ¿Qué sentirías? Él es más rápido que tú, ¿verdad? Y si estás en una bicicleta y ves a alguien en un coche, él sigue siendo, esto es más rápido que tú. Pero si estás en el coche y ves a alguien en un Ferrari, sentirás que todavía él es más rápido. Así que realmente depende de dónde estés. Cada vez que estás a la derecha y te mueves a la izquierda, sientes que esto es más rápido y todo al revés. Si estás en el coche, sentirás que el ciclista es incluso más lento. Así que solo para asegurarte de que entiendes esto. Entonces, ¿una moto o motocicleta sería más rápida o más lenta? Realmente depende de dónde estés. ¿Verdad? Así que para esas personas, sentirás que, está bien, esto es relativamente más lento. Está bien. Y para esas personas que sentirán que esto es rápido. Así que necesitamos aprender cómo y dónde está el usuario.

Así que para medir el rendimiento, simplemente tenemos dos formas básicas. La primera es la prueba de laboratorio, que es simular cómo el usuario va a experimentar esto, y debes tener suficientes datos para decidir si es rápido o lento, cómo están haciendo eso. Y esto no es preciso. Realmente depende nuevamente de tus grandes dispositivos que estás usando. Tienes un M1, buscas un M2 o M3 y el comportamiento basado en pruebas de laboratorio para un M3 es diferente que un Intel. Estoy hablando por experiencia y la otra forma, que me interesa más hoy, que es la prueba de campo o también conocida como prueba de Rome, monitoreo real del usuario. Y para esta, obtienes toneladas de información, incluyendo core vitals, diferentes métricas. También obtienes la distribución de dispositivos. También obtienes la distribución de la conexión. Y te sorprenderás si ejecutas esto en tu sitio web o cualquier aplicación que estés construyendo. Encontrarás que muchas personas todavía están usando 3G o 2G, por lo que no es muy accesible para ellos. Y basado en esta información, reconocerás que no hay una talla única para todos. Tienes que hacerlo muy personalizado para el usuario y cómo están sintiendo tu sitio web. Todo se trata de percepción nuevamente. Así que necesitas elegir un objetivo. Ya sea que lo construyas para las mejores condiciones del usuario y construyas la gloriosa experiencia de usuario.

Esto dará una mala accesibilidad para las personas con dispositivos de gama baja. Sin embargo, es una gran experiencia para las personas con dispositivos de gama alta como iPhones o algo así. O vas con una condición garantizada. Imagina que estás ejecutando algo como Windows XP en todas las PC del mundo. Bien, para las personas, incluidas las personas con un procesador M3, eso será agradablemente rápido, ¿verdad? Pero probablemente será una experiencia de usuario horrible. Y esto te está dando más accesibilidad. Sin embargo, es una mala experiencia de usuario. Así que esto no es aceptable. Esto tampoco es aceptable. Entonces, ¿qué tal si evitamos que el usuario tenga esta sensación de que es ya sea una mala experiencia de usuario y no puedes simplemente trabajar con un dispositivo de gama alta que compraron con, ya sabes, toneladas de dinero. Pero al mismo tiempo, y lo más importante es que las personas donde están navegando con dispositivos débiles. Necesitas hacerlo accesible para ellos también. Así que constrúyelo para todos y haz feliz a todos. Esto es exactamente de lo que necesitamos hablar hoy. Es hacer una implementación adaptativa para todos. Así que te da la mejor experiencia de usuario y al mismo tiempo, la mejor accesibilidad para todos. Esto es bien conocido en el mundo con, ya sabes, mejoras progresivas o degradación elegante. Ambos están haciendo más o menos lo mismo. No tenemos una experiencia que podamos enviar a todas partes. Así que en lugar de tener una experiencia de usuario gloriosa, que nos incluye a nosotros también, la mejor experiencia de desarrollador, la enviamos a todas partes. Tal vez ahora estamos quedando atrás para las personas con dispositivos débiles o mala conexión a Internet y así sucesivamente. Y si comenzamos desde abajo, que para MVP o algo, las personas con o buscando una gran experiencia no estarían tan felices. Ambos están haciendo lo mismo. Pero esto abrió la puerta para no tener una experiencia, sino un espectro más amplio para muchas experiencias, dependiendo de lo que el usuario tenga y su condición.

Así que vamos a sumergirnos en las cosas. ¿Qué factores relacionados con el usuario están fuera de nuestro control? Como dije antes, hay algunas cosas, tamaños de pantalla, navegadores, dispositivos, conexión a Internet, posición al sentarse. Desafortunadamente, este no está cubierto, pero estos cuatro, vamos a obtener algunos consejos y seguir adelante. Y cada vez que veas algo que estás aplicando a tu aplicación, solo ponte un punto y contaremos al final.

Bien. Así que comenzando con los tamaños de pantalla, no voy a discutir aquí el diseño responsivo. Esto ha estado presente durante como una década ahora, pero estoy interesado hoy en hablar sobre componentes reutilizables. Si estás construyendo componentes razonables, y usualmente lo haces, necesitas construirlos para que sean responsivos como el agua. Así que no sabes dónde se va a reutilizar este componente y en qué tamaño de pantalla, ni siquiera tamaño de pantalla, en qué contenedor ahora que estás construyendo. Algunas personas argumentarían no agua y solo responsivos como los gatos. Los gatos son líquidos. Eso es interesante, por cierto. Solo compruébalo. Y estoy más interesado no solo en componentes responsivos. Estoy interesado en las imágenes porque las imágenes son el 60, 70% del tamaño total de la página web. Así que si tienes un componente, que es un gran componente, incluyendo algunas imágenes dentro de él, de nuevo, no hay una talla única para todos. Necesitamos hacer algo. Es una forma regular de crear una etiqueta de imagen HTML. Tienes una etiqueta de imagen, das la fuente y esta fuente se envía a todas partes.

Asumo que tienes tres tamaños. Así que el tamaño grande estás sirviendo esta imagen y es como 500 kilobytes. Es una calidad decente que estás sirviendo. Está bien. Sin embargo, si lo sirves para una tableta, en este caso, estás enviando algunos bytes que el usuario podría no notar la diferencia por eso. Y será peor también si estás usando algo como un móvil. Es un dispositivo muy pequeño y estás enviando una imagen relativamente grande para eso. Por eso tenemos algo llamado imagen responsiva que ha estado presente por un tiempo. Y de esa manera estás proporcionando algo llamado source set y estás dando algunas sugerencias al navegador que le estás diciendo al navegador cuándo cargar qué tamaño. Y con eso, puedes dar, por ejemplo, esto al lado de cada imagen.

Hay algún ancho. Esto se llama candidato de imagen o descriptor de ancho. Aún puedes decirle al navegador en este ancho o más allá. Puedes usar esta imagen en una pendiente y también hay tamaños allí abajo.

Lo bueno de eso es que lo envías para escritorio. Todavía estás enviando los 500. Está bien. Pero puedes proporcionar una mejor experiencia para la tableta de las personas e incluso mejor experiencia para personas con móvil. Lo bueno es que esto está totalmente soportado, puedes usarlo hoy.

¿Por qué traigo eso a una conferencia de React? Porque me gustaría darte una recomendación, una alta recomendación, que debes usar algo como el componente de imagen proporcionado por el framework que probablemente estás usando. ¿Por qué está sucediendo esto? Porque hay una colaboración entre un equipo en Chrome. Se llama Aurora. Y está ayudando a todos los frameworks a optimizar la imagen o hacer un componente de imagen que esté totalmente optimizado desde el principio. Esto, por ejemplo, con Next.js solo estás proporcionando como una fuente y tal vez un ancho y altura. Y esto se traduce exactamente en lo que necesitas para optimizar desde el principio. Entonces, ¿por qué no haces eso? Así que tienes algo llamado Distribuidor de Píxeles. Está haciendo más o menos lo mismo. Detectando el tamaño correcto en la pantalla o no y enviando el tamaño correcto basado en eso.

No solo Next.js. Puedes tener lo mismo con el componente de imagen de Astro o Gatsby y otros lugares.

¿Qué pasa si estoy usando algo que no proporciona algún componente? Es fácil. Hazlo tú mismo. E incluso la última versión de Next.js está usando ahora alguna biblioteca como Sharp. Solía usar algo llamado Squoosh. ¿Quién está familiarizado con Squoosh aquí? Genial. Algunas personas. Así que Sharp ahora se está usando incluso para Next.js bajo el capó. Puedes hacer eso especialmente si estás construyendo algo que tiene algunas imágenes dinámicas que el usuario está subiendo alguna imagen y estás sirviendo en todas partes. No puedes controlar esto. Pero puedes hacer que use Sharp o ImageMagick o usar algo en línea que está fuera de la caja como Cloudinary o Vercel. Y esto te proporciona algunos CDNs también. Así que puedes servirlo en todas partes.

Genial, pasemos a otra cosa que no podemos controlar. El soporte de navegadores. Según las últimas estadísticas, muestra que tenemos como 20-25 navegadores diferentes en el mundo. Navegadores activos ahora mismo. Pero los cinco principales aquí. Chrome, por supuesto, es el mejor y Safari, Edge, Firefox, Opera y otros navegadores. Y basado en eso, vamos a hablar de los cinco principales por una razón que voy a compartir en un momento.

Pero, ¿por qué tenemos todos estos navegadores en primer lugar? Esto es algo que podría venir a tu mente. ¿Y qué característica podría no ser compatible con un navegador específico? Eso se debe a dos cosas importantes. Probablemente ya lo sepas. Dos motores. De hecho, el primero se llama Motor de Renderizado. Y esto es proporcionado por el navegador para hacer el flujo de tu HTML, CSS, renderizando la UI para ti. Y para estos cinco, los cinco principales que tenemos. Tenemos estos tres, por ejemplo, que están basados en Chromium y están usando algo llamado Blink Rendering Engine. Esto es un basado en Chromium. Y Firefox está usando algo llamado Gecko. Y Safari está usando WebKit. Curiosamente, si tienes un iPhone y estás usando cualquier navegador en tu iPhone, están usando WebKit. ¿Por qué? Porque Apple no permite ningún otro motor en su teléfono. Hay algún caso en Europa, en la UE ahora para cambiar eso. Pero hasta ahora, eso explica cuando estás usando Chrome, por ejemplo, en un iPhone y encuentras algo que aún no es compatible, eso es por WebKit, no por Chrome.

OK. Sí. La otra cosa que tiene una diferenciación son los motores de JavaScript. Nuevamente, los tres de ellos están basados en Chromium. Están usando algo llamado V8. Y este motor de JavaScript también está siendo utilizado por Node.js.

Creo que todos lo saben. Y Firefox está usando algo llamado Spider Monkey. Y Safari está usando Nitro. Así que cada motor. Tenemos un estándar, pero cada motor está implementando estos estándares en su propio tiempo y a su propio ritmo.

Entonces, ¿cómo podemos determinar si una característica no es compatible? Pregunta súper fácil. Solíamos verificar algo llamado, Can I use? Correcto. Y también verificamos MDN. Te da una idea. Y recientemente Google introdujo algo llamado Baseline. Y basado en eso, solo obtienes un ícono, lo que significa que los cinco principales navegadores están soportando esta característica. Así que está bien usarla. Por supuesto, esto no garantiza todos los navegadores del mundo. Pero hay una gran posibilidad de que esto sea compatible con la mayoría de tus visitantes.

Bueno, ¿qué nos permite hacer? Nos permite usar algunas APIs del futuro. Es una API rápida y muy pequeña de una línea que puedes usar hoy para compartir contenido desde tu sitio web. Así que solo un botón. Haz clic en él y abrirá automáticamente el compartir en tu dispositivo, ya sea un escritorio o un móvil. Solo una línea. Súper fácil, ¿verdad? Sin embargo, no está completamente soportado. Firefox se está quedando atrás. Entonces, ¿cómo puedo hacer eso? Solo envuélvelo, envuélvelo alrededor de if else y di, está bien, si está soportado, usa eso de lo contrario, usa una biblioteca de terceros como solíamos hacer antes de esta API.

Entonces, ¿cómo podemos beneficiarnos de eso? ¿Qué es importante? La importancia aquí es que para los navegadores que están soportando esta API, no vas a enviar ningún tercero. Es un impulso de rendimiento desde el primer momento. Puedes simplemente usar la API ya enviada en el dispositivo o en el navegador del usuario. Pero para las personas que todavía están usando Firefox, lo siento, tenemos que compartir o enviar algunos más bytes. Y esa es una penalización que tienes que pagar. Genial. Otra cosa, imágenes de nuevo. Sí.

Sí. Las imágenes son muy grandes, así que debemos preocuparnos por ello. Entonces, ¿qué pasa si la imagen se proporciona como un JPEG en todas partes? Podría funcionar, ¿verdad? Sí. Sin embargo, puedes proporcionar otras cosas. Puedes usar elementos picture y este elemento picture. Puedes proporcionar diferentes extensiones de diferentes compresiones. De esta manera, podrías proporcionar Aviv o GXL. Y para las personas que no saben qué es GXL, es una nueva extensión que es sin pérdida y 50 a 1 de compresión. Es fantástico compitiendo con Aviv. Y desafortunadamente, no es compatible con Bizline todavía. Irónicamente, es compatible con Safari. Así que, OK, este no puedes usarlo en todas partes.

Lo recojo. Si no, lo omito. El siguiente, el siguiente. Y como te mostré aquí, también volvemos al JPEG. Así que no estás perdiendo nada. Solo proporcionando una mejor experiencia, una mejora progresiva para los usuarios que están usando algo como Safari o algo compatible. Y por otro lado, las otras tres extensiones están siendo totalmente compatibles. Bizline ahora mismo. Incluso Aviv no era compatible hasta principios de este año. Edge se estaba quedando atrás. Ahora, Edge también está usando Blink. Así que Aviv está siendo compatible.

Me gustaría preguntarte, ¿notarías algo con tus propios ojos entre los tres? Responderé esto por el momento. No lo notarás, porque es una compresión bastante buena con Aviv. Pero lo que puedes notar es que el tamaño de la imagen entre JPEG y Aviv es menos de la mitad del tamaño de JPEG. Así que funciona para ser compatible. Necesitas proporcionar diferentes versiones de la imagen en lugar de solo JPEG. Y eso combinado, si tienes muchas imágenes en tu sitio web, eso marcará la diferencia.

Pasando a otro consejo rápido que la mayoría de la gente está usando. Si estás usando alguno de estos empaquetadores, creo que lo haces. Bebel, Outperfixer, Webpack, NixJS y otros. Dependen bastante de alguna configuración como la lista de navegadores. La lista de navegadores se puede proporcionar de dos maneras. Ya sea tenerla en tu package.json de esa manera, o tenerla en un archivo diferente. Browser list RC, supongo. Y de esa manera estás dando pistas, pero esta vez no al navegador. Estás dando pistas a los empaquetadores sobre qué proporcionar y qué polyfill. En el pasado, solíamos tener algunos polyfills y corejs. No estoy seguro si alguien está familiarizado con eso. Genial, tenemos algunos, ya sabes, personas mayores aquí.

Quiero decir, viejo en la carrera, nada más. Así que las pistas aquí son muy importantes, para que el empaquetador no envíe nada que no sea necesario. Así que, por ejemplo, la segunda línea aquí no está muerta. Así que nos aseguramos de que no estamos dando ningún polyfill para ninguna característica que sea compatible en IE, por ejemplo. IE está muerto, ¿verdad? Opera Mini está muerto. Así que no lo soportamos. Así que no se envían polyfills. Las dos últimas versiones. ¿Así que algo no es compatible desde hace tres versiones de cualquier navegador? No, no lo soportamos. Así que no vendas o no, ya sabes, envíes estas características. Si es utilizado por el 0.25% de la población de Internet, que es mucho, por cierto, entonces apóyalo o puedes dar una versión específica. Y de esa manera, sin nada, solo una pequeña configuración. Estos empaquetadores lo recogerán y solo enviarán las cosas que necesitan ser enviadas.

Genial, pasemos a otra cosa, el dispositivo. Esa es otra cosa que no podemos controlar para el usuario. Y solíamos tener esto. La gente piensa que Chrome está consumiendo su RAM. Correcto. Pero no es cierto porque el año pasado Chrome hizo una actualización que los desarrolladores piensan que es un error, pero es una característica. Que cuando pasas el ratón sobre cualquier pestaña, puedes tener una idea de cuánto consume de tu memoria. Así que no es Chrome, son ustedes, los desarrolladores, quienes están haciendo eso. Los desarrolladores comienzan. Oh, solíamos culpar a Chrome. Ahora tenemos que hacerlo. Así que les presento una API experimental que pueden usar hoy. Se llama window navigator device memory. Esto te da un número aproximado de memoria en gigabytes que se proporciona en el dispositivo del usuario. Basado en eso, puedes tener una idea de cuán fuerte o débil es este dispositivo y puedes servir tal vez una versión más ligera. Como ejemplo, construí esto solo construyendo una API de contexto, verificando solo una vez cuán fuerte o débil es este dispositivo y enviándolo en el contexto. Y en cualquier componente en tu árbol que sientas que está haciendo muchas computaciones, tal vez cargando una imagen grande o un video o algo, puedes simplemente hacer esta pequeña verificación de la fuerza del dispositivo. ¿Es débil? Muy bien.

Simplemente elimina algunas cosas que podrían estar haciendo que la experiencia del usuario sea muy mala. De lo contrario, simplemente sírvelo. Esa es otra opción débil que puedes usar. Esta solo se proporciona en navegadores basados en Chromium. Por eso no cuesta nada solo para las personas que usan navegadores basados en Chromium. Pueden experimentar una mejor experiencia para las otras personas. Simplemente haz lo mismo que solías hacer por defecto.

Otro se llama hardware concurrency, y esto también te da el número de núcleos concurrentes. Eso es lo que el usuario está ejecutando en su dispositivo, y basado en eso, puedes tener una idea de qué tan rápido o lento es el dispositivo y tal vez hacer algo diferente. Esta mañana hubo una gran charla en el mismo lugar donde estuve, esa charla de Dara. Estaba hablando sobre la concurrencia. Estoy interesado en esta parte. Estaba tan feliz de que ella mencionara esta parte de la que está hablando. Sabes, esto puede agregar tensión al CPU en dispositivos de gama baja. ¿Cómo puedes hacer eso? ¿Cómo puedes detectarlo con esta API?

Puedes detectar si este dispositivo puede o no hacer esta concurrencia, y tal vez puedas construir, es mucho trabajo, pero puedes construir dos versiones de este componente y hacerlo condicionalmente porque no puedes o no puedes hacerlo sin él. Y condicionalmente, hazlo porque no puedes, por supuesto, renderizar condicionalmente Hawks. Así que un pequeño fragmento rápido también. Puedes simplemente detectar. Oh, lo siento, puedes simplemente detectar cuántos núcleos y basado en eso, si es más de cuatro núcleos. Por ejemplo, puedes cargar más cosas, ejecutar más web workers, cargar el modelo 3D o algo. Tengo experiencia en el pasado que cuando visitas algunos, estaba visitando algún sitio web que muestra algunos modelos 3D, y cuando sucede. No tenía M1 en ese entonces. No fue hasta que cualquiera puede esperar lo que sucedió. Simplemente siento que mi portátil está despegando. Los ventiladores se volvieron demasiado ruidosos por eso. Están usando mucho CPU, mucha memoria y haciendo muchas cosas sin detectar si mi portátil puede hacer eso o no. Así que ahora puedes hacer eso y dar una mejor experiencia a las personas. Esto no puedes pensarlo desde el principio, pero es una mejora progresiva nuevamente. O degradación elegante. Si estás sirviendo algo muy pesado más adelante, simplemente puedes degradarlo.

La buena noticia es que esto es totalmente compatible. Así que hazlo hoy. Puedes simplemente pensarlo si estás construyendo algo que es muy pesado en cuanto a CPU. Simplemente hazlo hoy y creo que serás más feliz.

Última parte, seré muy rápido con esta. Lo siento, está tomando demasiado tiempo. Conexión a Internet. No puedes detectar o no, puedes detectar, pero no puedes esperar al usuario. Conectándose desde qué conexión a Internet. Y aquí hay un pronóstico que dice que para 2030 vamos a tener 5G dominando. Sin embargo, lo que noté como experto en rendimiento, las personas en la parte inferior, 2G, 3G combinados serían como el 9% de la población de Internet. Eso es mucho. Aún en 2030. Sin embargo, todavía estamos en 2024. Así que las personas que están experimentando 2G y 3G son más que combinadas, son más del 25% de la población de Internet. Eso es bastante. Eso no es accesible para ellos.

Así que aquí hay un ejemplo de cómo podemos mejorarlo progresivamente. YouTube, por defecto, si tienes una mala conexión a Internet, la calidad se reduce automáticamente. ¿Alguien ha experimentado eso? Sí, exactamente. ¿Por qué están haciendo eso? Porque es mejor para el usuario ver un video de mala calidad que esperar mucho tiempo para tener un video de buena calidad. Esto es exactamente lo que también necesitamos hacer.

Otro ejemplo es si estás ejecutando SSR, en realidad, estás enviando HTML, HTML puro, y luego haces JavaScript para rehidratarlo. Entonces, ¿qué pasaría si estás cargando un formulario como HTML y ese formulario? Tal vez sea una línea o un input y enviar y lo llenas rápidamente y sigues enviando. Pero el JavaScript aún no se ha cargado. En realidad, este botón no hará nada hasta que el JavaScript esté cargado y luego pueda responderte. Mi recomendación es usar algo como el componente Form que viene de serie con Remix. No solo Remix, también viene con Reboot y Next.js y la última versión. Esto es importante porque lo que está sucediendo con el componente de formulario es que está retrocediendo al elemento de formulario HTML, lo que significa que será una experiencia un poco diferente si el usuario comienza a enviar cuando el HTML acaba de aparecer, se estará enviando de vuelta. ¿Alguien con experiencia en PHP? ¿Solo yo? Oh, está en Bevo. Genial.

Entonces, lo que está sucediendo en este caso es que no tienes JavaScript. Simplemente estás enviando, se volverá a publicar, toda la página se recargará. No es la mejor experiencia, pero sigue siendo accesible para las personas con mala conexión, porque el JavaScript tardará un poco en cargarse.

Así que, siguiente. Hay una API experimental, y es controvertida y voy a explicar por qué. Esta te da una idea de cuán fuerte es el internet en el dispositivo del usuario usando algo llamado effective type. Y effective type, si lo ejecutas en tu navegador hoy en día, simplemente te dará 4G, 3G, 2G, usualmente es 4G, incluso en Wi-Fi. Y puedes simplemente obtenerlo y dar una experiencia diferente.

Por ejemplo, puedes cargar activos pesados, imágenes o videos de alta calidad para 4G, de lo contrario, dar imágenes de baja calidad, ¿verdad? ¿Por qué esto podría ser algo grande? Porque si el usuario ya tiene una mala conexión a internet o una mala red, solo servirás un megabyte de video, por ejemplo. Un video degradado en 4G, pero si es 2G o 3G, puedes servir solo una imagen, que es de 30 kilobytes.

Siempre piensa en la cantidad de bytes que vas a enviar al usuario. Desafortunadamente, esto solo es compatible con los basados en Chromium. Y encontrarás lo curioso de esta imagen, que Firefox lo soportó y luego eliminó el soporte. Correcto. Eso fue muy interesante. Lo soportaron y lo que sucedió es que Firefox para móviles tuvo un gran error debido a esta habilitación. Y luego comenzaron, después de soportarlo, lo eliminaron nuevamente y dijeron, no, esto es malo para la seguridad. Ahora tenemos huellas del usuario que también podemos detectar dónde están y si al detectar su internet, si es 2G, esto significa que tal vez están caminando. Se convierte en un 5G. Ahora está en un lugar con Wi-Fi. Tal vez está en el trabajo. Tal vez está en casa. Correcto. Y moviéndose nuevamente a 4G. Esto significa, perdón 3G. Esto significa que está caminando por la calle. Así que tiene algunas huellas que podrían ser malas para la privacidad. Por eso trabajaron junto con el equipo de Chrome para introducir una propuesta. Esto no es oficial, esto aún no está hecho.

Y en lugar de responder con effective type y, ya sabes, ser deshabilitado y demás, save data. Tenemos este tres medido, velocidad sostenida y solo cambiamos esta propuesta. No está ahí fuera. Durante dos años, están discutiendo por qué van tan lento. Se están tomando su tiempo. Lo que estará en el medidor es que pueden detectar si estás en una conexión a internet, sí, si estás en una conexión a internet, que es muy limitada, especialmente si estás en un hotel que te está dando, ya sabes, solo una cantidad medida de datos. Tal vez aquí en la conferencia. No estoy seguro. Tal vez en el aeropuerto, también te están dando una cantidad limitada de datos. Pueden detectarlo y, basándose en eso, puedes dar una experiencia diferente.

Si estás usando React, ¿es una pregunta legítima? ¿Quién no está usando React aquí? Bien, solo oh, hay algunas personas. Esto fue una comprobación de cordura de que estoy en el lugar correcto. Bien, puedes simplemente hacer eso. Usa este hoax adaptativo, que fue proporcionado por el equipo de Chrome hace mucho tiempo. Nuevamente, esto podría haber cambiado basado en el cambio de la API en sí. Pero puedes usarlo hoy porque ahora está totalmente soportado por el proceso de dispositivo basado en Chromium. Solo pruébalo. Te dará todo lo que hablamos listo para usar con algunos hoax personalizados que podrían ser útiles y limpios.

Así que como un resumen rápido, hablamos sobre tamaños de pantalla y cómo podemos proporcionar diferentes versiones de tamaños de imágenes. También hablamos sobre el soporte de navegadores y cómo podemos usar APIs del futuro sin afectar nada y hacerlo fácil en el futuro para eliminar y limpiar eso sin enviar bytes innecesarios. Hablamos sobre la CPU del dispositivo, cómo podemos detectar e-memoria y CPU como tendencias y negocios que dan diferentes experiencias. Y finalmente, conexión a internet, solo una cosa de la que no hablamos, no, no hablaremos, que es la posición al sentarse. Pero sí, dejaré eso para el servicio visual. Por favor, cuídense. Hay bastantes recursos. No tengo que fotografiar eso. Si te gusta, voy a compartir eso más tarde en mi Twitter. Ven a seguirme. Así que sí, eso fue todo. Muchas gracias.

Una pregunta de anónimo. Varios teléfonos Android de gama baja en realidad tienen varios gigabytes de RAM y varios núcleos de CPU. Pero todos los núcleos son muy lentos. De todos modos, para verificar eso. Oh, sí, eso es bastante difícil. Quiero decir, sin una API que te dé esta idea lista para usar, será prueba y error. Tienes que encontrar un patrón, cómo el usuario está experimentando eso. Tal vez una marca de dispositivo específica o algún modelo. Y hay algunos modelos que ya han sido detectados por el equipo de Chrome que son bastante lentos. Creo que el Motorola G2 algo ya está detectado como un dispositivo de gama media. Así que si tiene buen hardware y buena memoria y aún es lento, creo que es otra cosa. Tienes que detectar tal vez optar a tus usuarios a algún informe de experiencia de usuario de Chrome o algo, datos de campo de RAM, y basado en eso, todos los datos combinados, puedes detectar cuál es el culpable.

Muy bien. Entonces una pequeña pregunta. Solo quiero la respuesta sí o no. El proyecto Aurora que mencionaste, ¿también hace Web P y A fifth y la generación Jxcel o necesitas proporcionarlo tú mismo? Así que vuelve a preguntar. Sí. Mencionaste el proyecto Aurora. Sí. Optimización de imágenes. ¿Solo hace tamaños o también diferentes formatos de imagen? Respuesta sí o no. Respuesta sí o no. No, todo. Todo. No, sí o no. No.

Bien. Eso es todo el tiempo que tenemos. Muchas gracias. Gracias.