BrowserStack QA Meetup Group- Bangkok-AUG2026

Modern Web Performance and Architecture

Speaker Nitish Mittal

📌 สำหรับหัวข้อนี้จะ Focus ในส่วนของ Front End ผ่านมา 10 ปีเราจะพบว่ามันต้องมีเทคนิคที่ทำให้ User Experience ไม่สะดุด เพราะมี Device หลายประเภทมากขึ้น อย่างพวก Mobile Device ( Smart Phone / Tablet) มันเลยย้อนกลับมาว่า Dev จากเดิมที่ต้องดูการใช้ CPU / RAM จากพวก PC / Notebook ให้ทำงานได้ไหลลื่นต้องกลับมาดูด้วย

📌 นับวัน Traffic ที่มาจาก Mobile Device สูงขึ้นเรื่อยๆ ยิ่งถ้ามีปัญหาด้าน Performance มันผลเสียได้ ดังนี้

• ผลกระทบทางธุรกิจ: กรณีของ Rakuten ที่พบว่าทุกวินาทีเว็บช้าหรือหน่วง ส่งผลกับการสั่งซื้อสินค้า
• ความรู้สึกของผู้ใช้งาน: นอกจากตรวจสอบว่ามันเร็วบนเครื่องของ Dev แล้ว ยังต้องตรวจสอบกับ Device อื่นๆด้วย ว่ามันเร็วตอบกับความต้องการของผูใช้ไหม เช่น ภายใน 1-2 เว็บตัวต้องแสดงขึ้นมาแล้ว ไม่ใช่ต้องรอ

📌 ยิ่งถ้าเว็บเราใหญ่ขึ้น ทั้ง Image / Font / Script (JS) แม้ว่าเราจะมีการ Optimize Image / Font แต่ปัญหาหลักที่ทำให้เว็บช้าคือ ปริมาณ JavaScript ที่ส่งไปยังเบราว์เซอร์ เพราะ JavaScript จะไปบล็อกการทำงานของ Main Thread ในการประมวลผล ทำให้เกิดการรอกันได้

📌 ดังนั้นก่อนเข้าใจว่าจะแก้ปัญหาอย่างไร สิ่งที่ต้องรุ้ก่อนตัว Browser มันมี Rendering Pipeline

1. Parsing: เบราว์เซอร์จะสร้าง Abstract Syntax Tree จาก HTML และ JavaScript.
2. Styles: การประมวลผลสไตล์และ CSS ทั้งหมด.
3. Layout: การคำนวณตำแหน่งและพื้นที่ (Geometry) ของแต่ละบล็อกบนหน้าจอ.
4. Painting: การวางเซลล์ต่างๆ ลงบนหน้าจอ.
5. Composition: การรวมเลเยอร์ต่างๆ เข้าด้วยกัน (เช่น การจัดการ Z-index)

ขั้นตอนที่ 1-3 ทำงานบน CPU (Main Thread) ซึ่งเป็น Single Thread หากมีงานค้างอยู่จะไม่สามารถทำอย่างอื่นได้ ส่วนขั้นตอนที่ 4-5 สามารถส่งต่อไปยัง GPU ได้.

📌 ถ้าจะรู้ว่าอะไรช้า หรือ เร็ว ทาง Google มีออก Metric ตัวชี้วัด(Core Web Vitals) เอาเฉพาะใน Talk มีตามนี้

• LCP (Largest Contentful Paint): เวลาที่ใช้ในการแสดงผล Block ที่ใหญ่ที่สุดในหน้าเว็บ ควรน้อยกว่า 2.5 วินาที.
• TTFB (Time to First Byte): ระยะเวลาตั้งแต่ส่งคำขอจนถึงได้รับข้อมูลไบต์แรกจากเซิร์ฟเวอร์ ซึ่งส่งผลโดยตรงต่อ LCP.
• INP (Interaction to Next Paint): ตัวชี้วัดใหม่ที่มาแทน FID เพื่อวัดระยะเวลาตั้งแต่ผู้ใช้โต้ตอบ (คลิก) จนถึงการแสดงผลเฟรมถัดไป.

Web Browser ทั่วไปทำงานที่ 60Hz (16.66ms ต่อเฟรม) หาก Main Thread ถูก Block นานกว่า 50ms (เทียบเท่าการข้ามไป 3 เฟรม) ผู้ใช้จะเริ่มรู้สึกถึงความหน่วง (Janky เค้าน่าจะเขียนแบบนี้นะ)

📌 แล้วปัจจุบันการ Browser Rendering มันมี Rendering Architectures ท่าไหนมาช่วยได้บ้าง มี 4 แบบ ดังนี้

• Client-Side Rendering (CSR):
  - ทุกอย่างประมวลผลที่ Client
  - ทำให้ LCP ไม่ดีเพราะต้องโหลดและประมวลผล JavaScript ปริมาณมากก่อนแสดงผล
  - Sample Lib / Framework: React / Vue.js / Angular
• Hydrated SSR:
  - Service ปั๊น HTML มาให้ทันทีทำให้ LCP ดีขึ้น แต่ต้องรอขั้นตอน Hydration (การเชื่อมต่อ Event Handlers กับ HTML)
  - หาก JavaScript เยอะจะทำให้ INP แย่ลงเพราะ Main Thread ถูกบล็อกในช่วงเวลานั้น
  - Sample Lib / Framework: Next.js / Nuxt / Angular (มี Config) / Gatsby
• Island Architecture:
  - Server ส่งไฟล์ Static มาเป็นหลัก และจะส่ง JavaScript เฉพาะส่วนที่เป็น Dynamic (เรียกว่า Islands)
  - ช่วยลดภาระการประมวลผลจากทั้งหน้า มาเฉพาะจุดที่สนใจเท่านั้น
  - Sample Lib / Framework : Astro
• React Server Components (RSC) & Streaming:
  - การสร้าง HTML ทั้งส่วน Static และ Dynamic บนเซิร์ฟเวอร์แล้วค่อยๆ ส่ง (Stream) มายังผู้ใช้
  - ช่วยให้แสดงผลส่วนที่พร้อมได้ทันทีโดยไม่ต้องรอส่วนที่ต้องรอข้อมูลจาก DB นานๆได้
  - Sample Lib / Framework : React 19+ / Next.js / Nuxt (Nuxt Server Components / Component Islands)

📌 ถ้าต้องการสร้างเว็บใหม่ควรใช้ Rendering Architectures แบบไหนต้องดูจากตัวอย่างเว็บตามนี้

• E-commerce: แนะนำ Island Architecture เพราะเนื้อหาส่วนใหญ่เป็น Static มีเพียงบางส่วนอย่างตะกร้าสินค้าที่เป็น Dynamic.
• Dynamic Web App: แนะนำ Next.js หรือ Remix (Server Components) เพื่อให้ได้คะแนน Google Page Speed ที่ดี
• SAS Tool หรือ Canvas App: แนะนำ CSR เพราะมีการประมวลผลหนักๆ อยู่ที่ฝั่งผู้ใช้อยู่แล้ว

MCP in Practice: From First Server to Secure Agents

Speaker Akhilesh S.

📌 Model Context Protocol (MCP)

• เหมือนเป็น USB-C สำหรับ AI ที่ช่วยให้ Large Language Models (LLMs) สามารถเข้าถึงข้อมูลส่วนตัว (Context) หรือทรัพยากรได้ Tools / Prompt / Resource
• เริ่มต้นโดย Anthropic ในปี 2024 และได้รับความร่วมมือจากบริษัทไอทีชั้นนำอย่าง Google และ OpenAI จนกลายเป็นมาตรฐานเปิดที่บริจาคให้กับ Linux Foundation
• ปี 2025 เพิ่ม Security เข้าไป มีตัว OAuth 2.1 / RFC9728 / RFC9207
• ปี 2026 หลายองค์กรทำ MCP Server ให้ใช้กับ Product / Service ตัวเอง

📌การสร้าง MCP Server พื้นฐาน

• Local Setup - ใช้ภายในเครื่องตัวเอง stdio ไม่จำเป็นใช้ Security
• Remote - http มี OAuth 2.1 มาจัดการพวก Auth Per Reuqest ก่อนถึง Resource อย่าง Tools / Prompt / Resource

📌Stack ที่ใช้ Demo รอบนี้

• Spring Boot - เปิด Sample REST EndPoint
• Spring AI
  - ใช้ Annotate (@Tool) บน Method ของ Service เพื่อระบุว่าเป็นเครื่องมือที่ LLM เรียกใช้ได้
  - Description: การเขียนคำอธิบาย (Description) ให้กับ Tool มีผลอย่างมาก เพราะ LLM จะใช้ส่วนนี้ในการตัดสินใจว่าคำถามของผู้ใช้ควรเรียกใช้ Tool ตัวไหน
  - MCP Security OAuth 2.1 + PKCE
• MCP Inspector เอาไว้ทดสอบ
• Claude Desktop สำหรับ Config

📌ปัญหาด้านความปลอดภัย

ก่อนที่จะมีการกำหนดมาตรฐาน Security เคยเกิดเหตุการณ์ข้อมูลรั่วไหลจากการใช้ MCP

• กรณี Asana: เกิดการรั่วไหลของข้อมูลข้ามองค์กร (Cross-tenant leak) นานถึง 2 สัปดาห์ เนื่องจากระบบ Logic ของ MCP Layer ไม่มีการตรวจสอบสิทธิ์ที่รัดกุม
• กรณี GitHub: Agent มี Token ที่เข้าถึงได้ทั้ง Public และ Private Repositories จนทำให้ข้อมูลในส่วน Private รั่วไหลออกมา
• กรณี Supabase: ผู้โจมตีเข้าถึงข้อมูล SQL ทั้งหมดได้ผ่านการโจมตีประเภท Stored Prompt Injection เนื่องจากสิทธิ์เข้าถึงฐานข้อมูลระดับสูงสุด (service_role) และการขาดการตรวจสอบข้อมูลจากภายนอก Blind trust in user-submitted content

เนื่องจาก LLM เป็น Non-deterministic และจะพยายามทำทุกอย่างเพื่อตอบสนองผู้ใช้ หากไม่มีการควบคุมสิทธิ์ (Permission) ที่ดีพอ Agent อาจทำสิ่งที่นอกเหนือจากความตั้งใจได้.

📌MCP Server (Remote) + OAuth 2.1

• Dynamic Registration: ต่างจาก OAuth แบบเดิมที่ต้องลงทะเบียน Client ไว้ล่วงหน้า แต่ AI Agent มีความยืดหยุ่นสูง (Dynamic)จึงต้องรองรับการลงทะเบียน Client แบบอัตโนมัติภายใต้ระบบ Trust Chain
• Trust Chain: ประกอบด้วย Client (Agent), Authorization Server (เช่น Google/Facebook IDP), และ Resource Server (แหล่งข้อมูล MCP) โดยแต่ละส่วนต้องเชื่อถือซึ่งกันและกัน
• การจัดการสิทธิ์ (Scopes): แทนที่จะให้สิทธิ์การเข้าถึงทั้งหมด ควรใช้ Scope-based Tokens เช่น กำหนดให้ Agent อ่านได้อย่างเดียว (Read-only) หรือเข้าถึงได้เฉพาะบาง Domain ข้อมูลเท่านั้น เพื่อจำกัดความเสียหายหากเกิดการรั่วไหล

Ref: https://modelcontextprotocol.io/specification/draft/basic/authorization

📌แนวทาง MCP Server On Production

• Tenant Isolation: ตรวจสอบให้แน่ใจว่าข้อมูลที่ Agent ดึงมาแสดงนั้นเป็นของ Tenant หรือผู้ใช้งานคนนั้นจริงๆ เพื่อป้องกันปัญหา Cross-tenant leaks.
• Input Sanitization: ตรวจสอบและกรอง Input ที่ได้รับจาก LLM ก่อนส่งไปประมวลผลต่อเสมอ
• Identity Verification: ทุกครั้งก่อนดึงข้อมูลจาก Database ต้องมีการตรวจสอบ Identity ของผู้ใช้ที่กำลังใช้งาน Agent นั้นอยู่เสมอ (Logged-in user validation)
• Audit Logging: ระบบควรมีการจัดเก็บ Log การเรียกใช้งาน Tool ทั้งหมด เพื่อให้สามารถตรวจสอบย้อนกลับได้ทันทีหากพบความผิดปกติหรือข้อมูลรั่วไหล

สำหรับ dotnet ใครที่สนใจ ผมมีเขียน Blog ไว้คร้าบ

มาลองปรับ Code .NET(REST API) เดิมเป็น MCP Server

Reference

• BrowserStack QA Meetup- Bangkok (Aug 8)