In its September 25 engineering write-up, GitHub described migrating github.com away from CSS-in-JS. The useful discussion is about where style work happens and what that costs the browser.
For your own app, start with a trace of one real interaction. Identify the time spent in JavaScript, style calculation and layout. Check a production build; development tooling changes the workload.
Then inspect one expensive component. Are you constructing styles on repeated renders? Are you changing geometry when a visual effect could use a different property? Are you loading a styling runtime for a page that mostly serves static content?
Make one change and repeat the same interaction under the same conditions. A smaller bundle is useful evidence, but it does not tell you whether the user sees the content sooner or whether a click responds faster.
There is no need to migrate a working app because a large company chose a different architecture. Its constraints may differ from yours.
Take the question into your next performance session: which work could happen before the page reaches the browser? Keep the answer tied to a measurement.
Disclosure: This article was prepared with AI assistance and reviewed against the linked sources and implementation. Examples explicitly marked fictional are illustrative.
Top comments (0)