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.
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.
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".
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
@@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.
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).
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 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 :)
@@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.
@@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.
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.
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 :(
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.
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.
@@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.
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 😁
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.
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
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.
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. "
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.
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.
You shouldn't do this you shouldn't do that. I don't do this. I don't believe that. Can we get some agreed upon standards and quit talking about stuff that doesn't really matter?
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.
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
@@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
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!
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
@@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
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.
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
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".
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.
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.
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.
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)
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.
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
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?
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 🤷♂
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.
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.
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.
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.
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"
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.
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.
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! 🎉
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.
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!
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.
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.
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.
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.
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.
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
(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).
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.
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.
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).
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.
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.
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.
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.
Not to mention that if it's anyone's problem it's browsers/bundlers developers problem, not application developers problem.
let's say 100%. totally useless.
Tell this to someone who works in ecommerce
too late already spent 3 days doing it.
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.
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".
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
@@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.
@@pokefreak2112 How is it undebuggable?
yeah. what the heck was the point of the video idk
@@thekwoka4707 Variable spam and every style being its own class makes the inspector incredibly noisy.
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).
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
also that inline css doesn't support many things.
@@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 :)
@@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.
@@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.
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.
Making a problem out of something that isn't a problem, this is the way.
True 🤣
So they can find another crazy fix
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
:(
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.
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.
"CSS Is 2.4x Slower Than Inline Styles" the test is in a react application...
@16.41 If you think a straight line is "grows exponentially", we've got a problem.
Yeah exponential vs linear is a pretty fundamental difference!
log-log scales are quite natural
@@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.
@ruroruro Either way it's besides the point
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 😁
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.
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
Unsurprising. More locality = better performance 99% of the time.
Plus inline CSS doesn't need to worry about selectors
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.
Shall we create a transformer to inline css in build or there exists one before?
Seems the gains are cool
Of course it already exists, angular has been inlining its styles for ages
Vite already offers it.
In Fresh it's done by default.
Try to inline mediaQueries
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.
"
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.
Yes, please make performance measuring chaos video. Thank you in adance
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.
Are there any apps that show me blogs like this guys videos? He finds nice articles but damn would I rather read
12:50 Where does this 200ms number come from? There's no way this kind of latency would feel "instantaneous".
It is 41,67% as fast. Saying 2.4 times slower is just... really confusing.
PLEASE A WEB VITALS CHAOS VIDEO
You .css should not be getting a new hash if the contents don't change. It can remain cached between builds
MEH im gonna embed styles HARDER
Content security policy, anyone?
Media queries are faster in CSS .
That's one website and one test on one machine.... Or 2 if you count mobile. I'm giving a thumbs down not often but this is one of the cases.
You shouldn't do this you shouldn't do that. I don't do this. I don't believe that. Can we get some agreed upon standards and quit talking about stuff that doesn't really matter?
Tailwind for the win!
6:40 DO NOT make bar charts with non-zero baseline! 😡
Logarithmic chart entered chat...
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.
watch me
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
@@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
TLDR on the DX front. If your bosses worry about the speed of CSS vs inline styles, you need different bosses.
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!
Exactly. This is just a discussion as far as I'm concerned.
@@Fs3iIf you have such selectors, you have bigger problems than just speed of loading :)
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
There is runtime considerations as well.
How about single page application?
@@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
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.
Was there a challenge in “how many times can I bring up tailwind before it’s relevant to the actual video”
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
[ graph of straight line ]
[ grows exponentially ]
> pick one
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?
my thought also
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.
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".
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
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.
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.
If you change text on your page, your CSS hashes should _not_ change
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
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.
Nothing else will start loading until html files are loaded. Inline CSS is adding to this payload.
just inline your assets too
Seems like this is addressed in the article
Wrong. HTML is streamed in and other resources get loaded the moment they are parsed, which is usually in the header.
@@pokefreak2112 but its all render blocked until all of the css is loaded
@@pokefreak2112 let me repeat: no other files start downloading until the HTML has finished being loaded AND parsed.
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)
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
CSS is the bane of my life
Let's suffer together.
@@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.
Yes please make the video on perf acronym chaos.
How is this news? Every front end dev knows this, it's the basics. Inline styles -> Inline CSS -> CSS files
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.
pretty useless facts...
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
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?
14kb baby!
If it was the norm, that norm died out brutally at some point.
It used to be the norm that >300ms is too slow. Now that’s >1s. Because?
You know whats even faster? Raw 2D graphics! Lets rewrite all of our websites using canvas! (Sarcasm)
lol that made me laugh
I was looking for an excuse to use inline styles all this time :)
I find ai generated images so boring and lazy. honestly already tired of them.
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 🤷♂
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.
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.
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.
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.
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"
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.
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.
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! 🎉
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.
I agree, for FE devs browser dev tools are must!
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!
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.
This is very common knowledge as well as that CSS-in-JS is just stupid. Most good frameworks just inline your styles anyway…
You should do a dedicated video about FCP/LCP/INP/FID/all of the chaos that is measuring a page's performance.
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.
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.
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.
I thought this has been discussed multiple times over the last 10+ years now people still get surprised over this?
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.
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
I have to say CSS modules seem to solve many problems from scoping, maintainability to bundle size.
Hey, I jus want to know what is the blackboard web app you use to draw the graphics... Thanks.
It isn't taking 9 seconds to load a 65kB image lol. And the image was present in all three
People like to whine about google amp but they do inline CSS probably for these reasons
Inline style may be slightly better for Performance. But it is horrible for maintenance.
please make a video about LCP, FCP etc.
(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).
Like Tailwind :D
Does it matter? Sometimes software is just fast enough.. You dont always need to rewrite it in rust
😂😂😂ccs os faster when..... But uses slowly react.. sooooo completely pointless then.
Maybe you'll finally listen when I say inline CSS is literally better than Tailwind
Different versions of HTTP protocol could also influence the results.
why is css in js (styled components / stitches / ...) slower?
Skydiving is faster without a parachute...
Totally would a deep video on page rendering performance
yeah i can already hear OWASP complaining.
I think ya'll writing too much css to begin with
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.
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.
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).
I render my CSS server-side with PHP 😎😎
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.
A video about FCP, LCP, etc would be appreciated. Even better so if you could explain on how to improve it with NextJS
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.
People’s CSPs are fuming
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.
Read some years ago, about an XSS attack could be possible via Inline styles since then I have never used them
Basically use Tailwind... 😅
please do video on FCP, LCP