←back to thread

182 points evilpie | 5 comments | | HN request time: 0.001s | source
Show context
theandrewbailey ◴[] No.43630873[source]
CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though <link>, and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.
replies(6): >>43630934 #>>43631184 #>>43631253 #>>43632334 #>>43633733 #>>43635528 #
chrismorgan ◴[] No.43631184[source]
> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.

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.

replies(4): >>43631249 #>>43631792 #>>43632338 #>>43632478 #
1. eru ◴[] No.43631792[source]
I think that's a limitation of our implementations. In principle, it's just bytes that we shoving down the pipe to the browser, so it shouldn't matter for performance whether those bytes are 'inline' or in 'external resources'.

In principle, you could imagine the server packing all the external resources that the browser will definitely ask for together, and just sending them together with the original website. But I'm not sure how much re-engineering that would be.

replies(2): >>43631989 #>>43632398 #
2. erikerikson ◴[] No.43631989[source]
In principle there's no difference between principle and practice.
replies(1): >>43633267 #
3. Perseids ◴[] No.43632398[source]
This feature actually existed (see https://en.wikipedia.org/wiki/HTTP/2_Server_Push ) but was deemed a failure unfortunately (see https://developer.chrome.com/blog/removing-push )
replies(1): >>43633273 #
4. eru ◴[] No.43633267[source]
Simple models are still useful: understanding exactly how and why they fail is instructive. There's a reason spherical cows in a vacuum come up again and again.
5. eru ◴[] No.43633273[source]
Thanks for the links! Yes, my comment was based of a vague recollection of this kind of thing.

I'll read up on the '103 early hints' and 'preload' and 'preconnect' which might be close in enough practice.