วัดก่อนปรับปรุง: เวิร์กโฟลว์ของ Paul Irish เพื่อความเร็ว

ทำไมการปรับก่อนวัดมักเสียเวลา\n\nงานด้านประสิทธิภาพมักรู้สึกกระจัดกระจายเมื่อคุณเริ่มจากการแก้ไข วันหนึ่งคุณย่อไฟล์ บีบอัดรูป อีกวันคุณปรับแคช แล้ววันถัดไปลบไลบรารี บางครั้งช่วย บางครั้งก็ไม่มีอะไรเปลี่ยน แล้วคุณก็ไม่รู้ว่าเพราะอะไร\n\nความเสี่ยงใหญ่คือการไปปรับในสิ่งที่ไม่ใช่ปัญหา ถ้าหน้าช้าเพราะ main thread ถูกบล็อกด้วย JavaScript การใช้เวลาหลายชั่วโมงบีบอัดรูปอาจแทบไม่เห็นผล หรือคุณอาจเร่งบางอย่างที่ผู้ใช้ไม่สังเกต ในขณะที่ความล่าช้าจริงมาจากการเรียก API ที่ยาว การเลย์เอาต์ที่เกิด reflow บ่อย หรือสคริปต์ตัวเดียวที่บล็อก\n\nกับดักอีกอย่างคือตัดสินจากความรู้สึก “รู้สึกเร็วขึ้น” ซึ่งอาจเป็นผลจาก placebo (เช่น spinner) หรือการทดสอบบนเครือข่าย อุปกรณ์ หรือช่วงเวลาที่ต่างกัน “เร็วขึ้นจริง” หมายถึงการกระทำเดียวกัน ภายใต้เงื่อนไขเดียวกัน ให้ตัวเลขที่ดีกว่า\n\nคำสัญญาง่าย ๆ แก้ปัญหาเกือบทั้งหมดได้: วัดก่อนปรับ แล้วค่อยตัดสิน เมื่อคุณมองประสิทธิภาพเป็นปัญหาการวัด คุณจะหยุดเดาและเริ่มเรียนรู้\n\nลูปปฏิบัติได้จริงเป็นแบบนี้: เลือกการกระทำของผู้ใช้หนึ่งอย่างที่จะปรับ ปรับ baseline ภายใต้เงื่อนไขที่ทำซ้ำได้ เปลี่ยนทีละอย่างที่อธิบายได้ แล้ววัดซ้ำและเก็บการเปลี่ยนแปลงถ้าตัวเลขดีขึ้น\n\n## Paul Irish และนิสัยการวัดก่อน\n\nPaul Irish เป็นหนึ่งในผู้มีเสียงโดดเด่นเรื่องประสิทธิภาพเว็บ ผ่านงานด้านเครื่องมือของเบราว์เซอร์และคำแนะนำเรื่องประสิทธิภาพ เขาช่วยทำให้แนวคิดตรงไปตรงมานี้เป็นที่นิยม: งานแรกของคุณไม่ใช่การเดาว่าสิ่งใดช้า แต่คือการพิสูจน์\n\nแนวคิดนี้เปลี่ยนไดนามิกทีม แทนที่จะเถียงจากนิสัยว่า “รูปมักเป็นปัญหาเสมอ” หรือ “ต้องเป็นเฟรมเวิร์ก” คุณเริ่มจากหลักฐาน เมื่อชี้ให้เห็นไทม์ไลน์ คำขอที่ช้า หรือ long task ได้ การสนทนาจะเปลี่ยนจากการโทษเป็นการแก้ไข\n\n"วัดก่อนปรับ" ยังช่วยให้การถกเถียงเรื่องประสิทธิภาพเย็นลงเพราะมันสร้างกติการ่วม: ตกลงว่ากำลังวัดอะไร ตกลงว่า "ดีกว่า" หมายถึงอะไร แล้วฉลองเฉพาะเมื่อเลขขยับจริง\n\nวิธีนี้ใช้ได้ทั้งไซต์เล็กและแอปใหญ่ baseline เดียวสามารถหยุดการปรับจุกจิกแบบสุ่มบนหน้าโฆษณาได้ ในผลิตภัณฑ์ขนาดใหญ่ การวัดที่สม่ำเสมอจะช่วยไม่ให้ประสิทธิภาพกลายเป็นรายการสิ่งที่ต้องทำไม่มีวันจบ\n\nวิธีทำให้มันเป็นจริงคือมองประสิทธิภาพเหมือนบั๊กรีพอร์ต: ขั้นตอนการทำซ้ำชัดเจน เมตริกที่เห็น และการเปลี่ยนแปลงหนึ่งอย่างที่ผูกกับผลลัพธ์หนึ่งอย่าง หากสองคนไม่เห็นด้วย ให้รันการวัดอีกครั้งแล้วให้ข้อมูลตัดสิน\n\n## ประสิทธิภาพคือปัญหาการติดตั้งการวัด\n\nมองประสิทธิภาพเป็นปัญหาการติดตั้งการวัดก่อน: เพิ่มวิธีสังเกตว่าผู้ใช้ประสบอย่างไรจริง ๆ ถ้าคุณมองไม่เห็น คุณจะจบลงด้วยการถกเถียงกันด้วยความเห็น ไม่ใช่หลักฐาน นั่นคือความหมายจริงของการวัดก่อน\n\nการติดตั้งการวัดไม่จำเป็นต้องหรูหรา มันคือการเก็บสัญญาณบางอย่างอย่างสม่ำเสมอ ในจุดเดียวกัน เพื่อให้ตอบคำถามพื้นฐานได้:\n\n- อะไรที่รู้สึกช้า?\n- เวลาไปอยู่ที่ไหน?\n- การเปลี่ยนแปลงช่วยหรือไม่?\n\nโดยทั่วไปคุณต้องการข้อมูลสองประเภท\n\nข้อมูลแลปถูกจับในสภาพควบคุม: แล็ปท็อปหรืออุปกรณ์ทดสอบหนึ่งเครื่อง โปรไฟล์เครือข่ายคงที่ ขั้นตอนเดียวกันทุกการรัน มันดีสำหรับดีบักเพราะคุณทำให้ช้าซ้ำได้เมื่ออยากดู\n\nข้อมูลผู้ใช้จริงคือสิ่งที่ผู้คนเจอในโลกจริง: อุปกรณ์ สถานที่ และคุณภาพการเชื่อมต่อที่ต่างกัน มันดีสำหรับการให้ลำดับความสำคัญเพราะแสดงสิ่งที่ทำร้ายผู้ใช้จริง ไม่ใช่แค่การรันเดียว\n\nแม้ไม่เป็นผู้เชี่ยวชาญ คุณก็วัดเหตุการณ์การโหลดหน้า (เช่น คอนเทนต์แรกที่แสดง), long tasks และการบล็อก main-thread, คำขอเครือข่ายช้า, งานเรนเดอร์หนัก (layout, style, paint) และเวลาตอบเซิร์ฟเวอร์ได้\n\nสัญญาณเหล่านี้มักอยู่ในไม่กี่ที่: เครื่องมือผู้พัฒนาเบราว์เซอร์สำหรับการโปรไฟล์แลป, โลกเซิร์ฟเวอร์และเทรซสำหรับการจับเวลาแบ็กเอนด์, และแดชบอร์ด analytics หรือ RUM สำหรับข้อมูลผู้ใช้จริง ตัวอย่างเช่น ถ้า checkout รู้สึกช้า DevTools อาจแสดงว่าเบราว์เซอร์ยุ่งกับการเรนเดอร์ UI ตะกร้าขนาดใหญ่ ในขณะที่โลกเซิร์ฟเวอร์แสดงว่า API เร็ว หากไม่มีการติดตั้งการวัด คุณอาจปรับแบ็กเอนด์แต่มิได้แก้ปัญหาจริง