ลด TTFB ให้ต่ำกว่า 200ms: Guide 2026

เอาตรง ๆ นะครับ ถ้าคุณกำลังปวดหัวกับเรื่องเว็บโหลดช้า ผมแนะนำให้เริ่มจากตัวเลขเดียวก่อนเลย — Time to First Byte (TTFB) มันคือเวลาตั้งแต่เบราว์เซอร์ส่งคำขอไป จนได้รับไบต์แรกกลับมาจากเซิร์ฟเวอร์ และมันคือ "เพดาน" ของประสิทธิภาพเว็บทั้งหมดอย่างแท้จริง เพราะถ้า TTFB ช้า เมตริกอื่น ๆ อย่าง LCP, FCP หรือ INP มันก็ช้าตามไปหมดแหละครับ ในปี 2026 Google ยังคงแนะนำให้ TTFB อยู่ที่ 800ms หรือต่ำกว่า สำหรับเกณฑ์ "Good" แต่ถ้าดูเว็บไซต์ระดับโลกจริง ๆ เขาทำกันต่ำกว่า 200ms กันเป็นเรื่องปกติ

บทความนี้ผมจะพาไปดูเทคนิคล่าสุดในการลด TTFB ตั้งแต่ Edge Computing, 103 Early Hints, Streaming SSR ไปจนถึงการ Optimize Database Query และ Connection Pooling — พร้อมโค้ดตัวอย่างที่ผมเอาไปใช้งานจริงในโปรเจกต์ได้เลย

TTFB คืออะไร และมันประกอบด้วยอะไรกันแน่

เรื่องที่หลายคนเข้าใจผิดคือคิดว่า TTFB เป็นเมตริกเดี่ยว ๆ — แต่จริง ๆ แล้วมันเป็นผลรวมของหลายขั้นตอนที่เกิดขึ้นก่อนเบราว์เซอร์จะได้รับ HTML ตัวแรกครับ ตามมาตรฐาน Navigation Timing API ของ W3C ปี 2026 TTFB ประกอบด้วย:

Redirect time — เวลาที่ใช้ในการ redirect (ถ้ามี)
Service Worker startup — เวลาที่ Service Worker เริ่มทำงาน
DNS lookup — เวลาในการแปลงโดเมนเป็น IP address
TCP handshake — การสร้างการเชื่อมต่อ TCP (ถ้าเป็น HTTP/3 ก็จะใช้ QUIC แทน)
TLS negotiation — การเจรจา certificate และ encryption
Request — เวลาส่งคำขอไปยังเซิร์ฟเวอร์
Server processing — เวลาที่เซิร์ฟเวอร์ประมวลผล (ส่วนใหญ่งานหนักอยู่ตรงนี้)
Response — เวลาส่งไบต์แรกกลับมา

การวัด TTFB ที่แม่นยำในเบราว์เซอร์ทำได้ผ่าน Performance API แบบนี้ครับ:

// วัด TTFB ด้วย PerformanceObserver
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const ttfb = entry.responseStart - entry.requestStart;
    const fullTTFB = entry.responseStart - entry.startTime;
    console.log('Pure server TTFB:', ttfb, 'ms');
    console.log('Full TTFB (including connection):', fullTTFB, 'ms');
  }
}).observe({ type: 'navigation', buffered: true });

เกณฑ์ TTFB ที่ควรตั้งเป้าในปี 2026

ตามข้อมูลล่าสุดจาก Chrome User Experience Report (CrUX) และ web.dev เกณฑ์ TTFB แบ่งเป็น 3 ระดับครับ:

Good: น้อยกว่า 800ms (เกณฑ์ขั้นต่ำที่ Google แนะนำ)
Needs Improvement: 800ms – 1800ms
Poor: มากกว่า 1800ms

แต่อย่าเพิ่งดีใจไปนะครับว่าผ่าน 800ms แล้วจบ — ความจริงคือ ถ้าคุณอยากได้ LCP ที่ดี (น้อยกว่า 2.5 วินาที) ในตลาดที่แข่งขันสูง คุณควรตั้งเป้า TTFB ไว้ที่ 200–400ms เพื่อให้เหลือเวลาเพียงพอสำหรับโหลด CSS, JavaScript และ render LCP element ครับ

เทคนิคที่ 1: Edge Computing และ Edge Functions

Edge Computing คือการรันโค้ดให้ใกล้กับผู้ใช้มากที่สุด แทนที่จะรันบนเซิร์ฟเวอร์กลางที่อาจอยู่อีกซีกโลก (ลองคิดดูว่าลูกค้าคุณอยู่กรุงเทพ แต่เซิร์ฟเวอร์อยู่ที่เวอร์จิเนีย — มันคนละเรื่องเลย) ในปี 2026 ผู้ให้บริการ Edge หลัก ๆ ก็ยังเป็น Cloudflare Workers, Vercel Edge Functions, AWS Lambda@Edge, Netlify Edge Functions และ Deno Deploy

จากประสบการณ์ส่วนตัว ผมเคยย้ายระบบหนึ่งจาก origin เดียวที่สิงคโปร์ไปใช้ Edge แล้ว TTFB ลดลงเกือบ 70% ทันที ตัวอย่าง Edge Function ด้วย Cloudflare Workers ที่ผมใช้บ่อย ๆ:

// cloudflare-worker.js
export default {
  async fetch(request, env, ctx) {
    const cache = caches.default;
    const cacheKey = new Request(request.url, request);

    // ลองดึงจาก cache ก่อน
    let response = await cache.match(cacheKey);

    if (!response) {
      // สร้าง response แบบ streaming
      response = await fetch(request);
      response = new Response(response.body, response);
      response.headers.set('Cache-Control', 'public, max-age=3600');

      // เก็บใน cache แบบ async ไม่บล็อค response
      ctx.waitUntil(cache.put(cacheKey, response.clone()));
    }

    return response;
  }
};

ส่วนใครใช้ Next.js 15+ บอกเลยว่าทำง่ายมาก แค่ใส่ runtime กับ region ก็จบ:

// app/api/data/route.ts
export const runtime = 'edge';
export const preferredRegion = ['sin1', 'hnd1', 'icn1']; // เลือก region ใกล้ผู้ใช้

export async function GET(request: Request) {
  const data = await fetch('https://api.example.com/data', {
    next: { revalidate: 60 } // ISR ที่ Edge
  });

  return new Response(await data.text(), {
    headers: {
      'Content-Type': 'application/json',
      'Cache-Control': 's-maxage=60, stale-while-revalidate=300'
    }
  });
}

เทคนิคที่ 2: 103 Early Hints

มาถึงตัวที่ผมชอบที่สุดในปีนี้ — HTTP 103 Early Hints ครับ ฟีเจอร์นี้ Chrome รองรับเต็มที่ตั้งแต่ปี 2024 และพอมาถึงปี 2026 Safari กับ Firefox ก็รองรับครบแล้ว มันช่วยให้เซิร์ฟเวอร์ส่ง Link headers สำหรับ preload resource ก่อนที่จะส่ง HTML response เต็ม ทำให้เบราว์เซอร์เริ่มดาวน์โหลด CSS, JavaScript, fonts ได้ทันทีโดยไม่ต้องรอ

ตัวอย่างการใช้งานใน Express.js:

// express-early-hints.js
import express from 'express';
const app = express();

app.get('/', (req, res) => {
  // ส่ง 103 Early Hints ก่อน
  res.writeEarlyHints({
    link: [
      '</styles/main.css>; rel=preload; as=style',
      '</fonts/inter.woff2>; rel=preload; as=font; crossorigin',
      '</scripts/app.js>; rel=modulepreload'
    ]
  });

  // จากนั้นค่อยประมวลผลและส่ง response เต็ม
  setTimeout(() => {
    res.send(renderHTML());
  }, 200);
});

ส่วนถ้าใช้ Cloudflare Workers ก็สบายเลยครับ แค่ใส่ Link headers ปกติ Cloudflare จะแปลงเป็น 103 ให้อัตโนมัติ:

// cloudflare-early-hints.js
export default {
  async fetch(request) {
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);

    newResponse.headers.append('Link',
      '</critical.css>; rel=preload; as=style'
    );
    newResponse.headers.append('Link',
      '</hero.webp>; rel=preload; as=image; fetchpriority=high'
    );

    return newResponse;
  }
};

ผลลัพธ์ก็น่าทึ่งทีเดียว — Shopify เคยทดสอบในปี 2025 แล้วพบว่า 103 Early Hints ลด LCP ได้เฉลี่ย 1.2 วินาทีสำหรับหน้า e-commerce ที่ใช้ critical CSS และ web fonts จำนวนมาก (1.2 วินาทีนี่ในโลก performance ถือว่าเยอะมากนะครับ)

เทคนิคที่ 3: Streaming SSR (Server-Side Rendering)

Streaming SSR คือการส่ง HTML เป็น chunks แทนที่จะรอให้ render เสร็จทั้งหมดก่อน ผลคือ TTFB เร็วขึ้นเยอะ เพราะเบราว์เซอร์ได้รับไบต์แรกทันทีที่เซิร์ฟเวอร์เริ่ม render

ใน React 19 (เวอร์ชันปัจจุบันของปี 2026) เราใช้ renderToPipeableStream หรือไม่ก็ Server Components ตรง ๆ:

// server.js - Streaming SSR ด้วย React 19
import { renderToPipeableStream } from 'react-dom/server';
import App from './App';

app.get('/', (req, res) => {
  const { pipe, abort } = renderToPipeableStream(<App />, {
    bootstrapScripts: ['/main.js'],
    onShellReady() {
      // เริ่ม streaming ทันทีที่ shell พร้อม
      res.statusCode = 200;
      res.setHeader('Content-Type', 'text/html');
      pipe(res);
    },
    onShellError(error) {
      res.statusCode = 500;
      res.send('<!doctype html><p>Error</p>');
    },
    onError(err) {
      console.error(err);
    }
  });

  // Timeout protection
  setTimeout(abort, 10000);
});

ส่วนใน Next.js 15 App Router นั้นง่ายกว่ามาก แค่ใช้ <Suspense> ห่อส่วนที่อยากให้ stream ก็เรียบร้อยแล้ว:

// app/page.tsx
import { Suspense } from 'react';

export default function Page() {
  return (
    <main>
      {/* แสดงทันที */}
      <Header />
      <Hero />

      {/* Stream เมื่อข้อมูลพร้อม */}
      <Suspense fallback={<ProductsSkeleton />}>
        <Products />
      </Suspense>

      <Suspense fallback={<ReviewsSkeleton />}>
        <Reviews />
      </Suspense>
    </main>
  );
}

เทคนิคที่ 4: HTTP Caching ที่มีประสิทธิภาพ

ความจริงข้อหนึ่งที่ผมพูดบ่อย ๆ ก็คือ — การ cache ที่ดีคือการลด TTFB ให้เป็น "เกือบ 0" สำหรับ request ซ้ำเลยครับ มันมีหลายชั้นที่ควรใช้พร้อมกัน

Cache-Control Headers ที่ถูกต้อง

// Static assets - cache ถาวร
Cache-Control: public, max-age=31536000, immutable

// HTML pages - revalidate บ่อย
Cache-Control: public, max-age=0, s-maxage=86400, stale-while-revalidate=604800

// API responses - cache สั้น ๆ
Cache-Control: public, max-age=60, s-maxage=300, stale-if-error=86400

Stale-While-Revalidate Pattern

เทคนิคนี้คือของโปรดเลย — ให้ CDN ส่ง response แบบ cached ทันที (TTFB ใกล้ 0) ในขณะที่ทำการ revalidate ข้อมูลในพื้นหลัง ผู้ใช้คนถัดไปจะได้ข้อมูลใหม่เอง:

Cache-Control: max-age=600, stale-while-revalidate=86400

แปลเป็นภาษาคนก็คือ: cache สด 10 นาที ถ้าหมดอายุแต่ไม่เกิน 24 ชั่วโมง ส่ง stale ไปก่อนเลย แล้วค่อย revalidate ในเบื้องหลัง ผู้ใช้ไม่ต้องรอ

เทคนิคที่ 5: Database Optimization

ถ้าให้ผมเดา 80% ของปัญหา TTFB ที่ผมเจอในงานจริงมาจาก Database query ที่เป็นคอขวดของ Server processing time นั่นแหละครับ เทคนิคที่ใช้ได้ผลในปี 2026:

Connection Pooling

ทุก request ใหม่ที่ต้องสร้าง connection ใหม่จะเสียเวลาประมาณ 50–200ms (ลองคูณด้วยจำนวน request ต่อวันดูสิครับ มันโหดเอาเรื่อง) แนะนำให้ใช้ connection pool อย่าง PgBouncer (Postgres), ProxySQL (MySQL) หรือ Prisma Accelerate:

// Prisma ใน Edge Runtime
import { PrismaClient } from '@prisma/client/edge';
import { withAccelerate } from '@prisma/extension-accelerate';

const prisma = new PrismaClient().$extends(withAccelerate());

export async function GET() {
  const users = await prisma.user.findMany({
    cacheStrategy: { ttl: 60, swr: 300 }, // edge cache
    take: 10
  });
  return Response.json(users);
}

Query Optimization Checklist

เพิ่ม index สำหรับคอลัมน์ที่ใช้ใน WHERE, ORDER BY, JOIN
หลีกเลี่ยง N+1 queries โดยใช้ include หรือ JOIN
ใช้ SELECT เฉพาะคอลัมน์ที่ต้องการ อย่าเผลอใช้ SELECT * เด็ดขาด
ใช้ EXPLAIN ANALYZE เพื่อตรวจสอบ query plan
พิจารณาใช้ materialized views สำหรับ aggregate queries ที่ซับซ้อน

เทคนิคที่ 6: HTTP/3 และ QUIC

HTTP/3 ใช้ QUIC protocol แทน TCP ลด handshake จาก 3 round-trips เหลือ 1 round-trip (และเป็น 0-RTT เลยสำหรับ connection ที่เคยเชื่อมแล้ว) ตอนนี้ผู้ให้บริการหลักทุกราย — Cloudflare, Fastly, AWS CloudFront — รองรับ HTTP/3 หมดแล้ว แทบไม่มีเหตุผลที่จะไม่เปิดใช้

การเปิดใช้บน Nginx 1.25+ ทำได้ตามนี้:

# nginx.conf
http {
  server {
    listen 443 quic reuseport;
    listen 443 ssl;

    ssl_certificate /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;

    # บอก browser ว่าเรารองรับ HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
    add_header QUIC-Status $http3;
  }
}

เทคนิคที่ 7: Compression ที่เหมาะสม

การ compress response ลดขนาดข้อมูลที่ต้องส่งก็จริง แต่ก็เพิ่มเวลา CPU ในการ compress ด้วยนะครับ ต้องบาลานซ์ให้ดี ในปี 2026 Brotli ยังเป็นมาตรฐานหลัก:

# nginx Brotli config
brotli on;
brotli_comp_level 4;  # ระดับ 4 เป็นจุดสมดุลระหว่าง compression ratio กับ CPU
brotli_types
  text/html
  text/css
  application/javascript
  application/json
  image/svg+xml
  font/woff2;
brotli_static on;  # ใช้ pre-compressed files ถ้ามี

ทริกเล็ก ๆ คือ สำหรับ static assets ให้ pre-compress ตอน build time ไปเลย จะได้ไม่ต้อง compress runtime:

# Build script
find ./dist -type f \( -name "*.js" -o -name "*.css" -o -name "*.html" \) \
  -exec brotli -q 11 -k {} \;

การวัดและ Monitor TTFB

เรื่องของการวัดผลนี่สำคัญมากครับ เพราะ "what gets measured gets improved" จริง ๆ ใช้ web-vitals library ของ Google เพื่อวัด TTFB จากผู้ใช้จริง (Real User Monitoring):

import { onTTFB } from 'web-vitals/attribution';

onTTFB((metric) => {
  // ส่งไป analytics
  navigator.sendBeacon('/analytics', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
    waitingDuration: metric.attribution.waitingDuration,
    cacheDuration: metric.attribution.cacheDuration,
    dnsDuration: metric.attribution.dnsDuration,
    connectionDuration: metric.attribution.connectionDuration,
    requestDuration: metric.attribution.requestDuration
  }));
});

เครื่องมืออื่น ๆ ที่ผมใช้เป็นประจำ:

Chrome DevTools Network tab → Timing
WebPageTest สำหรับทดสอบจากหลาย ๆ location
PageSpeed Insights ที่แสดงข้อมูล CrUX
Cloudflare Web Analytics ที่มี TTFB breakdown ละเอียดดี

Checklist สำหรับลด TTFB ในปี 2026

ย้าย rendering logic ไปที่ Edge (Cloudflare Workers, Vercel Edge)
เปิดใช้ HTTP/3 และ QUIC
ส่ง 103 Early Hints สำหรับ critical resources
ใช้ Streaming SSR แทน blocking SSR
ตั้งค่า Cache-Control headers ที่เหมาะสมในทุกชั้น
ใช้ stale-while-revalidate pattern
เปิดใช้ Brotli compression
ใช้ Connection pooling สำหรับ database
เพิ่ม index และ optimize queries ทั้งหมด
Monitor TTFB ด้วย web-vitals library อย่างต่อเนื่อง

คำถามที่พบบ่อย (FAQ)

TTFB ที่ดีในปี 2026 ควรเป็นเท่าไหร่?

Google ยังแนะนำให้ TTFB ต่ำกว่า 800ms เป็นเกณฑ์ "Good" แต่ถ้าอยากจริงจังกว่านั้น ควรตั้งเป้าที่ 200–400ms ครับ เว็บระดับโลกอย่าง Vercel, Cloudflare, GitHub มักทำ TTFB ได้ต่ำกว่า 100ms ด้วยการใช้ Edge Computing เต็มรูปแบบ

TTFB ส่งผลต่อ SEO อย่างไร?

TTFB เป็นปัจจัยทางอ้อมที่ส่งผลต่อ Core Web Vitals — โดยเฉพาะ LCP เพราะ LCP ไม่สามารถเริ่มได้ก่อน TTFB เสร็จ และ Google ก็ใช้ Core Web Vitals เป็นปัจจัยจัดอันดับ ดังนั้นเว็บที่ TTFB ช้าเกินไปอาจไม่ผ่านเกณฑ์ "Good" ของ LCP ส่งผลให้อันดับใน search ลดลงตามไปด้วย

ความแตกต่างระหว่าง TTFB กับ FCP คืออะไร?

TTFB (Time to First Byte) วัดเวลาตั้งแต่ส่ง request จนได้รับไบต์แรกของ response ในขณะที่ FCP (First Contentful Paint) วัดเวลาที่เบราว์เซอร์ render content แรกบนหน้าจอ FCP เกิดขึ้นหลัง TTFB เสมอ และต้องรอ HTML, CSS, fonts ที่จำเป็นสำหรับ render ครั้งแรกด้วย

Edge Computing ลด TTFB ได้จริงหรือ?

ใช่ครับ — Edge Computing ลด TTFB ได้อย่างมีนัยสำคัญ โดยเฉพาะสำหรับผู้ใช้ที่อยู่ห่างจาก origin server การทดสอบจริงพบว่า Edge Functions ลด TTFB ได้ 50–80% สำหรับผู้ใช้ในเอเชียที่เข้าถึงเซิร์ฟเวอร์ในอเมริกา จากเดิมราว 600–800ms เหลือเพียง 100–150ms เท่านั้น

ควรใช้ SSR หรือ SSG เพื่อ TTFB ที่ดีที่สุด?

SSG (Static Site Generation) ให้ TTFB ที่ดีที่สุดเสมอ เพราะเป็นไฟล์ static ที่ cache ได้เต็มที่บน CDN แต่ถ้าต้องการ dynamic content แนะนำให้ใช้ ISR (Incremental Static Regeneration) หรือ SSR with Edge Caching ซึ่งให้ TTFB ใกล้เคียงกับ SSG หลีกเลี่ยง pure SSR ที่ต้อง render ทุก request เพราะ TTFB จะแปรผันตาม server load มาก ๆ

สรุป

การลด TTFB ในปี 2026 ไม่ใช่เรื่องของเทคนิคเดียวครับ แต่เป็นการรวมหลายชั้นเข้าด้วยกัน — Edge Computing เพื่อลด network latency, 103 Early Hints เพื่อให้เบราว์เซอร์เริ่ม preload เร็ว, Streaming SSR เพื่อส่ง HTML ทันที, Caching หลายชั้นเพื่อหลีกเลี่ยงการประมวลผลซ้ำ, Database optimization เพื่อลด server processing และสุดท้าย HTTP/3 เพื่อลด connection overhead

คำแนะนำของผมคือ เริ่มต้นจากการ measure TTFB ปัจจุบันด้วย web-vitals library ก่อน จากนั้นค่อย ๆ ใช้เทคนิคทีละอย่าง วัดผลแต่ละขั้นไปเรื่อย ๆ แล้วคุณจะเห็นเองว่า TTFB ที่ต่ำกว่า 200ms ไม่ใช่เรื่องไกลเกินเอื้อมเลย เอาน่า ลองไปทำดูแล้วเล่าให้ฟังบ้างครับ