Why 650ms TTFB is a paid media lever, not a vanity metric.

Every performance conversation starts with a Lighthouse score and ends with a redesign proposal. That is backwards. The number that matters is not the score. It is the cost of the session that abandoned before your hero rendered.

For a paid media program, page speed is not a technical hygiene item. It is a multiplier on every rupee of spend. If 20% of mobile sessions leave before the page becomes usable, you paid for 100% of the click and competed for 80% of the conversion.

This is the case for treating TTFB, LCP, and interaction latency as media levers — with the same rigor you apply to bids, audiences, and creative.

The TTFB tax on paid media

Time to First Byte measures how long it takes for the server to return the first byte of the document. It is the foundation of every metric that follows. If TTFB is 650ms, the browser cannot begin parsing, discovering the hero image, or loading the font until that 650ms has passed.

A 650ms TTFB is not catastrophic on a fast connection. It is expensive on the connection your actual buyer is using. On a mid-range Android phone on a congested network, the network latency stacks: DNS, TLS, server response, HTML download, CSS, font, hero image, JavaScript. The user sees a blank screen and decides whether to wait.

The distribution matters more than the average. We look at p75 and p95, segmented by device and country. Averages hide the audience that experiences the worst version of your site — usually the mobile users acquisition teams are paying the most to reach.

In one B2B SaaS audit, the marketing site's median TTFB was 480ms but p75 on mobile in India was 1.9 seconds. The lab score was green. The field data explained why paid social conversion was half the rate of paid search.

Where speed shows up in ad platforms

Google Ads does not publish a "speed score" that maps cleanly to Quality Score. But landing page experience is a component, and page experience signals — including Core Web Vitals — feed how Google evaluates that landing page. Slow, unstable pages tend to produce worse ad experiences, and worse ad experiences tend to cost more.

The effect is rarely a dramatic CPC penalty on day one. It shows up as:

• Higher cost per click in auctions where landing page experience is a differentiator.
• Lower conversion rate on the same creative and audience.
• Worse return on retargeting, because the first session never produced a signal.
• Longer payback periods that make otherwise viable campaigns look unprofitable.

Meta's delivery system behaves differently but reaches a similar conclusion. It optimizes toward events it can observe. A slow page delays or loses those events, the algorithm gets a thinner signal, and delivery drifts toward whatever else is producing conversions. You end up blaming creative when the real constraint is the delivery layer.

This is why speed and server-side attribution should be fixed in the same quarter. One improves the experience; the other improves the platform's ability to see it.

The CAC math most teams skip

Here is a deliberately simple model. Same spend, same traffic, better conversion rate after a speed fix.

A 35-basis-point conversion-rate improvement cuts CAC by 22.6% with no change in media spend. In this model, that is ₹5,65,000 of avoided acquisition cost per month. The engineering work might cost a fraction of that once.

The counter-argument is usually "our conversion rate is already fine". Check it against the right baseline. If your landing page converts at 1.2% on desktop and 0.4% on mobile, the blended number hides the actual problem. Segment by device, connection type, and campaign before deciding that speed is not the constraint.

There is a second-order effect too: faster pages allow more creative variants to be tested in the same budget. A page that renders in 400ms can absorb traffic from a new hook without the bounce rate destroying the read. That compounds over a quarter.

Four fixes that move both metrics

Most of the gain comes from a small number of changes. We start with these before proposing a rebuild.

1. Move the origin closer, or remove it from the critical path

If TTFB is above 600ms, the server is usually doing work it does not need to do on every request: database queries, session lookups, personalization, or a monolithic CMS render. Cache the page at the edge, prerender marketing routes, and move personalization to the client after the shell loads. For content sites, static generation with on-demand revalidation is usually the highest-leverage change available.

2. Make the hero independent of JavaScript

The largest contentful element is often an image, a video poster, or a headline. If any of those depend on a client-side framework hydrating, LCP inherits the entire JavaScript budget. Server-render the hero, preload the image, set explicit dimensions, and serve the correct size for the viewport.

3. Audit third-party scripts like media spend

Tag managers, chat widgets, heatmaps, A/B testing tools, and consent banners all compete for the main thread. We inventory every script, assign an owner, and remove anything that cannot justify its cost in conversion or attribution. A tag that adds 300ms of blocking time needs to be worth more than the conversions it costs.

4. Stabilize layout and interaction

CLS and INP are not just Core Web Vitals checkboxes. A page that shifts while the user is trying to tap a CTA produces misclicks and abandonment. Reserve space for images and embeds, avoid injecting banners above the fold, and break up long tasks that block the main thread.

Instrument RUM before you refactor

Lab tools are useful for diagnosis, but they do not represent your users. Before changing anything, install real-user monitoring that captures:

• TTFB, LCP, CLS, and INP at p50, p75, and p95.
• Device class, connection type, country, and campaign source.
• Landing page and template, not just the site average.
• Conversion event timing, so you can see how speed relates to outcome.

Segment by campaign. A page that performs well for organic desktop traffic may be failing for the mobile paid cohort that represents most of your acquisition budget. If your analytics cannot join speed data to conversion data, fix that first. Otherwise you are optimizing in the dark.

We use a lightweight RUM beacon plus GA4 or warehouse events, with a dashboard that shows speed and conversion side by side. The point is not a prettier report. It is a shared language between engineering and media buying.

A 30-day speed sprint

Speed work drifts when it is treated as a background chore. We scope it like a media sprint: one hypothesis, one metric, one ship date.

Week 1 — baseline and triage

• Pull field data by template, device, and campaign.
• Identify the three templates responsible for the most paid sessions.
• Run a waterfall on the worst-performing template and list the blocking requests.

Week 2 — server and hero

• Cache or prerender the top templates at the edge.
• Preload the hero image and font; remove render-blocking CSS where possible.
• Ship a canary and compare p75 TTFB and LCP against the baseline.

Week 3 — third parties and interaction

• Remove or defer non-critical tags.
• Reserve layout space and fix the largest shift sources.
• Break up long tasks on the main thread.

Week 4 — readout and next constraint

• Compare conversion rate and CAC for the affected campaigns.
• Document what changed, what did not, and what the next bottleneck is.
• Fold the winning patterns into the component library so the next page inherits them.

The sequencing matters more than any single number. Fix the experience first, confirm that conversion tracking still fires correctly, then compare CAC for the affected campaigns. If several things changed at once — a new page, new creative, and a new attribution setup — you will not know which one moved the number. Change one layer, measure, then change the next.

What not to do

• Do not chase a perfect Lighthouse score. A 100 in the lab with poor field data is a vanity result. Optimize p75 field metrics for paid cohorts.
• Do not rebuild the whole site to fix TTFB. Edge caching, prerendering, and query elimination usually solve most of it.
• Do not add a speed tool without an owner. Dashboards do not reduce latency. Someone has to ship the fix.
• Do not treat speed as a one-time project. Every new tag, hero video, and personalization script adds weight. Budget for regression control.
• Do not separate speed from media reporting. If the media team cannot see the conversion impact, the work will always lose priority to a campaign launch.

The practical takeaway is simple. Your landing page is part of your bid. Every 100ms between click and usable page is a tax on the acquisition model. Fix the server, fix the hero, remove the tags that do not earn their keep — then measure the CAC line, not the Lighthouse circle.

If you want a second opinion, request a proposal. Tell us which templates carry the most paid traffic, and we will explain what we would review first and what a website engagement would cover.