Meu nome é Paul Kinlan, e sou líder de relações com desenvolvedores do Chrome. Como parte do meu trabalho, trabalho com uma equipe de defensores da Web encarregados de levar a perspectiva dos desenvolvedores reais às nossas equipes de produto e engenharia, com a principal métrica de melhorar a satisfação dos desenvolvedores.
Reconhecemos que a "satisfação" é uma métrica ambiciosa e subjetiva para acompanhar e melhorar. Por isso, sempre iteramos sobre como podemos causar impacto, enquanto focamos nas necessidades do desenvolvedor. Um princípio orientador que achamos útil seguir é "atender aos desenvolvedores onde eles estiverem". Um estudo recente do Stack Overflow mostrou que 75% dos desenvolvedores relatam usar frameworks ou algum tipo de abstração. Nos perguntamos qual é a melhor forma de atender aos desenvolvedores que já tomaram decisões ou não têm controle sobre o conjunto de tecnologias. Como podemos torná-los mais produtivos sem gerar mais sobrecarga?
Uma pequena equipe do Chrome está trabalhando em um projeto chamado Aurora, com o objetivo de trabalhar com abstrações de terceiros da plataforma da Web, como frameworks e bibliotecas. O objetivo é ajudar a gerar ganhos de desempenho diretamente nessas abstrações, em vez de fazer o fardo cair sobre os clientes, os desenvolvedores da Web.
Na terceira edição do Chrome Dev Insider, conversei com Addy Osmani, Kara Erickson e Houssein Djirdeh, da equipe do Project Aurora, para saber mais sobre como eles estão abordando esse projeto e o que tem pela frente.
Informações privilegiadas: como trabalhar com estruturas de terceiros
Vamos começar com a criação deste projeto. Como surgiu?
Addy:a Aurora começou com uma ideia simples: vamos conhecer os desenvolvedores onde eles estão e ajudá-los a chegar aonde precisam ir. Por exemplo, ajudar o conjunto de tecnologias mais conhecido que eles escolheram para melhorar o desempenho. Muitos desenvolvedores de apps estão criando com React, Vue ou Angular atualmente, ou metaframeworks* como Next.js e Nuxt. E, claro, muitos outros... Escuro, Lit, Preato, Astro. E a lista é para todos!). Em vez de esperar que esses desenvolvedores se tornem especialistas profundas (por exemplo, em desempenho), podemos garantir que eles caiam no poço do sucesso incorporando mais práticas recomendadas por padrão nessas pilhas. Dessa forma, sites de melhor qualidade são apenas um efeito colateral de apenas criar para a Web.
A Aurora escolhe algumas estruturas e metaestruturas amplamente usadas para serem parceiras. Nós documentamos nossos aprendizados (por exemplo, como criar um bom componente de imagem), para que outras pessoas possam seguir rapidamente e tentar escalonar com outras estruturas e ferramentas por meio do Chrome Frameworks Fund. Embora seja possível melhorar a qualidade das experiências na Web por meio do navegador, acreditamos que esse objetivo também pode (em alguns casos) também ser alcançado por meio de estruturas. Esperamos que isso nos ajude a alcançar nossos objetivos de uma Web de mais qualidade para todos.
Kara: Para explicar melhor, a ideia é melhorar o desempenho na Web melhorando a experiência do desenvolvedor. Não basta divulgar as práticas recomendadas de desempenho, porque elas costumam mudar, e é difícil para as empresas acompanharem. Elas têm prioridades de negócios próprias que provavelmente virão antes da performance.
Portanto, nosso pensamento é que, se os desenvolvedores têm tempo limitado para se dedicar ao desempenho, vamos facilitar (e agilizar) a criação de um app de alto desempenho. Se fizermos parceria com frameworks da Web populares, estamos na camada certa de abstração para melhorar a experiência do desenvolvedor com componentes de nível superior, avisos de conformidade etc. Qualquer pessoa que usar essas ferramentas populares terá acesso a esses benefícios. E, teoricamente, se as recomendações mudarem, poderemos atualizar nossos componentes nos bastidores, e os desenvolvedores não precisam se preocupar em se manterem atualizados.
Houssein: Entrei no Google como mediador de desenvolvedores antes de mudar para uma função de engenharia de software alguns anos depois. Grande parte do meu trabalho anterior envolvia ensinar desenvolvedores da Web as muitas maneiras diferentes de criar ótimas experiências do usuário. Foram fornecidas variações da mesma orientação repetidamente para alertar os desenvolvedores sobre os problemas comuns que provavelmente afetarão o desempenho e a usabilidade dos sites. Quando começamos a pensar no projeto Aurora, perguntamos a nós mesmos: se poderíamos ir em uma direção em que nunca precisemos dizer aos desenvolvedores o que fazer, porque a cadeia de ferramentas cuida de tudo para eles?
Se entendi, você é uma equipe de seis engenheiros? Aposto que não é possível trabalhar com todas as estruturas ou bibliotecas possíveis. Então, como você escolhe com quem trabalhar? E quem são elas?
Addy:a Web é, em muitos aspectos, como o velho oeste selvagem. É possível escolher praticamente qualquer framework, bundler, bibliotecas e terceiros que você quiser. Isso introduz várias camadas de complexidade que podem contribuir para um desempenho bom ou ruim. Uma das melhores maneiras de melhorar o desempenho é fazer com que essas camadas se sintam à vontade para serem opinativas e adicionar mais opiniões a elas.
Por exemplo, frameworks da Web (Next.js, Nuxt.js e, em certo ponto, Angular) tentam incorporar mais opiniões e padrões do que uma solução mais manual. Esse é um dos motivos pelos quais adoramos trabalhar com eles. Nesses modelos, é recomendável ter padrões mais rigorosos sobre o carregamento de imagens, fontes e scripts para melhorar as Core Web Vitals.
Ela também é uma boa forma de confirmar onde as práticas recomendadas modernas funcionam ou podem precisar de uma repensação, além de ajudar a informar todo o ecossistema sobre como abordar a solução de problemas de otimização.
Kara: Na realidade, também temos que considerar a popularidade. Se quisermos ter o maior impacto possível na Web, o ideal é trabalhar com estruturas e bibliotecas que tenham uma grande comunidade de desenvolvedores. Dessa forma, podemos alcançar mais desenvolvedores e apps. Mas não pode ser apenas popularidade. No fim das contas, é uma interseção entre popularidade, quão opinativa é uma biblioteca e o conjunto de recursos disponíveis com que podemos trabalhar.
Por exemplo, se analisarmos apenas a popularidade, React, Vue e Angular são os três principais. Mas trabalhamos mais com Next.js, Nuxt e Angular. Isso ocorre porque as bibliotecas de visualização como React e Vue se concentram principalmente na renderização. Por isso, é impossível criar todos os recursos que queremos diretamente nelas. Por isso, trabalhamos mais perto com metaestruturas opinativas criadas com base nelas: Next.js e Nuxt. Nesse nível de abstração, é possível criar componentes integrados. Elas também têm servidores integrados, então podemos incluir otimizações do lado do servidor.
Você pode notar que o Angular estava nessa lista de parcerias profundas, mas não é um meta-framework. O Angular é um caso especial porque é bastante usado, mas não tem um meta-framework complementar como o React e o Vue. Por isso, trabalhamos com eles diretamente e contribuímos com os recursos pela CLI sempre que possível.
Vale a pena ressaltar que temos vários relacionamentos contínuos com outros projetos, como o Gatsby, em que sincronizamos um pouco regularmente no design, mas não contribuímos ativamente com código.
Como isso funciona na prática? Qual foi sua abordagem para resolver esse problema?
Kara: Na prática, colaboramos de perto com algumas estruturas. Levaremos algum tempo para criar o perfil dos apps que usam essa estrutura e descobrir problemas comuns de desempenho. Em seguida, trabalhamos com a equipe do framework para desenvolver recursos experimentais que resolvam essas dificuldades e contribuam com o código diretamente para o repositório OSS a fim de implementá-las.
É muito importante para nós validar se o impacto no desempenho é o que previmos. Por isso, também trabalhamos com empresas externas para realizar testes de desempenho na produção. Se os resultados forem encorajadores, ajudaremos o recurso a se tornar "estável" e possivelmente torná-lo um padrão.
Tudo isso não pode ser tão fácil quanto você. Quais foram alguns dos desafios ou aprendizados que você teve até agora?
Houssein:algo importante que tentamos fazer ao máximo é contribuir com repositórios de código aberto conhecidos com muitas prioridades. Só porque somos uma equipe do Google não significa necessariamente que nossos recursos serão priorizados. Fazemos todo o possível para nos alinharmos ao processo típico de propor e lançar novos recursos sem pisar no cliente. Tivemos o privilégio de trabalhar com mantenedores receptivos nos ecossistemas Next.js, Nuxt e Angular. Somos gratos por eles estarem abertos a ouvir nossas preocupações sobre o ecossistema da Web e dispostos a colaborar conosco de várias maneiras.
Com muitas das estruturas com as quais trabalhamos, nossa missão geral é a mesma: como os desenvolvedores podem ter uma experiência do usuário aprimorada pronta para uso, além de desfrutar de uma ótima experiência de desenvolvedor? Estamos cientes e respeitamos que existem centenas, se não milhares, de colaboradores da comunidade e mantenedores da estrutura trabalhando em diferentes projetos que se cruzam uns com os outros.
Kara: Além disso, como nos preocupamos em validar o impacto da performance e agir com base nos dados, o processo leva um pouco mais de tempo. Estamos em uma situação desconhecida, então, às vezes, testamos uma otimização que não funciona e não criamos um recurso planejado. Mesmo quando um recurso se movimenta, as poucas etapas extras para avaliar o desempenho levam tempo e estendem os cronogramas.
Encontrar parceiros de produção para testar nossos recursos também pode ser desafiador. Como mencionado anteriormente, elas são empresas e têm prioridades próprias, então pode ser difícil se encaixar em novas iniciativas se não estiverem alinhadas bem com os projetos existentes que precisam vir primeiro. Além disso, as empresas mais interessadas em ajudar tendem a investir na performance, por isso elas não são nosso público-alvo. Queremos coletar feedback de grande parte da comunidade que não pode investir na performance, mas é menos provável que entre em contato com a gente.
Em que tipo de otimização você tem se concentrado?
Houssein:depois de analisar milhares de aplicativos, descobrimos que os maiores problemas de desempenho geralmente se devem a antipadrões no código do aplicativo, e não ao próprio framework. Por exemplo, enviar imagens desnecessariamente grandes, carregar fontes personalizadas tarde demais, buscar muitas solicitações de terceiros que bloqueiam a linha de execução principal e não processar como o conteúdo assíncrono pode fazer com que outras coisas mudem na página. Todos esses são problemas que podem surgir independentemente da ferramenta que você usa, então pensamos: podemos incorporar algumas otimizações padrão que funcionam bem com elas, mas com uma ótima experiência de desenvolvedor que se encaixa perfeitamente nas ferramentas do framework?
Pensando nisso, enviamos:
- Componente de imagem Next.js.
- Componente do script Next.js.
- In-line de fontes automática no processo de build do Next.js.
- Diretiva de imagem angular
- Plug-in ESLint de conformidade com o Next.js (em inglês) para fornecer orientações úteis aos desenvolvedores.
Nosso trabalho inspirou outras estruturas e ferramentas a implementar otimizações similares. Isso inclui, entre outros:
- Módulo de imagem Nuxt
- Substituições de métricas de fontes Nuxt
- Componente de script Nuxt (em andamento)
- Componente "Gatsby Script"
Você pode compartilhar alguns resultados positivos do seu trabalho com algumas dessas empresas?
Houssein:muitos sites tiveram melhorias no desempenho devido às otimizações que enviamos. Um dos meus exemplos favoritos é o Leboncoin, que reduziu a LCP de 2,4s para 1,7s depois de mudar para o componente de imagem Next.js. Ainda há muito mais nas fases de experimentação e teste, e vamos continuar compartilhando o que você aprendeu aqui.
Ok, entendo que seu foco é naqueles que são mais populares, mas existem maneiras pelas quais outras estruturas ou bibliotecas com as quais você não trabalha também se beneficiam proativamente?
Addy:muitas das otimizações de desempenho com que o Aurora colabora podem ser replicadas por qualquer framework. Confira nossos esforços para os componentes de Imagem ou Script, por exemplo, eles geralmente codificam um conjunto existente de práticas recomendadas. Tentamos documentar o "como" da criação desses componentes e como eles ficam em cada framework. Espero que este seja um bom começo para copiar a ideia.
Tivemos bons resultados ao usar os aprendizados de um ecossistema (por exemplo, React e Next.js) e aplicá-los a outros. Por exemplo, a nova Diretiva de Imagem Angular (baseada nos nossos aprendizados para criar o componente de imagem Next.js) ou o Gatsby adotando nossa abordagem de agrupamento granular do JavaScript.
Ao mesmo tempo, entendemos que nem toda estrutura terá largura de banda ou financiamento para que os colaboradores criem recursos de desempenho semelhantes ou invistam em outras otimizações que possam ser importantes para os usuários. O Chrome Web Frameworks Fund é uma forma de patrocinarmos o trabalho de desempenho no ecossistema JavaScript para permitir que os projetos paguem seus colaboradores e ampliem o trabalho de desempenho no ecossistema.
Então o que está nos planos para sua equipe?
Kara: Temos muitos projetos incríveis em breve. Veja alguns destaques:
- Redução da CLS relacionada a fontes:é bastante comum ver mudanças de layout quando uma fonte da Web é carregada e substitui a fonte substituta. Estamos explorando o uso de substituições de métricas de fonte e a propriedade "size-adjust" para reduzir a CLS relacionada à fonte por padrão no Next.js. Também consultamos a equipe da Nuxt sobre isso e planejamos estender essa ideia para mais estruturas no próximo ano.
- Depuração de INP:agora que a métrica Interação com a próxima exibição (INP) foi lançada, estamos trabalhando com frameworks para investigar as causas raiz mais comuns de problemas de INP nas comunidades e sugerir correções. Estamos em parceria com a Angular para isso e esperamos ter alguns resultados para compartilhar em breve.
- Otimização de scripts de terceiros comuns:carregar scripts de terceiros na hora errada pode ter um impacto negativo significativo na performance. Como há alguns terceiros que são muito comuns, estamos analisando se podemos oferecer wrappers para garantir que eles sejam carregados da melhor forma possível com frameworks e não bloqueiem a linha de execução principal. Estamos usando o componente de script Next.js que criamos como ponto de partida para esta investigação.
Os desenvolvedores podem acompanhar nosso progresso neste site.
Notícias
Antes de finalizar o processo, gostaria de deixar algumas atualizações interessantes sobre o mundo dos frameworks do Google.
Em julho, a equipe do Chrome anunciou a última rodada de financiamento de US $500 mil para o fundo de estruturas e ferramentas, que se concentra no financiamento de projetos que visam melhorar o desempenho, a experiência do usuário e a experiência do desenvolvedor na Web. Os financiamentos futuros considerarão novos projetos, portanto, lembre-se de enviar sua solicitação.
E, claro, também há MUITAS coisas incríveis acontecendo na comunidade. O ecossistema está repleto de novas estruturas, como o Fresh do Deno, e experiências incríveis, como o tutorial de integração do Svelte, que não é apenas uma demonstração no navegador, mas também usa a API Web Container para executar o Node.js de forma nativa no navegador. Quanta coisa boa!
Fico realmente animado com a união do ecossistema, impulsionando o que é possível no navegador e ajudando os desenvolvedores a criar produtos que funcionem para todos. Estamos em um momento emocionante para ser um desenvolvedor da Web.
Até o próximo Insider, Hwyl fawr.
O que você achou desta edição do The Chrome Dev Insider? Envie feedback.