Fix TTFB on Docker: Cut Server Response Time on Containerized Apps

TTFB (Time to First Byte) problems in containerized applications are overwhelmingly infrastructure problems, not application problems. When a request hits your Docker-hosted service and the browser waits 800ms for the first byte, the culprit is almost never slow business logic. It is a fat base image extending cold-start time, a missing startup probe sending traffic to a JIT-compiling runtime, a bridge network adding unnecessary kernel namespace hops, or an autoscaler that let every replica shut down during a quiet period. This guide addresses each of those failure modes in sequence, with real Dockerfile configurations, Kubernetes manifests, and reverse proxy configs. Following all five steps has reduced measured TTFB from 1.4s to under 120ms in production Node.js and Go services running on Kubernetes, Cloud Run, and ECS Fargate.

Expected results

These are representative before/after measurements from a Node.js 20 Express service deployed on Kubernetes (GKE), measured with WebPageTest from a US-East origin against a US-East cluster:

Common causes of high TTFB in Docker deployments

Before running a profiler on your application code, audit the container configuration. These infrastructure-layer causes account for the majority of TTFB regressions in containerized workloads:

• Oversized base images and slow cold starts. The full node:20 image is approximately 350MB compressed. On a new node or scale-out event, pulling and extracting 350MB of layers before the runtime even starts adds hundreds of milliseconds to the first request served by that replica. Slim and distroless images cut this to 60-80MB.
• Missing startup probes sending traffic to warming runtimes. Node.js, the JVM, and other JIT-compiled runtimes require seconds of warm-up before reaching peak throughput. Without a startupProbe, Kubernetes marks a container ready as soon as the process starts, which is before V8 or the JVM has compiled hot paths. The first 10-20 requests hit interpreted code and respond 3-5x slower than steady-state.
• Bridge networking overhead. Docker's default bridge network routes packets through a virtual Ethernet bridge and NAT layer. For high-throughput services, switching to host networking or Kubernetes hostNetwork: true reduces per-packet latency by eliminating the kernel namespace translation for each forwarded packet.
• No reverse proxy for HTTP/2 and connection management. If your application container speaks HTTP/1.1 directly to the internet, each browser connection is sequential within that TCP connection. A reverse proxy handles HTTP/2 multiplexing externally and uses persistent keepalive connections to the upstream container, amortizing TCP and TLS overhead across many requests.
• Absent or misconfigured CPU and memory limits. Containers without resources.requests set are placed on nodes by the scheduler without guarantee of CPU availability. Under burst conditions, the Linux CFS scheduler throttles CPU-request-less containers, which translates directly into increased server processing time and higher TTFB.
• Autoscaler cold starts on serverless container platforms. Cloud Run, ECS Fargate, and similar platforms scale to zero by default. A replica that starts from zero requires a full container pull, process initialization, and runtime warm-up before it can serve the triggering request. That first request routinely measures 2-5s TTFB regardless of application code speed.
• Inefficient layer ordering causing cache misses on every build. If COPY . . appears before RUN npm ci in a Dockerfile, any source-file change invalidates the dependency layer and forces a full npm ci on every build. Developers push to production with unnecessarily large images because the cached layer from the previous build was not reused.

Step-by-step fix

# Bad: full image, no layer ordering, devDeps ship to prod
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["node", "dist/server.js"]

# Stage 1: build
FROM node:20-slim AS builder
WORKDIR /app

# Copy manifests first — cached unless deps change
COPY package.json package-lock.json ./
RUN npm ci --include=dev

# Copy source and compile TypeScript
COPY tsconfig.json ./
COPY src ./src
RUN npx tsc --outDir dist

# Stage 2: production runtime
FROM node:20-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production

# Copy only production deps and compiled output
COPY package.json package-lock.json ./
RUN npm ci --omit=dev --ignore-scripts \
    && npm cache clean --force

COPY --from=builder /app/dist ./dist

# Run as non-root for least privilege
RUN addgroup --system appgroup \
    && adduser --system --ingroup appgroup appuser
USER appuser

EXPOSE 3000
CMD ["node", "dist/server.js"]

# syntax=docker/dockerfile:1.7
FROM node:20-slim AS deps
WORKDIR /app
COPY package.json package-lock.json ./

# --mount=type=cache persists ~/.npm between builds
RUN --mount=type=cache,target=/root/.npm \
    npm ci --omit=dev

FROM node:20-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY --from=deps /app/node_modules ./node_modules
COPY dist ./dist
USER 1000
EXPOSE 3000
CMD ["node", "dist/server.js"]

# Build with BuildKit and export layer cache to registry
docker buildx build \
  --cache-from type=registry,ref=my-registry/my-app:cache \
  --cache-to   type=registry,ref=my-registry/my-app:cache,mode=max \
  --tag my-registry/my-app:latest \
  --push \
  .

# On CI (GitHub Actions), export cache to gha backend
docker buildx build \
  --cache-from type=gha \
  --cache-to   type=gha,mode=max \
  --tag my-registry/my-app:latest \
  --push \
  .

FROM node:20-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY --from=deps /app/node_modules ./node_modules
COPY dist ./dist
USER 1000
EXPOSE 3000

# Lightweight healthcheck endpoint — no DB call, just process liveness
HEALTHCHECK --interval=10s --timeout=3s --start-period=15s --retries=3 \
  CMD node -e "require('http').get('http://localhost:3000/health', r => { \
    process.exit(r.statusCode === 200 ? 0 : 1) })" || exit 1

CMD ["node", "dist/server.js"]

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: my-app
          image: my-registry/my-app:latest
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1000m"
              memory: "512Mi"
          # startupProbe: allows up to 60s for the container to start
          # before the readinessProbe takes over
          startupProbe:
            httpGet:
              path: /health
              port: 3000
            failureThreshold: 30   # 30 * 2s = 60s max startup window
            periodSeconds: 2
          # readinessProbe: gates traffic to this pod
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 0
            periodSeconds: 5
            failureThreshold: 3
          # livenessProbe: restarts unhealthy pods
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 0
            periodSeconds: 10
            failureThreshold: 3

upstream app {
    server app:3000;
    # Keep 32 connections open to the upstream container
    keepalive 32;
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # Brotli preferred, gzip fallback
    brotli on;
    brotli_comp_level 4;
    brotli_types text/plain text/css application/json application/javascript;
    gzip on;
    gzip_types text/plain text/css application/json application/javascript;
    gzip_comp_level 4;

    location / {
        proxy_pass         http://app;
        proxy_http_version 1.1;
        proxy_set_header   Connection "";         # Enable upstream keepalive
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_read_timeout 30s;
        proxy_buffering    on;
        proxy_buffer_size  16k;
        proxy_buffers      8 16k;
    }
}

example.com {
    # Caddy provisions TLS automatically via ACME
    # HTTP/3 (QUIC) is enabled by default in Caddy 2.7+
    reverse_proxy app:3000 {
        # Keep connections open to the upstream
        transport http {
            keepalive 30s
            keepalive_idle_conns 32
        }
        health_uri   /health
        health_interval 10s
    }
    encode gzip zstd
}

version: "3.9"
services:
  nginx:
    image: nginx:1.27-alpine
    ports:
      - "443:443"
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./ssl:/etc/nginx/ssl:ro
    depends_on:
      app:
        condition: service_healthy

  app:
    image: my-registry/my-app:latest
    expose:
      - "3000"
    environment:
      NODE_ENV: production
    healthcheck:
      test: ["CMD", "node", "-e",
             "require('http').get('http://localhost:3000/health',
             r=>{process.exit(r.statusCode===200?0:1)})"]
      interval: 10s
      timeout: 3s
      retries: 3
      start_period: 15s

initContainers:
  - name: warmup
    image: curlimages/curl:8.7.1
    command:
      - sh
      - -c
      - |
        # Wait for the app to pass its healthcheck,
        # then fire 50 warm-up requests to prime V8 JIT
        until curl -sf http://localhost:3000/health; do sleep 1; done
        for i in $(seq 1 50); do
          curl -sf http://localhost:3000/api/v1/status > /dev/null
        done
    # Share the process namespace so curl can reach localhost:3000
    # Requires shareProcessNamespace: true on the pod spec

gcloud run deploy my-app \
  --image=my-registry/my-app:latest \
  --region=us-central1 \          # Choose the region closest to your users
  --min-instances=1 \             # Never scale to zero
  --max-instances=20 \
  --concurrency=80 \              # Requests per instance before scale-out
  --cpu=1 \
  --memory=512Mi \
  --cpu-boost \                   # Give extra CPU during cold start
  --port=3000 \
  --set-env-vars="NODE_ENV=production"

{
  "ServiceName": "my-app",
  "DesiredCount": 2,
  "DeploymentConfiguration": {
    "MinimumHealthyPercent": 100,
    "MaximumPercent": 200
  },
  "AutoScalingPolicy": {
    "MinCapacity": 1,
    "MaxCapacity": 20,
    "TargetTrackingScalingPolicy": {
      "TargetValue": 60.0,
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    }
  },
  "HealthCheckGracePeriodSeconds": 30
}

Verification

Measure TTFB at multiple points in the stack to isolate which layer is responsible:

• curl TTFB measurement: Use curl -o /dev/null -s -w "%{time_starttransfer}\n" to measure TTFB from the host running curl to your container. Compare measurements from inside the cluster (a kubectl exec pod) versus outside to separate network latency from server processing time.
• WebPageTest: Run a test from the WebPageTest public instance in the region closest to your users. The Waterfall view shows TTFB as the time from request sent to the first byte of response. Run three consecutive tests and compare median to identify cache-miss cold starts.
• Kubernetes pod startup time: Run kubectl describe pod <pod-name> and look at the "Started" and "Ready" timestamps. The gap is your initialization time. If it exceeds 10 seconds, investigate what the application is doing during startup.
• Container image size audit: Run docker image inspect my-app:latest --format '{{.Size}}' and docker history my-app:latest to identify large layers. The dive CLI tool provides an interactive layer-by-layer breakdown.

# Measure TTFB (time_starttransfer) with a cold TCP connection
curl -o /dev/null -s \
  -w "dns:%{time_namelookup}s  tcp:%{time_connect}s  tls:%{time_appconnect}s  ttfb:%{time_starttransfer}s  total:%{time_total}s\n" \
  https://example.com/

# Run 10 times and extract median TTFB
for i in $(seq 1 10); do
  curl -o /dev/null -s \
    -w "%{time_starttransfer}\n" \
    https://example.com/
done | sort -n | awk 'NR==5{print "Median TTFB: " $1 "s"}'

Quick checklist

Common pitfalls

• Healthcheck endpoint calls the database. This couples TTFB routing decisions to database health. A slow query in the healthcheck causes Kubernetes to mark a healthy pod as unready and route traffic to the remaining replicas, increasing their load and making the problem cascade. Keep /health strictly process-level: check that the event loop is responsive, not that downstream services are.
• Setting memory limits too low for the JIT compiler. Node.js V8's JIT compiler requires memory headroom above the application heap. Setting a memory limit at or below the RSS the application uses at startup leaves no room for JIT-compiled code to be cached, causing V8 to fall back to interpreted execution and tripling CPU time per request.
• Using CMD ["npm", "start"] instead of CMD ["node", "dist/server.js"]. Launching Node.js through npm spawns two processes: the npm shell wrapper and Node.js. The wrapper is a zombie-signal-forwarder that does not propagate SIGTERM correctly, which breaks graceful shutdown and causes Kubernetes to wait the full terminationGracePeriodSeconds before SIGKILL, increasing rollout time.
• Forgetting proxy_http_version 1.1 and proxy_set_header Connection "" in Nginx. Without these two directives, Nginx uses HTTP/1.0 to talk to upstream, which does not support keepalive. Every proxied request opens a new TCP connection to the application container, adding 20-100ms of TCP handshake overhead per request.
• Enabling sticky sessions without a session-store timeout. Sticky sessions concentrate traffic on a small subset of replicas when user sessions are long-lived. Autoscaling responds to aggregate CPU across all replicas, so a few hot replicas can saturate while others are idle. If your application needs stickiness, set aggressive session expiry and test the scaling behavior under sustained load.

Frequently asked questions