Use branches to keep file memory low

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:

  • Don't overstuff components with hidden layers that won't be used. Instead, use placeholders and instance swap properties.
  • Don't let your variant sets get too big. Instead, offload some of those properties into variables (like validation styling and theming), or split it into separate components (like the hierarchy levels of your buttons).
  • Don’t let draft material hang around. Instead, archive it by hard-saving a version to the save history and then delete it.

But did you also know you can use the branch feature to keep file memory down?

Session history and file memory

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:

Four differently styled buttons, named Button Brand-A, Button Brand-B, etc. to the left of the buttons are pages named Avatar, Buttons, cards, Dropdown, and Select.

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:

Similarly styled components from Brand-A, including an Avatar, Card, Button, Select, and Dropdown. To the left the pages have been edited to read Brand-A, Brand-B, etc.=

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.

Recommendation: use branches to keep file memory low

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.

No branches? No problem.

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.

Naming branches

Part of using branches requires naming them. I tend to think of branches in two categories:

  • Branches that will create work for engineers. This could be new components, or edits to existing components.
  • Branches that won’t create work for engineers. Usually this is quality-of-life enhancements for designers. When absolute positioning was released we could stop using the zero frame hack.

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:

  • Button [Brand-A] JIRA-001
  • Card [Brand-B]
  • Select [Brand-A], [Brand-B], [Brand-C] JIRA-002

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).

Scoping branches

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.

<h2 id="change-log">Change log</h2>

  • June 14, 2024
    Katie Cooper and Gleb helped me confirm that version history alone does not contribute to file memory usage. I have edited the section about session history to reflect this, and also added a section about what to do if you don't have access to the branching feature. "Abbreviation" was also misspelled (now correct).
  • June 11, 2024
    First publication