ดูวิธีเพิ่มประสิทธิภาพสำหรับเมตริกเวลาที่ได้รับข้อมูลไบต์แรก
เผยแพร่เมื่อวันที่ 19 มกราคม 2023 อัปเดตล่าสุดเมื่อวันที่ 28 พฤศจิกายน 2025
เวลาที่ได้รับข้อมูลไบต์แรก (TTFB) เป็นเมตริกประสิทธิภาพพื้นฐานของเว็บที่มาก่อนเมตริกประสบการณ์ของผู้ใช้ที่มีความหมายอื่นๆ ทั้งหมด เช่น First Contentful Paint (FCP) และ Largest Contentful Paint (LCP) ซึ่งหมายความว่าค่า TTFB ที่สูงจะเพิ่มเวลาให้กับเมตริกที่ตามมา
เราขอแนะนำให้เซิร์ฟเวอร์ตอบสนองต่อคำขอการนำทางอย่างรวดเร็วพอเพื่อให้ผู้ใช้เปอร์เซ็นไทล์ที่ 75 ได้รับประสบการณ์ FCP ภายในเกณฑ์ "ดี" โดยทั่วไปแล้ว เว็บไซต์ส่วนใหญ่ควรพยายามให้มี TTFB ไม่เกิน 0.8 วินาที
วิธีวัด TTFB
ก่อนที่จะเพิ่มประสิทธิภาพ TTFB ได้ คุณต้องสังเกตว่า TTFB ส่งผลต่อผู้ใช้เว็บไซต์อย่างไร คุณควรใช้ข้อมูลภาคสนามเป็นแหล่งข้อมูลหลักในการสังเกต TTFB เนื่องจากได้รับผลกระทบจากการเปลี่ยนเส้นทาง ในขณะที่เครื่องมือที่อิงตามห้องปฏิบัติการมักจะวัดโดยใช้ URL สุดท้าย จึงทำให้ไม่พบความล่าช้าเพิ่มเติมนี้
PageSpeed Insights เป็นวิธีหนึ่งในการรับทั้งข้อมูลภาคสนามและข้อมูลในห้องปฏิบัติการสำหรับเว็บไซต์สาธารณะที่มีอยู่ในรายงานประสบการณ์ของผู้ใช้ Chrome
TTFB สำหรับผู้ใช้จริงจะแสดงในส่วนดูสิ่งที่ผู้ใช้จริงได้รับที่ด้านบน
สำหรับข้อมูลจากห้องปฏิบัติการ ปัญหา TTFB จะแสดงในข้อมูลเชิงลึกเวลาในการตอบสนองต่อคำขอเอกสาร
หากต้องการดูวิธีอื่นๆ ในการวัด TTFB ทั้งในภาคสนามและในห้องทดลอง โปรดดูหน้าเมตริก TTFB
ทำความเข้าใจความแตกต่างระหว่าง TTFB ในภาคสนามและในห้องปฏิบัติการ
TTFB ในห้องปฏิบัติการและในภาคสนามอาจแตกต่างกันได้หลายสาเหตุ และเมื่อแตกต่างกัน คุณควรทำความเข้าใจสาเหตุเพื่อให้สามารถใช้ข้อมูลในห้องปฏิบัติการเพื่อปรับปรุงประสบการณ์ของผู้ใช้ได้อย่างมีประสิทธิภาพ
เมื่อ TTFB ในห้องปฏิบัติการมีค่ามากกว่า TTFB ในภาคสนามมาก แสดงว่าสภาพแวดล้อมในห้องปฏิบัติการมีข้อจำกัดมากกว่าประสบการณ์ของผู้ใช้ทั่วไป ซึ่งไม่จำเป็นต้องเป็นปัญหา เนื่องจากผลลัพธ์และคำแนะนำของห้องทดลองยังคงถูกต้อง แต่อาจทำให้ผลกระทบและการปรับปรุงเกินจริง
เมื่อ TTFB ในภาคสนามมีค่ามากกว่า TTFB ในห้องทดลองมาก แสดงว่ามีปัญหาที่ไม่ปรากฏในการเรียกใช้ในห้องทดลอง เช่น การใช้การแคชฝั่งเซิร์ฟเวอร์ การเปลี่ยนเส้นทาง หรือความแตกต่างของเครือข่าย ในกรณีนี้ ผลการทดสอบและคำแนะนำอาจมีประโยชน์น้อยลง เนื่องจากไม่ได้ระบุปัญหาหลักอย่างใดอย่างหนึ่ง
หากต้องการดูว่าการแคชฝั่งเซิร์ฟเวอร์ส่งผลต่อ TTFB ในห้องปฏิบัติการหรือไม่ ให้ลองทดสอบหน้าเว็บที่ไม่ค่อยมีการเข้าชมหรือใช้พารามิเตอร์ของ URL อื่นเพื่อรับเนื้อหาที่ไม่ได้แคชเพื่อดูว่า TTFB สอดคล้องกับ TTFB ในภาคสนามมากขึ้นหรือไม่ นอกจากนี้ คุณยังสามารถข้ามการแคชฝั่งเซิร์ฟเวอร์ด้วยพารามิเตอร์ของ URL ที่เฉพาะเจาะจงได้ด้วย ดูส่วนเนื้อหาที่แคชไว้
สำหรับการเปลี่ยนเส้นทางและความแตกต่างของเครือข่าย การวิเคราะห์วิธีที่การเข้าชมมายังเว็บไซต์ของเราและแหล่งที่มาของการเข้าชมอาจเป็นประโยชน์ในการวินิจฉัยว่าสิ่งเหล่านั้นเป็นปัญหาที่อาจเกิดขึ้นหรือไม่
แก้ไขข้อบกพร่อง TTFB สูงในภาคสนามด้วย Server-Timing
คุณสามารถใช้ส่วนหัวการตอบกลับ Server-Timing ในแบ็กเอนด์ของแอปพลิเคชันเพื่อวัดกระบวนการแบ็กเอนด์ที่แตกต่างกันซึ่งอาจทำให้เกิดเวลาในการตอบสนองสูง โครงสร้างของค่าส่วนหัวมีความยืดหยุ่น โดยอย่างน้อยจะยอมรับแฮนเดิลที่คุณกำหนด ค่าที่ไม่บังคับ ได้แก่ ค่าระยะเวลา (ผ่าน dur) รวมถึงคำอธิบายที่มนุษย์อ่านได้ (ผ่าน desc)
คุณสามารถใช้ Serving-Timing เพื่อวัดกระบวนการแบ็กเอนด์ของแอปพลิเคชันได้หลายอย่าง แต่มีบางอย่างที่คุณอาจต้องให้ความสนใจเป็นพิเศษ ดังนี้
- การค้นหาฐานข้อมูล
- เวลาในการแสดงผลฝั่งเซิร์ฟเวอร์ (หากมี)
- การค้นหาดิสก์
- พบหรือไม่พบแคชของเซิร์ฟเวอร์ Edge (หากใช้ CDN)
ทุกส่วนของรายการ Server-Timing จะคั่นด้วยโคลอน และรายการหลายรายการจะคั่นด้วยคอมมาได้ ดังนี้
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
คุณตั้งค่าส่วนหัวได้โดยใช้ภาษาที่เลือกของแบ็กเอนด์แอปพลิเคชัน ตัวอย่างเช่น ใน PHP คุณสามารถตั้งค่าส่วนหัวได้ดังนี้
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
เมื่อตั้งค่าส่วนหัวนี้ ส่วนหัวจะแสดงข้อมูลที่คุณใช้ได้ทั้งในห้องทดลองและในภาคสนาม
ในช่องนี้ หน้าเว็บที่มีการตั้งค่าส่วนหัวการตอบกลับ Server-Timing จะป้อนข้อมูลพร็อพเพอร์ตี้ serverTiming ใน Navigation Timing API ดังนี้
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
ในห้องทดลอง ข้อมูลจากส่วนหัวการตอบกลับ Server-Timing จะแสดงเป็นภาพในแผงการกำหนดเวลาของแท็บเครือข่ายในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ดังนี้
ในกรณีนี้ ระบบจะใช้ Server-Timing เพื่อวัดว่าคำขอทรัพยากรเข้าถึงแคช CDN หรือไม่ และคำขอใช้เวลานานเท่าใดในการเข้าถึงเซิร์ฟเวอร์ Edge ของ CDN แล้วจึงเข้าถึงต้นทาง
เวลาของเซิร์ฟเวอร์ยังแสดงในแทร็กเครือข่ายของแผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ด้วย
เมื่อพิจารณาแล้วว่าคุณมี TTFB ที่เป็นปัญหาโดยการวิเคราะห์ข้อมูลที่มีอยู่ คุณก็สามารถดำเนินการแก้ไขปัญหาได้
วิธีเพิ่มประสิทธิภาพ TTFB
แง่มุมที่ท้าทายที่สุดในการเพิ่มประสิทธิภาพ TTFB คือแม้ว่าสแต็กฟรอนท์เอนด์ของเว็บจะเป็น HTML, CSS และ JavaScript เสมอ แต่สแต็กแบ็กเอนด์อาจแตกต่างกันอย่างมาก มีสแต็กแบ็กเอนด์และผลิตภัณฑ์ฐานข้อมูลจำนวนมากซึ่งแต่ละรายการมีเทคนิคการเพิ่มประสิทธิภาพของตนเอง ดังนั้น คู่มือนี้จึงมุ่งเน้นไปที่สิ่งที่ใช้ได้กับสถาปัตยกรรมส่วนใหญ่ แทนที่จะมุ่งเน้นเฉพาะคำแนะนำเฉพาะสแต็ก
คำแนะนำเฉพาะแพลตฟอร์ม
แพลตฟอร์มที่คุณใช้สำหรับเว็บไซต์อาจส่งผลต่อ TTFB อย่างมาก ตัวอย่างเช่น ประสิทธิภาพของ WordPress จะได้รับผลกระทบจากจำนวนและคุณภาพของปลั๊กอิน หรือธีมที่ใช้ แพลตฟอร์มอื่นๆ ก็ได้รับผลกระทบในลักษณะเดียวกันเมื่อมีการปรับแต่งแพลตฟอร์ม คุณควรดูเอกสารประกอบของแพลตฟอร์มเพื่อรับคำแนะนำเฉพาะของผู้ให้บริการเพื่อเสริมคำแนะนำด้านประสิทธิภาพทั่วไปในโพสต์นี้ นอกจากนี้ ข้อมูลเชิงลึกของ Lighthouse ยังมีคำแนะนำเฉพาะสแต็กแบบจำกัดด้วย
โฮสติ้ง โฮสติ้ง โฮสติ้ง
ก่อนที่จะพิจารณาแนวทางการเพิ่มประสิทธิภาพอื่นๆ คุณควรพิจารณาเรื่องโฮสติ้งเป็นอันดับแรก เราไม่มีคำแนะนำที่เฉพาะเจาะจงมากนัก แต่หลักการทั่วไปคือตรวจสอบว่าโฮสต์ของเว็บไซต์สามารถรองรับการเข้าชมที่คุณส่งไปได้
โดยทั่วไปแล้ว โฮสติ้งที่ใช้ร่วมกันจะช้ากว่า หากคุณใช้เว็บไซต์ส่วนตัวขนาดเล็กที่แสดงไฟล์แบบคงที่เป็นส่วนใหญ่ ก็อาจไม่มีปัญหา ใช้เทคนิคการเพิ่มประสิทธิภาพต่อไปนี้เพื่อช่วยลด TTFB ให้ได้มากที่สุด
อย่างไรก็ตาม หากคุณใช้งานแอปพลิเคชันขนาดใหญ่ที่มีผู้ใช้จำนวนมากซึ่งเกี่ยวข้องกับการปรับเปลี่ยนในแบบของคุณ การค้นหาฐานข้อมูล และการดำเนินการฝั่งเซิร์ฟเวอร์ที่เข้มข้นอื่นๆ ตัวเลือกโฮสติ้งจะมีความสำคัญอย่างยิ่งต่อการลด TTFB ในภาคสนาม
สิ่งที่ควรคำนึงถึงเมื่อเลือกผู้ให้บริการโฮสติ้งมีดังนี้
- อินสแตนซ์แอปพลิเคชันของคุณได้รับการจัดสรรหน่วยความจำเท่าใด หากแอปพลิเคชันมีหน่วยความจำไม่เพียงพอ ระบบจะทำงานหนักและพยายามแสดงหน้าเว็บให้เร็วที่สุด
- ผู้ให้บริการโฮสติ้งของคุณอัปเดตสแต็กแบ็กเอนด์ให้เป็นปัจจุบันอยู่เสมอหรือไม่ เมื่อมีการเปิดตัวภาษาแบ็กเอนด์ของแอปพลิเคชัน การใช้งาน HTTP และซอฟต์แวร์ฐานข้อมูลเวอร์ชันใหม่ ประสิทธิภาพในซอฟต์แวร์นั้นจะดีขึ้นเมื่อเวลาผ่านไป การร่วมมือกับผู้ให้บริการโฮสติ้งที่ให้ความสำคัญกับการบำรุงรักษาที่สำคัญประเภทนี้จึงเป็นสิ่งสำคัญ
- หากคุณมีข้อกำหนดเฉพาะเจาะจงมากสำหรับแอปพลิเคชันและต้องการสิทธิ์เข้าถึงไฟล์การกำหนดค่าเซิร์ฟเวอร์ในระดับต่ำสุด ให้สอบถามว่าการปรับแต่งแบ็กเอนด์ของอินสแตนซ์แอปพลิเคชันของคุณเองนั้นเหมาะสมหรือไม่
มีผู้ให้บริการโฮสติ้งจำนวนมากที่ดูแลสิ่งเหล่านี้ให้คุณ แต่หากคุณเริ่มสังเกตเห็นค่า TTFB ที่ยาวนานแม้ในผู้ให้บริการโฮสติ้งเฉพาะ ก็อาจเป็นสัญญาณว่าคุณอาจต้องประเมินความสามารถของผู้ให้บริการโฮสติ้งปัจจุบันอีกครั้งเพื่อให้คุณสามารถมอบประสบการณ์ของผู้ใช้ที่ดีที่สุดเท่าที่จะเป็นไปได้
ใช้เครือข่ายนำส่งข้อมูล (CDN)
หัวข้อการใช้งาน CDN เป็นหัวข้อที่พูดถึงกันบ่อย แต่ก็มีเหตุผลที่ดี นั่นคือคุณอาจมีแบ็กเอนด์ของแอปพลิเคชันที่ได้รับการเพิ่มประสิทธิภาพเป็นอย่างดี แต่ผู้ใช้ที่อยู่ห่างจากเซิร์ฟเวอร์ต้นทางอาจยังคงพบ TTFB สูงในภาคสนาม
CDN แก้ปัญหาเรื่องความใกล้ชิดของผู้ใช้จากเซิร์ฟเวอร์ต้นทางโดยใช้เครือข่ายเซิร์ฟเวอร์แบบกระจายที่แคชทรัพยากรในเซิร์ฟเวอร์ที่อยู่ใกล้กับผู้ใช้มากกว่าในทางกายภาพ เซิร์ฟเวอร์เหล่านี้เรียกว่าเซิร์ฟเวอร์ Edge
ผู้ให้บริการ CDN อาจให้สิทธิประโยชน์อื่นๆ นอกเหนือจากเซิร์ฟเวอร์ Edge ดังนี้
- โดยปกติแล้ว ผู้ให้บริการ CDN จะมีเวลาในการแปลง DNS ที่รวดเร็วมาก
- CDN มีแนวโน้มที่จะแสดงเนื้อหาจากเซิร์ฟเวอร์ Edge โดยใช้โปรโตคอลที่ทันสมัย เช่น HTTP/2 หรือ HTTP/3
- โดยเฉพาะอย่างยิ่ง HTTP/3 จะช่วยแก้ปัญหาการบล็อกที่ส่วนหัวของบรรทัดซึ่งมีอยู่ใน TCP (ซึ่ง HTTP/2 อาศัยอยู่) โดยใช้โปรโตคอล UDP
- CDN มักจะให้บริการ TLS เวอร์ชันใหม่ ซึ่งช่วยลดเวลาในการตอบสนองที่เกี่ยวข้องกับเวลาในการเจรจาต่อรอง TLS โดยเฉพาะอย่างยิ่ง TLS 1.3 ได้รับการออกแบบมาเพื่อให้การเจรจา TLS สั้นที่สุดเท่าที่จะเป็นไปได้
- ผู้ให้บริการ CDN บางรายมีฟีเจอร์ที่มักเรียกว่า "Edge Worker" ซึ่งใช้ API ที่คล้ายกับ Service Worker API เพื่อสกัดกั้นคำขอ จัดการการตอบกลับในการแคชไปยังเซิร์ฟเวอร์ปลายทางแบบเป็นโปรแกรม หรือเขียนการตอบกลับใหม่ทั้งหมด
- ผู้ให้บริการ CDN มีความเชี่ยวชาญอย่างมากในการเพิ่มประสิทธิภาพการบีบอัด การบีบอัดเป็นเรื่องที่ทำได้ยากด้วยตนเอง และอาจทำให้เวลาในการตอบสนองช้าลงในบางกรณีที่มีมาร์กอัปที่สร้างขึ้นแบบไดนามิก ซึ่งต้องบีบอัดแบบเรียลไทม์
- นอกจากนี้ ผู้ให้บริการ CDN จะแคชการตอบกลับที่บีบอัดสำหรับทรัพยากรแบบคงที่โดยอัตโนมัติ ซึ่งจะทำให้ได้อัตราส่วนการบีบอัดและเวลาในการตอบกลับที่ดีที่สุด
แม้ว่าการใช้ CDN จะต้องใช้ความพยายามในระดับที่แตกต่างกันไปตั้งแต่เล็กน้อยไปจนถึงมาก แต่ก็ควรให้ความสำคัญกับการเพิ่มประสิทธิภาพ TTFB เป็นอันดับต้นๆ หากเว็บไซต์ของคุณยังไม่ได้ใช้ CDN
ใช้เนื้อหาที่แคชไว้หากเป็นไปได้
CDN ช่วยให้แคชเนื้อหาที่เซิร์ฟเวอร์ Edge ซึ่งอยู่ใกล้กับผู้เข้าชมได้ หากเนื้อหามีการกำหนดค่าด้วยส่วนหัว HTTP Cache-Control ที่เหมาะสม แม้ว่าวิธีนี้จะไม่เหมาะกับเนื้อหาที่ปรับเปลี่ยนในแบบของคุณ แต่การกำหนดให้ต้องเดินทางกลับไปยังต้นทางอาจทำให้คุณค่าของ CDN ลดลงอย่างมาก
สำหรับเว็บไซต์ที่อัปเดตเนื้อหาบ่อยครั้ง แม้แต่เวลาในการแคชสั้นๆ ก็อาจส่งผลให้ประสิทธิภาพเพิ่มขึ้นอย่างเห็นได้ชัดสำหรับเว็บไซต์ที่มีผู้เข้าชมจำนวนมาก เนื่องจากมีเพียงผู้เข้าชมรายแรกในช่วงเวลานั้นเท่านั้นที่พบเวลาในการตอบสนองทั้งหมดกลับไปยังเซิร์ฟเวอร์ต้นทาง ขณะที่ผู้เข้าชมรายอื่นๆ ทั้งหมดสามารถใช้ทรัพยากรที่แคชไว้ซ้ำจากเซิร์ฟเวอร์ Edge ได้ CDN บางรายการอนุญาตให้ลบล้างแคชในรุ่นของเว็บไซต์ ซึ่งช่วยให้ได้รับประโยชน์จากทั้ง 2 อย่าง นั่นคือแคชมีอายุยาวนาน แต่ก็อัปเดตได้ทันทีเมื่อจำเป็น
แม้ว่าจะกำหนดค่าการแคชอย่างถูกต้องแล้ว แต่ก็อาจละเว้นได้โดยใช้พารามิเตอร์สตริงการค้นหาที่ไม่ซ้ำกันสำหรับการวัดผลการวิเคราะห์ ซึ่งอาจดูเหมือนเนื้อหาที่แตกต่างกันสำหรับ CDN แม้ว่าจะเป็นเนื้อหาเดียวกันก็ตาม ดังนั้นระบบจึงจะไม่ใช้เวอร์ชันที่แคชไว้
นอกจากนี้ ระบบอาจไม่แคชเนื้อหาที่เก่ากว่าหรือมีการเข้าชมน้อยกว่า ซึ่งอาจส่งผลให้ค่า TTFB ในบางหน้าสูงกว่าหน้าอื่นๆ การเพิ่มเวลาในการแคชจะช่วยลดผลกระทบนี้ได้ แต่โปรดทราบว่าการเพิ่มเวลาในการแคชจะเพิ่มโอกาสในการแสดงเนื้อหาที่อาจล้าสมัย
ผลกระทบของเนื้อหาที่แคชไว้ไม่ได้ส่งผลต่อผู้ที่ใช้ CDN เท่านั้น โครงสร้างพื้นฐานของเซิร์ฟเวอร์อาจต้องสร้างเนื้อหาจากการค้นหาฐานข้อมูลที่มีค่าใช้จ่ายสูงเมื่อไม่สามารถใช้เนื้อหาที่แคชไว้ซ้ำได้ ข้อมูลที่เข้าถึงบ่อยกว่าหรือหน้าเว็บที่แคชไว้ล่วงหน้ามักจะทำงานได้ดีกว่า
หลีกเลี่ยงการเปลี่ยนเส้นทางหน้าเว็บหลายครั้ง
ปัจจัยที่พบบ่อยอย่างหนึ่งที่ทำให้ TTFB สูงคือการเปลี่ยนเส้นทาง การเปลี่ยนเส้นทางจะเกิดขึ้นเมื่อคำขอการนำทางสำหรับเอกสารได้รับการตอบกลับที่แจ้งให้เบราว์เซอร์ทราบว่ามีทรัพยากรอยู่ในตำแหน่งอื่น การเปลี่ยนเส้นทาง 1 ครั้งอาจเพิ่มเวลาในการตอบสนองที่ไม่พึงประสงค์ให้กับคำขอการไปยังส่วนต่างๆ แต่จะแย่ลงไปอีกหากการเปลี่ยนเส้นทางนั้นชี้ไปยังทรัพยากรอื่นที่ส่งผลให้เกิดการเปลี่ยนเส้นทางอีกครั้ง และเป็นเช่นนี้ไปเรื่อยๆ ซึ่งอาจส่งผลกระทบต่อเว็บไซต์ที่ได้รับผู้เข้าชมจำนวนมากจากโฆษณาหรือจดหมายข่าว เนื่องจากเว็บไซต์เหล่านี้มักเปลี่ยนเส้นทางผ่านบริการวิเคราะห์เพื่อวัตถุประสงค์ในการวัดผล การกำจัดการเปลี่ยนเส้นทางภายใต้การควบคุมโดยตรงของคุณจะช่วยให้ได้ TTFB ที่ดี
การเปลี่ยนเส้นทางมี 2 ประเภท ได้แก่
- การเปลี่ยนเส้นทางต้นทางเดียวกัน ซึ่งการเปลี่ยนเส้นทางเกิดขึ้นทั้งหมดในเว็บไซต์ของคุณ
- การเปลี่ยนเส้นทางแบบข้ามต้นทาง ซึ่งการเปลี่ยนเส้นทางเกิดขึ้นในตอนแรกที่ต้นทางอื่น เช่น จากบริการการย่อ URL ของโซเชียลมีเดีย ก่อนที่จะมาถึงเว็บไซต์ของคุณ
มุ่งเน้นที่การกำจัดการเปลี่ยนเส้นทางแบบต้นทางเดียวกัน เนื่องจากเป็นสิ่งที่คุณควบคุมได้โดยตรง ซึ่งรวมถึงการตรวจสอบลิงก์ในเว็บไซต์เพื่อดูว่าลิงก์ใดส่งผลให้เกิดโค้ดตอบกลับ 302 หรือ 301 ซึ่งมักเกิดจากการไม่รวมรูปแบบ https:// (ดังนั้นเบราว์เซอร์จึงใช้ http:// เป็นค่าเริ่มต้นซึ่งจะเปลี่ยนเส้นทาง) หรือเนื่องจากไม่ได้รวมหรือยกเว้นเครื่องหมายทับปิดท้ายใน URL อย่างเหมาะสม
การเปลี่ยนเส้นทางแบบข้ามต้นทางนั้นยุ่งยากกว่าเนื่องจากมักอยู่นอกเหนือการควบคุมของคุณ แต่พยายามหลีกเลี่ยงการเปลี่ยนเส้นทางหลายครั้งหากเป็นไปได้ เช่น โดยใช้เครื่องมือย่อลิงก์หลายรายการเมื่อแชร์ลิงก์ ตรวจสอบว่า URL ที่ระบุให้ผู้ลงโฆษณาหรือจดหมายข่าวเป็น URL สุดท้ายที่ถูกต้อง เพื่อไม่ให้เพิ่มการเปลี่ยนเส้นทางอีกรายการหนึ่งลงในการเปลี่ยนเส้นทางที่บริการเหล่านั้นใช้
แหล่งที่มาสำคัญอีกแหล่งหนึ่งของเวลาในการเปลี่ยนเส้นทางอาจมาจากการเปลี่ยนเส้นทาง HTTP เป็น HTTPS วิธีหนึ่งที่คุณสามารถหลีกเลี่ยงปัญหานี้ได้คือการใช้ส่วนหัว Strict-Transport-Security (HSTS) ซึ่งบังคับใช้ HTTPS ในการเข้าชมต้นทางครั้งแรก จากนั้นจะบอกให้เบราว์เซอร์เข้าถึงต้นทางผ่านรูปแบบ HTTPS ทันทีในการเข้าชมครั้งต่อๆ ไป
เมื่อมีนโยบาย HSTS ที่ดีแล้ว คุณสามารถเร่งความเร็วในการเข้าชมต้นทางครั้งแรกได้โดยเพิ่มเว็บไซต์ลงในรายการโหลดล่วงหน้าของ HSTS
สตรีมมาร์กอัปไปยังเบราว์เซอร์
เบราว์เซอร์ได้รับการเพิ่มประสิทธิภาพให้ประมวลผลมาร์กอัปอย่างมีประสิทธิภาพเมื่อมีการสตรีม ซึ่งหมายความว่าระบบจะจัดการมาร์กอัปเป็นกลุ่มๆ เมื่อได้รับจากเซิร์ฟเวอร์ ซึ่งสำคัญอย่างยิ่งเมื่อมีเพย์โหลดมาร์กอัปขนาดใหญ่ เนื่องจากหมายความว่าเบราว์เซอร์สามารถแยกวิเคราะห์มาร์กอัปทีละส่วนได้ แทนที่จะต้องรอให้การตอบกลับทั้งหมดมาถึงก่อนจึงจะเริ่มแยกวิเคราะห์ได้
แม้ว่าเบราว์เซอร์จะจัดการมาร์กอัปสตรีมมิงได้ดี แต่คุณก็ต้องทำทุกอย่างที่ทำได้เพื่อให้สตรีมนั้นไหลต่อไป เพื่อให้มาร์กอัปบิตแรกๆ เริ่มทำงานโดยเร็วที่สุด หากแบ็กเอนด์ทำให้เกิดความล่าช้า นั่นคือปัญหา เนื่องจากสแต็กแบ็กเอนด์มีจำนวนมาก จึงอยู่นอกเหนือขอบเขตของคู่มือนี้ที่จะครอบคลุมสแต็กทุกรายการและปัญหาที่อาจเกิดขึ้นในแต่ละรายการ
ตัวอย่างเช่น React และเฟรมเวิร์กอื่นๆ ที่สามารถแสดงผลมาร์กอัปตามคำขอบนเซิร์ฟเวอร์ได้ใช้วิธีการแบบซิงโครนัสในการแสดงผลฝั่งเซิร์ฟเวอร์ อย่างไรก็ตาม React เวอร์ชันใหม่ๆ ได้ใช้เมธอดเซิร์ฟเวอร์สำหรับมาร์กอัปสตรีมมิงขณะที่แสดงผล ซึ่งหมายความว่าคุณไม่ต้องรอให้เมธอด API ของเซิร์ฟเวอร์ React แสดงผลการตอบกลับทั้งหมดก่อนที่จะส่ง
อีกวิธีหนึ่งในการตรวจสอบว่ามาร์กอัปสตรีมไปยังเบราว์เซอร์อย่างรวดเร็วคือการใช้การแสดงผลแบบคงที่ ซึ่งจะสร้างไฟล์ HTML ในระหว่างเวลาบิลด์ เมื่อมีไฟล์เต็มรูปแบบพร้อมใช้งานทันที เว็บเซิร์ฟเวอร์จะเริ่มส่งไฟล์ได้ทันที และลักษณะโดยธรรมชาติของ HTTP จะส่งผลให้เกิดมาร์กอัปสตรีมมิง แม้ว่าแนวทางนี้จะไม่เหมาะกับทุกหน้าในทุกเว็บไซต์ เช่น หน้าที่ต้องมีการตอบสนองแบบไดนามิกซึ่งเป็นส่วนหนึ่งของประสบการณ์ของผู้ใช้ แต่ก็อาจเป็นประโยชน์สำหรับหน้าเว็บที่ไม่ต้องปรับเปลี่ยนมาร์กอัปให้เหมาะกับผู้ใช้แต่ละราย
ใช้ Service Worker
Service Worker API อาจส่งผลอย่างมากต่อ TTFB สำหรับทั้งเอกสารและทรัพยากรที่เอกสารโหลด สาเหตุคือ Service Worker ทำหน้าที่เป็นพร็อกซีระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ แต่ผลกระทบต่อ TTFB ของเว็บไซต์จะขึ้นอยู่กับวิธีตั้งค่า Service Worker และการตั้งค่านั้นสอดคล้องกับข้อกำหนดของแอปพลิเคชันหรือไม่
- ใช้กลยุทธ์ stale-while-revalidate สำหรับเนื้อหา หากชิ้นงานอยู่ในแคชของ Service Worker ไม่ว่าจะเป็นเอกสารหรือทรัพยากรที่เอกสารต้องการ กลยุทธ์ stale-while-revalidate จะแสดงทรัพยากรนั้นจากแคชก่อน จากนั้นจะดาวน์โหลดชิ้นงานนั้นในเบื้องหลังและแสดงจากแคชสำหรับการโต้ตอบในอนาคต
- หากคุณมีทรัพยากรเอกสารที่ไม่ได้เปลี่ยนแปลงบ่อยนัก การใช้กลยุทธ์ stale-while-revalidate จะทำให้ TTFB ของหน้าเว็บทำงานได้เกือบจะทันที อย่างไรก็ตาม วิธีนี้อาจใช้ไม่ได้ผลหากเว็บไซต์ส่งมาร์กอัปที่สร้างขึ้นแบบไดนามิก เช่น มาร์กอัปที่เปลี่ยนแปลงตามการตรวจสอบสิทธิ์ของผู้ใช้ ในกรณีเช่นนี้ คุณจะต้องเข้าถึงเครือข่ายก่อนเสมอ เพื่อให้เอกสารเป็นเวอร์ชันล่าสุดที่สุด
- หากเอกสารโหลดทรัพยากรที่ไม่สำคัญซึ่งมีการเปลี่ยนแปลงค่อนข้างบ่อย แต่การดึงข้อมูลทรัพยากรที่ไม่มีการอัปเดตจะไม่ส่งผลต่อประสบการณ์ของผู้ใช้อย่างมาก เช่น รูปภาพบางรูปหรือทรัพยากรอื่นๆ ที่ไม่สำคัญ TTFB สำหรับทรัพยากรเหล่านั้นจะลดลงอย่างมากเมื่อใช้กลยุทธ์ stale-while-revalidate
- ใช้โมเดล App Shell สำหรับแอปพลิเคชันที่แสดงผลฝั่งไคลเอ็นต์ โมเดลนี้เหมาะที่สุดสำหรับ SPA ที่สามารถส่ง "เชลล์" ของหน้าเว็บได้ทันทีจากแคชของ Service Worker และเนื้อหาแบบไดนามิกของหน้าเว็บจะได้รับการป้อนข้อมูลและแสดงผลในภายหลังในวงจรของหน้าเว็บ
ใช้ 103 Early Hints สำหรับทรัพยากรที่สำคัญต่อการแสดงผล
ไม่ว่าแบ็กเอนด์ของแอปพลิเคชันจะได้รับการเพิ่มประสิทธิภาพดีเพียงใด เซิร์ฟเวอร์ก็อาจยังคงต้องทำงานจำนวนมากเพื่อเตรียมการตอบกลับ ซึ่งรวมถึงงานฐานข้อมูลที่มีค่าใช้จ่ายสูง (แต่จำเป็น) ซึ่งทำให้การตอบกลับการนำทางล่าช้ากว่าที่ควรจะเป็น ผลกระทบที่อาจเกิดขึ้นคือทรัพยากรที่สำคัญต่อการแสดงผลที่ตามมาบางรายการอาจล่าช้า เช่น CSS หรือ JavaScript (ในบางกรณี) ที่แสดงผลมาร์กอัปในฝั่งไคลเอ็นต์
ส่วนหัว 103 Early Hints คือโค้ดตอบกลับเบื้องต้นที่เซิร์ฟเวอร์สามารถส่งไปยังเบราว์เซอร์ได้ขณะที่แบ็กเอนด์กำลังเตรียมมาร์กอัป ส่วนหัวนี้ใช้เพื่อบอกใบ้เบราว์เซอร์ว่ามีทรัพยากรที่สำคัญต่อการแสดงผลซึ่งหน้าเว็บควรเริ่มดาวน์โหลดขณะที่กำลังเตรียมมาร์กอัป สำหรับเบราว์เซอร์ที่รองรับ ผลลัพธ์ที่ได้อาจเป็นการแสดงผลเอกสาร (CSS) ที่เร็วขึ้นและการโหลดหน้าเว็บที่รวดเร็วขึ้น
ข้อเสียอย่างหนึ่งของ 103 Early Hints คืออาจบดบัง TTFB "จริง" ของเว็บไซต์ได้ เช่นเดียวกับการแคช หากโครงสร้างพื้นฐานของเซิร์ฟเวอร์ทำงานช้า (เนื่องจากมีประสิทธิภาพต่ำหรือโค้ดต้องได้รับการเพิ่มประสิทธิภาพ) ปัญหานี้อาจไม่ชัดเจนนักเมื่อใช้ 103 Early Hints เนื่องจาก TTFB ดูเหมือนจะทำงานเร็ว เว็บไซต์ที่ใช้ 103 Early Hints ควรพิจารณาวัดเวลาเซิร์ฟเวอร์จริง (ผ่าน Server-Timing หรือ finalResponseHeadersStart ของ PerformanceNavigationTiming API)
บทสรุป
เนื่องจากสแต็กแอปพลิเคชันแบ็กเอนด์มีหลายชุดค่าผสม จึงไม่มีบทความใดที่สามารถสรุปทุกอย่างที่คุณทำได้เพื่อลด TTFB ของเว็บไซต์ อย่างไรก็ตาม คุณสามารถลองใช้ตัวเลือกต่อไปนี้เพื่อพยายามทำให้สิ่งต่างๆ ดำเนินไปได้เร็วขึ้นเล็กน้อยในฝั่งเซิร์ฟเวอร์
เช่นเดียวกับการเพิ่มประสิทธิภาพเมตริกทุกรายการ แนวทางนี้มีความคล้ายคลึงกันมาก นั่นคือวัด TTFB ในภาคสนาม ใช้เครื่องมือ Lab เพื่อเจาะลึกสาเหตุ แล้วใช้การเพิ่มประสิทธิภาพหากเป็นไปได้ แม้ว่าบางเทคนิคอาจใช้ไม่ได้กับสถานการณ์ของคุณ แต่บางเทคนิคก็น่าจะใช้ได้ เช่นเคย คุณจะต้องคอยตรวจสอบข้อมูลภาคสนามอย่างใกล้ชิด และทำการปรับเปลี่ยนตามความจำเป็นเพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่รวดเร็วที่สุด