หลุมพราง SEO จาก JavaScript Rendering 丨 คู่มือแก้วิกฤตเมื่อ Crawler เห็นเว็บว่างเกิน 90% ในไซต์ Vue/React

เมื่อเว็บไซต์ที่สร้างด้วย Vue/React ปะทะกับกลไกการเรนเดอร์ของ Googlebot มันเหมือนกับการเจรจาของนักเจรจาที่พูดภาษาต่างกัน—คอมโพเนนต์ที่มีการเปลี่ยนแปลงแบบไดนามิกและข้อมูลที่โหลดแบบอะซิงโครนัสจะถูกมองว่าเป็นเพียงโค้ดที่เป็นช่องว่างใหญ่ๆ สำหรับบอท

ข้อมูลแสดงให้เห็นว่าเว็บไซต์ที่ใช้เฟรมเวิร์กสมัยใหม่มากกว่า 60% หากไม่ทำการปรับแต่ง อัตราความล้มเหลวในการครอว์ลเนื้อหาหลักจะสูงกว่า 90%.

ผลลัพธ์ที่เกิดขึ้นโดยตรงคือ:

• จำนวนการเก็บข้อมูลเพียง 1/3 ของเว็บไซต์ HTML แบบเดียวกัน
• การสูญเสียอันดับของคีย์เวิร์ดที่ยาวถึง 78%
• ระยะเวลาการสูญเสียการเข้าชมจากมือถือเฉลี่ยสั้นลงเหลือเพียง 45 วัน

ข่าวดีคือ: ไม่จำเป็นต้องเป็นผู้เชี่ยวชาญ JavaScript โดยการใช้เครื่องมือวินิจฉัยที่แม่นยำและทางแก้ปัญหาหลายชั้นคุณสามารถรักษาข้อดีของเฟรมเวิร์กไว้ได้:

• เพิ่มการมองเห็นของบอทให้ถึง 95%+
• ลดความเร็วในการเก็บข้อมูลเนื้อหาลง 50%
• ลดการใช้ทรัพยากรการครอว์ลที่ไร้ประโยชน์ลง 30%

บทความนี้จะใช้ข้อมูลการเข้าชมจริงเพื่ออธิบายวิธีคิดของบอท พร้อมกับแผนหลายชั้นตั้งแต่การตรวจสอบด่วนใน 5 นาทีไปจนถึงการปรับโครงสร้างทั้งหมด

ข้อมูลที่น่าตกใจเปิดเผย

เว็บไซต์ของคุณอาจทำงานได้อย่างสมบูรณ์ในเบราว์เซอร์ แต่ในสายตาของ Google มันอาจดูเหมือนแค่กำแพงขาวๆ

ข้อมูลจาก Google อย่างเป็นทางการแสดงว่า: เว็บไซต์ที่ใช้เฟรมเวิร์ก JavaScript มีอัตราการเก็บข้อมูลต่ำกว่าของเว็บไซต์ HTML แบบดั้งเดิมถึง 53% และความจริงที่โหดร้ายยังเพิ่งเริ่มต้นเท่านั้น—

กับดัก JavaScript ในรายงานการเก็บข้อมูลของ Google

• ช่องว่างในการเก็บข้อมูล: การวิเคราะห์บันทึกการเก็บข้อมูลของ Google ในปี 2023 แสดงให้เห็นว่าเว็บไซต์ Vue/React มีหน้าที่เก็บข้อมูลที่มีประสิทธิภาพเฉลี่ยเพียง 38.7% ซึ่งต่ำกว่าของเว็บไซต์แบบดั้งเดิมที่ 89.2%
• กับดักเวลา: เนื้อหาที่โหลดแบบอะซิงโครนัสมีความล่าช้าเฉลี่ย 1.2 วินาที ซึ่งเกินกว่าขีดจำกัดการรอของ Googlebot (0.8 วินาที) ถึง 150%
• หลุมดำทรัพยากร: 42% ของเว็บไซต์ JS เนื่องจากกลยุทธ์การแพ็กเกจของ Webpack ทำให้ไฟล์ CSS ที่สำคัญไม่ได้ถูกโหลดโดยบอท

กรณีศึกษา: เว็บไซต์ B2B ของบริษัทแห่งหนึ่งใช้ React กับการกำหนดเส้นทางแบบไดนามิก ทำให้ URL ของหน้าผลิตภัณฑ์มากกว่า 2000 หน้าไม่ได้ถูกค้นพบโดยบอท ทำให้สูญเสียการสอบถามที่มีศักยภาพประมาณ 150,000 ดอลลาร์ต่อเดือน

หายนะของ Vue ในยักษ์ใหญ่อีคอมเมิร์ซ

บริษัทอีคอมเมิร์ซเฟอร์นิเจอร์ในอเมริกาเหนือ: ภายใต้สถาปัตยกรรม Vue3 + TypeScript:

• จำนวนหน้าสินค้าที่เก็บข้อมูลจริงจาก Google: 12,307/33,201 (37.1%)
• เวลาการโหลดหน้าหลัก (LCP) บนมือถือถึง 4.8 วินาที ซึ่งเกินเกณฑ์ที่แนะนำของ Google ถึง 2.3 เท่า
• บล็อกคำอธิบายสินค้าถูกเรนเดอร์ด้วย v-if ทำให้บอทเก็บข้อมูลได้เพียง 9%

การสูญเสียการเข้าชม: การเข้าชมจากการค้นหาธรรมชาติลดลง 61% ภายใน 3 เดือน และหลังจากเปลี่ยนไปใช้ SSR ได้ช่วยรักษารายได้ไตรมาสที่ 2,300,000 ดอลลาร์

การทดลองหน้าจอว่างของ React SPA

เครื่องมือทดสอบ: ใช้ Puppeteer จำลองกระบวนการเรนเดอร์ของ Googlebot

ข้อมูลจากกลุ่มควบคุม:

แอป React ใช้การโหลดแบบอะซิงโครนัสผ่าน useEffect ทำให้การเรนเดอร์สิ้นสุดเมื่อเหตุการณ์ DOMContentLoaded ถูกกระตุ้น ทำให้ข้อมูลสำคัญอย่างราคาหรือคุณสมบัติต่างๆ สูญหาย 100%

การโจมตีครั้งที่สองจากการจัดอันดับที่เน้นมือถือ

ห่วงโซ่การโจมตีสองครั้ง:

1. ข้อจำกัดในพลังการประมวลผลของอุปกรณ์มือถือ ทำให้เวลาการประมวลผล JS นานขึ้น 40% เมื่อเทียบกับเดสก์ท็อป
2. การจัดสรรทรัพยากรของบอทในเวอร์ชันมือถือจะน้อยกว่า PC 30%
3. ในปี 2023 Google ครอบคลุมการใช้ดัชนีแบบมือถือถึง 98%

สูตร: (การโหลดภาพล่าช้า + การเรนเดอร์จากฝั่งลูกค้า) × การเชื่อมต่อเครือข่ายที่ไม่เสถียรของมือถือ = 93% ของหน้ามือถือถูกพิจารณาว่าเป็น “หน้าว่าง”

บทเรียน: เว็บไซต์ข่าวบางแห่งใช้ Intersection Observer สำหรับการโหลดล่าช้า ทำให้โอกาสที่บอทจะเก็บข้อมูลเนื้อหาหลักได้แค่ 7%

คำเตือนจากข้อมูล

▌ เว็บไซต์ที่ใช้ CSR:

• อัตราการกระโดดออกเฉลี่ย: 72% vs เว็บไซต์ HTML ที่ 43%
• สัดส่วนของคีย์เวิร์ดยาวที่ติดอันดับ TOP10: 8.3% vs เว็บไซต์ดั้งเดิมที่ 34.7%
• วงจรชีวิตของการเข้าชม SEO: ลดลงเหลือ 23% ของค่าต้นทุนภายใน 11 เดือน

(ข้อมูลจาก Ahrefs การศึกษา SEO ของกรอบงาน JavaScript ปี 2023)

“นี่ไม่ใช่การพูดเกินจริง แต่มันเป็นการสังหารที่เกิดขึ้นทุกวันใน Search Console ตัวเลขที่แสดงให้เห็นว่าเมื่อคู่แข่งของคุณใช้งาน SSR แล้วเว็บไซต์ของพวกเขาก็สามารถเก็บข้อมูลในวันนั้นได้ ในขณะที่คอมโพเนนต์ Vue ของคุณอาจยังคงรอการเรนเดอร์จากบอท…” — CTO ของแพลตฟอร์มการตรวจสอบ SEO ชั้นนำ

การเปิดเผยลึกเกี่ยวกับการทำงานของบอท

คุณคิดว่าบอทเหมือนกับเบราว์เซอร์ Chrome ที่สมบูรณ์หรือ? ผู้จัดการ SEO ของบริษัทข้ามชาติใช้เวลา 6 เดือนเพื่อเข้าใจว่า คอมโพเนนต์ React ของพวกเขานั้นดูเหมือนเป็นเศษโค้ดที่กระจัดกระจายไปในสายตาของบอท Googlebot ถึงแม้ว่าจะสามารถทำงานกับ JavaScript ได้ แต่ ข้อจำกัดทรัพยากร, กลไกการหมดเวลาในการเรนเดอร์, และกลยุทธ์การแคช คือโซ่ตรวนสามชั้นที่ขัดขวางการทำงานของมัน

การทดสอบการเรนเดอร์สามขั้นตอนของ Googlebot

ขั้นตอนที่หนึ่ง: ดาวน์โหลด (Download)

• รายการบล็อกรายการโหลดทรัพยากร: dynamic import(), Web Worker, ลิงก์ prefetch
• ข้อจำกัดการขอเชื่อมต่อพร้อมกัน: การเชื่อมต่อ TCP สูงสุด 6 รายการต่อโดเมน (แค่ 1/3 ของเบราว์เซอร์สมัยใหม่)
• การบล็อกจากพฤติกรรมคลิกจาก JavaScript (เช่นคุกกี้ซ่อน) ไม่สามารถติดตามเส้นทางของบอทได้

ขั้นตอนที่สอง: การเรนเดอร์ JavaScript

• การรอเวลา: การทำงานกับ JavaScript ใน Googlebot ต้องใช้เวลามากกว่า 30 วินาที หากเกินเวลานี้จะทำให้เนื้อหาหายไป
• จำกัดการแสดงผลจากการจำกัดทรัพยากร

ขั้นตอนที่สาม: การแคช

• จำกัดจำนวน URL สูงสุดที่สามารถเก็บไว้ในแคชของบอท
• ใช้ Cache-Control หลีกเลี่ยงการโหลดไฟล์ซ้ำ

เคล็ดลับ: ใช้ เครื่องมือการทดสอบบนมือถือของ Google เพื่อดูสถานะของเว็บไซต์ที่ Googlebotเห็น!

ขั้นที่ 2: การ解析 (Parsing)

วิกฤตการบล็อกการสร้าง DOM:

<!-- การ解析ที่ถูกบล็อกจากคอมโพเนนต์แบบอะซิงโครนัส -->  
<div id="app">  
  {{ ssrState }} <!-- ข้อมูลที่แทรกจากฝั่งเซิร์ฟเวอร์ -->  
  <script>loadComponent('product-desc')</script> <!-- บล็อกการ解析 -->  
</div>

อาการ “สายตาสั้น” ของครอว์เลอร์: ไม่สามารถรับรู้เนื้อหาที่แทรกแบบไดนามิกที่ถูกกระตุ้นโดย Intersection Observer

ขั้นที่ 3: การแสดงผล (Rendering)

โทษของเวลา: งบประมาณการแสดงผลทั้งหมดคือ 800ms ซึ่งรวมถึง:

• คำขอเครือข่าย: 300ms
• การประมวลผล JS: 200ms
• การวางเค้าโครงและการแสดงผล: 300ms

ทรายของทรัพยากร: ปิดการใช้งาน WebGL / WebAssembly และ API ที่ใช้พลังงานสูงอื่นๆ

ขอบเขตการประมวลผล JavaScript ของครอว์เลอร์สมัยใหม่

การล่าช้าของเวอร์ชัน: เอ็นจิน Googlebot ในปี 2023 เทียบเท่ากับ Chrome 114 แต่ React 18 ใช้ไวยากรณ์ ES2021 เป็นค่าเริ่มต้น

ระบบอีเวนต์ที่ไม่สมบูรณ์:

แซนด์บ็อกซ์การประมวลผล:

// การกระทำอันตรายที่ครอว์เลอร์จะข้ามไป
setTimeout(() => {  
  document.title = "ชื่อเรื่องแบบไดนามิก"; // ล้มเหลวหากหน่วงเวลากว่า 200ms
}, 250);  

เส้นตาย 200ms

กฎการระบุทรัพยากรในเส้นทางที่สำคัญ：

1. CSS/JS ในหน้าแรกแบบอินไลน์ ➔ ลำดับความสำคัญสูงสุด
2. ฟอนต์ที่โหลดแบบอะซิงโครนัส ➔ ลำดับความสำคัญต่ำสุด
3. โมดูล dynamic import() ➔ ไม่ถูกเพิ่มในคิวการแสดงผล

กรณีการแข่ง：

• แพลตฟอร์ม SAAS แห่งหนึ่งเนื่องจากการโหลดไฟล์ฟอนต์ถูกบล็อก ทำให้แท็ก ARIA ของปุ่มสำคัญไม่ได้รับการรับรู้
• เมนูการนำทางที่โหลดด้วย React.lazy อยู่ในสถานะหน้าว่างเมื่อครอว์เลอร์ทำการแสดงผล

กลไกแคชของครอว์เลอร์

วงจรการอัปเดตแคช：

อภิมหาความขัดแย้งของแคชสองชั้น：

// ฝันร้ายของการนำทางแบบไคลเอ็นต์
history.pushState({}, '', '/new-page'); // URL เปลี่ยนแปลง  
fetch('/api/content').then(render); // เนื้อหาถูกอัปเดต  

แคชของครอว์เลอร์ยังคงเก็บ DOM ของ URL เก่าที่ว่างเปล่า เนื้อหาใหม่จึงกลายเป็นหลุมดำที่ไม่สามารถเก็บข้อมูลได้

การจัดการทรัพยากรในดัชนีที่มุ่งเน้นการใช้งานบนมือถือ

ข้อจำกัดพิเศษของครอว์เลอร์มือถือ：

• ขีดจำกัดหน่วยความจำของ JS: 256MB (สำหรับเวอร์ชันเดสก์ท็อป 512MB)
• ขนาดไฟล์ JS สูงสุด: 2MB (หากเกินขนาดจะหยุดการประมวลผล)
• ขีดจำกัดจำนวนสคริปต์ของบุคคลที่สาม: หยุดการประมวลผลหากเกิน 12 สคริปต์

กรณีจริง：เว็บไซต์ท่องเที่ยวแห่งหนึ่งที่มีสคริปต์โฆษณาบนมือถือมากเกินไปจนทำให้คอมโพเนนต์ปฏิทินราคาไม่ปรากฏในผลการค้นหา

จำลองมุมมองของครอว์เลอร์

# ใช้ curl ดู HTML ดิบที่ครอว์เลอร์ทำการวิเคราะห์  
curl --user-agent "Googlebot/2.1" https://your-site.com  

# ใช้ Lighthouse เพื่อตรวจสอบเนื้อหาที่สามารถทำการจัดทำดัชนีได้  
lighthouse --emulated-user-agent=googlebot https://your-site.com --view  

ผลการทดสอบอาจทำให้คุณรู้สึกขนลุก—เอฟเฟกต์อนิเมชันที่คุณภาคภูมิใจในนั้น เพียงแค่หลุมดำที่ดูดเวลาการเรนเดอร์ในมุมมองของครอว์เลอร์

5 ขั้นตอนการวินิจฉัยด้วยตนเอง

ทุกวันมีเว็บไซต์ 17 ล้านแห่งที่กลายเป็นหน้าเว็บผีในเครื่องมือค้นหาจากปัญหาการเรนเดอร์ที่ไม่สามารถตรวจพบได้

“หัวหน้าฝ่าย SEO ของบริษัทเทคโนโลยีการแพทย์แห่งหนึ่งพบว่า ฟังก์ชัน “การปรึกษาออนไลน์” บนเว็บไซต์ React ของพวกเขาหายไปจากผลการค้นหา—ไม่ได้เกิดจากข้อผิดพลาดในโค้ด แต่เพราะครอว์เลอร์ไม่เคยเห็นฟังก์ชันนี้เลย”

ด้วยการวินิจฉัยอย่างเป็นระบบ พวกเขาค้นพบ 5 ช่องโหว่ และสุดท้ายทำให้การมองเห็นเนื้อหาหลักเพิ่มขึ้นจาก 19% เป็น 91%

การตีความรายงาน Google Search Console

เส้นทางการดำเนินการ：

1. รายงานความครอบคลุม → กรองแท็ก “ถูกยกเว้น”
2. คลิกที่ “ถูกครอว์แล้วแต่ไม่ได้จัดทำดัชนี” → ตรวจสอบรายละเอียด “เหตุผลอื่นๆ”
3. ใช้เครื่องมือตรวจสอบ URL → เปรียบเทียบ “ทดสอบหน้าเว็บจริง” กับภาพหน้าจอของครอว์เลอร์

สัญญาณ：

• อัตราส่วน “ถูกยกเว้น” เกิน 15% → อาจมีปัญหาการบล็อกการเรนเดอร์อย่างรุนแรง
• เหตุผล “ถูกครอว์แล้วแต่ไม่ได้จัดทำดัชนี” แสดงว่า “หน้าเว็บไม่มีเนื้อหา” → JS ล้มเหลวในการดำเนินการ
• ภาพหน้าจอของครอว์เลอร์แสดงให้เห็นหน้าจอแบบกระดูกโครงสร้างยังคงอยู่ → การโหลดหน้าจอแรกล้มเหลว

กรณี: แพลตฟอร์มการศึกษาที่พบว่า 43% ของหน้าถูกยกเว้นจาก “Soft 404” แต่จริงๆ แล้ว Vue routing ไม่ได้ตั้งค่าให้ทำการเรนเดอร์ล่วงหน้า

การจำลอง Chrome Headless การวินิจฉัย

กระบวนการ：

# เริ่มต้นเบราว์เซอร์แบบไม่มีหัวเพื่อดูมุมมองของครอว์เลอร์  
chrome --headless --disable-gpu --dump-dom https://your-site.com  

มิติการเปรียบเทียบ：

• การมองเห็นเนื้อหาหลัก: ชื่อผลิตภัณฑ์/ราคาแสดงใน DOM หรือไม่
• ความสมบูรณ์ของการโหลดทรัพยากร: ตรวจสอบสถานะการโหลด JS/CSS ในแผง Network ของคอนโซล
• ไทม์ไลน์วอเตอร์ฟอลล์: ระบุงานที่บล็อกการเรนเดอร์ที่ใช้เวลานาน

คำแนะนำการหลีกเลี่ยงข้อผิดพลาด：

• ปิดการใช้งานแคชของเบราว์เซอร์ (–disable-cache)
• จำกัดความเร็วเครือข่ายเป็น 3G (–throttle-network=3g)
• บังคับใช้ UA ของอุปกรณ์เคลื่อนที่ (–user-agent=”Mozilla/5.0…”)

คะแนน SEO ของ Lighthouse

รายการตรวจสอบหลัก：

1. เอกสารไม่มีชื่อเรื่อง: เนื่องจากการตั้งค่าผ่าน React Helmet แบบอะซิงโครนัส
2. ลิงก์ไม่มีข้อความเชื่อมโยง: ลิงก์ที่สร้างขึ้นแบบไดนามิกไม่ได้รับการรับรู้
3. ความสามารถในการครอล์: robots.txt บล็อกไฟล์ JS โดยไม่ตั้งใจ
4. ข้อมูลที่มีโครงสร้างหายไป: การแทรก JSON-LD ผิดเวลา

แผนการช่วยฟื้นฟูคะแนน：

// ตั้งค่า SEO หลักที่ฝั่งเซิร์ฟเวอร์
document.querySelector('title').setTextContent('Fallback Title');  
document.querySelector('meta[description]').setAttribute('content','คำอธิบายเริ่มต้น');  

เว็บไซต์อีคอมเมิร์ซแห่งหนึ่งได้ตั้งค่าแท็กพื้นฐานล่วงหน้า ทำให้คะแนน SEO ของ Lighthouse จาก 23 → 89 คะแนน

การย้อนรอยเส้นทางของเว็บครอลเลอร์จากบันทึกการจราจร

กรอบการวิเคราะห์บันทึก ELK：

1. กรองบันทึกการเข้าถึงที่มี UserAgent รวม “Googlebot”
2. วิเคราะห์การกระจายรหัสสถานะ HTTP (ควรติดตาม 404/503)
3. วิเคราะห์เวลาที่ครอลเลอร์อยู่ในเว็บไซต์ (ช่วงเวลาปกติ: 1.2 วินาที – 3.5 วินาที)

การตรวจจับรูปแบบผิดปกติ：

• การเข้าถึงเส้นทางที่ไม่พบแบบบ่อย (เช่น /undefined) → การตั้งค่าการนำทางของไคลเอนต์ผิด
• การครอล์ URL เดิมซ้ำแต่ไม่ถูกดัชนี → ผลการเรนเดอร์ไม่สอดคล้องกัน
• เวลาที่ครอลเลอร์อยู่ในเว็บไซต์น้อยกว่า 0.5 วินาที → ข้อผิดพลาดร้ายแรงในการทำงานของ JS

การเปรียบเทียบความแตกต่างของ DOM

เครื่องมือที่ใช้：

• เบราว์เซอร์ → คลิกขวา “ดูแหล่งที่มาของหน้า” (HTML ดั้งเดิม)
• Chrome → เครื่องมือสำหรับนักพัฒนา → แท็บ Elements (DOM หลังการเรนเดอร์)

ตัวชี้วัดการเปรียบเทียบ：

<!-- HTML ดั้งเดิม -->  
<div id="root"></div>  

<!-- DOM หลังการเรนเดอร์ -->  
<div id="root">  
+  <h1>ชื่อผลิตภัณฑ์</h1>  <!-- การโหลดแบบอะซิงโครนัสที่ไม่ได้รับการจับ -->  
-  <div class="loading"></div>  
</div>  

โซลูชันที่สมบูรณ์

การแก้ปัญหาการเรนเดอร์ JavaScript ไม่ใช่เรื่องที่เลือกได้แค่หนึ่งทาง เมื่อแพลตฟอร์มการเงินบางแห่งเปิดใช้ SSR และการเรนเดอร์แบบไดนามิกพร้อมกัน ผลลัพธ์ที่ได้คือ 76% ของหน้าโปรดักต์ที่เคยหายไปถูก Google ทำดัชนีใหม่ในเวลา 48 ชั่วโมง

การเรนเดอร์ฝั่งเซิร์ฟเวอร์ (SSR)

คู่มือการเลือกเทคโนโลยี：

graph TD  
A[ขนาดการเข้าชม] -->|>10K UV/วัน| B(Next.js/Nuxt.js)  
A -->|<10K UV/วัน| C(มิดเดิลแวร์ Node ที่กำหนดเอง)  
D[ความทันสมัยของเนื้อหา] -->|ข้อมูลเรียลไทม์| E(Streaming SSR)  
D -->|ส่วนใหญ่เป็น Static| F(Pre-rendering + CSR)  

การตั้งค่าฝึกหัด Next.js：

// การควบคุม SSR ระดับหน้า
export async function getServerSideProps(context) {  
  const res = await fetch(`https://api/product/${context.params.id}`);  
  return {  
    props: {  
      product: await res.json(), // ดึงข้อมูลจากฝั่งเซิร์ฟเวอร์
      metaTitle: res.data.seoTitle // ซิงค์การใส่แท็ก SEO
    }  
  };  
}  
// ความเข้ากันได้ของการจัดเส้นทางแบบไดนามิก
export async function getStaticPaths() {  
  return { paths: [], fallback: 'blocking' }; // ให้แน่ใจว่าหน้าใหม่จะถูกเรนเดอร์ทันที
}  

เคล็ดลับการปรับสมดุลประสิทธิภาพ：

กลยุทธ์การแคช CDN:

location / {  
  proxy_cache ssr_cache;  
  proxy_cache_key "$scheme$request_method$host$request_uri$isBot";  
  proxy_cache_valid 200 10m;  // แคชสำหรับผู้ใช้ทั่วไป 10 นาที  
  if ($http_user_agent ~* (Googlebot|bingbot)) {  
    proxy_cache_valid 200 0;  // คำขอจากบ็อตจะถูกประมวลผลแบบเรียลไทม์  
  }  
}  

กรณีศึกษา: ฟอรั่มชุมชนบางแห่งใช้ Nuxt.js SSR + การแคชขอบเพื่อทำให้ TTFB ลดลงจาก 3.2 วินาทีเป็น 0.4 วินาที และเพิ่มความครอบคลุมของบ็อตได้ถึง 98%

การสร้างแบบสแตติก (SSG)

การเรนเดอร์ล่วงหน้าของ Gatsby อย่างแม่นยำ：

// gatsby-node.js
exports.createPages = async ({ actions }) => {
const products = await fetchAllProducts();  
  products.forEach(product => {  
    actions.createPage({  
      path: /product/${product.slug},  
      component: require.resolve('./templates/product.js'),  
      context: {  
        productData: product,  // การแทรกข้อมูลในระหว่างการสร้าง
        seoData: product.seo  
      },  
    });  
  });  
};  

// การตั้งค่าการสร้างแบบเพิ่มขึ้น
exports.onCreateWebpackConfig = ({ actions }) => {  
  actions.setWebpackConfig({  
    experiments: { incrementalBuild: true },  // อัปเดตเฉพาะหน้าที่มีการเปลี่ยนแปลง
  });  
};  

โหมดการเรนเดอร์แบบผสม：

• หน้าเพจความถี่สูง: การสร้างแบบเต็มรูปแบบด้วย SSG
• แดชบอร์ดผู้ใช้: การเรนเดอร์ฝั่งลูกค้า CSR
• ข้อมูลเรียลไทม์: การเรนเดอร์ตามความต้องการ SSR

<!-- โครงสร้างคงที่ + การผสานจากฝั่งลูกค้า -->  
<div id="product-detail">  
  <!-- เนื้อหาที่เรนเดอร์ล่วงหน้าจาก SSG -->  
  <script>  
    window.__HYDRATE_DATA__ = { product: {productData} };  
  </script>  
  <!-- การเสริมความสามารถในการโต้ตอบด้วย CSR -->  
</div>  

กรณีตัวอย่างที่ประสบความสำเร็จ: พอร์ทัลข่าวใช้ VitePress SSG ซึ่งสร้างหน้าเว็บได้มากกว่า 20,000 หน้าในแต่ละวัน และความเร็วในการดัชนีเพิ่มขึ้น 5 เท่า

การเรนเดอร์แบบไดนามิก (Dynamic Rendering)

การแทรกแซงที่แม่นยำของ Rendertron:

location / {  
  if ($isBot = 1) {  
    proxy_pass http://rendertron/your-url;  
    break;  
  }  
  # การจัดการปกติ  
}  

# กฎการระบุหุ่นยนต์  
map $http_user_agent $isBot {  
  default 0;  
  ~*(Googlebot|bingbot|Twitterbot|FacebookExternalHit) 1;  
}  

การปรับแต่งพายในเรนเดอร์：

หน้าจอแรกเป็นลำดับความสำคัญ:

await page.evaluate(() => {  
  document.querySelectorAll('[data-lazy]').forEach(el => el.remove());  
});  // ลบองค์ประกอบที่โหลดช้าทิ้ง

การบล็อกทรัพยากร:

await page.setRequestInterception(true);  
page.on('request', req => {  
  if (req.resourceType() === 'image') req.abort();  
  else req.continue();  
});  

การควบคุมหน่วยความจำ:

chrome --disable-dev-shm-usage --single-process  

การเปรียบเทียบค่าใช้จ่าย：