ทำไม Time to First Byte ของคุณจึงช้า และควรทำอย่างไร

เริ่มจากสิ่งที่ TTFB วัดจริง ๆ

Time to First Byte ซึ่งมักย่อว่า TTFB คือเวลาตั้งแต่เบราว์เซอร์ร้องขอ resource ไปจนถึงได้รับ byte แรกของ response

ฟังดูเหมือนเป็น metric ของเซิร์ฟเวอร์ แต่ไม่ได้เป็นเพียง metric ของเซิร์ฟเวอร์เท่านั้น TTFB รวมหลายขั้นตอนเข้าด้วยกัน:

• DNS lookup หาก hostname ยังไม่ได้ถูก resolve
• การตั้งค่าการเชื่อมต่อ TCP
• การเจรจา TLS สำหรับ HTTPS
• เวลาเดินทางของ request ไปยังเซิร์ฟเวอร์หรือ CDN edge
• การเข้าคิวและการประมวลผลบนเซิร์ฟเวอร์
• เวลาเดินทางของ response กลับไปยังเบราว์เซอร์

ดังนั้น TTFB ที่สูงอาจหมายความว่า backend ของคุณช้า แต่ก็อาจหมายความว่าผู้ใช้อยู่ไกลจาก origin, CDN ตั้งค่าผิด, แคชพลาดอยู่ตลอดเวลา หรือเซิร์ฟเวอร์ใช้เวลานานเกินไปในการตัดสินใจว่าจะส่งอะไรกลับไป

เรื่องนี้สำคัญเพราะ TTFB อยู่ใกล้จุดเริ่มต้นของสายการโหลด หากเอกสาร HTML มาถึงช้า เบราว์เซอร์ก็จะค้นพบ CSS, JavaScript, fonts และ images ช้าตามไปด้วย คุณอาจปรับแต่ง front-end ได้ดีเยี่ยม แต่ยังรู้สึกว่าช้าได้ หาก response ของเอกสารแรกใช้เวลา 1.5 วินาที

TTFB แบบไหนถือว่าช้า?

ไม่มีตัวเลขสากลที่เหมาะกับทุกเว็บไซต์ ทุกภูมิภาค และทุกสถาปัตยกรรม อย่างไรก็ตาม เกณฑ์เชิงปฏิบัติช่วยได้

คำแนะนำจาก web.dev ของ Google จัดให้ TTFB ที่ดีอยู่ต่ำกว่า 800 ms, ช่วง 800–1800 ms ต้องปรับปรุง และมากกว่า 1800 ms ถือว่าแย่ สำหรับหน้า marketing ที่แคชไว้อย่างดีและให้บริการใกล้ผู้ใช้ คุณมักทำได้ดีกว่านั้นมาก สำหรับ dashboard ที่ซับซ้อนและต้อง authentication พร้อมงาน dynamic ตัวเลขที่ยอมรับได้อาจสูงกว่า แต่ก็ควรอธิบายได้

นิสัยที่สำคัญคือการแยกตัวเลขออกเป็นส่วน ๆ ค่าเฉลี่ย TTFB ทั่วโลกที่ 900 ms อาจซ่อน response 150 ms สำหรับผู้ใช้ที่อยู่ใกล้ CDN edge ของคุณ และ response 2200 ms สำหรับผู้ใช้ในอีกภูมิภาคหนึ่งได้ เช่นเดียวกัน homepage ของคุณอาจไม่มีปัญหา ขณะที่หน้า search, category หรือหน้าที่ logged-in กลับช้าอย่างเงียบ ๆ

วัดจากมากกว่าหนึ่งที่

อย่าวินิจฉัย TTFB จากการรัน Lighthouse เพียงครั้งเดียว Lighthouse มีประโยชน์ แต่เป็นการทดสอบหนึ่งครั้งจากสภาพแวดล้อมเดียว หากคุณเพิ่งเริ่มตีความรายงานนี้ ให้เริ่มจากการอ่านอย่างใจเย็นว่าอ่านรายงาน Lighthouse อย่างไรโดยไม่ตื่นตระหนก — บทเรียนหลักคือการแยกสัญญาณจาก lab ออกจากความเป็นจริงใน field

สำหรับ TTFB คุณควรมีอย่างน้อยสามมุมมอง:

1. Browser developer tools

เปิด Network panel, reload โดยปิด cache แล้วตรวจสอบ request ของเอกสารหลัก รายละเอียด timing จะแสดงช่วง DNS, connection, TLS, waiting และ download ช่วง “waiting” มักเป็นสิ่งที่ผู้คนหมายถึงเวลา backend แม้ว่ามันอาจรวม upstream latency ด้วยก็ตาม

2. Synthetic tests จากหลายภูมิภาค

รันทดสอบจากตำแหน่งที่อยู่ใกล้และไกลจากผู้ใช้ของคุณ หาก TTFB ต่ำในภูมิภาคหนึ่งแต่สูงในอีกภูมิภาคหนึ่ง ให้สงสัยเรื่องภูมิศาสตร์, CDN routing, ตำแหน่ง origin หรือ cache coverage ก่อนที่จะเขียน application code ใหม่

3. Real user monitoring หรือ server logs

Field data บอกได้ว่าผู้ใช้จริงเจออะไรบนอุปกรณ์ เครือข่าย และ session ที่หลากหลาย Server logs บอกได้ว่า origin สร้าง response ได้เร็วเพียงใด ความแตกต่างระหว่าง TTFB ที่ client สังเกตเห็นกับเวลา processing ของ origin มักเป็นจุดที่ปัญหา CDN และ network ปรากฏขึ้น

สาเหตุทั่วไปของ TTFB ที่ช้า

HTML ของคุณไม่ได้ถูกแคช

นี่เป็นปัญหาที่พบบ่อยที่สุดบน content sites และ ecommerce sites Static assets ถูกแคชอย่างเข้มงวด แต่เอกสาร HTML — สิ่งที่เบราว์เซอร์ต้องการก่อน — กลับถูกสร้างใหม่ในทุก request

บางครั้งสิ่งนี้จำเป็น แต่บ่อยครั้งก็ไม่จำเป็น

หาก public page เปลี่ยนเพียงไม่กี่ครั้งต่อวัน ก็น่าจะไม่ควรต้อง render จากฐานข้อมูลใหม่สำหรับ anonymous visitor ทุกคน ใช้ full-page caching, edge caching, static generation หรือรูปแบบ stale-while-revalidate ตามความเหมาะสม

ตรวจสอบ response headers เพื่อดูสัญญาณอย่าง Cache-Control, CDN-Cache-Status, Age, Vary และ Set-Cookie หน้าที่ส่ง cookie เฉพาะให้ผู้เยี่ยมชมทุกคนอาจทำให้ตัวเองไม่สามารถแคชได้โดยไม่ตั้งใจ หากคุณต้องการวิธีเชิงปฏิบัติในการคิดเกี่ยวกับชั้นนี้ นิสัยการ debug แบบเดียวกับใน คู่มือของเราเรื่อง redirects และ HTTP headers ใน production สามารถนำมาใช้กับงาน TTFB ได้โดยตรง

CDN ของคุณแคชเฉพาะ assets

หลายทีมเพิ่ม CDN แล้วสรุปว่างานด้าน performance เสร็จแล้ว แต่หาก CDN ให้บริการเฉพาะ images, CSS และ JavaScript request HTML แรกอาจยังต้องเดินทางไปจนถึง origin server เพียงตัวเดียว

สิ่งนี้อาจใช้ได้สำหรับเว็บไซต์ธุรกิจท้องถิ่นที่มีผู้ใช้ในพื้นที่ แต่ไม่เหมาะสำหรับผู้ชมระดับนานาชาติ ยิ่งผู้ใช้อยู่ไกลจาก origin มากเท่าไร คุณก็ยิ่งจ่าย latency มากขึ้นก่อนที่งาน backend จะเริ่มด้วยซ้ำ

การตั้งค่า CDN ที่ดีสำหรับ TTFB มักหมายถึง:

• แคช public HTML ในจุดที่ปลอดภัย
• เคารพกฎ bypass ที่ตั้งใจไว้สำหรับหน้าที่ authenticated หรือ personalized
• หลีกเลี่ยง headers Vary ที่ไม่จำเป็นซึ่งทำให้แคชแตกละเอียดเกินไป
• ใช้ cache purging หรือ revalidation แทนการปิดแคชทั้งหมด
• ยืนยันว่า edge locations ให้บริการจาก cache hits จริง ไม่ใช่ forward ทุก request

CDN ไม่ใช่เวทมนตร์ มันคือชั้นของ cache และ routing จงปฏิบัติกับมันเช่นนั้น

เซิร์ฟเวอร์ของคุณทำงานมากเกินไปก่อนตอบกลับ

backend path ที่ช้าอาจมาจากความล่าช้าเล็ก ๆ หลายอย่าง: database queries, API calls, template rendering, feature flag checks, authentication, personalization, logging และ cold starts

รูปแบบที่แย่ที่สุดคือการทำงานแบบพึ่งพากันเป็นลำดับ ตัวอย่างเช่น:

1. Fetch page data
2. Then fetch related products
3. Then fetch pricing
4. Then call a recommendations service
5. Then render HTML

หากแต่ละขั้นต้องรอขั้นก่อนหน้า TTFB จะเพิ่มขึ้นอย่างรวดเร็ว ให้ parallelize งานที่เป็นอิสระต่อกัน, ย้าย calls ที่ไม่สำคัญออกจาก response แรก และแคชผลลัพธ์ที่มีต้นทุนสูง

กฎที่มีประโยชน์คือ หากผู้ใช้ไม่สามารถเห็นหรือใช้ผลลัพธ์ได้ทันที สิ่งนั้นก็น่าจะไม่ควร block byte แรก

Database queries ช้าหรือคาดเดาไม่ได้

ฐานข้อมูลมักทำให้เกิดปัญหา TTFB เพราะมันทำงานได้ดีใน development แต่แย่ลงเมื่อเจอ traffic จริง Missing indexes, joins ขนาดใหญ่, N+1 queries, lock contention และ result sets ที่ใหญ่เกินไป ล้วนปรากฏเป็น “เซิร์ฟเวอร์ช้า”

อย่าเดาในจุดนี้ ให้เก็บ query timings สำหรับ requests ที่ช้า ดู p95 และ p99 ไม่ใช่แค่ค่าเฉลี่ย หน้าหนึ่งที่ปกติตอบใน 120 ms แต่บางครั้ง block เป็นเวลา 4 วินาที ก็ยังสร้างประสบการณ์ผู้ใช้ที่แย่ได้

แนวทางแก้ไขที่พบบ่อย ได้แก่:

• เพิ่มหรือแก้ไข indexes
• ลบรูปแบบ N+1 query
• แคชข้อมูลที่อ่านบ่อย
• ทำ pagination ให้ queries ขนาดใหญ่
• ย้าย reporting หรือ analytics queries ออกจาก request time
• ตั้ง timeouts ที่เหมาะสมสำหรับ downstream calls

แอปพลิเคชันของคุณมี cold starts

แพลตฟอร์ม serverless และ containerized อาจยอดเยี่ยมมาก แต่ cold starts สามารถทำร้าย TTFB ได้เมื่อ traffic มาเป็นช่วง ๆ หรือภูมิภาคถูก provision ไว้ไม่พอ

หาก request แรกหลังจาก idle ช้ากว่า request ถัด ๆ ไปมาก ให้ตรวจสอบ cold starts คุณอาจต้องใช้ provisioned concurrency, bundles ที่เล็กลง, startup dependencies ที่น้อยลง, functions ที่ warm ขึ้น หรือรูปแบบ deployment ที่ต่างออกไปสำหรับ routes ที่ไวต่อ latency

นี่ไม่ใช่ข้อโต้แย้งต่อต้าน serverless แต่เป็นข้อโต้แย้งต่อการแสร้งว่ารูปแบบ runtime นั้นมองไม่เห็น

Redirects ทำให้ request แรกสูญเปล่า

redirect เพิ่มรอบ request-response อีกหนึ่งรอบก่อนที่เบราว์เซอร์จะได้รับเอกสารสุดท้าย redirect หนึ่งครั้งจาก http:// ไป https:// อาจหลีกเลี่ยงไม่ได้สำหรับลิงก์เก่า แต่ chains นั้นสิ้นเปลือง

chains ที่พบบ่อย ได้แก่:

• http://example.com → https://example.com → https://www.example.com
• การ normalize trailing slash หลังจากการ normalize protocol
• geo หรือ language redirects ก่อน cache lookup
• legacy campaign links ที่กระโดดผ่านหลาย URLs

แก้ source links เมื่อทำได้, รวมกฎ redirect ให้สั้นลง และทำให้ canonical URLs ไปถึงปลายทางโดยตรง เวลา redirect ไม่ได้ถูกรายงานเป็น TTFB ของ request สุดท้ายเสมอไป แต่ผู้ใช้ยังคงต้องจ่ายเวลานั้น

ลำดับการ debug ที่ใช้ได้จริง

เมื่อ TTFB ดูช้า ให้ใช้ลำดับนี้ มันช่วยหลีกเลี่ยงข้อผิดพลาดทั่วไปคือการ optimize application code ก่อนยืนยันพฤติกรรม cache และ routing

Step 1: ทดสอบเอกสารหลัก ไม่ใช่แค่ทั้งหน้า

หา request ของเอกสาร HTML บันทึก TTFB รวมและรายละเอียด timing ทำซ้ำทั้งแบบมีและไม่มี browser cache ทดสอบ public page, dynamic page และ logged-in page หากเกี่ยวข้อง

Step 2: เปรียบเทียบภูมิภาค

รัน URL เดียวกันจากหลายตำแหน่งทางภูมิศาสตร์ หากภูมิภาคที่ช้าสัมพันธ์กับระยะทางจาก origin ให้ให้ความสำคัญกับ CDN และ edge caching หากทุกภูมิภาคช้า ให้ดู backend processing และ origin capacity

Step 3: ตรวจสอบ response headers

มองหา cache headers, cookies, Age, CDN status และ Vary header Age ที่หายไปหรือ cache misses ซ้ำ ๆ คือเบาะแส header Vary: Cookie ที่กว้างเกินไปบน public HTML มักเป็นตัวทำลายแคช

Step 4: ตรวจสอบ origin timing

เพิ่ม server timing instrumentation header Server-Timing สามารถเปิดเผย phases ของ backend เช่น database time, render time และ upstream API time แม้แต่ label ง่าย ๆ ก็มีประโยชน์:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

ตอนนี้ browser timings ของคุณจะแสดงได้ว่าเซิร์ฟเวอร์ใช้เวลา 300 ms กับงานจริง หรือความล่าช้าเกิดขึ้นก่อน request จะถึงแอปพลิเคชันของคุณ

Step 5: แก้ความล่าช้าที่ได้รับการยืนยันว่าใหญ่ที่สุด

ฟังดูชัดเจน แต่ทีมมักแก้สิ่งที่คุ้นเคยมากกว่าสิ่งที่วัดได้ หาก cache misses ครอบงำ ให้แก้ caching หากฐานข้อมูลครอบงำ ให้แก้ queries หาก TLS และ connection setup ครอบงำสำหรับผู้ใช้ทั่วโลก ให้แก้ routing, CDN coverage หรือภูมิศาสตร์ของ origin

งาน front-end ยังสำคัญ Fonts, images และ JavaScript ส่งผลต่อสิ่งที่เกิดขึ้นหลัง HTML มาถึง แต่สิ่งเหล่านั้นไม่ใช่สิ่งทดแทน response แรกที่รวดเร็ว หากคุณกำลังทำงานกับ render performance ด้วย web fonts ยังคงเป็นหนึ่งในชัยชนะที่ง่ายที่สุดบนหลายเว็บไซต์ เพราะมันส่งผลต่อความเร็วที่ข้อความเริ่มใช้งานได้หลังเอกสารมาถึง

วิธีแก้ที่มักได้ผล

แคช public HTML ที่ edge

สำหรับ marketing pages, documentation, blogs, landing pages และ category pages การทำ edge caching มักเป็นการปรับปรุง TTFB ที่ใหญ่ที่สุด ใช้ TTL สั้น ๆ หากเนื้อหาเปลี่ยนบ่อย ใช้ stale-while-revalidate หากยอมรับเนื้อหาที่ stale เล็กน้อยได้ในขณะที่ cache refresh อยู่เบื้องหลัง

ระวัง personalization หากหน้าหนึ่งเปลี่ยนตาม currency, language, login state หรือ experiment group ให้กำหนด variants เหล่านั้นอย่างชัดเจน ความแปรผันแบบต่อผู้ใช้โดยไม่ตั้งใจทำลายประสิทธิภาพของแคช

ย้ายงานที่ไม่สำคัญออกจาก request path

Email sending, analytics enrichment, recommendation generation, webhook calls และ heavy logging แทบไม่ควร block byte แรก ให้วางไว้ใน queues หรือรันหลังจาก response เริ่มแล้ว

ลด chains ของ dependency ฝั่ง backend

Parallelize calls ที่เป็นอิสระต่อกัน แคช responses จาก APIs ที่ช้า ตั้ง timeouts ออกแบบ fallback content สำหรับบริการที่มีประโยชน์แต่ไม่จำเป็น

recommendations widget ที่ช้าไม่ควรทำให้ทั้ง product page ล่าช้า

นำ compute ไปไว้ใกล้ผู้ใช้มากขึ้น

หากผู้ใช้ของคุณอยู่ทั่วโลกและ origin อยู่ในภูมิภาคเดียว latency คือปัญหาเชิงโครงสร้าง CDN caching สามารถซ่อนสิ่งนี้ได้มากสำหรับ public content สำหรับ dynamic content ให้พิจารณา regional deployments, edge rendering สำหรับ routes ที่เหมาะสม หรือย้าย APIs ให้ใกล้กลุ่มผู้ชมมากขึ้น

ทำให้ redirects เรียบง่าย

Canonicalize URLs ในหนึ่ง hop อัปเดต internal links เพื่อให้ผู้ใช้และ crawlers ไปยังปลายทางสุดท้ายได้โดยตรง ตรวจสอบ campaign URLs เก่าและ platform migrations Redirects มักถูกมองข้ามเพราะมองไม่เห็นเมื่อทำงานได้ แต่ยังคงมีต้นทุนด้านเวลา

สิ่งที่ไม่ควรทำ

อย่าไล่ตามตัวเลข TTFB ที่สมบูรณ์แบบสำหรับทุก route report ที่ authenticated และทำ computation จริงจะไม่ทำงานเหมือน blog post ที่ถูกแคชไว้

อย่าใช้ TTFB เฉลี่ยเป็น metric เดียวของคุณ Percentiles สำคัญ ภูมิศาสตร์สำคัญ ประเภทหน้าสำคัญ

อย่าสรุปว่า CDN หมายความว่า HTML ของคุณถูกแคชแล้ว จงตรวจสอบ

และอย่าปฏิบัติต่อ TTFB ราวกับแยกขาดจากการตัดสินใจด้าน product Personalization, experimentation, real-time inventory และ third-party services ล้วนมีต้นทุนด้าน latency บางอย่างคุ้มค่า บางอย่างเป็นเพียงความเคยชิน

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: เมื่อวินิจฉัย TTFB, Get Headers จะแสดงสถานะแคช เวลาการทำงานของเซิร์ฟเวอร์ และการเปลี่ยนเส้นทาง ซึ่งมักอธิบายได้ว่าความล่าช้ามาจากที่ใด

<!-- tool-cta:end -->

แผนแบบใจเย็น

TTFB ที่ช้ามักแก้ไขได้ เมื่อคุณหยุดมองมันเป็น “ปัญหาเซิร์ฟเวอร์” ที่คลุมเครือ วัด request ของเอกสาร แยกตามภูมิภาคและประเภทหน้า ตรวจสอบ headers เปรียบเทียบ client timing กับ origin timing จากนั้นแก้ bottleneck ที่ได้รับการยืนยันว่าใหญ่ที่สุด

เว็บไซต์ส่วนใหญ่ไม่ต้องการสถาปัตยกรรมแปลกใหม่ พวกเขาต้องการ cache misses ที่หลีกเลี่ยงได้ให้น้อยลง, งาน backend ที่ block น้อยลง, redirects ที่สะอาดขึ้น และความเข้าใจที่ชัดเจนขึ้นว่าอะไรต้องเกิดขึ้นก่อนส่ง byte แรก