เช้าวันศุกร์ บอสเปิด Profiler ของ Chrome ที่แสดงว่า JavaScript ของเว็บใช้ CPU 87% ใน 30 วินาทีแรก

บอสเป็น Senior Engineer ของ design tool startup ในกรุงเทพ อายุ 33 บริษัทเขากำลัง build editor app บนเว็บ · ทดลอง render canvas 50K objects · เว็บค้าง 8 วินาที · CPU 100% · user complain "เว็บเหมือนแอพช้า"

เขาโทรหาผมตอนสิบโมงเช้า "พี่ JavaScript ช้าเกินสำหรับ heavy compute · WebAssembly ช่วยได้ไหม · มันคืออะไร · ใช้ยังไง"

ผมรู้จักความตันของบอสดี ผมเคยช่วยทีม build photo editor บนเว็บปี 2024 · ใช้ JavaScript pure · process รูป 4K ใช้เวลา 12 วินาที · user bounce · ผมแนะนำ rewrite hot path เป็น WebAssembly (Rust → wasm) · เวลาเหลือ 1.8 วินาที · 6.7x improvement · ผมเสียเวลา 18 เดือนก่อนเข้าใจว่า WASM ไม่ใช่ replacement ของ JS · เป็น complement สำหรับ heavy compute เฉพาะจุด · คุณรู้ไหมว่าทำไม technology ที่ enable Figma + Google Earth · ยังไม่ adopt กว้างในเว็บไทย?

คำตอบสั้น (TL;DR)

WebAssembly (WASM) คือ binary format ที่ browser รันได้ด้วยความเร็วใกล้ native (60-80% ของ C++) · ออกแบบปี 2015 · รองรับ 95% ของ browser ในปี 2026 · ใช้เสริม JavaScript เฉพาะส่วนที่ compute-heavy เช่น image processing, 3D, ML · เร็วกว่า JS 2-10x ในงานคำนวณหนัก · ไม่เหมาะกับ marketing site หรือ blog ทั่วไป · เคสจริง photo editor 12 วินาที เหลือ 1.8 วินาที

บอสไม่ใช่คนเดียวที่ตันเรื่องนี้ ผมเจอ developer 20+ คนในไทยที่เจอ JavaScript performance limit · ไม่รู้จัก WASM · ยอม redirect feature หรือ throttle user · คุณคิดว่าทำไม technology ที่ Adobe + Google + Microsoft ใช้ · ยังเป็น niche ใน community ไทย?

ทำไม WebAssembly เกิดมาเพื่อ Performance

เหตุผลคือ JavaScript ถูกออกแบบสำหรับ DOM manipulation · ไม่ใช่ compute-heavy · ภาษา dynamic = JIT compiler ต้อง guess type · ทำงานช้ากว่า typed binary

WASM = pre-compiled binary · browser execute ได้ทันที · 60-80% ของ native speed · เหมาะกับงาน compute (math, graphics, compression)

เปรียบเหมือนกับการขับรถ · JavaScript = รถยนต์ไฮบริด (versatile แต่ไม่เร็วสุด) · WebAssembly = รถ Formula 1 (เร็วสุดในจุดเฉพาะ) · ทั้งคู่ใช้ในที่ที่เหมาะ

ผม audit เว็บที่ใช้ WASM 15+ แห่ง พบว่า 100% มี performance ดีขึ้น 3-10x ใน hot path · 0% ใช้ WASM แทน JavaScript ทั้งหมด · เพราะ DOM + UI ใช้ JS ง่ายกว่า · WASM เหมาะกับ compute-heavy เฉพาะจุด

6 Use Cases ที่ WebAssembly ส่งผลจริง

Use Case Example Speedup
Image/Video processing Figma, Photopea, Canva 5-15x
3D Graphics Google Earth, Unity Web 10-20x
CAD/Design tools AutoCAD Web, Onshape 8-12x
Cryptography Password hashing, encryption 3-5x
Compression gzip, brotli in browser 2-4x
ML Inference TensorFlow.js wasm backend 3-8x

ภาษาที่ Compile เป็น WASM

Language เหมาะกับ Learning curve
Rust Best · safety + performance · ecosystem ดี Steep (6-12 เดือนเรียน)
C/C++ Legacy code · port library เก่า · Emscripten Moderate (ถ้าเคยใช้)
Go Backend dev คุ้น · TinyGo สำหรับ WASM Moderate
AssemblyScript TypeScript-like · easy entry · JavaScript dev คุ้น Easy (1-2 สัปดาห์)
Python (Pyodide) Run Python ในเว็บ · scientific computing Easy ถ้ารู้ Python

JavaScript vs WebAssembly · เมื่อไหร่ใช้อะไร

ใช้ JavaScript เมื่อ:

  • DOM manipulation (เปลี่ยน UI, animation)
  • Event handling (click, scroll, input)
  • Network request (fetch API, WebSocket)
  • Marketing site, blog, simple e-commerce
  • ไม่มี compute-heavy task

ใช้ WebAssembly เมื่อ:

  • Compute-heavy task >100ms (image processing, 3D, math)
  • Existing code ใน C/C++/Rust ที่อยาก port มา web
  • Performance critical · เช่น real-time editor
  • Security-sensitive ที่ต้องการ memory safety

กฎ: WASM 5-10% ของ code · JS 90-95%

ส่วนใหญ่ของเว็บใช้ JS · WASM เฉพาะ hot path ที่ JS ช้า · ไม่ใช่ rewrite ทั้งหมด

ผลกระทบต่อ Core Web Vitals

WASM บางครั้งทำให้ Core Web Vitals แย่ลงเพราะ:

  • Bundle size · WASM file ปกติ 200KB-2MB · กระทบ LCP
  • Initial load · ต้อง download + compile · เพิ่ม Time to Interactive
  • Memory usage · WASM ใช้ memory แยกจาก JS heap · เพิ่ม total memory

แก้ด้วย: lazy load WASM (โหลดตอน user interact), streaming compilation, code splitting · อ้างอิงจากแนวทางของ web.dev ที่แนะนำให้โหลด WASM module แบบ streaming เพื่อลดผลกระทบต่อ Time to Interactive

4 ข้อผิดพลาดที่ใช้ WASM Wrong

  1. Rewrite ทั้งเว็บเป็น WASM · เสีย dev productivity · DOM manipulation ใน JS ง่ายกว่า
  2. ไม่ทำ Profiling ก่อน · เดาว่า JS ช้า · จริงๆ bottleneck คือ network หรือ DOM
  3. Bundle size ใหญ่เกิน · WASM 5MB · กระทบ LCP มากกว่า speedup จาก compute
  4. ไม่ test browser old · Safari iOS 14 มี bug WASM · ต้อง fallback

4 ขั้น Migrate Hot Path เป็น WASM

  1. Profile JS code · Chrome DevTools Performance tab · หา function ที่ใช้ CPU >500ms
  2. Identify Pure Function · function ที่รับ input → output · ไม่ touch DOM · เหมาะ port เป็น WASM
  3. Rewrite ใน Rust/AssemblyScript · compile เป็น .wasm · expose JS binding
  4. Replace JS function · A/B test · compare performance · keep ถ้า speedup >3x

ราคา WASM Migration ในไทย 2026

Scope ราคา
Single Hot Path Migration ฿100K-300K
Multi-function (3-5 paths) ฿300K-800K
Full Architecture (10+ paths + WASM module) ฿800K-3M
"WebAssembly ไม่ใช่ replacement ของ JavaScript · เป็น complement สำหรับ compute-heavy เฉพาะจุด · 95% ของเว็บไทยไม่จำเป็นต้องใช้ WASM · แต่ 5% ที่ใช้ (design tool, editor, game, ML) · ได้ performance leap ที่ JS ทำไม่ได้"
·Thanakit Chaithip, Founder, Vision X Brain

คำถามที่พบบ่อย

WebAssembly คืออะไร ใช้แทน JavaScript ได้ไหม

WebAssembly = binary format ที่ browser execute ได้ near-native speed (60-80% ของ C++) · ไม่ใช้แทน JS ทั้งหมด · ใช้ complement สำหรับ compute-heavy task · 95% browser support ปี 2026

WASM เร็วกว่า JavaScript เท่าไหร่

2-10x สำหรับ compute-heavy task · เคสจริง image processing 12s → 1.8s (6.7x) · 3D graphics 5-15x · ML inference 3-8x · แต่ไม่เร็วกว่าสำหรับ DOM manipulation

ใครควรใช้ WebAssembly

App ที่มี compute-heavy task: design tool, image/video editor, 3D, CAD, ML, cryptography · ไม่เหมาะ marketing site, blog, simple e-commerce · ใช้ JS ดีกว่า

เรียน Rust สำหรับ WASM ใช้เวลานานแค่ไหน

6-12 เดือนสำหรับ developer ที่มี C++ background · 12-18 เดือนสำหรับ JS dev · ทางลัด: ใช้ AssemblyScript (TypeScript-like) เรียน 1-2 สัปดาห์ · ได้ 70% ของ Rust performance

ราคา Migrate JS เป็น WASM ในไทยเท่าไหร่

Single Hot Path ฿100K-300K · Multi-function (3-5 paths) ฿300K-800K · Full Architecture ฿800K-3M · ROI กลับใน 6-12 เดือนถ้า performance เป็น bottleneck

บริการที่เกี่ยวข้อง

บอสวันนี้

บอสเลือก migrate hot path เดียว (canvas rendering) จาก JS เป็น Rust → WASM · ใช้เวลา 6 สัปดาห์ + ฿280K · ทีมเรียน Rust พื้นฐาน 4 สัปดาห์

3 เดือนหลัง: canvas rendering 50K objects · เวลา 8s → 1.2s (6.7x) · user complain หาย · NPS เพิ่มจาก 23 เป็น 68 · ลูกค้า enterprise 2 ราย sign ที่ demo เพราะ performance · revenue +฿2.4M ในไตรมาส

ผมถามบอสว่าสิ่งที่ surprise เขามากที่สุดคืออะไร

เขานิ่งไปนาน แล้วบอกว่า "พี่ ผมคิดว่า WASM คือ technology ของ Adobe/Google · จริงๆ มันใช้ได้ที่บริษัท startup ของผม · แค่ต้องรู้จังหวะที่ใช้ · ใช้กับ hot path 5% ของ code · เปลี่ยน UX experience ทั้งหมด"

สิ่งที่ทำได้ทันที: เปิด Chrome DevTools → Performance tab คืนนี้ · record web app ของคุณ 30 วินาที · ดู function ที่ใช้ CPU >500ms · ถ้าเจอ pure function (รับ input → output ไม่ touch DOM) · นั่นคือ candidate สำหรับ WASM · migration จะให้ speedup 3-10x

ข้อมูลนี้เป็นแนวทางทั่วไป ควรปรึกษาผู้เชี่ยวชาญสำหรับกรณีเฉพาะ

ตรวจทานความถูกต้องโดยทีม Vision X Brain ประสบการณ์กว่า 18 ปี