How to Lazy Load Images in Framer (Without Hurting LCP)

Lazy loading defers offscreen images so the browser can prioritise what the visitor sees first. Applied to your hero image, it does the exact opposite — it delays your Largest Contentful Paint and makes the page measurably slower. Selectivity is the whole technique.

TL;DR

• Never lazy-load anything above the fold. Especially not the LCP element.

• Framer lazy-loads by default in most contexts, which is right for galleries and wrong for heroes.

• The biggest performance win is usually image size, not loading strategy.

• Reserve space for images or you trade an LCP problem for a layout shift problem.

• Measure with field data, not a single lab run.

What lazy loading actually does

A lazy-loaded image is not requested until the browser thinks it is about to enter the viewport. This frees bandwidth and connections during the critical early moments of page load, so the content the visitor can actually see arrives sooner. On a long page with twenty images, it is a large win.

The mechanism has no idea which of your images matters. That judgement is yours, and getting it wrong is worse than not lazy-loading at all.

Why lazy-loading the hero is actively harmful

Your Largest Contentful Paint is usually the hero image, and LCP is one of the three Core Web Vitals. A lazy-loaded image is discovered later in the page lifecycle, because the browser has to run layout before it decides the image is needed. That delay lands directly on your LCP score.

The rule is simple and absolute: everything visible without scrolling loads eagerly. Everything below loads lazily. The only difficulty is that "above the fold" differs by device, so use the mobile viewport as your boundary — it is the smaller one and the one Core Web Vitals is measured on.

How this works in Framer

Framer applies lazy loading to images by default in most contexts, which is a sensible default for content images and the wrong one for heroes. Where you have control — image components, background fills, and code components — set the hero and any above-fold imagery to load eagerly. For CMS listing pages, the first row of cards is frequently above the fold on desktop and should be treated the same way.

If you are using a code component to render images, this is one attribute: loading="eager" plus fetchpriority="high" on the LCP image, and loading="lazy" on the rest.

The bigger win nobody makes

Loading strategy is worth tens of milliseconds. Image size is worth seconds. The most common cause of a slow Framer site is not the loading attribute, it is a hero photograph uploaded at 4000 pixels wide because that is what came out of the camera.

Framer serves responsive sizes and modern formats automatically, which helps a great deal, but it cannot invent detail it does not need or fix a source file that is twenty times larger than any rendered size. Export at roughly twice the largest rendered dimension and no more.

Do not trade LCP for CLS

An image that arrives late without reserved space pushes the content below it down, which is a layout shift and a different Core Web Vital. Every image needs known dimensions or a fixed aspect ratio container so the space is held before the pixels arrive. In Framer this usually means giving the image frame an explicit aspect ratio rather than letting it size to content.

Where Framer's automatic lazy-loading doesn't reach

The default only covers standard image layers in the normal page flow. Three cases fall outside it, and Framer's own team has flagged them as a known gap rather than a design choice:

• Images inside code components — the component controls its own markup, so Framer's loading behaviour never touches it.

• Images inside smart components whose visibility or layout is driven by a variable — the variant swap happens after Framer has already decided what to load.

• Images inside CMS rich text fields — anything a blog author drops into a formatted-text field, including your own body images, ships without the automatic behaviour.

That last one matters most for a blog. If your post template renders images through a formatted-text CMS field — which is exactly how most Framer blogs are built, including this one — none of the pictures below your first paragraph are getting deferred by default. On a long post with six or eight inline images, that is real weight loading eagerly for no reason.

The fix is a code override applied to the CMS rich text component, forcing loading="lazy" on every image tag except the first (which may be above the fold and should stay eager). It is a five-line override, not a plugin, and it is the one lazy-loading fix most Framer blogs never make because the default behaviour looks like it is already handling it.

A short checklist

• Hero and any above-fold images: eager, high priority, correctly sized.

• Everything below the fold: lazy.

• Every image container has reserved dimensions or an aspect ratio.

• No source image more than roughly twice its largest rendered size.

• Decorative background images checked separately — they are easy to forget and often the heaviest thing on the page.

• Re-measure after changes, on mobile, with field data rather than one lab run.

How to check whether you got it right

Run the page through a Core Web Vitals tool and look at which element is identified as the LCP element. If it is your hero image and the timing is poor, check its loading attribute first and its file size second. If the LCP element is something unexpected — a block of text, or an image you thought was decorative — that is worth knowing on its own.

What to do next

Audit your five highest-traffic pages for above-fold images set to lazy, then check the source dimensions of every hero on the site. Those two passes fix most Framer performance problems. The performance service page covers the deeper work when defaults are not enough.