ดูวิธีเพิ่มประสิทธิภาพสําหรับเมตริกเวลาที่ได้รับข้อมูลไบต์แรก
เวลาในการตอบสนองครั้งแรก (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 (หากใช้ 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 ของ CDN และไปยังต้นทาง
เมื่อวิเคราะห์ข้อมูลที่มีอยู่แล้วและพบว่า TTFB เป็นปัญหา คุณก็ดำเนินการแก้ไขปัญหาได้
วิธีเพิ่มประสิทธิภาพ TTFB
สิ่งที่ท้าทายที่สุดในการเพิ่มประสิทธิภาพ TTFB คือในขณะที่สแต็กส่วนหน้าของเว็บจะเป็น HTML, CSS และ JavaScript เสมอ สแต็กส่วนหลังอาจแตกต่างกันอย่างมาก มีแสต็กแบ็กเอนด์และผลิตภัณฑ์ฐานข้อมูลที่จํานวนมากซึ่งแต่ละรายการมีเทคนิคการเพิ่มประสิทธิภาพของตนเอง ดังนั้น คู่มือนี้จะเน้นที่สิ่งที่ใช้ได้กับสถาปัตยกรรมส่วนใหญ่ แทนที่จะเน้นเฉพาะคำแนะนำสำหรับสแต็ก
คำแนะนำเฉพาะแพลตฟอร์ม
แพลตฟอร์มที่คุณใช้สำหรับเว็บไซต์อาจส่งผลต่อ TTFB อย่างมาก เช่น ประสิทธิภาพของ WordPress จะได้รับผลกระทบจากจํานวนคุณภาพของปลั๊กอิน หรือธีมที่ใช้งาน แพลตฟอร์มอื่นๆ จะได้รับผลกระทบในลักษณะเดียวกันเมื่อมีการกําหนดค่าแพลตฟอร์ม คุณควรอ่านเอกสารประกอบของแพลตฟอร์มเพื่อดูคําแนะนําเฉพาะของผู้ให้บริการเพื่อเสริมคําแนะนําด้านประสิทธิภาพทั่วไปเพิ่มเติมในโพสต์นี้ การตรวจสอบ Lighthouse เพื่อลดเวลาในการตอบกลับของเซิร์ฟเวอร์ยังมีคำแนะนำเฉพาะสแต็กแบบจำกัดด้วย
โฮสติ้ง โฮสติ้ง โฮสติ้ง
ก่อนที่จะพิจารณาแนวทางการเพิ่มประสิทธิภาพอื่นๆ คุณควรพิจารณาเรื่องโฮสติ้งเป็นอันดับแรก เราไม่สามารถให้คําแนะนําที่เฉพาะเจาะจงได้มากนัก แต่หลักทั่วไปคือตรวจสอบว่าโฮสต์ของเว็บไซต์สามารถรองรับการเข้าชมที่คุณส่งไปได้
โดยทั่วไปแล้ว โฮสติ้งแบบแชร์จะช้ากว่า หากคุณใช้งานเว็บไซต์ส่วนตัวขนาดเล็กที่แสดงไฟล์แบบคงที่ส่วนใหญ่ TTFB นี้อาจไม่เป็นปัญหา และเทคนิคการเพิ่มประสิทธิภาพบางส่วนที่ระบุไว้ด้านล่างจะช่วยคุณลด TTFB ให้ได้มากที่สุด
อย่างไรก็ตาม หากคุณใช้งานแอปพลิเคชันขนาดใหญ่ที่มีผู้ใช้จํานวนมากซึ่งเกี่ยวข้องกับการปรับตามโปรไฟล์ของผู้ใช้ การค้นหาฐานข้อมูล และการดำเนินการอื่นๆ ฝั่งเซิร์ฟเวอร์ที่เข้มข้น การเลือกโฮสติ้งจะมีความสำคัญอย่างยิ่งในการลด TTFB ในพื้นที่
สิ่งที่ควรพิจารณาเมื่อเลือกผู้ให้บริการโฮสติ้งมีดังนี้
- อินสแตนซ์แอปพลิเคชันของคุณจัดสรรหน่วยความจําเท่าใด หากแอปพลิเคชันมีหน่วยความจําไม่เพียงพอ แอปพลิเคชันจะทำงานอย่างหนักและแสดงหน้าเว็บได้ช้า
- ผู้ให้บริการโฮสติ้งอัปเดตแพ็กเกจแบ็กเอนด์ให้เป็นเวอร์ชันล่าสุดอยู่เสมอหรือไม่ เมื่อมีการเผยแพร่ภาษาแบ็กเอนด์ของแอปพลิเคชัน การใช้งาน HTTP และซอฟต์แวร์ฐานข้อมูลเวอร์ชันใหม่ ประสิทธิภาพของซอฟต์แวร์ดังกล่าวก็จะดีขึ้นเมื่อเวลาผ่านไป คุณควรพาร์ทเนอร์กับผู้ให้บริการโฮสติ้งที่ให้ความสำคัญกับการบำรุงรักษาที่สำคัญประเภทนี้
- หากคุณมีข้อกำหนดเฉพาะของแอปพลิเคชันมากและต้องการสิทธิ์เข้าถึงระดับต่ำสุดในไฟล์การกําหนดค่าเซิร์ฟเวอร์ ให้พิจารณาว่าการปรับแต่งแบ็กเอนด์ของอินสแตนซ์แอปพลิเคชันของคุณเองเหมาะสมหรือไม่
ผู้ให้บริการโฮสติ้งจํานวนมากจะดูแลสิ่งเหล่านี้ให้คุณ แต่หากคุณเริ่มสังเกตเห็นค่า TTFB ที่นานแม้ในผู้ให้บริการโฮสติ้งเฉพาะ อาจหมายความว่าคุณอาจต้องประเมินความสามารถของผู้ให้บริการโฮสติ้งปัจจุบันอีกครั้งเพื่อให้มอบประสบการณ์การใช้งานที่ดีที่สุดแก่ผู้ใช้
ใช้เครือข่ายนำส่งข้อมูล (CDN)
หัวข้อการใช้ CDN เป็นหัวข้อที่พูดถึงกันมาก แต่ก็มีเหตุผลที่ดี คุณอาจมีแบ็กเอนด์แอปพลิเคชันที่เพิ่มประสิทธิภาพมาอย่างดี แต่ผู้ใช้ที่อยู่ห่างจากเซิร์ฟเวอร์ต้นทางอาจยังพบ TTFB สูงในการใช้งาน
CDN ช่วยแก้ปัญหาความใกล้ของผู้ใช้จากเซิร์ฟเวอร์ต้นทางโดยใช้เครือข่ายเซิร์ฟเวอร์แบบกระจายซึ่งแคชทรัพยากรไว้ในเซิร์ฟเวอร์ที่อยู่ใกล้กับผู้ใช้มากกว่า เซิร์ฟเวอร์เหล่านี้เรียกว่าเซิร์ฟเวอร์ขอบ
ผู้ให้บริการ CDN ยังอาจให้ประโยชน์นอกเหนือจากที่ได้จาก Edge Server อีกด้วย ดังนี้
- โดยทั่วไปแล้ว ผู้ให้บริการ 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 เพื่อขัดขวางคำขอ จัดการการตอบกลับในแคช Edge โดยใช้โปรแกรม หรือเขียนการตอบกลับใหม่ทั้งหมด
- ผู้ให้บริการ CDN เพิ่มประสิทธิภาพการบีบอัดได้ดี การบีบอัดนั้นทําให้ถูกต้องด้วยตนเองได้ยาก และอาจทําให้เวลาในการตอบสนองช้าลงในบางกรณีที่มีมาร์กอัปที่สร้างขึ้นแบบไดนามิก ซึ่งต้องบีบอัดขณะดำเนินการ
- นอกจากนี้ ผู้ให้บริการ CDN จะแคชการตอบกลับที่บีบอัดแล้วสำหรับทรัพยากรแบบคงที่โดยอัตโนมัติด้วย ซึ่งจะทำให้เกิดอัตราส่วนการบีบอัดและเวลาในการตอบสนองที่ดีที่สุด
แม้ว่าการใช้ CDN จะมีความพยายามแตกต่างกันไปตั้งแต่เล็กน้อยไปจนถึงมาก แต่คุณควรให้ความสําคัญกับการเพิ่มประสิทธิภาพ TTFB เป็นลําดับความสําคัญสูงหากเว็บไซต์ของคุณไม่ได้ใช้ CDN อยู่แล้ว
ใช้เนื้อหาที่แคชไว้เมื่อเป็นไปได้
CDN ช่วยให้เนื้อหาแคชได้ที่เซิร์ฟเวอร์ที่ขอบซึ่งอยู่ใกล้กับผู้เข้าชมมากกว่า ในกรณีที่เนื้อหาได้รับการกําหนดค่าด้วยCache-Controlส่วนหัว HTTP ที่เหมาะสม แม้ว่าวิธีนี้จะไม่เหมาะกับเนื้อหาที่ปรับเปลี่ยนในแบบของคุณ แต่การต้องส่งคำขอกลับไปที่ต้นทางอาจทำให้ CDN เสียคุณค่าไปมาก
สําหรับเว็บไซต์ที่อัปเดตเนื้อหาบ่อยครั้ง แม้เวลาแคชเพียงสั้นๆ ก็อาจทําให้เว็บไซต์ที่มีผู้เข้าชมจํานวนมากมีประสิทธิภาพเพิ่มขึ้นอย่างเห็นได้ชัด เนื่องจากมีเพียงผู้เข้าชมรายแรกในช่วงเวลาดังกล่าวที่ประสบปัญหาเวลาในการตอบสนองที่นานมากจนกลับไปที่เซิร์ฟเวอร์ต้นทาง ขณะที่ผู้เข้าชมคนอื่นๆ ทั้งหมดสามารถนำทรัพยากรที่แคชไว้จากเซิร์ฟเวอร์ Edge มาใช้ซ้ำได้ CDN บางรายการอนุญาตให้ลบล้างแคชในรุ่นของเว็บไซต์เพื่อให้ได้สิ่งที่ดีที่สุดจากทั้ง 2 โลก คือ ระยะเวลาแคชนาน แต่อัปเดตทันทีเมื่อจำเป็น
แม้ว่าจะมีการกําหนดค่าการแคชอย่างถูกต้องแล้ว แต่ระบบอาจไม่สนใจการแคชนี้ผ่านการใช้พารามิเตอร์สตริงการค้นหาที่ไม่ซ้ำกันสําหรับการวัดข้อมูลวิเคราะห์ CDN อาจมองว่าเนื้อหาเหล่านี้แตกต่างกัน แม้ว่าจะเป็นเนื้อหาเดียวกันก็ตาม ระบบจึงจะไม่ใช้เวอร์ชันที่แคชไว้
นอกจากนี้ ระบบอาจไม่แคชเนื้อหาเก่าหรือเนื้อหาที่มีผู้เข้าชมน้อย ซึ่งอาจส่งผลให้ค่า TTFB ในบางหน้าสูงกว่าหน้าอื่นๆ การเพิ่มเวลาแคชสามารถลดผลกระทบนี้ได้ แต่โปรดทราบว่าเวลาแคชที่เพิ่มขึ้นก็อาจทำให้มีโอกาสแสดงเนื้อหาที่ล้าสมัยมากขึ้นด้วย
ผลกระทบของเนื้อหาที่แคชไว้ไม่ได้ส่งผลต่อผู้ที่ใช้ CDN เท่านั้น โครงสร้างพื้นฐานเซิร์ฟเวอร์อาจต้องสร้างเนื้อหาจากการค้นหาฐานข้อมูลที่เสียค่าใช้จ่ายเมื่อใช้เนื้อหาที่แคชไว้ซ้ำไม่ได้ ข้อมูลที่มีการเข้าถึงบ่อยขึ้นหรือหน้าที่แคชไว้ล่วงหน้ามักจะมีประสิทธิภาพดีกว่า
หลีกเลี่ยงการเปลี่ยนเส้นทางหน้าเว็บหลายครั้ง
สาเหตุที่พบบ่อยอย่างหนึ่งที่ทําให้ TTFB สูงคือการเปลี่ยนเส้นทาง การเปลี่ยนเส้นทางจะเกิดขึ้นเมื่อคำขอไปยังเอกสารได้รับการตอบกลับซึ่งแจ้งให้เบราว์เซอร์ทราบว่าทรัพยากรอยู่ในตำแหน่งอื่น การเปลี่ยนเส้นทาง 1 ครั้งอาจเพิ่มเวลาในการตอบสนองที่ไม่พึงประสงค์ให้กับคำขอไปยังส่วนต่างๆ ของเว็บไซต์ แต่อาจแย่กว่านั้นหากการเปลี่ยนเส้นทางนั้นชี้ไปยังแหล่งข้อมูลอื่นที่ส่งผลให้มีการเปลี่ยนเส้นทางอีกครั้ง และอื่นๆ ซึ่งอาจส่งผลกระทบต่อเว็บไซต์ที่มีผู้เข้าชมจำนวนมากจากโฆษณาหรือจดหมายข่าว เนื่องจากมักจะเปลี่ยนเส้นทางผ่านบริการวิเคราะห์เพื่อวัตถุประสงค์ในการวัดผล การกำจัดการเปลี่ยนเส้นทางที่คุณควบคุมได้โดยตรงจะช่วยให้ TTFB อยู่ในระดับที่ดี
การเปลี่ยนเส้นทางมี 2 ประเภท ได้แก่
- การเปลี่ยนเส้นทางจากต้นทางเดียวกัน ซึ่งการเปลี่ยนเส้นทางเกิดขึ้นทั้งหมดในเว็บไซต์ของคุณ
- การเปลี่ยนเส้นทางข้ามต้นทาง ซึ่งการเปลี่ยนเส้นทางเกิดขึ้นครั้งแรกในต้นทางอื่น เช่น จากบริการย่อ URL ของโซเชียลมีเดีย ก่อนที่จะมาถึงเว็บไซต์ของคุณ
คุณควรมุ่งเน้นที่การกำจัดการเปลี่ยนเส้นทางจากต้นทางเดียวกัน เนื่องจากเป็นสิ่งที่คุณควบคุมได้โดยตรง ซึ่งเกี่ยวข้องกับการตรวจสอบลิงก์ในเว็บไซต์เพื่อดูว่าลิงก์ใดทำให้เกิดรหัสการตอบกลับ 302 หรือ 301 หรือไม่ ปัญหานี้มักเกิดจากการไม่ใส่รูปแบบ https:// (เบราว์เซอร์จึงใช้ http:// เป็นค่าเริ่มต้น ซึ่งจะเปลี่ยนเส้นทางในภายหลัง) หรือเนื่องจากไม่ได้รวมหรือยกเว้นเครื่องหมายทับปิดท้ายใน URL อย่างเหมาะสม
การเปลี่ยนเส้นทางข้ามแหล่งที่มานั้นจัดการได้ยากกว่า เนื่องจากมักอยู่นอกเหนือการควบคุมของคุณ แต่พยายามหลีกเลี่ยงการเปลี่ยนเส้นทางหลายครั้งหากเป็นไปได้ เช่น การใช้เครื่องมือย่อลิงก์หลายรายการเมื่อแชร์ลิงก์ ตรวจสอบว่า 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 และการตั้งค่านั้นสอดคล้องกับข้อกําหนดของแอปพลิเคชันหรือไม่
- ใช้กลยุทธ์ "ใช้เนื้อหาเดิมขณะตรวจสอบอีกครั้ง" สำหรับเนื้อหา หากชิ้นงานอยู่ในแคช Service Worker ไม่ว่าจะเป็นเอกสารหรือทรัพยากรที่เอกสารต้องใช้ กลยุทธ์ "ล้าสมัยขณะตรวจสอบอีกครั้ง" จะแสดงทรัพยากรนั้นจากแคชก่อน จากนั้นจะดาวน์โหลดชิ้นงานนั้นในเบื้องหลังและแสดงจากแคชสำหรับการโต้ตอบในอนาคต
- หากคุณมีทรัพยากรเอกสารที่เปลี่ยนแปลงไม่บ่อยนัก การใช้กลยุทธ์ "ใช้ข้อมูลเก่าระหว่างตรวจสอบอีกครั้ง" อาจทําให้ TTFB ของหน้าเว็บเกือบจะทันที อย่างไรก็ตาม วิธีการนี้อาจใช้ไม่ได้ผลหากเว็บไซต์ส่งมาร์กอัปที่สร้างขึ้นแบบไดนามิก เช่น มาร์กอัปที่เปลี่ยนแปลงตามสถานะการตรวจสอบสิทธิ์ของผู้ใช้ ในกรณีเช่นนี้ คุณควรเผยแพร่ในเครือข่ายก่อนเสมอ เพื่อให้เอกสารเป็นข้อมูลล่าสุดมากที่สุด
- หากเอกสารโหลดทรัพยากรที่ไม่สําคัญซึ่งเปลี่ยนแปลงเป็นประจํา แต่การดึงข้อมูลทรัพยากรที่ล้าสมัยจะไม่ส่งผลต่อประสบการณ์ของผู้ใช้มากนัก เช่น รูปภาพบางรูปหรือทรัพยากรอื่นๆ ที่ไม่สําคัญ TTFB สําหรับทรัพยากรเหล่านั้นจะลดลงได้อย่างมากโดยใช้กลยุทธ์ "ล้าสมัยขณะตรวจสอบอีกครั้ง"
- ใช้รูปแบบเชลล์แอปสําหรับแอปพลิเคชันที่แสดงผลโดยไคลเอ็นต์ รูปแบบนี้เหมาะสําหรับ SPA มากที่สุด ซึ่งสามารถส่ง "เชลล์" ของหน้าเว็บได้ทันทีจากแคช Service Worker และระบบจะสร้างและแสดงผลเนื้อหาแบบไดนามิกของหน้าเว็บในภายหลังในวงจรชีวิตของหน้า
ใช้ 103 Early Hints สำหรับทรัพยากรที่สำคัญต่อการเรนเดอร์
ไม่ว่าแบ็กเอนด์ของแอปพลิเคชันจะได้รับการปรับปรุงประสิทธิภาพได้ดีเพียงใด ก็อาจยังมีงานจำนวนมากที่เซิร์ฟเวอร์ต้องทำเพื่อเตรียมการตอบกลับ ซึ่งรวมถึงงานฐานข้อมูลที่ต้องใช้ทรัพยากรมาก (แต่จำเป็น) ซึ่งทำให้การตอบกลับการนําทางล่าช้ากว่าที่ควรจะเป็น ผลที่อาจเกิดขึ้นคือทรัพยากรสําคัญในการแสดงผลบางรายการในภายหลังอาจล่าช้า เช่น CSS หรือในบางกรณี JavaScript ที่แสดงผลมาร์กอัปในไคลเอ็นต์
ส่วนหัว 103 Early Hints คือโค้ดการตอบกลับขั้นต้นที่เซิร์ฟเวอร์สามารถส่งไปยังเบราว์เซอร์ได้ขณะที่แบ็กเอนด์กำลังเตรียมมาร์กอัป ส่วนหัวนี้สามารถใช้เพื่อบอกใบ้ให้เบราว์เซอร์ทราบว่ามีทรัพยากรสําคัญต่อการแสดงผลที่หน้าเว็บควรเริ่มดาวน์โหลดขณะเตรียมมาร์กอัป สําหรับเบราว์เซอร์ที่รองรับ เอฟเฟกต์นี้อาจทําให้การแสดงผลเอกสาร (CSS) เร็วขึ้นและฟังก์ชันหลักของหน้าเว็บ (JavaScript) พร้อมใช้งานเร็วขึ้น
บทสรุป
เนื่องจากมีชุดสแต็กแอปพลิเคชันแบ็กเอนด์หลายชุด จึงไม่มีบทความใดที่สรุปทุกอย่างที่คุณทําได้เพื่อลด TTFB ของเว็บไซต์ อย่างไรก็ตาม ต่อไปนี้คือตัวเลือกบางส่วนที่คุณลองใช้ได้เพื่อพยายามทำให้การดำเนินการฝั่งเซิร์ฟเวอร์เร็วขึ้นเล็กน้อย
แนวทางในการเพิ่มประสิทธิภาพเมตริกทุกรายการนั้นคล้ายกันมาก กล่าวคือ ให้วัด TTFB ในพื้นที่ ใช้เครื่องมือใน Lab เพื่อเจาะลึกสาเหตุ แล้วจึงใช้การเพิ่มประสิทธิภาพเมื่อเป็นไปได้ เทคนิคบางเทคนิคอาจใช้ไม่ได้กับสถานการณ์ของคุณ แต่บางเทคนิคก็อาจใช้ได้ คุณต้องคอยตรวจสอบข้อมูลภาคสนามอย่างใกล้ชิดและทำการปรับเปลี่ยนตามที่จำเป็นเพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่รวดเร็วที่สุดเท่าที่จะเป็นไปได้
รูปภาพหลักโดย Taylor Vick จาก Unsplash