Why is my Framer site slow if Framer is fast by default?

Your Framer site is slow because of what you added, not because of Framer's engine. Out of the box, Framer gives you a faster baseline than most hand-coded sites: a global CDN, automatic image optimization (JPEG, PNG, WebP, and GIF are converted to AVIF and resized to multiple widths with srcset), Brotli compression on text assets, automatic lazy-loading for most images below the fold, server-side pre-rendering, and font optimization to WOFF2. Before you change anything, open Site Settings → Versions and confirm your latest version is marked Optimized — if it isn't, you're leaving the baseline on the table.

Once that baseline is in place, performance becomes a function of your decisions: how heavy your media is, how many animations run when nobody's watching, how many third-party scripts load on first paint, and how much custom JavaScript you ship. Fix those and most Framer sites move from a failing mobile score into the 90s. The rest of this guide is that fix list, in order of impact.

What did we find auditing 50+ Framer sites?

Across the Framer sites we've audited at FramerLab, five issues account for the overwhelming majority of failing performance scores — and four of the five are about what loads and when, not raw page size. We see them in roughly this order of frequency on sites that come to us underperforming:

*We audited 50+ sites other than mentioned site in above table to keep it clean and easy to understand we added only 1 site each

Here's each one in detail.

Are your images and videos quietly bloating the page?

Media is the biggest single lever on most Framer sites but the fix isn't "convert to WebP," because Framer already does that for you. Every image you upload is automatically converted to AVIF (or WebP lossless if you pick the lossless resolution), resized to multiple widths, and served with srcset so the browser fetches the smallest version that fits the screen. As long as your image Resolution is set to Auto, manual WebP export is wasted effort.

So where does the weight actually come from? Two places Framer can't fix for you.

Source file size. Framer optimizes what you give it, but it can't un-bloat a 10MB, 4000px hero. If an image displays at 1440px, a 4000px source is dead weight. Resize to roughly 2× the display size, target under ~500KB per image, and let Auto resolution handle the format. Tools like freeconvert.com, TinyPNG, or Compressor.io trim source weight in seconds. One caveat that catches people out: never lazy-load your hero image. It's almost always your Largest Contentful Paint (LCP) element, so it needs to load as early as possible — lazy-loading it directly hurts your score.

Video — this is the real one. Unlike images, Framer does not optimize video; it simply fetches the file you uploaded at its original resolution. A single unoptimized background video can sink an otherwise fast page. Two options, best first:

If you self-host, compress to MP4 or WebM with freeconvert.com or an online compressor (CloudConvert, Veed), and for background video, mute it, loop it, hide the controls, and avoid autoplay wherever you can. Get media right and you've usually recovered the majority of a failing score. The next three sections are about timing, not size.

Why does a ticker in your footer/hero slow down your whole page?

A ticker or marquee keeps animating even when it's off-screen so a logo strip in your footer/hero is burning rendering work the entire time someone is reading your hero. Continuous animations don't pause just because they've scrolled out of view. Stack two or three across a long landing page and the browser is permanently animating content nobody can see, which is exactly the kind of main-thread work that tanks a mobile score.

The fix is the same pattern Framer itself recommends for deferring heavy elements, applied to motion:

1. Turn the ticker into a component with two variants. Variant 1 runs the animation. Variant 2 is static (no animation).

2. Add a scroll / "section in view" variant trigger so the animated variant is only active while that section is inside the viewport.

3. When the section scrolls above or below the fold, it switches back to the static variant and the animation stops.

Now your ticker only animates when someone is actually looking at it. The same logic applies to motion generally: use Framer's Appear Effect for important above-the-fold elements (it runs before JavaScript loads, so it feels smoother), avoid stacking a Scroll Animation on the same elements, keep entrance animations under ~300ms, and keep blur values under 10 — Framer itself warns past that point because blur and heavy shadows are expensive to render.

Why do Cal.com and Calendly embeds hurt your load time?

Calendar and form embeds Cal.com, Calendly, HubSpot, Spline, chat widgets — pull their own scripts and data on initial page load even when they sit at the very bottom of the page. So a booking widget in your footer is competing for bandwidth with your hero before a visitor has scrolled an inch. Framer does lazy-load embeds, but they still inject extra third-party code, which is why one calendar embed can visibly drag a score down.

Three moves fix it:

• Defer the embed until it's in view. Use the same two-variant, "section in view" pattern from the ticker fix: keep the embed inside a component that only appears — and therefore only loads — when its section enters the viewport. The third-party script then loads late, instead of fighting your first paint.

• Scope scripts to the pages that need them. Put embed and tracking scripts in Page Settings → Custom Code for the specific page, not site-wide. Place <script> tags at the end of <body> or use defer (use async only if the script genuinely must load immediately).

• Add loading="lazy" to embedded iframes (YouTube, maps, calendars) so they hold off until the user scrolls near them.

Quick diagnostic: duplicate the site, remove the embed, and re-test in PageSpeed Insights. If the score jumps, you've found your culprit.

Is your AI-generated custom code actually optimized for Framer?

Every custom code component ships extra JavaScript and AI tools like Claude, GPT, Codex, and Cursor optimize for "make it work," not "make it fast inside Framer," unless you explicitly tell them to. That's not a knock on the tools; it's a prompting gap. The code runs, the component looks right, and nobody notices the unnecessary re-renders, the work firing on mount, or the event listener that never gets cleaned up until the score drops.

Two habits keep this under control.

First, before reaching for code at all, ask the honest question: can native Framer layers do this? A surprising amount of "we need custom code for this" is achievable natively, and every code component is JavaScript you're adding to a page that was otherwise pre-rendered and lean.

Second, when you genuinely need code, prompt the model with Framer-specific performance constraints before it writes a line:

Before writing this Framer code component, do a short performance analysis for Framer's rendering model, then implement to these constraints:

• Framer pre-renders / SSRs pages — don't break hydration or assume window exists on first render.

• Defer non-critical work; don't run heavy logic, fetches, or animations on mount.

• Only mount below-the-fold elements when they enter the viewport.

• Avoid layout thrash and needless re-renders (memoize; no heavy inline computation).

• Clean up timers, listeners, and observers on unmount.

• Keep dependencies minimal; prefer native browser APIs over heavy libraries. Then flag any performance tradeoffs you made.

The same model that would have handed you a slow component will hand you a fast one — you just have to set the rules first. This is the difference between AI-assisted Framer development and AI-bloated Framer development.

Do too many breakpoints slow down a Framer component?

Every breakpoint you add is another layout Framer has to compute and ship, so over-engineered responsive setups quietly add weight. (Note: this was the point the original brief trailed off on here's a reasonable version; trim or expand to match how FramerLab frames it.) Designing a separate desktop, tablet, phone, and a couple of custom breakpoints for a component that a single fluid layout could handle multiplies complexity for little gain. Use only the breakpoints you actually need, design mobile-first, lean on fluid/responsive sizing instead of duplicating entire layouts per device, and prune variants you're no longer using. Fewer, smarter breakpoints render faster and are far easier to maintain.

How did this play out on real client builds?

The fastest Framer sites aren't the ones with the least design — they're the ones where the heavy parts are loaded deliberately. A few examples from FramerLab's work

Fused — migrating a custom-coded site to Framer without losing performance. This was the textbook case for everything above. Migrating a complex product site from custom code into Framer meant we could drop a pile of hand-rolled JavaScript in favor of native layers, defer the heavy embeds, and lean on Framer's CDN and image pipeline improving performance, responsiveness, and content flexibility in one move.

Protocol — a motion-heavy AI hiring platform built Figma → Framer. Protocol needed the polish of an AI product brand without paying for it in load time. The animation lived where it earned attention; the rest of the page stayed lean.

Compound — a premium brand that had to stay fast. Compound's brief was explicit: reflect a premium brand while maintaining speed, clarity, and scalability. That tension premium feel and speed is exactly what the deferred-loading approach in this post is built to resolve.

Skulpt Sports — a 10+ page site with custom motion in every section. Heavy motion across an entire site is usually where performance dies. The fix was structural: motion gated to the section in view, so no single page carries the animation cost of all the others.

How do you actually run these fixes?

Work in order of impact, isolate problems with a duplicate site, and always test on mobile — that's where Framer sites struggle and where Google scores you hardest. The sequence:

1. Confirm the baseline. Site Settings → Versions → ensure it's marked Optimized.

2. Measure. Run the live URL through Google PageSpeed Insights on the mobile tab. Note the score, LCP, and flagged elements.

3. Fix media first. Resize oversized source images, move heavy video to Vimeo/YouTube, confirm the hero is not lazy-loaded. Re-test — usually the biggest jump.

4. Defer animation and third-party code. Convert tickers and embeds to the two-variant, "section in view" pattern; scope scripts to their pages; add defer/loading="lazy". Re-test.

5. Audit custom code. Remove anything native layers can do; re-prompt anything that stays with the performance constraints above.

6. Prune breakpoints and unused variants.

7. Isolate stubborn issues. Duplicate the site, strip one element at a time, re-test to find exactly what's costing you, then fix it on the live version.

None of this touches Framer's defaults. It's about being deliberate with everything you add on top.

FAQ: Speeding up a Framer website

Does Framer optimize images automatically?
Yes. Framer converts uploaded JPEG, PNG, WebP, and GIF images to AVIF (or WebP lossless), resizes them to multiple widths, and serves them with srcset. Keep image Resolution on Auto. What's still on you is source file weight and video, which Framer does not compress.

Why is my Framer site fast on desktop but slow on mobile?
Mobile devices have less CPU and slower networks, so costs desktop absorbs — heavy video, off-screen animations, third-party scripts — show up dramatically on mobile. Google also scores mobile more harshly. Always test the mobile tab in PageSpeed Insights.

Do animations slow down a Framer site?
They can. Tickers and marquees keep running off-screen, and scroll-triggered effects, parallax, and 3D transforms add JavaScript execution time. Limit them to your hero and one or two key sections, keep entrance animations under ~300ms, and use the two-variant "in view" pattern for anything that loops.

Should I upload video to Framer or use YouTube/Vimeo?
Use YouTube or Vimeo whenever you can — they adapt quality to the device and lazy-load automatically. Framer does not optimize self-hosted video; it serves the original file. If you must self-host, compress to MP4 or WebM and avoid unnecessary autoplay.

Why is my Cal.com or Calendly embed slowing my site down?
Calendar and form embeds load their own scripts and data on initial page load, even below the fold. Defer them with the two-variant "in view" pattern so they only load when their section is visible, scope the script to that page, and use defer plus loading="lazy".

How do I test my Framer site's performance?
Run the live URL through Google PageSpeed Insights (mobile tab) for your score and Core Web Vitals. To pinpoint a specific culprit, duplicate the site, remove one element at a time, and re-test — the element that recovers the score is your problem.

Can a Framer site score 90+ on PageSpeed?
Yes. Framer's CDN, automatic image optimization, Brotli compression, and built-in lazy-loading give a fast baseline. Reaching 90+ is mostly about controlling media weight, deferring animations and embeds, and keeping custom code lean.

Is Framer good for SEO and Core Web Vitals?
Framer pre-renders pages and gives you a strong technical baseline for Core Web Vitals, which Google uses as a ranking signal. The performance ceiling is set by your media, animation, and code choices — the fixes in this guide are what move a Framer site from "fine" to genuinely fast.

Want your Framer site fast from day one?

FramerLab is a senior-led Framer studio — 50+ sites launched, no juniors, no subcontracting, NDA-friendly. If your Framer site is slow, or you're moving to Framer and don't want to lose performance in the process, book a discovery call.

• Explore what we do at FramerLab

• Moving from another platform? See Webflow → Framer migration (migrate without losing performance or SEO)

• Agencies needing white-label capacity: White-label Framer development

• See it in practice: Compound — Figma to Framer build and the Fused custom-code → Framer migration (confirm Fused case-study URL)
  
  

Written by Dilip, founder of FramerLab, with 5+ years designing and building on Framer. Connect on LinkedIn and X.