 The other day I posted a video and the comments to that video sent me down a bit of a rabbit hole. It got me looking into old articles and watching old conference talks and I was messaging people and trying to learn more about these things because it wasn't something, a world that I've really been really deep into. And this all started from my video where I talked about semantic CSS where to be able to do that I was saying that we could use attribute selectors to select things based on their area attributes or their roles rather than using classes like we might traditionally do. And that got a lot of comments, a surprising amount of comments asking about the performance of attribute selectors. There was quite a few people to saying we can't use attribute selectors, they're too slow. And it really got me wondering, did I give some bad advice? Because as we know, website performance is really important. But it also got me wondering, is there that many people that concerned about the performance of our selectors the browsers these days are so good at what they do. But I needed to look it up. And the more I learned and the more I'd figure out and I'd be happy with my answer and go, no, it's all fine. And then I'd think of something else to test. And it was just this thing that kept eating at me for a really long time. And we're going to dive into how we can test it because it's actually the timing of all of this was really good because it's actually a lot easier to test these things now. But it also led to me realizing that there's probably one selector that you've used on every single one of your projects, which is not an attribute selector, it is probably the worst one you could possibly have for performance. So we'll get to there in a little bit. But before we get into that, let's dive into the code and see how we can actually test these things. And we'll go through a little bit of the process that I went through myself in comparing all of this. And if we go here right now, we can see here is a couple of selectors that I've set up for this project here. And this is an old project that I took. And you can see I have line numbers off for demos, but you can see it goes on and on and on and on. We have thousands of elements on this page. We'll figure out how many we have in a little bit. Exactly. But there's lots going on here. There's a lot of nesting going on in different stuffs. We can test lots of different things. But as I said, the first thing that came up was a class selector versus an attribute selector. And if we see I have the class of next, and anywhere that has the class of next also has the area label of next. So I wanted to test that. And it also made me think what about like these more complex types of selectors like that. And since we're doing this too, what if we used an attribute selector like class is equal to next, which we could also do. And I'm just doing very simple things here for what it's actually doing, because I'm not worried about the performance of rendering. It's just how long does it take for the browser to parse the selector itself. And you'll might notice on this side, I'm actually have edge opened. And that's because edge has recently added this to their dev tools. You know, edge these days is running Chromium, but this is, they've sort of done their own thing with their dev tools a little bit and have some unique features that other browsers don't in this is one of them as far as I know. So when you're in edge, you want to open your dev tools, we can go to inspect or however you like to open them. And from here, what we're going to do is go over to the performance tab. And in the performance tab, there's two things we want to do. The first is this enable advanced rendering instrumentation should be on. We need to have that on for this to work. It does slow things down quite a bit, just as a word of warning. And the other thing I'm going to do is my CPU, I'm going to put it on to forex to slow things down, just because then it creates a bigger difference between them all, a lot of us are running on good computers. So slowing things down, it just exaggerates the issues a little bit, which makes it more obvious if there is something that we should be looking at. Because it exaggerates the differences we can see them, because if not, they can be really, really small, just as a word of warning. And I'm going to click the refresh here. And I'm basically going to wait for this page to stop loading, which takes a while because there's so many elements and with that CPU slowdown on there, it's going to go for a little bit. One of the reasons, well, that's going actually now I can click stop. When you click stop, it's going to take a while. So I'll take this moment to just say one of the reasons I have this many elements on the page is because the differences I was getting at one point were so small. I said, I need to throw a ton of stuff at it, basically. And I wanted to find as much things, I wanted to put as much in place as I could to exaggerate the differences between them, just to really highlight what was what was going on. But there we go. That is finished, as you can see, it does take a little while. And you sort of get a breakdown of the performance, you can see different stuff going on. If you've never been in here, don't worry about it. We're going to keep it pretty simple, but there's a few different sections. And we need to get down to this one that you can see the frames, there's like the network and then the frames, this frames one here, we can even we can make that a bit bigger. And we have a scroll bar here. And I'm going to scroll down. Until I see this, we have the four and a half seconds just on my HTML. And then I have this recalculate styles here. So it took 1.33 seconds just to recalculate the styles and basically break all of that down. So I'm going to click on that recalculate styles there. And then we can move this up. And let's see if we can give ourselves a little bit more room to see what's in here. We can see the selector stats here. You didn't have enable advanced rendering instrument instrumentation on selector stats is not there. And just really fast because it is chromium edge is available on Mac as well as Windows. So we get my selector stats there and you can group them or you can change the ordering just by clicking and changing, you know, which one you want to organize by basically. So let's reverse it and and actually, let's just go by selector, I guess, and you can see my next one is there. And you'll notice we have a lapsed a few other bits of information that will go through and the selector itself. And the lapsed is with a strange unit, which is a microsecond. So I think that should be the first thing if you are worried about select performance, the fact that they're measured in microseconds and it's 1000 microseconds is one millisecond. So the fact that it's measured in microseconds, I think right away is your first clue to like, okay, they're going to be pretty fast, right. And you can see here, I had 891 elements that had the next class on there. And it took 623 microseconds. So just over half a millisecond to be able to parse through all of those. And then if we scroll down, let's go find my next one. And you'll see there's other stuff in here, you'll find the user agent styles in here for some of these things. As soon as I have an SVG, there's a few extra things that pop up and I had SVGs in here. So there's a few things that might look a little weird, don't worry, you just look for your own. For example, I didn't have a div selector, but there we go, we have 9,000 divs and there's elements on there that aren't divs. So it gives you an idea of how many elements we're dealing with. But let's keep on going. There's my two area labels here at the bottom. And you'll notice 700 and 800 microseconds. And the reason I even wanted to try those two is because, well, first, these are slower than class selectors, right? Yes, it was. And you can see that in this case, it's 700 instead of 640. So we're like 100 microseconds. So 0.1 milliseconds slower. And then if we had one of these more arbitrary ones, it's a little bit slower than that just because it has to do a little bit more work to figure them out. Now, one thing I did find out over time, and I won't recreate it now, but in this case, I have an area label of next and an area label of previous as two different elements. If the only elements on my page were area labels of next, this was actually faster than the class selector. But because I had the next and the previous, so it has to do more match attempts, because basically it's going to look for anything with an area label and then make sure that the next is actually the right thing. So because it has to run through that process, it slowed it down a little bit. So if I had like 15 different area labels, then that could potentially slow it down even more. But again, it's going over 891 total matches over 1,000 things that it has to check in the first place to see if it actually matches. So even if you had 15 different things, but you only had maybe 20 on your page, that also factors into things, right? It's going through a lot of things now, and it's taking a very small amount of time. So by looking at that for me, this is that first thing where I say, okay, that's good. Everything's fine. I don't have anything to worry about. But then I had more of those thoughts that sort of would pop up in my mind about, well, what if we tried this or what if we did that? So let's see what some of the things that can actually get us into trouble or the things that we hear about that could actually get us into trouble that maybe don't always do that. So I'm going to comment these ones out that were in the CSS there. And I have these other ones that I went through. And what I was wanting to do is test the performance if you were doing an is, where or not and like how that impacts things. And actually, let's just do this one first to start with, not those and not using the is just we'll see why I had that in there. But then also here where this is very similar to what we have here, it's not quite the same. This is a comma separated one. And this isn't. But this is a comma separated list, which matches what we have right here. And I want to just, is there a difference between those? So how can we tell what we save this file? And we try this out. The one thing with this that I will also say along the way with this is this is testing it in chromium, different rendering engines are going to do this a little bit differently. But because it's built into chromium now, it's the easiest one to test on. So it doesn't make my life a little bit easier on this. So I'm just saying this might not be universal for all of them, you know, there could be a certain or very specific selector or pattern that is actually slower or faster within other browser engines. So it's just something to keep in mind along the way while you're doing all of this. All right. And with that one done, what we're going to do is let's organize it by slowest to fastest. And look, now we've actually run into some slow ones, which got me excited because originally we didn't really those those class and area ones were pretty fast. Whereas by doing this, I actually like that's, okay, we're getting into some bigger times here. Now, again, look at these match attempts, really, it's trying to match over 24,000 elements. So this is not a realistic real world scenario. Again, I wanted to exaggerate the differences. Most pages won't have 24,000 different things to be trying to match against. So I just want to throw that out there. It's able to fast reject things with the way fast reject can work. So it's following, you know, it's smart the way they've set things up. But you'll notice my is my not and my where are all pretty slow. And if we come down to even this like media group div, all of a sudden it's not having to check is against as many things. It's a lot more optimized and we're running into like, okay, that's not so bad. Still slower than a lot of the other things we are looking at. But there's a lot of potential matches and then match counts. You know, there's a lot of stuff going on there. So it's having to fast reject a bunch of stuff. So it's definitely slowing down. Now, what's interesting with that is the media group a, there's less total match attempts. So it actually was like super fast compared to the div. So just to throw that out there, I did have tons of extra divs and other stuff in here just to like play around with it a little bit to check on speeds. And then I also had this media group a without the direct descendant. And it was also really fast. So that surprised me a little bit. I thought the direct descendant would actually speed things up. But it was actually faster without it. But I guess it's because then it doesn't have to evaluate like it's an a it's in a media group. It's fine. And I guess the browser just didn't have to check if it's the direct descendant or not. You think it was go I don't know, whatever, it was faster, which, which honestly did surprise me, especially because it's the same, I believe, amount of match counts for both of them, which it is. But just something interesting that came up on that one. But yeah, what seems to be going on with these is they're not as optimized because it's actually having to check every single element to see if it matches that, even though it's, it should be eliminating some because selectors are evaluated from right to left. It's I think anyway, maybe the fast reject is fast rejecting anything that's not a media group, but it's still having to like check everything because we have like group selectors here on like the comma separated selector, which actually got broken down into its own things because this media group div was part of a comma separated selector. So I thought that was really interesting that it could handle this and it doesn't break that down. To me, that doesn't mean using these is actually a little bit slower and people are using things. I use them all the time is and where are great and not you see used all the time. I've never heard anyone complaining about performance there, but attribute selectors work out. So just, you know, be careful with where you're worried about on things. Again, you're not normally going to have this many, you're probably not writing into issues. We're still dealing with 15 milliseconds to select all of this. So it's not like, holy moly. But it is a little bit slow. And I have CP through, you know, we have the throttling going on and stuff. So but just to say they're different selectors can have performance issues. And that might not be true forever, because this is clearly something that's not as optimized. The people who make these browsers are really smart. And just like attribute selectors used to be really slow. And there's other stuff along the way that has been in the past as well. This is probably something that one day will get better optimized. But for the moment, is obviously a less optimized thing. And when I saw that being like, hey, wait a second, that's not going so good. And I remember reading about actually, this was in the blog post that Chrome, not Chrome, that edge put out when they made this was the selector that everybody uses. And so let's let's put that right at the top, which is the star selector. And I won't even do it with the pseudo elements, but often we have the pseudo elements that are matched in there as well. But we're going to do the star selector, and then box, yeah, box sizing, order box, because everyone does this, right? That's on like every project, every site that's out there. And then let's do our refresh here. And I'll see once this is done. And with that, we can move this up a little bit. And here's the finished results. When I was happy to see that it was actually faster than these ones here, which were clearly like, not doing super good. But because it's having to look at every element on the page, it's slower than anything else that's here. You know, it's basically unless you're doing complex selectors with is not aware or other stuff. And I'm sure there's other ones I didn't test that are a little bit slower. But, you know, this is probably one of the biggest culprits on every single website is in terms of being the slowest possible selector on there. And then of course, if you add the pseudo elements in there, that's going to add on that as well, because then you have three different slower selectors that are going on. So just to throw that out there is something that every site basically has that is probably not the best. But again, we're, you know, eight milliseconds. It's not the end of the world or across a ton of stuff. And so it is definitely like selector performance is 100% something that is real. Different selectors can influence the performance of your site and how fast the browser does take to render the page because it needs to figure out all those selectors before it gets to anything. But I will say just based on like this going over 24,000 elements, taking 18 milliseconds to be able to do it, you have lots of that going on. And that's including the CPU slowdown. But that's important. We do want to test things on slower devices. But it's just to say that like, do a test on your site, see if there's any red flags or things that pop up or things that seem to be a lot slower than they need to be. And maybe there's a simpler selector that you could use. But if you're trying to optimize for your selectors, there's probably a lot of other things that you could optimize that would make a much bigger difference. Because if you're talking about just fixing this, like, I might save 18 milliseconds off the loading of this page by getting rid of that and just putting in like a div A or whatever. And or maybe I'm having that or whatever it is. So I'm saving, you know, even if it's 10 milliseconds, something like that, you know, come up with a better image optimization, get a little bit better JavaScript on optimization or remove some JavaScript or whatever it is, there's so many different things you could do to optimize your website before you probably need to worry about your CSS selectors. They're I'm almost guaranteeing you that they're not the lowest hanging fruit, but it could be a fun little thing to go in and learn a little bit more and see on your own site if there is something that is, you know, getting in the way or hanging things up or whatever it might be. And speaking of testing things, if you do want to test your site across all the different browser engines, and including getting a WebKit or which would be Safari tested on a Windows device, I have a video that looks at a really easy way to do that. You can see that right here. And with that, I would like to thank my enablers of awesome who are Michael Simon, Tim and Johnny as well as all my other patrons for their monthly support. And of course, until next time, don't forget to make your cornering internet just a little bit more awesome.