Are We Over-Engineering Marketing Sites?

Are we over-engineering marketing sites?

Often, yes. A marketing site has one job: put readable text and a clear next step in front of a stranger, quickly. A lot of them now ship an application framework, a component library, a state manager and a tag stack to do it. The measurements say we are getting heavier, not faster.

We say this as a studio that builds with modern tools, so this is not a plea to hand-code HTML in a text editor. It is an argument about what reaches the browser versus what you author in.

Here is the evidence, and where we think the line sits.

What does the data say about how much JavaScript we ship?

It says the web keeps getting heavier. The HTTP Archive's Web Almanac 2024 puts the median JavaScript payload at 558 kilobytes on mobile and 613 kilobytes on desktop, a 14 percent increase over 2023. The median page makes 22 JavaScript requests on mobile, and 68 at the 90th percentile.

The waste figure is the one that should sting. The same edition reports median unused JavaScript of 206 kilobytes on mobile, which is 44 percent of the delivered bytes. Nearly half of what we ship is never executed on that page.

The library picture explains some of it. The Almanac found jQuery on 74 percent of mobile pages, core-js on 41 percent and React on 10 percent. That is a web running several generations of tooling at once, often on the same page.

What is a marketing site actually for?

Getting a specific person to a specific decision. Read the value, check the proof, look at pricing, book a call. That flow is text, images, links and one form. None of it needs client-side routing or a hydration step to work.

Once you accept that, the engineering question changes. You are not asking what stack can build anything. You are asking what stack delivers this content with the least shipped to the browser and the least to maintain in two years.

The complexity usually arrives for authoring reasons, not for the reader: components, previews, reusable sections, a CMS the marketing team can use. Those are real needs. They are just build-time needs.

Does the framework matter, or only the output?

Mostly the output. Our own site is built with React and Vite, and every blog page is prerendered to static HTML at build time, so the browser gets finished markup rather than a script that fetches content. Same framework, entirely different result for the reader.

That is the distinction people skip in the framework arguments. React that prerenders is not the problem. React that ships a bundle to render a paragraph is. Our piece on static versus server rendered pages lays out the trade-offs.

So judge a proposal by what lands in the browser. Ask for the HTML with JavaScript disabled. If the page is blank, you are shipping an application to deliver an article.

Which parts of a modern stack earn their place?

Four, in our experience. A component model at build time, because repeated sections should exist once. A real CMS, because marketing teams should not need a deploy to fix a typo. A build pipeline that optimises images and fonts. And a deploy preview per branch, because it prevents an entire class of launch-day argument.

What rarely earns its place on a marketing site: client-side routing, global state management, a design system with 200 components for a nine-page site, and animation libraries loaded on every route for one hero effect.

Compression is worth checking too. The Almanac found Brotli leading at 45 percent of requests against gzip at 41 percent, so a site still shipping only gzip is leaving easy bytes on the table.

What do we regret building?

Abstractions built for a second use case that never arrived. The pattern is familiar: a client asks for one landing page variant, we build a flexible section system to handle any variant, and eighteen months later there are two variants and a system nobody remembers the rules for.

We also regret every early animation that had to be undone later for performance or accessibility reasons. Motion is cheap to add and expensive to remove, because by then it is in the brand.

The honest lesson is that flexibility has a carrying cost. Every option you build is a decision somebody has to make later, usually somebody who was not in the kickoff call.

How do you tell over-engineering from good engineering?

Count the things a new developer must understand before changing a headline. If that number is one file, the build is sound. If it is a component, a schema, a token file, a translation key and a deploy pipeline, the site has become a product, and product costs are ongoing.

The second test is performance under the standard thresholds. Google's guidance is that Largest Contentful Paint should occur within 2.5 seconds, Interaction to Next Paint should be 200 milliseconds or less, and Cumulative Layout Shift should stay at 0.1 or less, all measured at the 75th percentile.

If a stack cannot hit those for a page of text and one image, the stack is wrong for the job. Our guide to reducing JavaScript bundle size covers the usual culprits.

What breaks when the site outlives the team that built it?

Dependencies and knowledge, in that order. A marketing site tends to sit untouched for months, then need an urgent change. If the build needs a specific toolchain version and three environment variables nobody documented, the urgent change becomes a project.

This is the strongest practical argument for restraint. The team maintaining your site in two years is probably not the team writing it now, and they will judge every clever decision on how long it takes to understand.

We write the runbook before launch for this reason: how to build, how to deploy, how to roll back, what the environment needs. It is the least glamorous deliverable and the one clients thank us for later.

Does this mean you should use Webflow instead?

For many marketing sites, honestly yes, and we say that as a studio that builds in both. A visual builder with a CMS removes a whole category of maintenance work, and the output can be genuinely fast when the build is disciplined about markup, images and custom code.

Where custom code wins is when the site is genuinely part of the product: authenticated areas, complex data, heavy integrations, or a component system shared with an app. Then you are not building a marketing site, you are building a front end.

We laid out how we choose in Webflow versus custom code. The decision should come from the content model and the team, not from what the developers find interesting.

What would we build today for a new B2B site?

A small set of build-time components, content in a CMS, static HTML at the edge, images and fonts handled in the pipeline, and as close to zero client-side JavaScript as the interactions allow. Add complexity only when a specific reader-facing need demands it.

That is not a bold position. It is just the one the numbers support: heavier pages, nearly half the shipped script unused, and thresholds that a simple page clears easily and a complicated one fights.

If you want an honest read on whether your current stack fits the site you actually have, we are happy to look. You can see how we build at phoenix.studio.