CSS is a render-blocking resource: the browser cannot paint the page until it has downloaded, parsed, and applied the stylesheet. At scale, unmanaged CSS also creates cascading performance problems — huge stylesheets parsed on every navigation, specificity arms races that force the browser to evaluate ever-more-complex selectors, and layout thrash from the wrong kinds of animated properties. Tailwind's architecture addresses many of these structurally, but understanding the performance model is what lets you make the right call when situations fall outside the defaults.
Three distinct concerns apply at the CSS layer: size (how many bytes the browser downloads and parses), specificity (how expensive selectors are to match and resolve), and loading strategy (when and how the stylesheet arrives relative to the first paint). Utility-first has natural advantages on size (usage-driven generation) and specificity (one class, one property), but you still need to understand how they compound with your decisions about loading, splitting, and critical CSS.
This lesson is about CSS performance as a system — how the three concerns interact, where utility-first helps by design, and the specific decisions (loading, splitting, inlining critical CSS) that remain yours. Understanding these lets you reason confidently about the CSS contribution to page performance, and confidently tell stakeholders why a Tailwind-built site ships so little CSS.