เคยไหม เว็บไซต์เปิดขึ้นมาแล้วเห็นหน้าขาว ต้องรออีกพักหนึ่งกว่าเนื้อหาจะปรากฏ? ปัญหานี้อาจเกี่ยวข้องกับวิธีที่เว็บสร้างหน้า ระหว่าง SSR ซึ่งสร้าง HTML จากเซิร์ฟเวอร์ กับ CSR ซึ่งให้เบราว์เซอร์ประมวลผล JavaScript แล้วสร้างเนื้อหาเอง โดยทั่วไป SSR ช่วยให้เสิร์ชเอนจินพบเนื้อหาหลักได้ง่ายและรวดเร็วกว่า แต่ไม่ได้หมายความว่าใช้ SSR แล้วอันดับ SEO จะดีขึ้นทันที เพราะความเร็ว เซิร์ฟเวอร์ โครงสร้างเว็บไซต์ และคุณภาพเนื้อหายังคงมีผลร่วมกัน
SSR กับ CSR ต่างกันอย่างไร?
คำว่า Rendering หมายถึงกระบวนการนำข้อมูล โค้ด และส่วนประกอบต่าง ๆ มาสร้างเป็นหน้าเว็บที่ผู้ใช้มองเห็น ความแตกต่างสำคัญระหว่าง SSR กับ CSR คือ งานสร้าง HTML เกิดขึ้นที่ไหนและเกิดขึ้นเมื่อใด
SSR คืออะไร?
SSR ย่อมาจาก Server-Side Rendering หมายถึงการสร้าง HTML บนเซิร์ฟเวอร์ก่อนส่งไปยังเบราว์เซอร์ เมื่อคุณเปิดหน้าเว็บ เซิร์ฟเวอร์จะดึงข้อมูล ประกอบหน้า แล้วส่ง HTML ที่มีเนื้อหาหลักมาให้ทันที
ลองนึกภาพว่าคุณสั่งอาหารแล้วร้านจัดจานเสร็จเรียบร้อยก่อนนำมาเสิร์ฟ คุณจึงเห็นอาหารทันทีที่จานมาถึง นี่คือแนวคิดของ SSR
- เบราว์เซอร์ได้รับ HTML ที่มีหัวข้อ เนื้อหา และลิงก์ตั้งแต่การตอบสนองครั้งแรก
- เหมาะกับหน้าที่ต้องการให้ Google ค้นพบและจัดทำดัชนี
- รองรับข้อมูลที่เปลี่ยนตามคำขอ เช่น ราคา สต็อก หรือข้อมูลตามพื้นที่
- ต้องดูแลประสิทธิภาพเซิร์ฟเวอร์และระบบแคชให้ดี
ตัวอย่างเว็บไซต์ที่มักเหมาะกับ SSR ได้แก่ หน้าบริการ หน้าสินค้า เว็บไซต์ข่าว เว็บอสังหาริมทรัพย์ และหน้ารายละเอียดที่ข้อมูลเปลี่ยนบ่อย โดยเอกสารของ Next.js อธิบายว่า SSR จะสร้าง HTML ใหม่เมื่อมีคำขอเข้ามายังหน้าเว็บแต่ละครั้ง
CSR คืออะไร?
CSR ย่อมาจาก Client-Side Rendering หมายถึงเซิร์ฟเวอร์ส่ง HTML โครงเปล่าและไฟล์ JavaScript ไปให้เบราว์เซอร์ จากนั้น JavaScript จึงเรียกข้อมูลและประกอบหน้าเว็บบนอุปกรณ์ของผู้ใช้
เปรียบเทียบได้กับร้านที่นำวัตถุดิบมาให้คุณ แล้วให้คุณประกอบอาหารบนโต๊ะเอง ช่วงแรกจานอาจยังว่าง แต่หลังจากประมวลผลเสร็จ คุณจึงเห็นเนื้อหาครบและโต้ตอบกับระบบได้อย่างลื่นไหล
- เหมาะกับเว็บแอปที่มีการโต้ตอบสูง
- เปลี่ยนข้อมูลบางส่วนได้โดยไม่ต้องโหลดหน้าใหม่ทั้งหมด
- ลดภาระการสร้างหน้า HTML บางส่วนจากเซิร์ฟเวอร์
- อาจแสดงหน้าว่างหรือ Loading ระหว่างดาวน์โหลดและประมวลผล JavaScript
CSR เหมาะกับหน้าแดชบอร์ด ระบบหลังบ้าน เครื่องมือคำนวณ โปรแกรมจัดการโครงการ หรือหน้าบัญชีผู้ใช้ซึ่งไม่จำเป็นต้องติดอันดับบน Google เอกสาร Next.js แนะนำการดึงข้อมูลฝั่ง Client สำหรับหน้าที่ไม่ต้องพึ่งการจัดทำดัชนี SEO หรือไม่ต้องสร้างข้อมูลล่วงหน้า
SSR กับ CSR ส่งผลต่อ SEO แค่ไหน?
Rendering ไม่ใช่ปัจจัยจัดอันดับโดยตรง Google ไม่ได้ให้คะแนนเว็บไซต์เพียงเพราะเขียนด้วย SSR แต่รูปแบบการ Rendering ส่งผลต่อหลายเรื่องที่เกี่ยวข้องกับ SEO เช่น การค้นพบเนื้อหา การจัดทำดัชนี ความเร็ว และประสบการณ์ผู้ใช้
1. การรวบรวมข้อมูลและจัดทำดัชนี
หน้า SSR ส่งเนื้อหาหลักมาใน HTML ตั้งแต่ต้น โปรแกรมค้นหาจึงอ่านหัวข้อ ย่อหน้า ลิงก์ และข้อมูลสินค้าได้โดยไม่ต้องรอ JavaScript ทำงานเพิ่ม
ส่วนหน้า CSR อาจส่งกลับมาเพียงโครงสร้างลักษณะ <div id=”root”></div> แล้วให้ JavaScript เติมเนื้อหาภายหลัง Google สามารถประมวลผล JavaScript ได้ แต่ Google ระบุว่ายังมีข้อแตกต่างและข้อจำกัดที่ต้องคำนึงถึง โดยเฉพาะกรณีไฟล์ JavaScript ถูกบล็อก เกิดข้อผิดพลาด หรือเรียก API ไม่สำเร็จ อ่านเพิ่มเติมได้จาก คู่มือ JavaScript SEO ของ Google Search Central
จากประสบการณ์ตรวจเว็บจริง ปัญหาที่พบไม่ใช่ Google “อ่าน JavaScript ไม่ได้เลย” แต่เป็น Google ได้รับข้อมูลไม่ครบ เช่น เห็นชื่อสินค้าแต่ไม่เห็นรายละเอียด เห็นหน้า Category แต่ไม่เห็นลิงก์สินค้า หรือพบ Metadata คนละชุดกับที่ผู้ใช้เห็น
2. ความเร็วและ Core Web Vitals
SSR มีโอกาสแสดงเนื้อหาหลักได้เร็วกว่า เพราะเบราว์เซอร์ไม่ต้องรอดาวน์โหลด JavaScript ทั้งก้อนก่อนเริ่มสร้างหน้า จึงอาจช่วยค่า Largest Contentful Paint หรือ LCP ซึ่งวัดเวลาที่องค์ประกอบหลักปรากฏบนหน้าจอ
แต่ SSR ที่เซิร์ฟเวอร์ช้า ฐานข้อมูลตอบสนองนาน หรือไม่มีแคช ก็อาจทำให้ ค่า TTFB สูง และเปิดหน้าเว็บช้าได้เช่นกัน ส่วน CSR มักเสียเวลากับลำดับการทำงานหลายขั้น ได้แก่ โหลด HTML ดาวน์โหลด JavaScript ประมวลผลโค้ด เรียก API แล้วจึงแสดงเนื้อหา
ดังนั้นอย่าตัดสินจากคำว่า SSR หรือ CSR เพียงอย่างเดียว ควรตรวจทั้ง LCP, Interaction to Next Paint และ Cumulative Layout Shift ตามแนวทาง การปรับปรุง Core Web Vitals ด้วย Google แนะนำให้พิจารณา SSR แทน CSR ในกรณีที่ต้องการลดขั้นตอนก่อนแสดงองค์ประกอบหลักของหน้า
3. Metadata และลิงก์ภายใน
Title, Meta Description, Canonical Tag, Structured Data และลิงก์ภายในควรอยู่ใน HTML ที่ระบบค้นหาเข้าถึงได้ หน้า CSR บางระบบสร้างข้อมูลเหล่านี้หลัง JavaScript ทำงาน จึงเสี่ยงต่อการส่ง Metadata ไม่ครบหรือไม่ตรงกับเนื้อหา
ตัวอย่างที่เคยพบคือเว็บมีหน้าสินค้าหลายร้อย URL แต่ Source Code ของทุกหน้ามี Title เดียวกัน ส่วนชื่อสินค้าเพิ่งถูกเปลี่ยนภายหลังด้วย JavaScript ผลคือ Google เลือกชื่อหน้าเองและแสดงผลการค้นหาไม่ตรงกับที่ธุรกิจต้องการ การวาง Canonical Tag ให้ถูกต้อง จึงต้องตรวจจาก HTML ที่เซิร์ฟเวอร์ส่งกลับ ไม่ใช่ดูเฉพาะหน้า Elements ในเบราว์เซอร์
ใช้ SSR แล้ว SEO จะดีกว่า CSR เสมอหรือไม่?
ไม่เสมอไป เพราะการใช้ SSR ทุกหน้าอาจเพิ่มภาระให้เซิร์ฟเวอร์และทำให้ค่าใช้จ่ายสูงขึ้น หากทุกคำขอต้องดึงข้อมูลจำนวนมากจากฐานข้อมูล เว็บไซต์อาจช้ากว่า CSR ที่วางระบบไว้ดีเสียอีก
ทางเลือกที่ใช้งานได้จริงมักเป็น Hybrid Rendering หรือการผสมหลายรูปแบบในเว็บไซต์เดียว เช่น สร้างเนื้อหาสำคัญบนเซิร์ฟเวอร์ก่อน แล้วใช้ JavaScript เพิ่มระบบกรองสินค้า ตะกร้าสินค้า แผนที่ หรือเครื่องมือโต้ตอบภายหลัง
แนวทางนี้ช่วยให้ Google เห็นเนื้อหาหลักตั้งแต่ต้น ขณะที่ผู้ใช้ยังได้รับประสบการณ์แบบเว็บแอป ไม่จำเป็นต้องเลือกระหว่าง SSR และ CSR แบบขาวกับดำเสมอไป
หน้าเว็บแบบไหนควรใช้ SSR หรือ CSR?
ให้เริ่มจากถามว่า เนื้อหานี้ต้องปรากฏบน Google หรือไม่ และ ผู้ใช้ต้องเห็นอะไรทันทีเมื่อเปิดหน้า จากนั้นจึงเลือก Rendering ตามหน้าที่ของแต่ละหน้า
- บทความ หน้าบริการ และ Landing Page: ใช้ SSR หรือ Static Generation เพื่อให้เนื้อหาและ Metadata อยู่ใน HTML ตั้งแต่ต้น
- หน้าสินค้าและหน้าหมวดหมู่: ใช้ SSR หรือสร้างหน้าแบบ Static พร้อมอัปเดตตามรอบ โดยต้องมีลิงก์สินค้าใน HTML
- หน้าแดชบอร์ดและหลังบ้าน: ใช้ CSR ได้ เพราะข้อมูลเป็นส่วนตัวและไม่ต้องการให้ Google จัดทำดัชนี
- ระบบค้นหาและตัวกรอง: แสดงรายการเริ่มต้นจากเซิร์ฟเวอร์ แล้วใช้ CSR อัปเดตเมื่อผู้ใช้เลือกเงื่อนไข
- ข้อมูลเปลี่ยนตลอดเวลา: ใช้ SSR ร่วมกับ Cache หรือใช้ Server Rendering เฉพาะส่วนที่จำเป็น
สำหรับ WordPress แบบทั่วไป หน้าเว็บถูกสร้างจาก PHP บนเซิร์ฟเวอร์อยู่แล้ว จึงมีลักษณะใกล้เคียง SSR ปัญหามักเกิดเมื่อใช้ Page Builder หนักเกินไป หรือโหลดเนื้อหาหลักผ่าน JavaScript ภายหลัง
หากเป็น Headless WordPress ที่ใช้ React, Vue หรือ Next.js เป็นหน้าบ้าน คุณต้องกำหนด Rendering ให้ชัดเจน อย่าปล่อยให้บทความและหน้าสินค้าทั้งหมดกลายเป็น CSR โดยไม่ตั้งใจ
ตรวจสอบอย่างไรว่าเว็บไซต์มีปัญหา Rendering?
คุณสามารถตรวจเบื้องต้นได้โดยไม่ต้องเขียนโปรแกรม เริ่มจากเลือกหน้าที่สำคัญ เช่น หน้าบริการ หน้าสินค้า และบทความที่ต้องการทำอันดับ แล้วทำตามขั้นตอนนี้
ขั้นตอนที่ 1: เปิด View Page Source
คลิกขวาแล้วเลือก View Page Source จากนั้นค้นหาหัวข้อหลัก ข้อความสำคัญ ลิงก์ภายใน Canonical และ Structured Data หากเนื้อหาปรากฏอยู่ แปลว่าเซิร์ฟเวอร์ส่งข้อมูลส่วนนั้นมาใน HTML แล้ว
อย่าสับสนกับแท็บ Elements ใน Developer Tools เพราะ Elements แสดง DOM หลัง JavaScript ทำงานแล้ว จึงอาจเห็นเนื้อหาครบทั้งที่ Source Code เริ่มต้นไม่มีอะไรเลย
ขั้นตอนที่ 2: ทดลองปิด JavaScript
ปิด JavaScript ชั่วคราวแล้วโหลดหน้าใหม่ คุณไม่จำเป็นต้องทำให้ทุกฟังก์ชันใช้งานได้ แต่หัวข้อ เนื้อหาหลัก ราคา รายละเอียดสินค้า และลิงก์สำคัญควรยังปรากฏ หากหน้าเหลือเพียง Loading หรือหน้าขาว ควรตรวจต่อว่า Google ได้รับอะไรจริง
ขั้นตอนที่ 3: ใช้ URL Inspection ใน Search Console
นำ URL ไปตรวจใน Google Search Console แล้วใช้ฟังก์ชันทดสอบ URL จริง ตรวจ Screenshot, HTML ที่ Render แล้ว และทรัพยากรที่โหลดไม่สำเร็จ วิธีนี้ช่วยแยกได้ว่าปัญหาเกิดจาก Rendering, robots.txt, API หรือ JavaScript Error
ขั้นตอนที่ 4: วัดความเร็วจากข้อมูลผู้ใช้จริง
ตรวจ PageSpeed Insights และรายงาน Core Web Vitals แยกมือถือกับเดสก์ท็อป หาก LCP ช้าเพราะรอ JavaScript หรือรูปภาพหลักถูกโหลดช้า ให้ปรับ Rendering พร้อมกับ การใช้ Lazy Load อย่างถูกวิธี โดยไม่ Lazy Load รูป Hero ที่ต้องแสดงทันที
ข้อผิดพลาดที่พบบ่อยเมื่อทำ JavaScript SEO
- ส่ง HTML เปล่าให้ระบบค้นหา: เนื้อหาสำคัญทั้งหมดถูกสร้างหลังเรียก API
- สร้างลิงก์ด้วย Event Click อย่างเดียว: ไม่มีแท็ก Anchor และ URL จริงให้ Google ติดตาม
- เปลี่ยน Title และ Canonical หลังโหลดหน้า: เสี่ยงต่อข้อมูลไม่ตรงกันระหว่าง HTML เริ่มต้นกับหน้าที่ Render แล้ว
- โหลดเนื้อหาเมื่อเลื่อนหน้าจอเท่านั้น: Google อาจไม่กระตุ้นการเลื่อนเหมือนผู้ใช้ จึงไม่พบข้อมูลบางส่วน
- ใช้ SSR แต่ไม่ทำ Cache: เซิร์ฟเวอร์ต้องประมวลผลซ้ำทุกครั้ง ทำให้ TTFB สูงเมื่อมีผู้เข้าชมมาก
- ส่ง JavaScript มากเกินไป: แม้ HTML จะมาเร็ว แต่หน้าอาจกดไม่ได้ระหว่าง Hydration หรือช่วงที่ระบบเชื่อม HTML กับ JavaScript
การแก้ที่ถูกต้องจึงไม่ใช่เพียงติดตั้งปลั๊กอินเพิ่ม แต่ต้องดูเส้นทางตั้งแต่เซิร์ฟเวอร์ส่ง HTML จนถึงจังหวะที่ผู้ใช้มองเห็นและโต้ตอบกับหน้าได้จริง
SSR กับ CSR ส่งผลต่อธุรกิจอย่างไร?
ผลของ Rendering ไม่ได้หยุดอยู่ที่อันดับค้นหา หากลูกค้าเปิดหน้าโฆษณาแล้วพบหน้าขาว หรือคลิกสินค้าแล้วต้องรอ JavaScript หลายวินาที ธุรกิจก็อาจเสีย Conversion แม้จะซื้อทราฟฟิกมาแล้วก็ตาม
ในทางกลับกัน การบังคับใช้ SSR ทุกส่วนโดยไม่วาง Cache และโครงสร้างข้อมูล อาจเพิ่มค่าเซิร์ฟเวอร์และภาระดูแลระบบโดยไม่สร้างผลตอบแทน ดังนั้นการเลือก Rendering ที่เหมาะสมควรพิจารณาทั้งสามด้านพร้อมกัน
- SEO: ระบบค้นหาพบและเข้าใจเนื้อหาสำคัญได้หรือไม่
- UX: ผู้ใช้เห็นเนื้อหาและเริ่มใช้งานหน้าได้เร็วเพียงใด
- ต้นทุน: เซิร์ฟเวอร์ ทีมพัฒนา และระบบ Cache รองรับการเติบโตได้หรือไม่
แนวทางที่ปลอดภัยสำหรับเว็บไซต์ธุรกิจคือใช้ SSR หรือ Static Rendering กับหน้าที่ต้องการทราฟฟิกจาก Google แล้วใช้ CSR กับฟังก์ชันโต้ตอบหรือหน้าส่วนตัว ตรวจ HTML จริงทุกครั้ง และวัดผลจาก Search Console ควบคู่กับ Core Web Vitals วิธีนี้ให้ผลคุ้มกว่าการย้ายเทคโนโลยีทั้งเว็บไซต์เพียงเพราะได้ยินว่า SSR ดีต่อ SEO
คำถามที่พบบ่อย
Google อ่านเว็บไซต์แบบ CSR ได้ไหม?
Google สามารถประมวลผล JavaScript และอ่านเนื้อหาจากเว็บแบบ CSR ได้ แต่ต้องไม่มีไฟล์ถูกบล็อก ไม่มี JavaScript Error และ API ต้องตอบสนองได้ เนื้อหาที่สำคัญต่อ SEO จึงควรอยู่ใน HTML เริ่มต้นหรือใช้ Server Rendering เพื่อลดความเสี่ยง
WordPress เป็น SSR หรือ CSR?
WordPress แบบดั้งเดิมสร้าง HTML ด้วย PHP บนเซิร์ฟเวอร์ จึงมีลักษณะเป็น Server-Side Rendering แต่ธีมหรือปลั๊กอินบางตัวอาจใช้ JavaScript โหลดเนื้อหาบางส่วนภายหลัง ส่วน Headless WordPress จะเป็น SSR หรือ CSR ขึ้นอยู่กับ Framework และการตั้งค่าหน้าบ้าน
ควรเปลี่ยนเว็บ CSR ทั้งหมดให้เป็น SSR หรือไม่?
ไม่จำเป็น ควรเริ่มจากหน้าที่ต้องทำ SEO เช่น บทความ หน้าบริการ หน้าสินค้า และหน้าหมวดหมู่ก่อน ส่วนแดชบอร์ด บัญชีผู้ใช้ และเครื่องมือภายในยังใช้ CSR ได้ เป้าหมายคือทำให้เนื้อหาสาธารณะที่สำคัญเข้าถึงง่าย ไม่ใช่เปลี่ยนเทคโนโลยีทุกหน้าโดยไม่มีเหตุผลทางธุรกิจ