# Partial Prerendering (PPR) Next.js 15: คู่มือเพิ่มความเร็วเว็บ SME ไทย 2026
ในยุคที่ Google ใช้ Core Web Vitals เป็นหนึ่งในสัญญาณ Ranking และผู้ใช้รอเว็บโหลดได้ไม่เกิน 2 วินาทีก่อนปิดแท็บ ความเร็วของเว็บไม่ใช่ Nice-to-Have แต่เป็น Survival Mode สำหรับ SME ไทย ปัญหาคือ E-commerce หรือเว็บที่ต้องโชว์ราคา/สต็อกสด ๆ ไม่สามารถทำ Static Site ได้ทั้งหมด ส่วน Dynamic Rendering ก็ทำให้ TTFB ช้าเกินไป
Partial Prerendering (PPR) คือคำตอบของ Vercel สำหรับปัญหานี้ — เป็นโมเดล Rendering ใหม่ที่รวมข้อดีของ Static และ Dynamic เข้าด้วยกันใน Response เดียว ส่ง Static Shell ออกไปก่อน แล้วทยอย Stream Dynamic Hole ตามทีหลัง ผลลัพธ์คือผู้ใช้เห็นหน้าเว็บใน 50ms แต่ยังคงข้อมูล Personalized ครบ
บทความนี้จะอธิบาย PPR ตั้งแต่หลักการทำงาน วิธีเปิดใช้บน Next.js 15, ขั้นตอนการ Refactor โค้ดเดิม, ข้อจำกัดที่ต้องรู้ พร้อมเปรียบเทียบกับ Rendering Strategy อื่น ๆ เพื่อช่วยทีม Dev ของ SME ตัดสินใจ Adopt ได้อย่างมั่นใจ
PPR ทำงานอย่างไร และทำไมถึงเร็วกว่า
ก่อนหน้านี้ Next.js มี Rendering Mode 4 แบบ ได้แก่ Static Site Generation (SSG), Server-Side Rendering (SSR), Incremental Static Regeneration (ISR) และ Client-Side Rendering (CSR) แต่ละแบบมีจุดอ่อนของตัวเอง — SSG ขาดความสด, SSR ทำให้ TTFB ช้า, CSR ทำให้ SEO แย่
PPR แก้ปัญหาโดยใช้แนวคิด "Static Shell + Dynamic Holes" ระบบจะ Pre-render ส่วนที่ไม่เปลี่ยน (Header, Footer, Layout, Static Cards) เป็น HTML ไว้ตั้งแต่ Build Time เก็บที่ Edge Cache ของ Vercel หรือ CDN ส่วนที่ Dynamic เช่น ตะกร้าสินค้า, ยอดคงเหลือ, User Greeting จะถูก "เจาะรู" (Hole) ไว้ในตำแหน่งเดิม แล้วใช้ React Suspense Stream ข้อมูลตามทีหลัง
ผลลัพธ์คือ TTFB ลดเหลือ 50ms (เทียบกับ 800-1200ms ของ SSR แบบเดิม) และ FCP มาเร็วขึ้น 4-10 เท่า โดยไม่เสีย Interactivity และ Personalization
เปรียบเทียบ Rendering Strategy ของ Next.js
| Strategy | TTFB | Freshness | SEO | เหมาะกับ |
|----------|------|-----------|-----|----------|
| Static (SSG) | < 50ms | สด ๆ ตอน build | ดีมาก | Blog, Landing |
| ISR | < 100ms | สดตาม revalidate | ดีมาก | Catalog ที่ไม่เปลี่ยนบ่อย |
| SSR | 500-1200ms | สดทุก request | ดี | Dashboard, Profile |
| CSR | 50ms | สดตอน Fetch | แย่ | App ภายใน |
| PPR | < 100ms | สดตาม section | ดีมาก | E-commerce, SaaS Marketing |
จะเห็นว่า PPR เป็นการรวมจุดดีของ Static และ SSR เข้าด้วยกัน เหมาะอย่างยิ่งกับเว็บที่ต้องการทั้ง SEO และ Real-time Data — ซึ่งครอบคลุม Use Case ของ SME ไทยส่วนใหญ่
วิธีเปิดใช้ PPR บน Next.js 15
ในเวอร์ชันปัจจุบัน PPR ยังเป็น Experimental Feature ต้องเปิดใน config ก่อน
Step 1: เปิด Flag ใน next.config.ts
```typescript
import type { NextConfig } from 'next';
const nextConfig: NextConfig = {
experimental: {
ppr: 'incremental',
},
};
export default nextConfig;
```
ตัวเลือก `'incremental'` คือ Recommended ทำให้เปิดใช้ PPR ได้ทีละหน้า ไม่ต้อง Refactor ทั้งโปรเจกต์พร้อมกัน ถ้าใส่ `true` ระบบจะเปิด PPR ทุกหน้าทันที — ไม่แนะนำสำหรับโปรเจกต์ Production
Step 2: เปิด PPR ในระดับ Route
```typescript
// app/products/[id]/page.tsx
export const experimental_ppr = true;
import { Suspense } from 'react';
import StaticHeader from './StaticHeader';
import DynamicCart from './DynamicCart';
export default function ProductPage({ params }) {
return (
<>
<StaticHeader productId={params.id} />
<Suspense fallback={<CartSkeleton />}>
<DynamicCart />
</Suspense>
</>
);
}
```
ทุก Component ที่ต้อง Fetch Dynamic Data ต้องอยู่ภายใต้ `<Suspense>` เพื่อให้ระบบรู้ว่าตรงไหนคือ "Hole" และจะ Stream ข้อมูลทีหลัง
Step 3: ใช้ Dynamic API ภายใน Suspense Boundary
API อย่าง `cookies()`, `headers()`, `searchParams` จะ Trigger Dynamic Rendering ดังนั้นต้องใช้ภายใน Component ที่ Suspense ครอบไว้เท่านั้น มิฉะนั้น Page ทั้งหน้าจะกลับเป็น SSR แบบเดิม
Step 4: ทดสอบ Performance ด้วย Vercel Speed Insights
หลัง Deploy ขึ้น Vercel ใช้ Speed Insights วัด TTFB, FCP, LCP เปรียบเทียบก่อนและหลังเปิด PPR ในทาง Practice TTFB ของ Product Page ลดจาก 850ms เหลือ 92ms
Best Practices สำหรับการ Refactor
ก่อนเปิด PPR ทีม Dev ควรเตรียมโค้ดให้พร้อมตามแนวทางต่อไปนี้
ข้อจำกัดและสิ่งที่ต้องระวัง
แม้ PPR จะทำให้เร็วขึ้นมาก แต่ก็มีข้อควรระวังที่ทีม Dev ต้องเตรียมรับมือ
Use Case จริงสำหรับ SME ไทย
ร้าน E-commerce ขายเครื่องสำอางที่ใช้ Next.js 14 + SSR เดิมมี TTFB เฉลี่ย 1.1 วินาที หลัง Migrate เป็น Next.js 15 + PPR ผลลัพธ์คือ TTFB ลงเหลือ 95ms, LCP ดีขึ้น 60%, Conversion Rate เพิ่มขึ้น 18% ภายในเดือนแรก เพราะลูกค้าไม่ต้องรอนาน
อีกตัวอย่างคือเว็บ SaaS Dashboard ที่ใช้ PPR แยก Static Header/Sidebar ออกจาก Live Metrics ทำให้ผู้ใช้เห็น Layout ทันที ส่วนกราฟ Stream เข้ามาทีหลัง ลด Bounce Rate ได้ 25%
สรุปและขั้นตอนต่อไป
Partial Prerendering คือก้าวสำคัญของ React และ Next.js ในการแก้ปัญหา "เลือก Static หรือ Dynamic" ที่นักพัฒนาเผชิญมานาน 10 ปี สำหรับทีม Dev ของ SME ไทย PPR เป็นทางเลือกที่คุ้มค่ามาก เพราะลดต้นทุน Server โดยไม่เสีย UX
Key Takeaways:
หากต้องการให้ทีม Dev มืออาชีพช่วย Migrate Next.js Project เดิมไปสู่ PPR หรือออกแบบสถาปัตยกรรมใหม่ให้รองรับ PPR ตั้งแต่ต้น ติดต่อทีม ADS FIT ที่ contact@adsfit.co.th หรืออ่านบทความ Web Performance Optimization เพิ่มเติมได้ที่ Blog ของเรา