ดูวิธีเพิ่มประสิทธิภาพให้เมตริกจำนวนวันจนถึงไบต์แรก
Time to First Byte (TTFB) เป็นเมตริกประสิทธิภาพพื้นฐานบนเว็บที่แสดงก่อนเมตริกประสบการณ์ของผู้ใช้ที่มีความหมายอื่นๆ เช่น First Contentful Paint (FCP) และ Largest Contentful Paint (LCP) ซึ่งหมายความว่าค่า TTFB ที่สูงจะเพิ่มเวลาให้กับเมตริกที่ตามมา
ขอแนะนำให้เซิร์ฟเวอร์ตอบกลับคำขอการนำทางอย่างรวดเร็วพอ เพื่อให้ผู้ใช้ในเปอร์เซ็นไทล์ที่ 75 พบ FCP อยู่ในเกณฑ์ "ดี" โดยทั่วไป เว็บไซต์ส่วนใหญ่ควรพยายามให้มี TTFB ไม่เกิน 0.8 วินาที
วิธีวัด 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 ของ CDN และต้นทาง
เมื่อคุณพิจารณาได้ว่าคุณมี TTFB ที่มีปัญหาโดยการวิเคราะห์ข้อมูลที่มีอยู่ คุณสามารถดำเนินการแก้ไขปัญหาต่อได้
วิธีเพิ่มประสิทธิภาพ TTFB
สิ่งที่ท้าทายที่สุดของการเพิ่มประสิทธิภาพ TTFB คือ แม้ว่าสแต็กฟรอนท์เอนด์ของเว็บจะเป็น HTML, CSS และ JavaScript เสมอ แต่สแต็กแบ็กเอนด์อาจแตกต่างกันอย่างมาก มีสแต็กแบ็กเอนด์และผลิตภัณฑ์ฐานข้อมูลมากมายที่มีเทคนิคการเพิ่มประสิทธิภาพเป็นของตัวเอง ดังนั้น คู่มือนี้จะเน้นสิ่งที่ใช้กับสถาปัตยกรรมส่วนใหญ่ แทนที่จะมุ่งเน้นคำแนะนำเฉพาะสแต็กเพียงอย่างเดียว
คำแนะนำเฉพาะแพลตฟอร์ม
แพลตฟอร์มที่คุณใช้สำหรับเว็บไซต์อาจส่งผลกระทบอย่างมากต่อ TTFB ตัวอย่างเช่น ประสิทธิภาพของ WordPress ขึ้นอยู่กับจำนวนและคุณภาพของปลั๊กอินหรือธีมที่ใช้ แพลตฟอร์มอื่นๆ จะได้รับผลกระทบที่คล้ายกันเมื่อปรับแต่งแพลตฟอร์ม คุณควรอ่านเอกสารสำหรับแพลตฟอร์มของคุณ เพื่อขอคำแนะนำเฉพาะผู้ให้บริการ เพื่อเสริมคำแนะนำด้านประสิทธิภาพโดยทั่วไปในโพสต์นี้ การตรวจสอบ Lighthouse สำหรับการลดเวลาในการตอบกลับของเซิร์ฟเวอร์จะมีคําแนะนําเฉพาะสำหรับสแต็กที่จำกัดด้วย
โฮสติ้ง, การโฮสต์, การโฮสต์
ก่อนจะลองพิจารณาวิธีการเพิ่มประสิทธิภาพอื่นๆ โฮสติ้งควรเป็นสิ่งแรกที่คุณพิจารณา ไม่มีคำแนะนำที่เฉพาะเจาะจงมากนักที่สามารถเสนอที่นี่ได้ แต่กฎทั่วไปคือ การตรวจสอบว่าโฮสต์ของเว็บไซต์สามารถจัดการการเข้าชมที่คุณส่งเข้ามาได้
โดยทั่วไปโฮสติ้งที่ใช้ร่วมกันจะทำงานช้าลง หากคุณกำลังทำเว็บไซต์ส่วนตัวขนาดเล็กซึ่งให้บริการไฟล์แบบคงที่เป็นส่วนใหญ่ เรื่องนี้ก็น่าจะเพียงพอได้ และเทคนิคการเพิ่มประสิทธิภาพบางอย่างต่อไปนี้จะช่วยให้คุณลดการทำงานของ TTFB ลงมากที่สุดเท่าที่เป็นไปได้
อย่างไรก็ตาม หากคุณกำลังใช้แอปพลิเคชันขนาดใหญ่ที่มีผู้ใช้จำนวนมากซึ่งเกี่ยวข้องกับการปรับเปลี่ยนในแบบของคุณ การค้นหาฐานข้อมูล และการดำเนินการอื่นๆ ฝั่งเซิร์ฟเวอร์ที่เข้มข้น การเลือกโฮสติ้งของคุณจะมีความสำคัญต่อการลด TTFB ลงภาคสนาม
ข้อควรระวังเมื่อเลือกผู้ให้บริการโฮสติ้งมีดังนี้
- อินสแตนซ์ของแอปพลิเคชันมีการจัดสรรหน่วยความจำเท่าใด หากแอปพลิเคชันมีหน่วยความจำไม่เพียงพอ ระบบจะเร่งการแสดงผลและประสบปัญหาในการแสดงหน้าเว็บโดยเร็วที่สุด
- ผู้ให้บริการโฮสติ้งให้สแต็กแบ็กเอนด์ของคุณเป็นปัจจุบันไหม เมื่อมีการเปิดตัวภาษาแบ็กเอนด์ของแอปพลิเคชัน การใช้งาน HTTP และซอฟต์แวร์ฐานข้อมูลเวอร์ชันใหม่ ประสิทธิภาพของซอฟต์แวร์ดังกล่าวจะได้รับการปรับปรุงเมื่อเวลาผ่านไป การทำงานร่วมกับผู้ให้บริการโฮสติ้งที่ให้ความสำคัญกับการบำรุงรักษาประเภทนี้เป็นสิ่งสำคัญ
- หากมีความต้องการเฉพาะของแอปพลิเคชันและต้องการสิทธิ์เข้าถึงไฟล์การกำหนดค่าเซิร์ฟเวอร์ในระดับต่ำสุด ให้สอบถามว่าการปรับแต่งแบ็กเอนด์ของอินสแตนซ์แอปพลิเคชันของคุณเองเหมาะสมหรือไม่
มีผู้ให้บริการโฮสติ้งหลายรายที่ดูแลสิ่งเหล่านี้ให้กับคุณ แต่หากคุณเริ่มสังเกตเห็นค่า TTFB ที่ยาวนานแม้ในผู้ให้บริการโฮสติ้งโดยเฉพาะ นั่นอาจเป็นสัญญาณว่าคุณอาจต้องประเมินความสามารถของผู้ให้บริการโฮสติ้งปัจจุบันอีกครั้ง เพื่อที่คุณจะได้มอบประสบการณ์ที่ดีที่สุดแก่ผู้ใช้ได้
ใช้เครือข่ายนำส่งข้อมูล (CDN)
หัวข้อการใช้ CDN เป็นหัวข้อที่ใช้งานได้ดี แต่ก็มีเหตุผลอันสมควร นั่นคือคุณอาจมีแบ็กเอนด์แอปพลิเคชันที่ได้รับการเพิ่มประสิทธิภาพมาอย่างดี แต่ผู้ใช้ที่อยู่ไกลจากเซิร์ฟเวอร์ต้นทางอาจยังประสบปัญหา TTFB สูงในการใช้งานภาคสนามอยู่
CDN ช่วยแก้ปัญหาความใกล้ชิดของผู้ใช้จากเซิร์ฟเวอร์ต้นทางได้โดยใช้เครือข่ายเซิร์ฟเวอร์แบบกระจายซึ่งจะแคชทรัพยากรในเซิร์ฟเวอร์ที่อยู่ใกล้กับผู้ใช้มากกว่า เซิร์ฟเวอร์เหล่านี้เรียกว่าเอดจ์เซิร์ฟเวอร์
ผู้ให้บริการ CDN อาจนำเสนอสิทธิประโยชน์ที่นอกเหนือจาก Edge Server ด้วย ดังนี้
- ผู้ให้บริการ CDN มักเสนอเวลาในการแก้ไข DNS ที่รวดเร็วมาก
- CDN มักจะแสดงเนื้อหาของคุณจาก Edge Server โดยใช้โปรโตคอลสมัยใหม่ เช่น 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 ช่วยให้สามารถแคชเนื้อหาไว้ใน 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-to-HTTPS วิธีหนึ่งที่คุณสามารถหลีกเลี่ยงได้คือการใช้ส่วนหัว Strict-Transport-Security (HSTS) ซึ่งจะบังคับใช้ HTTPS ในการเข้าชมต้นทางครั้งแรก จากนั้นจะบอกให้เบราว์เซอร์เข้าถึงต้นทางทันทีผ่านรูปแบบ HTTPS สำหรับการเข้าชมในอนาคต
เมื่อมีนโยบาย HSTS ที่ดีแล้ว คุณจะเร่งการดำเนินการต่างๆ ได้เร็วขึ้นเมื่อเข้าชมต้นทางครั้งแรกโดยการเพิ่มเว็บไซต์ลงในรายการโหลดล่วงหน้าของ HSTS
มาร์กอัปสตรีมไปยังเบราว์เซอร์
เบราว์เซอร์จะได้รับการเพิ่มประสิทธิภาพให้ประมวลผลมาร์กอัปได้อย่างมีประสิทธิภาพเมื่อมีการสตรีม ซึ่งหมายความว่ามาร์กอัปจะได้รับการจัดการเป็นส่วนๆ เมื่อมาจากเซิร์ฟเวอร์ วิธีนี้สำคัญมากสำหรับความกังวลเกี่ยวกับเพย์โหลดของมาร์กอัปขนาดใหญ่ เนื่องจากเบราว์เซอร์จะแยกวิเคราะห์ส่วนที่เป็นส่วนๆ ของมาร์กอัปได้ทีละส่วน แทนการรอให้มีการตอบสนองทั้งหมดก่อนที่จะเริ่มการแยกวิเคราะห์
แม้ว่าเบราว์เซอร์จะเก่งมากในการจัดการมาร์กอัปสตรีมมิง แต่ก็จำเป็นมากที่จะทำทุกวิถีทางที่ทำได้เพื่อให้สตรีมดังกล่าวไหลลื่นอย่างต่อเนื่อง เพื่อให้มาร์กอัปส่วนแรกเริ่มเดินหน้าดำเนินการโดยเร็วที่สุด หากแบ็กเอนด์รออยู่ ก็ถือเป็นปัญหา เนื่องจากสแต็กแบ็กเอนด์มีหลายชุด จึงอาจอยู่นอกเหนือขอบเขตของคู่มือนี้ โดยจะครอบคลุมทุกสแต็กและปัญหาที่อาจเกิดขึ้นในแต่ละสแต็ก
ตัวอย่างเช่น React และเฟรมเวิร์กอื่นๆ ที่แสดงมาร์กอัปตามคำขอบนเซิร์ฟเวอร์ได้ต่างใช้วิธีแบบซิงโครนัสในการแสดงผลฝั่งเซิร์ฟเวอร์ อย่างไรก็ตาม React เวอร์ชันใหม่ได้ใช้เมธอดของเซิร์ฟเวอร์สําหรับมาร์กอัปสตรีมมิงขณะแสดงผล ซึ่งหมายความว่าคุณไม่จำเป็นต้องรอให้เมธอด API ของเซิร์ฟเวอร์ React แสดงผลการตอบกลับทั้งหมดก่อนส่ง
อีกวิธีหนึ่งในการตรวจสอบว่ามาร์กอัปได้รับการสตรีมไปยังเบราว์เซอร์อย่างรวดเร็วคือการใช้การแสดงผลแบบคงที่ ซึ่งจะสร้างไฟล์ HTML ระหว่างการสร้าง เมื่อไฟล์เต็มพร้อมใช้งานทันที เว็บเซิร์ฟเวอร์จะเริ่มส่งไฟล์ได้ทันที และลักษณะที่เป็นธรรมชาติของ HTTP จะส่งผลให้เกิดการมาร์กอัปสตรีมมิง แม้ว่าวิธีนี้จะไม่ได้เหมาะกับทุกหน้าของทุกเว็บไซต์ เช่น หน้าเว็บที่ต้องตอบสนองแบบไดนามิกโดยเป็นส่วนหนึ่งของประสบการณ์ของผู้ใช้ แต่อาจมีประโยชน์สำหรับหน้าเว็บที่ไม่จำเป็นต้องใช้มาร์กอัปในการปรับตามโปรไฟล์ของผู้ใช้ที่เฉพาะเจาะจง
ใช้ Service Worker
Service Worker API อาจมีผลกระทบอย่างมากต่อ TTFB ทั้งสำหรับเอกสารและทรัพยากรที่โหลด เนื่องจากโปรแกรมทำงานของบริการจะทำหน้าที่เป็นพร็อกซีระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ แต่โปรแกรมดังกล่าวจะส่งผลต่อ TTFB ของเว็บไซต์หรือไม่ ขึ้นอยู่กับวิธีตั้งค่าโปรแกรมทำงานของบริการและการตั้งค่านั้นสอดคล้องกับข้อกำหนดแอปพลิเคชันของคุณหรือไม่
- ใช้กลยุทธ์ "ไม่มีอัปเดตขณะตรวจสอบใหม่" สำหรับชิ้นงาน หากเนื้อหาอยู่ในแคชของ Service Worker ไม่ว่าจะเป็นเอกสารหรือทรัพยากรที่เอกสารต้องใช้ กลยุทธ์ที่ไม่มีการอัปเดตขณะตรวจสอบใหม่จะให้บริการทรัพยากรนั้นจากแคชก่อน จากนั้นจะดาวน์โหลดเนื้อหานั้นในเบื้องหลังและแสดงจากแคชสำหรับการโต้ตอบในอนาคต
- หากคุณมีทรัพยากรของเอกสารที่ไม่มีการเปลี่ยนแปลงบ่อยนัก การใช้กลยุทธ์ที่ไม่มีการอัปเดตขณะตรวจสอบใหม่อาจทำให้ TTFB ของหน้าเว็บหายไปได้เกือบทันที อย่างไรก็ตาม การดำเนินการนี้จะไม่ค่อยได้ผลหากเว็บไซต์ของคุณส่งมาร์กอัปที่สร้างขึ้นแบบไดนามิก เช่น มาร์กอัปที่มีการเปลี่ยนแปลงตามการตรวจสอบสิทธิ์ผู้ใช้ ในกรณีดังกล่าว คุณจะต้องเปิดใช้เครือข่ายก่อนเสมอเพื่อให้เอกสารมีความใหม่ที่สุดเท่าที่จะเป็นไปได้
- หากเอกสารโหลดทรัพยากรที่ไม่สำคัญซึ่งมีการเปลี่ยนแปลงตามความถี่ในระดับหนึ่ง แต่การดึงข้อมูลทรัพยากรที่ไม่มีอัปเดตจะไม่ส่งผลกระทบอย่างมากต่อประสบการณ์ของผู้ใช้ เช่น รูปภาพที่เลือกหรือทรัพยากรอื่นๆ ที่ไม่สำคัญ TTFB สำหรับทรัพยากรเหล่านั้นอาจลดลงได้มากโดยใช้กลยุทธ์ "เก่าขณะตรวจสอบใหม่"
- หากเป็นไปได้ ให้ใช้สถาปัตยกรรมของผู้ปฏิบัติงานบริการสตรีมมิง สถาปัตยกรรม Service Worker นี้ใช้วิธีการจัดเก็บส่วนต่างๆ ของทรัพยากรเอกสารไว้ในแคชของ Service Worker แล้วรวมกับบางส่วนของเนื้อหาในระหว่างส่งคำขอการนำทาง ผลของการใช้รูปแบบของ Service Worker นี้คือการนำทางจะค่อนข้างเร็ว โดยจะมีการดาวน์โหลดเพย์โหลด HTML ที่เล็กลงจากเครือข่าย แม้ว่ารูปแบบของโปรแกรมทำงานของบริการนี้จะใช้ไม่ได้กับบางเว็บไซต์ แต่เวลา TTFB สำหรับทรัพยากรเอกสารอาจจะเป็นแบบนั้นได้ทันทีสำหรับเว็บไซต์ที่ใช้งาน
- ใช้โมเดล App Shell สำหรับแอปพลิเคชันที่แสดงผลโดยไคลเอ็นต์ โมเดลนี้เหมาะกับ SPA ที่สามารถแสดง "เชลล์" ของหน้าเว็บจากแคชของ Service Worker ได้ทันที และเนื้อหาแบบไดนามิกของหน้าเว็บจะถูกเติมและแสดงผลในวงจรของหน้าในภายหลัง
ใช้ 103 Early Hints สำหรับทรัพยากรที่สำคัญในการแสดงผล
ไม่ว่าแบ็กเอนด์ของแอปพลิเคชันของคุณจะมีประสิทธิภาพเพียงใด ก็ยังมีงานที่เซิร์ฟเวอร์ต้องทำอีกมากเพื่อเตรียมการตอบสนอง ซึ่งรวมถึงงานฐานข้อมูลที่มีราคาแพง (แต่จำเป็น) ซึ่งทำให้การตอบสนองการนำทางไปถึงล่าช้าที่สุดเท่าที่จะทำได้ ผลกระทบที่อาจเกิดขึ้นจากการดำเนินการนี้คือทรัพยากรที่สำคัญในการแสดงผลที่ตามมาอาจล่าช้า เช่น CSS หรือในบางกรณี JavaScript ที่แสดงผลมาร์กอัปในไคลเอ็นต์
ส่วนหัว 103 Early Hints คือโค้ดตอบกลับล่วงหน้าที่เซิร์ฟเวอร์ส่งไปยังเบราว์เซอร์ได้ขณะที่แบ็กเอนด์ไม่ว่างในการเตรียมมาร์กอัป ส่วนหัวนี้สามารถใช้เพื่อบอกเบราว์เซอร์ว่ามีทรัพยากรที่สำคัญในการแสดงผล ซึ่งหน้าเว็บควรเริ่มดาวน์โหลดขณะที่กำลังเตรียมมาร์กอัป เพื่อให้เบราว์เซอร์ที่รองรับแสดงผลเอกสาร (CSS) ได้เร็วขึ้นและความพร้อมใช้งานของฟังก์ชันหลัก (JavaScript) ของหน้าเว็บก็เร็วขึ้น
บทสรุป
เนื่องจากกลุ่มแอปพลิเคชันแบ็กเอนด์มีชุดค่าผสมของสแต็กแอปพลิเคชันจำนวนมาก จึงไม่มีบทความใดที่จะสรุปทุกอย่างที่คุณทำได้เพื่อลด TTFB ของเว็บไซต์ อย่างไรก็ตาม ตัวเลือกเหล่านี้เป็นสิ่งที่คุณสามารถสำรวจเพื่อลองใช้งาน และทำให้ทุกอย่างรวดเร็วขึ้นจากฝั่งเซิร์ฟเวอร์
เช่นเดียวกับการเพิ่มประสิทธิภาพทุกเมตริก แนวทางส่วนใหญ่ก็คล้ายคลึงกัน นั่นคือ วัด TTFB ของคุณภาคสนาม ใช้เครื่องมือห้องทดลองเพื่อเจาะลึกลงไปถึงสาเหตุ และใช้การเพิ่มประสิทธิภาพหากทำได้ เทคนิคบางอย่างอาจใช้ไม่ได้กับสถานการณ์ของคุณ แต่บางเทคนิคก็อาจได้ผล คุณจะต้องคอยดูข้อมูลภาคสนามอย่างใกล้ชิด และทำการปรับเปลี่ยนตามความจำเป็นเพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดีที่สุด
รูปภาพหลักโดย Taylor Vick มาจาก UnSplash