inline CSS counts?

Not really a short term hack.

Google even recommends that if it's not much and saves a round trip at least for the content above the fold.

If it’s in <style> tags I can live with it, if it’s on an element as <div style=alotOfCss:here> I’ll cry

@C0D4 yeah not only that it sucks, it's also a road block for implementing CSP.

@C0D4 try making an html email sometime. Many tears involved.

@taigrr emails are the only place inline is acceptable, I know that hell all too well.

@C0D4 @taigrr agreed

@C0D4 not acceptable, but unfortunately required :/

@C0D4 at least it’s readable. Plus there are loading benefits on inline style

@Voxera acceptable as a necessary evil 😩

@sunfishcc I suppose, but if your reusing the same styles constantly for the same elements, it makes sense to make them reusable rather then inline everything. Good luck doing site wide UI changes otherwise.

@C0D4 True. But I often use inline style in React, which is a totally different game. Even though there’re lots of duplicates in the dom, they comes from js bundle. And that component only occurs once in is. Which is quite interesting if you think about it🤔

@sunfishcc for some very localized css inside a component that does not really concern site overall, for example positioning inside the component yes, but not style that need to match any other components, then you still should use separate css.

I only use inline css

@AL1L 😱

@AL1L what about media queries?

@nothappy he uses 100% inline css, what are the chances he does responsive development

@Voxera according to google page speed, since the initial dom will render only after all css downloaded, inject css inside header can be considered as a optimisation. Am I off topic?

@sunfishcc inside the header isn't the same as inline. You can still use classes and ids and other selectors within style tags in the header.

Though what you're saying is true, it's often faster since you don't incur multiple RTTs (Round Trip Times) for downloading external files, keep in mind that if a user visits your site more than once, it will be really fast the next couple times if your caching is set up properly.

Additionally, shared resources such as bootstrap css or jquery are probably loaded and cached from someone else before they even visit your site if you source it to a popular CDN.

@taigrr 🤦‍♂️totally forget about cache.im a f12 cache disabled man.btw in-line still wont hurt performance in react or vue template. Since the inline styles are actually saved in js, and that js file is cached✌️

@taigrr you can even combine both ways. Like putting a stripped down version in the header for the main index page and then loading the full CSS file via prefetch so that it will be in the browser cache for the other pages. Doesn't work for Safari, but meh.

@Fast-Nop Right. Unfortunately, thanks to the iPhone, Safari is still a major player.

@taigrr right, but then Safari will just have one round trip more for subsequent pages. Means, Safari doesn't actually suffer, but everyone else gets a little more speed.

@Fast-Nop yeah, I guess there's no real downside. Slightly bigger total bandwidth, but we're not on 2g anymore so it's probably negligible. Just make sure changes affect both definitions before pushing to prod, haha. Probably easy to miss updating the index definitions with the speed of localhost overriding them immediately.

@taigrr yeah it's a little bit of extra work. However, prefetched CSS doesn't get parsed in the prefetching page itself, only in the next ones where it's retrieved from the disk cache. So at least, it's easy to notice when changes are missing.