There's a common assumption that converting a Framer site to Next.js automatically makes it faster. We wanted an honest answer, not a marketing one, so we picked 10 real, published Framer portfolio templates โ Fuel, Portfolite, Palmer, LaunchFolio, Kirk, MakOS, Miles, Portavia, Artemis, and Meeko โ and ran mobile Lighthouse on both the original and a Next.js conversion of each that keeps Framer's runtime.
The result, unfiltered
Across all 10 templates, average mobile Performance went from 82.1 (original) to 69.8 (converted) โ a real, measurable drop, not an improvement. Accessibility went the other direction: 91.3 โ 94.9, improving on every single template. SEO matched exactly. Best Practices dipped slightly, traced to a separate, fixable bug.
One template โ MakOS โ actually beat its original: 85 โ 98. The rest ranged from a small dip to a serious one (Fuel: 99 โ 67).
Why performance doesn't automatically improve
A conversion that keeps a site's exact runtime, animations, and interactivity intact (as every FNJ output does) is, by definition, still running that same JavaScript runtime โ Framer's own bundled Motion/appear-animation engine, hover-state machinery, breakpoint system. Converting the hosting doesn't remove that weight. If a site was JS-heavy or image-heavy on Framer, it's still JS-heavy or image-heavy after conversion, just running from a different server.
The templates that dropped hardest were also the ones with the heaviest video/image payloads on the original โ the conversion process doesn't and shouldn't silently degrade those assets, so the weight carries over.
What genuinely does improve, and why
Accessibility improved on 10/10 templates because Framer's published markup had the same four fixable gaps on every template, regardless of the source site: no lang attribute on <html>, iframe embeds with no title, no main landmark, and icon-only logo/social links with zero accessible name. These are structural gaps in how Framer generates markup, not something any individual site's designer did wrong โ and they're mechanically fixable during conversion, which is why every single template we tested improved here.
If you actually want a faster site, not just a different host
Runtime-preserving conversion optimizes for "renders identically to the original." FNJ's HTML export keeps Framer's runtime too, so animations and interactions behave as authored; it gets lighter through WebP images and removed trackers rather than by stripping the runtime. FNJ doesn't offer a runtime-stripping mode, so the choice between its outputs depends on whether you want static files for any host, a Next.js project or an Astro project to build on, not on chasing a Lighthouse score; measure your own site in PageSpeed Insights either way โ see our comparison of the HTML and Next.js exports for the practical tradeoffs.
If you want to check where your own site lands, convert it and compare the real numbers in PageSpeed Insights before deciding which output fits.
Starting a new site instead? FNJ's AI website builder designs one from a description and a site you like, then gives you the code to host anywhere.