ประสิทธิภาพ Vue 3 ในปี 2026: Vapor Mode, Alien Signals และจุดจบของ Virtual DOM

Vue 3.6 Vapor Mode คือการเปลี่ยนแปลงสถาปัตยกรรมการเรนเดอร์ที่สำคัญที่สุดนับตั้งแต่ Vue นำ Virtual DOM มาใช้ในเวอร์ชัน 2 ด้วยการคอมไพล์ Single File Component ให้เป็นการทำงานกับ DOM แบบ imperative โดยตรง Vapor Mode จึงกำจัดภาระงาน diffing ที่นิยามไพป์ไลน์การเรนเดอร์ของ Vue มานานหลายปี เมื่อรวมกับการเขียนระบบ reactivity ขึ้นใหม่บนพื้นฐาน Alien Signals Vue 3.6 ก็ทำคะแนนเบนช์มาร์กได้ทัดเทียมกับ Solid.js และ Svelte 5 โดยที่นักพัฒนาไม่ต้องเรียนรู้ API ใหม่

Virtual DOM ของ Vue ทำงานอย่างไร — และเหตุใดจึงกลายเป็นคอขวด

รูปแบบ Virtual DOM (VDOM) ที่ React ทำให้แพร่หลายและ Vue 2 นำมาใช้ จะสร้างตัวแทนแบบ JavaScript ที่เบาของต้นไม้ DOM จริง ทุกครั้งที่ state เปลี่ยน Vue จะสร้างต้นไม้ VDOM ใหม่ เปรียบเทียบกับต้นไม้ก่อนหน้า แล้วแพตช์เฉพาะโหนดที่เปลี่ยนเข้าสู่ DOM จริง

แนวทางนี้ทำงานได้ดีกับแอปพลิเคชันส่วนใหญ่ อัลกอริทึม diffing ทำงานในเวลา O(n) และคอมไพเลอร์ของ Vue ก็ปรับ subtree แบบสแตติกออกจากเส้นทาง diff อยู่แล้ว แต่ภาระงานจะสะสมในบางสถานการณ์:

• รายการขนาดใหญ่ ที่มีหลายร้อยแถวกระตุ้นการเปรียบเทียบ subtree ทั้งหมดในทุกการอัปเดต
• การเปลี่ยน state บ่อยครั้ง (แอนิเมชัน ข้อมูลเรียลไทม์) สร้าง VDOM churn ที่ garbage collector ต้องเก็บกวาด
• ต้นไม้คอมโพเนนต์ที่ลึก ทวีคูณต้นทุนการไล่ผ่านต้นไม้และการสร้างแพตช์

คอมไพเลอร์เทมเพลตของ Vue 3 ได้นำการปรับแต่ง VDOM หลายอย่างมาใช้ — static hoisting, patch flag, block tree — ซึ่งลดงานที่ไม่จำเป็นลง สิ่งเหล่านี้ให้การปรับปรุงที่วัดผลได้ แต่สถาปัตยกรรมพื้นฐานยังคงต้องสร้าง เปรียบเทียบ และทิ้งอ็อบเจกต์ JavaScript ในทุกรอบการเรนเดอร์

Vue 3.6 Vapor Mode: คอมไพล์เพื่อกำจัด Virtual DOM

Vapor Mode ใช้แนวทางที่แตกต่างออกไปอย่างสิ้นเชิง แทนที่จะคอมไพล์เทมเพลตเป็นฟังก์ชันเรนเดอร์ที่คืนค่าโหนด VDOM คอมไพเลอร์ Vapor จะสร้างโค้ดที่สร้างและอัปเดตอิลิเมนต์ DOM โดยตรง การผูก reactive แต่ละจุดจะแมปไปยังการกลายพันธุ์ DOM ที่เจาะจง โดยไม่ต้องมีตัวแทนตัวกลาง

ต่อไปนี้คือวิธีที่คอมโพเนนต์ Vue มาตรฐานคอมไพล์แตกต่างกันในแต่ละโหมด:

<!-- Counter.vue -->
<script setup vapor>
import { ref } from 'vue'

const count = ref(0)
const increment = () => count.value++
</script>

<template>
  <button @click="increment">
    Count: {{ count }}
  </button>
</template>

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

ในโหมด Vapor คอมไพเลอร์จะสร้างบางอย่างที่ใกล้เคียงกับนี้:

// Simplified Vapor compilation output
const button = document.createElement('button')
const text = document.createTextNode('Count: 0')
button.appendChild(text)

// Direct binding: reactive source -> DOM mutation
effect(() => {
  text.nodeValue = `Count: ${count.value}`
})

button.addEventListener('click', increment)

เอฟเฟกต์ reactive เชื่อม count เข้ากับ text.nodeValue โดยตรง ไม่มีการสร้าง VDOM ไม่มี diffing ไม่มีการแพตช์ การเปลี่ยน state กระตุ้นการกลายพันธุ์ DOM เพียงครั้งเดียวพอดี

การเปิดใช้งาน Vapor Mode ในโปรเจกต์

Vapor Mode ทำงานในระดับคอมโพเนนต์ มีกลยุทธ์การผสานรวมสองแบบ:

import { createVaporApp } from 'vue'
import App from './App.vue'

createVaporApp(App).mount('#app')

import { createApp, vaporInteropPlugin } from 'vue'
import App from './App.vue'

createApp(App)
  .use(vaporInteropPlugin)
  .mount('#app')

แนวทางแบบไฮบริดช่วยให้ย้ายทีละน้อยได้ คอมโพเนนต์ที่สำคัญต่อประสิทธิภาพ — ตารางข้อมูล แดชบอร์ดเรียลไทม์ วิวที่มีแอนิเมชันหนาแน่น — สามารถเลือกใช้ Vapor ได้ ขณะที่ส่วนที่เหลือของแอปยังคงใช้รันไทม์ VDOM มาตรฐาน คอมโพเนนต์ทั้งสองชนิดอยู่ร่วมกันในต้นไม้คอมโพเนนต์เดียวกัน

Alien Signals: เครื่องยนต์ reactivity ใหม่ของ Vue

Vue 3.6 นำการเปลี่ยนแปลงครั้งใหญ่อย่างที่สองมาควบคู่กับ Vapor Mode: การเขียน @vue/reactivity ขึ้นใหม่ทั้งหมดบนพื้นฐานของไลบรารี Alien Signals สร้างโดย Johnson Chu Alien Signals ใช้อัลกอริทึม reactivity แบบ push-pull ที่ลดทั้งการจัดสรรหน่วยความจำและภาระงานการคำนวณ

โมเดล push-pull ทำงานในสองเฟส:

1. เฟส push — เมื่อ signal (แหล่ง reactive) เปลี่ยนแปลง มันจะกระจายแฟล็ก "dirty" ไปยัง computed property ที่พึ่งพาทั้งหมด การไล่ผ่านนี้มีต้นทุนต่ำ เพราะเพียงพลิกแฟล็กบูลีนโดยไม่รันการคำนวณใด ๆ
2. เฟส pull — เมื่อมีการอ่าน computed property มันจะตรวจสอบแฟล็ก dirty ของตน หากเป็น dirty มันจะคำนวณใหม่ หากเป็น clean มันจะคืนค่าที่แคชไว้ทันที

การออกแบบนี้กำจัดการคำนวณใหม่ที่ไม่จำเป็น ในระบบ reactivity ของ Vue 3.5 computed property ที่พึ่งพา signal สามตัวจะคำนวณใหม่ทุกครั้งที่ signal ใดเปลี่ยน แม้ผลลัพธ์จะเท่าเดิม Alien Signals จะคำนวณใหม่ก็ต่อเมื่อมีการอ่านค่าจริง ๆ และมีการพึ่งพาอย่างน้อยหนึ่งรายการเปลี่ยนไป

import { ref, computed, watch } from 'vue'

const firstName = ref('Jane')
const lastName = ref('Doe')
const isActive = ref(true)

// This computed only recalculates when read AND dirty
const displayName = computed(() => {
  return isActive.value
    ? `${firstName.value} ${lastName.value}`
    : 'Inactive User'
})

// Changing isActive marks displayName as dirty
// But no computation runs until something reads displayName.value
isActive.value = false

// NOW the recalculation happens
console.log(displayName.value) // 'Inactive User'

โครงสร้างข้อมูลภายในก็เปลี่ยนไปด้วย Alien Signals แทนที่การติดตามการพึ่งพาแบบ Set ด้วยลิงก์ลิสต์สองทาง ซึ่งลดหน่วยความจำต่อการพึ่งพา reactive แต่ละรายการ และเพิ่มความเร็วการไล่ผ่านระหว่างการเก็บกวาด

ผลเบนช์มาร์ก: Alien Signals ในทางปฏิบัติ

ตัวเลขจากเบนช์มาร์กเวอร์ชันเบตาของ Vue 3.6 แสดงการปรับปรุงที่สม่ำเสมอเหนือ Vue 3.5:

| ตัวชี้วัด | Vue 3.5 | Vue 3.6 (Alien Signals) | การปรับปรุง | |---|---|---|---| | หน่วยความจำต่อ ref reactive | ค่าฐาน | -14% | จัดสรรน้อยลง | | การคำนวณ computed ใหม่ | ค่าฐาน | -20% เฉลี่ย | รันที่ไม่จำเป็นน้อยลง | | การ mount คอมโพเนนต์ (100k) | ~300ms | ~100ms | เร็วขึ้น 3 เท่า | | First Contentful Paint | ค่าฐาน | ทั่วไป 0.7s | ภาระของเฟรมเวิร์กลดลง | | ขนาดบันเดิลพื้นฐาน | ~16KB | <10KB | -37% |

ผลประโยชน์เหล่านี้ใช้กับทุกแอปพลิเคชัน Vue 3.6 โดยอัตโนมัติ ต่างจาก Vapor Mode ที่ต้องเปิดใช้งานเป็นรายคอมโพเนนต์ ระบบ reactivity ของ Alien Signals เป็นค่าเริ่มต้นใน Vue 3.6

เทคนิคปรับแต่งประสิทธิภาพ Vue 3 ในทางปฏิบัติ

Vapor Mode และ Alien Signals จัดการภาระงานในระดับเฟรมเวิร์ก แต่ประสิทธิภาพในระดับแอปพลิเคชันยังขึ้นอยู่กับวิธีจัดโครงสร้างคอมโพเนนต์ เทคนิคเหล่านี้ใช้ได้กับทั้งคอมโพเนนต์ VDOM และ Vapor

Reactivity แบบตื้นสำหรับโครงสร้างข้อมูลขนาดใหญ่

Reactivity แบบลึกจะห่อทุกพร็อพเพอร์ตีที่ซ้อนกันไว้ใน Proxy สำหรับชุดข้อมูลขนาดใหญ่ — การตอบกลับจาก API อ็อบเจกต์การตั้งค่า สเตตที่แคชไว้ — สิ่งนี้สร้างตัวห่อ Proxy ที่ไม่จำเป็นนับพัน shallowRef และ shallowReactive จำกัด reactivity ไว้ที่การอ้างอิงระดับบนสุด

import { shallowRef, triggerRef } from 'vue'

interface Product {
  id: number
  name: string
  variants: { sku: string; price: number }[]
}

// Only the ref itself is reactive, not the nested properties
const products = shallowRef<Product[]>([])

// Fetching data — assign the new array to trigger reactivity
async function fetchProducts() {
  const response = await fetch('/api/products')
  products.value = await response.json() // triggers update
}

// Mutating nested data — must manually trigger
function updatePrice(productId: number, sku: string, newPrice: number) {
  const product = products.value.find(p => p.id === productId)
  const variant = product?.variants.find(v => v.sku === sku)
  if (variant) {
    variant.price = newPrice
    triggerRef(products) // explicit trigger required
  }
}

ไดเรกทิฟ v-memo สำหรับการเรนเดอร์รายการที่มีต้นทุนสูง

สำหรับคอมโพเนนต์ VDOM ที่เรนเดอร์รายการยาว v-memo จะแคชผลการเรนเดอร์ subtree ตามค่าของการพึ่งพา VDOM จะข้ามการ diffing ทั้งหมดสำหรับ subtree ที่ถูกเมโมไว้ซึ่งการพึ่งพาไม่เปลี่ยน

<!-- ProductGrid.vue -->
<script setup>
import { ref } from 'vue'

const products = ref([])
const selectedId = ref(null)
</script>

<template>
  <div class="grid">
    <div
      v-for="product in products"
      :key="product.id"
      v-memo="[product.id === selectedId, product.price]"
      :class="{ selected: product.id === selectedId }"
    >
      <h3>{{ product.name }}</h3>
      <span>{{ product.price }}</span>
    </div>
  </div>
</template>

อาร์เรย์ v-memo [product.id === selectedId, product.price] บอก Vue ว่า อย่าเรนเดอร์ไอเท็มนี้ใหม่เว้นแต่สถานะการเลือกหรือราคาจะเปลี่ยน สำหรับรายการสินค้า 500 รายการที่มีเพียงรายการเดียวถูกเลือก สิ่งนี้ลดงานของ VDOM จาก 500 diff ของ subtree เหลือ 2 (ไอเท็มที่เลือกก่อนหน้าและไอเท็มที่เพิ่งถูกเลือก)

คอมโพเนนต์แบบอะซิงโครนัสกับ Suspense สำหรับการแบ่งโค้ด

การโหลดคอมโพเนนต์หนัก ๆ แบบ lazy ช่วยให้บันเดิลเริ่มต้นเล็กกระชับ defineAsyncComponent ของ Vue ที่จับคู่กับ Suspense จัดการสถานะการโหลดในเชิงประกาศ

<!-- Dashboard.vue -->
<script setup>
import { defineAsyncComponent } from 'vue'

// Heavy charting library loaded only when needed
const AnalyticsChart = defineAsyncComponent(() =>
  import('./components/AnalyticsChart.vue')
)

const DataExport = defineAsyncComponent({
  loader: () => import('./components/DataExport.vue'),
  delay: 200,       // show loading after 200ms
  timeout: 10000,   // fail after 10s
})
</script>

<template>
  <Suspense>
    <template #default>
      <AnalyticsChart />
      <DataExport />
    </template>
    <template #fallback>
      <div class="skeleton-loader" />
    </template>
  </Suspense>
</template>

Vapor Mode กับ VDOM: เมื่อใดควรใช้แต่ละแนวทาง

Vapor Mode ไม่ใช่ตัวแทนสากลของ Virtual DOM โหมดการคอมไพล์แต่ละแบบมีจุดแข็งที่เหมาะกับโปรไฟล์คอมโพเนนต์ที่ต่างกัน

| สถานการณ์ | โหมดที่แนะนำ | เหตุผล | |---|---|---| | ตารางข้อมูล (1000+ แถว) | Vapor | กำจัดภาระ VDOM ต่อแถว | | แดชบอร์ดเรียลไทม์ | Vapor | การอัปเดตบ่อยได้ประโยชน์จากการผูก DOM โดยตรง | | คอมโพเนนต์ที่มีแอนิเมชันหนาแน่น | Vapor | ไม่มีแรงกดดันต่อ GC จาก VDOM churn | | ไลบรารีคอมโพเนนต์ VDOM ของบุคคลที่สาม | VDOM | เลเยอร์ interop เพิ่มความซับซ้อน | | คอมโพเนนต์ที่ใช้ Options API | VDOM | Vapor ต้องใช้ Composition API | | ฟอร์มที่มีการตรวจสอบซับซ้อน | ทั้งสองแบบ | ภาระการเรนเดอร์น้อยทั้งสองโหมด | | หน้าเนื้อหาแบบสแตติก | ทั้งสองแบบ | SSG/SSR รับงานหนักไว้ |

เส้นทางการย้ายที่แนะนำ: โปรไฟล์แอปก่อนด้วยแท็บ Performance ของ Vue DevTools ระบุคอมโพเนนต์ที่มีเวลาการเรนเดอร์และความถี่ในการเรนเดอร์ซ้ำสูงสุด แปลงเป็น Vapor Mode วัดผลกระทบ แล้วขยายต่อจากนั้น

คำถามสัมภาษณ์: ประสิทธิภาพ Vue 3 และ Vapor Mode

คำถามเหล่านี้สะท้อนสิ่งที่ทีมวิศวกรรมถามในปี 2026 เมื่อประเมินความเชี่ยวชาญ Vue แต่ละคำตอบสรุปเหตุผลทางเทคนิคที่ผู้สัมภาษณ์คาดหวัง

ถาม: Vapor Mode แก้ปัญหาอะไร และต่างจากการปรับแต่ง VDOM ที่ Vue มีอยู่แล้วอย่างไร?

คอมไพเลอร์ VDOM ของ Vue 3 ปรับ subtree แบบสแตติก เพิ่ม patch flag และใช้ block tree เพื่อข้าม diff ที่ไม่จำเป็นอยู่แล้ว สิ่งเหล่านี้ลดภาระ VDOM แต่ไม่ได้กำจัดมัน — ทุกการเปลี่ยน state ยังต้องสร้างโหนด VDOM ไล่ผ่านต้นไม้ และสร้างแพตช์ Vapor Mode ลบไพป์ไลน์ทั้งหมดนี้ออก คอมไพเลอร์แมปสเตต reactive ไปยังการกลายพันธุ์ DOM โดยตรง ดังนั้นการเปลี่ยน state จะกระตุ้นการทำงาน DOM ที่จำเป็นพอดี — ไม่มีโครงสร้างข้อมูลตัวกลาง ไม่มีอัลกอริทึม diffing ไม่มี garbage collection ของโหนด VDOM ที่ถูกทิ้ง

ถาม: คอมโพเนนต์ Vapor และ VDOM อยู่ร่วมกันในแอปพลิเคชันเดียวได้หรือไม่?

ได้ vaporInteropPlugin อนุญาตให้ใช้คอมโพเนนต์ทั้งสองชนิดในต้นไม้คอมโพเนนต์เดียว พาเรนต์ VDOM สามารถเรนเดอร์ลูกที่เป็น Vapor และในทางกลับกัน โดยมีข้อควรระวังบางประการ: slot ของ Vapor ไม่สามารถใช้ slots.default() ภายในคอมโพเนนต์ VDOM ได้ (ให้ใช้ renderSlot แทน) และการทำงานร่วมกับไลบรารีคอมโพเนนต์ที่อิงกับ VDOM (Vuetify, PrimeVue) อาจยังขรุขระในช่วงทดลอง

ถาม: อธิบายโมเดล reactivity แบบ push-pull ใน Alien Signals ของ Vue 3.6

โมเดล push-pull แบ่งการอัปเดต reactive ออกเป็นสองเฟส ในเฟส push เมื่อ signal เปลี่ยนค่า ระบบจะกระจายแฟล็ก dirty ลงไปยัง computed property ที่พึ่งพาทั้งหมด — ซึ่งมีต้นทุนต่ำเพราะเพียงพลิกแฟล็กบูลีน ในเฟส pull เมื่อมีการอ่านค่า computed จริง ๆ มันจะตรวจสอบว่าเป็น dirty หรือไม่ หากเป็น dirty มันจะคำนวณใหม่จากการพึ่งพา หากเป็น clean มันจะคืนค่าที่แคชไว้ สิ่งนี้หลีกเลี่ยงการคำนวณ computed property ล่วงหน้าที่อาจไม่เคยถูกอ่านในรอบการอัปเดตหนึ่ง ๆ

ถาม: ควรใช้ shallowRef แทน ref ในแอปพลิเคชัน Vue 3 เมื่อใด?

shallowRef เหมาะเมื่อโครงสร้างข้อมูลมีขนาดใหญ่ และมีเพียงการกำหนดค่าใหม่ระดับบนสุดเท่านั้นที่ควรกระตุ้น reactivity — แคชการตอบกลับ API อ็อบเจกต์การตั้งค่า และอาร์เรย์ขนาดใหญ่ที่ควบคุมการกลายพันธุ์ของแต่ละไอเท็มด้วยตนเองผ่าน triggerRef() Reactivity แบบลึกจะห่อทุกพร็อพเพอร์ตีที่ซ้อนกันไว้ใน Proxy ซึ่งเป็นภาระที่ไม่จำเป็นสำหรับข้อมูลที่จะถูกแทนที่ทั้งก้อนแทนการกลายพันธุ์ในที่

ฝึก คำถามสัมภาษณ์ Vue.js เพิ่มเติมที่ครอบคลุม composable และรูปแบบ reactivity บน SharpSkill

บทสรุป

• Vapor Mode คอมไพล์ SFC ของ Vue เป็นการทำงานกับ DOM โดยตรง กำจัดการสร้าง diffing และ patching ของ Virtual DOM ออกทั้งหมด
• เปิดใช้งานเป็นรายคอมโพเนนต์ด้วย <script setup vapor> — ไม่ต้องย้ายทั้งแอปพลิเคชัน
• Alien Signals ซึ่งเป็นเครื่องยนต์ reactivity เริ่มต้นตัวใหม่ ลดการใช้หน่วยความจำ 14% และเพิ่มประสิทธิภาพ computed property ด้วยการประเมินแบบ lazy push-pull
• ใช้ shallowRef สำหรับโครงสร้างข้อมูลขนาดใหญ่ v-memo สำหรับการเรนเดอร์รายการที่มีต้นทุนสูง และ defineAsyncComponent สำหรับการแบ่งโค้ด — รูปแบบเหล่านี้ใช้ได้ทั้งสองโหมด
• Vapor Mode ต้องใช้ Composition API ร่วมกับ <script setup> Options API, getCurrentInstance() และ globalProperties ไม่รองรับ
• โปรไฟล์ด้วย Vue DevTools ก่อน แปลงคอมโพเนนต์ที่มีผลกระทบสูงเป็น Vapor วัดผล แล้วทำซ้ำ
• Vue 3.6 อยู่ในช่วงเบตาเมื่อต้นปี 2026 — ให้ถือว่า Vapor Mode ยังเป็นการทดลองสำหรับแอปพลิเคชันบนโปรดักชัน แต่เริ่มสร้างความคุ้นเคยให้ทีมตั้งแต่ตอนนี้