Core Web Vitals for Framer

What real Framer sites measure

We measured Framer’s own site and Superlist, a high-profile production site built with Framer, using Lighthouse 13 (mobile emulation) in July 2026. Both scored 57/100 — a suggestive coincidence. framer.com came in at LCP 4.1 s, TBT 1,951 ms, CLS 0.08; superlist.com at LCP 3.6 s, TBT 967 ms, CLS 0.00. Both are motion-heavy showcases — closer to the ceiling of what teams build in Framer than the floor — and the shape of the cost is consistent: effects JavaScript inflates blocking time and pushes hero rendering past the 2.5 s LCP threshold, while layout stability stays excellent. A restrained Framer site starts far above these numbers; the sections below are about keeping motion where it earns its milliseconds.

Framer’s architecture works in your favor

Unlike the builder generation before it, Framer does not ship your whole site as a JavaScript application. Pages are pre-rendered to static HTML and CSS at publish time and served from Framer’s edge CDN; JavaScript hydrates the parts that need it (effects, interactive components) after the initial paint. Text and images are visible without waiting on a bundle, TTFB is short from anywhere, and images get automatic srcset variants and modern formats.

The practical implication mirrors other managed platforms but with a higher ceiling: there is no server to tune, no cache plugin to install, and platform-level findings are not yours to fix. Your levers are design decisions — how much motion, how much media, how many code components — and Framer will faithfully render either a fast site or a heavy one from them.

Effects and motion: spend them deliberately

Framer makes scroll transforms, parallax, appear effects, and text animations one click away, and that convenience is how fast sites become slow ones. Every animated layer hydrates JavaScript and runs work on the main thread; appear effects additionally hide content until the animation fires, which on a throttled phone means your headline — possibly your LCP element — renders late by design.

The discipline that keeps scores intact: keep the first viewport static so the hero and headline paint immediately, apply appear effects from the second section down, and prefer transform/opacity animations (compositor-friendly) over anything that changes layout. Looping tickers and infinite marquees are the worst offenders per byte — they run continuously, not just during load. A site that animates three deliberate moments feels more premium than one that animates everything, and measures dramatically better.

Media: heroes, video, and intrinsic sizes

Framer handles the image pipeline — responsive variants, modern formats, lazy loading below the fold — but it renders what you place at the size you place it. Upload sources at roughly 2x their largest rendered size rather than camera originals, and give media layers fixed intrinsic dimensions so nothing reflows when assets arrive.

Video is the decision that moves numbers most. An autoplaying hero video competes with every other resource during the exact window LCP is measured, and Framer will not stop you. If the design calls for motion in the hero, use a short clip, compressed hard, with a poster image — or better, a static hero with video below the fold. For embedded YouTube or Vimeo, use a thumbnail-plus-click pattern (a facade) instead of a live iframe; a YouTube embed loads more JavaScript than the rest of a typical Framer page combined.

Code components and embeds: the unbounded cost center

Framer’s escape hatches — code components and the embed element — are real React shipped to the client, outside the platform’s optimization guarantees. A code component pulling in a charting library or a widget SDK can add more JavaScript than your entire designed site; an embed pasting a third-party script does the same with less visibility. Both are legitimate tools; both should be treated as line items in a budget.

Audit them: each code component’s dependencies ship to every visitor of every page that uses it, so keep dependencies minimal and components below the fold where possible. For analytics and marketing tags added in Site Settings → custom code, the same head-versus-body logic applies as everywhere — nothing render-blocking in the head start, defer what can defer, and remove tags that no longer earn their place.

SEO settings and measuring correctly

Framer covers the mechanical SEO layer: per-page titles and descriptions, open-graph images, automatic sitemap.xml and robots.txt, canonical tags, and semantic tag assignment (which element is the H1) in the properties panel. The gaps to check by hand: exactly one H1 per page (easy to violate in a design tool), alt text on meaningful images, and structured data — Framer emits little JSON-LD by itself, and a custom-code block with your Organization markup fills that gap.

Measure the published site — your custom domain — not the editor preview, which carries the editing runtime. Framer publishes are instant, so the iteration loop is fast: change one thing (kill a hero animation, facade an embed, compress a video), publish, re-test. Watch results on a mobile profile; Framer sites are designed on large screens, and the gap between desktop and mobile scores is where the work usually hides.