Soy Paul Kinlan y dirijo las relaciones con desarrolladores de Chrome. Como parte de mi trabajo, trabajo con un equipo de apasionados defensores de la Web que tienen la tarea de llevar la perspectiva de los desarrolladores del mundo real a nuestros equipos de productos y de ingeniería, con la métrica de norte estrella para mejorar la satisfacción de los desarrolladores.
Reconocemos que la "satisfacción" es una métrica ambiciosa y subjetiva para hacer un seguimiento y mejorar, por lo que iteramos constantemente sobre cómo podemos generar un impacto y, al mismo tiempo, enfocarnos en las necesidades de los desarrolladores. Un principio rector que nos resultó útil seguir es "encontrarse con los desarrolladores donde estén". Un estudio reciente de Stack Overflow mostró que el 75% de los desarrolladores informa que usa frameworks o algún tipo de abstracción. Por lo tanto, nos preguntamos cómo brindar la mejor asistencia a los desarrolladores que ya tomaron decisiones sobre su pila de tecnología o no tienen control sobre ella. ¿Cómo podemos hacerlos más productivos sin agregar más sobrecarga?
Un pequeño equipo de Chrome ha estado trabajando en un proyecto llamado Aurora, con el objetivo de trabajar con abstracciones de terceros de la plataforma web, como frameworks y bibliotecas. Su objetivo es ayudar a obtener mejoras de rendimiento directamente en estas abstracciones, en lugar de que la carga recaiga en sus clientes, los desarrolladores web.
Para la tercera edición de Chrome Dev Insider, hablé con Addy Osmani, Kara Erickson y Houssein Djirdeh del equipo de Project Aurora para obtener más información sobre cómo se están acercando a este proyecto y qué les espera en el futuro.
Información privilegiada: Cómo trabajar con frameworks de terceros
Comencemos con el origen de este proyecto. ¿Cómo surgió?
Addy: Aurora comenzó con una idea simple: conocer a los desarrolladores donde están y ayudarlos a llegar a donde necesitan ir. Por ejemplo, ayudar a la pila de tecnología popular que eligieron para mejorar el rendimiento. En la actualidad, muchos desarrolladores de apps compilan con React, Vue o Angular, o bien metaframeworks* como Next.js y Nuxt (y, por supuesto, muchos otros…). Svelte, Lit, Preact y Astro. La lista sigue). En lugar de esperar que estos desarrolladores se conviertan en expertos (por ejemplo, en el rendimiento), podríamos asegurarnos de que tengan éxito incorporando más prácticas recomendadas de forma predeterminada en estas pilas. De esta manera, los sitios de mejor calidad son un efecto secundario de la compilación para la Web.
Aurora elige algunos frameworks y metaframeworks de uso general para asociarse. Documentamos nuestros aprendizajes (como cómo compilar un buen componente de imagen) para que otras personas puedan seguirlos rápidamente y tratar de escalar a través de otros frameworks y herramientas a través del Fondo de Frameworks de Chrome. Si bien es posible mejorar la calidad de las experiencias web a través del navegador, creemos que este objetivo también se puede lograr (en algunos casos) a través de frameworks. Esperamos que esto nos ayude a alcanzar nuestros objetivos de crear una Web de mayor calidad para todos.
Kara: Para ampliar esa idea, la idea es mejorar el rendimiento en la Web mejorando la experiencia del desarrollador. No basta con publicitar las prácticas recomendadas de rendimiento, ya que suelen cambiar y es difícil para las empresas seguir el ritmo. Tienen sus propias prioridades comerciales que probablemente se antepondrán al rendimiento.
Por lo tanto, pensamos que, si los desarrolladores tienen tiempo limitado para dedicar al rendimiento, debemos facilitarles (y acelerarles) la compilación de una app con un buen rendimiento. Si nos asociamos con frameworks web populares, nos encontramos en la capa de abstracción correcta para mejorar la experiencia de los desarrolladores a través de componentes de nivel superior, advertencias de conformidad, etc. Cualquier persona que use esas herramientas populares tendrá acceso a estos beneficios. Y, en teoría, si cambia el consejo recomendado, podemos actualizar nuestros componentes en segundo plano y los desarrolladores no tienen que preocuparse por mantenerse al día.
Houssein: Me uní a Google como promotor de desarrolladores antes de cambiar a un puesto de ingeniería de software unos años más tarde. Gran parte de mi trabajo anterior consistió en enseñar a los desarrolladores web las diferentes formas de crear experiencias del usuario excelentes. Se proporcionaron variaciones de la misma guía una y otra vez para advertir a los desarrolladores sobre los problemas habituales que probablemente afecten el rendimiento y la usabilidad de sus sitios. Cuando comenzamos a pensar en el proyecto Aurora, nos preguntamos: ¿Podemos avanzar en una dirección en la que nunca tengamos que decirles a los desarrolladores qué hacer porque su cadena de herramientas se encarga de todo por ellos?
Si entendí bien, tu equipo está formado por seis ingenieros, ¿es correcto? Apuesto a que no puedes trabajar con todos los frameworks o bibliotecas posibles. Entonces, ¿cómo eliges con quién trabajar? ¿Quiénes son?
Addy: La Web es, en muchos sentidos, como el Salvaje Oeste. Puedes elegir prácticamente cualquier framework, empaquetador, bibliotecas y terceros que desees. Esto introduce varias capas de complejidad que pueden contribuir a un rendimiento bueno o deficiente. Una de las mejores maneras de mejorar el rendimiento es encontrar esas capas que se sientan cómodas con tener opiniones y agregarles más.
Por ejemplo, los frameworks web (Next.js, Nuxt.js y, en cierta medida, Angular) intentan incorporar más opiniones y parámetros predeterminados que una solución más manual. Esta es una de las razones por las que nos encanta trabajar con ellos. Tener valores predeterminados más sólidos para cargar imágenes, fuentes y secuencias de comandos para mejorar las Métricas web esenciales tiene sentido en estos modelos.
También sirve como una buena forma de confirmar dónde funcionan las prácticas recomendadas modernas o si es necesario replantearlas, y puede ayudar a informar a todo el ecosistema sobre cómo abordar la resolución de problemas de optimización.
Kara: En realidad, también debemos considerar la popularidad. Si queremos tener el mayor impacto posible en la Web, lo ideal es trabajar con frameworks y bibliotecas que tengan una gran comunidad existente de desarrolladores. De esta manera, podemos llegar a más desarrolladores y más apps. Pero no puede ser solo la popularidad. En última instancia, es una intersección de popularidad, la opinión que tiene una biblioteca y el conjunto de funciones disponibles con las que podemos trabajar.
Por ejemplo, si solo nos fijamos en la popularidad, React, Vue y Angular son los “tres grandes” que se deben tener en cuenta. Sin embargo, trabajamos más con Next.js, Nuxt y Angular. Esto se debe a que las bibliotecas de vistas, como React y Vue, se enfocan principalmente en la renderización, por lo que es imposible compilar todas las funciones que queremos directamente en ellas. Por lo tanto, trabajamos más estrechamente con metaframeworks con opiniones que se compilan sobre ellos: Next.js y Nuxt. En este nivel de abstracción, podemos crear componentes integrados. También tienen servidores integrados, por lo que podemos incluir optimizaciones del servidor.
Es posible que notes que Angular estaba en esa lista de asociaciones sólidas, pero no es un metaframework. Angular es un caso especial porque es bastante popular, pero no tiene un metaframework complementario como React y Vue. Por lo tanto, trabajamos con ellos directamente y contribuimos con funciones a través de su CLI siempre que sea posible.
Además, vale la pena señalar que tenemos varias relaciones en curso con otros proyectos, como Gatsby, en los que nos sincronizamos con cierta regularidad en el diseño, pero no contribuimos activamente con el código.
Entonces, ¿cómo se ve esto en la práctica? ¿Cuál fue tu enfoque para resolver este problema?
Kara: En la práctica, tenemos algunos frameworks con los que colaboramos estrechamente. Nos tomaremos un tiempo para generar perfiles de las apps que usan ese framework y descubrir los problemas de rendimiento comunes. Luego, trabajamos con el equipo del framework para diseñar funciones experimentales que resuelvan esos problemas y contribuir con código directamente al repositorio de código abierto para implementarlas.
Para nosotros, es muy importante validar que el impacto en el rendimiento sea el que predijimos, por lo que también trabajamos con empresas externas para realizar pruebas de rendimiento en producción. Si los resultados son alentadores, ayudaremos a que la función sea "estable" y, posiblemente, la establezcamos como predeterminada.
Todo esto no puede ser tan fácil como lo haces sonar. ¿Cuáles fueron algunos de los desafíos o aprendizajes que tuviste hasta ahora?
Houssein: Una cosa importante que intentamos hacer lo mejor que podemos es contribuir a repositorios populares de código abierto que tienen muchas prioridades en competencia. El hecho de que seamos un equipo de Google no significa necesariamente que nuestras funciones se priorizarán, por lo que hacemos todo lo posible para alinearnos con el proceso típico de proponer y enviar funciones nuevas sin pisar el terreno de nadie. Tuvimos la gran suerte de trabajar con mantenedores receptivos en los ecosistemas de Next.js, Nuxt y Angular. Agradecemos que hayan escuchado nuestras inquietudes sobre el ecosistema web y que estén dispuestos a colaborar con nosotros de diferentes maneras.
Con muchos de los frameworks con los que trabajamos, nuestra misión general es la misma: ¿Cómo pueden los desarrolladores obtener una experiencia del usuario mejorada de forma inmediata y, al mismo tiempo, disfrutar de una gran experiencia de desarrollador? Sabemos y respetamos que hay cientos, si no miles, de colaboradores de la comunidad y mantenedores de frameworks que trabajan en diferentes proyectos que se cruzan entre sí.
Kara: Además, como nos preocupa validar el impacto en el rendimiento y actuar en función de los datos, el proceso lleva un poco más de tiempo. Estamos en un territorio desconocido, por lo que, a veces, experimentaremos con una optimización que no funcione y no terminemos por crear una función planificada. Incluso cuando una función funciona, esos pocos pasos adicionales para verificar el rendimiento llevan tiempo y extienden los plazos.
Encontrar socios de producción para probar nuestras funciones también puede ser un desafío. Como se mencionó anteriormente, son empresas y tienen sus propias prioridades, por lo que puede ser un desafío para ellos adaptarse a iniciativas nuevas si no se alinean bien con los proyectos existentes que deben priorizarse. Además, las empresas más interesadas en recibir ayuda suelen invertir tiempo en el rendimiento, por lo que no son nuestro público objetivo. Intentamos recopilar comentarios de la gran parte de la comunidad que no puede invertir en el rendimiento, pero es la menos propensa a comunicarse con nosotros.
Seguimos adelante. ¿En qué tipo de optimizaciones te has enfocado?
Houssein: Después de analizar miles de aplicaciones, descubrimos que los mayores problemas de rendimiento suelen deberse a patrones contraproducentes en el código de la aplicación en lugar del framework en sí. Por ejemplo, enviar imágenes innecesariamente grandes, cargar fuentes personalizadas demasiado tarde, recuperar demasiadas solicitudes de terceros que bloquean el subproceso principal y no controlar cómo el contenido asíncrono puede hacer que otros elementos cambien en la página. Todos estos problemas pueden surgir independientemente de la herramienta que uses, por lo que pensamos: ¿Podemos incorporar algunas optimizaciones predeterminadas que los manejen bien, pero con una experiencia del desarrollador ordenada que se ajuste bien a sus herramientas de framework?
Con este enfoque, enviamos lo siguiente:
- Componente de imagen de Next.js.
- Componente de secuencia de comandos de Next.js.
- Inserción automática de fuentes en el proceso de compilación de Next.js.
- Directiva de imagen de Angular.
- Complemento ESLint de conformidad con Next.js para proporcionar orientación práctica a los desarrolladores.
Nuestro trabajo inspiró a otros frameworks y herramientas para implementar optimizaciones similares. Estos son algunos ejemplos:
- Módulo de imagen de Nuxt
- Anulaciones de métricas de fuentes de Nuxt
- Componente de secuencia de comandos de Nuxt (en curso)
- Componente de la secuencia de comandos de Gatsby
¿Puedes compartir algunos resultados positivos de tu trabajo con algunos de estos jugadores?
Houssein: Muchos sitios observaron mejoras en el rendimiento debido a las optimizaciones que enviamos. Uno de mis ejemplos favoritos es Leboncoin, que redujo su LCP de 2.4 s a 1.7 s después de cambiar al componente de imagen de Next.js. Actualmente, hay muchos más en fases de experimentación y prueba, y seguiremos compartiendo los aprendizajes y los logros de esos aquí.
De acuerdo, entiendo que te enfocas en los que tienen más popularidad, pero ¿hay formas en que otros frameworks o bibliotecas con los que no trabajas de forma proactiva también se beneficien?
Addy: Cualquier framework puede replicar muchas de las optimizaciones de rendimiento en las que colabora Aurora. Por ejemplo, si observas nuestros esfuerzos en los componentes de imagen o de secuencia de comandos, a menudo codifican un conjunto existente de prácticas recomendadas. Intentamos documentar el “cómo” de compilar esos componentes y cómo se ven en cada framework. Espero que esto sea un buen comienzo para copiar la idea.
Hemos tenido mucho éxito con la transferencia de los aprendizajes de un ecosistema (por ejemplo, React y Next.js) a otros. Por ejemplo, la nueva Directiva de imagen de Angular (basada en nuestros aprendizajes para crear el componente de imagen de Next.js) o Gatsby que envía nuestro enfoque de fragmentación granular de JavaScript.
Al mismo tiempo, comprendemos que no todos los frameworks tendrán el ancho de banda ni la financiación para que los colaboradores creen funciones de rendimiento similares o inviertan en otras optimizaciones que consideren importantes para sus usuarios. El Fondo de Frameworks Web de Chrome es una forma para que patrocinamos el trabajo de rendimiento en el ecosistema de JavaScript para permitir que los proyectos paguen a sus colaboradores y que el trabajo de rendimiento se expanda aún más en el ecosistema.
¿Cuál es la hoja de ruta de tu equipo?
Kara: Tenemos muchos proyectos emocionantes en camino. Algunos aspectos destacados:
- Reducción del CLS relacionado con las fuentes: Es bastante común ver cambios de diseño cuando se carga una fuente web y se reemplaza la fuente de resguardo. Estamos explorando el uso de anulaciones de métricas de fuente y la propiedad "size-adjust" para reducir el CLS relacionado con la fuente de forma predeterminada en Next.js. También consultamos con el equipo de Nuxt sobre este tema y planeamos extender esta idea a más frameworks el próximo año.
- Depuración de INP: Ahora que se lanzó la métrica Interaction to Next Paint (INP), estamos trabajando con frameworks para investigar las causas raíz más comunes de los problemas de INP para sus comunidades y sugerir correcciones. Nos asociamos estrechamente con Angular en este tema y esperamos tener algunos resultados para compartir pronto.
- Optimiza las secuencias de comandos comunes de terceros: Cargar secuencias de comandos de terceros en el momento equivocado puede tener un impacto negativo sustancial en el rendimiento. Dado que hay algunos proveedores externos muy comunes, estamos investigando si podemos ofrecer algunos wrappers para garantizar que se carguen de forma óptima con frameworks y no bloqueen el subproceso principal. Usamos el componente de secuencia de comandos de Next.js que compilamos como punto de partida para esta investigación.
Los desarrolladores pueden seguir nuestro progreso en este sitio.
En las noticias
Antes de despedirme, quería dejarte algunas actualizaciones interesantes del mundo de los frameworks que se están desarrollando en Google.
En julio, el equipo de Chrome anunció la última ronda de financiación de USD 500,000 para el fondo de herramientas y frameworks, que se enfoca en financiar proyectos que tienen como objetivo mejorar el rendimiento, la experiencia del usuario y la del desarrollador en la Web. En el futuro, se considerarán proyectos nuevos, así que recuerda enviar tu solicitud.
Y, por supuesto, también suceden muchas cosas increíbles en la comunidad. El ecosistema está repleto de nuevos frameworks, como Fresh de Deno, y experiencias increíbles, como el instructivo de integración de Svelte, que no solo es una demostración en el navegador, sino que también usa la API de Web Container para ejecutar Node.js de forma nativa en el navegador. ¡Hay mucho contenido bueno!
Me entusiasma ver cómo se unen los componentes del ecosistema, cómo se aprovecha al máximo el navegador y cómo se ayuda a los desarrolladores a crear productos que funcionen para todos. Es un momento emocionante para ser desarrollador web.
Hasta la próxima actualización de Insider, Hwyl fawr.
¿Qué te pareció esta edición de Chrome Dev Insider? Comparte tus comentarios.