Prototype freezes for a while when opening an overlay

Ask the community
1

Hi, as stated in the title, every time I open an overlay from a button component, the prototype just struggles incredibly hard to load it, both on the Windows app and every browser.

Once a while passes, like 5 mins after clicking it, it loads the overlay without any issues and almost instantly.

This happens even if the overlay is just a frame with a text, no components inside, no nothing. It’s driving my crazy since I started the project from scratch just to resolve this issue.

I’m sitting at 6% max memory, there are almost 0 unnecesary frames, barely any repeated components with hidden elements. I basically reworked the entire project to be as efficient as possible, but the issue still persists.

Any tips?

Thank you so much!

2 Likes
2

Hi there,

Sorry to hear that’s happening. Have you tried clearing your desktop app’s cache?

You can do so by following stesp:

  1. On the right side of the top toolbar, click the down arrow to open the menu.
  2. Go to Help > Troubleshooting and select Clear Cache and Restart.

Alternatively, if you can’t access the app or prefer to do manually:

  1. Close the Desktop app.
  2. Open the Start menu
  3. Paste this string %APPDATA%\\\\Figma
  4. Press Enter to open the window
  5. Delete the Desktop and DesktopProfile folders, if they exist.
  6. Launch the Figma desktop app

If you have unsaved changes in your file, we recommend trying to open the file in the browser first. This will allow you to sync any offline changes, so you don’t lose your data.

Please let me know how that works!

Thanks,
Toku

4

Hi, followed the steps and nothing.

I redid again the whole project and still freezes. As of now, it’s completely unusable and it’s incredibly urgent that we figure this out for a client presentation next week.

Is there any support contact for this? Thank you.

5

In fact it now happens even without opening overlays, incredibly frutstrating and unusable.

6

Sorry for the frustration. Could you reach out directly to the support team with a copy of your file: https://help.figma.com/hc/en-us/requests/new? Our support team will look into it.

Please make sure you use the email associated with your Figma account, include links to the file in question, and share access with support-share@figma.com. Don’t worry, inviting us to view your file won’t impact your billing.

Thanks for your patience.
Toku

7

This sounds like the same issue I described in this thread: Prototype is slow but file is small - #9 by Jackie_Lampard

8

I posted this as a response to another thread, so I’ll add it here:

Since the issue for most projects is not memory usage, we decided to sacrifice some memory usage in order to gain speed.

Two things “solved” the issue:

First - Avoid variants in components when possible, and create separated components instead of sets. We used to have 4 types of buttons in one component set, and experienced all kinds of bugs and performance issues the bigger the file got. This action not only helped with performance but also “fixed” known bugs like persistent/incorrect state changes playing the prototype (icons suddenly changed to default color, labels breaking, hovers using default state colors, you name it).

REASON FOR THIS: Figma loads all component states and variants when any given component is in the rendered view of the prototype. Therefore, it’s faster to have more components with less variants, rather than less components with a huge amount of variants. Even if in the end, the designed component is not representantive of what the dev team will do (they will probably generate less components with more flexibility, depends obviously on the case/dev).

Second - Avoid overlays. This is the part that I couldn’t solve, but managed to avoid. The way to avoid it is incredibly annoying, but fixes the issue.

1- We grabbed every view of the app, and converted it to a component itself.
2- Then, for any given overlay we wanted to add in one of those views, we create a new view that has 3 things:

  • An instance of the view that acts as background for the overlay.
  • An instance of a component called “Overlay shadow layer”, which is the grey shadow behind the overlays.
  • The overlay on top of all.

This way we still only have to change the base view component, and the changes apply to all the views that have the overlay. It’s a hassle, and you lose the scroll position iirc, but it literally saved the day for us.

REASON FOR THIS: Can’t confirm, but it feels like Figma loads ALL the overlays internally at the same time in memory, hence when one is loaded, and the prototype becomes responsive again, then all overlays behave normaly. But this usually takes minutes to happen, so it’s a huge problem during client presentations.

Right now, we are sitting at around 16% memory usage, around 2-3% more than before taking these actions.

Hope this helps.

9

Wow… we have so much overlay, we can’t even think about doing this “diy-fix” to make our prototypes work again.

What’s going on Figma ?