GitHub Got Faster By Adding More CSS
Read the Portuguese translation →
Author: Better Stack · Watch on YouTube
Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.
Original language: English
Original video: GitHub Got Faster By Adding More CSS · Channel: Better Stack · 01:33 · Watch on YouTube
Topics: Enterprise AI applications, Software engineering with AI
Summary
Section titled “Summary”GitHub reduced its server render time by 22% by switching from server-rendered CSS-in-JS to CSS modules, which ship more CSS to the client. Server-rendered CSS-in-JS can send only the styles a page needs, but generating them adds work for the server. Compiling CSS at build time avoids that server work, though it may send more CSS than necessary. The best choice depends on the balance between server render time and data sent over the network, as well as the needs of the application and its users.
Key points
Section titled “Key points”- GitHub cut server render time by 22% after changing how it handles CSS.
- Server-rendered CSS-in-JS uses runtime arguments to generate styles and can ship only the CSS needed for a page.
- Generating CSS at runtime adds work for the server.
- CSS compiled at build time does not need to be generated by the server.
- Build-time CSS may send more styles to the client than a page needs.
- GitHub switched from server-rendered CSS-in-JS to CSS modules.
- The 22% improvement refers to server render time, not overall page load time.
- Choosing an approach involves balancing server render time against data sent over the network.
- The speaker prefers CSS modules for their separation between CSS and application logic.
- The video recommends experimenting to find what improves user experience for a specific application.
Chapters
Section titled “Chapters”| Start | Chapter | Summary |
|---|---|---|
| 00:00 | Two ways to render CSS | The video introduces server-rendered CSS-in-JS and build-time CSS compilation, comparing their benefits and trade-offs. |
| 00:31 | Why GitHub switched to CSS modules | GitHub found that server-rendered CSS-in-JS slowed rendering and reduced server render time by 22% by shipping more CSS to clients. |
| 01:03 | Balancing rendering time and data | The speaker clarifies that the improvement was in server render time, and says the right approach depends on the application and user experience. |
| 01:33 | Experimenting with CSS approaches | The video notes that CSS preferences vary and encourages experimenting to find what works best. |
Quotes
Section titled “Quotes”GitHub just cut their server render time by 22% by shipping more CSS. — 00:00
This means that the server doesn’t have to generate any CSS at all — 00:31
It just means the server render time was cut by that much. — 01:03
it’s always worth experimenting to see which option improves the user experience for you. — 01:33
Concepts and entities
Section titled “Concepts and entities”CSS-in-JS, styled-components, CSS Modules, GitHub, Tailwind, Chakra, Better Stack
Full transcript (original language)
Section titled “Full transcript (original language)”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.