Table of Contents
If there is one thing that scares many people in web development, it is refactoring CSS. CSS on its own is already hard to master. It gets even harder when you have to clean the mess after someone else. Luckily, you found this post. On the following lines you will find couple best tips and practices to make the whole process of refactoring CSS much easier and more enjoyable. Remember, it refactoring CSS doesn’t have to be a pain in the butt. All you need is to follow couple smart strategies I will share with you today. Without further ado, let’s start.
Prepare Yourself Mentally
The first and foremost step before getting into refactoring CSS is to prepare yourself mentally. Seriously, this is not a joke. If you are about to do your first refactoring, this step has even more weight. There are two main reasons why mental preparation should be the initial step in the process. First, the majority of projects you will work on will be probably bigger sites. Let’s face it … Landing pages or one-page website are not the types of projects clients will approach you with. These websites often contain only few dozens or hundreds of lines of CSS and their service life is quite short. In other words, refactoring CSS in case of these websites is not interesting for their owners.
Bigger websites are a different story. These projects often has to exist in terms of years, not just weeks or months. What’s more, during the time, they are edited and modified by wide range of people. Meaning, in most cases, there will be a lot of garbage created and collected. This will result in thousands of lines of code and a lot of time spent in front of computer. If you are not mentally prepared on this fact, it can easily overwhelm you. Let me give you an example. This will is from a client project I am working on at this moment.
The website of my client has been around for more about six years. During this time, it changed the clothes couple times. Unfortunately, all these changes were incremental. Meaning, when client wanted to improve something, he would hire a developer to either modify already existing code or add something new. As you can guess, the CSS slowly grew in size while performance went down. At the time when I was hired for refactoring CSS, the main stylesheet contained more than 4.500 lines f code. By the way, there were 8 (!) another stylesheets. The total number of lines? I don’t even want to think about that number. It already cost me couple dreamless nights (just kidding, maybe).
Fortunately, thanks to experiences gained on previous projects, I was prepared for situation that was even worse than this one. Sure, I was scared by the amount of hours it will take. However, I also knew that I can slay this monster (get it done). I have to admit that it was only thanks to this self-confidence and determination that I successfully finished this project. Without this mental preparation, it is quite possible I would withdraw from the project and refactoring CSS.
Takeaway: Refactoring CSS can be a very though job. Your mindset and belief in your ability to get the job done will become make-it or break-it factor. When monetary rewards will cease to work, this will keep you working. Remember, even champions have to prepare themselves mentally.
Start with an Audit
If there is one thing that’s harder than refactoring CSS it is proving its value and results to your client. Here is the thing. The majority of clients you will work with will either not be interested in the technical “stuff” or will lack any knowledge about it. Or both. For this reason, it will be quite helpful for you to create some documentation of the original state of the CSS, website and its performance. In other words, you should use tools such as PageSpeed Insights, CSS Dig, Pingdom and others to thoroughly analyze client’s CSS files. This should be inseparable part of your workflow when it comes to refactoring CSS.
All of these tools are very easy to use or require only few minutes spend reading the documentation. Most of them are also for free or at least offer a trial package so you can still try it without paying a dime. PageSpeed Insights and CSS Dig as well are available as browser extensions. Rejecting these tools you are doing only disservice to yourself and your work harder than it necessarily has to be. Remember that all these tools will provide you with better and deeper insights you can then use to do a better work. The better service and more value will you deliver to your client, the more likely he (or she) will work with you again and also recommend you.
Forget Ideal Conditions
One thing I would also suggest that you do is, when you will do the analysis we discussed above before refactoring CSS, to create snapshots and analysis for different devices and network conditions. Fortunately, the majority of modern browsers come with some kinds of web development tools, or inspector, included as default. As part of these tools, there is often an option to simulate network throttling. For those of you not familiar with this term, network throttling simply means simulating specific connection speed. For example, you can simulate how long the website will load on GPRS, 2G, 3G, 4G networks and so on.
Testing the website on high-tech device connected to a high-speed broadband is comfortable. I get it. However, there is a problem with this approach. Taking into account the number of people visiting your client’s website on a daily basis, how many of them will work in such conditions? How many of them will wait with visiting that website until they will get home to fire up their high-end computer (if you sense sarcasm, you are right)? Probably not so many. The majority of current users, and potential as well, will use whatever device available. This will often mean smartphone with connection of varying quality.
Let me illustrate this on an example that happened just a month ago. Back then, I was working with another company (I still am) on new design for their website. To give you a better idea without breaking the NDA … It was a complex dashboard for creating, saving and showing various statistical data. Anyway, to cut the long story short, the design was found friendly and website worked well … On desktop devices and mobile phones. The last step to make the testing phase complete was to try it on tablet – something in between the two.
Do a Reality Check
Fortunately, there was one guy on the team (working for that company) who had an iPad. It was, I guess, iPad 2 … The most affordable version. To say that website worked well would be an exaggeration. Loading speed was low and overall manipulation was quite painful. One of the reasons was a huge amount of scripts used for enhancing various elements running on the background. Now, you may argue that these scripts should slow the website on the mobile as well. Not exactly. The team and I built the majority of scripts in such a way that scripts not necessary for core functionality were set to be running only under specific conditions.
Some of the conditions included device screen width and support of touch events. With this set up we were able to turn off the most resources-demanding scripts and so increase the performance of the website on mobile phones. However, this was not true for almost anything between desktop and tablet. The problem is, where you should set the limits of what is resolution for tablet and for desktop. For example, there are already tablets bigger than small-size laptops. On the other hand, there are laptops you almost want to doubt that it is still a laptop. For this reason, the performance on mid-sized screens were worse than on small-sized.
Anyway, the takeaway I want you to get from this example is this. You cannot predict what device will people use. So, although it can be a pain in the ass to test your project on the low-end devices, it will be a reality check of how will your project work in the real world. So, remember to always do audits on devices across the performance scale. Don’t focus only on one end of the curve.
Takeaway: Before starting with refactoring CSS, make sure to run a complete audit of the project. Measure and log everything under different conditions and scenarios. Don’t stop with ideal conditions. More often than not, they will not be met on the side of users.
Prepare the Ground
Let’s suppose that the metal part is in check and your audit as well. What’s the next thing on the list to get done? Now, it’s time to prepare the ground for your work. This will include things such as creating backups and schedule and also making the whole project more workable. Let’s start with the first step of this phase which are backups.
Backup Everything
Right after you are done with audit, you should backup all files you will be working with. This is not because something may go wrong and you might need to use this backup. Sure, this is a great reason to keep everything backed as well. However, at this moment, the main intention is elsewhere. Speaking frankly, you should keep these backups to enable yourself to show your client direct comparison between the before and after states. With this, your work and proving its benefits and results will get much smoother and easier.
Sure, you can rely on your client’s ability to spot differences in loading speed. However, for the majority of your clients spotting improvements in terms of milliseconds and kilobytes will not be the best way to prove that refactoring CSS delivered some tangible results. On the other hand, the situation will be completely different if you will be able to show the before and after version of the website simultaneously. Your words will always have more weight and credibility when you will be able to support them with split-screen presentation.
Let’s also not forget that the more you are charging for your services, the better results you have to deliver. By this, I don’t want to suggest that you lower your rates. Not at all. You should charge accordingly to your skills and expertise. If you are an expert, your rates should mirror it. Otherwise, you will risk losing credibility. Just think about it. Would you trust someone offering you an iPhone 6 for $99? Probably not. The same thing applies to your rates as well.
So, don’t be afraid to charge more, but also make sure you have enough data to support the results of your work. Otherwise, your client may not trust you and even decline to pay you full price. One way to avoid this situation is to create a backups of the original files and save them on a safe place. Then, after refactoring CSS, you should go back to these files and make a comparison. This will suppress every possible argument your client might come up with.
Create a Schedule
The second part of the phase two – preparing the ground – is about creating a schedule for the whole project. Refactoring CSS will take a lot of time and trying to tackle it without any schedule is just insane. Also, don’t forget that your client will want to know how much time you will need to finish the work as well. So, like it or not, you will have to come up with less or more detailed schedule anyway. Creating a schedule will also help you organize and prepare your work. I already mentioned this earlier and we will discuss it in the next segment, but you should never approach refactoring CSS as a one big task. Doing that will only increase the chance of being paralyzed.
Regardless of your opinion or preferences when it comes to planning and scheduling your work there are some tools I would recommend that you at least take a look at. The most advanced and also complex are Kanban Tool, targetprocess, Redmine and Trello. Both of these tools are based on Kanban method. If you are not familiar with this type of tools, their complexity might scare you a bit on the first sight. However, it is this complexity that allows you to separate your project into smaller detailed tasks. Who knows, maybe you will find these tools comfortable working with.
On the other hand, what if you are more like me – a minimalist always choosing simplicity over complexity? Then, you can try tools such as Asana, Freedcamp, Basecamp or even Evernote. Or, if you want to take it one step further, you can try some of to-do list apps. The best known are Microsoft To-Do, Any.do or Todoist. Any of these apps will do the work and they all are also available for all platforms – desktop, web, iOS and Android. The last category of tools with different approach are mind mapping tools. Few examples are MindMeister, iMindMap, Freemind, Mindjet, XMind and Coggle. Except Coggle and MindMeister (webapps), all these tools are available to download.
My advice is to give it a shot and try all of these tools. Only then you will be able to find the tool you will feel most comfortable working with. Since you will use it on a daily basis, you shouldn’t settle for anything less than pleasant experience. Remember, your work will be already hard enough. So, why making it even harder?
Divide and Conquer
Have you ever played any strategy game against two or more opponents? Then, you probably know how hard it is to beat them all at the same time. Unless your opponents, human or artificial, are complete beginners or losers, you will have to go through couple of hard moments in order to win. Having said that, there is one specific strategy you can use to make this feat easier and your victory more probable. The strategy I’m referring to is something that used even one of the greatest war leaders Gaius Julius Caesar to expand the Roman Empire. In the words of Niccolò Machiavelli, and language spoken back then, you might know it as: “Divide et impera.” Translated into English, it means: “Divide and conquer.”
Thanks for this brief lesson from history Alex, but how exactly should this help me with refactoring CSS? What does your client’s CSS and Roman Empire have (or might have) in common is that both of these things are quite large to handle. At least in one piece. However, the whole situation will take completely different course if you will divide the problem into smaller pieces. Let’s take a look at how to apply this theory on refactoring CSS. First, forget about taking the whole stylesheet, or all of them (if there is more than one stylesheet), at once while trying to keep a sense of it.
What you should do instead is to go through the file and divide that monster into separate parts. Depending on the current project, you can divide the styles according to individual pages or modules, if you are lucky. Next step depends on your skills. First, you can use Sass, save all the modules into separate files and then connect them together through one main file and import directive. This is my favorite approach. If you don’t know sass, you can either learn it in fifteen minutes here or try the second approach. Let’s say you are not interested in sass. Then, you can simply import all the module stylesheets into one using import rule. Honestly, I wouldn’t do that. Or, you can link those stylesheets individually into HTML files.
Unfortunately, if you are working on something bigger than one-page website or landing page, this will make refactoring CSS literally hell. Seriously, you should learn sass. Anyway, when you complete this step the fun is just about to start. Now, you can finally start with the main phase of refactoring CSS. Just remember to always tackle only one module or module at the time, no more. Otherwise, you might get lost in it very fast and easily become anxious about your ability to get this work done.
Takeaway: The best way to start refactoring CSS process is by backing up everything so you can later use it to prove the results of your work. Next, you should create a schedule. Following this step, never try to tackle the whole project at one “sitting”.
Rest and Recharge
The last piece of advice I will share with you is to make sure to schedule regular breaks to rest and recharge your energy. Contrary to many popular beliefs, working long hours until you will literally dropout will not help you do a better work. Working to exhaustion will help you achieve only that … Exhaustion. If you don’t believe me, use search on the Internet. There is growing number of science-based studies showing that working longer hours will not make you more productive. In a fact, very often the outcomes will be opposite.
You will be less productive. Due to exhaustion of your organism your brain and body will not be able to perform as it possibly could. What’s more, the longer you will keep that insane, say 80-hour week, regime without recharge periods the bigger harm it will do to your health. If your plan is to be in business for a longer time and live long enough without surviving on dozens of pills, start implementing breaks into your daily working schedule as soon as possible. Paradoxically, this step might even increase your productivity.
My favorite productivity tool or method is pomodoro. The simplest description of this method is that you are working in a specific time windows followed by regular breaks. For example, the “default” setting of this method is to work for 25 minutes without interruption and then take a break for 5 minutes. After four sessions (4 work segments and 4 breaks) you take a longer break, mostly 15 minutes. You can find more information about pomodoro method here. Let me tell you that my productivity, and joy of work as well, increased significantly since I implemented this method into my workflow. I’m also less tired.
Takeaway: Don’t use your work as a way to slowly kill yourself. Take care about your health and schedule regular breaks to recharge your energy. This will help you deliver the best work in the long-term as well as enjoy the work on its own.
Closing Thoughts on Refactoring CSS
That’s it for the advices related to refactoring CSS. For those of you looking for showcases and examples of practical approach – seeing my refactoring process in action – don’t worry. I will dedicate one of the future posts, either on Monday or Friday, especially to that. Until then, use the advices given at this post to make at least part of your refactoring process more enjoyable. Thank you for your time. One more thing … If you found this post interesting, please share it.
If you liked this article, please subscribe so you don't miss any future post.
If you'd like to support me and this blog, you can become a patron, or you can buy me a coffee 🙂
Become a Patron
