I think a healthy memory usage amount for a component library is something under ~12%. Your mileage may vary of course. The scope of the library (icon library VS UI components), the kind of product it supports (basic content containers for a marketing landing page VS complex data table and dashboard components for a SaaS product).
But no matter the scope or purpose of our libraries, you probably agree that of all our figma files, it is especially important to keep libraries lightweight and snappy.
You’re likely already familiar with all of the obvious stuff you need to do to achieve this:
But did you also know you can use the branch feature to keep file memory down?
Every time you open Figma you start a session. During a session all of your clicks and actions are kept on record. That record of actions is what make undoing and redoing possible. The things that Figma records get pretty granular: not only are changes to object’s attributes recorded, but so are selections you make on the canvas. This is a lot of information to keep track of!
Originally I thought that a long running version history also contributed to file memory consumption. Luckily Katie Cooper and Gleb helped confirm that this isn't the case—great news! This means having a file that gets maintained over years and years should be possible without memory issues. But the reason I thought that wasn't the case is because of a situation Katie tweeted about:
She had a file get too big, despite having very little material in it. She ended up cutting and pasting into a new file. The memory usage in the new file was much lower than the old one:
I had assumed that it was something about the age of the file and a long running version history. It had nothing to do with version history and everything to do with session history. She had multiple people in that file with her, all of them accumulating a long series of undo-able actions. That's likely what blew up the memory usage.
Later on I found myself experiencing something very similar!
I had a library organized so each component had its own page. Because it was a multi brand library, there would be 1 of each component per brand. Keep in mind that this was pre-variables, so using separate components made the most sense at the time:
Later on my engineer and I eventually decided it would be better to map Pages in Figma to each brand (rather than component). Basically inverting the organizational schema:
When I went to move the components around, I immediately opened a branch. Our policy has always been to open a branch when making any kind of edits.
If you’re thinking, “Alice, you aren’t reeeeally editing the components, you’re just moving them around”—remember reader, changing the page name counts as an edit! This will make all the components show up as “modified” in the publication panel. This is related to why I have beef with people using status emojis in Page names. I wrote all about that in this other blog post.
Okay back to my re-organizing story. So I open a branch, make and name the new pages (Brand-A, Brand-B, etc), and start cutting components off of the old pages and pasting them into the new ones. No big deal.
Until my memory skyrockets from 9% to 61%:
I opened up the memory usage panel and revealed the memory-per-page. Each page’s memory was pretty low—something like 8%—but the total memory for the file was 61%.
The math wasn’t mathing.
I decided to close down the entire application (which would end the session I had started) and then re-open both the main branch and side branch. After booting everything back up and entering a fresh session, I opened the memory usage panel straight away.
The total memory was now 6%.
I hadn’t deleted anything. All I did was cut and paste a bunch of components around. And then close the session and start a new one.
Branches act like their own separate Figma files. Think about it: when you open a branch, an entirely new tab opens. And this connected, but separate branch file, the session data is separated. Your undos are all safely partitioned away from the main branch.
When you merge a branch back to the main file, the session ends. The only thing added to the main file’s history is a record of your merge.
But I want to make a caveat: this is best done in files that have a long shelf life. Things like libraries, or local files you’ll keep around for more than a couple of months. If you have a short-lived file, you likely won’t run into memory issues. Still, it could be good practice.
For those of you who aren't on Figma plans that allow branching, I suggest closing down the file at the end of each day. And if you're really designing up a storm for a full day, consider closing the file when you break for lunch. Take small bites when it comes to making edits. This is even more important if you have other editors in the file like Katie! Build a habit with your team to end sessions frequently.
Part of using branches requires naming them. I tend to think of branches in two categories:
These categories affect how I name the branch. If there’s work for engineers, I always make sure to include the Jira project abbreviation and issue number of the ticket the engineer will be assigned in the branch name. We don’t use Jira to track design-only edits, so in those cases I don’t have a Jira ticket to reference in the branch name.
But in both cases I always include the name of the component I’m working on in the branch name. Here’s a few examples:
When I’m not working on components, but instead working with variable collections, I’ll try name the variable collections I’m editing.
The purpose of this naming is to make it clear to any designers who open the file that work is being done (one or more branches are open), and what is being worked on (included in the branch name).
It’s sort of implied in the naming, but I try to keep the scope of work in each branch as small as I can. I don’t like to leave a branch open for more than a day or two. While I haven’t experienced it first hand, I’ve seen lots of reports from others having issues merging branches because the amount of changes were just too big for Figma to handle without crashing.
And believe it or not, this also has to do with memory usage! It appears that when you merge a side branch back into the main one, there is a big spike in memory usage. Perhaps something to do with difference-checking and reconciling? An engineer would know better than me. But the fact of the matter is the more editing you do in your branch, the more information needs to be reconciled when merging, and the greater your risk of a memory crash during a merge.
Keeping things scoped to a single component has helped me avoid these problems entirely. There’s no limit to the number of branches you can open and merge, so you may as well take frequent small bites.
If you'd like to be notified of when I publish a new blog post, joining my newsletter is a great way to keep up. My readers enjoy bonus behind-the-scenes insights on every post!
