GitHub ficou mais rápido adicionando mais CSS

Ver no idioma original →

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: GitHub Got Faster By Adding More CSS · Canal: Better Stack · 01:33 · Assistir no YouTube

Tópicos: Aplicações empresariais de IA, Engenharia de software com IA

Resumo

O GitHub reduziu em 22% o tempo de renderização no servidor ao trocar CSS-in-JS renderizado no servidor por CSS Modules compilado durante o build e enviado ao cliente. A mudança transfere trabalho do servidor para o navegador e pode resultar no envio de mais CSS do que a página precisa. A redução não significa que o tempo total de carregamento da página também caiu 22%. A melhor opção depende do equilíbrio entre o tempo de renderização no servidor, os dados enviados pela rede e a experiência do usuário.

Pontos-chave

• CSS-in-JS renderizado no servidor pode gerar apenas o CSS necessário para a página, mas exige mais trabalho do servidor.
• Compilar CSS durante o build evita que o servidor precise gerá-lo, embora possa enviar estilos desnecessários ao cliente.
• O GitHub reduziu em 22% o tempo de renderização no servidor ao adotar CSS Modules.
• A redução no tempo de renderização no servidor não corresponde necessariamente a uma redução igual no tempo total de carregamento da página.
• A escolha entre as abordagens depende da aplicação e do impacto na experiência geral do usuário.
• O narrador prefere CSS Modules pela separação entre CSS e lógica da aplicação.
• Tailwind, Chakra e CSS Modules são opções que refletem preferências diferentes; vale experimentar para avaliar o resultado.

Capítulos

Início	Capítulo	Resumo
00:00	CSS-in-JS e geração de estilos	O vídeo compara gerar CSS dinamicamente no servidor com compilar estilos durante o build.
00:31	A mudança do GitHub	O GitHub trocou CSS-in-JS renderizado no servidor por CSS Modules e reduziu em 22% o tempo de renderização no servidor.
01:03	Desempenho e experiência do usuário	A redução não se aplica automaticamente ao carregamento total da página, e a escolha depende das necessidades da aplicação.

Citações

O GitHub acabou de reduzir o tempo de renderização no servidor em 22% enviando mais CSS. — 00:00

O servidor não precisa gerar CSS algum, mas isso também significa que você pode enviar mais CSS do que realmente precisa. — 00:31

Isso não significa que o tempo total de carregamento da página caiu 22%. — 01:03

Vale sempre experimentar para ver qual opção melhora a experiência do usuário para você. — 01:33

Conceitos e entidades

• CSS-in-JS (conceito): Abordagem que usa JavaScript para gerar estilos, inclusive em tempo de execução.
• styled-components (ferramenta): Biblioteca de CSS-in-JS citada como exemplo.
• CSS Modules (conceito): Abordagem para organizar CSS que, no exemplo, compila os estilos durante o build.
• GitHub (empresa): Empresa que reduziu em 22% o tempo de renderização no servidor ao mudar a estratégia de CSS.
• Tailwind (ferramenta): Opção de estilos mencionada como preferência de parte dos desenvolvedores.
• Chakra (ferramenta): Biblioteca citada como outra opção de estilos.
• Better Stack (empresa): Canal que publicou o vídeo.

Tradução completa (pt-BR)

00:00 O GitHub acabou de reduzir em 22% o tempo de renderização no servidor ao enviar mais CSS. Há algumas maneiras de renderizar CSS em aplicações web modernas: usando bibliotecas de CSS-in-JS, como styled-components, ou compilando todos os seus estilos durante o build. O CSS-in-JS renderizado no servidor oferece os benefícios de usar JavaScript dinâmico para gerar arquivos. Você provavelmente já viu um código assim. Não dá para compilar isso em um arquivo estático, porque os estilos dependem de argumentos em tempo de execução, mas isso significa que você só acaba enviando o CSS de que realmente precisa para a página. Isso pode ser ótimo para

00:31 reduzir o excesso, mas dá mais trabalho para o servidor. A outra opção é compilar todo o seu CSS durante o build e enviá-lo ao cliente. Isso significa que o servidor não precisa gerar CSS algum, mas também significa que você pode estar enviando mais CSS do que realmente precisa. Essa é uma configuração comum para módulos CSS. O GitHub estava usando CSS-in-JS renderizado no servidor, mas descobriu que isso estava, na verdade, deixando mais lenta a renderização no servidor. Ao passar a enviar mais CSS ao cliente usando módulos CSS, conseguiu reduzir em 22% o tempo de renderização no servidor.

01:03 Isso não significa que o tempo total de carregamento da página tenha sido reduzido em 22%. Significa apenas que o tempo de renderização no servidor foi reduzido nessa proporção. Nem sempre é óbvio qual solução funcionaria melhor para você. É preciso equilibrar o tempo de renderização no servidor com a quantidade de dados transmitidos pela rede. Você teria que verificar qual opção oferece melhor desempenho para a experiência geral do usuário, com base na sua aplicação específica. Eu, pessoalmente, já usei bastante as duas soluções, mas, na verdade, prefiro módulos CSS porque prefiro ter uma separação maior de responsabilidades entre meu CSS e a lógica da aplicação. Parece muito mais fácil entender o que está acontecendo quando você pode olhar para o seu

01:33 CSS isoladamente. Mas CSS é uma daquelas coisas sobre as quais as pessoas têm opiniões muito fortes. Muita gente gosta de Tailwind, algumas pessoas gostam de bibliotecas como Chakra, e outras preferem módulos CSS. É muito difícil chegar a qualquer tipo de consenso, mas sempre vale a pena experimentar para ver qual opção melhora a experiência do usuário no seu caso. E, se quiser ficar por dentro de notícias de tecnologia como esta, inscreva-se no Better Stack.

Transcrição original

[00:00] GitHub just cut their server render time by 22% by shipping more CSS. There are a few ways that you can render CSS with modern web apps using CSS-in-JS libraries like styled-components or by compiling all of your styles at build time. Server-rendered CSS-in-JS gives you the benefits of using dynamic JavaScript to generate files. You’ve probably seen code like this before. You can never compile this to a static file because the styles rely on runtime arguments, but it does mean you only end up shipping the CSS that you actually need for the page. This can be great for

[00:31] reducing bloat, but it’s more work for your server to do. The other option is to compile all of your CSS at build time and ship it to the client. This means that the server doesn’t have to generate any CSS at all, but it also means you might be shipping more CSS than you actually need. This is a common setup for CSS modules. GitHub was using server-rendered CSS-in-JS, but they found that this was actually slowing down their server render time. By switching to shipping more CSS to the client using CSS modules, they were able to cut their server render time by 22%.

[01:03] Now, this doesn’t mean that overall page load time was cut by 22%. It just means the server render time was cut by that much. It’s not always obvious which solution would actually work for you. It’s a balance between server render time and data over the wire. You’d have to check which is more performant for the overall user experience based on your specific application. Now, I’ve personally used both solutions heavily, but actually prefer CSS modules because I prefer to have more separation of concern between my CSS and application logic. It just seems much easier to reason about when you can look at your

[01:33] CSS in isolation. But, CSS is one of those things that is super opinionated. A lot of people like Tailwind, some like libraries like Chakra, and others like CSS modules. It’s very hard to come to any kind of consensus, but it’s always worth experimenting to see which option improves the user experience for you. And if you want to stay up-to-date with tech news like this, then subscribe to Better Stack.