Drag
Octotek Logo

Cursor

mode

0

Get in touch

shapeshape

Blog Sep 12, 2025

How We Cut TTFB by 60% on a Houston SaaS

octotek-logo

Written by OctoTEK

Sep 12, 2025

5 min read

How We Cut TTFB by 60% on a Houston SaaS

Table of Contents

  1. Why TTFB is the silent growth killer
  2. Baseline: how we measured (and what we saw)
  3. Quick wins that moved the needle immediately
  4. Deep fixes at the edge and origin
  5. Rendering strategy: SSR to ISR (and when not to)
  6. Database & API latency: eliminating the long tail
  7. Results and dashboards
  8. The 20‑point TTFB checklist
  9. FAQs

1) Why TTFB is the silent growth killer

TTFB is the time from a browser’s request to the first byte returned by your server (or CDN). It governs everything downstream:

  • Higher TTFB → slower LCP & INP → lower conversions.
  • Search engines use speed signals; better TTFB improves crawl efficiency and Core Web Vitals.
  • Support load drops when pages feel instant.

2) Baseline: how we measured (and what we saw)

We started with a Houston‑based B2B SaaS handling ~1.2M monthly requests.

Tooling

  • Synthetic: WebPageTest, Lighthouse CI, k6 for load, curl -w for low‑level timing.
  • RUM: First‑party JS capturing TTFB/LCP by geography and device.
  • Server: Origin logs (NGINX), APM spans (Node.js), DB tracing (Postgres).

Initial findings (p95):

  • TTFB: 780 ms US‑South; >1.1 s on EU visitors.
  • Handshake tax: 2–3 round trips on cold connections; old TLS 1.2.
  • Cache misses: Dynamic pages sharing cache keys with auth’d traffic → low CDN hit ratio.
  • Origin latency: Unpooled DB connections + unindexed filters → 300–500 ms DB time.
  • SSR hot path: Every visit rendered afresh, even for content that changes hourly.

3) Quick wins (week 1)

  1. TLS 1.3 + HTTP/3 (QUIC) enabled at the CDN; 0‑RTT resumption for repeat visitors.
  2. Preconnect & DNS‑prefetch to critical third‑party domains.
  3. Brotli compression for text assets; immutable caching for versioned files.
  4. Cache‑key isolation: separated anonymous vs. authenticated traffic; turned on origin shield.
  5. Priority hints (<link rel="preload"> and fetchpriority) for fonts & hero CSS.

Sample headers

# For edge caching of HTML for logged‑out users
Cache-Control: max-age=0, s-maxage=86400, stale-while-revalidate=604800Vary: Cookie, Authorization
<!-- In <head> -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="preload" as="style" href="/styles/hero.css" />

4) Deep fixes at the edge and origin (weeks 2–3)

4.1 Edge/CDN

  • Route to nearest PoP and use origin shield to collapse misses.
  • 103 Early Hints from the CDN to stream critical Link headers sooner.
  • HTTP/3 default; H2 fallback; disable deprecated server push.

4.2 NGINX origin tuning

# HTTPS & HTTP/3 (if supported by your build)
ssl_protocols TLSv1.3;
ssl_early_data on; # enable resumption/0‑RTT where safe

# Keep‑alive & buffers
keepalive_timeout 65;
keepalive_requests 1000;
client_body_buffer_size 64k;
# Brotli (requires module)brotli on; brotli_comp_level 5; brotli_types text/plain text/css application/javascript application/json application/xml;

4.3 Node.js + Postgres

  • Put PgBouncer in transaction mode; cap pool oversubscription.
  • Add composite indexes for top filters; remove N+1 joins in hot paths.
  • Memoize config lookups; cache feature flags for 60 s.

// node-postgres pool sizing (example)
import { Pool } from 'pg';
export const pool = new Pool({
max: 20, // match to CPU & PgBouncer limits
idleTimeoutMillis: 10000,
connectionTimeoutMillis: 2000
});

5) Rendering strategy: from SSR to ISR

Heavy, mostly‑static pages were moved from full SSR to ISR (Incremental Static Regeneration) with selective revalidation.

// Next.js App Router (Next 14/15)
export const revalidate = 300; // 5 minutes
async function getData() {
const res = await fetch("https://api.example.com/products", {
next: { revalidate: 300 }
});
return res.json();
}
export default async function Page() {
const data = await getData();
return <Products data={data} />;
}

Rules of thumb

  • Logged‑out marketing pages: cache HTML at edge (seconds–minutes) → huge TTFB wins.
  • Dashboard/API pages: optimize origin (pooling, indices) + partial SSR; avoid blocking on slow third‑parties.
  • Feature flags: don’t block render; hydrate progressively.

6) Database & API latency: killing the long tail

  • Slow query log turned on; top 10 offenders refactored.
  • Switched pricing service calls to bulk endpoints.
  • Enabled connection reuse and HTTP keep‑alive end‑to‑end.
  • Backed off rate‑limited vendors to a background sync; read from cache on first paint.

7) Results

Before → After (p95):

MetricBeforeAfterChangeTTFB (US‑South)780 ms310 ms−60%TTFB (EU)1.12 s520 ms−54%LCP (marketing)3.6 s2.1 s−41%Backend response820 ms340 ms−59%CDN hit ratio62%88%+26 ptsConversions—+7.8%liftCrawl throughput—+38%pages/day

We validated with RUM and synthetic runs across Houston, Dallas, Chicago, London.

The biggest lever: cacheable HTML for logged‑out traffic + HTTP/3.

8) The 20‑Point TTFB Checklist

Network & Edge

  1. TLS 1.3 everywhere; enable session resumption; prefer HTTP/3.
  2. Preconnect to critical third‑parties; prioritize fonts/CSS.
  3. Separate cache keys for authed vs. anon; add origin shield.
  4. Set s-maxage & stale-while-revalidate on cacheable HTML.
  5. Turn on 103 Early Hints; remove HTTP/2 server push.

Origin 6. Keep‑alive high; reasonable buffer sizes; Brotli for text. 7. Use PgBouncer; right‑size Node pool; cap concurrent queries. 8. Add indexes for top WHEREs/ORDER BYs; kill N+1s. 9. Memoize config/flags; cache API reads; batch external calls. 10. Avoid cold starts on serverless (provisioned concurrency for hot routes).

Rendering 11. Move heavy SSR pages to ISR with short revalidate. 12. Avoid blocking on 3rd‑party scripts; defer & async. 13. Stream HTML where possible; flush early.

Observability 14. RUM: collect TTFB/LCP by geo/device. 15. Synthetic: WebPageTest profiles per market. 16. APM: trace spans from CDN → origin → DB. 17. Alert on p95 TTFB regressions, not just averages.

Process 18. Performance budgets in CI for HTML weight & TTFB. 19. Load‑test before launches; capture cache warm/cold. 20. Post‑deploy verification against last 7 days.

9) FAQs

What’s a good TTFB?

  • Aim for <200 ms on cached HTML in your primary region; <500 ms globally via CDN.

Does TTFB affect SEO?

  • Indirectly via Core Web Vitals and crawl efficiency. Faster TTFB improves LCP and discovery.

Is 0‑RTT safe?

  • It trades replay risk for speed. Restrict to idempotent routes (GET) and avoid sensitive endpoints.

Will this help SPAs?

  • Yes. Even JS‑heavy apps benefit from edge caching for HTML, faster handshake, and API latencies.

How OctoTEK can help

  • Performance audit (2 weeks): deep dive on edge/origin/rendering.
  • Implementation sprint: hands‑on with your team.
  • Enablement: dashboards, budgets, and playbooks.

Ready to drop your TTFB by 50–70%? Book a free consult

Tags:Blog

octotek-logo

OctoTEK

OctoTEK (Technology Empowerment Kinetics) is aforward-thinking software development companydedicated to transforming businesses withcutting-edge technology solutions. With close to adecade of experience, we specialize in enterprisesolutions, web and mobile applications, cloudcomputing, data engineering, AI, machine learning,and website design and development. Known for ourinnovative approach, strategic vision, and highlyskilled team, we deliver custom solutions, rapidprototyping, and quality assurance.

Related Articles

Start Your Project

Ready to transform your ideas into powerful software solutions?

Let's discuss your project