This pain point almost needs no introduction. Hundreds, if not thousands of designers have faced the horror that is Figma’s memory usage warning banner:
Unfortunately people who are faced with a resource-strained file get the same flavor of dismissive, vague advice that gets doled out to folks who are struggling auto layout. The difference here is someone’s hard work is at risk of being lost. But it seems to rhyme:
“how do I reduce memory in my file!?”
“just get rid of your hidden layers”
“how do I learn auto layout!?”
The person in need of help has likely already tried these things! But they’re not seeing results.
And I’ll be honest, before I took the time to really understand this problem, that less-than-helpful one-liner, “just get rid of your hidden layers”, was the best I could offer too! Figma’s own documentation doesn’t go any further either.
So what’s better than a “heard that before”, crumb-size piece of advice that you already tried?
But not just “step 1, select hidden layers ... step 2, delete them” I’m talking about strategic instructions. Instructions that were designed to get you results as fast as possible.
In this blog post we’re not only going to rescue your memory bloated file from the depths of hell, we’re going to do it in record time. 🏎️ This entire blog post is designed to take you through the highest impact actions first. What this will do is win you back file memory in big chunks at first, getting you back to safety as fast as possible. This means memory usage reduction should get easier with each Milestone you complete.
Okay! Are you ready to get your file back? 🔥 Let’s roll 😎
If we want to knock this out fast it’s vital we tackle this problem strategically. We need to start wherever the highest concentration of memory usage is happening in your file.
Typically folks will use multiple pages to organize their work. To find out which page has the most information on it, keep reading. If you’re only using a single page in your file you can skip ahead and begin on step 4 of Phase 1 below.
At this point you could get really fancy with this and make a whole spreadsheet, but it’s not necessary. We’re on a rescue mission after all! This detective work helps us understand where our time and energy is best spent first. We want to win back memory from the biggest, gnarliest parts first so we can get as far away from the danger-zone and back to safety as fast as possible.
Take a look at your notes. Whichever page has the most layers that allows you to navigate to it without crashing the file is where you should navigate to in Figma. This page is where the next milestone kicks off.
Okay, so your detective notes from Milestone 1 led you to the biggest page in your file. Let’s dive in.
You probably thought we were going to start with hidden layers. That’s fair. It’s the one-liner piece of advice folks throw out to those of us trying to revive a file that’s choking on its layers. But I want to be clear: there’s nothing special about hidden layers that make them use more memory than visible layers. If you duplicate a layer and hide it, they both should cost the same amount of memory.
The reason people suggest you start with hidden layers because visible layers are probably visible for a reason! You’re using them!
But what about all those old drafts and iterations? The inspiration you swiped from other files? The beautiful clutter! The stuff that shows you’ve spent time experimenting and trying things. This material usually floats around or beside actual mockups and prototyping screens.
If this stuff is present on the page you’re looking at in Figma, the only step here is to:
If you don’t have draft material or removed some and are still not back to a safe amount of memory usage, don’t panic! There’s still work to be done here. Next we move on to hidden layers:
The first place to look is hidden layers is in non-instances, or “regular frames.” Now, in the last phase I had that whole preamble about hidden layers not being any more expensive than visible layers, but I do have a strong hunch that non-componentized hidden layers are the more expensive than componentized hidden layers. I’ve asked for someone to validate or correct this theory in the community forum, but until I get a reply, let’s assume I’m right (if I’m wrong that’s okay, it wouldn’t affect this guide).
This means the most valuable hidden layers to start with are the ones in regular, non-instance frames.
But the tricky thing with hidden layers is... they’re hidden! We have to find them before we can remove them. Here are the steps:
In cases where taking a screenshot in step 2 wasn’t appropriate, you should re-run the Find hidden layers plugin any time you need a reminder of where the hidden layers are.
⚠️ Important note! Repeat phase 1 and phase 2 of this milestone for every page of your file before proceeding to phase 3 below.
Now we’ll be examining the hidden layers in your main components. Unless you’re the author and sole-consumer of any library components you’re using, it’s best to begin with local components that are under your jurisdiction: the ones ones you’ve created for yourself in your local file.
Here’s how to proceed:
⚠️ Important note: Repeat this process with each local main component across your entire file.
After cleaning up your local components, you may find yourself raring to do the same in your component library. If it’s fast and easy for you to run through that file and make this kind of enhancement, more power to you! But if you need permission from teammates to edit and publish from the library, then the process might take too long. In those situations, I suggest moving on to the next milestone.
Good news, if you made progress in the last phase of Milestone 2, Phase 2, then you’ve technically already made some progress here! That doesn’t mean we’re done though. It can be taken even further.
Much like hidden layers, Figma renders each variant in the background when instances of that component are placed. This is what allows for instantaneous swapping using properties in the design panel.
My rule of thumb is that if you have a variant set with over 50 variants, it's worth taking a critical eye to it. Here’s the most efficient order to do this in:
Are you using ⍚ base components? If so, these tend to be a big clue for components that can be enhanced with this feature. Often nested ⍚ base component’s properties will be repeated downstream in the main components they support. But by using the expose nested instances feature, we no longer have to manually re-make those properties! Here’s how to execute this:
Repeat this process for each property on each component using ⍚ bases.
This post is already long enough that I won’t get into the specifics of what content carriers are, but here’s a quick summary: I believe there’s 7 unique types of components out there that many designers use (or should be using). The problem is they just don’t have widely known names, or have been nameless! And it's hard, if not impossible, to leverage a technique if you don't know what to call it. We do have names for a couple, like “bases” and “slots.” But the other 5 have yet to be adopted by the wider design community. ✎ Content carriers is one of them.
Okay. What the heck is a “faux-repeater property”? It’s where you use variants or boolean component properties to mimic repeater functionality. Here’s an example that appears to be using variants to offer 5 rows and 3 columns in a table component:
What folks are missing in Figma that tools like Adobe XD and Axure have is what’s known as a “repeater.” Repeaters allows you componentize a limitless list of objects. Here’s what it looks like in Adobe XD:
While we can mimic repeaters in Figma using variants or component properties, it requires tons of extra layers.
I believe the better solution is to allow designers to swap out a ✂ slot or small example of what populated content would look like with their own custom local component that’s suited to their mockup or prototype. That local component would be considered a ✎ content carrier.
If you’re interested in making this enhancement in your library, here are the steps to follow:
Now when you or other designers use instances of the component, they have a sensible starting place to begin with (e.g. a table with 3 rows), and if they need more or fewer nested objects, they can make a local copy of <span class="figma-component">✎ [parent component name] content</span>, detach it, turn it into a local main component, and then swap it into their instance!
Congratulations! This is as far as we can go to slash the layer count, which is the highest impact action we can have in reducing memory usage. But if you’re still looking for ways to speed up your file, continue on to phase 3:
If you’ve gone as far as you can go enhancing your components with component properties, but your instances feel laggy and slow when you use them, the next thing to consider is going old school. That’s right. Using separate components, like in the pre-variant days! Look for any components with properties that handle any of the following:
I have a lengthier blog post about the tradeoffs you should weigh as you’re making these decisions. While this won’t help you cut down on layers, it will reduce the size of individual variant sets, making them more snappy and responsive to changes. Speed is part of what makes a good user experience, and Figma components are tiny products, so it’s important to think about the experience of using your instances!
If you still have memory issues, the next most valuable place to look would be high resolution images weighing down your Figma file.
You may be using Styles to handle repeated imagery (like profile pictures, logos, product images etc.) In this case, I recommend using a free app like ImageOptim to compress your images externally from Figma. After compressing your images, edit the styles and upload the newly compressed imagery. This will be applied everywhere that style is being used, saving you time.
For places you’re not using Styles to handle imagery, use Alex Einarsson’s free plugin called Downsize. Alex includes some really good tips on the plugin’s page in the Figma community to get you the best results possible! Figma even recommends this plugin in their own file memory reduction documentation.
If your image is larger than 4,000px on any size, Figma will automatically downsample it upon load in an effort to maintain good performance. But this can result in pixelated images. If you must have an image of that size, use Yuan Qing Lim’s free plugin called Insert Big Image, which splits up the image into multiple smaller images to retain the size and resolution to avoid Figma’s auto downsampling.
I personally don’t see this much in product designers files, and don’t have a lot of experience working with vectors in Figma. But according to Figma’s documentation, complicated vectors with many points is another type of asset (similar to big, high-res images) that can slow down a file. Figma’s documentation suggests importing big, complicated SVGs as multiple, smaller SVGs.
If you know other strategies for slimming vector shapes without sacrificing quality, please send them my way!
I wrote this post after helping a talented designer named Sedat troubleshoot why his file was suffering memory issues. He kindly gave me view access, and as I explored the file and saw the percentage of used memory climb with every new page I visited. I remembered when I was in this same situation in 2019 on a very high profile project.
That was the most stressful experience I had ever had in Figma. We carefully moved our work into the safe harbors of a new file, but there were times I thought we were doomed to lose it all. I remember being worried about my job. This completely changed the way I worked in Figma. I avoided hidden layers like the plague. Having the opportunity to help someone out of the same tough spot is the least I can do.
Unfortunately I can’t scale personalized, one-on-one help like that. So I sincerely hope the guidance and instructions in this post have helped you rescue your Figma file from Hades’ clutches,Orpheus and Eurydice style. I hope you never looked over your shoulder on the journey out, trusting your file was right behind you. ❤️
More than my other posts, I’d love to know if there’s anything erroneous, unclear, or unhelpful in this one. People looking for instructions like this are under immense stress. I’d love your help making this post the best it can be. Folks who read this deserve an easy journey back to calm waters.
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. Right now I'm averaging 1 post every ~3 months (and trying to pick up my pace).