ดูวิธีเพิ่มประสิทธิภาพเมตริกเวลาไปถึงไบต์แรก
Time to First Byte (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 สูงในฟิลด์ด้วย Server-Timing
คุณสามารถใช้ส่วนหัวการตอบกลับ Server-Timing ในแบ็กเอนด์ของแอปพลิเคชันเพื่อวัดกระบวนการแบ็กเอนด์ที่แตกต่างกันซึ่งอาจทำให้เวลาในการตอบสนองสูงได้ โครงสร้างของค่าส่วนหัวยืดหยุ่นได้ อย่างน้อยก็ยอมรับแฮนเดิลที่คุณกำหนด ค่าที่ไม่บังคับ ได้แก่ ค่าระยะเวลา (ผ่าน dur) รวมถึงคำอธิบายที่ไม่บังคับซึ่งมนุษย์อ่านได้ (ผ่าน desc)
Serving-Timing สามารถใช้เพื่อวัดกระบวนการแบ็กเอนด์ของแอปพลิเคชันได้มากมาย แต่ก็มีบางอย่างที่คุณอาจต้องให้ความสนใจเป็นพิเศษ ดังนี้
- การค้นหาฐานข้อมูล
- เวลาการแสดงผลฝั่งเซิร์ฟเวอร์ (หากมี)
- การกรอดิสก์
- การพบ/ไม่พบแคชของ Edge Server (หากใช้ 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 - $dbReadStarTime) / 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 รายการปรากฏให้เห็นในแท็บเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ในที่นี้ จะมีการใช้ Server-Timing เพื่อวัดว่าคำขอสำหรับทรัพยากรไปถึงแคช CDN หรือไม่ และใช้เวลานานเท่าใดกว่าที่คำขอจะไปถึง Edge Server ของ CDN จากนั้นจึงไปที่ต้นทาง
เมื่อคุณพิจารณาแล้วว่าคุณมี TTFB ที่มีปัญหาโดยการวิเคราะห์ข้อมูลที่มีอยู่ คุณก็สามารถแก้ไขปัญหานั้นต่อได้
วิธีเพิ่มประสิทธิภาพ TTFB
ส่วนที่ท้าทายที่สุดในการเพิ่มประสิทธิภาพ TTFB คือ แม้ว่าสแต็กฟรอนท์เอนด์ของเว็บจะเป็น HTML, CSS และ JavaScript เสมอ แต่สแต็กแบ็กเอนด์อาจแตกต่างกันไปอย่างมาก มีสแต็กแบ็กเอนด์และผลิตภัณฑ์ฐานข้อมูลจำนวนมากที่แต่ละรายการมีเทคนิคการเพิ่มประสิทธิภาพของตนเอง ดังนั้น คู่มือนี้จะมุ่งเน้นสิ่งที่มีผลกับสถาปัตยกรรมส่วนใหญ่ มากกว่าที่จะมุ่งเน้นเฉพาะคำแนะนำสแต็กเฉพาะ
คำแนะนำเฉพาะแพลตฟอร์ม
แพลตฟอร์มที่คุณใช้สำหรับเว็บไซต์อาจส่งผลกระทบอย่างมากต่อ TTFB ตัวอย่างเช่น ประสิทธิภาพของ WordPress ได้รับผลกระทบจากจำนวนและคุณภาพของปลั๊กอิน หรือธีมที่มีการใช้งาน แพลตฟอร์มอื่นๆ ก็ได้รับผลกระทบคล้ายๆ กันนี้เมื่อมีการปรับแต่งแพลตฟอร์ม คุณควรศึกษาเอกสารสำหรับแพลตฟอร์มของคุณเพื่อขอคำแนะนำเฉพาะผู้ให้บริการ เพื่อเสริมคำแนะนำเกี่ยวกับประสิทธิภาพโดยทั่วไปในโพสต์นี้ การตรวจสอบ Lighthouse เพื่อลดเวลาในการตอบกลับของเซิร์ฟเวอร์ยังมีคำแนะนำเฉพาะสแต็กที่จำกัดอีกด้วย
โฮสติ้ง, โฮสติ้ง, โฮสติ้ง
ก่อนที่คุณจะพิจารณาแนวทางการเพิ่มประสิทธิภาพอื่นๆ โฮสติ้งควรเป็นสิ่งแรกที่คุณคำนึงถึง ที่นี่ไม่มีคำแนะนำเฉพาะมากนัก แต่หลักการทั่วไปคือการตรวจสอบให้แน่ใจว่าโฮสต์ของเว็บไซต์สามารถจัดการการเข้าชมที่คุณส่งไปยังเว็บไซต์นั้นได้
โดยทั่วไปโฮสติ้งที่แชร์จะทำงานช้ากว่า หากคุณใช้งานเว็บไซต์ส่วนตัวขนาดเล็กที่แสดงไฟล์แบบคงที่เป็นส่วนใหญ่ ก็อาจไม่มีปัญหาใดๆ และเทคนิคการเพิ่มประสิทธิภาพต่อไปนี้จะช่วยให้คุณลด TTFB ลงได้มากที่สุด
อย่างไรก็ตาม หากคุณใช้งานแอปพลิเคชันขนาดใหญ่ที่มีผู้ใช้จำนวนมากที่เกี่ยวข้องกับการปรับเปลี่ยนในแบบของคุณ การค้นหาฐานข้อมูล และการดำเนินการฝั่งเซิร์ฟเวอร์อื่นๆ ที่ใช้ทรัพยากรมาก ตัวเลือกโฮสติ้งของคุณจะกลายเป็นปัจจัยสำคัญที่ทำให้ TTFB ในฟิลด์ดังกล่าวต่ำลง
สิ่งที่ควรระวังเมื่อเลือกผู้ให้บริการโฮสติ้ง
- อินสแตนซ์ของแอปพลิเคชันมีการจัดสรรหน่วยความจำเท่าใด หากแอปพลิเคชันของคุณมีหน่วยความจำไม่เพียงพอ แอปพลิเคชันอาจหยุดทำงานและประสบปัญหาในการแสดงหน้าเว็บให้เร็วที่สุดเท่าที่เป็นไปได้
- ผู้ให้บริการโฮสติ้งอัปเดตสแต็กแบ็กเอนด์ให้เป็นปัจจุบันไหม เมื่อมีการเปิดตัวภาษาแบ็กเอนด์ของแอปพลิเคชัน การใช้งาน HTTP และซอฟต์แวร์ฐานข้อมูลเวอร์ชันใหม่ ประสิทธิภาพในซอฟต์แวร์นั้นจะพัฒนาขึ้นตามกาลเวลา สิ่งสำคัญคือการทำงานร่วมกับผู้ให้บริการโฮสติ้งที่ให้ความสำคัญกับการบำรุงรักษาที่สำคัญประเภทนี้
- หากคุณมีข้อกำหนดแอปพลิเคชันที่เฉพาะเจาะจงมากและต้องการการเข้าถึงไฟล์การกำหนดค่าเซิร์ฟเวอร์ในระดับสูงสุด ให้สอบถามว่าการปรับแต่งแบ็กเอนด์ของอินสแตนซ์แอปพลิเคชันของคุณเองเหมาะสมหรือไม่
มีผู้ให้บริการโฮสติ้งหลายรายที่จะดูแลสิ่งเหล่านี้ให้คุณ แต่หากคุณเริ่มสังเกตเห็นค่า TTFB ยาวๆ แม้แต่ในผู้ให้บริการโฮสติ้งเฉพาะ นี่อาจเป็นสัญญาณว่าคุณอาจต้องประเมินความสามารถของผู้ให้บริการโฮสติ้งปัจจุบันของคุณอีกครั้งเพื่อมอบประสบการณ์ของผู้ใช้ที่ดีที่สุดเท่าที่จะเป็นไปได้
ใช้เครือข่ายนำส่งข้อมูล (CDN)
หัวข้อการใช้ CDN เป็นหัวข้อที่ใช้งานได้ดี แต่ก็มีเหตุผลที่ดี นั่นคือ คุณอาจมีแบ็กเอนด์ของแอปพลิเคชันที่เพิ่มประสิทธิภาพอย่างดีแล้ว แต่ผู้ใช้ที่อยู่ไกลจากเซิร์ฟเวอร์ต้นทางอาจยังได้รับประสบการณ์ TTFB สูงในการทำงาน
CDN ช่วยแก้ปัญหาความใกล้ของผู้ใช้จากเซิร์ฟเวอร์ต้นทางของคุณ โดยใช้เครือข่ายเซิร์ฟเวอร์แบบกระจายที่แคชทรัพยากรบนเซิร์ฟเวอร์ที่อยู่ใกล้ผู้ใช้ของคุณมากขึ้น เซิร์ฟเวอร์เหล่านี้เรียกว่าเซิร์ฟเวอร์ Edge
ผู้ให้บริการ CDN อาจมีสิทธิประโยชน์นอกเหนือจาก Edge Server ด้วย ดังนี้
- ผู้ให้บริการ CDN มักจะใช้เวลาในการแก้ปัญหา DNS ที่เร็วมาก
- CDN อาจแสดงเนื้อหาของคุณจาก Edge Server โดยใช้โปรโตคอลสมัยใหม่ เช่น HTTP/2 หรือ HTTP/3
- HTTP/3 ช่วยแก้ปัญหาการบล็อกส่วนหัว ซึ่งอยู่ใน TCP (ซึ่ง HTTP/2 ใช้) โดยใช้โปรโตคอล UUD
- CDN มีแนวโน้มที่จะมี TLS เวอร์ชันที่ทันสมัย ซึ่งจะลดเวลาในการตอบสนองที่เกี่ยวข้องกับเวลาในการเจรจา TLS โดยเฉพาะอย่างยิ่ง TLS 1.3 ได้รับการออกแบบมาเพื่อให้การเจรจา TLS เป็นไปอย่างราบรื่นที่สุด
- ผู้ให้บริการ CDN บางรายมีฟีเจอร์ที่มักเรียกว่า " Edge Worker" ซึ่งใช้ API คล้ายกับของ Service Worker API เพื่อสกัดกั้นคำขอ จัดการการตอบกลับในแคช Edge แบบเป็นโปรแกรม หรือเขียนการตอบกลับทั้งหมด
- ผู้ให้บริการ CDN มีการเพิ่มประสิทธิภาพสำหรับการบีบอัดได้ดีมาก การบีบอัดนั้นยุ่งยากในการจัดการโดยตรง และอาจทำให้เวลาในการตอบสนองช้าลงในบางกรณี หากใช้มาร์กอัปที่สร้างขึ้นแบบไดนามิก ซึ่งต้องบีบอัดทันที
- ผู้ให้บริการ CDN จะแคชการตอบกลับที่บีบอัดโดยอัตโนมัติสำหรับทรัพยากรแบบคงที่ ซึ่งจะเป็นส่วนผสมที่ดีที่สุดของอัตราส่วนการบีบอัดและเวลาในการตอบกลับ
แม้ว่าการนำ CDN มาใช้จะใช้ความพยายามที่แตกต่างกันตั้งแต่เพียงเล็กน้อยไปจนถึงอย่างมาก แต่คุณควรให้ความสำคัญกับการเพิ่มประสิทธิภาพ TTFB หากเว็บไซต์ของคุณยังไม่ได้ใช้ CDN
ใช้เนื้อหาที่แคชไว้หากเป็นไปได้
CDN อนุญาตให้มีการแคชเนื้อหาใน Edge Server ที่อยู่ใกล้ผู้เข้าชมมากกว่า หากเนื้อหาได้รับการกำหนดค่าด้วยส่วนหัว HTTP Cache-Control ที่เหมาะสม แม้ว่าวิธีนี้จะไม่เหมาะสำหรับเนื้อหาที่ปรับเปลี่ยนให้เหมาะกับแต่ละบุคคล แต่การย้อนกลับไปที่ต้นทางอาจลดคุณค่าของ CDN ได้อย่างมาก
สำหรับเว็บไซต์ที่อัปเดตเนื้อหาบ่อยๆ การแคชเป็นระยะเวลาสั้นๆ อาจทำให้เว็บไซต์ที่ไม่ว่างเพิ่มขึ้นอย่างเห็นได้ชัด เนื่องจากมีเพียงผู้เข้าชมครั้งแรกในช่วงเวลานั้นเท่านั้นที่เวลาในการตอบสนองกลับไปยังเซิร์ฟเวอร์ต้นทาง ในขณะที่ผู้เข้าชมรายอื่นๆ ทั้งหมดสามารถนำทรัพยากรที่แคชไว้จาก EDGE Server กลับมาใช้ใหม่ได้ CDN บางจุดอนุญาตให้มีการเอาข้อมูลเก่าในแคชออกในเว็บไซต์ ทำให้ได้รับประโยชน์จากทั้ง 2 แพลตฟอร์ม ใช้เวลาแคชที่นาน แต่มีการอัปเดตทันทีเมื่อจำเป็น
แม้ว่าคุณจะกําหนดค่าการแคชอย่างถูกต้อง แต่ก็ไม่ต้องใช้พารามิเตอร์สตริงคําค้นหาที่ไม่ซ้ำกันสําหรับการวัดผลข้อมูลวิเคราะห์ เนื้อหาเหล่านี้อาจดูเหมือนเนื้อหาที่แตกต่างกันใน CDN ถึงแม้จะเหมือนกันก็ตาม ดังนั้นจะไม่มีการใช้เวอร์ชันที่แคชไว้
ระบบอาจไม่แคชเนื้อหาเก่าหรือที่เข้าชมน้อยกว่าด้วย ซึ่งอาจทำให้ค่า TTFB ในบางหน้าสูงกว่าหน้าอื่นๆ การเพิ่มเวลาในการแคชจะช่วยลดผลกระทบจากปัญหานี้ได้ แต่โปรดทราบว่าเมื่อแคชเพิ่มขึ้นก็มีโอกาสที่จะแสดงเนื้อหาที่อาจล้าสมัยมากขึ้น
ผลกระทบจากเนื้อหาที่แคชไม่ได้ส่งผลกระทบต่อผู้ที่ใช้ CDN เท่านั้น โครงสร้างพื้นฐานของเซิร์ฟเวอร์อาจต้องสร้างเนื้อหาจากการค้นหาฐานข้อมูลที่มีราคาแพง เมื่อเนื้อหาที่แคชไม่สามารถนำมาใช้ซ้ำได้ ข้อมูลที่เข้าถึงบ่อยหรือหน้าเว็บที่แคชล่วงหน้ามักจะทำงานได้ดีกว่า
หลีกเลี่ยงการเปลี่ยนเส้นทางหน้าเว็บหลายครั้ง
ปัจจัยหนึ่งที่ทำให้ TTFB มีค่าสูงขึ้นคือการเปลี่ยนเส้นทาง การเปลี่ยนเส้นทางเกิดขึ้นเมื่อคำขอการนำทางสำหรับเอกสารได้รับการตอบกลับที่แจ้งให้เบราว์เซอร์ทราบว่ามีทรัพยากรอยู่ที่ตำแหน่งอื่น การเปลี่ยนเส้นทางแบบหนึ่งอาจเพิ่มเวลาในการตอบสนองที่ไม่พึงประสงค์ให้กับคำขอนำทางได้ แต่จะแย่ลงได้ถ้าการเปลี่ยนเส้นทางดังกล่าวชี้ไปยังทรัพยากรอื่นที่ทำให้เกิดการเปลี่ยนเส้นทางอื่น และเป็นเช่นนั้นไปเรื่อยๆ ซึ่งอาจส่งผลกระทบต่อเว็บไซต์ที่ได้รับผู้เข้าชมจำนวนมากจากโฆษณาหรือจดหมายข่าว เนื่องจากเว็บไซต์เหล่านี้มักจะเปลี่ยนเส้นทางผ่านบริการการวิเคราะห์เพื่อวัตถุประสงค์ในการวัดผล การกำจัดการเปลี่ยนเส้นทางภายใต้การควบคุมโดยตรงของคุณจะช่วยให้ได้ TTFB ที่ดี
การเปลี่ยนเส้นทางมี 2 ประเภท ได้แก่
- การเปลี่ยนเส้นทางต้นทางเดียวกัน ซึ่งการเปลี่ยนเส้นทางจะเกิดขึ้นทั้งหมดในเว็บไซต์ของคุณ
- การเปลี่ยนเส้นทางข้ามต้นทาง ซึ่งการเปลี่ยนเส้นทางจะเกิดขึ้นในตอนแรกในต้นทางอื่น เช่น จากบริการย่อ URL ของโซเชียลมีเดีย เช่น ก่อนที่จะมาที่เว็บไซต์
คุณต้องมุ่งเน้นที่การกำจัดการเปลี่ยนเส้นทางต้นทางเดียวกัน เนื่องจากคุณจะสามารถควบคุมได้โดยตรง การดำเนินการนี้จะต้องมีการตรวจสอบลิงก์ในเว็บไซต์ของคุณเพื่อดูว่ามีลิงก์ใดที่ทำให้เกิดเป็นโค้ดตอบกลับ 302 หรือ 301 หรือไม่ ซึ่งมักเป็นผลมาจากการไม่รวมรูปแบบ https:// (ดังนั้นเบราว์เซอร์จะมีค่าเริ่มต้นเป็น http:// ซึ่งจะเปลี่ยนเส้นทางในภายหลัง) หรือเนื่องจากไม่มีการรวมหรือยกเว้นเครื่องหมายทับอย่างเหมาะสมใน URL
การเปลี่ยนเส้นทางแบบข้ามต้นทางจะยุ่งยากกว่า เนื่องจากมักอยู่นอกเหนือการควบคุมของคุณ แต่ให้พยายามหลีกเลี่ยงการเปลี่ยนเส้นทางหลายครั้งหากทำได้ เช่น การใช้โปรแกรมย่อลิงก์หลายรายการเมื่อแชร์ลิงก์ ตรวจสอบว่า URL ที่ให้ไว้กับผู้ลงโฆษณาหรือจดหมายข่าวเป็น URL สุดท้ายที่ถูกต้อง จะได้ไม่เพิ่มการเปลี่ยนเส้นทางอีกไปยัง URL ที่บริการเหล่านั้นใช้
แหล่งที่มาที่สำคัญอีกอย่างหนึ่งของเวลาในการเปลี่ยนเส้นทางอาจมาจากการเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS วิธีหนึ่งที่จะช่วยแก้ปัญหานี้ได้คือการใช้ส่วนหัว Strict-Transport-Security (HSTS) ซึ่งจะบังคับใช้ HTTPS กับการเข้าชมต้นทางครั้งแรก จากนั้นจะแจ้งให้เบราว์เซอร์เข้าถึงต้นทางผ่านรูปแบบ HTTPS ทันทีสำหรับการเข้าชมในอนาคต
เมื่อมีนโยบาย HSTS ที่ถูกต้องแล้ว คุณสามารถเพิ่มความเร็วให้กับการเข้าชมต้นทางครั้งแรกได้โดยเพิ่มเว็บไซต์ลงในรายการโหลดล่วงหน้าของ HSTS
สตรีมมาร์กอัปไปยังเบราว์เซอร์
เบราว์เซอร์ได้รับการเพิ่มประสิทธิภาพเพื่อประมวลผลมาร์กอัปอย่างมีประสิทธิภาพเมื่อมีการสตรีม ซึ่งหมายความว่ามาร์กอัปจะถูกจัดการเป็นกลุ่มเมื่อมาจากเซิร์ฟเวอร์ นี่เป็นเรื่องที่สำคัญมากในการลดหย่อนเพย์โหลดของมาร์กอัปขนาดใหญ่ เนื่องจากจะทำให้เบราว์เซอร์แยกวิเคราะห์มาร์กอัปชิ้นดังกล่าวเป็นส่วนๆ ได้ แทนที่จะต้องรอการตอบกลับทั้งหมดก่อนจึงจะเริ่มการแยกวิเคราะห์ได้
แม้ว่าเบราว์เซอร์จะจัดการมาร์กอัปของสตรีมมิงได้เป็นอย่างดี แต่ก็ต้องทำทุกวิถีทางเพื่อให้สตรีมมีความต่อเนื่องเพื่อให้มาร์กอัปส่วนแรกเริ่มจะพร้อมใช้งานโดยเร็วที่สุด หากแบ็กเอนด์ดำเนินการอยู่ได้ แสดงว่าเป็นปัญหา เนื่องจากสแต็กแบ็กเอนด์มีมากมาย จึงอยู่นอกเหนือขอบเขตของคู่มือนี้ โดยจะครอบคลุมทุกสแต็กและปัญหาที่อาจเกิดขึ้นในแต่ละสแต็ก
ตัวอย่างเช่น React และเฟรมเวิร์กอื่นๆ ที่แสดงผลมาร์กอัปตามคำขอบนเซิร์ฟเวอร์ได้ใช้วิธีการแบบซิงโครนัสในการแสดงผลฝั่งเซิร์ฟเวอร์ อย่างไรก็ตาม React เวอร์ชันใหม่ได้ใช้เมธอดของเซิร์ฟเวอร์สำหรับสตรีมมาร์กอัปขณะที่กำลังแสดงผล ซึ่งหมายความว่าคุณไม่ต้องรอให้เมธอด React Server API แสดงผลการตอบกลับทั้งหมดก่อนที่จะส่ง
อีกวิธีหนึ่งในการตรวจสอบว่ามาร์กอัปสตรีมไปยังเบราว์เซอร์อย่างรวดเร็วคือการใช้การแสดงผลแบบคงที่ซึ่งจะสร้างไฟล์ HTML ในระหว่างเวลาบิลด์ เมื่อมีไฟล์แบบเต็มพร้อมใช้งานทันที เว็บเซิร์ฟเวอร์จะเริ่มส่งไฟล์ได้ทันที และลักษณะการทำงานโดยธรรมชาติของ HTTP จะส่งผลให้มีมาร์กอัปสตรีมมิง แม้ว่าวิธีนี้จะไม่ได้เหมาะกับทุกหน้าในเว็บไซต์บางแห่ง เช่น หน้าเว็บที่ต้องใช้การตอบกลับแบบไดนามิกเพื่อเป็นส่วนหนึ่งของประสบการณ์ของผู้ใช้ แต่อาจเป็นประโยชน์สำหรับหน้าเว็บที่ไม่ต้องการมาร์กอัปเพื่อปรับเปลี่ยนสำหรับผู้ใช้บางราย
ใช้ Service Worker
Service Worker API อาจมีผลกระทบอย่างมากต่อ TTFB สำหรับทั้งเอกสารและทรัพยากรที่โหลด เนื่องจากโปรแกรมทำงานของบริการทำหน้าที่เป็นพร็อกซีระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ แต่จะส่งผลต่อ TTFB ของเว็บไซต์หรือไม่นั้นขึ้นอยู่กับวิธีตั้งค่า Service Worker และการตั้งค่านั้นสอดคล้องกับข้อกำหนดของแอปพลิเคชันหรือไม่
- ใช้กลยุทธ์ที่ไม่มีการอัปเดตขณะตรวจสอบความถูกต้องอีกครั้งสำหรับเนื้อหา หากเนื้อหาอยู่ในแคชของ Service Worker ไม่ว่าจะเป็นเอกสารหรือทรัพยากรที่เอกสารต้องการ กลยุทธ์ที่ไม่มีการอัปเดตขณะตรวจสอบความถูกต้องจะให้บริการทรัพยากรนั้นจากแคชก่อน จากนั้นจะดาวน์โหลดเนื้อหานั้นในเบื้องหลังและแสดงจากแคชสำหรับการโต้ตอบในอนาคต
- หากคุณมีทรัพยากรเอกสารที่ไม่ได้เปลี่ยนแปลงบ่อยนัก การใช้กลยุทธ์ที่ไม่มีการอัปเดตขณะตรวจสอบความถูกต้องอีกครั้งอาจทำให้ TTFB ของหน้าเว็บเกือบจะทันที อย่างไรก็ตาม การดำเนินการนี้จะทำงานได้ไม่ดีหากเว็บไซต์ของคุณส่งมาร์กอัปที่สร้างขึ้นแบบไดนามิก เช่น มาร์กอัปที่เปลี่ยนแปลงตามการตรวจสอบสิทธิ์ของผู้ใช้ ในกรณีดังกล่าว ก็จะต้องเชื่อมต่อเครือข่ายก่อนเสมอ เพื่อให้เอกสารมีความใหม่ที่สุดเท่าที่จะเป็นไปได้
- หากเอกสารของคุณโหลดทรัพยากรที่ไม่สำคัญซึ่งมีการเปลี่ยนแปลงในบางความถี่ แต่การดึงข้อมูลทรัพยากรที่ไม่มีการอัปเดตจะไม่ส่งผลต่อประสบการณ์ของผู้ใช้มากนัก เช่น รูปภาพที่เลือกหรือทรัพยากรอื่นๆ ที่ไม่สำคัญ ระบบอาจลด TTFB สำหรับทรัพยากรเหล่านั้นเป็นอย่างมากโดยใช้กลยุทธ์ที่ไม่มีการอัปเดตขณะตรวจสอบความถูกต้องอีกครั้ง
- ใช้โมเดล App Shell สำหรับแอปพลิเคชันที่แสดงผลโดยไคลเอ็นต์ โมเดลนี้เหมาะกับ SPA ที่สามารถนำ "เชลล์" ของหน้าเว็บจากแคชของ Service Worker ได้ทันที และเนื้อหาแบบไดนามิกของหน้าเว็บจะได้รับการสร้างขึ้นและแสดงผลในภายหลังในวงจรของหน้า
ใช้ 103 Early Hints สำหรับทรัพยากรที่สำคัญในการแสดงผล
ไม่ว่าแบ็กเอนด์แอปพลิเคชันของคุณจะได้รับการปรับปรุงประสิทธิภาพดีเพียงใด อาจยังมีงานอีกมากมายที่เซิร์ฟเวอร์ต้องทำเพื่อเตรียมการตอบสนอง รวมถึงงานฐานข้อมูลที่มีราคาแพง (แต่จำเป็น) ซึ่งทำให้การตอบสนองของการนำทางมาถึงอย่างรวดเร็วที่สุดเท่าที่ทำได้ ผลกระทบที่อาจเกิดขึ้นจากกรณีนี้คือ ทรัพยากรที่สำคัญในการแสดงผลในภายหลังบางรายการอาจล่าช้า เช่น CSS หรือในบางกรณีอาจแสดงผลมาร์กอัปบนไคลเอ็นต์
ส่วนหัว 103 Early Hints เป็นโค้ดตอบกลับล่วงหน้าที่เซิร์ฟเวอร์สามารถส่งไปยังเบราว์เซอร์ขณะที่แบ็กเอนด์กำลังยุ่งอยู่กับการเตรียมมาร์กอัป ส่วนหัวนี้สามารถใช้บอกใบ้ให้เบราว์เซอร์มีทรัพยากรที่สำคัญในการแสดงผล ซึ่งหน้าเว็บควรเริ่มดาวน์โหลดขณะเตรียมมาร์กอัป เนื่องจากเบราว์เซอร์ที่รองรับ เอฟเฟกต์ดังกล่าวจะช่วยให้แสดงผลเอกสาร (CSS) ได้เร็วขึ้นและความพร้อมใช้งานของฟังก์ชันหลักของหน้า (JavaScript) ได้เร็วขึ้น
บทสรุป
เนื่องจากชุดสแต็กแอปพลิเคชันแบ็กเอนด์มีมากมาย จึงไม่มีบทความใดสรุปทุกอย่างที่ทําได้เพื่อลด TTFB ของเว็บไซต์ได้ อย่างไรก็ตาม ต่อไปนี้เป็นตัวเลือกบางอย่างที่คุณสามารถลองใช้เพื่อทำสิ่งต่างๆ ให้เสร็จสิ้นได้เร็วขึ้นเล็กน้อยสำหรับฝั่งเซิร์ฟเวอร์
วิธีการก็คล้ายกันมากเช่นเดียวกับการเพิ่มประสิทธิภาพเมตริกทุกเมตริก นั่นคือ วัด TTFB ภาคสนาม ใช้เครื่องมือในห้องทดลองเพื่อเจาะลึกถึงสาเหตุต่างๆ แล้วจึงใช้การเพิ่มประสิทธิภาพหากเป็นไปได้ เทคนิคบางอย่างอาจใช้ไม่ได้กับสถานการณ์ของคุณ แต่บางเทคนิคก็ใช้ได้ และเช่นเคย คุณยังต้องติดตามข้อมูลภาคสนามอย่างใกล้ชิดและทำการปรับเปลี่ยนตามความจำเป็นเพื่อให้มั่นใจว่าผู้ใช้จะได้รับประสบการณ์การใช้งานที่เร็วที่สุด
รูปภาพหลักโดย Taylor Vick ที่มาจาก Unsplash