ตอนแก้เว็บแล้วกดวัดใหม่ สิ่งที่อยากเห็นก็คือผลดีขึ้นตามงานที่เพิ่งทำ แต่บางครั้งยังไม่ได้เปลี่ยนอะไร คะแนนรอบถัดไปก็ไม่เท่าเดิมแล้ว พอเป็นแบบนี้เราจะรู้ได้อย่างไรว่าการแก้ช่วยจริง หรือแค่บังเอิญวัดในช่วงที่เงื่อนไขเอื้อกว่าเดิม
การทดสอบความเร็วมีความแปรปรวนอยู่ด้วยครับ ทั้งเครื่องที่ใช้ เครือข่าย เนื้อหาที่ได้รับ และสถานะแคช จึงควรเตรียมวิธีเทียบก่อนเริ่มแก้ เพื่อไม่ให้สุดท้ายเหลือเพียงภาพรายงานที่เลือกมาคนละรอบ
เป้าหมายไม่ใช่ทำให้ทุกครั้งได้ตัวเลขเท่ากัน แต่ทำให้รู้ว่ากำลังเทียบงานภายใต้เงื่อนไขใด และผลที่ต่างกันมีหลักฐานพอให้ตัดสินใจต่อหรือยัง
ลองเปลี่ยนจากคำถามว่าเว็บเร็วขึ้นไหม เป็นภาพปกเริ่มโหลดเร็วขึ้นหรือไม่ หรือปริมาณงานที่ขวาง main thread ลดลงหรือยัง จะช่วยเลือกตัวชี้วัดและหลักฐานที่เกี่ยวข้องได้ ก่อนกลับไปดูผลรวมของหน้า
คะแนน Performance ของ Lighthouse รวมผล metric ตามวิธีให้น้ำหนักและแปลงคะแนนของเครื่องมือ การเปลี่ยนคะแนนจึงไม่ได้บอกด้วยตัวเองว่างานช่วงใดเปลี่ยน และการขยับหนึ่งคะแนนก็ไม่ได้หมายถึงจำนวนเวลาคงที่ทุกช่วง
ถ้าเป้าหมายคือให้คนอ่านเห็นเนื้อหาหลักเร็วขึ้น ก็ควรเก็บเวลานั้นกับ element ที่เกี่ยวข้องร่วมด้วย การดูเฉพาะคะแนนรวมอาจพาเราไปแก้ส่วนที่ทำให้คะแนนเปลี่ยนแต่ไม่ได้ตอบอาการที่คนอ่านกำลังเจอ
สำหรับรอบที่เปลี่ยนโครงเว็บ ควรเลือกหน้าที่เป็นตัวแทนอย่างมีเหตุผล เช่น บทความภาพน้อยกับภาพมาก โดยยังรักษารายการเดิมในแต่ละชุด การเพิ่มหน้าที่ง่ายกว่าภายหลังแล้วเทียบค่าเฉลี่ยใหม่จะทำให้ไม่เห็นผลของการแก้เดิมชัด
URL รุ่นโค้ด วันเวลา รุ่น Chrome และ Lighthouse ควรอยู่กับรายงาน รวมถึงรูปแบบมือถือหรือ desktop การจำลอง CPU และเครือข่าย เพราะการใช้เครื่องมือชื่อเดียวกันไม่ได้ทำให้ทุกคนกำลังจำลองสภาพเดียวกันเสมอไป
ฝั่งเครื่องก็ควรลดงานอื่นที่ไม่เกี่ยวข้อง เช่น งานบิ้วขนาดใหญ่ที่แย่ง CPU และส่วนเสริมที่เพิ่มโค้ดในหน้า สำหรับเครื่องที่ร้อนหรืออยู่ในสถานะจำกัดพลังงาน ผลก็อาจต่างจากช่วงปกติได้ จึงควรรักษาสภาพให้ใกล้กันมากกว่าหาค่าต่ำสุดให้ได้
เว็บที่มีข้อมูลเปลี่ยนตามผู้ใช้ โฆษณา หรือเนื้อหาภายนอกต้องบอกขอบเขตด้วย หากรอบหนึ่งโหลดคนละชุด ความต่างอาจมาจากข้อมูลที่รับ ไม่ใช่โค้ดหน้าเพียงอย่างเดียว จึงควรมีหน้าทดลองหรือข้อมูลที่ควบคุมได้สำหรับคำถามที่ต้องแยกเหตุให้ชัด
หากใช้ระบบรันทดสอบอัตโนมัติ ให้เก็บค่าตั้งไปกับผล ไม่พึ่งความทรงจำว่ารอบนั้นน่าจะใช้ default แบบเดียวกัน เพราะค่าเริ่มต้นกับวิธีจำลองมีโอกาสเปลี่ยนตามรุ่นเครื่องมือ
คนที่เปิดครั้งแรกกับคนที่อ่านอยู่แล้วอาจเจอเส้นทางต่างกัน การทดสอบทั้งสองแบบมีประโยชน์ แต่ต้องตั้งชื่อและวิธีเตรียมให้ชัดว่าต้องการตอบกลุ่มใด ไม่ทำให้บางรอบมีไฟล์เตรียมอยู่โดยไม่บอก
นอกจาก browser cache ยังมี cache ฝั่งบริการและข้อมูลที่ระบบเตรียมไว้ก่อนเข้า URL จึงควรดูคำขอกับ response ที่เกี่ยวข้องประกอบ ถ้าได้คำตอบจากคนละทาง การล้าง cache ในเบราว์เซอร์อย่างเดียวอาจยังไม่ได้ทำให้จุดเริ่มต้นเหมือนกันทั้งหมด
สำหรับการเปลี่ยนหน้าภายในเว็บ ให้จดหน้าที่เริ่ม ลิงก์ที่กด และเวลาที่อยู่ก่อนกดด้วย เพราะ prefetch อาจมีเวลาเตรียมงานต่างกัน หากรอบหนึ่งกดทันทีแต่อีกรอบหยุดอ่านก่อนนานมาก การเทียบก็มีตัวแปรเพิ่มที่ต้องอธิบาย
เมื่อมีชื่อสถานการณ์ชัด เราสามารถทำซ้ำเป็นชุดได้ เช่น เปิด URL ใหม่ภายใต้สภาพที่กำหนด แล้วแยกอีกชุดสำหรับเปลี่ยนจากรายการบทความ โดยไม่เอาทั้งหมดมาปนเป็นคะแนนเดียวที่ไม่รู้ความหมาย
การมีหลายรอบช่วยให้เห็นว่าผลจับกลุ่มอยู่ใกล้กันหรือกระจายมาก สามารถใช้ค่ากลางอย่าง median ประกอบกับช่วงของผลได้ แต่ยังควรเก็บค่ารายรอบไว้ เพราะค่ากลางอย่างเดียวอาจซ่อนรอบที่ผิดปกติซ้ำๆ
หากพบรอบหนึ่งต่างมาก ให้ย้อนดูว่ามีคำขอล้มเหลว เนื้อหาเปลี่ยน หรือเงื่อนไขอื่นหรือไม่ ถ้าจะตัดรอบนั้นออกต้องมีเหตุผลที่อธิบายได้และใช้กติกาเดียวกันทั้งก่อนและหลัง ไม่เลือกตัดเพียงเพราะทำให้ผลดูไม่ดี
การมีรอบเพิ่มไม่ได้ชดเชยเงื่อนไขที่ผิดทั้งหมด ถ้ารันทุกรอบในสภาพที่ไม่แทนการใช้งานที่สนใจ เราก็แค่มั่นใจมากขึ้นกับคำถามอีกข้อหนึ่ง จึงต้องตกลงสถานการณ์ให้ถูกก่อนเพิ่มจำนวนการวัด
แผนภาพในบทนี้เป็นช่องทางจัดบันทึก ไม่มีคะแนนหรือผลทดสอบที่สร้างขึ้น ตัวเลขจริงควรมาจากรายงานที่เก็บไว้พร้อมเงื่อนไขของแต่ละรอบ จึงจะไล่ได้ว่าข้อสรุปตั้งอยู่บนข้อมูลชุดใด
ถ้าทดลองลดขนาดภาพ ให้ดูคำขอภาพกับช่วง LCP ที่เกี่ยวข้องด้วย หากลดข้อมูลได้แต่เวลาที่เห็นภาพไม่เปลี่ยน อาจมีช่วงรออื่นที่ยังขวางอยู่ การอ่านผลแบบนี้มีประโยชน์กว่าประกาศว่าการบีบภาพไม่ได้ผลจากคะแนนที่นิ่งเพียงอย่างเดียว
เมื่อจำเป็นต้องแก้หลายส่วนพร้อมกันเพราะเป็นงานเดียวกัน ก็ระบุขอบเขตตามนั้น และอย่าแยกยกผลดีให้ทุกการเปลี่ยนโดยไม่มีรอบทดลองรองรับ อาจบอกได้ว่าชุดการเปลี่ยนช่วย แต่ยังไม่รู้ส่วนแบ่งของแต่ละจุด
หลังได้ผลใน lab ให้เก็บวันที่เผยแพร่แล้วติดตามข้อมูลใช้งานจริงเมื่อมี เพื่อดูว่าประสบการณ์ของกลุ่มที่สนใจสอดคล้องหรือไม่ โดยคำนึงถึงช่วงรวมข้อมูล ไม่คาดว่ารายงานย้อนหลังจะเปลี่ยนเป็นผลของโค้ดใหม่ทั้งหมดทันที
ควรเก็บรายงานดิบไว้กับบันทึกการเปลี่ยนแปลงด้วย ภาพคะแนนช่วยสื่อสารเร็ว แต่รายละเอียดคำขอและเวลาย่อยจะสำคัญเมื่อภายหลังต้องย้อนหาว่าการปรับครั้งนั้นช่วยส่วนใด หรือเกิดผลข้างเคียงกับหน้าอื่นหรือไม่
เวลาคะแนน Lighthouse ไม่เท่าเดิม ให้กลับมาดูคำถาม เงื่อนไข แคช และหลักฐานรายรอบก่อนเลือกเชื่อตัวเลขใด การทดสอบหลายครั้งภายใต้สถานการณ์เดิมพร้อมเก็บค่ากลางและช่วงผล จะช่วยแยกความเปลี่ยนแปลงจากความแกว่งได้ดีขึ้น และทำให้เหตุผลที่เลือกแก้เว็บตรวจย้อนกลับได้โดยไม่ต้องเลือกเฉพาะรอบที่คะแนนสวยครับ