เกณฑ์ใหม่ของ Google: Core Web Vitals
เผยแพร่แล้ว: 2020-12-01อัปเดตเมื่อ พฤษภาคม 2021
ในการทำการตลาด SEO บริษัท บล็อก เว็บไซต์ และแพลตฟอร์มออนไลน์แข่งขันกันทุกวัน อันดับต้น ๆ ของรายการ Google คือที่ที่พวกเขาต้องการ
จากรายชื่อนับไม่ถ้วนใน Google 90% ของเว็บไซต์ที่อยู่ในรายการไม่เคยไปที่หน้าแรก 10% ที่ทำคือโฆษณาแบบชำระเงิน กราฟความรู้ และรายชื่อทั่วไปประมาณ 10 รายการ การจราจรในหมู่พวกเขาไม่สม่ำเสมอ ผู้ใช้เว็บไม่ถึง 3% ได้ผลลัพธ์ในหน้าติดตามผล
จนถึงตอนนี้ กลไกการตลาด SEO ที่มีอิทธิพลหลัก ๆ ได้แก่ หัวข้อ เนื้อหา แท็กชื่อ คีย์เวิร์ด คำอธิบายรูปภาพ ลิงก์ภายใน ลิงก์ย้อนกลับ ฯลฯ โดยเน้นที่การควบคุมคุณภาพ เครื่องยนต์แมมมอธ Google จะแยกส่วนในใหม่ จำเป็น.
Core Web Vitals จะกลายเป็นองค์ประกอบที่กำหนดของ หน่วยงานด้านเทคนิค SEO ใน สหรัฐอเมริกา นอกจากนี้ยังสามารถคาดหวังและมีแนวโน้มที่จะกำหนดผลการค้นหาใหม่ ในขณะที่การตลาด SEO แบบดั้งเดิมครอบคลุมความเกี่ยวข้อง ระยะทาง และความโดดเด่น Core Web Vitals จะยึดมูลค่าไว้
สารบัญ
- Core Web Vitals คืออะไร?
- องค์ประกอบสามประการของ Core Web Vitals
- ระบายสีเนื้อหาที่ใหญ่ที่สุด
- ความล่าช้าในการป้อนข้อมูลครั้งแรก
- เลื่อนเค้าโครงสะสม
- Core Web Vital Metrics
- เครื่องมือวิเคราะห์ Core Web Vitals
- เหตุใดการเพิ่มประสิทธิภาพ Core Web Vitals จึงสำคัญ
- บทสรุป
Core Web Vitals คืออะไร?
Core Web Vitals เป็นชุดเมตริกที่แยกจากกันที่กำหนดประสบการณ์ผู้ใช้ (UX) บนเว็บไซต์ หลังรวมการวัดความเร็วเพจและการโต้ตอบกับโหนดไคลเอ็นต์ที่แตกต่างกันสามแบบ การสะสมของปัจจัยเหล่านี้จะปรากฏในระบบการให้คะแนนซึ่งกำหนดลำดับความสำคัญที่หน้าจะได้รับเป็นรายการ
สามองค์ประกอบของ Core Web Vitals
ระบายสีเนื้อหาที่ใหญ่ที่สุด
Largest Contentful Paint (LCP) คือการวัดที่สร้างขึ้นโดย Google เพื่อให้ผู้ใช้พึงพอใจ พารามิเตอร์นี้เน้นที่ประสิทธิภาพมากกว่าการนำเสนอ หากหน้าเว็บใช้เวลาในการโหลดนานเกินไปและนักท่องเว็บออกไป ถือว่าไม่น่าพอใจ
เวลาในการโหลดหน้าเว็บและปัจจัยประสบการณ์ของ Google เช่น แท็กรูปภาพและภาพขนาดย่อของวิดีโอเป็นตัวกำหนดการจัดประเภท LCP ภาพพื้นหลังที่มี CSS และองค์ประกอบข้อความ เช่น ย่อหน้า หัวเรื่อง และรายการจะได้รับการตรวจสอบเพื่อความคล่องแคล่ว
สาเหตุของ LCP ที่ไม่ดี
เวลาตอบสนองของเซิร์ฟเวอร์ช้า
ความเร็วในการแสดงผลของเว็บไซต์ขึ้นอยู่กับเวลาตอบสนองของเซิร์ฟเวอร์ ยิ่งเซิร์ฟเวอร์ทำงานช้าลง การแสดงอะไรบนหน้าจอของอุปกรณ์ก็จะยิ่งนานขึ้นเท่านั้น
วิธีแก้ปัญหาหลักที่นี่คือการปรับเซิร์ฟเวอร์ของคุณให้เหมาะสม การแคชสินทรัพย์และการให้บริการ HTML แคชก่อนจะเร่งกระบวนการบริการ นอกจากนี้ ขอแนะนำให้กำหนดเส้นทางผู้ใช้ไปยัง CDN ที่อยู่ใกล้เคียง ด้วยการสร้างการเชื่อมต่อจากบุคคลที่สามตั้งแต่เนิ่นๆ เวลาแฝงจะน้อยที่สุด ซึ่งเป็นสิ่งสำคัญสำหรับเว็บไซต์ที่ตอบสนองต่ออุปกรณ์เคลื่อนที่
การบล็อกการแสดงผล CSS และ JavaScript
เบราว์เซอร์ส่งเนื้อหาโดยแยกวิเคราะห์มาร์กอัป HTML ลงในแผนผัง DOM หาก parser พบสไตล์ชีตภายนอกใด ๆ โปรแกรมจะหยุดชั่วคราว สคริปต์และสไตล์ชีตภายนอกชะลอการกระจายทรัพยากรการบล็อก, FCP และ LCP ในท้ายที่สุด
CSS และ Java นั้นแข็งแกร่งและสามารถสูญเสีย “น้ำหนักได้มาก” ผ่านการเคารพ การย่อขนาด และการลดขนาด ซอฟต์แวร์ที่มีให้สำหรับการบดอัด Java ได้แก่ UglifyJS2, Closure Compiler และ YUI Compressor CSSnano, UNCSS และ CSSO เป็นกลไกทั้งหมดที่สามารถบีบอัด CSS ได้ เวลาของการเพิ่มประสิทธิภาพการโหลดจะดีขึ้นด้วยการปรับใช้เครื่องมือเหล่านี้
เวลาในการโหลดทรัพยากรไม่ดี
แม้ว่าการเพิ่มขึ้นของกิจกรรม CSS และ JavaScript ทำให้เกิดผลลัพธ์ที่ไม่ดี แต่องค์ประกอบอื่นๆ ก็พิสูจน์ได้ว่ามีปัญหาเช่นกัน องค์ประกอบที่ส่งผลเสียต่อ LCP คือ < รูปภาพ >, < img > และ < วิดีโอ > และส่วนประกอบระดับบล็อกที่มีโหนดข้อความ
การเพิ่มประสิทธิภาพและการบีบอัดไฟล์รูปภาพและข้อความจะช่วยได้ที่นี่ โดยการโหลดทรัพยากรที่จำเป็นล่วงหน้าและการแคชสินทรัพย์ ในขณะที่ใช้พนักงานบริการอื่น เวลาที่จำเป็นจะลดลง
การแสดงผลสิ้นสุดของผู้ใช้
ไซต์ที่แสดงผลส่วนใหญ่ในฝั่งไคลเอ็นต์สูญเสียการควบคุมอย่างยุติธรรม ข้อเสียของตัวเลือกนี้จะเห็นได้ชัดเมื่อใช้กลุ่ม JavaScript ขนาดใหญ่ ในกรณีส่วนใหญ่ เนื้อหาจะไม่แสดงจนกว่า JavaScript จะเรนเดอร์เสร็จ มันจะเป็นอันตรายต่อการจัดอันดับ LCP
การย่อขนาด JavaScript ให้เล็กสุดเป็นสิ่งสำคัญ และการเรนเดอร์ส่วนปลายของเซิร์ฟเวอร์นั้นดีกว่าฝั่งผู้ใช้ อีกวิธีหนึ่งคือการแสดงผลล่วงหน้าซึ่งจะช่วยในเรื่องเวลาในการโหลดให้เหมาะสม
ความล่าช้าในการป้อนข้อมูลครั้งแรก
First Input Delay (FID) วัดเวลาจากการโต้ตอบของผู้ใช้ครั้งแรกจนถึงเวลาที่เบราว์เซอร์ตอบสนอง เป็นปัจจัยสำคัญที่ลูกค้าจะออกจากไซต์หรือไม่ ความล่าช้ามักเกิดขึ้นเมื่อเธรดหลักของเบราว์เซอร์ไม่ว่าง
ไฟล์ JavaScript ที่โหลดโดยแอพในเครื่องมักจะถูกตำหนิสำหรับปัญหา FID สิ่งที่เกิดขึ้นคือเบราว์เซอร์พยายามแยกวิเคราะห์และดำเนินการ แต่เกิดความหน่วงแฝง ส่งผลให้อุปกรณ์ปลายทางไม่ตอบสนอง การให้คะแนน FID ที่ต่ำอาจทำให้แน่ใจได้ว่าไซต์หรือหน้าที่เป็นปัญหานั้นใช้ไม่ได้
สาเหตุของ FID ที่ไม่ดี
JavaScript
โดยทั่วไป ในขณะที่เธรดหลักไม่ว่าง เบราว์เซอร์ไม่สามารถตอบสนองต่อการโต้ตอบได้ การดำเนินการ JavaScript จำนวนมากทำให้เกิดปัญหานี้ซึ่งทำให้เกิดความล่าช้าในความเร็วในการโหลด
การแบ่งงานที่ยาวนานจะช่วยบรรเทางานในมือได้ นอกจากนี้ การจำกัดรันไทม์ของ JavaScript ควรปรับปรุงการตอบสนอง การใช้ผู้ปฏิบัติงานเว็บก็มีประโยชน์เช่นกัน ทั้งหมดนี้เป็นวิธีการเพิ่มประสิทธิภาพเมตริกของเว็บไซต์เพื่อการโต้ตอบ
เลื่อนเค้าโครงสะสม
ตัวชี้วัด Cumulative Layout Shift (CLS) จะวัดความเสถียรของการออกแบบหน้าเว็บ มันทำงานเพื่อให้แน่ใจว่าการโต้ตอบกับลูกค้าเป็นไปอย่างเป็นธรรมชาติมากที่สุด นักท่องเว็บมักประสบปัญหาการหยุดชะงักหรือกระโดดข้ามขณะดูเนื้อหาบนไซต์ ดังนั้นจึงนำไปสู่การขาดสมาธิและสร้างประสบการณ์ที่ไม่ดี
ความไม่สะดวกเป็นผลมาจากการออกแบบที่อ่อนแอ ผลกระทบจะมีผลกับเว็บไซต์ที่ตอบสนองต่อมือถือและเบราว์เซอร์เดสก์ท็อป
การขาดองค์ประกอบการออกแบบที่ถูกต้องทำให้เกิดความไม่มั่นคงทางสายตา อย่างหลังมีแนวโน้มที่จะบังคับให้เปลี่ยนเลย์เอาต์กะทันหัน หลายครั้งทำให้ผู้ใช้คลิกเนื้อหาที่ไม่ต้องการโดยไม่ได้ตั้งใจ ตัวอย่างทั่วไปคือเว็บไซต์ที่มีโฆษณาป๊อปอัป
การออกแบบใหม่ แม้ว่าจะมีโครงสร้างที่ถูกต้อง แต่ก็อาจทำให้หน้าเว็บช้าลงได้ อัลกอริทึมของ Google จะชดเชยโดยอนุญาตให้ละเว้น 500ms ก่อนเริ่มกระบวนการคำนวณ
สาเหตุทั่วไปของ CLS
รูปภาพไม่มีขนาด
การยกเว้นแอตทริบิวต์ขนาดความกว้างและความสูงสำหรับทั้งวิดีโอและภาพจะส่งผลให้มีอันดับต่ำ หลายคนไม่จองพื้นที่สำหรับสื่อ ซึ่งส่งผลให้เกิดการก้าวกระโดดและการเปลี่ยนแปลง
วิธีแก้ปัญหาที่นี่ง่าย รวมความกว้างและความสูงเสมอ อีกตัวเลือกหนึ่งคือกล่องอัตราส่วนกว้างยาว CSS มีประโยชน์สำหรับการจองพื้นที่บนเว็บไซต์ มีประโยชน์อย่างยิ่งกับไซต์ที่โฮสต์โฆษณา
โฆษณา การฝัง และ Iframes ที่ไม่มีมิติ
โฆษณามีส่วนสนับสนุนอย่างมากในประเด็นนี้ เครือข่ายโฆษณาเลือกใช้การปรับขนาดแบบไดนามิกซึ่งต่างจากรูปแบบคงที่ซึ่งเพิ่มการเข้าชมเว็บไซต์ น่าเสียดายที่สิ่งนี้เป็นค่าใช้จ่ายของประสบการณ์เดสก์ท็อปหรือมือถือ
วิดเจ็ตบางอย่างอนุญาตให้ฝังรายการต่างๆ เช่น วิดีโอ แผนที่ และเนื้อหาโซเชียลมีเดียลงในหน้าเว็บได้ ปัญหาคือเว็บไซต์มักไม่ทราบขนาดที่แน่นอนหรือองค์ประกอบของการฝัง หากไม่จองพื้นที่ ความไม่เสถียรจะปรากฏชัดเจนเมื่อโหลดหน้าเว็บ
การคำนวณล่วงหน้าของความต้องการเชิงพื้นที่ที่จำเป็นสำหรับการฝังหรือทางเลือกไซต์ช่วยหลีกเลี่ยงอันตรายจาก CLS เครื่องมือสำหรับนักพัฒนาเบราว์เซอร์มีประโยชน์ในการรับความสูงและความกว้างของผลลัพธ์ หลังจากสร้างสิ่งนี้ iframe จะพอดีกับพื้นที่ที่สงวนไว้โดยอัตโนมัติทุกครั้งที่โหลดหน้า
เนื้อหาที่ฉีดแบบไดนามิก
รายการที่แทรกใหม่ทับสื่อเก่ายังเป็นสิ่งที่สร้างการเลื่อนเลย์เอาต์ ตัวอย่างทั่วไปของสิ่งเหล่านี้คือแบนเนอร์คำกระตุ้นการตัดสินใจ พวกมันไม่เพียงแต่ปิดกั้นปฏิสัมพันธ์เท่านั้น แต่ยังสร้างความรำคาญมากกว่าที่จะโน้มน้าวใจ
อีกครั้งจองพื้นที่ นอกจากนี้ ผู้ออกแบบเว็บไซต์สามารถเพิ่มโครงร่าง UI ได้ หลังเป็นตัวยึดตำแหน่งที่จะป้องกันไม่ให้ข้อความย้ายเมื่อโหลดรูปภาพ
แบบอักษรเว็บทำให้เกิด FOIT/FOUT
การดาวน์โหลดและแสดงแบบอักษรของเว็บเป็นเครื่องมือใน Flash ของ Unstyled Text (FOUT) ในกรณีนี้ รูปแบบใหม่จะแทนที่การพิมพ์สำรอง
ผลที่ตามมาเพิ่มเติมคือ Flash of Invisible Text (FOIT) ซึ่งจะซ่อนแบบอักษรจนกว่าจะมีกรณีใหม่
Font Loading API ช่วยลดเวลาที่ต้องใช้เพื่อให้ได้รูปแบบตัวอักษรที่จำเป็น ดังนั้นจึงลดหรือขจัดการเกิด FOUT และ FOIT
Core Web Vital Metrics
ตามที่ระบุไว้ องค์ประกอบ Core Web Vital ทั้งสามองค์ประกอบมีการวัดแยกกัน แต่ละคนให้คะแนนตามมาตรฐานเวลาที่แตกต่างกัน
- คะแนน LCP ที่ดีนั้นน้อยกว่า 2.5 วินาที Google จะยอมผ่อนปรนสำหรับทุกอย่างที่อายุต่ำกว่า 4 ปี แต่ก็ยังหมายความว่ายังมีช่องว่างสำหรับการปรับปรุง
- หน่วยวัดของ FID คือมิลลิวินาที และหากเวลาระหว่างการป้อนข้อมูลของผู้ใช้และปฏิกิริยาของหน้าเว็บต่ำกว่า 100 นี่ถือว่าเหมาะสมที่สุด เมตริก 300ms เป็นที่ยอมรับได้ แต่เป็นการบ่งบอกถึงปัญหาที่จะเกิดขึ้น อะไรที่สูงกว่า 300ms จะนำไปสู่การตกชั้นของรายชื่อเว็บ
- ค่าที่อ่านได้ในอุดมคติสำหรับ CLS คือศูนย์ อัลกอริทึมของ Google จะยอมรับ 0.1 แต่เนื่องจากความสามารถในการยอมรับสูงสุดคือ 0.25 จึงสร้างส่วนต่างที่เล็กเกินไปสำหรับความยืดหยุ่น ผู้ดูแลเว็บไซต์อาจพยายามอย่างเต็มที่เช่นกัน
เครื่องมือวิเคราะห์ Core Web Vitals
- Web Vitals สำหรับ Chrome เหมือนกับส่วนขยายอื่นๆ และบางส่วนอาจไม่สะดวกกับตัวเลือกนี้เนื่องจากข้อกังวลด้านความเป็นส่วนตัว
- ข้อมูลเชิงลึกเกี่ยวกับความเร็วของเพจเป็นอินเทอร์เฟซที่เรียบง่ายซึ่งช่วยให้คุณสลับระหว่างตัวเลือกเดสก์ท็อปและอุปกรณ์เคลื่อนที่ได้ ผลลัพธ์ของพีซีและอุปกรณ์อัจฉริยะจะแตกต่างกันโดยไม่คำนึงถึงซอฟต์แวร์การวิเคราะห์ที่คุณใช้ ข้อมูลดังกล่าวสร้างข้อมูลภาคสนามของผู้ใช้ Google จริงใน 28 วัน
- การออกแบบ Chrome Dev Tools และ Lighthouse ช่วยให้ตรวจสอบ LCP และ CLS ได้ น่าเสียดายที่ซอฟต์แวร์เดียวกันนี้ไม่สามารถวัด FID ได้ แต่มี TBT สำหรับสิ่งนั้น
ในขณะที่ Core Web Vitals แพร่หลายมากขึ้น เครื่องมือตรวจสอบต่างๆ จะถูกผูกไว้กับที่เกิดเหตุ
เหตุใดการเพิ่มประสิทธิภาพ Core Web Vitals จึงสำคัญ
การอัปเดตหลักของ Google มีกำหนดจะเกิดขึ้นในเดือนพฤษภาคม 2021 ซึ่งหมายความว่าจากนี้ไป สัญญาณ SEO ตามปกติจะไม่เพียงพอต่อการรักษาอันดับที่สูงใน Google
เป็นการนำ UX ที่มีคุณภาพมาใช้เป็นมาตรฐาน ไซต์ที่สอดคล้องกับเกณฑ์ใหม่จะไม่ได้รับผลกระทบ หน้าเว็บที่ยังไม่ได้ปรับแต่งจะรู้สึกได้ถึงผลกระทบ แม้ว่า SEO ของพวกเขาจะมีประสิทธิภาพมากเพียงใด รายการที่มี Core Web Vitals ที่อ่อนแอจะลดอันดับลง ทำให้มีที่ว่างสำหรับหน่วยงานที่ปฏิบัติตามข้อกำหนด
บทสรุป
ด้วยการกำหนดกฎระเบียบใหม่ในการทำการตลาด SEO ทำให้ Google ปูทางไปสู่การปรับปรุง มาตรฐาน Core Web Vital เป็นมาตรฐานแรก และยังมีอีกมากมายที่จะตามมาอย่างแน่นอน มาตรการเหล่านี้สร้างแพลตฟอร์มสำหรับยุคใหม่ของอินเทอร์เน็ตที่ผสานเข้ากับเทคโนโลยีเกิดใหม่อย่างไร้ที่ติ นอกจากนี้ คุณสามารถใช้เคล็ดลับเหล่านี้เพื่อเพิ่มความเร็วในการโหลดเว็บไซต์ของคุณ