แนวทางคอมไพเลอร์ต่อประสิทธิภาพเว็บ: มุมมองของ Rich Harris

ทำไมบางเว็บแอปถึงรู้สึกช้าแม้บนอุปกรณ์ที่ดี

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

อาการคุ้นเคย: การโหลดครั้งแรกช้า (UI ว่างหรือยังสร้างไม่ครบ), การโต้ตอบหน่วง (คลิกแล้วเกิดขึ้นหลังจากหยุดเล็กน้อย, การเลื่อนกระตุก), และ spinner นานหลังการกระทำที่ควรรู้สึกทันที เช่น บันทึกฟอร์มหรือกรองรายการ

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

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

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

เฟรมเวิร์กเน้นรันไทม์ vs เวลาเขียน: แนวคิดพื้นฐาน

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

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

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

โมเดลที่ช่วยให้คิดง่าย:

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

ผลิตภัณฑ์จริงมักอยู่ตรงกลางแนวสเปกตรัม คอมไพเลอร์-แรกยังคงส่งโค้ดรันไทม์บางส่วน (routing, data fetching, animations, error handling) เฟรมเวิร์กที่เน้นรันไทม์ก็ใช้เทคนิคตอน build ด้วย (minification, code splitting, server rendering) คำถามเชิงปฏิบัติไม่ใช่ค่ายไหนถูกที่สุด แต่ค่ายไหนเหมาะกับสินค้าของคุณ

Rich Harris และทำไม "framework is a compiler" ถึงสำคัญ

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

แรงจูงใจเป็นเรื่องปฏิบัติ เฟรมเวิร์กที่เน้นรันไทม์หลายตัวส่งเอ็นจินทั่วไป: โลจิกคอมโพเนนต์ ความ reactive การ diffing การจัดตาราง และ helper ที่ต้องทำงานได้กับทุกแอป ความยืดหยุ่นนั้นมีค่า แต่มีค่าตรงไบต์และ CPU แม้ UI คุณจะเล็ก คุณก็ยังจ่ายค่าสำหรับรันไทม์ขนาดใหญ่

แนวทางคอมไพเลอร์กลับแบบจำลอง ระหว่าง build คอมไพเลอร์ดูคอมโพเนนต์จริงของคุณและสร้างโค้ดอัพเดต DOM เฉพาะที่จำเป็น ถ้าป้ายข้อความไม่เคยเปลี่ยน มันกลายเป็น HTML ธรรมดา ถ้ามีค่าเดียวที่เปลี่ยน ก็สร้างเฉพาะเส้นทางอัพเดตค่านั้น แทนที่จะส่งเครื่อง UI ทั่วไป คุณส่งเอาต์พุตที่ปรับแต่งสำหรับผลิตภัณฑ์ของคุณ

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

ข้อแลกเปลี่ยนยังสำคัญ:

• แบบไดนามิกบางอย่างทำยากหากคอมไพเลอร์มองไม่ออกล่วงหน้า
• คุณภาพของ tooling สำคัญขึ้น (ความเร็วการ build, การดีบัก, source maps)
• แนวทางใน ecosystem อาจต่างไป ส่งผลต่อการหาคนและการนำกลับมาใช้ซ้ำ
• คุณอาจยังต้องการ helper ฝั่งรันไทม์ แต่อยู่ในขนาดเล็กและมุ่งเป้า

กฎปฏิบัติ: ถ้า UI ของคุณรู้ได้ล่วงหน้าส่วนใหญ่ในเวลา build คอมไพเลอร์จะสร้างเอาต์พุตที่กระชับได้ ถ้า UI ของคุณไดนามิกมากหรือขับเคลื่อนด้วยปลั๊กอิน รันไทม์ที่หนักกว่าอาจง่ายกว่า

การปรับแต่งตอน build ช่วยอะไรได้บ้างในทางปฏิบัติ

การปรับแต่งตอน build เปลี่ยนตำแหน่งที่งานเกิดขึ้น การตัดสินใจหลายอย่างย้ายไปยังขั้นตอน build และงานน้อยลงถูกทิ้งไว้ให้เบราว์เซอร์

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

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

การวิเคราะห์ตอน build ยังช่วยให้ tree-shaking และการลบโค้ดที่ไม่ได้ใช้แข็งแรงขึ้น ผลตอบแทนไม่ใช่แค่ไฟล์เล็กลง แต่คือเส้นทางโค้ดที่เบราว์เซอร์ต้องโหลดและรันน้อยลง

การไฮเดรตคืออีกพื้นที่ที่ตัวเลือกตอน build ช่วยได้ การไฮเดรตคือขั้นตอนที่หน้าเรนเดอร์จากเซิร์ฟเวอร์กลายเป็นโต้ตอบได้โดยการแนบ event handler และสร้างสถานะพอสมควรในเบราว์เซอร์ ถ้าขั้นตอน build สามารถกำหนดได้ว่าส่วนไหนต้องโต้ตอบจริง ๆ ก็จะลดงานโหลดครั้งแรกได้

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

ลองนึกภาพแดชบอร์ดที่มีตัวกรองและตารางข้อมูลขนาดใหญ่ แนวทางคอมไพเลอร์-แรกสามารถรักษาการโหลดเริ่มต้นให้เบา อัพเดตเฉพาะเซลล์ที่เปลี่ยนหลังคลิกกรอง และหลีกเลี่ยงการไฮเดรตส่วนที่ไม่ต้องโต้ตอบ

เมื่อไหร่เฟรมเวิร์กที่เน้นรันไทม์ยังคงเหมาะ

รันไทม์ที่ใหญ่กว่าไม่ใช่เรื่องเลวเสมอไป มันมักแลกมาด้วยความยืดหยุ่น: แบบแผนที่ตัดสินตอนรันไทม์ คอมโพเนนต์ third-party เยอะ และเวิร์กโฟลว์ที่ผ่านการทดสอบมาหลายปี

เฟรมเวิร์กเน้นรันไทม์โดดเด่นเมื่อกฎ UI เปลี่ยนบ่อย ถ้าคุณต้องการ routing ซับซ้อน เลย์เอาต์ซ้อน ฟอร์มที่รวย และโมเดลสถานะลึก รันไทม์ที่โตเต็มที่อาจเป็นตาข่ายนิรภัย

รันไทม์จ่ายเพื่อความสะดวก

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

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

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

เมื่อโอเวอร์เฮดรันไทม์ไม่ใช่คอขวด

หลายคำร้องทุกข์ว่า "แอปช้า" มาจากสาเหตุอื่น ถ้าหน้ารอ API ช้า รูปใหญ่ ฟอนต์เยอะ หรือสคริปต์ third-party การเปลี่ยนเฟรมเวิร์กไม่แก้ปัญหา

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

"เร็วพอ" อาจเป็นเป้าหมายที่เหมาะในช่วงแรก ถ้าคุณยังพิสูจน์คุณค่าของผลิตภัณฑ์ ให้รักษาความเร็วในการวนซ้ำไว้สูง ตั้งงบประมาณพื้นฐาน แล้วค่อยรับความซับซ้อนคอมไพเลอร์-แรกเมื่อมีหลักฐานว่าจำเป็น

ประสิทธิภาพกับความเร็วในการวนซ้ำ: ข้อแลกเปลี่ยนที่แท้จริงในทีม

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

งานด้านประสิทธิภาพทำให้ลูปช้าลงเมื่อทำเร็วเกินไปหรือทำกว้างเกินไป ถ้าทุก pull request กลายเป็นการถกเถียงเรื่องจุดทอนจิ๋ว ทีมจะหยุดเสี่ยง ถ้าคุณสร้าง pipeline ที่ซับซ้อนก่อนรู้ว่าผลิตภัณฑ์เป็นอย่างไร ผู้คนจะใช้เวลาต่อสู้กับ tooling มากกว่าคุยกับผู้ใช้

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

งบประมาณเชิงปฏิบัติอาจรวม:

• หน้าพร้อมใช้งานภายในไม่กี่วินาทีบนมือถือระดับกลาง
• JavaScript ต่อเส้นทางอยู่ภายใต้เพดานที่ทีมตกลง
• การโต้ตอบหลัก (ค้นหา เพิ่มสินค้า บันทึก) ตอบสนองเร็ว
• ไม่มีฟีเจอร์เดียวเพิ่ม JS/CSS มากเกินกว่าจำนวนที่กำหนด

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

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

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

วิธีวัดประสิทธิภาพโดยไม่หลงทาง

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

ชุดเริ่มต้นง่ายๆ:

• เวลาโหลดเริ่มต้น (ถึงหน้าจอที่ใช้งานได้ครั้งแรก)
• ความหน่วงในการโต้ตอบ (การแตะ/คลิกติดหรือไม่)
• ขนาด bundle (สิ่งที่ต้องดาวน์โหลดและแยกวิเคราะห์)
• ความหน่วง API (เวลาแบ็กเอนด์ตอบ)

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

ทำให้เป็นจริง: เลือก 2–3 อุปกรณ์ที่ตรงกับผู้ใช้จริง และรันฟลูว์เดียวกันทุกครั้ง (หน้าหลัก เข้าสู่ระบบ งานที่ใช้บ่อย) ทำอย่างสม่ำเสมอ

ก่อนเปลี่ยนเฟรมเวิร์ก เก็บ baseline: บันทึกตัวเลขของ build ปัจจุบันสำหรับฟลูว์เดียวกัน เก็บรูปก่อน (before photo)

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

เมื่อเลขแย่ลง อย่าเดา เช็คสิ่งที่ปล่อย ชิ้นไหนบล็อกการเรนเดอร์ และเวลาไปที่ไหน: เครือข่าย, JavaScript, หรือ API

กรอบตัดสินใจทีละขั้นตอนที่ใช้ได้จริง

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

1. กำหนดพื้นผิวของผลิตภัณฑ์. แยกหน้าแลนดิ้ง หน้าล็อกอินแดชบอร์ด มือถือ และเครื่องมือภายใน แต่ละพื้นผิวมีผู้ใช้ อุปกรณ์ และความคาดหวังต่างกัน
2. ตั้งงบประมาณประสิทธิภาพ. เลือก 2–3 ตัวเลขที่คุณจะปกป้อง เช่น โหลดครั้งแรกบนมือถือระดับกลาง และเวลาสำหรับการโต้ตอบหลัก (ค้นหา กรอง บันทึก)
3. จัดลำดับข้อจำกัด. ซื่อสัตย์กับสิ่งที่สำคัญตอนนี้: ทักษะทีม เส้นตาย SEO กฎความเป็นส่วนตัว และที่ที่แอปต้องทำงาน
4. เลือกแนวทาง. คอมไพเลอร์-แรกเหมาะเมื่อเวลาโหลดและความเร็วการโต้ตอบเป็นเรื่องที่ไม่สามารถต่อรองได้ รันไทม์-แรกเหมาะเมื่อคุณต้องการความยืดหยุ่นสูงและการวนซ้ำเร็ว ไฮบริดมักชนะ: ทำพื้นผิวที่ไวต่อประสิทธิภาพให้เบา และใช้รันไทม์หนักในที่ที่คุ้มกับการทดลอง
5. ยืนยันด้วย thin slice แล้วล็อกการตัดสินใจ. สร้างเส้นทางผู้ใช้จริงหนึ่งเส้นจบที่จบ, วัดกับงบประมาณ, และจดบันทึกเหตุผลที่เลือก

thin slice ควรรวมส่วนที่ยุ่ง: ข้อมูลจริง auth และหน้าที่ช้าที่สุด

ถ้าต้องการวิธีตีความอย่างรวดเร็วในการทำ thin slice, Koder.ai (koder.ai) ให้คุณสร้างเว็บ แบ็กเอนด์ และแอปมือถือผ่านการแชท แล้วส่งออกซอร์ส ช่วยให้ทดสอบเส้นทางจริงตั้งแต่ต้นและกลับคืนสถานะด้วย snapshot

จงบันทึกการตัดสินใจด้วยภาษาง่ายๆ รวมถึงเงื่อนไขที่จะทำให้คุณทบทวน (การเติบโตของทราฟฟิก ส่วนแบ่งมือถือ เป้าหมาย SEO) เพื่อให้การเลือกคงอยู่เมื่อทีมเปลี่ยน