เพิ่มประสิทธิภาพเวลาในการไบต์แรก

ดูวิธีเพิ่มประสิทธิภาพเมตริกเวลาไปถึงไบต์แรก

Jeremy Wagner

Barry Pollard

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 - $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 รายการปรากฏให้เห็นในแท็บเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บใน 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 สำหรับทั้งเอกสารและทรัพยากรที่โหลด กรณีนี้เกิดจากการที่ Service Worker ทำหน้าที่เป็นพร็อกซีระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ แต่จะส่งผลต่อ 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