Mi nombre es Paul Kinlan y soy líder de Relaciones con Desarrolladores de Chrome. Como parte de mi trabajo, trabajo con un equipo de apasionados usuarios de la Web que se encargan de mostrar la perspectiva de los desarrolladores del mundo real a nuestros equipos de ingeniería y productos, con la métrica guía 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 repetimos constantemente cómo podemos generar un impacto mientras nos enfocamos en las necesidades de los desarrolladores. Un principio rector que nos resultó útil es "conocer a los desarrolladores donde estén". En un estudio reciente de Stack Overflow, se demostró que el 75% de los desarrolladores informan usar frameworks o algún tipo de abstracción. Por lo tanto, nos preguntamos cuál es la mejor manera de servir a los desarrolladores que ya tomaron decisiones sobre su pila tecnológica o que no tienen control sobre ella. ¿Cómo podemos hacer que sean 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 incorporar mejoras de rendimiento directamente en estas abstracciones, en lugar de hacer que la carga recaiga sobre 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 su enfoque en este proyecto y lo que les espera.
Información privilegiada: Cómo trabajar con marcos de trabajo de terceros
Comencemos con la génesis de este proyecto. ¿Cómo surgió?
Addy: Aurora comenzó con una idea simple: vamos a conocer a los desarrolladores donde están y ayudarlos a llegar a donde deben ir. Por ejemplo, ayudar a la popular pila tecnológica que eligieron para mejorar el rendimiento. Muchos desarrolladores de apps realizan compilaciones con React, Vue o Angular en la actualidad (o metaframeworks* como Next.js y Nuxt) (y, por supuesto, muchos otros... Svelte, Lit, Preact, Astro. La lista continúa). En lugar de esperar que estos desarrolladores se conviertan en grandes expertos (por ejemplo, en el rendimiento), podríamos asegurarnos de que caigan en la pobre del éxito incorporando más prácticas recomendadas de forma predeterminada en estas pilas. De este modo, sitios de mejor calidad son un efecto secundario de la simple compilación para la Web.
Aurora elige algunos frameworks y metamarcos de uso general para asociarse con ellos. Documentamos nuestros aprendizajes (por ejemplo, cómo crear un buen componente de imagen) para que otros puedan seguirlos rápidamente e intentar escalarlos con otros frameworks y herramientas a través del Chrome Frameworks Fund. 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) mediante frameworks. Esperamos que esto nos ayude a lograr nuestros objetivos de una Web de mayor calidad para todos.
Kara: Para ampliar eso, la idea es mejorar la experiencia de los desarrolladores para mejorar el rendimiento en la Web. No es suficiente promocionar las prácticas recomendadas de rendimiento porque suelen cambiar y es difícil para las empresas seguir el ritmo de estos cambios. Tienen sus propias prioridades empresariales que probablemente aparecerán antes que el rendimiento.
Por lo tanto, pensamos que, si los desarrolladores tienen un tiempo limitado para dedicarse al rendimiento, hagamos que sea más fácil (y más rápido) compilar una app con buen rendimiento. Si nos asociamos con frameworks web populares, estamos en la capa correcta de abstracción para mejorar la experiencia de los desarrolladores a través de componentes de nivel superior, advertencias de cumplimiento, etc. Cualquiera que use esas herramientas populares tendrá acceso a estos beneficios. Y, en teoría, si los consejos recomendados cambian, podemos actualizar nuestros componentes de forma interna, y los desarrolladores no tienen que preocuparse por mantenerse actualizados.
Houssein: Me uní a Google como Developer Advocate antes de cambiarme a una función de ingeniería de software unos años más tarde. Gran parte de mi trabajo anterior consistió en enseñarles a los desarrolladores web las diversas formas de crear excelentes experiencias del usuario. Se proporcionaron variaciones de la misma orientación, una y otra vez, para advertir a los desarrolladores sobre los problemas habituales que probablemente afectarán el rendimiento y la usabilidad de sus sitios. Cuando comenzamos a pensar en el proyecto Aurora, nos preguntamos si podíamos dirigirnos hacia una dirección en la que nunca tener que decirles a los desarrolladores qué hacer porque su cadena de herramientas se encarga de todo por ellos.
Si entiendo bien, ¿eres un equipo de seis ingenieros? 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: En muchos sentidos, la Web es similar al salvaje Oeste. Puedes elegir casi cualquier framework, agrupador, 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 influir en el rendimiento es sentir que esas capas se sienten cómodas al momento de decidirse y agregarles más opiniones.
Por ejemplo, los frameworks web (Next.js, Nuxt.js y, hasta cierto punto Angular), intentan generar más opiniones y valores predeterminados que una solución más enrollada a mano. Esta es una de las razones por las que nos encanta trabajar con ellos. En estos modelos, tiene sentido contar con valores predeterminados más sólidos sobre cómo cargar imágenes, fuentes y secuencias de comandos para obtener mejores Métricas web esenciales.
También sirve como una buena manera de confirmar dónde funcionan las prácticas recomendadas modernas o dónde es posible que sea necesario reconsiderarlas, y puede ayudar a informar a todo el ecosistema sobre cómo abordar la resolución de problemas de optimización.
Kara: Siendo realista, también debemos tener en cuenta 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 popularidad. En última instancia, se trata de una intersección entre popularidad, lo bien definida que es una biblioteca y el conjunto de atributos disponible con el que podemos trabajar.
Por ejemplo, si solo analizamos la popularidad, React, Vue y Angular son los “tres grandes” que se deben considerar. Pero 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 en ellas directamente. Por lo tanto, trabajamos más de cerca con metaframeworks bien definidos que se basan en 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 lado del servidor.
Quizás notes que Angular estaba en esa lista de asociaciones profundas, pero no es un metaframework. Angular es un caso especial porque es muy popular, pero no tiene un metaframework complementario como lo hacen React y Vue. Por lo tanto, trabajamos con ellos directamente y aportamos atributos a través de la CLI cuando es posible.
Y cabe mencionar que tenemos varias relaciones en curso con otros proyectos como Gatsby en los que sincronizamos con cierta frecuencia el diseño, pero no aportamos código de forma activa.
¿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 marcos con los que colaboramos estrechamente. Dedicaremos un tiempo a generar perfiles de las apps con ese framework y descubrir los problemas comunes de rendimiento. Luego, trabajamos con el equipo del framework para diseñar características experimentales que permitan resolver esos puntos débiles y contribuiremos con código directamente al repositorio de OSS para implementarlos.
Para nosotros es muy importante validar que el impacto en el rendimiento es lo 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 se vuelva "estable" y, posiblemente, se establezca 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 aprendimos hasta ahora?
Houssein: Algo importante que tratamos de explorar lo mejor que podemos es contribuir a los repositorios de código abierto populares que tienen muchas prioridades en competencia. El hecho de ser un equipo de Google no significa necesariamente que se prioricen nuestras funciones, por lo que hacemos todo lo posible para alinearnos con el proceso típico de proponer y presentar nuevas funciones sin invadir a nadie. Somos muy afortunados de trabajar con encargados de mantenimiento receptivos en los ecosistemas Next.js, Nuxt y Angular. Agradecemos que se hayan abierto a escuchar nuestras preocupaciones sobre el ecosistema web y que estén dispuestos a colaborar con nosotros de más 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 inmediato y, al mismo tiempo, disfrutar de una excelente experiencia como desarrollador? Sabemos y respetamos que hay cientos, si no miles, de colaboradores de la comunidad y encargados de mantenimiento del framework, cada uno trabajando en diferentes proyectos que se cruzan entre sí.
Kara: Además, como nos importa 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 realizamos experimentos con una optimización que no funcione y no terminemos desarrollando una función planificada. Incluso cuando una función resulta satisfactoria, esos pasos adicionales para examinar el rendimiento toman tiempo y amplían los plazos.
Encontrar socios de producción que prueben nuestras funciones también puede ser todo un desafío. Como se mencionó anteriormente, son empresas y tienen sus propias prioridades, por lo que puede ser un desafío para ellos incorporar nuevas iniciativas si no se alinean bien con los proyectos existentes que deben ocurrir primero. Además, las empresas más interesadas en ayudar tienden a tomarse el tiempo necesario para invertir en el rendimiento, por lo que, en realidad, no son nuestro público objetivo. Estamos tratando de recopilar comentarios de toda la comunidad que no puede invertir en rendimiento, pero es el que es menos probable que se comunique con nosotros.
Avancemos. ¿En qué tipo de optimizaciones te enfocas?
Houssein: Después de analizar miles de aplicaciones, descubrimos que los mayores problemas de rendimiento suelen deberse a antipatrones en el código de la aplicación y no al 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 la forma en que el contenido asíncrono puede hacer que otros elementos se modifiquen en la página. Todos estos problemas pueden surgir independientemente de la herramienta que uses. Entonces, pensamos: ¿podemos integrar algunas optimizaciones predeterminadas que los manejen bien, pero con una experiencia de desarrollador prolija que se adapte bien a sus herramientas de framework?
Pensando en esto, enviamos:
- Componente de imagen Next.js.
- Componente de secuencia de comandos Next.js.
- Inserción automática de fuentes en el proceso de compilación de Next.js
- Directiva de imagen angular.
- Complemento ESLint de conformidad de Next.js para brindar orientación práctica a los desarrolladores.
Nuestro trabajo inspiró otros frameworks y herramientas para implementar optimizaciones similares. Estos son algunos ejemplos:
- Módulo de imagen Nuxt
- Anulaciones de métricas de fuentes Nuxt
- Componente de la secuencia de comandos de Nuxt (en curso)
- Componente de secuencia de comandos de Gatsby
¿Puedes compartir algunos resultados positivos de tu trabajo con algunos de estos actores?
Houssein: Muchos sitios experimentaron 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 Next.js. Actualmente, hay muchas más etapas de experimentación y pruebas. Seguiremos compartiendo los aprendizajes y los logros de esos participantes aquí.
Entiendo que te enfoques en los que tienen más popularidad, pero ¿hay formas en que otros frameworks o bibliotecas con los que no estás trabajando de forma proactiva también se beneficien?
Addy: Muchas de las optimizaciones de rendimiento en las que colabora Aurora se pueden replicar mediante cualquier framework. Por ejemplo, echemos un vistazo a nuestros esfuerzos de componentes de imagen o secuencia de comandos. Por ejemplo, a menudo codifican un conjunto existente de prácticas recomendadas. Intentamos documentar el “cómo” para crear esos componentes y el aspecto que tienen en cada framework. Espero que este sea un buen comienzo para copiar la idea.
Tuvimos éxito bastante en la incorporación de los aprendizajes de un ecosistema (por ejemplo, React y Next.js) y implementarlos en otros. Por ejemplo, la nueva Directiva de imágenes de Angular (creada sobre la base de lo aprendido en la compilación del componente de imagen Next.js) o Gatsby presentó nuestro enfoque sobre la fragmentación detallada de JavaScript.
Al mismo tiempo, entendemos que no todos los frameworks tendrán el ancho de banda o la financiación para que los colaboradores creen funciones de rendimiento similares o inviertan en otras optimizaciones que consideren importantes para sus usuarios. El Chrome Web Frameworks Fund es una forma de patrocinar el trabajo de rendimiento en el ecosistema de JavaScript para permitir que los proyectos paguen a sus colaboradores y posibiliten el escalamiento del trabajo de rendimiento en el ecosistema.
Entonces, ¿cuál es el plan de acción que tendrá tu equipo?
Kara: ¡Tenemos muchos proyectos emocionantes por venir! Algunos aspectos destacados:
- Reducir el CLS relacionado con la fuente: Es bastante común ver cambios de diseño cuando se carga una fuente web y 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 fuentes de forma predeterminada en Next.js. También consultamos al equipo de Nuxt sobre este tema y planeamos extender esta idea a otros marcos de trabajo el próximo año.
- Depuración de INP: Ahora que se lanzó la métrica Interaction to Next Paint (INP), estamos trabajando con marcos de trabajo para investigar las causas raíz más comunes de los problemas de INP en sus comunidades y sugerir soluciones. Hemos estado trabajando estrechamente con Angular y esperamos tener algunos resultados para compartir pronto.
- Optimización de secuencias de comandos comunes de terceros: Cargar secuencias de comandos de terceros en el momento incorrecto puede tener un impacto negativo considerable en el rendimiento. Dado que hay algunos terceros que son muy comunes, estamos evaluando si podemos ofrecer algunos wrappers para garantizar que se carguen de manera óptima con los frameworks y no bloqueen el subproceso principal. Estamos usando el componente de secuencia de comandos Next.js que creamos 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 compartir algunas actualizaciones interesantes sobre el mundo de los frameworks que ocurren en Google.
En julio, el equipo de Chrome anunció la última ronda de financiación de USD 500,000 para el Fondo de marcos de trabajo y herramientas, que se enfoca en financiar proyectos destinados a mejorar el rendimiento, la experiencia del usuario y la experiencia del desarrollador en la Web. En el futuro, se considerarán nuevos proyectos, por lo que debes recordar enviar tu solicitud.
Y, por supuesto, también hay 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 utiliza la API de Web Container para ejecutar Node.js de forma nativa en el navegador. ¡Hay muchas cosas buenas!
Me entusiasma mucho ver cómo el ecosistema se une, impulsa lo que es posible en el navegador y ayuda a los desarrolladores a crear productos que funcionen para todas las personas. Es un gran momento para ser desarrollador web.
Hasta el próximo Insider, Hwyl fawr.
¿Qué te pareció esta edición de Chrome Dev Insider? Comparte tus comentarios.