R3ACT: Una mirada aterradora a las cifras de rendimiento

Buenos días a todos. O debería decir, buenos días, Dom. Para los cinco de ustedes que me siguen en Twitter, sí, todavía estoy en Twitter! ¡Todavía estoy en Twitter! Es como un twitter. ¡Todavía estoy en Twitter! Los sigo a todos en Twitter. ¿Me sigues en Twitter? Sí, todavía estoy en Twitter. ¡Imagínate eso! Hago esto todas las mañanas. Saludo al Dom y he estado haciendo esto probablemente durante unos seis, siete años, literalmente todos los días. Y quiero agradecer, bueno, estoy aquí para la React Masterclass en EE. UU. Quiero agradecer a las naciones por tenerme. Merci beaucoup. Y quiero decir hola a Nueva Jersey. Nueva Jersey es lo que solía llamar U.S. east 1 NYC 1A. Porque así es como trabajamos, ¿verdad? Pero estamos aquí en Nueva Jersey, hogar de lo que solía ser los New Jersey Nets. ¿Algún fanático del baloncesto aquí? Nueva Jersey, lugar de nacimiento de Whitney Houston. En los EE. UU., el New York Times. Son los mejores empleadores en la historia del trabajo. Los Soprano. Escuché que son buenos para trabajar. Nueva Jersey, lugar de nacimiento de Greg, bueno, alguien sabe. Y para aquellos que no saben quién es Greg, ¿podrían conocer Craigslist? Oh. Ahí lo tienen. Ya saben. Hablando de horror y tragedia, hoy en realidad vamos a hablar sobre el rendimiento performance web. Quiero decir, rendimiento performance web, vamos, ahora. No es tan malo. Pero, ya saben, sé que Halloween fue hace unas semanas. Personalmente me gusta Halloween. Es un poco divertido. Pero, esencialmente, nos vamos a divertir con la charla de hoy.

Y, esencialmente, estoy, ya sabes, titulando esto Lunes 13. Porque vamos a ver algunos datos bastante interesantes y potencialmente tristes data. Entonces, con todo eso dicho, bienvenidos a mi presentación, a la que llamo React. Y, específicamente, es una mirada aterradora a las cifras de performance. Quiero decir, no quiero hacerlo sonar como si fuera realmente malo. No estoy diciendo que realmente vaya a ser tan malo. Pero vamos a ver algunos data. Y eso no siempre es favorable. Pero así es como es la web a veces cuando hablamos de performance.

Entonces, permítanme presentarme. Mi nombre es Henry. Pueden encontrarme en todas las redes sociales como Henry Helvetica. Sí, ese no es mi verdadero nombre. Es un seudónimo conocido. Tengo una situación que estoy iniciando llamada Command H. Es una especie de empresa de web development. Voy a hacer cosas de performance web. Soy de la mejor ciudad del planeta llamada Toronto en Canadá. Oh, tenemos canadienses aquí. Oh, gracias. Gracias por venir a verme. Y soy un poco corredor de larga distancia. Sí, hice una campaña de Nike hace unos años. Estaría encantado de hablar de eso. La carrera, eso es. Pero comencé esta campaña en línea llamada la campaña de hashtag devs, y, sí, si tienes algún corredor aquí, sí. Quería salir esta mañana. No tenía mis guantes. Hacía cero grados Celsius, y decidí no hacerlo.

Ahora, las métricas modernas se ven algo así. Estas son solo algunas de ellas, pero aquí tenemos un septeto de métricas, tiempo hasta la primera mordida, pintura de contenido más grande, tiempo total, cambio de diseño acumulativo, índice de velocidad, que es uno de mis favoritos, por cierto, primer retraso de entrada e interacción hasta la siguiente pintura. Estas son siete métricas a las que prestamos atención hoy. ¿Quién ha oído hablar de la mayoría de estas? Ni siquiera puedo ver, por cierto, así que lo que sea. Pero me voy a concentrar en unas pocas, y específicamente en este cuarteto de métricas, LCPCLS, FID, e interacción hasta la siguiente pintura.

Entonces, primero, permíteme comenzar con mi primer punto, que es la prueba de la página web. Solía trabajar en esta empresa llamada Cashpoint donde teníamos esta herramienta llamada prueba de la página web. ¿Quién ha oído hablar de la prueba de la página web? Por favor, di que sí. No. Ok. Solo algunos de ustedes. Todo bien. Porque ahora más de ustedes pueden tomar mi masterclass el próximo año. Pero miramos cómo se ve la web por debajo del capó, todo bien, como el coche brillante se ve genial, pero tal vez está soplando humo azul. Sabes, podemos recoger eso. Pero lo que voy a presentarles es una especie de instantánea de la web. Esto es lo que vemos como personas de rendimiento cuando miramos debajo del capó. Y específicamente, ok. Pensé que era un provocador. Y específicamente, voy a hablar sobre las herramientas que usamos, bueno, herramientas. Voy a extraer datos de este lugar llamado el archivo HP. Que es algo así como datos de laboratorio de cómo se está construyendo la web. Y ese es el principal tipo de datos que tenemos. También voy a extraer del informe CWV tech dot.

Entonces, es esencialmente un informe de indicadores clave. Y son datos RUM data. Y voy a extraer algo de eso también. Y también voy a extraer data del archivo RUM. Que es una versión RUM del archivo HP. Cortesía de las buenas personas de Akamai. Y esto también es súper útil para cualquiera que esté intentando hacer rendimiento web.

Y como estamos hablando de rendimiento web moderno y, ya sabes, quiero hablar en un idioma que al menos la gente haya oído hablar. ¿Quién está familiarizado con los indicadores clave aquí? Levanta la mano si has oído hablar de ello. Vale. Genial. Gracias. Así que vamos a hablar de eso hoy. Y los indicadores clave se componen de tres métricas. Y nuestro indicador clave es el tiempo, la user experience, y el proceso de carga.

Así que empezamos con cosas como la completitud visual, ya sabes, la user experience de la completitud visual. Cuando estás sosteniendo tu dispositivo portátil, probablemente un smartphone. ¿Cómo se ve cuando la página está cargando? Cuando eso sucede, hablamos del LCP, el contenido más grande para pintar. Y eso significa, como, la imagen principal o el héroe o el contenido más grande, cuando es bueno, se carga en 2,500 milisegundos, o más. En medio, es algo así como, meh. Pero vamos a hablar de eso. Pero también tenemos que hablar de la estabilidad de la página. ¿Quién aquí ha cargado un sitio, y es como, esperaste a que la página se calmara antes de empezar a leer? ¿Verdad? Hablamos de eso todo el tiempo, y eso también se reduce a un poco de user experience. Y cuando se trata de la estabilidad de la página hablamos del CLS, que es el cambio de diseño acumulativo. Y, ya sabes, aquí no es un índice de tiempo, es más como solo una métrica, y 0.1 o menos, genial. 0.25 o más, no tan bueno. Y en medio es como, lo que sea. Necesita trabajo. La puntuación final aquí es cero. ¿Vale? Y, por supuesto, tenemos que hablar de la interactividad.

¿Qué sucede cuando haces clic en ese botón de comprar en tu entrada para la Masterclass de React en EE.UU? ¿Quieres que funcione o no? ¿Verdad? Pero, hablamos sobre el FID, el retraso de la primera entrada. 100 milisegundos o menos, genial. 300 o más, no tan bueno. Y en medio, necesita trabajo. Bien. Entonces, ahora los data. Vamos a empezar a mirar esto. Lo que voy a hacer ahora, voy a comparar cómo se ve la web y cómo vemos los sitios de React. ¿De acuerdo? Entonces, cómo se ve la web ahora cuando sondeamos la web, 43. 1% tienen buen CLS, buen LCP y buen FID. Entonces, algo así como tres verificaciones verdes. Cuando se trata de sitios de React, 37. 7% tienen buenos en todos los aspectos. Bien. Eso realmente significa que poco más del 60% de los usuarios de la web, ya sea con buen LCP o buen FID, son mediocres o pobres en Core Web Vitals. Y estos son solo puntos de data que quiero que tengas en cuenta. Miremos ahora estos vitales individualmente. Empecemos con el LCP. Ahora, la web tiene un buen LCP a una tasa de alrededor del 59%, lo cual es bastante bueno. Entonces, de nuevo, eso significa que el héroe o el contenido más grande en la web es mejor que tu Google Play Store, y con alrededor del 60 al 70% de los usuarios de la web que son intensivos en medios, eso significa que son más rápidos a una tasa del 60 o 59%. React, 47.4%. Bueno, no es gran cosa, pero, ya sabes, de nuevo, solo un recordatorio de lo que está pasando. La web, cuando se trata de CLS, cuando se trata de la estabilidad de la página, lo está haciendo bien a una tasa de alrededor del 75%. Cuando se trata de móviles, ya sabes, de cualquier manera, todo es bastante bueno. De nuevo, estos son puntos que quiero que recuerdes. Ahora, el FID, el retraso de la primera entrada, la métrica de interactividad, la web está pasando a una tasa del 96%, lo cual es increíble. React está pasando a una tasa de casi lo mismo, 96.5, lo cual también es increíble. Pero para aquellos de ustedes que rastrean el performance, esta es una métrica con la que hemos tenido algunos desafíos, y mientras miramos este ejemplo, hemos mirado los data. ¿Algún profesor, ex profesor aquí, algo así? ¿Sí? ¿Sabes cuando escribes ese examen, y todos en clase obtienen como A plus? Y estás como, hmm. O bien este fue el examen equivocado, o todos estaban haciendo trampa.

Bueno, se descubrió que esta era la métrica incorrecta. Y esto era algo que estaba medio oculto, y descubrieron que, tú sabes, no estaban rastreando esta métrica de interactividad correctamente, por lo que se va a eliminar oficialmente el próximo año, pero lo que hicieron fue reemplazarla con esta métrica llamada Interacción al Siguiente Rosa. Yo olvidé la segunda parte. Fue experimental hasta este año, donde básicamente se programó para entrar en pleno funcionamiento en marzo del próximo año, ¿de acuerdo? Entonces, cuando empiezas a mirar interact, INP para abreviar, empiezas a mirar los data. Parece esto. La web está pasando a una tasa del 78%, y de nuevo, esta es una métrica de interactividad. Así es como, tú sabes, compramos cosas en línea, JavaScript, pero React no está haciendo lo mejor. Entonces, de nuevo, el promedio de INP es del 80%. Así es como compramos cosas en línea. JavaScript no está haciendo lo mejor. Entonces, de nuevo, cuando se trata del INP, React a una tasa del 50% es mediocre o pobre. Entonces, solo para ponerte al día de lo que el INP va a significar en términos de métricas, avanzando, a 200 algo. Entonces, en medio está bien. No está bien. Y en medio es meh. Perdóneme. Pero, de nuevo, estas son partes importantes porque estamos hablando de la interactividad que es necesaria para que la web funcione en estos días, ¿de acuerdo?

El 67% de los sitios tienen más tráfico móvil que de escritorio. De nuevo, es natural. Y, sabes, solo quiero recordar a la gente que hay dos usuarios móviles que conocemos, ¿vale? Usuarios de iPhone y payasos. Al parecer hay algunos payasos aquí. Pero en serio. Hablando en serio. Esto es importante y aquí está el por qué. Algunos nerds pueden haberlo recogido, visto las charlas, pero los ingenieros de Facebook han hecho un trabajo fabuloso y había esta biblioteca que tenían llamada Device Year Class. ¿Alguien familiarizado con eso? Es totalmente genial porque estoy aquí para contarte sobre ello. Los dispositivos Android hicieron este juego por volumen, lo que significa que podías comprar dispositivos Android baratos. Lo que pasó fue que te dieron teléfonos nuevos y brillantes con componentes anticuados o viejos. Viejos CPUs, viejos GPUs, pero funcionaban. Eso es todo lo que importaba. Pero lo que descubrieron es que este tipo de información era súper importante en términos de lo que estabas enviando por el cable. En general, los dispositivos Android simplemente no son tan potentes. Terminamos con un teléfono nuevo con básicamente partes más antiguas. Ahora, ¿por qué importa esto? El recordatorio de que estamos principalmente en móviles. El recordatorio de que el tiempo total de bloqueo del que hablé es 2.5 a 3 veces peor en un dispositivo móvil. Así que esa interactividad que estás tratando de lograr, la gente tiene más dificultades en los teléfonos móviles. Esto es algo llamado 'rage-clicking'. Suena divertido, pero en realidad está siendo rastreado por los proveedores de RUM.

Dinotrace, en realidad las buenas personas de Sentry afuera, en realidad tienen su propia métrica a la que llaman miseria del usuario o algo así. Pero esto está siendo rastreado. Es como cuántas veces estás presionando este botón, porque no está funcionando. Lo que sucede es que el JavaScript está golpeando el hilo principal, en lugar de golpear tu experiencia de usuario. Más JavaScript, peor TBT, tiempo total de bloqueo y peor se vuelve tu INP. Harry Roberts tiene la cita de todas las citas, un ingeniero de rendimiento del Reino Unido, JavaScript es la forma más rápida de construirte un sitio web lento, lo cual me pareció interesante.

Siempre hablamos de medir. Absolutamente tienes que medir. Quieres ver qué está pasando, la aplicación se ve genial, el sitio se ve increíble, pero ¿qué está pasando bajo el capó? No puedes mejorar lo que no mides. Saludos a los corredores que están tratando de conseguir Pbs. Gracias. Utilizas herramientas como WebPagetest, donde solía trabajar, pero también tienes herramientas como Lighthouse, Debugbear, Trio. Otra cita que me gusta aquí, sé conservador con lo que envías. No envíes JavaScript que no va a ser consumido. Hay mucho de eso sucediendo. Podría haber dado otra charla sobre eso. Envía recursos a las máquinas que se ajustan completamente a las especificaciones. Algo así como una interpretación del principio de robustez. De nuevo, ten en cuenta a tus usuarios. Tenemos la tecnología para averiguarlo. El rendimiento de la página es ahora percepción en toda la experiencia del usuario. Esa es una cita fantástica. Porque es mía.

¿Recuerdas esa página de inicio de la NBA? Es un sitio de React por cierto. Falló en la métrica de pintura de contenido más grande. Cambio acumulativo de LRG. FID. INP, mediocre. Y el tiempo total de bloqueo no es el mejor. Dicho esto, al cerrar, quiero decir que tenemos tres o cuatro discusiones de rendimiento o dos o tres presentaciones que se llevarán a cabo en esta conferencia.

Tres de ellos se llevarán a cabo con estos caballeros aquí, Ivan Ken, Medhat que va a estar transmitiendo. Dicho esto, puedes encontrarme en todas las redes sociales, Instagram, ¿cuál es la otra? No Facebook. Instagram, Twitter, Bastodon, Blue Sky, lo que surja mañana.

Vamos a tomar dos preguntas para Henry. Henry, la primera es, ¿por qué las páginas web de React generalmente tienen un código JS más grande? Quiero decir, creo que en su mayoría, está bien, así que no me gusta jugar a este juego de culpas porque no creo que se trate de eso. Realmente creo que se trata de testing. Se trata de asegurarse de que ves realmente lo que está pasando. Creo que estaba hablando con alguien sobre esto ayer, es como, sabes, estamos muy contentos con el trabajo que hacemos. Probablemente la gente de React Sí, puedes tener el mío. Uno, dos, está bien. Sí. Quiero decir, creo que simplemente se reduce a testing realmente, porque creo que eso se pasa por alto, aunque el performance se está convirtiendo en una conversación un poco más grande, pero al final del día creo que, si probamos y vemos lo que realmente está pasando, seremos como, oh, no puedo seguir con esto ahora mismo. Y entonces, hay una discusión de disciplina que debe tener lugar. Sacudiendo mi cabeza, testing.

Bueno, la siguiente pregunta es, ¿cuáles son algunas frutas bajas que se pasan por alto comúnmente al intentar mejorar el performance de la página web? Quiero decir, hay... oh sí. Ya sabes, frutas bajas. Creo que una de las más fáciles es, creo, el peso de la página. Porque si ves una página pesada, tienes que al menos preguntarte, ¿qué está pasando que me he perdido? Esa es la primera indicación. Y el siguiente paso es realmente hacer un rastreo, o realmente, solo mirar tus herramientas de desarrollo y un gráfico de cascada. Y sé que mucha gente no mira los gráficos de cascada. Lo he oído de boca de caballo, de hecho. Eso te indicará que algo no va bien y luego puedes empezar a investigar a fondo y averiguar exactamente qué está pasando. Así que creo que esa es la fruta más baja.

Bueno, podríamos seguir hablando, Henry, pero se nos acabó el tiempo. Henry va a estar en la sala de preguntas y respuestas de los oradores. Todas las preguntas increíbles, las veo. Lamento que no tuviéramos tiempo para hacerlas. No dudes en ir y hablar con Henry y él te dará todas las respuestas que estás buscando.