3 min read

Switching to Inline Styles Could Save You 15% or More on Page Speed

by Daniel Nagy @danimal_channel
A neckbeard dressed like they belong to a country club
Expand for the tl;dr


I switched from CSS-in-JS to inline styles and improved the load performance of my website by 18%. I also decreased the complexity of my website, and I decreased the size of my JavaScript bundle by 6.36%. All while maintaining the same developer experience for styling.

My last post got me thinking more about inline styles and my own website. I was advocating for inline styles, yet I wasn't really using inline styles myself. At the risk of being a hypocrite, I decided to transition my own website to inline styles.

I reasoned that I could transition my website from UI Box, a CSS-in-JS library, to inline styles pretty quickly, given that I was already declaring my styles inline with the markup. After about two hours, I had completely migrated my website to using inline styles, and the results were surprising (ok, maybe not that surprising).

How Did I Migrate So Quickly?#

First, you may be wondering how I was able to migrate my website to inline styles in only a couple of hours. I was able to do this because I was using a component (Box) as an abstraction for styling elements. Because of this, I was already declaring my styles in line with the markup.

However, rather than remove this abstraction and move all my styles to inline styles, I simply replaced the Box component with my own component that rendered the styles inline instead of generating CSS. I was able to significantly change the way my website was rendered in the browser by replacing a single component. That is pretty remarkable.

Surprising Results#

Switching to inline styles came with some unexpected, but measurable, performance benefits. The first of which was delivering less HTML to the browser.

How did switching to inline styles result in less HTML being shipped to the browser? Well, my dear Watson, allow me to explain.

UI Box was taking my inline styles and converting them to CSS. To do this, it generated a unique class name for each style. So every element would end up with a long set of class names, much like atomic CSS.

It then inlined the CSS it generated at the top of the page in a style tag. Now you can probably guess why the HTML was larger. However, that's not all. In addition to the extra CSS, I would inline a data structure at the bottom of the page for UI Box to rehydrate its state in the browser. By doing this, all the generated class names were duplicated in the HTML.

It turns out that replacing UI Box with inline styles reduced the average amount of HTML I was delivering to the browser by about 33%. Over the network, gzipped, I saw an average savings of 10%.

This resulted in Lighthouse reporting a nice performance improvement (on mobile) for the first contentful paint and the largest contentful paint. Both of which improved by 0.2s from 1.1s to 0.9s, or 18%. In addition, UI Box was my third largest dependency, after React DOM and Sentry (Sentry, please do something about the size of your JavaScript. Thank you.), and removing it reduced my JavaScript bundle by 6.36%.

In addition, I no longer pay the runtime tax for UI Box. It was doing some amount of work to parse my inline styles, convert them to CSS, and dynamically insert the CSS into a style tag, causing a reflow of the browser. I don't know how significant of a performance improvement this is, but I know it is not zero.


CSS-in-JS is probably doing your website more harm than good, especially if you have accumulated multiple CSS-in-JS solutions through transitive dependencies.

My website is now roughly 98–99% inline styles, and I have no dependencies for styling. I am all-in on inline styles because they are:

  1. simple
  2. composable
  3. portable

That last point deserves more attention. If you've ever distributed a package with reusable UI, then you probably already understand the importance of UI portability. However, I have more fringe ideas when it comes to UI portability, and inline styles may be a prerequisite for those ideas.

Written by Daniel Nagy

Daniel is a software engineer and full-stack web developer. He studied computer science at Ohio University and has been doing web development and hybrid mobile app development for over 8 years.


You will not receive notifications for new comments. If you are waiting for a reply, please check back periodically.
Markdown enabled