Lighthouse 13.6 อาจทำให้คะแนน lab ใน PageSpeed Insights สูงขึ้น: อะไรเปลี่ยน

ตามรายงานของ Search Engine Journal เมื่อวันที่ 2 พฤศจิกายน 2569 ที่อ้างถึง Barry Pollard จาก Chrome ระบุว่า PageSpeed Insights เปลี่ยนมาใช้ Lighthouse 13.6.0 แล้ว เวอร์ชันนี้ทีม Lighthouse เผยแพร่ใน GitHub ของ GoogleChrome เมื่อวันที่ 27 ตุลาคม 2569 และปรับ Lantern ซึ่งเป็นเอนจินที่จำลองการโหลดหน้าเว็บ Barry Pollard ตำแหน่ง Web Performance Developer Advocate ของ Chrome ระบุว่าอัปเดตนี้ทำให้ค่า First Contentful Paint (FCP) และ Largest Contentful Paint (LCP) ที่จำลองได้แม่นยำขึ้น และโดยทั่วไปให้คะแนนสูงขึ้น โดยเว็บไซต์ที่ใช้ JavaScript หนักมีแนวโน้มได้รับผลมากกว่า ผลคือหน้าเว็บอาจได้คะแนน lab ใน PageSpeed Insights ดีขึ้นทั้งที่ไม่ได้แก้อะไรในหน้าเลย

บันทึกการเผยแพร่ Lighthouse v13.6.0 บน GitHub ระบุว่าทีมคาดว่าเวอร์ชันนี้จะขึ้น PageSpeed Insights "ภายในหนึ่งสัปดาห์" และจะมากับ DevTools ของ Chrome 159 ส่วน Search Engine Journal รายงานเมื่อวันที่ 2 พฤศจิกายน 2569 ว่า PageSpeed Insights เปลี่ยนเวอร์ชันแล้ว โดยอ้างโพสต์ของ Pollard บน Bluesky บทความนี้อธิบายว่าการจำลองเปลี่ยนไปอย่างไร ทำไมกราฟคะแนนย้อนหลังจะเห็นการกระโดด และข้อมูล lab ต่างจากข้อมูล field ที่ Google ใช้ในการรายงาน Core Web Vitals อย่างไร

Lighthouse 13.6.0 เปลี่ยนอะไรบ้าง

บันทึกการเผยแพร่จัดกลุ่มการเปลี่ยนแปลงของ 13.6.0 ไว้เป็นหัวข้อหลักไม่กี่หมวด ตารางด้านล่างสรุปรายการที่มีผลต่อการรายงานประสิทธิภาพและการออดิตเว็บไซต์ ตามที่บันทึกการเผยแพร่ระบุ พร้อมวันที่และสถานะที่มีการรายงานช่วงทยอยเปิดใช้

Lantern จำลองการโหลดหน้าเว็บอย่างไร

โดยค่าเริ่มต้น Lighthouse ไม่ได้ทำให้เครือข่ายช้าลงจริงระหว่างทดสอบ Search Engine Journal สรุปจากเอกสารเรื่อง throttling ของ Lighthouse ว่า หน้าเว็บจะโหลดด้วยความเร็วเต็มที่ แล้ว Lighthouse จึงประเมินว่าหน้าจะโหลดอย่างไรหากใช้การเชื่อมต่อที่ช้ากว่า การประเมินนี้คือหน้าที่ของ Lantern ซึ่งสร้างกราฟความสัมพันธ์ของคำขอและงานบน main thread ของหน้า จำลองเครือข่าย แล้วคำนวณว่า FCP, LCP และตัวชี้วัดอื่นจะเกิดขึ้นเมื่อใดภายใต้โปรไฟล์ที่ถูกจำกัดความเร็ว Search Engine Journal ระบุด้วยว่าเอกสาร throttling บอกว่าการจำกัดความเร็วแบบจำลองนี้ตรงกับการตั้งค่าของ PageSpeed Insights

เมื่อตัวชี้วัดที่รายงานมาจากการคำนวณ การเปลี่ยนโมเดลก็เปลี่ยนตัวเลข แม้หน้าเว็บและเครือข่ายจริงจะเหมือนเดิมทุกอย่าง นี่คือแก่นของข่าวนี้ Lighthouse 13.6.0 เปลี่ยนโมเดล ผลลัพธ์ lab ของ PageSpeed Insights ก่อนและหลังการเปลี่ยนจึงมาจากการจำลองคนละแบบ

การเปลี่ยนเรื่อง render-blocking

บันทึกการเผยแพร่ระบุว่า Lighthouse ใช้สถานะ renderBlocking จากโปรโตคอลเพื่อกำหนดลำดับความสำคัญแบบ render-blocking แล้ว Search Engine Journal อธิบายความต่างว่า Lighthouse 13.5 ใช้ fetch priority ของแต่ละคำขอเพื่อตัดสินว่าคำขอนั้นบล็อกการเรนเดอร์หรือไม่ ขณะที่ Lantern ใน 13.6 ใช้ป้ายกำกับ render-blocking ของ Chrome เองสำหรับแต่ละคำขอ และกลับไปใช้ priority เฉพาะเมื่อไม่มีป้ายกำกับนั้น คำขอที่ Chrome ไม่ถือว่าบล็อกการเรนเดอร์แต่มี fetch priority สูง เดิมจะถูกนับว่าทำให้การแสดงผลครั้งแรกในการจำลองช้าลง

การเปลี่ยนเรื่อง LCP ที่เป็นข้อความ

การเปลี่ยนแปลงที่สองใช้กับกรณีที่องค์ประกอบ LCP เป็นข้อความที่แสดงในเฟรมเดียวกับเนื้อหาแรกของหน้า ทำให้การแสดงผลครั้งเดียวนับเป็นทั้ง FCP และ LCP ตามบันทึกการเผยแพร่ Lantern จะใช้กราฟของ FCP ในกรณีนี้ Search Engine Journal อธิบายผลว่า Lantern ประเมิน LCP นั้นจากชุดคำขอและงานของหน้าชุดเดียวกับที่ใช้คำนวณ FCP แทนที่จะใช้ชุดที่อาจรวมทุกคำขอที่เกิดก่อน LCP

Search Engine Journal ระบุว่าส่วนหนึ่งของเรื่องนี้เริ่มจาก issue บน GitHub ที่นักพัฒนา Ivan Akulov เปิดไว้ หน้าทดสอบของเขาสร้างด้วย Framer และมีเพียงข้อความในส่วนบนของหน้า FCP และ LCP จึงเป็นองค์ประกอบเดียวกัน แต่การจำลองแบบเดิมยังรายงาน LCP ช้ากว่า FCP มาก การ preload โมดูล JavaScript ของหน้าช่วยให้หน้าจริงโต้ตอบได้เร็วขึ้น แต่กลับทำให้ LCP ที่จำลองแย่ลง Pollard ตอบว่า Akulov เป็นผู้ "จุดประกายการปรับปรุงบางส่วนนี้" และทีม Lighthouse ปิด issue ว่าเสร็จสิ้นแล้วใน Lantern เวอร์ชันที่อัปเกรดตามบันทึกของ 13.6

การจำลองเครือข่ายและ JavaScript

รายการอื่นของ Lantern ในบันทึกการเผยแพร่เกี่ยวกับเครือข่ายและการระบุที่มาของสคริปต์ การเชื่อมต่อ HTTP/3 ถูกถือเป็นแบบ multiplexed ไบต์ส่วนเกินของ HTTP/2 ที่ถูกใช้ไปถูกนับข้ามขั้นตอนการจำลอง คำขอที่ไม่มีการเชื่อมต่อถูกตัดออกจากการนับการเชื่อมต่อที่ใช้งานอยู่ และมีการปรับการประเมิน round-trip time, throughput และการจัดการ redirect ของ origin นอกจากนี้ Lighthouse เพิ่มการระบุที่มาของเหตุการณ์ trace ชื่อ v8.compileModule และ v8.evaluateModule ซึ่งเกี่ยวกับโมดูล JavaScript และแก้การคำนวณการแจกแจง LCP ที่จำลอง รุ่นนี้ยังอัปเกรด trace engine เป็นเวอร์ชัน 0.0.66 และ 0.0.67

ทำไมเว็บที่ใช้ JavaScript หนักจึงเห็นคะแนนกระโดดมากที่สุด

ความเห็นของ Pollard ตามที่ Search Engine Journal อ้างไว้คือ การเปลี่ยนแปลงนี้ "ไม่ได้เฉพาะกับ SPA (และไม่เกี่ยวกับงานด้าน SPA อื่นที่กำลังทำอยู่) แต่มีแนวโน้มกระทบเว็บที่ใช้ JS หนักมากกว่า" เขาตอบนักพัฒนาคนหนึ่งที่สังเกตว่าแอปแบบหน้าเดียวได้ผลดีขึ้นมาก โดยยกตัวอย่าง react.dev ตัวบันทึกการเผยแพร่เองไม่ได้จัดลำดับว่าเว็บประเภทใดได้รับผลมากที่สุด ข้อมูลส่วนนี้จึงอ้างอิงจากคำพูดของ Pollard

กลไกนี้สอดคล้องกับรายการที่เปลี่ยน เว็บที่โหลดสคริปต์จำนวนมาก preload โมดูล JavaScript หรือส่งทรัพยากรหลายรายการด้วย fetch priority สูง เป็นกลุ่มที่โดนวิธีนับคำขอ render-blocking แบบเดิมและการประเมิน LCP ที่เป็นข้อความแบบเดิมมากที่สุด ย่อหน้านี้เป็นบทวิเคราะห์ ไม่ใช่ข้ออ้างของ Google บันทึกการเผยแพร่อธิบายการเปลี่ยนโมเดล ส่วน Pollard บอกทิศทางของผลต่อคะแนน

การเปลี่ยนนี้ไม่ได้แปลว่าการจำลองสมบูรณ์แล้ว Search Engine Journal ชี้ไปยัง issue บน GitHub ของ Lighthouse ที่ยังเปิดอยู่ ซึ่งกำลังตรวจกรณีที่ LCP ที่ Lantern จำลองสูงกว่า LCP ที่วัดได้จริงมาก โดยยกตัวอย่างเว็บที่ใช้ JavaScript ขนาดใหญ่และเว็บแบบ SPA

ข้อมูล lab ต่างจากข้อมูล field อย่างไร

PageSpeed Insights แสดงข้อมูลสองประเภท และมีเพียงประเภทเดียวที่เปลี่ยนในอัปเดตนี้ เอกสาร PageSpeed Insights ของ Google ระบุว่าข้อมูล lab สร้างโดย Lighthouse ในสภาพแวดล้อมจำลอง และสำหรับมือถือ Lighthouse จำลองอุปกรณ์ระดับกลาง (Moto G4) บนเครือข่ายมือถือ ส่วนข้อมูล field มาจาก Chrome User Experience Report (CrUX) ครอบคลุมค่า FCP, LCP, CLS และ INP ของผู้ใช้จริงในช่วงเก็บข้อมูล 28 วันที่ผ่านมา เอกสารระบุว่าคะแนน lab ตั้งแต่ 90 ขึ้นไปถือว่าดี แต่ "การมีข้อมูล lab ที่ดีไม่ได้แปลว่าประสบการณ์ของผู้ใช้จริงจะดีด้วยเสมอไป"

ส่วนข้อมูล field ในรายงาน PageSpeed Insights ไม่ได้รับผลจาก Lighthouse 13.6 เพราะไม่ได้มาจากการจำลอง มีเพียงคะแนนประสิทธิภาพ lab และตัวชี้วัด lab ด้านล่างเท่านั้นที่ขยับ

ความต่างนี้เป็นเส้นแบ่งเดียวกับที่ Google ใช้ในเรื่องการค้นหา หน้า "Understanding Core Web Vitals and Google search results" ของ Google Search Central อธิบายว่า Core Web Vitals เป็นชุดตัวชี้วัดที่วัดประสบการณ์ผู้ใช้ในโลกจริงด้านการโหลด การโต้ตอบ และความเสถียรของการแสดงผล และระบุว่า Core Web Vitals ที่ดีสอดคล้องกับสิ่งที่ระบบจัดอันดับหลักของ Google ต้องการให้รางวัล ส่วนรายงาน Core Web Vitals ใน Search Console ตามหน้าช่วยเหลือของรายงาน อ้างอิงข้อมูลการใช้งานจริงจาก CrUX ซึ่งบางครั้งเรียกว่าข้อมูล field ดังนั้นคะแนน Lighthouse ที่สูงขึ้นหลัง 13.6 ไม่ได้บอกอะไรใหม่เกี่ยวกับตัวชี้วัดของผู้ใช้จริงที่ Search Console รายงาน

ผลต่อรายงานประสิทธิภาพเว็บไซต์

Search Engine Journal สรุปความเสี่ยงไว้ตรง ๆ ว่า คะแนน PageSpeed Insights ก่อนและหลังอัปเดตไม่ได้วัดด้วยการจำลองแบบเดียวกัน คะแนน lab ที่สูงขึ้นบนหน้าที่เพิ่งปรับปรุงจึงอาจมาจากเวอร์ชันใหม่บางส่วน และกราฟที่ติดตามคะแนน lab ตามเวลาอาจเห็นการกระโดด ณ จุดที่เปลี่ยนเป็น 13.6 รายงาน PageSpeed Insights ทุกฉบับแสดงเวอร์ชัน Lighthouse ที่ใช้ไว้ข้างอุปกรณ์ที่จำลอง จึงบอกได้ว่าผลลัพธ์แต่ละครั้งอยู่ก่อนหรือหลังการเปลี่ยน

รายการต่อไปนี้เป็นบทวิเคราะห์สำหรับทีมที่รายงานคะแนน lab ไม่ใช่คำแนะนำจาก Google

• ใส่หมายเหตุในแดชบอร์ดและรายงานรายเดือน ณ วันที่เครื่องมือของคุณเปลี่ยนเป็น Lighthouse 13.6 เพื่อไม่ให้การกระโดดของคะแนนถูกตีความว่าเว็บดีขึ้นหรือเป็นผลงานของทีม
• เปรียบเทียบสิ่งที่เทียบกันได้ ก่อนอ้างว่าดีขึ้น ให้ตรวจว่ารายงานก่อนและหลังระบุเวอร์ชัน Lighthouse เดียวกัน ตามที่ Search Engine Journal แนะนำ และเทียบข้อมูล field ด้วย
• ถ้ารัน Lighthouse เองผ่าน CLI ไปป์ไลน์ CI หรือเครื่องมือมอนิเตอร์ภายนอก ให้ตรวจว่าแต่ละเครื่องมือใช้เวอร์ชันใด DevTools คาดว่าจะได้ 13.6 มากับ Chrome 159 ซึ่ง Search Engine Journal ระบุว่า ณ วันที่ 2 พฤศจิกายน 2569 อยู่ในช่อง Dev และ Canary และมีกำหนดเผยแพร่รุ่นเสถียรวันที่ 8 ธันวาคม 2569 จนกว่าจะถึงตอนนั้น DevTools กับ PageSpeed Insights อาจให้ผลไม่ตรงกัน
• สำหรับรายงานถึงลูกค้าหรือผู้บริหาร ให้เริ่มจากข้อมูล field ของ CrUX และรายงาน Core Web Vitals ใน Search Console หากเว็บมีทราฟฟิกมากพอจะปรากฏใน CrUX และใช้คะแนน lab เป็นเครื่องมือช่วยหาปัญหา

ทีมที่รวมการตรวจประสิทธิภาพไว้ใน การออดิต SEO ควรบันทึกเวอร์ชัน Lighthouse ไว้คู่กับผล lab ทุกครั้งนับจากนี้

การเปลี่ยนแปลงอื่นในรุ่นนี้

ออดิตหลาย URL พร้อมกันผ่าน CLI

Lighthouse CLI ออดิตหลาย URL ในคำสั่งเดียวได้แล้ว ทั้งการใส่ URL หลายรายการ หรือใช้ --url-file และ --fail-fast จะหยุดการรันเมื่อเจอความล้มเหลวครั้งแรก ชื่อไฟล์รายงานเริ่มต้นตอนนี้รวม pathname ของ URL ในรูปแบบ hostname-pathname_date เพื่อไม่ให้ชื่อไฟล์ชนกันระหว่างหน้าในโดเมนเดียวกัน สำหรับคนที่ออดิตชุดเทมเพลตทั่วทั้งเว็บ ข้อนี้ช่วยตัดขั้นตอนการเขียนสคริปต์ไปหนึ่งขั้น

ออดิต Agentic Resource Discovery อัปเดตเป็น v0.91

ออดิต ARD ที่เริ่มมีใน Lighthouse 13.5 ได้รับการอัปเดตตามสเปก ARD v0.91 โดยใช้ ard.json แทน ai-catalog.json บันทึกการเผยแพร่ระบุว่ารองรับการค้นพบผ่าน Link HTTP header, องค์ประกอบ <link rel="ard"> และ /.well-known/ard.json โดย Lighthouse จะเตือนเมื่อพบตำแหน่ง ai-catalog แบบเดิม และส่วนท้ายรายงานจะแสดงเวอร์ชันของสเปก ARD Search Engine Journal เสริมว่า 13.6 จะมองหาบรรทัด Agentmap ใน robots.txt ก่อนตรวจชื่อ ai-catalog แบบเก่าด้วย และภายใต้ 13.5 เว็บที่ใช้เฉพาะชื่อไฟล์ใหม่โดยไม่มีบรรทัดนั้นใน robots.txt อาจแสดงผลเป็น Not Applicable

การแก้ไขย่อยที่ควรรู้

บันทึกการเผยแพร่ยังระบุว่าออดิต robots.txt และ llms.txt ไม่ error อีกเมื่อเนื้อหาเป็นค่าว่าง และจะไม่ผ่านเมื่อได้รับ HTTP 429 ออดิตกลุ่ม performance insight จะใส่ค่า numericValue จากเวลาหรือจำนวนไบต์ที่ประเมินว่าประหยัดได้ และการใช้หน่วยความจำสูงสุดระหว่างการรันลดลงด้วยการสตรีม trace

ความหมายสำหรับนักการตลาดไทย

ไม่มีส่วนใดในอัปเดตนี้ที่เฉพาะกับประเทศไทย PageSpeed Insights เป็นเครื่องมือระดับโลก เว็บไซต์ไทยที่ทดสอบหลังการเปลี่ยนจึงถูกให้คะแนนด้วย Lighthouse 13.6 และกราฟคะแนนย้อนหลังจะเห็นการกระโดดแบบเดียวกัน เอกสารของ PageSpeed Insights ระบุด้วยว่าการทดสอบรันในดาต้าเซ็นเตอร์ของ Google ในอเมริกาเหนือ ยุโรป หรือเอเชีย และตำแหน่งอาจเปลี่ยนได้ จึงควรดูส่วน environment ของรายงานเมื่อเทียบผลการรันแต่ละครั้ง

ประเด็นที่ใช้งานได้จริงสำหรับธุรกิจไทยอยู่ที่การรายงาน หากเอเจนซี นักพัฒนา หรือทีมภายในรายงานว่าคะแนน PageSpeed Insights เพิ่มขึ้นทันทีในต้นเดือนพฤศจิกายน 2569 ให้ถามว่าเว็บเปลี่ยนหรือเครื่องมือเปลี่ยน สำหรับเว็บที่มีทราฟฟิกจาก Chrome มากพอจะมีข้อมูล CrUX ส่วนข้อมูล field ในรายงานเดียวกันเป็นตัววัดที่นิ่งกว่า เพราะสะท้อนผู้เข้าชมจริงในช่วง 28 วัน เมื่อมีการทำเว็บใหม่ การวัด lab ก่อนและหลังเปิดตัวควรใช้ Lighthouse เวอร์ชันเดียวกัน หากเว็บต้องการการปรับประสิทธิภาพจริงมากกว่าตัวเลขที่ดูดีขึ้น ทีม ออกแบบเว็บไซต์ ของ Relevant Audience ช่วยวางแผนงานนั้นได้

คำถามที่พบบ่อย

ทำไมคะแนน PageSpeed Insights ขึ้นทั้งที่ไม่ได้แก้อะไร

คะแนนน่าจะขึ้นเพราะ PageSpeed Insights เปลี่ยนมาใช้ Lighthouse 13.6.0 ซึ่งการจำลองแบบใหม่โดยทั่วไปให้ผล FCP และ LCP ที่ดีขึ้น ตามที่ Barry Pollard ของ Google ระบุ คะแนน lab คำนวณจากโมเดล และสิ่งที่เปลี่ยนคือโมเดล ไม่ใช่หน้าเว็บ

อัปเดต Lighthouse 13.6 เปลี่ยนค่า Core Web Vitals ของเว็บหรือไม่

ไม่เปลี่ยน อัปเดตนี้เปลี่ยนเฉพาะผล lab ส่วน Core Web Vitals ที่รายงานใน Search Console และในส่วนข้อมูล field ของ PageSpeed Insights มาจากข้อมูล CrUX ของผู้ใช้ Chrome จริง ซึ่ง Lighthouse ไม่ได้จำลอง

เว็บประเภทใดได้รับผลจาก Lighthouse 13.6 มากที่สุด

เว็บที่ใช้ JavaScript หนักมีแนวโน้มได้รับผลมากกว่า ตามที่ Pollard ระบุ และเขาบอกด้วยว่าการเปลี่ยนแปลงนี้ไม่ได้เฉพาะกับแอปแบบหน้าเดียว บันทึกการเผยแพร่อธิบายการเปลี่ยนโมเดลเรื่องคำขอ render-blocking, LCP ที่เป็นข้อความซึ่งแสดงพร้อม FCP, HTTP/3 และเหตุการณ์ของโมดูล JavaScript

จะรู้ได้อย่างไรว่าผลลัพธ์มาจาก Lighthouse เวอร์ชันใด

รายงาน PageSpeed Insights ทุกฉบับแสดงเวอร์ชัน Lighthouse ไว้ข้างอุปกรณ์ที่จำลอง ตามที่ Search Engine Journal ระบุ การเทียบสองรายงานจะยุติธรรมก็ต่อเมื่อทั้งสองระบุเวอร์ชันเดียวกัน

Chrome DevTools จะใช้ Lighthouse 13.6 เมื่อใด

ทีม Lighthouse คาดว่า 13.6 จะมากับ DevTools ของ Chrome 159 โดย Search Engine Journal รายงานว่า ณ วันที่ 2 พฤศจิกายน 2569 กำหนดการของ Chrome ระบุให้ Chrome 159 เผยแพร่รุ่นเสถียรวันที่ 8 ธันวาคม 2569

คะแนนที่กระโดดเพราะการจำลองแบบใหม่อธิบายได้ง่ายเมื่อมีเวอร์ชันระบุไว้ในรายงาน หากทีมของคุณต้องการให้การตรวจประสิทธิภาพและด้านเทคนิคผูกกับข้อมูลผู้ใช้จริง บริการ SEO ของ Relevant Audience ช่วยวางระบบนี้ได้