Figma slowness and bloated handoffs almost always trace back to the same root cause: images. Specifically, two separate properties of those images that get conflated as one problem, but actually need two different fixes.
Two different problems, often mistaken for one
- File size (compression): how many bytes the image takes up on disk and during sync. This affects how fast your Figma file opens, how quickly changes sync to collaborators, and total document bloat.
- Pixel dimensions (resolution): how many actual pixels the image contains. This affects how much memory Figma uses to decode and render it on canvas — which drives pan/zoom lag while you're actively designing.
Most "make Figma faster" advice only addresses the first one. That's genuinely useful, but it won't fully fix canvas sluggishness if the underlying images are still carrying far more pixels than they'll ever be displayed at.
Why file size slows down handoff and sync
A Figma file is a single document that embeds every image you've placed into it. Paste in fifty unoptimized screenshots and product photos, and your file's total size balloons — every collaborator now has to download that entire payload to open the file, and every change has to sync across that same weight in multiplayer. Figma's own performance guidance points at large embedded images as one of the most common causes of slow file load and laggy collaboration.
This is also exactly what hits your engineering team during handoff. A "quick" design export that's 4-5MB because it carries an unoptimized PNG isn't just a Figma problem anymore — it becomes a slow asset in the actual shipped product, the exact scenario our guide to automatically compressing Figma exports before they hit your repo walks through fixing on the dev side.
The problem compounds fast inside a design system. A single oversized hero photo dropped into a shared component gets reused across dozens of pages and dozens of files that reference it. What looked like a one-off 4MB image turns into a recurring multi-megabyte tax on every file that pulls in that component, every time someone opens or duplicates it.
Why pixel dimensions slow down the canvas itself
Compression and resolution are independent. You can heavily compress an image and it can still be enormous in pixel terms — a 6000×4000px photo compressed to a tidy 800KB JPEG is still 6000×4000px once Figma decodes it to draw it on screen. Decoding produces an uncompressed bitmap in memory, and that bitmap's size depends entirely on its dimensions, not how it was stored on disk.
This is why a file can have a perfectly reasonable total size and still feel sluggish to pan and zoom: a handful of full-resolution photos pasted directly from a camera or stock library, each carrying 10-20x more pixels than the frame actually displays, each costing real GPU memory the moment they're on screen.
A practical rule of thumb: size images to roughly 2x their maximum display size on canvas — enough for crisp rendering on retina displays, without dragging in pixels nobody will ever see. A photo placed into a 400px-wide frame needs to be around 800px wide, not 6000px.
The same anti-aliasing problem shows up here too
If you're exporting UI mockups, icons, or illustrations rather than photos, there's a related issue worth knowing about: Figma exports are heavy on anti-aliasing and soft shadows by design, which is exactly the characteristic that trips up naive "photo vs graphic" compression heuristics. We covered the technical detail in why screenshots and AI-generated images compress so poorly — the short version is that a compressor that always tries palette quantization, rather than guessing upfront, avoids the issue entirely.
The complete fix
- Before placing a photo on canvas, resize it to roughly 2x its maximum display dimensions — not the original camera/stock resolution
- Compress every image you place or export — PNG for UI elements needing transparency, JPEG or WebP for photos
- Periodically audit large Figma files for oversized embedded images (Figma's own "file size" indicators help here)
- For exports heading into a codebase, automate compression at the point they land in your project folder rather than relying on manual steps every time
Dimensions fix the canvas lag. Compression fixes the handoff bloat and sync slowness. Most guides only tell you about one of these — doing both is what actually makes a heavy Figma file feel fast again.
Frequently asked questions
Does reducing image file size make Figma run faster?
Yes, for file load time, multiplayer sync, and overall document bloat. It doesn't fully fix in-canvas pan/zoom lag on its own, because that depends more on image pixel dimensions than compressed file size.
Why does Figma feel slow even after I compress my images?
Compression reduces file size on disk and during sync, but once Figma decodes an image to render it, what costs memory and causes lag is the pixel dimensions, not the compressed size. A heavily compressed 4000×3000px image still decodes to the same large bitmap as an uncompressed one at those dimensions.
What is the right resolution for images placed in Figma?
Generally 2x the maximum size the image will actually be displayed at on canvas, enough to support retina screens without excess. A full-resolution 6000×4000px photo placed into a 400px-wide frame carries roughly 200x more pixel data than it needs.