Optimizing Motion Animations for Core Web Vitals in Next.js 16+

The "SaaS aesthetic" is undeniable. Beautifully orchestrated bento grids, fluid layout morphing, and interactive micro-animations are what separate amateur side projects from premium products.

But there’s a catch: Animations can destroy your Core Web Vitals if handled incorrectly.

Heavy production-ready libraries like Framer Motion bring immense power, but if you drop a raw <motion.div> on your hero section, you risk bloating your First Load JS, shifting elements around during hydration, and thrashing the main thread.

If you want a 100/100 Lighthouse score while keeping your premium UI animations intact, you need to optimize. Here is the definitive production guide to optimizing Framer Motion for Next.js 16+ and the App Router.

1. Eliminate Bundle Bloat with LazyMotion and m

By default, importing motion from framer-motion pulls in the entire library feature set—including dragging, layout animations, and exit transitions—adding roughly 34kB+ (gzipped) directly to your initial JavaScript bundle.
If this happens on your landing page, your Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) will suffer.

The Fix: Drop motion, Use m

Framer Motion provides a slimmer, tree-shakeable alternative: the m component. Combined with LazyMotion, you can defer loading animation features until after the initial page render.

// tsx
import { motion } from "framer-motion"

export default function Hero() {
return <motion.div animate={{ opacity: 1 }}>Hello World</motion.div>
}