หากคุณสนใจเฉพาะประสิทธิภาพคำแนะนำส่วนใหญ่ในชุดข้อความนี้ไม่ถูกต้องและผิดพลาดมากขึ้นเรื่อย ๆ ในยุค SPA ซึ่งเราสามารถสันนิษฐานได้ว่าหน้าเว็บนั้นไร้ประโยชน์หากไม่มีรหัส JS ฉันใช้เวลานับไม่ถ้วนในการเพิ่มประสิทธิภาพเวลาในการโหลดหน้า SPA และตรวจสอบผลลัพธ์เหล่านี้ด้วยเบราว์เซอร์ต่างๆ ประสิทธิภาพที่เพิ่มขึ้นทั่วทั้งกระดานโดยการจัดระเบียบ html ของคุณใหม่อาจเป็นเรื่องที่น่าทึ่งมาก
เพื่อให้ได้ประสิทธิภาพสูงสุดคุณต้องคิดว่าเพจเป็นจรวดสองขั้นตอน ทั้งสองขั้นตอนประมาณสอดคล้องกับการ<head>และ<body>ขั้นตอน แต่คิดว่าพวกเขาแทนที่จะเป็นและ<static> <dynamic>ส่วนคงที่โดยพื้นฐานแล้วเป็นค่าคงที่ของสตริงที่คุณดันท่อตอบสนองให้เร็วที่สุดเท่าที่จะทำได้ อาจเป็นเรื่องยุ่งยากเล็กน้อยหากคุณใช้มิดเดิลแวร์จำนวนมากที่ตั้งค่าคุกกี้ (จำเป็นต้องตั้งค่าก่อนที่จะส่งเนื้อหา http) แต่โดยหลักการแล้วมันเป็นเพียงการล้างบัฟเฟอร์การตอบสนองหวังว่าก่อนที่จะกระโดดลงในโค้ดเทมเพลต (razor, php, ฯลฯ ) บนเซิร์ฟเวอร์ นี่อาจฟังดูยาก แต่ฉันแค่อธิบายผิดเพราะมันเป็นเรื่องเล็กน้อย ตามที่คุณอาจเดาได้ส่วนที่คงที่นี้ควรมี javascript ทั้งหมดที่อยู่ในบรรทัดและย่อขนาด มันจะดูเหมือน
<!DOCTYPE html>
<html>
<head>
<script>/*...inlined jquery, angular, your code*/</script>
<style>/* ditto css */</style>
</head>
<body>
<!-- inline all your templates, if applicable -->
<script type='template-mime' id='1'></script>
<script type='template-mime' id='2'></script>
<script type='template-mime' id='3'></script>
เนื่องจากคุณไม่มีค่าใช้จ่ายใด ๆ ในการส่งส่วนนี้ลงไปคุณสามารถคาดหวังได้ว่าไคลเอนต์จะเริ่มได้รับเวลาแฝงประมาณ 5ms + หลังจากเชื่อมต่อกับเซิร์ฟเวอร์ของคุณ สมมติว่าเซิร์ฟเวอร์ปิดพอสมควรเวลาแฝงนี้อาจอยู่ระหว่าง 20ms ถึง 60ms เบราว์เซอร์จะเริ่มประมวลผลส่วนนี้ทันทีที่ได้รับและเวลาในการประมวลผลโดยปกติจะมีผลเหนือเวลาในการถ่ายโอนตามแฟคเตอร์ 20 ขึ้นไปซึ่งตอนนี้เป็นช่วงเวลาตัดจำหน่ายของคุณสำหรับการประมวลผลในฝั่งเซิร์ฟเวอร์ของ<dynamic>ส่วนนั้น
เบราว์เซอร์ใช้เวลาประมาณ 50ms (chrome พักอาจช้ากว่า 20%) ในการประมวลผล jquery + signalr แบบอินไลน์ + angular + ng animate + ng touch + ng เส้นทาง + lodash มันน่าทึ่งมากในตัวของมันเอง เว็บแอปส่วนใหญ่มีโค้ดน้อยกว่าไลบรารียอดนิยมทั้งหมดที่รวมกัน แต่สมมติว่าคุณมีมากพอ ๆ กันดังนั้นเราจะชนะเวลาแฝง + 100 มิลลิวินาทีในการประมวลผลบนไคลเอนต์ (เวลาแฝงที่ชนะนี้มาจากส่วนการถ่ายโอนที่สอง) เมื่อถึงช่วงที่สองเราได้ประมวลผลโค้ด js และเทมเพลตทั้งหมดและเราสามารถเริ่มดำเนินการแปลง dom ได้
คุณอาจคัดค้านว่าวิธีนี้ตั้งฉากกับแนวคิดแบบอินไลน์ แต่ไม่ใช่ หากคุณแทนที่จะเชื่อมโยงไปยัง cdns หรือเซิร์ฟเวอร์ของคุณเองเบราว์เซอร์จะต้องเปิดการเชื่อมต่ออื่นและชะลอการดำเนินการ เนื่องจากการดำเนินการนี้โดยทั่วไปฟรี (เนื่องจากฝั่งเซิร์ฟเวอร์กำลังคุยกับฐานข้อมูล) จึงต้องชัดเจนว่าการกระโดดทั้งหมดนี้จะเสียค่าใช้จ่ายมากกว่าการไม่กระโดดเลย หากมีมุมมองเบราว์เซอร์ที่กล่าวว่า js ภายนอกทำงานได้เร็วขึ้นเราสามารถวัดได้ว่าปัจจัยใดครอบงำ การวัดของฉันระบุว่าคำขอพิเศษฆ่าประสิทธิภาพในขั้นตอนนี้
ฉันทำงานหนักมากกับการเพิ่มประสิทธิภาพของแอป SPA เป็นเรื่องปกติที่ผู้คนจะคิดว่าปริมาณข้อมูลเป็นเรื่องใหญ่ในขณะที่เวลาแฝงความจริงและการดำเนินการมักมีอิทธิพลเหนือกว่า ไลบรารีที่ย่อขนาดที่ฉันระบุไว้นั้นเพิ่มข้อมูลได้มากถึง 300kb และนั่นเป็นเพียง 68 kb gzipped หรือดาวน์โหลด 200ms บนโทรศัพท์ 2mbit 3g / 4g ซึ่งเป็นเวลาแฝงที่จะใช้ในโทรศัพท์เครื่องเดียวกันเพื่อตรวจสอบว่ามีข้อมูลเดียวกันหรือไม่ ในแคชอยู่แล้วแม้ว่าจะมีการแคชพร็อกซีก็ตามเนื่องจากยังคงมีการเรียกเก็บภาษีเวลาแฝงของอุปกรณ์เคลื่อนที่ (โทรศัพท์ถึงทาวเวอร์ - เวลาในการตอบสนอง) ในขณะเดียวกันการเชื่อมต่อเดสก์ท็อปที่มีเวลาแฝงในการแสดงครั้งแรกที่ต่ำกว่ามักจะมีแบนด์วิดท์ที่สูงกว่าอยู่ดี
ในระยะสั้นตอนนี้ (2014) ควรแทรกสคริปต์สไตล์และเทมเพลตทั้งหมดไว้ในบรรทัด
แก้ไข (พฤษภาคม 2016)
เนื่องจากแอปพลิเคชัน JS เติบโตขึ้นอย่างต่อเนื่องและตอนนี้ payload บางส่วนของฉันมีโค้ดย่อขนาดถึง 3+ เมกะไบต์จึงเห็นได้ชัดว่าอย่างน้อยที่สุดไลบรารีทั่วไปไม่ควรอยู่ในแนวอินไลน์อีกต่อไป