Framer to Next.js benchmark: speed, visual fidelity and build results

We converted 12 public Framer sites to Next.js with Deframer on 25 October 2026. All 12 converted, with a median first-conversion time of 11.7 seconds. 11 of 12 built with next build without changes (the 12th after a two-line fix). Across 11 measured sites, the median site differed from its live original by 0.23% of pixels at 1440 and 390 px. The benchmark used the Next.js export; Deframer also exports the same conversion to TanStack Start, Astro, React Router and Vite.

This post reports the aggregate numbers, the conditions they were measured under, and what they don't tell you. The five-site deep dive with per-page results is in real conversion tests on five websites; the method is in how we test a Framer to Next.js converter.

What were the test conditions?

How the 12 sites were chosen: five were picked by a written rule, one per type (landing page, agency, animated portfolio, CMS blog, multilingual) from a list of 150 Marketplace template demos spread evenly over the catalog. The other seven came from a systematic draw (every 10th template on that list, and custom-domain Framer sites at a fixed interval by name), taking the first seven while keeping a mix of types. We planned 25 sites and cut to 12 for time; the cut was made before measuring the seven. Sites are anonymized here; the list is available on request.

How fast was the conversion?

Measured. Wall time from the public URL to a written project, first conversion (nothing cached):

Most of the conversion time is downloading the published site's code, so it depends on the network and the site's size more than on the CPU. Build times exclude npm install and were measured against an already-installed set of packages, so a first build on a fresh machine takes longer.

How close did the converted sites look?

Measured. For each route and width, the share of pixels that differ from both of two live captures (details of the comparison are in the methodology post).

Per site (anonymized):

Captures per site are 2 to 6 (one-page sites have one route at two widths). Sites A to E are sites 1 to 5 of the five-site test, measured again here in benchmark mode.

Did the projects build and type-check?

Measured.

Every project contained code components or vendored code, and Deframer turns off type checking during next build for such projects, because Framer never type-checks that code. That is why 8 projects with tsc errors still built. Most errors were in the sites' own code components or vendored code; one site had 8 errors in a generated component. The failed build (site E) was a converter bug: two documentation comments left unclosed in code components. Both are listed in the migration problems database.

What do these numbers not show?

• Only three static routes per site. The benchmark compares the first three static routes. It missed defects the five-site test found on deeper pages: three CMS posts returning 404 on site D and an animation error on one page of site B. Read the five-site test for those.
• Reduced motion. Captures run with the reduced-motion preference on, so they compare layouts after animations, not the animations.
• No interactions. Menus, accordions and forms were not exercised; our interaction checker did not work on this output (see the methodology post).
• Pixel ratios are blunt. On site C, rechecking showed that the 19.3% capture came from the live site's own preloader still running when it was captured, while another high capture was a real difference on the converted page. We report the numbers as measured.
• Performance and SEO. We didn't measure page speed, Core Web Vitals or rankings, and this benchmark doesn't show that converting improves either. See Framer PageSpeed before and after conversion and SEO when moving off Framer for those topics.
• Sample size. n = 12, mostly templates. Treat percentiles as descriptive of these sites, not as guarantees for yours.

What is our judgment?

These are opinions, separate from the measurements above.

• For layout fidelity on the pages measured, we consider the results good: 52 of 56 captures under 1% and every page height equal to the live page. We did not open every diff image, so we can't say what each remaining difference was.
• The defects that matter most to a site owner were page-specific (one build failure, one animation error, one slug encoding bug), not systematic. They are fixable by hand and are now tracked as converter bugs.
• The tsc results mean you should plan time to fix types in code components if you want type-checked builds.

How can you reproduce this benchmark?

Use the method in our testing methodology post: fix a site list first, convert, run tsc --noEmit and next build, compare full-page screenshots against two live captures at fixed widths, and publish every failure. It works with any converter or with a hand-built rebuild. If you want to compare tools, run them on the same list on the same day, since live sites change.

When will it be re-run?

We'll re-run this benchmark on later converter versions with the same rule, add sites, and update this post with the date and version. Each run's raw results (per-capture JSON) are kept.