ผลการทดสอบ SEO ที่เผยแพร่สัปดาห์นี้ ตั้งคำถามกับความเชื่อที่ถูกพูดถึงมากที่สุดเรื่องหนึ่งเกี่ยวกับการเรนเดอร์ JavaScript ของ Google ความเชื่อนั้นบอกว่า Web Rendering Service ของ Google ให้เวลาแต่ละหน้าเพียงห้าวินาที และอะไรที่โผล่มาหลังจากนั้นจะไม่ถูกเก็บลงใน DOM snapshot ที่ Google นำไปทำดัชนี Search Engine Journal รายงานการทดสอบของ Dave Smart จาก Tame the Bots ซึ่งเป็นนัก SEO ในสหราชอาณาจักร โดยเนื้อหาที่ใช้เวลานานเกินห้าวินาทีไปมากก็ยังถูกเก็บได้อยู่ดี ทั้งนี้เป็นผลจากผู้ทดสอบอิสระรายเดียว ไม่ใช่คำประกาศจาก Google และ Google ยังไม่ได้ยืนยันเรื่องนี้
ตัวเลขห้าวินาทีมาจากไหน
ความเชื่อนี้ย้อนไปถึงคำพูดของ Martin Splitt จาก Google สิ่งที่เขาพูดจริงตามที่บทความอ้างไว้คือ "In median, a page's rendering queued for five seconds... 90th percentile is a few minutes."
เขากำลังอธิบายว่าหน้าเว็บรอคิวเรนเดอร์นานแค่ไหนก่อนที่ตัวเรนเดอเรอร์จะหยิบไปทำ นั่นคือเวลารอ ไม่ใช่เวลาทำงาน ประเด็นของบทความคือคนทำ SEO อ่านสถิติเวลาคิวเป็นเส้นตายของการเรนเดอร์ แล้วความเข้าใจผิดนั้นก็แข็งตัวกลายเป็นกฎ ซึ่งย้อนกลับไปกำหนดวิธีที่คนสร้างหน้าเว็บ
การทดสอบทำอะไรบ้าง
Smart สร้างหน้าทดสอบที่ยิงคำขอแบบ POST สองครั้งเรียงกันไปยังสคริปต์ PHP โดยสคริปต์นั้นหน่วงการตอบกลับแต่ละครั้งแบบสุ่มระหว่างสามถึงหกวินาที ดังนั้นสองคำขอรวมกันจะใช้เวลาได้ตั้งแต่หกถึงสิบสองวินาที ทุกรอบจึงเกินเส้นห้าวินาทีที่เชื่อกันไปพอสมควร
ตอนแรกผลลัพธ์ดูเหมือนจะยืนยันทฤษฎีเดิม เพราะตัวจับเวลา JavaScript บนหน้าเดินไปห้าวินาที แต่ Web Rendering Service ของ Google กลับยังรอการตอบกลับที่ถูกหน่วงไว้ และเก็บเนื้อหาที่มาถึงหลังจากนั้นได้
ข้อสรุปของ Smart ตามที่ SEJ รายงานคือ WRS ทำงานบนนาฬิกาเสมือนที่มันควบคุมเอง และสามารถหยุดกับเดินนาฬิกาการเรนเดอร์ใหม่ได้ แทนที่จะผูกกับเวลาจริงที่ผ่านไป คำอธิบายนี้รองรับสองสิ่งที่สังเกตเห็นพร้อมกัน คือตัวจับเวลาของหน้าทำตัวเหมือนผ่านไปห้าวินาทีแล้ว ขณะที่ตัวเรนเดอเรอร์ยังรอเนื้อหาที่ใช้เวลาจริงนานกว่านั้นมาก
ขั้นตอนการเรนเดอร์ของ Google
บทความอธิบายลำดับการทำงานของ WRS ไว้ดังนี้
- รับ HTML ที่ Googlebot ไต่มาได้
- ดึงทรัพยากรที่หน้านั้นต้องใช้ ทั้ง CSS, JavaScript และรูปภาพ
- โหลดหน้าในเบราว์เซอร์ Chromium แบบ headless
- ประมวลผล JavaScript
- สร้าง DOM snapshot
- ส่ง snapshot นั้นต่อให้ระบบทำดัชนีของ Google
สิ่งที่ถูกนำไปทำดัชนีคือ snapshot ดังนั้นข้อถกเถียงเรื่องเวลาทั้งหมด แท้จริงแล้วคือข้อถกเถียงว่ามีอะไรโหลดเสร็จแล้วบ้างในวินาทีที่ snapshot ถูกถ่ายไว้
อ่านข้อจำกัดให้ครบก่อนจะไปแก้อะไร
มีข้อจำกัดสามข้อที่ควรพูดให้ชัด
ข้อแรก นี่คือการทดสอบของผู้ปฏิบัติงานอิสระรายเดียว ไม่ใช่ประกาศจาก Google และไม่มีอะไรในนี้เป็นการเปลี่ยนนโยบาย ข้อสอง Google ยังไม่ได้ยืนยันคำอธิบายเรื่องนาฬิกาเสมือน จึงควรมองว่าเป็นการทดลองที่ออกแบบมาดีและให้ผลขัดกับกฎที่ท่องกันมา ซึ่งต่างจากพฤติกรรมที่มีเอกสารรองรับจนใช้วางโครงเว็บได้
ข้อสาม เรื่องนี้ไม่ได้ทำให้การเรนเดอร์ช้าเป็นเรื่องดีขึ้นเลย หน้าที่ใช้เวลาแปดวินาทีกว่าจะประกอบเนื้อหาเสร็จ ก็ยังเป็นหน้าที่แย่สำหรับคนที่นั่งรออยู่ และ Core Web Vitals ก็ยังวัดประสบการณ์ที่ผู้ใช้ได้รับจริง ผลการทดสอบนี้ลบความเชื่อผิดออกไปหนึ่งข้อ แต่ไม่ได้ลบเหตุผลที่ต้องทำเว็บให้เร็ว
เว็บที่พึ่ง JavaScript หนักควรกังวลเรื่องอะไรจริง ๆ
เลิกใช้ตัวเลขห้าวินาทีเป็นข้อจำกัดในการออกแบบได้แล้ว เพราะมันไม่เคยเป็นตัวเลขอย่างที่คนเข้าใจตั้งแต่ต้น สิ่งที่ควรใช้แทนไม่ใช่ตัวเลขใหม่ แต่เป็นนิสัยการทำงาน คือตรวจว่า Google เรนเดอร์เทมเพลตของคุณออกมาเป็นอย่างไรจริง แทนที่จะเชื่อกฎกลาง ๆ
- ใช้เครื่องมือตรวจสอบ URL ใน Search Console ทดสอบแบบสดกับ URL ตัวแทนของเทมเพลตแต่ละแบบ แล้วอ่าน HTML ที่เรนเดอร์ออกมา ไม่ใช่ดูแค่ภาพหน้าจอ ถ้าเนื้อหาหลัก ลิงก์ภายใน หรือข้อมูลโครงสร้างหายไปตรงนั้น นั่นคือปัญหาจริงไม่ว่าทฤษฎีเรื่องเวลาจะเป็นอย่างไร
- ตรวจลิงก์ ไม่ใช่แค่ตัวอักษร เมนูและระบบแบ่งหน้าที่ถูกฉีดเข้ามาด้วย JavaScript คือส่วนที่หายบ่อยที่สุด และลิงก์ที่หายไปแปลว่าเส้นทางการไต่หายตามไปด้วย
- อย่าลืมเรื่องคิว คำพูดชุดเดียวกันที่เป็นต้นเหตุของความเชื่อนี้ ระบุว่าเวลารอคิวที่เปอร์เซ็นไทล์ที่ 90 อยู่ที่ระดับไม่กี่นาที การเรนเดอร์จึงไม่ได้เกิดทันที เนื้อหาที่เพิ่งเผยแพร่อาจใช้เวลากว่าจะสะท้อนผลนานกว่าที่ดูจากบันทึกการไต่
- ส่งเนื้อหาสำคัญจากฝั่งเซิร์ฟเวอร์เท่าที่ทำได้ ไม่ใช่เพราะเส้นห้าวินาที แต่เพราะมันตัดเงื่อนไขนี้ทิ้งทั้งหมด และเร็วกว่าสำหรับผู้ใช้
สำหรับเว็บที่กำลังทำใหม่บนเฟรมเวิร์ก JavaScript สมัยใหม่ คำถามนี้ควรตอบตั้งแต่ตอนพัฒนา ไม่ใช่หลังเปิดใช้งาน เพราะวิธีที่เนื้อหาเดินทางไปถึง DOM เป็นการตัดสินใจในงาน ออกแบบและพัฒนาเว็บไซต์ ที่ส่งผลต่อการค้นหา และแก้ที่เทมเพลตย่อมถูกกว่าตามแก้ URL หลักพันหน้าที่เปิดใช้งานไปแล้ว
เรื่องนี้บอกอะไรกับนักการตลาดในไทย
เว็บไทยจำนวนมากตอนนี้ใช้เฟรมเวิร์กที่ประกอบเนื้อหาฝั่งไคลเอนต์ โดยเฉพาะแคตตาล็อกอีคอมเมิร์ซ ประกาศอสังหาริมทรัพย์ และขั้นตอนการจอง ที่ตัวกรองและข้อมูลห้องว่างมาจาก API หลังหน้าเว็บโหลดรอบแรก กฎห้าวินาทีถูกใช้ในหลายโปรเจกต์เหล่านั้นเป็นตัวย่อของคำว่าปลอดภัย ซึ่งตัวย่อนั้นไม่เคยแม่นทั้งสองทาง การเปลี่ยนมาทดสอบจริงจึงเป็นข้อสรุปที่ใช้งานได้
ยังมีเหตุผลที่สองที่ควรทดสอบแทนการเดา เนื้อหาภาษาไทย ข้อมูลราคาและสต็อก รวมถึงข้อมูลโครงสร้างเวอร์ชันท้องถิ่น มักเป็นส่วนที่ถูกฉีดเข้ามาท้ายสุด จึงมีโอกาสหายไปจาก snapshot ที่เรนเดอร์มากที่สุด การยืนยันว่า Google เห็นเนื้อหาภาษาไทยเหมือนที่เห็นเนื้อหาภาษาอังกฤษ เป็นการตรวจเฉพาะจุด ไม่ใช่การตรวจแบบกว้าง และควรอยู่ในแผน SEO ของเว็บสองภาษาทุกแห่ง
คำถามที่พบบ่อย
Google หยุดเรนเดอร์หลังห้าวินาทีจริงหรือไม่ การทดสอบที่ SEJ รายงานพบว่าเนื้อหาที่มาถึงช้ากว่าห้าวินาทีไปมากก็ยังถูกเก็บได้ และ Google ยังไม่ได้ยืนยันว่าตัวเรนเดอเรอร์จัดการเรื่องเวลาอย่างไร จึงควรมองตัวเลขห้าวินาทีว่าเชื่อถือไม่ได้ มากกว่าจะมองว่าเป็นขีดจำกัดที่ยืนยันแล้วไม่ว่าทางใด
ตัวเลขห้าวินาทีมาจากไหน มาจากคำพูดของ Martin Splitt ที่อธิบายค่ามัธยฐานของเวลารอคิวเรนเดอร์ โดยเปอร์เซ็นไทล์ที่ 90 อยู่ที่ระดับไม่กี่นาที มันอธิบายการรอคิว ไม่ใช่งบเวลาสำหรับการเรนเดอร์
แปลว่าเลิกสนใจความเร็วเว็บได้ใช่ไหม ไม่ใช่ ความเร็วยังสำคัญทั้งต่อผู้ใช้และต่อ Core Web Vitals ผลการทดสอบนี้แค่ลบกฎที่ท่องกันมาข้อหนึ่งออกไปเท่านั้น
จะตรวจว่า Google เรนเดอร์เว็บเราออกมาอย่างไร ใช้เครื่องมือตรวจสอบ URL ใน Search Console ทดสอบแบบสด แล้วอ่าน HTML ที่เรนเดอร์ของเทมเพลตแต่ละแบบ
ถ้าเว็บของคุณพึ่ง JavaScript ในการส่งเนื้อหาหลัก และยังไม่มีใครตรวจว่า Google เรนเดอร์ออกมาเป็นอย่างไร การตรวจรอบนี้คุ้มค่าที่จะจัดคิวไว้ ทีมงานเรายินดีไล่ดูทีละเทมเพลตไปพร้อมกับคุณ
