 Okay, I'm gonna go ahead and get started. Can you believe it's 9 a.m. on the second day? First session here. All right, good morning. Good morning, DrupalCon. Welcome to my presentation, audit your theme. Slides are available on the DrupalCon session page. My name is Andrew Olson. I'm a friend and developer from the Chicago suburbs. I work for a company called Bounteous. We have a strong Drupal team, but we do more than Drupal. I've been working with Drupal since 2008, and a fun fact about me is I'm a musician, and I played in a band at La La Plusa a while back. You can, which band? They're called Bank Merrill out of Boston. I was part of the traveling choir. Love to talk more about it. It was a fabulous time. And I had a great time at the Museum of Pop Culture. Those jam rooms, oh, it was great. It was a really fun time. But I'd love to talk more about that, but we're here to talk about how to audit your theme. First, we're gonna discuss how to analyze your theme, and then I'm gonna demonstrate some helpful tools for that analysis, and then I'm gonna provide some refactor pro tips. And finally, we're gonna discuss an approach to measure your theme over time. So why did you decide to attend this session? Perhaps you fall into one of the following buckets. On the screen, you see a bucket full of delicious cherries, and maybe that was the start of your theme, or the start of your platform. And then you got another bucket full of delicious cherries, and then three, and then four, and then finally you have to put them in this really large wheelbarrow. So your theme has grown a little unmanageable over time, and it's a really good time to reassess and audit your site to get some improvements out of it. Perhaps you fall into this bucket. On the screen, there's a bucket full of icy, tasty beverages, and it's great. You've celebrated, but perhaps you had to consume a few too many of these along the way and make compromises, and right after launch, after celebrating all your successes, it might be a really good time while it's still fresh to refactor and take a look at it, and these tools will help out. Perhaps you fall into this bucket. You're stuck with it. On the screen, you'll see a cat in this orange bucket and does not look too happy. So as you get this theme, these tools and running through this analysis will really help you understand what's going on. Perhaps you have one of these buckets. It's a very large project. On the screen, you'll see a waterfall, and there's four kids with water. They're just slinging code, slinging water, back and forth at each other. Might be a good time to kind of just say, hey, slow down, let's see what's going on, get some organization and reusability out of this. Finally, maybe you're here today in this bucket. You're new to theming. So on the screen, you'll see a child in a bucket just having some fun. So this is a good session to just kind of get a good feel for what's going on in your theme. So regardless of which one of these buckets you're in, let's begin. So we're gonna analyze, we're gonna go through some questions to ask yourself and files to look at, and then ultimately audit is going to lead to action. The first file I suggest you look at is your theme.info.yaml file. Right away, it's gonna tell you what type of theme it is. On the screen, you're gonna see on the right, I know it's a little small, but again, I have the slides up. What you see is just an example of a base theme that's using Zerb Foundation. And this is a sub theme based off of that. So right away, what I would do is I would say, oh, if I am not familiar with Zerb Foundation, I would go out to that theme page on Drupal.org and see what versions, see if there's any enhancements or fixes that have been made to it. The other thing I'm gonna see when I'm out there is the theme actively maintained. So right away, just by looking at this, you get a lot of information. Another thing at the bottom, again, a little hard to see, but in this particular case, it's using a component library, which is using Pattern Lab. That tells me that, hey, I might have to hunt and peck for some theme, maybe some twig or some styling in other locations, just by looking at this one file, it tells you an awful lot. The next file I suggest you look at is your theme.libraries.yaml file. It's just gonna tell you how the CSS and JS is being loaded. It'll tell you if maybe you're using a front end framework or there's some additional complexity going on in here. It'll also tell you what external dependencies you have, if it's a CDN or if they're web fonts and they're hosted external. Maybe you wanna pull those into the site and not have that external dependency. The next file is your theme.theme file. When you open that up, again, if you're inheriting a project, you're gonna see all the preprocess hooks and all the template overrides. Just by looking at this, you're gonna just get a good gauge for how complex and different areas of the site that you should kind of keep in mind as you take on this theme. The next is you might have a breakpoints.yaml file and that's gonna tell you what screen sizes you have. If you don't have this or you haven't implemented the responsive images module, it might be a good time to do that. Be friendly to your mobile users and serve up some smaller images. So those are files for Drupal, but let's look at some additional files you might find in your theme. If your site is using automation, you're gonna see probably some files for Gulp, maybe Webpack, Grunt, Yarn. I've used all of these and each time I just hope and pray that there's a really nice readme file so I can get refocused and back into theming whichever one is being used. The other reason is why are we using Webpack? Is there a reason why we chose that over possibly a simpler Gulp implementation? So again, you're just understanding what you have at your fingertips and putting in the back of your mind and taking notes for possible enhancements. Is your site using SAS or less? I'm very partial pun intended to SAS. Or you can also see if your site is using a pattern library. Brian Perry gave a great one, great talk yesterday about internal or external, so you should definitely check that out. But again, by looking in your theme, you're gonna get a good feel for the complexity of what's going on. More questions. You're gonna look into that templates folder and see how many templates you have. How are they organized? So are they all just jammed in one folder like Bartik or are they in multiple directories? Like Umami has a components folder that has blocks, navigation and search, content folder and layout. So just get an understanding of how it's organized or maybe somebody did it and it grew over time and it's not organized and now's a good time to just reassess that. So we've gone through the files, we've gone through the folders and now we have a better understanding of our theme but let's take a big step back. You might wanna just look at the project as a whole. This talk was inspired by a project that was about three to four years old and so when I was looking at this, I wanted to look at recent analytics and see what kind of browser support. Things have changed over the past four years and I wanted to see if the users had come along and what kind of support I had. Was very surprised by the very large increase in the mobile traffic. So right away I'm looking at this through the lens of my users and how to optimize the theme. The other great thing at our agency might be another developer that took that on and I roll in to just make some enhancements as they move on. Is the original developer available for questions? One thing I love to do is ask them to navigate the site after I get a good feel for it and have them navigate the site with specific tasks. They're gonna tell you some great stories, maybe some horror stories, hopefully some success stories about why things were built in a certain way. That might actually be the start of it. Well I would have done it this way. Really the goal is to just find out how it is and why it was built that way and see if there's room for improvements and refactoring as you're going into it. The most important thing is listen, don't lead them. But at the end of that conversation kind of review their findings and tell them like oh maybe this part needed a little bit more documentation or I could not find how this section affected this section. So with all of that, your audit is gonna lead to action. So you have a good feel for what's going on, but the next part of this is I'm gonna show you some helpful tools that are really CSS focused to help you write more efficient themes. And we're gonna go over four tools. First one is called Parker. The next one's Analyze CSS. The third is a fairly new one and I'm pretty excited about called Project Wallace. And the last one is just I wanna cover Lint. So let's start with Parker. Parker's Style Sheet Analysis Tool and it runs metrics on your Style Sheet and it really helps report on the complexity and it gives you numbers that can tell you kind of how complex it is and what's going on. So how does it work? You go to GitHub and you can clone the repository. You install it locally with NPM. And again the slides are up, you can click on these links and highly encourage you to give it a try. You can measure local CSS files or remote CSS files. And the awesome, awesome thing about it is it outputs JSON. So let's take a look at the Parker JSON output. By running it, I'm gonna run it on a local CSS file. That's from a D8 project. And it's a sub theme of the Zerb Foundation theme. And just to let you know that sub theme uses a lot of the Zerb files. Just to let you know that sub theme uses a lot of the Zerb Foundation framework. So we're pretty much taking Zerb Foundation wholesale. So this is what it looks like. For the project, we used Grunt and we grunted all the theme into one CSS file. And that tells us the size of the CSS file, 192K. And then next up it tells us like rules, selectors, declarations. I'm looking out. Does everybody remember what all those are? I didn't either. So let's have a little CSS 101. Everything in the green on the screen is a CSS rule. H1 is a selector. Color is your property and the hex color is your value. So let's take that little cheat sheet, move it up into the right and let's look at these numbers again. So we have that many rules, that many selectors and declarations. Again, it's just numbers that are just kind of telling you right away what's going on by just running this quick command against your theme CSS. Pretty cool, but what are identifiers? So identifiers are not IDs. These are the measure of the parts per selector. If you look on the right hand side of the screen, an example is just one class is considered one identifier. All the way down to the bottom, you can see five identifiers. So now that you know what identifiers are, let's go back and look at that number. So really what do these values mean? Are they too high? Are they too low? Are they just right? So your mileage may vary from theme to theme. I encourage you to run this on a few projects to get a good feel for these initial numbers. But the next part of the JSON is pretty exciting. We're gonna go through it. It's really gonna help you provide insight into what's going on with how you're styling your theme. A great one is the selectors per rule. Again, keeping that cheat sheet in the top right. You want that rule to be as close to one as possible. If you have a lot of selectors per rule, it's suggesting that we're applying the same styles to a number of different selectors. If that's the case, then perhaps we could create one class to catch all the styles in this. Let's look at an example of that, of how to reduce the number of selectors per rule. So on the left, you see the styling for input boxes and a text area, basic styling, right? This is a great opportunity to write just one CSS class to reduce the number of selectors. So now, if we write this as like C for component, input text, and put all the styling in there, now we don't have to just keep adding the markup styling to it. We just add a CSS class to all the form elements right from the start. So it's a great way to reduce that kind of complexity. And if it needs a change, if design says, oh, it needs to be a thicker border or the select state needs to be different, we just do it here. So next, your identifiers per selector should be between one and two. Anything that's higher than two means that we're being too specific with that CSS rule. I'm pretty guilty of that. And we're really limiting the ability to reuse our styles. We're not writing a class-based theme. So that's why you wanna get that number between one and two, to have really class-based reusable styles and patterns. The next exciting thing is the specificity per selector. I stayed up late and just said in the mirror, specificity, so I could do this at 9 a.m. But let's look at it and see if I can keep it going with saying specificity. So what is it? Let's take a look. I know I needed a refresher as I was looking at these numbers. So you can generally read specificity values as if they were just a number. The higher the number, the more specific the rule, and the more likely it's gonna win in the style wars. That sounds really funny. So clearly a 1,000 is gonna win over a 100 style. So if you look on the screen, I have just the zeros, but on the left is an inline style. That's gonna always win over an ID. IDs are always gonna win over a class, and a class is gonna win over elements. Let's look at a few examples just to put it together. So this LI has an inline style, and it's gonna be specificity of a thousand, so I know that's gonna win. Bad idea, theming, right? We can do better. Here, the value is 113, so because we have one ID, one class, and three elements. Just one quick reminder for specificity, this isn't a true base 10 numbering system, so I could have like 0, 1, 5, 13, if it's pretty crazy, but generally this is a good rule of thumb for determining what CSS style is gonna win. At the end of the slides, I have a great CSS tricks article that I use and put these together from to help remind you of specificity, because I don't know about you, two sessions, it's gonna go away, and I'm gonna need that resource when I come back. Last things, universal selector is zeros and important is an automatic win. It's like putting it in the millionth placement. And importance win through the cascade of your style sheets. So if you had an important at the beginning and one at the end, the cascade, the one at the end is always gonna win. So speaking of importance, that's what Parker tells you. We're gonna get a little bit more to that later, but it counts the number of importance as well. So now that we know more about specificity, let's go back to these numbers. So if we look at specificity per selector, and we know that class based is like a 10, it looks like when I run this against the theme, it's a 25. So I wanna get that as close to 10 as possible. Your mileage may vary. You might have a certain section of the page that you kind of need to what I always call quarantine your styles and make it really specific so things don't bleed out of it. Like navigation, ULLI lists and navigation need to be pretty specific. So this rule is, again, just kind of a guide post. If it's super high, you know, or you run it on three different projects, hopefully these numbers start making sense. But the whole goal of this is these numbers are gonna help you understand what's going on and write a better class based flatter theme that's gonna be more reusable and shared. Another thing, the total ID selectors. Ideally is zero, again, not always the case, but as we all know, you can only use one ID per page. So again, it's not very reusable. If I use an ID on a button and there's four buttons on the page, that's not valid. So again, it's a good indicator of how many IDs you have specified. More things, Parker tells you, again, as I said, the counts up all your important keywords. What I really love about it, too, is it tells you all the total media queries and spits them out on the page for you. Again, using Zerb Foundation in this site might use a couple other, a couple other, it's using some other CSS. It's gonna grab all of those and just put them in there because I compile everything into one file. The other great thing is it covers, it counts up all your colors and spits them out as hex values. So you can go back to the design team and really dial in those four different shades of red, right? And just write one variable and get it dialed in. Pros of Parker, it helps you measure the file size. And again, when you output at JSON, we're gonna talk about this a little bit later, is it allows you to measure that over time. So it takes a cut of the size of your file at that time. It gives you metrics for that class-based theming. It allows you to find all those color values and media queries and all those importance to investigate deeper. Cons, I'll skip the first one, but it's last updated 2016. And I thought, boy, that's a little old. Is there something a little bit newer? And that led me to analyze CSS. Very similar tool. So moving on from Parker, let's talk a little bit about CSS. It does a lot of the same thing, test, weigh, and analyze your CSS to reduce that complexity that you have. Very similar to Parker. You go to GitHub, install with NPM, again, measure local CSS files, or you can point it to remote CSS files and output in tasty, tasty JSON. It tells you a few other things, but it covers a lot of it. There's great documentation on the site about these values, but it just gives you a little bit more. The thing that I like about analyze CSS is it gives you the offenders list, so it tells you the most specific value in your CSS. So then you can investigate and say, oh, this is the Instagram post that I'm getting from another third party, and I really wanna make sure all the styling inside of there is kinda quarantined to that part of the page. So the pros of it, it has additional metrics compared to Parker. I love the offenders list, and it's updated and maintained. I'm gonna move on to the third tool. Again, these 30-minute sessions go kinda fast. Go to the slides, but I wanna talk about Project Wallace. It's a style sheet analysis tool that keeps track of metrics over time. Really excited, Brian Perry sent me this at the first part of the year, and it kinda put a lot of this together. It's by a gentleman named Bart Veneman, and he's from the Netherlands. And what this does is it's an online site, and it gives you an online dashboard. The talks that I've given this talk a few times, and because it presents JSON, you can do a lot with it. What he's done is he's written this and has a website that does a lot of the same things, and he's just taking that JSON, tracking it over time, and putting it in a nice graphical form. It's really, really pretty cool. So you can go to the website. There's two different options. First is go to the website, you can create an account. Again, you give it your project, and it can create some nice graphical dashboards, and then keep visiting the site, keep giving it the cuts of the site that you want, and it helps you track it over time. He's also on the Twitters there as well, and keeps it updated and maintained. There's three ways on the site, is you analyze it by grabbing the CSS from a single webpage, so you can just put a hyperlink to that CSS file for your project. You can copy and paste raw CSS, so if you wanted to break a certain part of your theme away, if I didn't want to count all of Zerb Foundations and just look at mine over time, you could just cut that in there. And the other really cool thing, I haven't tried it out, but you can use a webhook and you make it part of your continuous integration. So all the details are up on the site, but it also has a command line interface, pretty much exactly like Parker and analyze CSS. Same thing, you just need node, install local, point at local, or remote CSS files and outputs JSON. Pros, it's got improved output. He's doing a lot of the right things, and he's also tracking it over time. He's not just saying, here's this tool, go for it. He's taking the concept of what I'm gonna get into here next is tracking over time and really understanding how you're improving over time. The cons, it's a really hard con. It's free for only one project and there's a cost to it, but again, he's giving a lot of features and benefits. So it's a very reluctant con because I think the pricing's pretty good for what you can get and what you can share with your teams. Quickly, going over lint. Linting is a process of running a program that's gonna analyze your code for potential errors. You're gonna wanna lint your JavaScript and CSS and install this as part of your automation. I can't stress enough, it catches mistakes, it saves your bacon and makes you write better code. It doesn't help you write better code, it makes you write better code. So if you set it up right, you just can't run and output your CSS without fixing the mistakes and adhering to the rules that you set up in the project. So linting is great. I'm gonna go over some refactor pro tips. Again, audit leads to action. So by putting it into action, we've looked at all this, we've seen the CSS. Ideally, if it's not there already, we're gonna look and want to apply some possible atomic design principles. Maybe there was a component written and then it was just copy and pasted three times and now's the time to abstract that up and write a nice abstract class-based reusable part of the theme. Last mac structure. If it was all just piled into one CSS file, you're gonna want to, you might wanna just start breaking that out into partials. Another good opportunity to maybe start rewriting slowly those partials into BEM. Again, links at the end about all these concepts. SAS, these tools are outstanding to help you start writing variables for those breakpoints that we saw, for the colors that we saw, maybe for some fonts. Now that you've kind of rolled around in your CSS, it's a good time to see if there's mix-ins or functions you can write to, like for all the buttons, so you don't have like 50 different buttons. You can write a nice mix-in and send it your button variants in one place. JavaScript. Always, always use Drupal behaviors and include JavaScript as libraries. Yay, D8. Only include JavaScript when you need it. And as you're picking up a theme, if it's not written that way, now's a really good time to make it more better trademark. Okay, ultimately, we want to establish the metrics within our theme and we're gonna measure this over time and these tools do a great job with that. So what I'm proposing is inside of your theme folder, you make a metrics folder. And what you do is you use one of these tools, output that JSON and put it right in that metrics folder. So right away, you leave here, you make a cut of a baseline of where your theme is at, it'll measure your size, it'll measure your specificity, it'll do all of that. And then sprint by sprint, if you can put these tools as part of your automation, sprint by sprint, you can measure this the size of your CSS over time. So when the phone call rings, when the phone rings and the call says, hey, the website's slow, you can go back through and see what was the spike? Was it integrating this part of the CSS? So how did it bloat over time? Otherwise, you just say, I don't know, I think it was fine, you know. So you can capture a lot of these things. Other ideas, since it can be anything, you can put alley scores in here or just any other metrics that you wish. Lighthouse has a good export of that cut of your site at that time sprint by sprint. And then you can do cool things like maybe diff your JSON. And if you don't know, so measuring tells us where we've been and gives us clues on how to improve. Thanks. Questions?