The Great CSS Migration: Why Shipping More CSS is a Scaling Strategy for Enterprise Frontends

Sunday, September 27, 2026

As a Senior Front-End Architect, I've seen countless trends come and go. Yet, some architectural decisions transcend fleeting hype, ultimately defining the long-term viability and performance of our applications. One such pivotal re-evaluation gaining significant traction in the industry – exemplified by recent moves from engineering giants like GitHub – is the strategic shift away from certain styles of CSS-in-JS towards embracing what's being called 'more CSS'. This isn't a nostalgic trip back to global stylesheets; it's a sophisticated, performance-driven architectural pivot that merits a deep dive.

The Allure and The Abyss: CSS-in-JS at Scale

When CSS-in-JS libraries first emerged, they promised a dream: co-location of styles with components, dynamic theming, component encapsulation, and the power of JavaScript for styling logic. For smaller to medium-sized projects, and for teams struggling with traditional CSS's global scope and specificity issues, this was a revelation. It offered a compelling developer experience (DX), seemingly solving many pain points with elegance.

However, as applications scale – both in codebase size and user traffic – the dream can quickly turn into a performance nightmare. We’re talking about enterprise-grade applications with millions of lines of code, complex design systems, and user interfaces that can render hundreds of components simultaneously, often in environments where every millisecond counts (think, for instance, GitHub’s challenge in 'Rendering huge pull requests').

The Promises That Faltered

Let's break down where the initial promise of CSS-in-JS often falls short in high-scale environments:

• Runtime Overhead: Many CSS-in-JS solutions inject styles into the DOM at runtime. This process introduces CPU costs, particularly during initial page load and hydration. For interactive applications, this overhead directly impacts First Contentful Paint (FCP) and Largest Contentful Paint (LCP), two critical Core Web Vitals. The browser needs to parse and execute JavaScript to construct the stylesheet, delaying style application.
• Bundle Size Bloat: While it seems counter-intuitive, encapsulating CSS within JavaScript often leads to larger JavaScript bundles. The CSS itself is bundled within JS, plus the runtime library's code. This increases network transfer times and parsing costs.
• CSS Specificity Battles, Reimagined: While offering component-level encapsulation, complex theming logic or global overrides in CSS-in-JS can still lead to unexpected specificity challenges, albeit in a JavaScript context.
• Cache Inefficiency: Because styles are often dynamically generated based on props and potentially unique per component instance, browser caching of CSS can become less effective. Each page load might require re-parsing and re-injecting styles, even if the underlying CSS rules are identical.
• Build Performance: For very large codebases, the process of extracting, optimizing, and bundling CSS from JavaScript can add significant time to build pipelines, hindering rapid iteration.

Consider a simple example. With styled-components, you might write:

import styled from 'styled-components';

const StyledButton = styled.button`
  background: ${(props) => (props.primary ? 'palevioletred' : 'white')};
  color: ${(props) => (props.primary ? 'white' : 'palevioletred')};
  font-size: 1em;
  margin: 1em;
  padding: 0.25em 1em;
  border: 2px solid palevioletred;
  border-radius: 3px;
`;

function MyComponent() {
  return (
    <StyledButton primary>Click Me</StyledButton>
  );
}

This looks clean. But at runtime, this JavaScript needs to execute to generate a class name (e.g., sc-dkrFOg bTzPoo) and inject the corresponding CSS rule (.sc-dkrFOg.bTzPoo { ... }) into a <style> tag in the document head or body. Multiply this by hundreds or thousands of components across a complex application, and the cumulative cost becomes substantial.

The Resurgence of 'More CSS': What It Means Architecturally

GitHub's candid blog post, 'Improving site performance by shipping more CSS,' articulates a migration that many large organizations are quietly undertaking. 'More CSS' doesn't imply a regression to unmanaged, global .css files. Instead, it signifies a strategic embrace of modern, build-time processed CSS methodologies. These typically include:

• CSS Modules: Providing local scope by default, eliminating specificity conflicts by generating unique class names at build time. No runtime JS required for styling.
• Utility-First CSS (e.g., Tailwind CSS): A highly efficient approach where styles are composed from small, single-purpose utility classes. This often leads to highly optimized, deduplicated CSS bundles.
• Modern CSS Features with PostCSS: Leveraging native CSS features like Custom Properties (CSS Variables), nesting, clamp(), and more, often transpiled for broader browser support using PostCSS.
• CSS-in-JS with Build-Time Extraction: Some CSS-in-JS libraries (like Emotion with its css prop or Linaria) offer zero-runtime options where styles are extracted into static .css files during the build process. This provides the DX benefits without the runtime overhead.

The core principle is to move style generation and injection from runtime JavaScript to compile-time static CSS assets. This has profound performance implications:

1. Reduced JavaScript Payload: Less CSS in your JS bundles means smaller, faster-downloading, and faster-parsing JavaScript.
2. Faster Critical Rendering Path: Browsers can download, parse, and apply static CSS faster than waiting for JavaScript to execute and inject styles. This significantly improves FCP and LCP.
3. Improved Browser Caching: Static CSS files are highly cacheable. Once downloaded, they can be served from cache on subsequent visits, drastically improving load times.
4. Enhanced Developer Tooling: Standard CSS benefits from decades of browser tooling, linting, and editor support, often more robust than specialized CSS-in-JS syntaxes.

Contrast the earlier styled-components example with a CSS Modules approach:

// Button.module.css
.button {
  font-size: 1em;
  margin: 1em;
  padding: 0.25em 1em;
  border: 2px solid palevioletred;
  border-radius: 3px;
}

.primary {
  background: palevioletred;
  color: white;
}

.secondary {
  background: white;
  color: palevioletred;
}

// Button.jsx
import styles from './Button.module.css';

function Button({ primary, children }) {
  const className = primary ? ``styles.button`{styles.primary}` : ``styles.button`{styles.secondary}`;
  return <button className={className}>{children}</button>;
}

function MyComponent() {
  return (
    <Button primary>Click Me</Button>
  );
}

Here, the CSS is compiled into a static .css file, with class names like Button_button__abCde and Button_primary__fGhIj. The browser simply downloads and applies the CSS; no JavaScript execution is needed to generate styles at runtime.

Navigating the Architectural Shift: Trade-offs and Leadership

Migrating a large codebase from one styling paradigm to another is a monumental effort. It's not merely a technical task; it's an exercise in engineering leadership, requiring careful planning, communication, and a clear understanding of trade-offs.

Migration Strategy: Incrementalism is Key

A full, 'big-bang' rewrite is almost always a bad idea for active, large applications. An incremental strategy is crucial:

• New Features First: Start adopting the new styling approach for all new components and features. This immediately prevents the existing problem from getting worse.
• Low-Risk Refactors: Identify isolated components or sections of the UI that can be migrated with minimal risk. This builds confidence and provides early wins.
• Co-existence: Accept that the two styling paradigms will co-exist for a significant period. Establish clear guidelines for distinguishing between old and new code.
• Automated Tooling: Where possible, leverage codemods or AI-assisted refactoring tools (like elements of GitHub Copilot) to automate parts of the migration, though manual review is always necessary.

Realigning the Design System

Your design system is the backbone of your frontend. This migration requires a re-evaluation of how tokens, components, and themes are defined and implemented. A shift to 'more CSS' often implies moving towards a stronger reliance on CSS Custom Properties (variables) for design tokens, providing dynamic theming capabilities purely in CSS, without JavaScript runtime overhead.

Developer Experience and Education

While the long-term benefits for performance and maintainability are clear, the immediate DX for engineers might see a dip during the transition. Developers accustomed to the tight coupling of CSS-in-JS might find the separation of concerns a hurdle initially. Engineering leadership must:

• Clearly Articulate 'Why': Explain the performance and maintainability gains to the team.
• Provide Training: Offer workshops, documentation, and pairing sessions on the new styling approach.
• Establish Clear Standards: Define naming conventions, structure, and best practices for the new CSS methodology. Utilize linting tools and code reviews to enforce consistency.

Measuring the Impact

The most convincing argument for such a significant architectural shift comes from measurable improvements. Establish clear KPIs before, during, and after the migration:

• Core Web Vitals: Monitor FCP, LCP, CLS (Cumulative Layout Shift) rigorously. Expect to see significant improvements in FCP and LCP.
• Bundle Size: Track JavaScript and CSS bundle sizes. The goal is smaller JS, potentially slightly larger but more efficient CSS.
• Lighthouse Scores: Regularly run Lighthouse audits, focusing on performance metrics.
• Build Times: Monitor build pipeline duration to ensure the new approach doesn't introduce unexpected regressions.

The Path Forward: Prioritizing User Experience

The industry context strongly hints at a renewed focus on core performance and user experience. 'When chat is the wrong UI' and 'Rendering huge pull requests' both underscore the need for robust, performant interfaces that don't rely on overly complex runtime logic. The move to 'more CSS' is a direct answer to this call for efficiency. It's about engineering pragmatism, making deliberate choices to optimize for the user and for the long-term health of the codebase. It’s an architectural decision that directly contributes to delivering more efficient software, a clear demand from developers themselves.

Key Takeaways

• CSS-in-JS has runtime overhead that can significantly impact performance in large-scale applications, particularly for FCP and LCP.
• The 'More CSS' movement advocates for static, build-time processed CSS (e.g., CSS Modules, Utility-First CSS, zero-runtime CSS-in-JS) for superior performance and caching.
• Migration from CSS-in-JS requires a strategic, incremental approach, careful planning, and strong engineering leadership to manage the transition and educate teams.
• Realigning design systems to leverage CSS Custom Properties is a key aspect of this architectural shift.
• Measure everything: Monitor Core Web Vitals, bundle sizes, and build times to validate the success of the migration.

What You Should Do Today

1. Audit Your Current Application: If you're using CSS-in-JS, perform a critical audit of your Core Web Vitals, especially FCP and LCP. Use Lighthouse and real user monitoring (RUM) tools to understand the actual performance impact.
2. Research Alternative Styling Approaches: Dive deeper into CSS Modules, Tailwind CSS, or zero-runtime CSS-in-JS solutions. Understand their pros and cons for your specific context.
3. Propose a Pilot Project: For a new feature or a low-risk component, experiment with one of the 'more CSS' approaches. Document the process, performance gains, and developer feedback.
4. Educate Your Team: Start discussions with your frontend team about the performance implications of different styling methodologies. Share articles like GitHub's migration story to foster a shared understanding of the architectural landscape.
5. Review Your Design System Strategy: Evaluate how your design tokens are implemented. Could you shift more dynamic theming to CSS Custom Properties, reducing reliance on runtime JavaScript?