The counterintuitive fix: send more CSS
GitHub just reported a significant win: up to a 22% reduction in server render time on specific target pages. This performance boost came from a counterintuitive decision—shipping more CSS. Instead of dynamically generating styles on the fly, GitHub opted to compile its styling work at build time, offloading the CPU-intensive task from request-time processing.
This outcome sounds backwards to many web developers. Conventional wisdom often dictates that leaner, route-specific CSS is ideal for performance. However, producing this tailored CSS dynamically, particularly with server-rendered CSS-in-JS libraries, can consume substantial server CPU cycles during each user request. The perceived benefit of only sending "needed" CSS becomes a server-side bottleneck.
Crucially, this improvement focuses solely on server-side rendering. The 22% figure represents the time saved on the server preparing the initial HTML response. It does not imply that overall client-side page load times decreased by the same margin or that the entire application became 22% faster. This is a targeted optimization for the server's workload, shifting a significant portion of styling logic from runtime execution to static asset compilation.
The hidden CPU bill in runtime styling
GitHub's initial architecture relied heavily on server-rendered CSS-in-JS, a technique where styling logic executes during each request. This approach leverages JavaScript to evaluate prop-dependent styles, generate unique class names, and collect the necessary CSS while the server renders HTML. While seemingly efficient, this dynamic process carries a hidden computational cost.
On component-heavy pages, this cost escalates dramatically. Each component’s style resolution and insertion adds CPU work to an already busy rendering path. Imagine a page with hundreds of components, each potentially triggering its own style evaluation—the cumulative effect quickly turns into a significant server bottleneck.
Runtime styling offers a compelling benefit: it only emits the precise styles required for a given page state, minimizing the client-side CSS payload. However, this selectivity isn't free. The server pays the price in CPU cycles, repeatedly performing the same style calculations and string manipulations for every incoming request.
This trade-off became clear for GitHub. The promise of lean client bundles was overshadowed by the increased server render time, forcing them to re-evaluate whether the performance hit was truly worth the perceived benefits of dynamic, component-driven styling.
CSS Modules move the work before the request
GitHub's transition to CSS Modules exemplifies a fundamental shift in where computational work happens. Instead of generating styles on demand, CSS Modules compile styles into static .css files at build time. This means the server renders only static HTML with pre-defined class names, completely offloading style generation from the request-response cycle.
This isn't about eliminating work, but rather shifting its cost. While shipping more CSS might mean a slightly larger initial payload for the client, these static files are highly cacheable, and the server's CPU is freed from the intensive task of runtime style evaluation. The trade-off prioritizes server performance and faster initial render times.
The reported 22% server render time improvement on specific GitHub pages is a compelling result, but it’s crucial not to conflate this with universal gains across their entire platform. GitHub's broader Primer migration, which involved deprecating over 6,400 dynamic props, led to an overall 55% reduction in server-side render time across core component suites and a 25% reduction in component initialization time.
Page-specific gains varied from 1% to 22%, reflecting the complexity and scale of their application. This nuanced outcome underscores that while the principle of moving work to build time is sound, the exact performance benefits are highly dependent on the application's unique architecture and component usage. For more on the specifics of this architectural shift, see Improving site performance by shipping more CSS - The GitHub Blog.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
Measure the page, not the styling ideology
GitHub’s findings offer a vital lesson: measure the page, not the styling ideology. Teams must evaluate server render time alongside CSS bytes, cache behavior, and critical user-facing metrics like Time to First Byte (TTFB) and Largest Contentful Paint (LCP) on representative routes. This holistic view reveals the true impact on user experience.
No single styling solution reigns supreme. CSS Modules, Tailwind CSS CSS, Chakra UI UI, and zero-runtime tools each present distinct trade-offs in authoring experience, network payload, and architectural overhead. The choice depends entirely on an application's specific needs and performance bottlenecks, not a universal decree.
Benchmarking the entire user journey is paramount. While GitHub achieved up to a 22% reduction in server render time by shipping more CSS, this alone does not guarantee a faster overall page load. The server is just one link in the chain; a heavier client-side payload or slower network conditions could negate those server-side gains.
Ultimately, the goal is a faster, more responsive application for the end-user. That means rigorously testing and comparing styling models against a comprehensive set of metrics. Choose the approach that best fits your application’s architecture and delivers demonstrable improvements across the full stack.
Frequently Asked Questions
How did GitHub reduce server render time by 22%?
On specific target pages, GitHub reduced server-side styling work by moving from runtime CSS-in-JS toward build-time CSS Modules.
Does a 22% faster server render mean a 22% faster page?
No. It describes server render time, not total load time. Network transfer, CSS parsing, and rendering also affect what users experience.
Why can runtime CSS-in-JS slow down server rendering?
The server may need to evaluate dynamic styles, generate class names, and collect or insert CSS while rendering each request.
When should a team consider CSS Modules?
They can be a good fit when server-side style generation is costly and a team values scoped styles, though the CSS payload should be measured.