Eleveyte

How We Approach Core Web Vitals at Eleveyte

Performance is a design constraint, not a post-launch fix. Here is how we bake Core Web Vitals into every Eleveyte build.

Alkesh Shah
Alkesh Shah
Jan 25, 2026
How We Approach Core Web Vitals at Eleveyte

Performance is a design decision

The fastest sites aren't fast because someone optimised them at the end. They're fast because performance was a constraint from the first design review. At Eleveyte we set a budget — usually under 100KB of JS and an LCP under 2 seconds — and design backwards from it.

Our default stack

  • Next.js with server components and streaming
  • Images served through next/image with explicit sizes
  • Fonts self-hosted with `font-display: swap` and preloaded
  • Tailwind purged aggressively to keep CSS under 20KB
  • Animations from CSS first, JS only when necessary

What we measure

We track Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint and the total JS payload on every PR. Lighthouse CI fails the build if anything regresses by more than the agreed budget.

Common wins we keep seeing

  • Replacing carousel libraries with native CSS scroll-snap
  • Removing unused fonts and icon libraries
  • Lazy-loading anything below the fold
  • Pre-rendering or ISR for marketing pages instead of fully dynamic SSR
  • Cutting third-party scripts down to what's actually needed

The payoff

Faster sites convert better, rank better and cost less to host. Treat performance as a feature, fund it like one, and the numbers move.