PageSpeed Insights อ่านยังไง ส่วนไหนที่ Google ใช้วัดเว็บคุณจริง

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

รายงาน PageSpeed Insights ของ Google ก็ทำงานแบบเดียวกันเป๊ะครับ ในหน้าเดียวมีตัวเลขสองแบบวางซ้อนกันอยู่ แบบหนึ่งคือการวัดครั้งเดียวในห้องทดลอง อีกแบบคือสมุดบันทึกจากผู้ใช้จริงย้อนหลังหลายสัปดาห์ เจ้าของธุรกิจหลายคนที่ผมคุยด้วย เห็นวงกลมสีแดงหรือสีส้มตัวเลขใหญ่ๆ ตรงกลางจอ แล้วตกใจจนรีบจ้างคนมาทำ "speed optimisation" ทันที ทั้งที่ยังไม่รู้เลยว่าตัวเลขนั้นคือสมุดบันทึก หรือคือความดันตอนเพิ่งวิ่งขึ้นบันได

บทความนี้ผมจะพาไล่อ่านรายงานไปทีละชั้นครับ ว่าส่วนไหนที่ Google ใช้จริง ส่วนไหนแกว่งได้ทุกครั้งที่กด ส่วนไหนเจ้าของเว็บดูเองได้ และควรถามทีมทำเว็บว่าอะไรก่อนจ่ายเงินสักบาท ถ้าอยากรู้ก่อนว่า Core Web Vitals คืออะไรและทำไมถึงสำคัญ ผมเขียนไว้แยกในบทความเรื่อง Core Web Vitals กับเว็บไซต์ธุรกิจแล้ว ที่นี่เราจะโฟกัสแค่การอ่านรายงานอย่างเดียว

ลองเปิดรายงานของเว็บคุณไปพร้อมกันสักห้านาที

เปิดเว็บ pagespeed.web.dev แล้ววางลิงก์หน้าแรกของเว็บคุณลงไป กดวิเคราะห์ แล้วรอประมาณหนึ่งนาทีครับ ระหว่างรอ ผมอยากให้คุณเตรียมตอบคำถามสามข้อนี้จากหน้าจอของตัวเอง

ข้อแรก กล่องบนสุดที่เขียนว่า "ดูประสบการณ์ที่ผู้ใช้งานจริงได้รับ" มีตัวเลขขึ้นไหม หรือขึ้นข้อความว่าข้อมูลไม่เพียงพอ ข้อสอง ถ้ามีตัวเลข บรรทัด "การประเมิน Core Web Vitals" เขียนว่าผ่านหรือไม่ผ่าน ข้อสาม วงกลมคะแนน Performance ที่อยู่ถัดลงมา ได้กี่คะแนน

แล้วลองกดวิเคราะห์ซ้ำอีกรอบ ดูว่าคำตอบข้อไหนเปลี่ยน ข้อไหนเหมือนเดิม

ถ้าคุณทำตามนี้ คุณจะเห็นด้วยตาตัวเองว่าข้อหนึ่งกับข้อสองแทบไม่ขยับ ส่วนข้อสามอาจกระโดดไปหลายสิบคะแนน ความต่างตรงนี้แหละครับคือหัวใจของการอ่านรายงานทั้งฉบับ

รายงาน PageSpeed Insights หน้าเดียว แต่มีสองชั้นที่เล่าเรื่องต่างกัน

Google อธิบายไว้ตรงๆ ในเอกสารเกี่ยวกับ PageSpeed Insights ว่ารายงานมีข้อมูลสองประเภท ข้อมูลภาคสนาม (field data) มาจากผู้ใช้จริงที่เข้าเว็บด้วยอุปกรณ์และเครือข่ายที่หลากหลาย ส่วนข้อมูลห้องทดลอง (lab data) มาจากการจำลองโหลดหน้าเว็บบนอุปกรณ์เครื่องเดียว ด้วยเงื่อนไขเครือข่ายที่ตั้งไว้ตายตัว และในเอกสารเดียวกันก็เขียนไว้เลยว่าค่าของสองแบบนี้อาจไม่ตรงกัน

ชั้นบน สมุดบันทึกจากผู้ใช้จริง

กล่องบนสุดคือข้อมูลภาคสนามครับ ตัวเลขมาจาก Chrome User Experience Report หรือที่เรียกสั้นๆ ว่า CrUX ซึ่งเอกสารของ Chromeอธิบายว่าเป็นชุดข้อมูลที่สะท้อนประสบการณ์ของผู้ใช้ Chrome ในโลกจริง ตัวเลขชุดนี้เก็บย้อนหลัง 28 วัน ไม่ได้วัดตอนที่คุณกดปุ่ม นี่คือเหตุผลที่กดกี่รอบก็ได้ตัวเลขเดิม เพราะมันคือสมุดบันทึกทั้งเดือน

ในกล่องนี้จะมีสามตัวหลักที่เรียกรวมกันว่า Core Web Vitals คือ LCP (หน้าเว็บแสดงเนื้อหาหลักเสร็จเร็วแค่ไหน) INP (กดปุ่มแล้วหน้าจอตอบสนองไวแค่ไหน) และ CLS (หน้าเว็บกระตุกเลื่อนไปมาระหว่างโหลดมากแค่ไหน) เกณฑ์ที่ web.dev กำหนดไว้ในบทความ Web Vitals คือ LCP ภายใน 2.5 วินาที INP ไม่เกิน 200 มิลลิวินาที และ CLS ไม่เกิน 0.1 โดยวัดที่เปอร์เซ็นไทล์ที่ 75 แยกมือถือกับเดสก์ท็อป

คำว่าเปอร์เซ็นไทล์ที่ 75 ฟังดูวิชาการ แต่แปลเป็นภาษาบ้านๆ ได้ว่า ถ้ามีคนเข้าเว็บคุณ 100 ครั้ง ให้เรียงจากเร็วไปช้า แล้วดูครั้งที่ 75 ถ้าครั้งนั้นยังอยู่ในเกณฑ์ดี แปลว่าคนส่วนใหญ่ได้ประสบการณ์ดี เอกสาร PageSpeed Insights ระบุว่าจะผ่านการประเมิน Core Web Vitals ได้ ค่าที่เปอร์เซ็นไทล์ที่ 75 ของทั้งสามตัวต้องอยู่ในเกณฑ์ดีทั้งหมด ตัวไหนตัวหนึ่งหลุด ก็ขึ้นว่าไม่ผ่าน (ยกเว้นกรณีข้อมูล INP ไม่พอ ระบบจะตัดสินจาก LCP กับ CLS สองตัว)

ชั้นนี้คือส่วนที่สะท้อนประสบการณ์ลูกค้าของคุณจริงๆ ครับ และเป็นชั้นที่ควรให้น้ำหนักมากที่สุดเวลาจะตัดสินใจเรื่องเงิน

ชั้นล่าง การวัดครั้งเดียวในห้องทดลอง

วงกลมคะแนน Performance 0 ถึง 100 ที่ทุกคนจ้องมอง มาจากเครื่องมือชื่อ Lighthouse ที่ Google เปิดเว็บคุณขึ้นมาหนึ่งครั้งบนเครื่องจำลอง ในรายงานจะเขียนกำกับไว้ตัวเล็กๆ ครับ ถ้าเป็นแท็บมือถือ ตอนที่ผมทดสอบจะขึ้นว่าจำลองเครื่อง Moto G Power ผ่านเครือข่าย 4G แบบช้า ซึ่งเป็นโทรศัพท์ระดับกลางบนเน็ตช้า และอาจช้ากว่ามือถือที่ลูกค้าของคุณใช้จริงอยู่พอสมควร

ช่วงสีของคะแนนนี้ เอกสารของ Google แบ่งไว้ว่า 90 ขึ้นไปคือดี 50 ถึง 89 คือควรปรับปรุง และต่ำกว่า 50 คือแย่ ส่วนคะแนนคำนวณจากห้าตัวชี้วัดถ่วงน้ำหนักกัน ตามเอกสารการให้คะแนนของ Lighthouse Total Blocking Time มีน้ำหนักมากที่สุดที่ 30% ตามด้วย LCP และ CLS อย่างละ 25% ส่วน First Contentful Paint กับ Speed Index อย่างละ 10%

สังเกตไหมครับว่าในห้าตัวนี้ไม่มี INP เลย เหตุผลเขียนไว้ชัดในบทความ Web Vitals ว่าเครื่องมืออย่าง Lighthouse ที่โหลดหน้าเว็บในสภาพจำลองโดยไม่มีคนกดอะไร วัด INP ไม่ได้ เพราะไม่มีการกดของผู้ใช้เกิดขึ้น พูดง่ายๆ คือตัวชี้วัดหนึ่งในสามตัวที่ Google ใช้ตัดสินจริง ไม่ได้อยู่ในวงกลมคะแนนที่คุณเห็นเลย

แล้วทำไมคะแนนชั้นล่างถึงแกว่ง เอกสารของ Lighthouse ยกตัวอย่างสาเหตุไว้หลายข้อ ทั้ง A/B test หรือโฆษณาที่เปลี่ยนไปในแต่ละครั้ง การเปลี่ยนเส้นทางของอินเทอร์เน็ต การทดสอบบนอุปกรณ์ต่างกัน ส่วนเอกสาร PageSpeed Insights ก็บอกว่าความแปรปรวนมาจากเครือข่าย ฮาร์ดแวร์ และการแย่งทรัพยากรของเครื่องที่ใช้ทดสอบ เหมือนวัดความดันตอนใจยังเต้นแรงนั่นแหละครับ

ตอนที่ขึ้นว่าข้อมูลผู้ใช้จริงไม่เพียงพอ

เว็บ SME จำนวนมากจะเจอข้อความนี้ในกล่องบนสุด และหลายคนเข้าใจผิดว่าเว็บมีปัญหา จริงๆ แล้วมันแค่บอกว่า CrUX ยังเก็บข้อมูลของหน้านี้ได้ไม่มากพอ เอกสารของ Chrome ระบุว่าหน้าเว็บจะมีข้อมูลใน CrUX ได้ ต้องเป็นหน้าที่ค้นพบได้แบบสาธารณะ และมีผู้เข้าชมมากพอจะทำเป็นสถิติที่เชื่อถือได้

เมื่อหน้าใดหน้าหนึ่งมีข้อมูลไม่พอ PageSpeed Insights จะถอยไปใช้ข้อมูลระดับต้นทาง (origin) ซึ่งหมายถึงประสบการณ์ของผู้ใช้ทุกหน้าในเว็บรวมกัน ถ้าทั้งเว็บยังมีข้อมูลไม่พออีก กล่องนี้ก็จะว่างไปเลย สำหรับเว็บธุรกิจขนาดเล็กที่คนเข้าไม่เยอะ เรื่องนี้ปกติมากครับ ไม่ได้แปลว่าเว็บช้าหรือเร็ว แค่แปลว่าสมุดบันทึกยังมีหน้าไม่พอให้อ่าน

ในกรณีนี้ ชั้นล่างคือสิ่งเดียวที่คุณมี ก็ใช้ได้ครับ แต่ให้ใช้แบบรู้ตัว คือกดวัดหลายรอบแล้วดูภาพรวม อย่าตัดสินจากรอบเดียว

ส่วนวินิจฉัยด้านล่างสุด

เลื่อนลงไปใต้วงกลมคะแนน จะเจอรายการยาวเหยียดในหัวข้อข้อมูลเชิงลึกและการวินิจฉัย เช่น ลดจำนวน JavaScript ที่ไม่ได้ใช้ ปรับปรุงการนำส่งรูปภาพ คำขอบล็อกการแสดงผล พร้อมตัวเลขว่าประหยัดได้กี่ KiB หรือกี่มิลลิวินาที

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

ยกตัวอย่างจากรายงานมือถือของเว็บเราเองในวันที่ทดสอบ รายการที่อยู่บนสุดคือคำขอบล็อกการแสดงผล ซึ่งรายงานประเมินว่าประหยัดเวลาได้ราว 340 มิลลิวินาที ถัดมาคือปรับปรุงการนำส่งรูปภาพ ประหยัดพื้นที่ได้ราว 122 KiB สองบรรทัดนี้คือสิ่งที่ผมจะส่งให้ทีมดูก่อน ส่วนรายการใช้อายุการใช้งานแคชที่มีประสิทธิภาพที่ประหยัดได้แค่ 4 KiB ผมปล่อยไว้ท้ายคิวได้สบายๆ ครับ

ตัวเลขจริงจากเว็บของเราเอง บ่ายวันที่ 28 กันยายน 2569

พูดทฤษฎีมาเยอะแล้ว ผมขอเปิดรายงานของเว็บ tumwebsme.com เองให้ดูแบบไม่ตัดต่อครับ วันนี้ผมกดวิเคราะห์หน้าแรกสองรอบ ห่างกันประมาณห้านาที ไม่มีใครแก้อะไรในเว็บระหว่างนั้น

รอบแรกเวลา 13:39 น. คะแนน Performance บนมือถือได้ 68 บนเดสก์ท็อปได้ 65 ถ้าเป็นเจ้าของเว็บทั่วไปเห็นเลขนี้ คงใจหายไปพอสมควร

รอบที่สองเวลา 13:44 น. มือถือขึ้นเป็น 89 เดสก์ท็อปขึ้นเป็น 94 เว็บเดิม หน้าเดิม ห่างกันห้านาที

ถ้าไล่ดูข้างใน ตัวที่แกว่งหนักที่สุดคือ Total Blocking Time ของเดสก์ท็อป รอบแรกวัดได้ 1,700 มิลลิวินาที รอบที่สองเหลือ 190 มิลลิวินาที และเพราะตัวนี้มีน้ำหนัก 30% ของคะแนน คะแนนทั้งก้อนจึงกระโดดตาม

ทีนี้มาดูชั้นบนกันบ้าง ทั้งสองรอบกล่องข้อมูลผู้ใช้จริงขึ้นตัวเลขชุดเดียวกัน เพราะเป็นข้อมูลเก็บสะสม 28 วัน (ช่วงวันที่ 30 ส.ค. ถึง 26 ก.ย. 2569) และหน้าแรกของเราเองมีข้อมูลระดับ URL ไม่พอ รายงานจึงถอยไปใช้ข้อมูลทั้งเว็บ (origin) แทน ตรงกับที่อธิบายไว้ด้านบนพอดี

บนเดสก์ท็อป ผลประเมิน Core Web Vitals ผ่าน LCP อยู่ที่ 1.4 วินาที INP อยู่ที่ 87 มิลลิวินาที CLS อยู่ที่ 0.01 ซึ่งแปลว่าคะแนน 65 ในรอบแรกไม่ได้สะท้อนสิ่งที่ลูกค้าบนคอมพิวเตอร์เจอจริงเลย

ถ้ากดขยายมุมมองในกล่องนี้ จะเห็นแถบสีที่แบ่งผู้ใช้ออกเป็นสามช่วงด้วยครับ ของเดสก์ท็อปเรา LCP อยู่ในช่วงดี 94% ช่วงต้องปรับปรุง 4% และช่วงแย่ 1% แถบนี้อ่านง่ายกว่าตัวเลขตัวเดียวมาก เพราะบอกได้ว่าลูกค้ากี่ส่วนเจอประสบการณ์แบบไหน ในกรณีนี้คือมีลูกค้าส่วนน้อยมากที่รอหน้าเว็บนานเกิน 4 วินาที

ส่วนบนมือถือ ผลประเมินไม่ผ่านครับ ผมไม่ขอเลี่ยงเรื่องนี้ LCP อยู่ที่ 3.2 วินาที เกินเกณฑ์ 2.5 วินาที อยู่ในช่วงต้องปรับปรุง และ INP อยู่ที่ 550 มิลลิวินาที ซึ่งเกินเกณฑ์ 200 มิลลิวินาทีไปเยอะ ส่วน CLS อยู่ที่ 0 ไม่มีปัญหา

บทเรียนที่ผมอยากให้เห็นจากตัวเลขชุดนี้ คือคะแนนมือถือรอบที่สองได้ 89 เกือบเขียวแล้ว ถ้าดูแค่วงกลม เราคงคิดว่าเว็บใกล้สมบูรณ์ แต่ปัญหาจริงของเราบนมือถือคือ INP ซึ่งวงกลมคะแนนวัดไม่ได้ตั้งแต่แรก ถ้าวันนี้เราจ้างใครสักคนมาดันวงกลมให้เป็น 100 ได้ ปัญหาที่ลูกค้ามือถือเจอจริงก็อาจยังอยู่ที่เดิม งานถัดไปของทีมเราจึงเป็นการไล่หาว่าปุ่มหรือสคริปต์ตัวไหนทำให้หน้าจอตอบสนองช้าบนมือถือ

"แต่เลขแดงก็แปลว่าเว็บช้าไม่ใช่เหรอ"

เป็นคำถามที่ผมได้ยินบ่อยที่สุด และต้องบอกว่ามีส่วนถูกจริงครับ ผมไม่เถียงเลย ถ้าวงกลมเป็นสีแดงซ้ำๆ ทุกครั้งที่กด ไม่ว่าจะกดกี่รอบก็ไม่ขึ้นมาเกิน 50 นั่นคือสัญญาณที่ควรใส่ใจแน่นอน และคะแนนห้องทดลองก็มีประโยชน์มาก เพราะมันบอกช่างได้ว่าปัญหาน่าจะอยู่ตรงไหน ข้อมูลภาคสนามบอกได้แค่ว่าลูกค้าเจออะไร แต่ไม่บอกว่าเพราะอะไร

สิ่งที่ผมอยากชวนให้ระวังคือการเอาคะแนนรอบเดียวมาเป็นเหตุผลในการจ่ายเงิน โดยเฉพาะเมื่อชั้นบนของรายงานบอกว่าผ่านอยู่แล้ว เอกสาร Lighthouse มีประโยคหนึ่งที่ผมชอบมาก คือการดันคะแนนจาก 99 เป็น 100 ต้องปรับตัวชี้วัดพอๆ กับการดันจาก 90 เป็น 94 ยิ่งเข้าใกล้ 100 ยิ่งเหนื่อยขึ้นเรื่อยๆ และลูกค้าที่เข้าเว็บคุณอาจไม่รู้สึกถึงความต่างนั้นเลย

ถ้าอยากเข้าใจว่าความเร็วเว็บส่งผลกับ SEO และยอดขายแค่ไหน และแนวทางทำให้เว็บเร็วขึ้นมีอะไรบ้าง ผมเล่าไว้ละเอียดในบทความเรื่องความเร็วเว็บกับ SEOครับ

ทำไมอ่านเป็นตั้งแต่วันนี้ถึงคุ้มกว่ารอให้มีปัญหา

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

อีกเรื่องคือ คนที่อ่านรายงานเป็นจะคุยกับทีมทำเว็บได้เร็วขึ้นมาก แทนที่จะส่งภาพหน้าจอวงกลมสีแดงไปพร้อมคำว่า "ช่วยทำให้เร็วขึ้นหน่อย" คุณส่งได้เลยว่า INP บนมือถือไม่ผ่าน ส่วนเดสก์ท็อปผ่านแล้ว ทีมจะรู้ทันทีว่าต้องไปดูตรงไหน งานสั้นลง ค่าใช้จ่ายก็มักจะแคบลงตาม

สิ่งที่เจ้าของเว็บตัดสินเองได้ในสามบรรทัด

ถ้าไม่มีเวลาอ่านทั้งรายงาน ขอแค่สามเรื่องนี้พอครับ เริ่มจากกล่องบนสุดก่อนเสมอ ถ้ามีข้อมูลและขึ้นว่าผ่าน ทั้งบนมือถือและเดสก์ท็อป เว็บคุณอยู่ในเกณฑ์ที่ Google ถือว่าดีแล้ว ไม่ต้องตกใจกับวงกลมด้านล่าง

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

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

ตัวอย่างเครื่องมือที่ใช้ข้อมูลชุดเดียวกัน

ข้อมูลผู้ใช้จริงชุดเดียวกับกล่องบนสุดของ PageSpeed Insights ไปโผล่ในอีกหลายที่ที่คุณอาจใช้อยู่แล้ว ที่ใกล้ตัวที่สุดคือรายงาน Core Web Vitals ใน Google Search Console ซึ่งจัดกลุ่ม URL ที่มีปัญหาคล้ายกันไว้ให้ ดูได้ทั้งเว็บในหน้าเดียว ไม่ต้องกดทีละหน้า ถ้ายังไม่เคยเปิด Search Console ลองอ่านคู่มือ Google Search Console สำหรับมือใหม่ประกอบได้ครับ

ส่วนชั้นล่าง Lighthouse ตัวเดียวกันนี้ฝังอยู่ใน Chrome DevTools ของทุกเครื่อง ทีมทำเว็บส่วนใหญ่จะเปิดวัดจากตรงนั้นระหว่างแก้งาน ซึ่งคะแนนก็จะต่างจาก PageSpeed Insights ได้อีก เพราะเครื่องและเครือข่ายที่วัดคนละตัวกัน เป็นเรื่องปกติครับ

และอีกเรื่องที่ควรรู้ ถ้ากล่องบนสุดชี้ว่า TTFB หรือเวลาที่เซิร์ฟเวอร์ตอบกลับครั้งแรกช้า ต้นเหตุอาจอยู่ที่โฮสติ้งมากกว่าตัวหน้าเว็บ ผมเขียนเรื่องคำถามที่ควรถามก่อนเซ็นสัญญาโฮสติ้งไว้ในบทความวิธีอ่านใบเสนอราคาโฮสติ้งครับ

แผนห้าขั้นก่อนจ่ายค่า speed optimisation

1. วัดตั้งต้น: เปิด PageSpeed Insights วัดหน้าแรกและหน้าที่ลูกค้าเข้าบ่อยที่สุด ทั้งแท็บมือถือและเดสก์ท็อป บันทึกภาพหน้าจอกล่องบนสุดพร้อมช่วงวันที่เก็บข้อมูลไว้

2. วัดชั้นล่างหลายรอบ: กดวิเคราะห์ซ้ำสามถึงห้ารอบ จดคะแนนทุกรอบลงตาราง จะได้เห็นว่าเว็บคุณแกว่งกว้างแค่ไหน

3. สรุปโจทย์เป็นประโยคเดียว: เช่น "INP บนมือถือไม่ผ่าน LCP ผ่าน" แทนคำว่า "เว็บช้า"

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

5. ตกลงเกณฑ์วัดผลก่อนเริ่มงาน: ให้ผลงานวัดจากข้อมูลผู้ใช้จริงหลังผ่านไปอย่างน้อย 28 วัน ไม่ใช่จากวงกลมคะแนนรอบเดียวในวันส่งงาน

จะวัดยังไงว่างานที่จ่ายไปได้ผล

หลังทีมทำเว็บแก้เสร็จ ให้กลับมาเปิดกล่องบนสุดอีกครั้งเมื่อผ่านไปราว 28 วัน เทียบกับภาพหน้าจอตั้งต้น ตัวที่เคยไม่ผ่านควรขยับเข้าใกล้หรือเข้าเกณฑ์ดี และดูในรายงาน Core Web Vitals ของ Search Console ด้วยว่าจำนวน URL ที่อยู่ในกลุ่มดีเพิ่มขึ้นหรือเปล่า

ส่วนวงกลมคะแนนด้านล่าง ถ้าหลังแก้แล้วกดหลายรอบได้ค่ากลางสูงขึ้นก็ถือเป็นสัญญาณดีครับ แต่ให้ถือเป็นหลักฐานเสริม ไม่ใช่ตัวตัดสิน

ถ้าคุณกำลังเตรียมทำเว็บใหม่และอยากรู้ว่าแต่ละแพ็กเกจของเราดูแลเรื่องประสิทธิภาพเว็บไว้แค่ไหน ดูรายละเอียดได้ที่หน้าแพ็กเกจทำเว็บไซต์ของ TumWebSMEครับ

ส่งท้าย

กลับมาที่ห้องตรวจสุขภาพอีกครั้งนะครับ ตัวเลขความดันตอนเพิ่งเดินขึ้นบันได ไม่ได้โกหกเรา มันแค่เล่าเรื่องของห้านาทีนั้น ส่วนสมุดจดความดันทั้งเดือน คือสิ่งที่คุณหมอใช้ตัดสินใจว่าจะรักษาอะไร รายงาน PageSpeed Insights ก็เหมือนกัน วงกลมคะแนนคือตัวเลขห้านาที กล่องบนสุดคือสมุดบันทึกของลูกค้าคุณ อ่านสมุดก่อน แล้วค่อยใช้ตัวเลขห้านาทีช่วยหาสาเหตุ

ถ้าคุณเปิดรายงานของเว็บตัวเองแล้วยังไม่แน่ใจว่าควรอ่านตรงไหนก่อน ส่งภาพหน้าจอมาคุยกับเราได้เลยครับ เราจะช่วยดูว่าตัวเลขชุดนั้นกำลังเล่าอะไร และเรื่องไหนควรทำก่อนหลัง

ช่องทางการติดตาม TumWebSME

ติดตามสาระความรู้เรื่องการทำเว็บไซต์และการตลาดออนไลน์ได้ที่:

• Facebook: TumWebSME รับทำเว็บไซต์ธุรกิจ

• Instagram: @tumwebsme

• TikTok: @tumwebsme

• YouTube: TumWebSME

ติดต่องานและสอบถามบริการ

• 088-983-9386 (คุณพลอย)

• 099-856-3198 (คุณแสนนาน)