When marketing says the site isn't converting, most developers reach for the funnel, the CTA copy, or the ad spend. The real problem usually sits a layer deeper, in the code that decides how fast a page paints, how stable it feels under a thumb, and whether a first-time visitor trusts what loads in front of them.
So where should engineering actually start when the numbers come in soft?
Performance Is a Conversion Problem, Not a Vanity Metric
Page speed used to be an SEO talking point. Now it's a revenue one. A Google/SOASTA study trained a neural net on real mobile traffic and found that the probability of a visitor bouncing jumps 123% as load time slides from one to ten seconds.
That isn't a soft correlation. That's the bounce curve most marketing dashboards are sitting on without knowing it.
For a dev team, the useful part is that the fixes are measurable. Image weight, render-blocking scripts, and lazy hydration all show up in tooling you already run. Fix them and the marketing KPIs move without anyone rewriting a headline.
Core Web Vitals Are the Contract Between Code and Growth
If you want a shared vocabulary with the marketing side, Core Web Vitals are it. LCP, INP, and CLS turn loading, responsiveness, and visual stability into numbers a backend engineer and a growth lead can argue about in the same meeting.
- LCP under 2.5s. Largest Contentful Paint measures when the main content actually shows up. Hero images, web fonts, and unoptimized server responses are the usual culprits.
- INP under 200ms. Interaction to Next Paint captures how snappy the page feels when someone taps a button. Long tasks on the main thread are what wreck it.
- CLS under 0.1. Cumulative Layout Shift punishes the ad slot that shoves a checkout button out from under a thumb. Reserve dimensions for media and injected content.
Design Debt Reads Like Broken Trust
Speed gets a visitor to render. Design decides whether they stay. Inconsistent typography, buttons that don't match between templates, a homepage that doesn't visually agree with the pricing page: all of it reads as sloppiness even when the code underneath is clean.
Marketing teams that live at the intersection of brand and build, like the folks at Design At Work, spend a lot of time reconciling those two realities. The pattern library and the marketing site have to speak the same language, or growth spend leaks out through mismatched impressions.
Ship Fewer Experiments, But Instrument All of Them
A common failure mode: marketing wants twelve landing page variants, engineering ships them, and nobody wires up analytics deep enough to attribute the win. Then everyone argues about gut feel for a quarter.
- Define the event before the PR. Decide what "converted" means at the code level, and add the event alongside the feature, not after.
- Guard the vitals in CI. Budget LCP and bundle size. A regression should fail a build, not a quarterly review.
- Kill variants on a schedule. If a test can't hit significance in a fixed window, retire it. Dead A/B branches rot in the codebase and drag on the next deploy.
Where Engineering Earns the Marketing Budget
The teams that get this right stop treating the marketing site as a second-class app. It goes through the same review standards as the product, with the same observability and the same on-call rotation behind it.
When a campaign lands, the infrastructure holds, the vitals stay green, and the design system doesn't fracture under a new hero section.
None of this needs a rewrite. It needs developers to accept that conversion is partly a code problem, and to own the parts of it that live in their repo.
