Faster LiveView renders with inlined critical CSS

P.S. There are some tools that could help, like Critical and Penthouse. I haven’t used those yet. And I was actually a bit surprised to see that Tailwind and Esbuild haven’t targeted this feature yet. But maybe with good reason?

When on JS land I used to do this, but since the resurgence of utility first CSS libraries like Tailwind I haven’t seen this tackled.I haven’t read on it, but I suppose the nature of atomic CSS reduces the importance of critical stylesheets?

Indeed, that thought crossed my mind. There might not typically be a significant difference between the utility classes used above the fold compared to those used throughout the rest of the page.

Certain UI components may only be present above the fold, which makes it beneficial to include their CSS classes and IDs in a critical stylesheet when using regular CSS. However, with utility classes, it’s more ‘random’—for lack of a better term—regarding which classes are used for components above or below the fold.

This seems like a limitation inherent to a utility-first approach.

Also, I am currently not using Tailwind yet. I am still on the fence about whether to use it or not.

I don’t know of any tools, but I’m curious if your CSS files are truly the biggest bottleneck for reaching First Contentful Paint? And if so, on what percentage of page views is this true?

Regardless of your answers to the above, this article from Harry Roberts breaks down the difficulty of reliably implementing and maintaining inlined-critical-css, as well as why it might not give you the expected bang/buck.

Given that CSS files are generally cached (and compressed!), your users are probably only experiencing CSS fetch bottlenecks on their first visit, and those first visits can be optimized by leveraging a CDN for asset paths, and implementing HTTP 103 Early Hints (via plug_early_hints | Hex) to preemptively fetch your CSS while the origin server is doing any sort of additional IO/work to build out the actual HTML response. Cheers!

I stand by the recommendation above, but one method for inlining css so that it’s only present if the component is rendered is to use inline <style></style> tags within your HEEX components, and to do so above the elements in the component so that the styles are available by the time the markup is parsed. You’d then have to not fetch the standard stylesheet on the entrypoint pages.

That said, I wouldn’t use this approach for oft-recurring components like <.link> or <.button> due to the repetition it would introduce to the markup, but it could be useful for if you have componentry that’s only present on entry/landing pages (due to my note above about cacheability of CSS files).

This is something I’ve never worried about before. There is some context missing from this article, but I’m thinking this is more of an optimization you’d take on if 99.9% of your DOM is being created by JavaScript after parsing a bunch of JSON. Perhaps even more so if you are using one of those CSS-in-JS-style thingies that create hashed class names (I’m actually not sure how efficient those are). It seems to be implied that’s the paradigm the author—and 95% of the web dev community—works in. LiveView is already getting a massive initial render boost by having raw HTML sent to the browser, so I wouldn’t worry about this… I don’t think? I’ve only worked in a Modern JS Framework™ once for a couple of years but other than that I’ve always worked server-side sending HTML and never had any trouble keep initial renders super snappy. At least not resorting to this kind of thing. The culprit would always be more tangible stuff like a slow DB query or someone forgetting to shrink an image.

Thanks for sharing the links. It was useful to research your suggestions.

And about whether render blocking CSS is the problem or not. I’m not sure actually at this point. The app is still too far from what it’s going to be at launch. And, to the point from the article you referenced, it might be difficult to predict even then!

From my experience, on higher latency connections and lower-end devices, using a CDN for assets actually made things slower. A lot of this was due to DNS, establishing a new TCP connection, etc.

I don’t recall the numbers off-hand, but it was between 10%-30% improvement for my site / layout. Anecdotally, I had a 5 year old phone and was out in the hinterlands, I noticed the difference immediately. Reducing the number of origins made an incredible difference, not in raw speed, but in reliability. Nothing is more frustrating than a load being fast most of the time and then getting a half-load 1/20 times.

Also, regarding CDN performance, one of the advantages used to be that common js libraries (jquery) that were pulled from the CDN likely did not have to be downloaded as they would already be cached in the browser. I believe a security change was made a few years ago that prevented the re-use of cache, so that advantage is now gone.

Definitely need to try this.

And just in case people don’t know about it, https://www.webpagetest.org/ is a great resource.

I am using css-scope-inline. It uses Mutation Observer and re runs on dom change.