TTFB คืออะไร? วิธีลด Time To First Byte ต่ำกว่า 200ms ปี 2026

ลองนึกภาพว่าคุณกำลังต่อแถวซื้อกาแฟ คุณยืนรออยู่หน้าเคาน์เตอร์ บาริสต้ารับออเดอร์แล้ว แต่กลับเดินไปทำอย่างอื่นเสียก่อน 2 นาที ค่อยกลับมาเริ่มชงกาแฟ — ความรู้สึกของผู้ใช้ที่กำลังรอเว็บไซต์ของคุณโหลดก็เหมือนกันเป๊ะ ๆ เพราะ TTFB (Time to First Byte) คือช่วงเวลานั้น คือช่วงที่ browser ส่ง request ไปแล้ว และยืนรอ server ตอบกลับ byte แรก ถ้า server ของคุณใช้เวลา 2 วินาทีถึงจะส่ง byte แรกออกมา ไม่ว่าคุณจะ optimize อะไรหลังจากนั้น — minify CSS, lazy load image, preload font — ผู้ใช้ก็เห็นจอขาวเปล่า ๆ ไปแล้ว 2 วินาที

ในปี 2026 Google ใช้ Core Web Vitals เป็น ranking signal อย่างเป็นทางการมา 4 ปีเต็ม และ TTFB คือฐานรากของทุก metric ที่เหลือ ทุกอย่างไม่ว่าจะเป็น LCP, FCP, INP มันรอ TTFB ตอบกลับก่อนถึงจะเริ่มทำงานได้ ถ้า TTFB ของคุณ 1.5 วินาที LCP ที่ดีที่สุดที่คุณทำได้ก็คือ 1.5 วินาทีบวก time-to-render — ซึ่งเกินเกณฑ์ “Good” ของ Core Web Vitals (2.5s) แทบจะแน่นอนสำหรับเว็บที่มี content ปานกลางขึ้นไป

บทความนี้คุณจะได้เรียนรู้ทุกอย่างเกี่ยวกับ TTFB ตั้งแต่นิยามทางเทคนิค องค์ประกอบที่ทำให้ TTFB ช้า เครื่องมือวัด และที่สำคัญที่สุด — 12 เทคนิคจริงที่ทีม Southern Whale ใช้ลด TTFB ของลูกค้าจาก 1.8 วินาที เหลือ 180 มิลลิวินาที พร้อม code config จริง ๆ ที่คุณ copy ไปใช้ได้ทันที ไม่ว่าจะใช้ WordPress, Laravel, Astro หรือ Next.js

TTFB คืออะไรกันแน่?

TTFB หรือ Time to First Byte คือ “ระยะเวลาตั้งแต่ browser ส่ง HTTP request ออกไป จนกระทั่งได้รับ byte แรกของ response กลับมา” Google นิยามไว้อย่างเป็นทางการในเอกสาร web.dev และใช้เป็น metric หนึ่งใน Lighthouse, CrUX (Chrome User Experience Report) และ PageSpeed Insights

ความเข้าใจผิดที่พบบ่อยคือ คนคิดว่า TTFB = Server Processing Time อย่างเดียว ซึ่งไม่ถูก เพราะ TTFB จริง ๆ ครอบคลุม 4 ช่วงเวลา:

DNS Lookup — เวลาที่ browser แปลง domain (example.com) เป็น IP address
TCP Handshake — การจับมือ 3 ขั้นตอน (SYN → SYN-ACK → ACK) เพื่อสร้าง connection
TLS Negotiation — การแลกเปลี่ยน certificate และตกลง encryption key (เฉพาะ HTTPS)
Server Processing + First Byte — เวลาที่ server ใช้ประมวลผล request และส่ง byte แรกออกมา

ทั้งหมดนี้รวมกันคือ TTFB ที่ผู้ใช้ “รู้สึก” ได้จริง ๆ ดังนั้นการ optimize TTFB ไม่ใช่แค่การทำให้ server เร็วขึ้น แต่รวมถึงการลดเวลาในทุกขั้นตอนของการ “เชื่อมต่อ” ก่อนที่ server จะเริ่มทำงานด้วย

เกณฑ์ TTFB ตามมาตรฐาน Google

Google ได้กำหนดเกณฑ์ TTFB ที่ใช้อ้างอิงในระดับสากล โดยอิงข้อมูลจาก CrUX ของเว็บไซต์ทั่วโลก:

ระดับ	TTFB	คำอธิบาย
Good (ดี)	< 800ms	ผ่านเกณฑ์ Core Web Vitals สำหรับ TTFB
Needs Improvement	800ms – 1800ms	ใช้งานได้ แต่ควร optimize เพิ่ม
Poor (แย่)	> 1800ms	ส่งผลเสียต่อ SEO อย่างชัดเจน
Ideal Target (เป้าหมายเว็บพรีเมียม)	< 200ms	ระดับ enterprise / e-commerce

แต่ Southern Whale แนะนำลูกค้าเสมอว่าอย่ายึดแค่ “Good” — เพราะตัวเลข 800ms นั้นเป็นค่ามาตรฐานสำหรับเว็บส่วนใหญ่ที่ใช้ shared hosting หรือไม่มี CDN ถ้าคุณทำธุรกิจที่ลูกค้า conversion rate มีความสำคัญสูง เช่น e-commerce, lead generation, หรือ news site เป้าหมายที่ควรตั้งคือ < 200ms สำหรับ cached pages และ < 600ms สำหรับ dynamic pages

งานวิจัยจาก Akamai และ Amazon เก่ากว่าทศวรรษพบว่า ทุก ๆ 100ms ของ latency ที่เพิ่มขึ้น ทำให้ conversion rate ลดลง 1% ในบริบทของ TTFB หมายความว่าถ้าคุณลด TTFB จาก 1.2s เหลือ 200ms (1,000ms) คุณอาจเพิ่ม conversion ได้ถึง 10% โดยไม่ต้องเปลี่ยน design หรือ copy เลย

TTFB Breakdown: เกิดอะไรขึ้นใน 4 ช่วงนี้

เพื่อให้คุณเข้าใจว่าควร optimize ตรงไหน ลองมาดู timeline จริงของการ request เว็บไซต์หนึ่งครั้ง:

0ms ─── User คลิก link
  │
  ├─ 0-50ms     DNS Lookup (resolve example.com → 203.0.113.5)
  │
  ├─ 50-100ms   TCP Handshake (SYN → SYN-ACK → ACK)
  │
  ├─ 100-300ms  TLS Negotiation (Certificate + Key Exchange)
  │
  ├─ 300-1500ms Server Processing (PHP + MySQL + Application)
  │
  └─ 1500ms     First Byte received → TTFB = 1500ms

1. DNS Lookup (ปกติ 20–120ms)

ทุกครั้งที่ browser เห็น domain ใหม่ มันจะต้องไปถาม DNS server ว่า IP คืออะไร ถ้า DNS provider ของคุณช้า (เช่นใช้ DNS ฟรีของ registrar ทั่วไป) อาจกินเวลาได้ถึง 200ms+ — แต่ถ้าใช้ Cloudflare DNS หรือ Route53 มักจะอยู่ที่ 10–30ms

2. TCP Handshake (ปกติ 30–100ms)

3-way handshake ใช้เวลาเท่ากับ 1.5 RTT (Round-Trip Time) ระหว่าง client กับ server ถ้า server ของคุณอยู่สิงคโปร์ และ user อยู่กรุงเทพฯ RTT ประมาณ 40ms = TCP handshake ใช้เวลา ~60ms แต่ถ้า server อยู่ US East Coast RTT ประมาณ 220ms = TCP handshake กิน 330ms ทันที

3. TLS Negotiation (ปกติ 100–400ms ถ้าไม่ใช้ 0-RTT)

TLS 1.2 ใช้ 2 RTT, TLS 1.3 ใช้ 1 RTT, และถ้าเปิด 0-RTT (Zero Round Trip Time Resumption) สำหรับ returning visitors จะลดเหลือ 0 RTT เลย — แต่ต้องระวังเรื่อง replay attack สำหรับ POST request

4. Server Processing (ส่วนใหญ่ของปัญหาอยู่ตรงนี้)

ในเว็บไซต์ที่ไม่ได้ optimize ขั้นนี้กินเวลา 500ms ถึงหลายวินาที ขึ้นกับ:

จำนวน database queries ที่รัน
ความซับซ้อนของ application logic
จำนวน plugin/middleware ที่โหลด
ขนาดของ HTML ที่ render

10 สาเหตุที่ทำให้ TTFB ของคุณช้า

ก่อนจะ optimize ต้องรู้ก่อนว่าปัญหาเกิดจากอะไร นี่คือ 10 สาเหตุที่พบมากที่สุดจากประสบการณ์การทำ audit เว็บไซต์ลูกค้าหลายร้อยเว็บของ Southern Whale

1. Server Bandwidth ต่ำ

Hosting ราคาถูก ๆ มักจำกัด network bandwidth ที่ 100Mbps หรือต่ำกว่า ในขณะที่ traffic peak อาจต้องการ 1Gbps+ ผลคือทุก request ต้องรอคิวส่งข้อมูล แม้ HTML จะเล็กแค่ 50KB ก็ตาม

2. Hosting Plan แย่ (Shared Hosting Limit)

Shared hosting หมายความว่า server เครื่องเดียว host เว็บไซต์ 100–500 เว็บพร้อมกัน ถ้ามีเว็บใดเว็บหนึ่งใช้ CPU เยอะ เว็บอื่น ๆ ก็ช้าตามทั้งหมด เป็นปรากฏการณ์ที่เรียกว่า “noisy neighbor”

3. Database Query ช้า / ไม่ได้ Optimize

เว็บที่มี query แบบ SELECT * FROM posts ORDER BY date DESC โดยที่ column date ไม่มี index จะใช้เวลา query หลายวินาทีเมื่อข้อมูลถึง 100,000 rows ขึ้นไป — และเว็บ WordPress ที่ใช้ปลั๊กอินมาก ๆ มักจะรัน query แบบนี้หลาย 10 ครั้งต่อหน้า

4. PHP Version เก่า (PHP 7.4 vs 8.3)

PHP 8.3 เร็วกว่า PHP 7.4 ประมาณ 30–40% สำหรับงาน WordPress ทั่วไป และ PHP 8.3 มี JIT compiler ที่ช่วยเร่ง computation-heavy workload ได้อีกระดับ การอัพเกรด PHP เพียงอย่างเดียวอาจลด TTFB ได้ 300–500ms

5. Plugin Bloat (WordPress โดยเฉพาะ)

ทุก plugin = code เพิ่ม = query เพิ่ม = filter/action hooks เพิ่ม เว็บที่มี 40+ plugins มัก TTFB เกิน 2 วินาที แม้จะใช้ hosting ดี

6. ไม่มี Caching

ทุก request ที่เข้ามา = render หน้าใหม่ทั้งหน้า = query database ใหม่ทุกครั้ง = TTFB สูง ในทางตรงข้าม cached page สามารถ serve ได้ในเวลา 5–20ms

7. ไม่มี CDN

ถ้า user อยู่ในเอเชียและ server อยู่ในอเมริกา latency พื้นฐานคือ 200ms+ ก่อนที่ server จะเริ่มทำงานด้วยซ้ำ CDN แก้ปัญหานี้โดยมี edge server ใกล้ user

8. Geographic Distance ระหว่าง User กับ Server

แม้ server จะเร็ว แต่ถ้า user อยู่ไกล TTFB ก็สูงเพราะ network latency เป็น physics ที่หลีกเลี่ยงไม่ได้ — ความเร็วแสงจำกัดว่า packet เดินทางได้เร็วแค่ไหน

9. Synchronous Third-party Scripts บน Server-side

เว็บที่เรียก API ภายนอก (เช่น weather API, social media API) ตอน render HTML — ถ้า API นั้นช้า, TTFB ก็ช้าตาม เพราะ server รอ response ก่อนส่ง byte แรก

10. Heavy Middleware (Laravel, Express)

Framework สมัยใหม่มี middleware stack ที่ทุก request ต้องผ่าน ถ้ามี middleware 20+ ตัว และแต่ละตัวทำ database query หรือ external call ก็จะกินเวลาเพิ่มขึ้นเรื่อย ๆ

12 วิธีลด TTFB ให้ต่ำกว่า 200ms

ทีนี้มาดูส่วนสำคัญที่สุดของบทความ — วิธี optimize จริง ๆ พร้อม code config ที่คุณ copy ไปใช้ได้

1. ใช้ CDN (Cloudflare) — ลดได้ 200–800ms ทันที

วิธีที่ effective ที่สุดและทำง่ายที่สุดคือเปิด Cloudflare CDN ขั้นตอน:

ขั้นที่ 1: สมัคร Cloudflare (free plan ใช้ได้)

ขั้นที่ 2: เพิ่ม site ของคุณ Cloudflare จะ scan DNS records อัตโนมัติ

ขั้นที่ 3: เปลี่ยน Nameserver ที่ domain registrar ของคุณเป็น Cloudflare nameservers ตัวอย่างที่ Cloudflare ให้:

calm.ns.cloudflare.com
walt.ns.cloudflare.com

ขั้นที่ 4: รอ DNS propagation 5 นาทีถึง 24 ชั่วโมง

ขั้นที่ 5: ไปที่ SSL/TLS → Edge Certificates → เปิด:

Always Use HTTPS: ON
HTTP Strict Transport Security (HSTS): ON
Minimum TLS Version: TLS 1.3
Opportunistic Encryption: ON
TLS 1.3: ON
0-RTT Connection Resumption: ON

อ่านรายละเอียดเพิ่มเติมที่ คู่มือ Cloudflare ครบจบ

2. Edge Caching (Cloudflare Cache Rules)

แค่ใช้ CDN ไม่พอ ต้องบอก Cloudflare ด้วยว่าให้ cache อะไรบ้าง ที่ Cache → Cache Rules สร้าง rule:

Rule name: Cache HTML pages
When incoming requests match:
  Hostname equals "yourdomain.com"
  AND URI Path does not contain "/wp-admin"
  AND URI Path does not contain "/cart"
  AND URI Path does not contain "/checkout"

Then:
  Cache eligibility: Eligible for cache
  Edge TTL: 1 month
  Browser TTL: 4 hours

สำหรับ WordPress + WooCommerce ต้อง bypass cache สำหรับ logged-in users และ cart pages

3. Object Cache (Redis/Memcached) — ลด DB query ได้ 90%

ทุก query ที่ซ้ำ ๆ ควรถูก cache ไว้ใน memory แทนการ query database ทุกครั้ง ตัวอย่าง Redis config สำหรับ WordPress:

ติดตั้ง Redis บน Ubuntu:

sudo apt update
sudo apt install redis-server php-redis -y
sudo systemctl enable redis-server
sudo systemctl start redis-server

แก้ /etc/redis/redis.conf:

maxmemory 256mb
maxmemory-policy allkeys-lru
save ""

สำหรับ WordPress ติดตั้งปลั๊กอิน Redis Object Cache หรือเพิ่มใน wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_PASSWORD', 'your_strong_password');
define('WP_CACHE', true);

สำหรับ Laravel ใช้ใน .env:

CACHE_DRIVER=redis
SESSION_DRIVER=redis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

ในโค้ด:

use Illuminate\Support\Facades\Cache;

$users = Cache::remember('users.all', 3600, function () {
    return User::with('posts', 'comments')->get();
});

ผลลัพธ์: query ที่เคยใช้ 200ms กลายเป็น 2ms

4. Database Query Optimization

ใช้ EXPLAIN ANALYZE หาว่า query ตัวไหนช้า:

EXPLAIN ANALYZE
SELECT p.*, u.display_name
FROM wp_posts p
JOIN wp_users u ON p.post_author = u.ID
WHERE p.post_status = 'publish'
  AND p.post_type = 'post'
ORDER BY p.post_date DESC
LIMIT 10;

ถ้าเห็น Using filesort หรือ Using temporary แปลว่าต้องเพิ่ม index:

CREATE INDEX idx_posts_status_type_date
ON wp_posts (post_status, post_type, post_date DESC);

หลังเพิ่ม index รันใหม่ คุณจะเห็น Using index แทน และเวลาลดจาก 800ms เหลือ 5ms

5. PHP-FPM Tuning

เปิด /etc/php/8.3/fpm/pool.d/www.conf แล้วปรับ:

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 1000
pm.process_idle_timeout = 10s

request_terminate_timeout = 30s

slowlog = /var/log/php-fpm-slow.log
request_slowlog_timeout = 5s

สูตรคำนวณ pm.max_children:

pm.max_children = (Total RAM - System RAM) / Average PHP Process Size

ตัวอย่าง: Server 4GB RAM
- ใช้ระบบ + MySQL = 1.5GB
- เหลือสำหรับ PHP = 2.5GB
- แต่ละ PHP process ใช้ ~80MB
- pm.max_children = 2560 / 80 = 32

restart:

sudo systemctl restart php8.3-fpm

6. OPcache (php.ini config)

OPcache เก็บ compiled PHP bytecode ใน memory ทำให้ไม่ต้อง compile ใหม่ทุก request เปิด /etc/php/8.3/fpm/php.ini:

[opcache]
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
opcache.fast_shutdown=1
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.jit_buffer_size=128M
opcache.jit=tracing

ส่วน opcache.jit คือ PHP 8 JIT compiler — เปิดแล้วเร็วขึ้นอีก 10–30% สำหรับ workload ที่มีการคำนวณเยอะ

7. Server-side Compression (Brotli + Gzip)

nginx.conf:

http {
    # Gzip
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml+rss
        application/xhtml+xml
        application/x-font-ttf
        application/vnd.ms-fontobject
        image/svg+xml;
    gzip_min_length 1024;

    # Brotli (ต้อง compile nginx with ngx_brotli module)
    brotli on;
    brotli_comp_level 6;
    brotli_static on;
    brotli_types
        text/plain
        text/css
        application/json
        application/javascript
        text/xml
        application/xml
        application/xml+rss
        text/javascript
        image/svg+xml;
}

Brotli ให้ compression ratio ดีกว่า Gzip ประมาณ 15–25% และ Chrome, Firefox, Edge รุ่นใหม่ทั้งหมด support

8. DNS Prefetch

ใน HTML ของคุณเพิ่ม:

<head>
  <link rel="dns-prefetch" href="https://fonts.googleapis.com">
  <link rel="dns-prefetch" href="https://www.google-analytics.com">
  <link rel="dns-prefetch" href="https://cdn.jsdelivr.net">

  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
</head>

dns-prefetch ทำแค่ DNS lookup ล่วงหน้า ส่วน preconnect ทำทั้ง DNS + TCP + TLS เลย เหมาะกับ origin ที่จะใช้แน่ ๆ

9. HTTP/3 / QUIC

HTTP/3 ใช้ QUIC แทน TCP ซึ่งลด handshake และจัดการ packet loss ดีกว่ามาก โดยเฉพาะใน mobile network เปิดใน nginx ใหม่ที่ build with HTTP/3:

server {
    listen 443 quic reuseport;
    listen 443 ssl;
    http2 on;

    ssl_protocols TLSv1.3;

    # Advertise HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # ... rest of server config
}

Cloudflare เปิด HTTP/3 ให้ฟรีในทุก plan แค่ไปที่ Network → HTTP/3 (with QUIC): ON

10. Static Site Generation (SSG)

ถ้าเว็บคุณไม่มี dynamic content ที่เปลี่ยนทุกวินาที พิจารณาใช้ SSG framework เช่น Astro หรือ Next.js แทน WordPress

Astro:

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  output: 'static',
  build: {
    inlineStylesheets: 'auto'
  }
});

Next.js (App Router):

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await fetchPosts();
  return posts.map(p => ({ slug: p.slug }));
}

export const revalidate = 3600; // ISR — regenerate every hour

SSG จะ generate HTML files ล่วงหน้า ส่ง CDN คือเสร็จ TTFB จะอยู่ที่ 30–80ms ทั่วไป

11. Edge Functions (Cloudflare Workers / Vercel Edge)

ถ้ามี logic ที่ต้อง dynamic แต่ไม่อยากให้ TTFB ช้า ใช้ Edge Functions แทน — โค้ดรันที่ edge server ใกล้ user ไม่ต้องไป origin

Cloudflare Workers ตัวอย่าง:

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    // Personalization at edge
    const country = request.cf.country;
    const variant = country === 'TH' ? 'th' : 'en';

    const cacheKey = `${url.pathname}-${variant}`;
    const cache = caches.default;

    let response = await cache.match(cacheKey);

    if (!response) {
      response = await fetch(`https://origin.example.com${url.pathname}`, {
        headers: { 'X-Variant': variant }
      });

      response = new Response(response.body, response);
      response.headers.set('Cache-Control', 's-maxage=3600');

      ctx.waitUntil(cache.put(cacheKey, response.clone()));
    }

    return response;
  }
}

12. ย้ายจาก Shared Hosting ไป VPS / Dedicated / Managed Cloud

ถ้าทำทุกอย่างข้างบนแล้ว TTFB ยังเกิน 500ms ปัญหาอยู่ที่ infrastructure ไม่ใช่ application พิจารณาย้ายไป:

Hosting Type	TTFB ที่คาดหวัง	ราคา/เดือน
Shared Hosting	800–3000ms	100–500 บาท
VPS (DigitalOcean, Vultr, Linode)	100–400ms	200–2000 บาท
Managed WordPress (Kinsta, WP Engine)	80–300ms	1000–10000 บาท
Dedicated Server	50–200ms	5000–50000 บาท
Cloud (AWS, GCP) + CDN	30–100ms	ผันผวน

เครื่องมือ Measure TTFB

จะ optimize อะไรก็ต้องวัดได้ก่อน นี่คือ 5 เครื่องมือที่ใช้บ่อยที่สุด

1. Chrome DevTools

กด F12 → Network tab → Refresh → คลิกที่ HTML document แรก → Headers → Timing:

Queueing — เวลารอคิวใน browser
Stalled — รอ connection
DNS Lookup
Initial connection
SSL
Request sent
Waiting (TTFB) ← ตัวนี้คือ TTFB จริง
Content Download

2. WebPageTest (webpagetest.org)

มี waterfall view ละเอียดมาก แสดงทุก request และเวลาแต่ละช่วง รวมถึง connection view ที่บอกว่า request ไหน reuse connection ได้

Test URL: https://yourdomain.com
Location: Bangkok, Thailand - Chrome - Cable
Test Count: 3
First View + Repeat View

หลัง test เสร็จดูที่ Connection View จะเห็นว่า TTFB อยู่ที่เท่าไหร่ และ break down ได้ละเอียด

3. GTmetrix

คล้าย WebPageTest แต่ UI เป็นมิตรกว่า เลือก test server ที่ฮ่องกงสำหรับ benchmark traffic เอเชีย

4. curl Command

วัด TTFB จาก command line:

curl -w "@curl-format.txt" -o /dev/null -s "https://yourdomain.com"

สร้างไฟล์ curl-format.txt:

     time_namelookup:  %{time_namelookup}s\n
        time_connect:  %{time_connect}s\n
     time_appconnect:  %{time_appconnect}s\n
    time_pretransfer:  %{time_pretransfer}s\n
       time_redirect:  %{time_redirect}s\n
  time_starttransfer:  %{time_starttransfer}s\n
                     ----------\n
          time_total:  %{time_total}s\n

time_starttransfer คือ TTFB ผลตัวอย่าง:

     time_namelookup:  0.012s
        time_connect:  0.038s
     time_appconnect:  0.105s
    time_pretransfer:  0.106s
       time_redirect:  0.000s
  time_starttransfer:  0.187s   ← TTFB = 187ms
                     ----------
          time_total:  0.241s

5. PageSpeed Insights

ไปที่ pagespeed.web.dev ใส่ URL จะเห็น Field Data (จาก CrUX) ที่บอก p75 TTFB ของผู้ใช้จริง พร้อม Lab Data จาก Lighthouse

อ่านวิธีใช้ PSI ละเอียดได้ที่ PageSpeed Insights Guide

TTFB สำหรับ WordPress

WordPress คือ CMS ที่ใช้แพร่หลายที่สุด แต่ก็มีปัญหา TTFB เยอะที่สุด เพราะ default behavior คือ render ทุกหน้าใหม่ทุก request นี่คือ stack ที่ทีม Southern Whale แนะนำ:

Plugin ที่ต้องมี

WP Rocket (เสียเงิน, แต่คุ้ม):

Page caching
Browser caching
GZIP compression
Critical CSS generation
Lazy load
Database optimization

ตั้งค่า WP Rocket:

Cache → Mobile Cache: ON
Cache → User Cache: OFF (ยกเว้น membership site)
File Optimization → Minify CSS, JS, HTML: ON
File Optimization → Combine Google Fonts: ON
Media → LazyLoad → For images: ON
Preload → Activate Preloading: ON

LiteSpeed Cache (ฟรี, ดีที่สุดถ้าใช้ LiteSpeed server):

Cache → Default Public Cache TTL: 604800 (7 วัน)
Cache → ESI: ON
CDN → QUIC.cloud CDN: ON
Image Optimization: ON (ใช้ QUIC.cloud quota ฟรี)

object-cache.php (Redis Drop-in)

หลังติดตั้ง Redis Object Cache plugin คุณจะเห็นไฟล์ wp-content/object-cache.php เกิดขึ้น — ไฟล์นี้คือสิ่งที่ทำให้ WordPress queries ทั้งหมดเป็น cached

ทดสอบว่าใช้ได้จริง:

<?php
// ทดสอบใน wp-content/themes/your-theme/test-redis.php
if (wp_cache_set('test_key', 'hello world')) {
    echo "Cache write: OK\n";
}

$value = wp_cache_get('test_key');
echo "Cache read: $value\n";

WordPress Specific Tips

ปิด WP-Cron จริง ๆ แล้วใช้ real cron แทน:

// wp-config.php
define('DISABLE_WP_CRON', true);

# crontab -e
*/5 * * * * curl -s https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null

จำกัด revisions:

define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 300);

ใช้ heartbeat API น้อยลง ผ่าน Heartbeat Control plugin
ลบ plugin ที่ไม่ใช้ — แม้จะ deactivate แล้วก็ตามถ้าไม่ใช้ก็ลบทิ้ง

TTFB สำหรับ Astro / Next.js

Modern framework เปิดประตูให้ achieve TTFB ระดับ < 100ms ได้ง่ายมาก

Astro บน Cloudflare Pages

# สร้าง project
npm create astro@latest my-site
cd my-site
npm install @astrojs/cloudflare

astro.config.mjs:

import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'static', // หรือ 'hybrid' ถ้าต้องการ SSR บางหน้า
  adapter: cloudflare({
    mode: 'directory'
  }),
  build: {
    inlineStylesheets: 'auto'
  },
  vite: {
    build: {
      cssMinify: 'lightningcss',
      minify: 'esbuild'
    }
  }
});

Deploy:

npm run build
npx wrangler pages deploy ./dist

TTFB ที่ได้: 40–80ms ทั่วโลก (เพราะ Cloudflare มี 300+ edge locations)

Next.js บน Vercel Edge

app/page.tsx:

export const runtime = 'edge';
export const revalidate = 3600;

export default async function HomePage() {
  const data = await fetch('https://api.example.com/posts', {
    next: { revalidate: 3600 }
  }).then(r => r.json());

  return <PostList posts={data} />;
}

Vercel Edge Runtime ใช้ V8 isolates แทน Node.js full runtime — cold start ใกล้ 0ms

Self-host Astro/Next on VPS + Nginx

ถ้าไม่อยาก lock-in กับ Vercel/Cloudflare:

server {
    listen 443 ssl http2;
    listen 443 quic;
    server_name yourdomain.com;

    # SSL
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ssl_protocols TLSv1.3;
    ssl_early_data on;
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;

    # Static files
    root /var/www/yoursite/dist;
    index index.html;

    # Cache HTML
    location ~ \.html$ {
        add_header Cache-Control "public, max-age=300, s-maxage=3600";
    }

    # Cache assets aggressive
    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2)$ {
        add_header Cache-Control "public, max-age=31536000, immutable";
        access_log off;
    }

    # Try files
    location / {
        try_files $uri $uri/ $uri.html /index.html;
    }
}

ตัวอย่างจริง: TTFB 1.8s → 180ms

ลูกค้าของ Southern Whale รายหนึ่งเป็น e-commerce ใช้ WordPress + WooCommerce ขายสินค้าประมาณ 5,000 SKU มี traffic 200,000 page views/เดือน TTFB เริ่มต้นที่ 1,800ms ทำให้ bounce rate สูง 68%

Before

TTFB Breakdown:
- DNS Lookup:        45ms
- TCP Handshake:     180ms (server ที่ Singapore)
- TLS:               340ms (TLS 1.2 + ไม่มี session resumption)
- Server Processing: 1,235ms
─────────────────────────────
Total TTFB:          1,800ms

Steps ที่ทำ

ขั้นตอน	สิ่งที่ทำ	TTFB หลังทำ
1	เปิด Cloudflare (CDN + TLS 1.3)	1,200ms
2	ติดตั้ง Redis Object Cache	850ms
3	อัพเกรด PHP 7.4 → 8.3 + OPcache JIT	620ms
4	ติดตั้ง WP Rocket + Cache HTML	280ms
5	Database query optimization + index	240ms
6	Cloudflare APO (Automatic Platform Optimization)	180ms

After

TTFB Breakdown:
- DNS Lookup:        12ms (Cloudflare DNS)
- TCP Handshake:     35ms (Edge ที่ Bangkok)
- TLS:               45ms (TLS 1.3 + 0-RTT)
- Server Processing: 88ms (cached HTML จาก edge)
─────────────────────────────
Total TTFB:          180ms

ผลลัพธ์ทางธุรกิจ:

Bounce rate: 68% → 32%
Conversion rate: 1.2% → 2.8% (เพิ่ม 133%)
Organic traffic (3 เดือนหลัง): +47%
Average session duration: 1:20 → 2:45

5 ข้อผิดพลาดที่พบบ่อยในการ Optimize TTFB

1. Cache HTML โดยไม่คิดถึง logged-in users

WordPress ที่ cache HTML แบบ aggressive แล้วลืม exclude logged-in users จะทำให้ admin เห็นหน้าของ guest, หรือลูกค้าเห็น cart ของคนอื่น — ปัญหาความปลอดภัยร้ายแรง

วิธีแก้: ตั้ง bypass cache cookie:

map $http_cookie $bypass_cache {
    default 0;
    "~*wordpress_logged_in" 1;
    "~*woocommerce_items_in_cart" 1;
    "~*comment_author" 1;
}

location / {
    fastcgi_cache_bypass $bypass_cache;
    fastcgi_no_cache $bypass_cache;
}

2. วัด TTFB แค่ครั้งเดียว

TTFB ผันผวนได้มาก ขึ้นกับ load, time of day, network condition — ต้องวัดอย่างน้อย 5–10 ครั้งแล้วเอา median ไม่ใช่ average เพราะ outlier จะ skew

3. Optimize TTFB แต่ไม่ดู Core Web Vitals อื่น

TTFB เร็วแต่ LCP ช้าก็ไม่มีประโยชน์ — ต้องดู metric ทั้งหมดร่วมกัน อ่าน Core Web Vitals Guide เพื่อเข้าใจ metric ทั้งหมด

4. ใช้ CDN แล้วลืมเปิด HTTPS

CDN อย่าง Cloudflare ต้องเปิด “Always Use HTTPS” และตั้ง SSL/TLS encryption mode เป็น “Full (Strict)” ไม่ใช่ “Flexible” — เพราะ Flexible จะทำให้เกิด redirect loop และ TTFB เพิ่ม

5. Cache แบบ static แต่ content เปลี่ยนบ่อย

ถ้าเว็บคุณเป็น news site ที่ update ทุกชั่วโมง อย่าตั้ง cache TTL 7 วัน — ใช้ short TTL + cache purge on update แทน:

// WordPress: purge cache on post update
add_action('save_post', function($post_id) {
    if (function_exists('rocket_clean_post')) {
        rocket_clean_post($post_id);
    }

    // Purge Cloudflare cache
    $cf_api_key = 'your_api_key';
    $zone_id = 'your_zone_id';

    wp_remote_post("https://api.cloudflare.com/client/v4/zones/{$zone_id}/purge_cache", [
        'headers' => [
            'Authorization' => "Bearer {$cf_api_key}",
            'Content-Type' => 'application/json'
        ],
        'body' => json_encode([
            'files' => [get_permalink($post_id)]
        ])
    ]);
});

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

Q1: TTFB กับ Server Response Time ต่างกันไหม?

ในทางปฏิบัติ Google ใช้คำสองคำนี้สลับกันได้ แต่ทางเทคนิคแล้ว TTFB รวม DNS + TCP + TLS + Server processing ส่วน Server Response Time จะนับแค่ส่วน server processing (ตั้งแต่ request ถึง first byte sent ที่ server เท่านั้น) ใน Lighthouse คุณจะเห็น “Reduce server response times (TTFB)” ซึ่งหมายถึง TTFB

Q2: TTFB เท่าไหร่ถึงจะถือว่า “ดี” สำหรับ Google?

Google บอกว่า TTFB ที่ดีควรอยู่ที่ < 800ms (p75) — หมายถึง 75% ของ user ต้องได้ TTFB ต่ำกว่า 800ms ส่วนตัว Southern Whale แนะนำ target ที่ < 600ms สำหรับเว็บทั่วไป และ < 200ms สำหรับเว็บ performance-critical

Q3: ถ้าใช้ Cloudflare แล้ว TTFB ยังช้า ทำไม?

มี 3 สาเหตุหลัก:

ไม่ได้ตั้ง Cache Rules — Cloudflare ไม่ cache HTML by default
Cache hit ratio ต่ำ — เช็คได้ที่ Analytics → Performance
Origin server ช้า — Cloudflare ก็ช่วยอะไรไม่ได้ถ้า origin ช้า

Q4: SSG (Static Site Generation) ลด TTFB ได้จริงไหม?

จริงและลดมาก SSG จะ generate HTML files ล่วงหน้า เวลา request เข้ามาแค่ส่งไฟล์ — ไม่ต้อง process อะไรเลย TTFB ปกติ 30–80ms ทั่วโลกเมื่อ deploy บน CDN เช่น Cloudflare Pages หรือ Vercel

Q5: WordPress สามารถทำ TTFB ต่ำกว่า 200ms ได้ไหม?

ได้ แต่ต้องการ stack ที่ถูก: Managed Hosting (Kinsta, WP Engine) + Object Cache (Redis) + Page Cache (WP Rocket หรือ LiteSpeed) + CDN (Cloudflare) + PHP 8.3 + Optimized Database ถ้าทำครบเหล่านี้ TTFB 150–250ms เป็นไปได้

Q6: HTTP/3 ช่วยลด TTFB เยอะไหม?

ช่วย โดยเฉพาะใน mobile network ที่ packet loss สูง HTTP/3 ลด connection setup จาก 3 RTT (TCP + TLS 1.3) เหลือ 1 RTT (QUIC) สำหรับ first visit และ 0 RTT สำหรับ returning visit ผลต่างประมาณ 50–200ms ต่อ connection

Q7: Database ที่ใหญ่มาก ๆ จะทำ TTFB เร็วได้ยังไง?

วิธีหลัก:

Index ที่ถูกต้อง — query plan ทุก slow query ด้วย EXPLAIN ANALYZE
Read replica — แยก read load ออกจาก write load
Query cache layer — เก็บผล query ที่ใช้บ่อยใน Redis
Partition ตาราง — สำหรับตารางใหญ่ ๆ เช่น logs, analytics
Pre-aggregate — สำหรับ stat ที่คำนวณบ่อย เก็บผลรวมไว้แทนการคำนวณทุก request

Q8: ทำไม Mobile TTFB ช้ากว่า Desktop?

เพราะ:

Mobile network latency สูงกว่า WiFi (4G ประมาณ 50ms, 5G ประมาณ 10–30ms, WiFi 5ms)
Packet loss สูงกว่า — ทำให้ retransmission เยอะขึ้น
CPU/RAM น้อยกว่า — สำหรับ TLS handshake ใช้เวลา compute มากขึ้น

วิธีแก้: เปิด HTTP/3 (จัดการ packet loss ดีกว่า TCP) + 0-RTT resumption + reduce TLS computational cost (ใช้ ECDSA cert แทน RSA 4096)

สรุป: TTFB คือฐานรากของทุก optimization

TTFB ไม่ใช่ metric ที่ “fix แล้วลืม” ได้ มันต้อง monitor อย่างต่อเนื่อง เพราะอาจช้าลงได้จาก traffic spike, plugin update, database growth หรือแม้กระทั่ง infrastructure provider เปลี่ยน routing

สรุป checklist ที่คุณควรทำตามลำดับ:

วัด TTFB ปัจจุบัน ด้วย Chrome DevTools, PageSpeed Insights, WebPageTest
เปิด CDN (Cloudflare ฟรีก็ดีพอสำหรับเริ่มต้น)
เปิด Cache Rules ที่ CDN level สำหรับ HTML
ตั้ง Object Cache (Redis/Memcached) ถ้าใช้ WordPress/PHP framework
อัพเกรด PHP เป็น 8.3 ล่าสุด + เปิด OPcache JIT
Tune Database ด้วย index ที่ถูกต้อง
เปิด Brotli compression ที่ web server
พิจารณาย้ายไป SSG ถ้าเว็บไม่ต้องการ real-time dynamic content
ใช้ Edge Functions สำหรับ logic ที่ต้องเป็น dynamic
Monitor อย่างต่อเนื่อง ด้วย Real User Monitoring (RUM) tool

การมี TTFB เร็วไม่ใช่ luxury — มันคือ baseline ที่ทุกเว็บไซต์ในปี 2026 ต้องมี ทั้งเพื่อ SEO, conversion rate และ user experience ที่ดี ถ้าคุณยังมี TTFB เกิน 1 วินาที คุณกำลังเสียโอกาสทางธุรกิจอย่างมหาศาลโดยไม่รู้ตัว

ทีม Southern Whale เชี่ยวชาญด้านการ optimize TTFB และ Core Web Vitals มาแล้วมากกว่า 200 โปรเจกต์ ครอบคลุมทั้ง WordPress, WooCommerce, Laravel, Astro และ Next.js เราการันตีลด TTFB อย่างน้อย 50% ภายใน 14 วัน หรือคืนเงิน

หากคุณสนใจให้เราช่วย audit + optimize TTFB ให้เว็บไซต์ของคุณ ติดต่อทีมงาน ของเราได้เลย — รับปรึกษาฟรี 30 นาที พร้อม performance report เบื้องต้น

อ่านบทความ Web Performance อื่น ๆ ที่เกี่ยวข้อง: