I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying with only inline styles and scripts. The threshold where it becomes more subjective is, for most target audiences, possibly over half a megabyte by now.
Seriously, it’s ridiculous just how good inlining everything is for performance, whether for first or subsequent page load; especially when you have hundreds of milliseconds of latency to the server, but even when you’re nearby. Local caches can be bafflingly slow, and letting the browser just execute it all in one go without even needing to look for a file has huge benefits.
It’s also a lot more robust. Fetching external resources is much more fragile than people tend to imagine.
1. Inlining everything burns bandwidth, even if it's 100KB each. (I hope your cloud hosting bills are small.) External resources can be cached across multiple pageloads.
2. Best practice is to load CSS files as early as possible in the header, and load (and defer) all scripts at the end of the page. The browser can request the CSS before it finishes loading the page. If you're inlining scripts, you can't defer them.
3. If you're using HTTP/2+ (it's 2025, why aren't you?[0]), the connection stays open long enough for the browser to parse the DOM to request external resources, cutting down on RTT. If you have only one script and CSS, and they're both loaded from the same server as the HTML, the hit is small.
4. As allan_s mentioned, you can use nonce values, but those feel like a workaround to me, and the values should change on each page load.
> Local caches can be bafflingly slow, and letting the browser just execute it all in one go without even needing to look for a file has huge benefits.
Source? I'd really like to know how and when slow caches can happen, and possibly how to prevent them.
[0] Use something like nginx, HAProxy, or Cloudflare in front of your server if needed.
As is often the case with security, the downsides of locking something down may not be worth the increased security .
Another reason not to prohibit inline scripts and stylesheets is if you need to dynamically generate them (although I think strict-dynamic would allow that).
> External resources can be cached across multiple pageloads.
That only matters if the resource is actually shared across multiple pages