TL;DR: A marketing site loads once, shows mostly-static text, and routes a visitor to a CTA. The job is served by HTML, CSS, images, and maybe 50 lines of JavaScript. Since 2020 the default has been a Next.js app with seven npm dependencies, three rendering modes, and 400kb of JavaScript shipped to render a hero headline. The result is slower, uglier, and harder to maintain. The four jobs of a marketing site: load fast, show a message, prove a claim, route to a CTA. Every animation, A/B scaffold, analytics event, chat widget, and personalization layer competes with those four. Most should not win.
A marketing site is not an app. It loads once, reads mostly-static text, and converts a visitor into a lead or a signup. The job is served by HTML, CSS, some images, and maybe fifty lines of JavaScript.
Somewhere around 2020 we stopped treating marketing sites that way. Now the default is a Next.js app with seven npm dependencies in the critical path, a component library, three rendering modes, and a bundle that ships 400kb of JavaScript to show someone a hero headline. The result is slower, uglier, and harder to maintain — and almost every studio is still doing it. Us included, some of the time.
Here is the case for doing less.
What a marketing site actually is
A marketing site does four things.
- Loads fast.
- Shows a message.
- Proves a claim.
- Routes to a CTA.
Every additional thing — animations, interactions, dynamic personalization, A/B scaffolding, analytics events, chat widgets, marketing tags — competes with those four. Most of them should not win.
What most marketing sites ship instead
A typical mid-market SaaS site in 2026 ships:
- 600kb of JavaScript, 300kb of it before interactive.
- Six third-party tags (GTM, Segment, Intercom, HubSpot, a heatmap tool, and one more you forgot about).
- Three render modes: SSR, ISR, client-side hydration for "interactive islands" that are not actually interactive.
- A component library that requires 40kb of runtime to render a button.
- Motion libraries that run on every scroll event, even when nothing is animating.
None of this is making the site better. Most of it is making the site slower and more fragile.
The actual performance cost
Specific numbers from sites we have audited.
- Typical React SaaS marketing site: 2.5–4.2s Time to Interactive on 3G, 1.1–1.8s Largest Contentful Paint.
- Same content as static HTML + CSS + minimal JS: 0.4–0.9s TTI, 0.6–1.0s LCP.
- Bundle size difference: 400kb vs 40kb.
- Lighthouse performance score: 72 vs 99.
This gap costs you conversions, measured by every bounce-rate study run since 2010. It costs you Google rankings on Core Web Vitals. It costs you trust from technical buyers who notice the page stutter.
The real reason we over-build
Three structural reasons, all honest, none good enough.
1. The tooling assumes app-scale complexity. Next.js, Remix, and Nuxt are designed for products with auth, data fetching, and routing. They work for marketing sites but they are over-sized for the job.
2. Developers build sites using the same patterns they know from apps. If you work in React all day, every UI problem looks like a React problem. A scroll animation becomes a Framer Motion component with a dependency on a state library.
3. Marketing teams pile on tracking. Every pixel, tag, and widget looks free because nobody is the DRI for total bundle weight. So the site keeps gaining weight until a new site is cheaper than a cleanup.
What to do instead
A marketing site should be mostly static HTML, some CSS, and a small amount of JavaScript where it earns its weight.
Default to static. Pre-render every page. There is almost no marketing page that needs to be rendered at request time. If a page has personalization, render it with a JS hydration layer for the personalized chunk only, not the whole page.
Use JavaScript only where it earns it. A hero animation that adds 40kb is fine if the animation is a brand asset. A button component that adds 40kb is not. Audit every dependency. Can you write it yourself in 100 lines?
Ship less CSS. Tailwind or plain CSS is fine. 200kb CSS bundles on marketing sites is a sign that nobody purged unused styles. Modern tooling does this automatically; use it.
Audit third-party tags quarterly. Every tag on the page should have a named owner and a justification. Tags with neither should be removed. "We might need it" is not a justification.
Use the platform. CSS scroll snap, native lazy loading, content-visibility, view-transitions, native dialogs, HTML <details>. Every platform primitive you use is JavaScript you do not ship.
Measure total transfer, not just Lighthouse. Lighthouse is directional. Real mobile performance on a 3G emulation or a slow phone is the metric that matters.
When a heavier site is actually justified
Two cases, both narrow.
1. The site is the product. A designer showcasing bespoke motion, an agency selling craft, a studio that needs the site itself to demonstrate what they build. In these cases, the site is allowed to be heavier, because the heaviness is the product. But even then, ship only what earns it.
2. The site has app-level interactivity. A live pricing calculator, a real-time demo, a data dashboard embedded in the marketing page. These are app-scale interactions and app-scale tooling is appropriate — for those sections only, not the whole page.
Every other marketing site should ship like a 2012 blog: fast, cached, boring on the wire, clean on the screen.
What we ship when we are honest
A Webdimonia site we are proud of:
- 40–80kb of JS, zero on the critical path for the hero.
- Three to five dependencies total in the bundle, not forty.
- Scroll animations implemented with the platform (
animation-timeline, IntersectionObserver, a tiny motion helper when we need one). - Tailwind, purged.
- Vercel Analytics only, no third-party tag pileup unless the client really needs it.
- Lighthouse 99 on desktop, 95+ on mobile.
- LCP under 1.2s on simulated mobile.
That is not hard to hit. It does require saying no to a lot of defaults.
A last thing
The agency version of "we over-ship on marketing sites" is "we over-scope on everything." The same instinct that adds a component library to a static site also adds a discovery phase to a one-page project. Cut both.
Doing less, on purpose, is a skill. The studios that learn it ship faster, cheaper, and better. Clients notice.