Video Summary and Transcription
Esta charla sobre rendimiento web y React explora varias métricas como el tiempo hasta la primera mordida, la pintura de contenido más grande, el cambio acumulativo de diseño y el primer retraso de entrada. Destaca los desafíos de JavaScript en impactar el tiempo total de bloqueo y la experiencia del usuario. Se discute el uso de dispositivos móviles y el rendimiento del dispositivo, junto con la importancia de medir y mejorar el rendimiento de la página. El orador también menciona la abundancia de tecnologías en la web de hoy y enfatiza la necesidad de priorizar la experiencia del usuario sobre el envío excesivo de JavaScript.
1. Introducción al Rendimiento Web
Buenos días a todos. O debería decir, buenos días, Dom. ¡Todavía estoy en Twitter! Estoy aquí para la Masterclass de React en EE. UU. Gracias naciones. Hola a Nueva Jersey. Lugar de nacimiento de Whitney Houston, el New York Times y Greg. Hoy vamos a hablar sobre el rendimiento web. No es tan malo. ¡Nos divertiremos!
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.
2. Introducción al Rendimiento de React
Bienvenidos a mi presentación sobre React y una mirada aterradora a las cifras de rendimiento. Exploraremos algunos datos interesantes y potencialmente tristes. Soy Henry, el fundador de Command H, una empresa de desarrollo web. Soy de Toronto, Canadá, y también soy corredor de larga distancia. ¡Empecemos!
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.
3. Introducción a la Web Moderna
Estamos discutiendo sobre React, que cumplió 10 años este año, marcando una era significativa en el desarrollo web. Hace una década, tecnologías como el iPhone 5S y Moto X eran nuevas. Sin embargo, un cambio crucial ocurrió en noviembre de 2016, remodelando la accesibilidad web, particularmente para los usuarios móviles. Este cambio indica nuestra entrada en los tiempos de la web moderna. La web ha evolucionado desde diseños simplistas, como los primeros Craigslist, hasta sistemas complejos, especialmente evidentes en plataformas que atienden a los fans de la NBA. La web de hoy integra casi 50 tecnologías, incluyendo actualizaciones en vivo, mostrando sus capacidades avanzadas.
Dicho esto, comencemos. Así que estamos aquí para hablar sobre React. Ahora, algunos de ustedes probablemente recuerdan que React cumplió 10 años este año, lo cual es realmente genial, y si miras atrás y piensas en lo que estaba sucediendo hace diez años, el iPhone 5S era lo nuevo. ¿Cuándo salió el iPhone 5S? Vale. Y, si eres del otro sabor, el Moto X era completamente nuevo, pero eso fue hace diez años. Pero algo realmente importante sucedió unos años después de eso, específicamente tres años después. En noviembre de 2016, trato de recordar a la gente todo el tiempo, esto fue una fecha significativa en la historia de la web para los desarrolladores también. Era incluso más accesible en el otoño que en el escritorio. Y eso sucedió en otoño de 2016, y quiero que tengan en cuenta que esto nunca, nunca, nunca, nunca, nunca, nunca, va a volver. ¿De acuerdo? Ahora, eso también indica que básicamente estamos en tiempos modernos. Y, sabes, una vez tuvimos la web que se veía así. Hablando de Craigslist, hablando de South Jersey, de acuerdo, real hablando de tecnología. Hay mucho pasando en la web ahora mismo. Tenemos un poco, no demasiadas, sabes, tecnologías en el capó aquí. Pero, sabes, la web de hoy se ve más o menos así, sabes, para los fans de la NBA. Hay mucho pasando aquí. Sabes, puede que no lo parezca, pero estamos hablando de solo menos de, como, 50 tecnologías trabajando bajo el capó, ¿sabes? Actualizaciones en vivo, ¿sabes? Como, hay tanto pasando aquí. Hay tanto pasando, ¿sabes? Y es la web y lo que es capaz de hacer y cómo se ve
4. Introducción al Rendimiento Moderno de la Web
Cuando hablamos de rendimiento moderno, necesitamos discutir las métricas modernas. Algunas de las métricas a las que prestamos atención hoy incluyen tiempo hasta la primera mordida, pintura de contenido más grande, tiempo total, cambio de diseño acumulativo, índice de velocidad, primer retraso de entrada e interacción hasta la siguiente pintura. Comencemos con la prueba de la página web, utilizando una herramienta llamada prueba de la página web. Proporcionaré una instantánea de la web desde una perspectiva de rendimiento y discutiré las herramientas que usamos, como el archivo HP y el informe CWV tech dot.
hoy. Cuando hablamos de la Web moderna, también queremos hablar sobre el rendimiento moderno. Porque si vas a hablar y trabajar con la Web moderna en tus dispositivos, cuando haces un seguimiento del rendimiento, estamos hablando de rendimiento moderno. Y, sabes, siempre que el rendimiento viene a la mente, tenemos que discutir la idea de las métricas. Y, sabes, sentía como, sabes, podríamos hacer clic, clic, ok, 8. 5 segundos, estamos bien, pero las métricas modernas o el rendimiento moderno también requieren métricas modernas. Y estamos aquí hoy.
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.
5. Introducción a los Indicadores Clave
Entonces, es esencialmente un informe de indicadores clave. Y son datos RUM. Y también voy a extraer datos del archivo RUM. Los indicadores clave se componen de tres métricas: completitud visual, pintura de contenido más grande (LCP) y estabilidad de la página (CLS). El CLS es una métrica que mide el cambio de diseño acumulativo, con una puntuación de 0.1 o menos siendo excelente. La interactividad también es un aspecto importante a considerar.
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.
6. Analizando las Métricas de Rendimiento de la Web y React
¿Qué sucede cuando haces clic en ese botón de comprar en tu entrada para la Masterclass de React en EE.UU? Hablamos sobre el FID, el retraso de la primera entrada. Ahora, los datos. Vamos a comparar cómo se ve la web y cómo se ven los sitios de React. La web tiene un buen LCP a una tasa de alrededor del 59%, React al 47.4%. Cuando se trata de CLS y la estabilidad de la página, la web lo está haciendo bien a una tasa de alrededor del 75%. El FID, el retraso de la primera entrada, la web y React están pasando a una tasa del 96% y 96.5% respectivamente. Pero para aquellos que rastrean el rendimiento, esta es una métrica con la que hemos tenido algunos desafíos.
¿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.
7. Introducción a las Métricas de Interactividad
Bueno, se descubrió que la métrica de interactividad se estaba rastreando incorrectamente y será reemplazada por la métrica de Interacción al Siguiente Rosa. El promedio de INP de React es del 80%, lo que indica un rendimiento mediocre o pobre. Esta interactividad es crucial para que la web funcione de manera efectiva.
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?
8. JavaScript y Tiempo Total de Bloqueo
JavaScript tiene este nivel de toxicidad que simplemente necesitamos tener en cuenta. La web está enviando alrededor de 560 kilobytes de JS, mientras que los sitios de React están enviando casi 1200 kilobytes. Los 100,000 sitios de React más importantes están enviando 436 kilobytes, el doble de lo que está haciendo la web. El tiempo total de bloqueo se ve influenciado por la abundancia de JavaScript y puede impactar negativamente en la experiencia del usuario. Las métricas móviles tienden a ser peores que las métricas de escritorio, con más dispositivos móviles en línea que de escritorio.
Ahora, veamos más data. Super divertido. Ahora, estamos hablando de JavaScript, ¿verdad? Y solo un recordatorio de que un kilobyte de JS no es igual a un kilobyte de, digamos, imágenes. Datos de imagen. JavaScript tiene este nivel de toxicidad que simplemente necesitamos tener en cuenta. Sabes, de nuevo, no estamos odiando a JS. Al menos yo no. Alguien más en mi presentación lo hará. Pero esto es importante saberlo. Así que veamos algunos data aquí del archivo HTTP. Entonces, en el percentil 50, la web está enviando alrededor de 560 kilobytes de JS. Genial. Ahora, si comparamos eso con lo que los sitios de React están haciendo, aparentemente todos están felices. Casi 1200 kilobytes. ¿De acuerdo? Y esto ha ido aumentando año tras año. Un aumento del 12% año tras año desde el año pasado. Ahora, si miramos los 100,000 sitios de React más importantes, están enviando 436 kilobytes en el percentil 50, que es básicamente el doble de lo que está haciendo la web en los 100,000 sitios más importantes. Ahora, otra métrica que me costó traer pero no quería hacerlo porque casi merece su propia charla es el tiempo total de bloqueo. Para aquellos que siguen, no sé, las puntuaciones de lighthouse, esto vale mucho en tu puntuación, ¿de acuerdo? El problema es que JavaScript, la abundancia de este tiende a influir en el tiempo total de bloqueo, aumentarlo, y probablemente empezar a, sabes, perjudicar tu experiencia de usuario. Voy a llegar a eso en un minuto, pero quiero mencionarlo aquí. Ahora veamos más data. Esto es super divertido. Solo un recordatorio de que, de nuevo, lo que mencioné antes, tenemos más usuarios móviles que usuarios de escritorio, en general. Y las métricas de escritorio tienden a ser mejores que las métricas móviles, tiene sentido. Sabes, aún no tenemos laptops M3 y teléfonos móviles. Pero en general, solo quieres tener eso en cuenta. Así que por ejemplo, estos son los datos de Akamai rum data. El tráfico de Internet se ve así. De nuevo, más dispositivos móviles en línea que de escritorio. A una tasa del 80% más. De acuerdo.
9. Uso Móvil y Rendimiento del Dispositivo
Bien, 61.4 versus casi 34. El uso móvil aumenta los fines de semana. El 67% de los sitios tienen más tráfico móvil que de escritorio. Los dispositivos Android no son tan potentes, lo que resulta en un peor tiempo total de bloqueo en móviles. Esto es algo llamado 'rage-clicking'.
61.4 versus casi 34. Ahora, esta es una captura de pantalla realmente interesante y quiero compartirla. Ahora, vas a ver esa parte donde me detengo el 1 de julio, y ves el móvil a una tasa de casi el 70%. Este es el tipo de punto de data que ocurre bastante a menudo. ¿Por qué? Tenemos fines de semana festivos. ¿Por qué? Tenemos fines de semana en general. El uso móvil aumenta los fines de semana en comparación con el resto de la semana. Así que, aún más data que te demuestra que estamos en una sociedad de dispositivos móviles.
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.
10. Rendimiento de JavaScript y Experiencia de Usuario
Dinotrace y Sentry tienen sus propias métricas para rastrear la miseria del usuario causada por JavaScript golpeando el hilo principal. JavaScript es la forma más rápida de construir un sitio web lento. La medición es crucial para la mejora, utilizando herramientas como WebPagetest, Lighthouse, Debugbear y Trio. Sé conservador al enviar JavaScript y prioriza la experiencia del usuario. El rendimiento de la página es ahora una parte crucial de la experiencia del usuario. La página de inicio de la NBA, construida con React, tuvo un rendimiento deficiente en múltiples métricas. Se llevarán a cabo múltiples discusiones y presentaciones de rendimiento en esta conferencia.
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.
11. Redes Sociales y Preguntas y Respuestas
Se espera que tres oradores, Ivan, Ken y Medhat, realicen una transmisión. Puedes seguir al orador en varias plataformas sociales como Instagram, Twitter, Bastodon y Blue Sky. Se dirigieron dos preguntas a Henry. La primera preguntaba por qué las páginas web de React generalmente tienen códigos JS más grandes. Henry enfatizó la importancia de probar y entender lo que está sucediendo en lugar de asignar culpas. La segunda pregunta se centró en métodos a menudo pasados por alto para mejorar el rendimiento de la página web. Henry destacó la importancia de monitorear el peso de la página, ya que es un indicador inicial de posibles problemas. Recomendó el uso de herramientas de desarrollo y un gráfico de cascada para un análisis más profundo. Aunque hubo muchas preguntas excelentes, las limitaciones de tiempo limitaron la discusión, y Henry dirigió a los asistentes a la sala de preguntas y respuestas del orador para más consultas.
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.
Comments