CSS Is 2.4x Slower Than Inline Styles (Oh No...)

[@allinvanguard]

Daily reminder that while interesting, this will not affect 99.9% of the applications we write. If CSS speed is a concern to you, you are likely to have people dedicated to dealing with these small differences. Don't go and rewrite your app. Just don't.

[@proosee]

Not to mention that if it's anyone's problem it's browsers/bundlers developers problem, not application developers problem.

[@HoNow222]

let's say 100%. totally useless.

[@swolebastard531]

Tell this to someone who works in ecommerce

[@walterlol]

too late already spent 3 days doing it.

[@thisweekinreact]

IMHO the point is not to rewrite your app for perf reason. The point is rather: should you consider using inline styles more in the future, particularly if they become more powerful? You can already introduce some today, but will you? And it's not impossible that they'd support nested styles, pseudo attributes and media queries in the future.

[@fredbluntstoned]

TLDR on the DX front. If your bosses worry about the speed of CSS vs inline styles, you need different bosses.

[@Fs3i]

It really really depends on if CSS rendering speed is a problem in reality. And I've seen it happen with heavily interactive pages. Not a blog-post, but like, a figma-style app. CSS can kill you quickly the more interactive you get, especially if people do a div > span > * selector or stuff like that. It's just expensive to match those to every single element!

[@incarnateTheGreat]

Exactly. This is just a discussion as far as I'm concerned.

[@chovnyk_pluve]

​@@Fs3iIf you have such selectors, you have bigger problems than just speed of loading :)

[@deluksic]

6:40 DO NOT make bar charts with non-zero baseline! 😡

[@HansStrijker]

Logarithmic chart entered chat...

[@keithjohnson6510]

To be fair for that chart it's not really changing the intent, but yeah in most cases I would totally agree, you often seen charts that are totally miss-leading when they do this.

[@rawallon]

watch me

[@Imperial_Squid]

While a generally good rule to follow, I think it's fine here. Having a non zero start point can be misleading _if_ you're trying to turn a non existent difference into an actual one, this chart isn't showing an obvious difference so I don't think that rule applies personally

[@SuperElephant]

@@HansStrijker Logarithmic chart still can and should start from zero. It still can show magnitudes of differences between values. There's nothing wrong with the scale, but it's intentionally misleading to just cut off most of the value just to show the "huge ratio difference" in a bar chart. e.g (100 : 92) vs (9:1). The latter has both values -91

[@Atmos41]

You can't use this video to sell Tailwind though. Tailwind is a CSS file. It's the worst case performer here, as it shares the same problems (render blocking, longer parsing, etc). Also he did say that he was using some form of atomic CSS in his tests. The fight isn't "normal CSS vs Tailwind", it's "CSS file vs inline CSS".

[@pokefreak2112]

Tailwind _could_ compile to inline styles whenever possible if they wanted to though. I would consider using it if they pursued this, as it stands their resulting CSS is an undebuggable mess

[@Atmos41]

@@pokefreak2112 At the same time, the article is not proof that you shouldn't use Tailwind either :) it's just an interesting showcase of the CSS file tradeoffs.

[@thekwoka4707]

@@pokefreak2112 How is it undebuggable?

[@HoNow222]

yeah. what the heck was the point of the video idk

[@pokefreak2112]

@@thekwoka4707 Variable spam and every style being its own class makes the inspector incredibly noisy.

[@TheMoonWatcher]

My guess here would be that inline styles are simpler to apply, since you don't have to do the parsing of selectors and applying the styles to all things that match. So it is faster to apply the inline style to the current element. I think the reason why people moved away from inline styles was more for maintainability and less for performance(but I could be wrong).

[@xdarrenx]

Not wrong, this entire video misses the entire point. You know what is faster than js? using C. Literally every abstraction from assembly up hurts performance but increases convenience. This video is either clickbait, or people lack the skill to look at the bigger picture. ABSTRACTIONS ARE BY DEFINITION SLOWER (OVERHEAD). You can make this same video on basically every abstraction

[@thekwoka4707]

also that inline css doesn't support many things.

[@TheMoonWatcher]

@@thekwoka4707 can you give an example here? One thing I can think of is pseudo elements and pseudo-classes, but curious to see if there are other things too :)

[@trapfethen]

@@TheMoonWatcher Any of the various Queries: Media Query, Container Query, Supports Query. They don't support the new CSS Layers standard. Those pop to the top of my mind.

[@msclrhd]

@@TheMoonWatcher Print vs screen vs audio (screen reader) styles. Styles matching attributes (e.g. aria attributes). Media queries also cover things like screen sizes and light/dark modes. Theming by referencing a different colour, etc. theme file or settings (e.g. by setting an attribute on the html element). You also need logic to implement things like alternating the row colour of odd/even table rows.Or inheriting/modifying a base style for buttons, etc. vs styling primary buttons. Or mixing styles like having common warn/info/etc. styles applied to buttons, etc.

[@lukasmolcic5143]

before watching the whole thing, just a quick initial thought, inlining css will be faster for that one page load, cause its one jump less to the server before the page can visually render, but having the styles in separate files means they will be cached locally for all other pages, which in my opinion is a much better win

[@thekwoka4707]

There is runtime considerations as well.

[@adenrius]

How about single page application?

[@lukasmolcic5143]

@@adenrius good point, then you keep the shared css between navigations until you leave the site and come back again before the cache would really make any difference

[@orionh5535]

If you control the server, you can cache the css files after page load, then load css files from cache on page visits after the first load. There are some hicups if you prefer having seperate css files for diferent modules, but there are things you can do to keep things smooth.

[@chepossofare]

Inline CSS are faster only because are non-blocking, but if you have a decent CSS file (eg: above 14kB) caching comes in so you save a block, a connection and payload, so... You only have to pick the right poison. Absolutism is the bane of this job.

[@dmtr_ptrv]

best comment here

[@TheThirdWorldCitizen]

Was there a challenge in “how many times can I bring up tailwind before it’s relevant to the actual video”

[@fronix5060]

Making a problem out of something that isn't a problem, this is the way.

[@600Code]

True 🤣

[@dapedu6768]

So they can find another crazy fix

[@nicholasbrown2021]

I'm going to push back on some of this. I think we've entered into a coding era where people think oh gzip, webpack, whatever will automatically fix everything and make it performant for me The browser still has to unpack all of this Just because a 500kb file can be gzipped down to 30kb doesn't mean you shouldn't try to trim the original as much as you can :(

[@BrankoDimitrijevic021]

8:20 - I believe bundlers will generally hash the content, so if your CSS hasn’t changed, the hash will not change even if you make a new build?

[@davidlacroix9837]

my thought also

[@northerncoder]

Yeah he misunderstands this concept. The hash is based on the content. If he didn’t change any styles the hash would be the same next build.

[@rand0mtv660]

Should be true unless it's configured differently for whatever reason. That's why when you configure Webpack for example, if you do a custom name for your output CSS or JS, you literally use [contenthash] as the part of the name that will be replaced (e.g. "app.[contenthash].css"). It's in the name, "content hash", not "build hash".

[@TurtleKwitty]

He's a react dev, only updating what you need instead of constantly redoing all the work for no reason is a foreign concept to him

[@0dWHOHWb0]

[ graph of straight line ] [ grows exponentially ] > pick one

[@KnightYoshi]

8:30 the hash shouldn't change just because it was rebuilt. The hash should be derived based on the file contents. That way it will only change when that file changes

[@jeremyholman]

@16.41 If you think a straight line is "grows exponentially", we've got a problem.

[@ruaidhrilumsden]

Yeah exponential vs linear is a pretty fundamental difference!

[@Oler-yx7xj]

log-log scales are quite natural

[@ruroruro]

​@@Oler-yx7xjit still wouldn't be exponential even if that was a log-log plot. Also, if that was a log-log plot, having the graphs start at the origin would make no sense.

[@Oler-yx7xj]

@ruroruro Either way it's besides the point

[@600Code]

The misconception here is that only CSS will grow. CSS is reusable like on the tailwind graph but the bundle will grow too, components will multiply, and complexity will increase around the whole APP. If we are talking about plain MPA the same thing is happening there. I think Theo makes these discussible/contradictory topics on purpose. Comments are in many cases more interesting than the original topic 😁

[@JasonLeBel]

What about caching? Can't cache inline styles (unless the HTML is cached) Inline styles should be faster, because they styles are immediate. But at the same time, your styles are repeated. And this example is using a single page? What about an entire site? Not sure anyone said inline styles were bad for performance (in terms of rendering). They're "bad" because of the overall payload. For a small site, it may not matter. But large sites it would.

[@yahi06]

"CSS Is 2.4x Slower Than Inline Styles" the test is in a react application...

[@scragar]

RE: cache I think when discussing cache an important factor is also how often you deploy. At my current company we're very focused on stability and release infrequently(every 2 months), as a result the vast majority of requests will hit the cache because of how long the same film is served. At my previous place of work the focus was very much on rapid deployment, we did biweekly deployments(2 a week) which meant the cache was only ever useful for more than a couple of days. Cache lifetime is always important to consider when talking about the cache, it's useful for reducing overall download to the user long term, but if the cache expires before that's likely to happen you're getting the opposite effect.

[@thekwoka4707]

That's not totally true. You can hash your files, so if a file didn't change, the cache is still valid. So for something like Tailwind, once most things are implemented, you're less likely to bust the cache. Just sweeping invalidation of the cache on deploy is nonsense.

[@szymdzum]

Nothing else will start loading until html files are loaded. Inline CSS is adding to this payload.

[@H8KU]

just inline your assets too

[@SharunKumar]

Seems like this is addressed in the article

[@pokefreak2112]

Wrong. HTML is streamed in and other resources get loaded the moment they are parsed, which is usually in the header.

[@lukasmolcic5143]

@@pokefreak2112 but its all render blocked until all of the css is loaded

[@szymdzum]

@@pokefreak2112 let me repeat: no other files start downloading until the HTML has finished being loaded AND parsed.

[@Kazyek]

Tailwind would bench lower than all of these in rendering time and vitals; it would have been the LOWEST. It's similar to the regular external CSS file, *except* that on top of that you also bloat your DOM with countless useless non-significant elements just for styling hierarchy purpose. DOM should only be a structured representation of the actual data (document), and non-content nodes (div/span) only added when extraneous containers are *specifically* needed.

[@CristianKirk]

I can't believe people actually use tailwind. And it's always interesting to see all these talks about performance efficiency in the age of bloated and clunky frameworks.

[@thekwoka4707]

Wouldn't this be obvious? It doesn't have to do selector tree matching, which is really heckin hard (and was one of the first things Firefox did in Rust)

[@dedicatedserver8214]

I thought CSS is non-blocking? When I go to a page I see html and then content shift/font load and jump all the time

[@rand0mtv660]

CSS is a render blocking resource. Font based content shift isn't tied to CSS loading necessarily, it's tied to fonts being loaded. Your CSS can be loaded and parsed and applied already, but for example maybe Google Fonts is slower at that moment and then when font does load, it will be applied and cause layout shifts because dimensions of text elements slightly changed. Other layout shifts might be caused by elements appearing after page load or changing their dimensions after page load. Maybe ads in an article or an image being loaded without width/height attributes or explicit size controlled through other means.

[@YazeedAlKhalaf]

Shall we create a transformer to inline css in build or there exists one before? Seems the gains are cool

[@yankotliarov9239]

Of course it already exists, angular has been inlining its styles for ages

[@thekwoka4707]

Vite already offers it. In Fresh it's done by default.

[@600Code]

Try to inline mediaQueries

[@houseandhobby6971]

All 3 categories are CSS: inline, page-level local, and then external file-based. The cascading aspect of CSS, the need to implement the cascade--it exists thanks to allowance of those degrees of locality of the styling and the need to give priority to otherwise conflicting CSS declarations. Thanks for the vid.

[@roei7111999]

2:26 External CSS = Fetching CSS from another file Internal CSS = Using the style tag Inline CSS = Using the attribute () Although inline CSS is naturally faster to load, it's impractical to build a website like this. You can use some magical JS compiler that will add the inline CSS to every element, but then the argument will be that the library takes time to compile... It all comes down to "Is it easy enough to maintain while keeping the outcome fast"

[@tangentfox4677]

The biggest thing I think of every time I see something like this is why are you shipping so much CSS to begin with? You don't need that much to have a good design.

[@figloalds]

This is very informative, in this day and age with the current web frameworks like Svelte, React, Angular, Vue we already have component scope, having the styles be inline isn't a hard thing to do and if a single component is getting too big we can split it up; However, if this is truly a 2x performance concern, I can see these web frameworks working in a way that bundling would pre-cascade the stylesheets and make them inline, it might sound hard, but it's not impossible. I'd say the extra performance cost goes into actually evaluating the selectors and cascading the style sheets, when the style is inline there's nothing to eval or cascade, you can just skip over properties that were set inline

[@dogoku]

You know whats even faster? Raw 2D graphics! Lets rewrite all of our websites using canvas! (Sarcasm)

[@amrojjeh]

lol that made me laugh

[@nicholasbrown3443]

Here's a way to really put a wrench in things. Qwik style rendering which is cacheable. Of course, you have overhead of injecting but ..... page size is reduced by like 80% and loading extremely small files per block. Then, of course you have media queries to worry about. So, split core styles into inline. Then, desktop / mobile into a split CSS link in the injected HTML w/ "media=" block. The server can respond which layout (mobile vs desktop w/ desktop vs mobile queries) to respond with based upon WURFL

[@shgysk8zer0]

Hey, I remember this. Had a bit of a conversation with the author on Reddit. I was one of the people who pointed out issues like caching, compression, reduced size of HTML, and also the issue of writing efficient CSS (styling each element individually and duplicating things is quite different from eg utility classes).

[@SaHaRaSquad]

12:50 Where does this 200ms number come from? There's no way this kind of latency would feel "instantaneous".

[@Slate245Ivanovo]

Theo, I think you're wrong about hashes at the end of files (about 8:30) Hash changes only when file is different after build. If you change a word in your blog, it doesn't affect the css produced, and the hash doesn't change. Astro is smart

[@dvkerns]

Yes please make the video on perf acronym chaos.

[@pokefreak2112]

Unsurprising. More locality = better performance 99% of the time. Plus inline CSS doesn't need to worry about selectors

[@nickolassiriluck1538]

CSS is the bane of my life

[@saiphaneeshk.h.5482]

Let's suffer together.

[@hungrymusicwolf]

@@saiphaneeshk.h.5482 This is one of the few problems I'd rather shove off onto someone else. So I'll have to decline your invitation.

[@brandon14125]

8:38 thats kinda bash cache busting though right? That hash should correspond to the CSS file only. So only changes when somthing in the CSS file changes.

[@keithjohnson6510]

I kind of see Tailwind as inline styling to some extent, and for pure CSS approach is nice. One big advantage of true inline styling is that it works perfect for bundle splitting. The point Theo makes about Talwind not growing larger as the project gets bigger when compared to inline is not strictly true either, you can also bundle your inline styles to re-use on other components. eg. const redButtonStyle:React.CSSProperties = { backgroundColor: 'red'}, place in it's own file, and the bundler will split, really nice for websites with lots of pages. You can also compose styles to makes things even smaller, eg. const bigRedButton = {...redButtonStyle,...bigButtonStyle}, etc. Of course you could do some form of composing with Tailwind class names too, but again you do have that initial CSS bundle to load first, so you don't get perfect bundle splitting. Because inline styles can just be made with JS/TS code, you have the power to just dynamically create new styles too. Finally one main advantage of inline style is CSS Specificity, there basically is none, no special IDE plugin needed. One disadvantage of inline styling is of course pseudo classes, I get around this by dynamically injecting Styles in the Head.

[@HansStrijker]

I'll still use separate hashed css files if at all possible. Simply because you don't depend on js/wasm/whatever being enabled in visitor's browser, and it can be parsed by command line browsers like Lynx. And with the newest css, there's a lot you can do without any need for js.

[@waffleNaut]

You should do a dedicated video about FCP/LCP/INP/FID/all of the chaos that is measuring a page's performance.

[@ErazerPT]

I'm not a web front end guy so maybe that's why i don't see why it would be any different as i (by default) go to "pipeline". If you inline, you're providing the static info at the point where it is instanced. It's part of the "object". If you use it in an "inline stylesheet", now you have to instance AND get it by reference to the inline styles. If from file, you instance, block waiting for the file THEN change your instances to reflect the info on the file. Add to that that the pipeline can make A LOT of assumptions based on the information it already has at any moment, so the more you have a priori, the more the engine can infer/assume. That said, let me put my old guy pants on and... You're shifting work client>server. Not a big issue if you're serving modest loads, but if you ever need to serve MASSIVE loads, that extra processing needed will bite you. Also, you're preventing re-use of a cached file ACROSS PAGES. Which is why the tests are "bad". It's not just on one page of the site, its ACROSS n different pages. But honestly, the question is really : WHY do you need all that CSS... Ikr, business/marketing/design all breathing down your throat for "MUST HAVE THIS". Sucks.

[@anon_y_mousse]

I would actually expect these results because it only has to fetch one file to process the page contents and start displaying things. However, I would also expect that a website that was developed properly would have some degree of backup mechanisms in place to allow for rendering to happen prior to the main stylesheet being fully loaded. What I am surprised by is the difference between inline styles and inline CSS with the style tag. That is where I would expect no difference, yet inline styles were faster, and while it wasn't expected I think I know why. Also, I would like to see a video on the whole rendering pipeline.

[@protocol6]

It'd be fun to write an inlinify tool that cascades all your CSS and applies it as inline styles in a compile step. I'm not convinced it'd be a good idea in most cases but it'd eliminate one of the arguments, maintainability. The problem would be on more dynamic pages where content gets inserted by code. It'd be a serious challenge to handle that automatically.

[@JMIK1991]

I dont know if this is how new browser does things from about 3 years ago... I like to meta preload files like css and images before drawing of the website starts. Browsers wont load them before handling the html and usually draws atleast once, even on same device. Without it on the website blocks on screen started to rearrange and images flash their background momentarily.

[@tyriceclark4283]

I actually was thinking about this when working on a small web page. I feel css was made to more address the issue of sharing styles between elements and less for separation of concerns. Interesting.

[@asmod4n]

Wasn't it the norm for decades to send the most critical http, html and css in the first network packet to the browser for the fastest first paint possible?

[@orionh5535]

14kb baby! If it was the norm, that norm died out brutally at some point.

[@ArneBab]

It used to be the norm that >300ms is too slow. Now that’s >1s. Because?

[@matej-world]

I was looking for an excuse to use inline styles all this time :)

[@TheUnknownFactor]

If you change text on your page, your CSS hashes should _not_ change

[@asjsjsienxjsks673]

Maintainability not performance is the reason we don’t use inline styles. Now if we could create a post processor to convert to inline styles that would be something but good luck debugging one element at a time

[@CouchProgrammer]

I'm wondering how an example without using media/pseudo elements/selectors can be called realistic. I started my career with Html 4.01 documentation and now people are conducting experiments to test the facts. Sounds like SCRUM. Html 4.01 about "why we need inline style": Some people have voiced concerns over performance issues for style sheets. For instance, retrieving an external style sheet may delay the full presentation for the user. A similar situation arises if the document head includes a lengthy set of style rules. The current proposal addresses these issues by allowing authors to include rendering instructions within each HTML element. The rendering information is then always available by the time the user agent wants to render each element.

[@NickMarcha]

I just want to highlight a reply on the blogpost from the author of this post: " @Wout Mertens I agree that tailwind would likely scale better, in terms of size, than other methods of authoring CSS. When it comes to load performance, however, I don't believe that it would perform best. Any CSS is a potential tax on first paint, and tailwind isn't exempt from that fact. When it comes to repainting, tailwind may perform better than inline styles. It is theoretically less work for the browser to parse the class attribute than it is for it to parse the style attribute. It is unknown if this is significant or not. My blog post mainly focuses on load performance. "

[@brnmln]

How is this news? Every front end dev knows this, it's the basics. Inline styles -> Inline CSS -> CSS files

[@TommieHansen]

Key word there being "dev". So called fromt end devs nowadays doesn't seem to have the slightest grasp on how browsers and css actually works since most of them seem to be at a very beginner level or is strictly using ie framework A + B + C.

[@farzadmf]

Definitely want one (or more :P) separate videos about performance "things"!

[@saikouhuebr]

Hey, I jus want to know what is the blackboard web app you use to draw the graphics... Thanks.

[@furycorp]

I think I'm more surprised that the difference is so small given the huge complexity of cascading style sheets and the interplay between css styling vs. the much more direct inline style. Not that the difference is really relevant for nearly every app in existence vs. where real-world hits to performance take place.

[@m4rt_]

no shit it's faster. there is less to parse, and there is no need to figure out how it all connects, IIRC inline styles override the styles in the style sheet, so there is just parsing what it means, and then just applying that.

[@canalbomon]

(I only read the title) Of course, at least I imagine so. But the downsides of using inline CSS are greater than just speed. Would I have to load a huge HTML file with embedded styles every time I open it? Having them separated makes partial loading possible. Although tools like Tailwind, from what I see, have brought some of this embedding of styles into components, as now there are several fragmented classes placed in the components (I even thought that Tailwind handled this and merged several classes in production to avoid a huge HTML with classes, but from what I understand, it is not done).

[@600Code]

Like Tailwind :D

[@pencilcheck]

I thought this has been discussed multiple times over the last 10+ years now people still get surprised over this?

[@thisweekinreact]

Always fun to see my link suggestions leading to a new Theo video 😄

[@dansurfrider]

A video about FCP, LCP, etc would be appreciated. Even better so if you could explain on how to improve it with NextJS

[@wildwoodways5812]

Tailwind is an awful, awful antipattern. USE THE PLATFORM like it was intended. CSS works the way it does BY DESIGN you just need to LEARN IT

[@viccie211]

I would love to see a video about the different contentful paints and stuff. It's something my colleagues and I are struggling to get down with our react app.

[@m33gs]

Read some years ago, about an XSS attack could be possible via Inline styles since then I have never used them

[@markebling]

I wish I had a dollar for every MB of junk CSS and JavaScript I've had to download to view just a couple pages of a site where those files were packed with code for all their pages I will never view. I believe this consideration was overlooked in this analysis.

[@marcialabrahantes3369]

what about tailwind? 🤔 since it's a mix

[@FunctionGermany]

please make a video about LCP, FCP etc.

[@Borret]

Are there any apps that show me blogs like this guys videos? He finds nice articles but damn would I rather read

[@speedstyle.]

It isn't taking 9 seconds to load a 65kB image lol. And the image was present in all three

[@TheAprc1]

Yes, please make performance measuring chaos video. Thank you in adance

[@jasonc6241992]

Is there a library that will take your style sheet selectors and apply it inline?

[@fouilhj]

What you said about a new hash being generated on every build is NOT true. Most solutions generate the hash from the contents of the file. So if that specific CSS file content is not changed, the generated hash stays the same, and users will hit the cached version. It will only change when the file actually changed, and therefore it needs to be updated for all users.

[@gedoumazoutsuki]

so we should compile css like, your css goes in the spot its call and replaces the class with the properties? can you imagine. you can code your sht well and organised but when you build theres no more css files :p

[@ArneBab]

Do you have a FIrefox comparison? Firefox tends to leave Chrome in the dust for CSS.

[@keithjohnson6510]

In my tests, Firefox on Linux, is slower for me. Not by a lot to be fair. Firefox certainly didn't leave Chrome in the dust anyway.

[@ArneBab]

@@keithjohnson6510 that’s strange, because in most *CSS* tests I saw firefox won by a lot.

[@ArneBab]

@@keithjohnson6510 FF being faster for CSS doesn’t work for every strategy of using CSS, but when you write the CSS as it has been best practice for the past decade, firefox was faster. I realized that when I looked at shadow-dom tests and they made much more of a difference for Chrome. Is it possible that the way react adds CSS is optimized for Chrome? On the linked page I also see much better web vitals in Firefox. But inline styles make even more of a difference there (?).

[@keithjohnson6510]

@ArneBab Yeah, it could be down to the types of CSS etc. Going on CSS Zen Garden, and trying lots of variants, side by side, I couldn't see any difference in speed. I think both browsers perform well. The main reason I stick with Chrome is that FF for some odd reason dropped support for progressive Web apps on Desktop, with no plans to support in the future.

[@rand0mtv660]

There is a chart for Firefox in the article. First chart in "Web Vitals" section has a dropdown where you can pick browser being tested. Firefox is battling with Safari it seems. Chrome is behind them. I'm actually surprised Safari is that fast, props to them as well. As far as I know, Firefox does have the fastest CSS engine out of all the browsers. They did rewrite their CSS engine some time ago. I've seen it win since then in other articles people have done on CSS performance.

[@joshuagriel4679]

Yeah, now do this experiment again and measure how long it'd take for a dev to go back and change 20 buttons that all use the same styling across 12 different files, lol.

[@GhiveciuMarian]

hash in css filaname is a no-no in my book, it is a nice way to pollute the browser cache. if you have a CSS file of 500K and deploy it 10 times without changing the css, only some text in app.. voila 5MB in disk usage for next month or how long browser keeps the cache.

[@j0hannes5]

why is css in js (styled components / stitches / ...) slower?

[@Vecusum]

This performance data indicates that the author doesn't actually know how to optimize render and CSS performance more than anything else. The sizes of variances are the telling factor here. BEM doesn't exactly encourage efficient selector choices from a performance standpoint.

[@gergelyvarju6679]

Different versions of HTTP protocol could also influence the results.

[@andgoedu]

Yeah But Inline Styles Look Horrible inside a file , for debugging i prefer tp debug a small page with the styles in another seperate file for more organized file and rewriting the whole css or scss for 1.3ms difference is not worth it , you should be focusing on optimizing assets and webcache and whats really causing the issue not css.

[@600Code]

I agree, for FE devs browser dev tools are must!

[@filaments]

please do video on FCP, LCP

[@HoNow222]

I find ai generated images so boring and lazy. honestly already tired of them.

[@ProtectMeYou]

PLEASE A WEB VITALS CHAOS VIDEO

[@adirmugrabi]

Inline style may be slightly better for Performance. But it is horrible for maintenance.

[@gro967]

This is very common knowledge as well as that CSS-in-JS is just stupid. Most good frameworks just inline your styles anyway…

[@piotrkmiec6590]

Does it matter? Sometimes software is just fast enough.. You dont always need to rewrite it in rust

[@Matt23488]

Maybe you'll finally listen when I say inline CSS is literally better than Tailwind

[@wsollers1]

Totally would a deep video on page rendering performance

[@600Code]

Ahh, Inline doesn't allow you media queries, combinators, parent/child selectors and your markup is a mess ... Keep in mind, you are writing the code once and read it 100x, browser dev tools are an important tool for FE development. Oh oh, inlining CSS is shooting in your leg 🤷‍♂

[@amodo80]

Skydiving is faster without a parachute...

[@ray73864]

I will say this, when doing your testing, test wifi AND ethernet. These days, majority of your users are likely to be browsing your site using wifi or mobile, so if you only test using ethernet, then you aren't really doing a proper test, thankfully your browser dev tools lets you simulate different connection methods!

[@Xe054]

Thanks for releasing the 1am content

[@Naton]

yeah i can already hear OWASP complaining.

[@tobiasfedder1390]

Organizing CSS with BEM, that's like inline styles with extra steps.

[@lukasmolcic5143]

the css skill issues in the React community are really killing me

[@tobiasfedder1390]

@@lukasmolcic5143 Absolutely.

[@600Code]

How do you organize CSS?

[@tobiasfedder1390]

@@600Code Currently I prefer the CUBE CSS methodology. Unfortunately I've to use BEM in most projects, which abandons the cascade to prevent "side effects" in larger code bases / teams. In my experience then relying on SASS mixins to keep it somewhat DRY, thereby reintroducing "side effects" right away.

[@600Code]

@@tobiasfedder1390 yes I agree. CUBE CSS is inspired by BEM methodology. Regarding DRY, It is not always perfect to be DRY because we are not machines and there is fine line between readability and maintainability andy DRY complexity. Did you ever tidy up your room, drawer, desk ... and you realized that you can't find anything anymore?

[@BrianJorgensenAbides]

I’m a man of science, but I didn’t make it through the red herrings. What is your opinion of experimental experience, maan!? I love youtube; theses still need to be in the first one minute for the MTV generation, and you’re dealing with tik tok now. I have elixir conference talks to watch! 🎉

[@mnnnw]

People like to whine about google amp but they do inline CSS probably for these reasons

[@SekGuy]

It is 41,67% as fast. Saying 2.4 times slower is just... really confusing.

[@jceggbert5]

I render my CSS server-side with PHP 😎😎

[@ehutch79]

You .css should not be getting a new hash if the contents don't change. It can remain cached between builds

[@aLfRemArShMeLlOw]

kzbin.info/www/bejne/Z5i9np6mqLt6oc0si=wDguZXU6yFh_kcT7&t=502 That hash is based on the contents of the file, so it doesn't change unless the file has been changed.

[@lorenzobignardi8605]

is being 5th still worth being mentioned?

[@pizzabossxd]

yes

[@Sindoku]

Inline styles and inline head style tags are not safe though. They open your site up to XSS attacks. I think it’s best to do something similar to what Chakra does only use “const styles = new CSSStyleSheet();” and pass props to your components like “height=“3.2rem” which uses the “insertRule” method on the style variable to insert CSS dynamically. That also reduces bundle size as it only makes the styles your app actually uses on a user by user basis according to the components they interact with in the UI (you do need a map to cache the styles to achieve this). I might make a new React library just to promote the idea more soon. I’ve already made it at work on a team of 15 developers and multiple teams too and we are using it without any issues.

[@keithjohnson6510]

XSS attacks are only appropriate were you allow 3rd party / users / advertisers to inject HTML/CSS, eg. A blog post that allows uses to post formatted content etc, (this always needs sanitising). if it's you doing inline styles then there is no more of a chance of an XSS attack, compared to an external CSS file.