TTFB ดีแล้ว ทำไมยังรู้สึกว่าเว็บช้า

เวลาตรวจเว็บแล้วเห็นเซิร์ฟเวอร์ตอบข้อมูลแรกได้เร็ว เราอาจรู้สึกว่างานส่วนใหญ่พร้อมแล้ว แต่คนอ่านยังอาจมองหน้าว่างหรือโครงหน้าอยู่ เพราะหลังข้อมูลแรกมาถึงยังมีงานอีกหลายช่วงก่อนเนื้อหาที่ต้องการจะปรากฏ

ความรู้สึกว่าเว็บช้าจึงควรถูกแยกว่ากำลังรออะไรครับ TTFB ช่วยให้เห็นช่วงเริ่มต้นของการเปิดหน้า แต่ถ้าจะรู้ว่าคนอ่านเริ่มอ่านได้เมื่อไร เราต้องตามเส้นทางหลังจากนั้นต่อด้วย

การแยกช่วงไม่ได้ทำให้ค่าที่วัดมาขัดกัน หน้าเดียวอาจมี TTFB ดีและยังต้องปรับงานฝั่งเบราว์เซอร์อีกมากได้ โดยที่ทั้งสองข้อเป็นจริงพร้อมกัน

ข้อมูลแรกอาจยังไม่ใช่เนื้อหาที่คนต้องการ

TTFB หรือ Time to First Byte พิจารณาช่วงเริ่มนำทางไปจนข้อมูลตอบกลับแรกเริ่มมาถึง ในการเปิดหน้าจริงช่วงนี้อาจเกี่ยวกับ redirect การตั้งการเชื่อมต่อ เครือข่าย และการรอเซิร์ฟเวอร์ จึงไม่ใช่เวลารันโค้ดหลังบ้านอย่างเดียว

แต่แม้ข้อมูลแรกมาถึง ก็ไม่ได้หมายความว่า HTML ทั้งเอกสารครบ หรือทรัพยากรที่ต้องใช้วาดหน้าพร้อมแล้ว เว็บยังอาจต้องโหลด style ฟอนต์ ภาพ และ JavaScript ก่อนจะไปถึงเนื้อหาสำคัญ

สำหรับหน้าที่ส่ง HTML เป็นช่วงๆ ต้องตรวจด้วยว่าข้อมูลแรกเป็นส่วนใด หากส่งโครงหรือ fallback มาก่อน metric ช่วงแรกอาจดูดีขึ้น แต่คนอ่านยังรอข้อมูลบทความต่ออยู่ สิ่งที่ควรถามคือแต่ละช่วงที่ส่งมาช่วยให้เริ่มใช้งานได้แค่ไหน

ดังนั้นเวลารายงานควรบอกขอบเขตชัด เช่น วัดการตอบเอกสารต้นทาง หรือวัดจังหวะเนื้อหาหลักปรากฏ การใช้ชื่อรวมว่าเวลาโหลดอาจทำให้ผู้รับเข้าใจว่าตัวเลขแรกคือเวลาพร้อมทั้งหมดโดยไม่ตั้งใจ

ถ้าต้องรอ API ต่อ ให้เห็นเส้นทางนั้นในหลักฐาน

สมมติว่าหน้าส่งโครงมาเร็ว แล้วให้ JavaScript เรียก API เพื่ออ่านบทความอีกครั้ง คนอ่านจะเห็นเนื้อหาได้หลังจากโค้ดพร้อม คำขอสำเร็จ และข้อมูลถูกแสดง การลดเวลาตอบโครงหน้าอย่างเดียวจึงไม่ได้ตัดทุกช่วงรอต่อกันในเส้นทางนี้

ลองเปิด Network ดูว่า API เริ่มเมื่อไร อะไรเป็นตัวเริ่ม และมีคำขอใดต้องจบก่อนอีกคำขอจะเกิดหรือไม่ หากมีงานต่อกันหลายขั้น ควรตรวจว่าจำเป็นต้องต่อเป็นลำดับทั้งหมด หรือบางส่วนสามารถเตรียมพร้อมโดยไม่รอข้อมูลที่ไม่เกี่ยวข้องได้

ตัวอย่างนี้ไม่ได้แปลว่าการใช้ API ฝั่ง client ช้าเสมอไป เพราะแคช การเปลี่ยนหน้าภายใน และลักษณะข้อมูลมีผลด้วย เพียงแต่ต้องวัดจากเส้นทางที่คนใช้จริง ไม่หยิบเวลาตอบโครงมาอธิบายประสบการณ์ของเนื้อหาที่โหลดอีกทาง

ถ้ากำลังเทียบ server rendering กับ client rendering ให้ใช้เนื้อหาและเงื่อนไขเดียวกัน พร้อมตรวจว่าแต่ละแบบมีงานอะไรอยู่ในรอบนั้น อย่าเทียบหน้าที่ได้ข้อมูลแล้วกับหน้าที่เริ่มขอใหม่โดยไม่ระบุความต่าง

Network เงียบแล้ว ยังมีงานให้เบราว์เซอร์ทำ

เมื่อไฟล์ดาวน์โหลดจบ JavaScript ยังต้องถูกอ่านและประมวลผล ส่วนข้อมูลที่ได้มาก็อาจต้องแปลงก่อนสร้าง UI หากหน้ามีงานต่อเนื่องมาก เบราว์เซอร์อาจยังไม่มีจังหวะวาดหรือรับคำสั่งได้ดี แม้ไม่เห็นแถบดาวน์โหลดเคลื่อนไหวแล้ว

จึงควรดู Performance trace คู่กับ Network เพื่อแยกว่ารอกิจกรรมเครือข่ายหรือรอ main thread ถ้าปัญหาอยู่ที่การประมวลผล การเพิ่ม cache ของไฟล์อย่างเดียวอาจลดการดาวน์โหลดแต่ยังเหลืองานเดิมทุกครั้งที่เปิดหน้า

งานจัด layout และฟอนต์ก็มีผลกับสิ่งที่เห็น เช่น ข้อความอาจรอฟอนต์หรือเปลี่ยนบรรทัดตอนสลับ ส่วนภาพที่โหลดเสร็จก็ยังมีขั้นที่เกี่ยวกับการเตรียมและวาด จึงไม่ควรใช้คำว่ารูปมาแล้วแทนว่าคนอ่านเห็นภาพในจังหวะเดียวกันแน่นอน

สำหรับหน้าบทความ คำถามที่ใกล้กับคนอ่านคือหัวข้อ ย่อหน้าแรก และภาพที่ช่วยเข้าใจเรื่องพร้อมเมื่อไร จากนั้นค่อยตรวจว่าการเลื่อนและการกดตอบสนองต่อได้อย่างไร เพราะความพร้อมด้านภาพกับความพร้อมต่อ interaction เป็นคนละมุมของประสบการณ์

แคชกับเส้นทางเปิดหน้าต้องอยู่ในชื่อรอบทดสอบ

รอบแรกของเครื่องที่ยังไม่มีไฟล์กับรอบที่ไฟล์อยู่ใน cache อาจต่างกัน รวมถึงการเปิดผ่านลิงก์ภายในที่มีข้อมูลเตรียมไว้ก่อน ถ้านำผลสองแบบมาเทียบกันโดยไม่แยก เราอาจยกผลดีให้การแก้โค้ดทั้งที่ตัวแปรสำคัญคือสิ่งที่โหลดไว้แล้ว

ฝั่งเซิร์ฟเวอร์ก็มีแคชหลายชั้น เช่น response จากบริการกลางกับข้อมูลที่ต้องคำนวณใหม่ การเห็น TTFB ของรอบหนึ่งดีจึงควรบอกด้วยว่ารอบนั้นได้อะไรจาก cache และมีเงื่อนไขใดทำให้ข้ามทางนั้นได้

เวลาแบ่งกลุ่มลองใช้คำที่บอกพฤติกรรม เช่น เปิด URL ใหม่โดยไม่มี browser cache หรือเปลี่ยนหน้าจากรายการหลังอยู่ในเว็บแล้ว จากนั้นรักษาลำดับการเปิดให้เหมือนกันในแต่ละแบบ แทนการใช้คำว่าเร็วขึ้นโดยไม่รู้ว่ารอบทดสอบเป็นแบบใด

เลือกแก้จากช่วงที่ขวางการอ่านจริง

หากข้อมูลเอกสารเริ่มช้า ค่อยไล่ redirect ระยะเครือข่าย แคช และงานเซิร์ฟเวอร์ที่เกี่ยวข้อง แต่ถ้าข้อมูลแรกมาเร็วแล้วภาพหลักเริ่มโหลดช้ามาก ก็ควรตามการค้นพบภาพหรือข้อมูลที่ใช้สร้างมัน ไม่เปลี่ยนเครื่องเซิร์ฟเวอร์เป็นขั้นแรกทุกครั้ง

เมื่อเนื้อหาขึ้นแล้วแต่กดไม่ไป ให้ตาม interaction และงานบน main thread เพิ่ม ส่วนหน้าที่เนื้อหาขยับก็ต้องดูการจัดพื้นที่ การแก้ความเร็วเว็บจึงควรมีคำอธิบายว่าแต่ละการเปลี่ยนจะตัดเวลาหรือความไม่แน่นอนตรงส่วนใด

เก็บหลายรอบภายใต้เงื่อนไขเดิม พร้อมดูเวลาของเนื้อหาสำคัญร่วมกับ TTFB แผนภาพในบทนี้เป็นลำดับแนวคิด ไม่มีสัดส่วนเวลาที่อ้างจากเว็บจริง จึงต้องนำ trace ที่วัดมาเติมก่อนสรุปว่าระบบใดใช้เวลาตรงไหนมากที่สุด

ถ้ามี field data ก็ควรย้อนดูว่ากลุ่มผู้ใช้ยังรอจุดเดียวกับที่ lab พบหรือไม่ การแก้ที่เครื่องทดสอบพิสูจน์ได้ช่วยยืนยันกลไกหนึ่ง แต่สภาพเครือข่าย อุปกรณ์ และทางเข้าหน้าที่หลากหลายยังต้องติดตามในข้อมูลใช้งานจริงต่อ

TTFB ที่ดีบอกว่าช่วงต้นของการตอบกลับทำงานได้ดีในเงื่อนไขที่วัด แต่การเริ่มอ่านยังขึ้นกับข้อมูลต่อเนื่อง ทรัพยากร และการประมวลผลหลังจากนั้น เมื่อตามจากคำขอแรกไปถึงเนื้อหาที่คนต้องการ พร้อมแยกแคชกับเส้นทางเปิดหน้า เราจะเลือกปรับส่วนที่ยังทำให้รอได้ตรงขึ้น และอธิบายผลโดยไม่ให้ตัวชี้วัดเดียวแบกความหมายของทั้งหน้าไว้ครับ