เปิด Lighthouse ครั้งแรก ควรอ่านอะไรก่อนคะแนน

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

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

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

เริ่มจากหน้าที่มีอาการ และบอกให้ได้ว่ารออะไรอยู่

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

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

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

คะแนน Performance มาจากตัวชี้วัด ไม่ใช่จำนวนข้อที่แก้หมด

ในรายงานจะมีทั้งตัวชี้วัดกับรายการวิเคราะห์ที่ชวนให้ตรวจเพิ่มเติม ซึ่ง Lighthouse ใช้ค่าตัวชี้วัดตามวิธีคำนวณของรุ่นนั้นสร้างคะแนน Performance การแก้รายการแนะนำจึงอาจช่วยให้ตัวชี้วัดดีขึ้น แต่ไม่ได้หมายความว่าทุกบรรทัดมีคะแนนให้หักหรือเพิ่มโดยตรงเหมือนกัน

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

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

ดูว่าค่าแต่ละตัวกำลังเล่าเหตุการณ์ช่วงไหน

ตัวอย่างเช่น LCP ช่วยมองจังหวะที่องค์ประกอบเนื้อหาขนาดใหญ่ตามนิยามของตัวชี้วัดถูกแสดง ส่วน CLS เกี่ยวกับการขยับขององค์ประกอบในหน้าที่เข้าข่ายการคำนวณ จึงต้องตรวจตัวองค์ประกอบจริง ไม่เดาจากชื่อไฟล์หรือจากความรู้สึกว่ารูปน่าจะใหญ่ที่สุดเสมอไป

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

การเห็นค่าผู้ใช้จริงในเครื่องมือบางแบบยังมีเงื่อนไขเรื่องข้อมูลที่เก็บได้ด้วย เว็บที่เพิ่งเริ่มมีเนื้อหาหรือมีผู้ใช้ไม่มากอาจยังไม่มีข้อมูลเพียงพอให้แสดง ซึ่งไม่ได้แปลว่าค่าเป็นศูนย์หรือเว็บผ่านเกณฑ์แล้ว เราควรแยกส่วนที่มีหลักฐานออกจากส่วนที่ยังต้องรอดู

รายการแนะนำช่วยชี้ทาง แต่ยังต้องเปิดดูต้นเหตุ

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

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

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

ทำให้ผลรอบถัดไปเทียบกับรอบเดิมได้

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

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

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

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

สรุป

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