5 ms·

My talk on CSS runtime performance

114 points by luu 3y ago

skrebbel 3y ago
Wow this was a great talk. I hardly ever manage to watch videos of talks through to the end anymore, for reasons of internet social media attention span etc etc. But this one just sucked me right in. I didn't even know that I didn't know what the browser is doing when it's "styling", love it.
- CharlesW 3y ago
  Agreed, it's so worth the watch. Thank you Nolan, if you happen to see this!
  - nolanl 3y ago
    Thanks a lot! I was just trying to highlight the cool work that browsers do under the hood, but which wasn't very well-known. So I'm really glad that folks enjoyed the talk. :)
AlienRobot 3y ago
I wish these CSS selector details were better documented somewhere. For example, if right to left is always true, then .cls[attr="value"] is always slower than [attr="value"].cls But I never see anybody using the second one. I think it's also interesting that there is no way to do figcaption.cls inverted like .clsfigcaption. It's strange that default CSS that comes with tools like Wordpress abuses pseudo-selectors as much. I think everyone just writes it off as "it's the CSS 3 way." On interesting example is that some javascript libraries to highlight code syntax will use ancestor selectors like .highlighted .keyword, which in my mind is crazy. You are making the classes through javascript, you could just use a single glass, which is what Highlight.js does: its classes look like .hlts-kw. One time I had to deal with layout in CSS being too slow. It was not because of webpage, but an electron app for android that needed to get the bounding rectangle a lot to place divs for its custom GUI elements on screen. Since changing the DOM/CSS changes the bounding rects, placing a div and then checking the bounding rect again was a performance cost. The solution ended up being caching the client rect once before updating the DOM to avoid the thrashing. Anyway, great talk :D I hope more people become aware CSS isn't magic, nor a black box, so they can think twice before writing their selectors. Sometimes I see CSS code with superfluous nested ancestors (e.g. .wrapper .content .post-body img), and I think that happens because it really just works, but unfortunately it seems that mentally carries on after a developer stops being a beginner, because the CSS just keeps working anyway.
- CharlesW 3y ago
  > .cls[attr="value"] is always slower than [attr="value"].cls Hey, have you instrumented this by chance? I assumed browsers have pretty smart query optimizers by now.
  - AlienRobot 3y ago
    No, I haven't. But I'm assuming it is based on the "right to left" concept while you are assuming it isn't based on browsers' ability to optimize this. The spec says nothing about it and I have never seen any documentation saying "this case will be optimized." And this is the problem with it, imho. Why would this be optimized but not .cls :has(.foo) .bar? Is :nth-child optimized? Should I do [attr]:nth-child or :nth-child:is([attr])? There are several ways to write the same complex selector and a lack of first-party guidelines about the best way to do it. Edit: to illustrate my point better, it used to be that if you wanted to make a table with alternating row colors you just used a class on each row. Then :nth-child(odd) and :nth-child(even) came out and everyone was like "just use that instead! No more classes in every row!" And now we have .foo-table :nth-child(odd) > td because obviously there's a tbody/thead/tfoot between tr and table and nobody knows if you should do this or .foo-table > :is(thead, tfoot, tbody) > :nth-child(odd) > td or which one is faster or if you should just use .odd > td because HTML TABLES ARE THE REAL EVIL TABLES IN WEB HISTORY. CSS TABLES WERE SAINTS COMPARED TO THIS. Anyway, every browser has different optimizations, and I have 5 different ways to make a row color alternate. This is the problem. When we have actual complex styling that makes use of the most powerful CSS selectors, all common optimization for simple stuff fall apart. So why even use powerful CSS selectors when they have potential to be permanently slow on HTML code that you may not ever be able to change in the future?
    - CharlesW 3y ago
      > …while you are assuming it isn't… I'm honestly just professing ignorance! Along with generally wondering about the state of CSS query optimizers, I think the two have the same specificity, which (in my very-incomplete mental model) makes me think that they're about the same amount of work to resolve. If Nolan stops by maybe he can weigh in. :^)
baggy_trough 3y ago
I just have this vague sense of dread about the tens of thousands of style rules trying to match on each element.
begueradj 3y ago
It never came to my mind to think about CSS from this perspective. Very useful information.

114 points by luu 3y ago

Wow this was a great talk. I hardly ever manage to watch videos of talks through to the end anymore, for reasons of internet social media attention span etc etc. But this one just sucked me right in. I didn't even know that I didn't know what the browser is doing when it's "styling", love it.

CharlesW 3y ago
Agreed, it's so worth the watch. Thank you Nolan, if you happen to see this!
- nolanl 3y ago
  Thanks a lot! I was just trying to highlight the cool work that browsers do under the hood, but which wasn't very well-known. So I'm really glad that folks enjoyed the talk. :)

AlienRobot 3y ago

I wish these CSS selector details were better documented somewhere. For example, if right to left is always true, then .cls[attr="value"] is always slower than [attr="value"].cls But I never see anybody using the second one. I think it's also interesting that there is no way to do figcaption.cls inverted like .clsfigcaption. It's strange that default CSS that comes with tools like Wordpress abuses pseudo-selectors as much. I think everyone just writes it off as "it's the CSS 3 way." On interesting example is that some javascript libraries to highlight code syntax will use ancestor selectors like .highlighted .keyword, which in my mind is crazy. You are making the classes through javascript, you could just use a single glass, which is what Highlight.js does: its classes look like .hlts-kw. One time I had to deal with layout in CSS being too slow. It was not because of webpage, but an electron app for android that needed to get the bounding rectangle a lot to place divs for its custom GUI elements on screen. Since changing the DOM/CSS changes the bounding rects, placing a div and then checking the bounding rect again was a performance cost. The solution ended up being caching the client rect once before updating the DOM to avoid the thrashing. Anyway, great talk :D I hope more people become aware CSS isn't magic, nor a black box, so they can think twice before writing their selectors. Sometimes I see CSS code with superfluous nested ancestors (e.g. .wrapper .content .post-body img), and I think that happens because it really just works, but unfortunately it seems that mentally carries on after a developer stops being a beginner, because the CSS just keeps working anyway.

CharlesW 3y ago
> .cls[attr="value"] is always slower than [attr="value"].cls Hey, have you instrumented this by chance? I assumed browsers have pretty smart query optimizers by now.
- AlienRobot 3y ago
  No, I haven't. But I'm assuming it is based on the "right to left" concept while you are assuming it isn't based on browsers' ability to optimize this. The spec says nothing about it and I have never seen any documentation saying "this case will be optimized." And this is the problem with it, imho. Why would this be optimized but not .cls :has(.foo) .bar? Is :nth-child optimized? Should I do [attr]:nth-child or :nth-child:is([attr])? There are several ways to write the same complex selector and a lack of first-party guidelines about the best way to do it. Edit: to illustrate my point better, it used to be that if you wanted to make a table with alternating row colors you just used a class on each row. Then :nth-child(odd) and :nth-child(even) came out and everyone was like "just use that instead! No more classes in every row!" And now we have .foo-table :nth-child(odd) > td because obviously there's a tbody/thead/tfoot between tr and table and nobody knows if you should do this or .foo-table > :is(thead, tfoot, tbody) > :nth-child(odd) > td or which one is faster or if you should just use .odd > td because HTML TABLES ARE THE REAL EVIL TABLES IN WEB HISTORY. CSS TABLES WERE SAINTS COMPARED TO THIS. Anyway, every browser has different optimizations, and I have 5 different ways to make a row color alternate. This is the problem. When we have actual complex styling that makes use of the most powerful CSS selectors, all common optimization for simple stuff fall apart. So why even use powerful CSS selectors when they have potential to be permanently slow on HTML code that you may not ever be able to change in the future?
  - CharlesW 3y ago
    > …while you are assuming it isn't… I'm honestly just professing ignorance! Along with generally wondering about the state of CSS query optimizers, I think the two have the same specificity, which (in my very-incomplete mental model) makes me think that they're about the same amount of work to resolve. If Nolan stops by maybe he can weigh in. :^)

baggy_trough 3y ago

I just have this vague sense of dread about the tens of thousands of style rules trying to match on each element.

begueradj 3y ago

It never came to my mind to think about CSS from this perspective. Very useful information.