A hand-coded campaign page beat the template it replaced on speed and conversion

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Paid search feeds most of this consumer-finance comparison startup's traffic, and the campaign page for its regulated product category is where that traffic either calculates or leaves. The company runs lean — a five-person team, with engineering time borrowed from the contractors who maintain the core site. Campaign pages lived in a page builder the previous marketing hire had chosen: quick to assemble, heavy to load, and hostile to edits. Rates for the page's comparison calculator changed weekly, and every change meant opening a visual editor and hoping nothing else moved.

What it was costing

Paid traffic landed on a page-builder template that weighed 2.4MB and scored 38 on mobile performance. The calculator — the page's whole job — lagged on mid-range phones, and every 100ms of delay was visible in the conversion data.

What they could see

• On mid-range phones the calculator responded to its first input only after several seconds of waiting.
• The paid team suspected part of every click's cost was buying load time, and the page's performance scores agreed with them.
• Rate updates occasionally knocked the calculator's layout sideways, and the team learned from visitors rather than from any check.
• Analytics showed visitors bouncing before the calculator rendered, but the builder offered no way to see why.

The constraints we worked inside

• The comparison calculator had specific compliance wording that could not be paraphrased.
• The page needed to ship in three weeks alongside a funding announcement.
• The marketing team needed to update rates themselves afterward.

What had been tried before

The team raised bids and widened match types to compensate for the page's weak conversion.

Paying more per click made the page's shortcomings more expensive without touching them — the leak scaled neatly with the budget instead of shrinking.

An audit had recommended image compression and a caching plugin inside the builder.

The wins were real but marginal; the weight lived in the builder's own framework and bundled scripts, which nothing installed on top could remove.

The core-site contractors were asked to quote a native rebuild of the page.

The estimate was honest and unusable — their release process was built for the product site, not a single page with a three-week funding deadline.

What we proposed

Restructure the page around one decision — compare, calculate, act — with proof placed where doubt actually occurs, then hand-build it: lean markup and styles with one small interactive island for the calculator. Rates move into a single editable data file with a documented update path, so marketing changes them without touching the calculator or the compliance text. The compliance wording ships verbatim and is treated as immutable content in the file. Analytics events are named once, in a shared dictionary, so future arguments start from agreed definitions.

Just as important is what we ruled out, and why:

• Staying in the page builder with performance patches — The builder's runtime shipped its framework before the first useful pixel; no tuning inside it would reach the target, and the calculator would still lag on the phones the ads bought.
• Rebuilding inside the main site's codebase — Right tool for the product site, wrong cadence for a campaign page — it would have tied marketing's weekly rate changes to someone else's release train.
• Embedding a third-party calculator widget — It kept the heavy shell and added a script rendering the compliance wording client-side, outside the team's control and outside the audit trail a regulated category expects.

How the work ran

Delivered by the experience pod — frontend engineer over 3 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Next.js (static)

A static build produces one deployable artifact and reads the calculator's rates from a data file — marketing edits content, engineering reviews deploys, and nobody opens a visual editor again.

Lean CSS

One page needs one design system's worth of styles, not a framework's full weight; hand-written CSS keeps the payload to kilobytes and makes the compliance blocks easy to audit line by line.

GA4 events

Calculator interactions, rate-table scrolls, and application clicks got names the team agreed in advance, so the next redesign argues from where visitors actually leave rather than from totals.

Consent Mode

Finance traffic draws regulator-sensitive audiences; Consent Mode lets measurement degrade gracefully before consent, which spared the page both an illegal tag and a banner shouting over the calculator.

What went wrong

How we worked together

Cadence

A 20-minute call every second day with the marketing lead, plus a staging link refreshed with each build and a written note whenever something was blocked.

Client side

The marketing lead owned content and sign-off; the product owner reviewed calculator behavior; the contractors stood by for the DNS cut at launch.

Decisions

Design calls were settled on staging links rather than in meetings — the lead commented, we shipped the same day, and anything contentious waited for the next call.

They provided

The approved compliance text, current rate tables with their update schedule, ad account access for event goals, and the old page as the behavior reference.

What changed

The headline: mobile lighthouse performance score (lab diagnostic), with p75 lcp moving from 4.2s to 1.3s in field data — 38 → 96, read from Lighthouse + CrUX field data. A second check: calculator-to-application conversion at +24%.

Rate changes stopped being an event. The marketing lead edits a file, previews it, and publishes — a process that once required the builder, a careful eye, and occasional repairs now takes minutes and cannot break the calculator. The paid team sends mobile traffic without apology, and the funding announcement went out behind a page that loads before the visitor's thumb settles. The contractors' next invoice, for once, was small.

The result was read from Lighthouse + CrUX field data against the pre-engagement baseline over the stated window, with a guardrail check on calculator-to-application conversion. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The page repository with a README covering preview, build, and deploy.
• A single rates file with documented fields and a worked example of a safe update.
• The GA4 event dictionary with every calculator interaction named and defined.
• A pre-launch checklist covering the performance budget and the compliance text's integrity.
• Deploy credentials transferred to the marketing lead with the contractors as backup.