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 apaixonados que têm a tarefa de trazer a perspectiva de desenvolvedores reais para nossas equipes de produto e engenharia, com a métrica estrela do norte para melhorar a satisfação dos desenvolvedores.
Sabemos que a "satisfação" é uma métrica ambiciosa e subjetiva para acompanhar e melhorar. Por isso, estamos sempre iterando sobre como podemos causar impacto, focando nas necessidades dos desenvolvedores. Um princípio fundamental que achamos útil é encontrar os desenvolvedores onde eles estão. Um estudo recente do Stack Overflow mostrou que 75% dos desenvolvedores usam frameworks ou algum tipo de abstração. Por isso, estamos nos perguntando como melhor atender aos desenvolvedores que já tomaram decisões sobre a pilha de tecnologia ou não têm controle sobre ela. Como podemos aumentar a produtividade sem aumentar a 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 deles é ajudar a trazer ganhos de performance diretamente para essas abstrações, em vez de deixar a carga 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 elas estão abordando esse projeto e o que está por vir.
Informações privilegiadas: como trabalhar com frameworks de terceiros
Vamos começar com a origem desse projeto. Como isso aconteceu?
Addy:a Aurora começou com uma ideia simples: vamos atender os desenvolvedores onde eles estão e ajudar a chegar onde precisam. Por exemplo, ajudar a pilha de tecnologia popular que eles escolheram para melhorar a performance. Muitos desenvolvedores de apps estão criando usando React, Vue ou Angular hoje em dia, ou metaframeworks* como Next.js e Nuxt (e, claro, muitos outros... Svelte, Lit, Preact, Astro. A lista é interminável. Em vez de esperar que esses desenvolvedores se tornem especialistas (por exemplo, em performance), podemos garantir que eles tenham sucesso ao incorporar mais práticas recomendadas por padrão nessas pilhas. Dessa forma, sites de melhor qualidade são um efeito colateral da criação para a Web.
O Aurora escolhe alguns frameworks e metaframeworks amplamente usados para fazer parceria. Documentamos nossos aprendizados (como como criar um bom componente de imagem) para que outras pessoas possam seguir rapidamente e tentar dimensionar usando outros frameworks e ferramentas pelo Chrome Frameworks Fund. Embora seja possível melhorar a qualidade das experiências da Web pelo navegador, acreditamos que esse objetivo também pode ser alcançado (em alguns casos) por frameworks. Esperamos que isso nos ajude a alcançar nossos objetivos de uma Web de maior qualidade para todos.
Kara:Para complementar, a ideia é melhorar a performance na Web melhorando a experiência do desenvolvedor. Não basta divulgar as práticas recomendadas de performance, porque elas mudam com frequência e é difícil para as empresas acompanharem. Eles têm prioridades de negócios que provavelmente vêm antes da performance.
Nosso pensamento é que, se os desenvolvedores têm tempo limitado para se dedicar à performance, vamos facilitar (e acelerar) a criação de um app com bom desempenho. Se fizermos parceria com frameworks da Web conhecidos, estaremos na camada de abstração certa para melhorar a experiência do desenvolvedor com componentes de nível mais alto, avisos de conformidade etc. Qualquer pessoa que use essas ferramentas conhecidas terá acesso a esses benefícios. E, teoricamente, se a recomendação mudar, podemos atualizar nossos componentes e os desenvolvedores não precisam se preocupar em ficar atualizados.
Houssein:entrei no Google como defensor de desenvolvedores e depois mudei para uma função de engenharia de software alguns anos depois. Grande parte do meu trabalho anterior envolveu ensinar aos desenvolvedores da Web as muitas maneiras diferentes de criar ótimas experiências do usuário. Várias variações da mesma orientação foram fornecidas para alertar os desenvolvedores sobre os problemas comuns que provavelmente afetam o desempenho e a usabilidade dos sites. Quando começamos a pensar no projeto Aurora, nos perguntamos: podemos seguir uma direção em que nunca precisamos dizer aos desenvolvedores o que fazer porque a cadeia de ferramentas cuida de tudo para eles?
Se entendi corretamente, vocês são uma equipe de seis engenheiros? Aposto que você não pode trabalhar com todos os frameworks ou bibliotecas possíveis. Como você escolhe com quem trabalhar? E quem são eles?
Addy:a Web é, de muitas maneiras, como o velho oeste. Você pode escolher praticamente qualquer framework, bundler, bibliotecas e terceiros que quiser. Isso introduz várias camadas de complexidade que podem contribuir para uma boa ou má performance. Uma das melhores maneiras de melhorar a performance é encontrar essas camadas que se sentem confortáveis em expressar opiniões e adicionar mais opiniões a elas.
Por exemplo, os frameworks da Web (Next.js, Nuxt.js e, em certa medida, Angular) tentam incorporar mais opiniões e padrões do que uma solução mais manual. Esse é um dos motivos de adorarmos trabalhar com eles. Ter padrões mais fortes de como carregar imagens, fontes e scripts para melhorar as Core Web Vitals faz sentido nesses modelos.
Ela também é uma boa maneira de confirmar onde as práticas recomendadas modernas funcionam ou precisam ser repensadas e pode ajudar a informar todo o ecossistema sobre como resolver problemas de otimização.
Kara:Precisamos considerar a popularidade. Se quisermos ter o maior impacto possível na Web, o ideal é trabalhar com frameworks e bibliotecas que tenham uma grande comunidade de desenvolvedores. Assim, podemos alcançar mais desenvolvedores e apps. Mas não pode ser apenas popularidade. No fim das contas, é uma interseção de popularidade, de como uma biblioteca é opinativa e do conjunto de recursos disponíveis com que podemos trabalhar.
Por exemplo, se considerarmos apenas a popularidade, React, Vue e Angular são os "três grandes" a serem considerados. Mas trabalhamos principalmente com Next.js, Nuxt e Angular. Isso ocorre porque as bibliotecas de visualização, como React e Vue, se concentram principalmente na renderização. Portanto, é impossível criar todos os recursos diretamente nelas. Por isso, trabalhamos mais de perto com metaframeworks opinativos criados com base neles: Next.js e Nuxt. Nesse nível de abstração, podemos criar componentes integrados. Eles também têm servidores integrados, então podemos incluir otimizações no servidor.
Você pode notar que o Angular estava na lista de parcerias profundas, mas não é um metaframework. O Angular é um caso especial porque é bastante conhecido, mas não tem um metaframework complementar como o React e o Vue. Por isso, trabalhamos com eles diretamente e contribuímos com recursos usando a CLI deles sempre que possível.
Vale ressaltar que temos vários relacionamentos em andamento com outros projetos, como o Gatsby, em que sincronizamos o design com certa frequência, mas não contribuímos ativamente com o código.
Como isso funciona na prática? Qual foi sua abordagem para resolver esse problema?
Kara:Na prática, temos alguns frameworks com os quais colaboramos de perto. Vamos levar algum tempo para criar o perfil de apps usando essa estrutura e descobrir os problemas de desempenho comuns. Em seguida, trabalhamos com a equipe do framework para projetar recursos experimentais que resolvam esses problemas e contribuir com o código diretamente no repositório de OSS para implementá-los.
É muito importante para nós validarmos 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, vamos ajudar o recurso a ficar "estável" e, possivelmente, torná-lo o padrão.
Isso não pode ser tão fácil quanto você está dizendo. Quais foram alguns dos desafios ou aprendizados que você teve até agora?
Houssein:Uma coisa importante que tentamos fazer é contribuir para repositórios de código aberto conhecidos que têm muitas prioridades concorrentes. O fato de sermos uma equipe do Google não significa necessariamente que nossos recursos serão priorizados. Por isso, fazemos o possível para nos alinharmos ao processo típico de propor e lançar novos recursos sem atrapalhar ninguém. Tivemos a sorte de trabalhar com mantenedores receptivos nos ecossistemas Next.js, Nuxt e Angular. Agradecemos por eles terem ouvido nossas preocupações sobre o ecossistema da Web e por estarem dispostos a colaborar com a gente de várias maneiras.
Com muitos dos frameworks com que trabalhamos, nossa missão é a mesma: como os desenvolvedores podem ter uma experiência do usuário melhor e ao mesmo tempo uma ótima experiência de desenvolvimento? Sabemos e respeitamos o fato de que há centenas, senão milhares, de colaboradores da comunidade e administradores de framework trabalhando em projetos diferentes que se cruzam.
Kara:Além disso, como nos preocupamos em validar o impacto na performance e agir com base em dados, o processo leva um pouco mais de tempo. Estamos em um território desconhecido, então às vezes testamos uma otimização que não funciona e não criamos um recurso planejado. Mesmo quando um recurso funciona, essas poucas etapas extras para verificar o desempenho levam tempo e prolongam os prazos.
Encontrar parceiros de produção para testar nossos recursos também pode ser um desafio. Como mencionado anteriormente, eles são empresas e têm prioridades próprias. Por isso, pode ser difícil para eles se encaixar em novas iniciativas se elas não se alinharem bem com os projetos atuais que precisam vir em primeiro lugar. Além disso, as empresas mais interessadas em ajudar tendem a já estar investindo em performance, então não são nosso público-alvo. Estamos tentando coletar feedback de uma grande parte da comunidade que não pode investir em performance, mas que tem menos probabilidade de entrar em contato conosco.
Em que tipo de otimizações você tem se concentrado?
Houssein:depois de analisar milhares de aplicativos, descobrimos que os maiores problemas de desempenho geralmente são causados por antipadrões no código do aplicativo, e não no framework em si. Por exemplo, enviar imagens grandes desnecessariamente, carregar fontes personalizadas com atraso, 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 causar mudanças em outras coisas na página. Todos esses problemas podem surgir independentemente da ferramenta usada. Por isso, pensamos: podemos incluir algumas otimizações padrão que lidam bem com eles, mas com uma experiência de desenvolvedor bacana que se encaixa bem nas ferramentas do framework?
Com esse pensamento, lançamos:
- Componente de imagem do Next.js.
- Componente de script do Next.js.
- Inserção automática de fontes no processo de build do Next.js.
- Directive de imagem do Angular.
- Plug-in ESLint de conformidade do Next.js para fornecer orientações úteis aos desenvolvedores.
Nosso trabalho inspirou outros frameworks e ferramentas a implementar otimizações semelhantes. Isso inclui, sem limitação:
- Módulo de imagem Nuxt
- Substituições de métricas de fontes do Nuxt
- Componente do script Nuxt (em andamento)
- Componente do script do Gatsby
Você pode compartilhar alguns resultados positivos do seu trabalho com alguns desses jogadores?
Houssein:muitos sites tiveram melhorias de desempenho devido às otimizações que lançamos. Um dos meus exemplos favoritos é o Leboncoin, que reduziu o LCP de 2,4 para 1,7 segundos depois de mudar para o componente de imagem do Next.js. Há muitos outros recursos em fases de experimentação e teste, e vamos continuar compartilhando aprendizados e vitórias aqui.
Ok, entendi que seu foco é nos frameworks mais conhecidos, mas há maneiras de outros frameworks ou bibliotecas com os quais você não está trabalhando também se beneficiarem?
Addy:muitas das otimizações de desempenho em que a Aurora colabora podem ser replicadas por qualquer framework. Confira nossos esforços de componentes de imagem ou script, por exemplo, que geralmente codificam um conjunto de práticas recomendadas. Tentamos documentar como criar esses componentes e como eles ficam em cada framework. Esperamos que isso seja um bom começo para copiar a ideia.
Tivemos sucesso ao usar as lições de um ecossistema (por exemplo, React e Next.js) e aplicá-las a outros. Por exemplo, a nova diretiva de imagem do Angular (criada com base em nossos aprendizados ao criar o componente de imagem do Next.js) ou o Gatsby enviando nossa abordagem para fragmentação granular de JavaScript.
Ao mesmo tempo, entendemos que nem todos os frameworks têm a largura de banda ou o financiamento necessários para que os colaboradores criem recursos de desempenho semelhantes ou invistam em outras otimizações que eles acreditam ser importantes para os usuários. O Chrome Web Frameworks Fund é uma forma de patrocinar o trabalho de performance no ecossistema JavaScript para que os projetos paguem aos colaboradores e para que o trabalho de performance seja ampliado no ecossistema.
Quais são os planos da sua equipe?
Kara:Temos muitos projetos interessantes pela frente. Veja alguns destaques:
- Como reduzir o CLS relacionado a fontes:é bastante comum que o layout mude quando uma fonte da Web é carregada e substitui a fonte substituta. Estamos testando o uso de substituições de métricas de fonte e a propriedade "size-adjust" para reduzir o CLS relacionado à fonte por padrão no Next.js. Também consultamos a equipe do Nuxt sobre isso e planejamos estender essa ideia para mais frameworks no ano que vem.
- Depuração de INP:agora que a métrica Interaction to Next Paint (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 trabalhando em parceria com o Angular e esperamos compartilhar os resultados em breve.
- Otimização de scripts comuns de terceiros:carregar scripts de terceiros no momento errado pode ter um impacto negativo significativo na performance. Como há alguns terceiros muito comuns, estamos analisando se podemos oferecer alguns wrappers para garantir que eles sejam carregados de maneira otimizada com frameworks e não bloqueiem a linha de execução principal. Estamos usando o componente de script do Next.js que criamos como ponto de partida para essa investigação.
Os desenvolvedores podem acompanhar nosso progresso neste site.
Notícias
Antes de encerrar, gostaria de compartilhar algumas atualizações interessantes do mundo dos frameworks que estão acontecendo no Google.
Em julho, a equipe do Chrome anunciou a última rodada de financiamento de US $500 mil para o fundo de frameworks e ferramentas, que se concentra em projetos de financiamento que visam melhorar o desempenho, a experiência do usuário e a experiência do desenvolvedor na Web. O financiamento futuro vai considerar novos projetos. Por isso, envie sua solicitação.
E, claro, há muitas coisas incríveis acontecendo na comunidade. O ecossistema está repleto de novos frameworks, 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. Muitas coisas boas!
Fico muito feliz em ver o ecossistema se unindo, avançando no que é possível no navegador e ajudando os desenvolvedores a criar produtos que funcionem para todos. É um momento empolgante para ser um desenvolvedor da Web.
Até a próxima, Hwyl.
O que você achou desta edição do The Chrome Dev Insider? Envie seu feedback.