การปรับปรุง Core Web Vitals กรณีศึกษาของนิตยสารยอดเยี่ยม

“เหตุใด Core Web Vitals ของฉันจึงล้มเหลว” นักพัฒนาหลายคนมักถามคำถามนี้กับตัวเอง บางครั้งการหาคำตอบของคำถามนั้นก็ง่ายพอ และเว็บไซต์ก็จำเป็นต้อง ลงทุนในประสิทธิภาพ แม้ว่าบางครั้งจะดูยุ่งยากกว่าเล็กน้อย และถึงแม้จะคิดว่าไซต์ของคุณมีประสิทธิภาพดีเยี่ยมด้วยเหตุผลบางประการ แต่ก็ยังล้มเหลวอยู่ นั่นคือสิ่งที่เกิดขึ้นกับ smashingmagazine.com ของเราเอง และเมื่อต้องค้นหาและแก้ไข ปัญหาก็ต้องใช้เวลาขุดคุ้ยนิดหน่อย

ร้องขอความช่วยเหลือ

ทุกอย่างเริ่มต้นด้วยชุดทวีตเมื่อเดือนมีนาคมที่ผ่านมาโดยขอความช่วยเหลือ:

นั่นทำให้ฉันสนใจ! ฉันเป็นแฟนตัวยงของ Smashing Magazine และสนใจอย่างมากในด้านประสิทธิภาพของเว็บและ Core Web Vitals ฉันเคยเขียนบทความเกี่ยวกับ Core Web Vitals มาแล้วสองสามบทความ และสนใจที่จะดูว่ามีอะไรอยู่ในรายการตรวจสอบประสิทธิภาพเว็บประจำปีของพวกเขาอยู่เสมอ ดังนั้น Smashing Magazine จึงรู้ดีเกี่ยวกับประสิทธิภาพของเว็บ และหากพวกเขาประสบปัญหา นี่อาจเป็นกรณีทดสอบที่น่าสนใจสำหรับการดู!

พวกเราสองสามคนได้ให้คำแนะนำเกี่ยวกับชุดข้อความว่าปัญหาอาจเกิดขึ้นหลังจากใช้เครื่องมือวิเคราะห์ประสิทธิภาพเว็บที่เราชื่นชอบ เช่น WebPageTest หรือ PageSpeed ​​Insights

การตรวจสอบปัญหา คสช.

ปัญหาคือ LCP บนมือถือช้าเกินไป LCP หรือ Largest Contentful Paint เป็นหนึ่งในสาม Core Web Vitals ที่คุณต้อง "ผ่าน" เพื่อรับการจัดอันดับการค้นหาอย่างเต็มรูปแบบจาก Google ซึ่งเป็นส่วนหนึ่งของการอัปเดตประสบการณ์หน้าเพจ ตามชื่อของมัน LCP ตั้งเป้าที่จะวัดเมื่อเนื้อหาที่ใหญ่ที่สุดของหน้าถูกวาด (หรือ "ทาสี") ไปที่หน้าจอ บ่อยครั้งนี่คือภาพฮีโร่หรือข้อความชื่อ มีจุดประสงค์เพื่อวัดว่าผู้เยี่ยมชมเว็บไซต์น่าจะมาที่นี่เพื่อดูอะไร

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

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

มีหลายวิธีในการวัดผล Core Web Vitals ของคุณ แต่วิธีการที่ชัดเจน แม้ว่าจะไม่ใช่วิธีที่ดีที่สุด ดังที่เราเห็นในเร็วๆ นี้ — อยู่ใน Google Search Console (GSC) จากมุมมองของ SEO ไม่สำคัญหรอกว่าเครื่องมืออื่นๆ จะบอกคุณอย่างไร GSC คือสิ่งที่ Google Search เห็น แน่นอน ว่ามันสำคัญต่อประสบการณ์ของผู้ใช้ มากกว่าสิ่งที่โปรแกรมรวบรวมข้อมูลของเครื่องมือค้นหาเห็น แต่สิ่งหนึ่งที่ยอดเยี่ยมเกี่ยวกับความคิดริเริ่ม Core Web Vitals คือการวัด ประสบการณ์ผู้ใช้จริง มากกว่าสิ่งที่ Google Bot เห็น! ดังนั้น หาก GSC บอกว่าคุณมีประสบการณ์ที่ไม่ดี แสดงว่าคุณมีประสบการณ์ที่ไม่ดี ตามผู้ใช้ของคุณ

Search Console บอก Smashing Magazine ว่า LCP บนมือถือสำหรับหน้าเว็บส่วนใหญ่จำเป็นต้องปรับปรุง เอาต์พุตที่มีมาตรฐานเพียงพอของส่วนนั้นของ GSC และจัดการได้ง่าย: เพียงทำให้องค์ประกอบ LCP ของคุณวาดเร็วขึ้น! การดำเนินการนี้ไม่ควรใช้เวลานานเกินไป ไม่ใช่หกเดือน (หรืออย่างที่เราคิด) อย่างแรกเลยคือการค้นหาว่าองค์ประกอบ LCP คืออะไร

การเรียกใช้หน้าบทความที่ล้มเหลวผ่าน WebPageTest เน้นองค์ประกอบ LCP:

การปรับปรุงภาพ LCP

ตกลง ดังนั้นรูปภาพผู้เขียนบทความจึงเป็นองค์ประกอบ LCP สัญชาตญาณแรกคือการถามว่าเราจะทำอย่างไรเพื่อให้เร็วขึ้น? สิ่งนี้เกี่ยวข้องกับการเจาะลึกลงไปในน้ำตก ดูเมื่อมีการร้องขอรูปภาพ ใช้เวลาในการดาวน์โหลดนานเท่าใด จากนั้นจึงตัดสินใจว่าจะปรับให้เหมาะสมอย่างไร ที่นี่ รูปภาพได้รับการ ปรับให้เหมาะสมที่สุด ในแง่ของขนาดและรูปแบบ (โดยปกติเป็นตัวเลือกแรกและง่ายที่สุดในการปรับปรุงประสิทธิภาพของภาพ!) รูปภาพถูกนำเสนอจาก โดเมนสินทรัพย์แยกต่างหาก (มักจะไม่ดีต่อประสิทธิภาพ) แต่จะไม่สามารถเปลี่ยนแปลงได้ในระยะสั้น และ Smashing Magazine ได้เพิ่มคำใบ้ทรัพยากรที่ preconnect เพื่อเพิ่มความเร็วให้ดีที่สุด สามารถ.

ดังที่ฉันได้กล่าวไว้ก่อนหน้านี้ Smashing Magazine รู้เกี่ยวกับประสิทธิภาพของเว็บ เพิ่งทำงานเพื่อปรับปรุงประสิทธิภาพ และทำทุกอย่างที่นี่ แต่ก็ยังล้มเหลว น่าสนใจ…

ข้อเสนอแนะอื่นๆ ที่นำมาใช้ รวมถึงการลดภาระงาน ความล่าช้าของพนักงานบริการ (เพื่อหลีกเลี่ยงความขัดแย้ง) หรือการตรวจสอบลำดับความสำคัญของ HTTP/2 แต่ไม่มีผลกระทบที่จำเป็นต่อเวลา LCP ดังนั้นเราจึงต้องเข้าไปที่กระเป๋าเครื่องมือประสิทธิภาพเว็บของเราเพื่อดู เคล็ดลับและกลเม็ดต่างๆ เพื่อดูว่าเราทำอะไรได้อีกที่นี่

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

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

รูปแบบภาพก้าวหน้าไปบ้างเมื่อเร็วๆ นี้ แต่ AVIF สร้างความตื่นตระหนกเนื่องจากมีอยู่แล้ว (อย่างน้อยใน Chrome และ Firefox) และให้ผลการบีบอัดที่น่าประทับใจเหนือรูปแบบ JPEG แบบเก่าที่ใช้สำหรับภาพถ่าย Vitaly ไม่ต้องการอินไลน์รูปภาพของผู้เขียนในเวอร์ชัน JPEG แต่ได้ตรวจสอบว่าการใส่เวอร์ชัน AVIF ในอินไลน์จะใช้งานได้หรือไม่ การบีบอัดรูปภาพของผู้เขียนโดยใช้ AVIF จากนั้นใช้ 64-ing รูปภาพลงใน HTML ทำให้น้ำหนักหน้า HTML เพิ่มขึ้น 3 KB ซึ่งมีขนาดเล็กและเป็นที่ยอมรับได้

เนื่องจาก AVIF ได้รับการสนับสนุนเฉพาะใน Chrome ในขณะนั้น (หลังจากทั้งหมดนี้มากับ Firefox) และเนื่องจาก Core Web Vitals เป็นโครงการริเริ่มของ Google จึงรู้สึกว่ามีการเพิ่มประสิทธิภาพเบราว์เซอร์ Google เล็กน้อยเนื่องจากคำสั่งของ Google Chrome มักจะอยู่ในแนวหน้าของการสนับสนุนคุณลักษณะใหม่ ๆ และนั่นก็น่ายกย่อง แต่ก็มักจะรู้สึกไม่ค่อยดีนักเมื่อทั้งสองฝ่ายของธุรกิจส่งผลกระทบซึ่งกันและกัน อย่างไรก็ตาม นี่เป็น รูปแบบภาพมาตรฐานใหม่ แทนที่จะเป็นรูปแบบเฉพาะสำหรับ Chrome ที่เป็นกรรมสิทธิ์เท่านั้น (แม้ว่าจะได้รับการสนับสนุนใน Chrome ในขั้นต้นเท่านั้น) และเป็นการปรับปรุงประสิทธิภาพแบบก้าวหน้า (ผู้ใช้ Safari ยังคงได้รับเนื้อหาเดิมแต่ไม่เร็วเท่า ) ดังนั้นด้วยการเพิ่ม AVIF ที่บิดเบี้ยว Smashing ได้นำคำแนะนำและแทรกภาพเข้าไป และเห็นผลลัพธ์ที่น่าประทับใจอย่างแท้จริงในเครื่องมือในห้องปฏิบัติการ แก้ไขปัญหา!

LCP ทางเลือก

ดังนั้นเราจึงปล่อยเตียงนั้นไว้และรอประมาณ 28 วันหรือประมาณนั้นเพื่อให้ตัวเลข Core Web Vitals เปลี่ยนเป็นสีเขียวทั้งหมด… แต่ก็ไม่เป็นเช่นนั้น พวกเขาสลับไปมาระหว่างสีเขียวและสีเหลืองอำพัน ดังนั้นเราจึงต้องปรับปรุงสิ่งต่างๆ ให้ดีขึ้น แต่ก็ไม่ได้แก้ปัญหาทั้งหมด หลังจากอยู่ในส่วน "ต้องปรับปรุง" ของอำพันเป็นเวลานาน Vitaly เอื้อมมือออกไปเพื่อดูว่ามีความคิดอื่น ๆ อีกหรือไม่

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

ผู้อ่านมาเพื่อบทความไม่ใช่ผู้เขียน ดังนั้นองค์ประกอบ LCP ควรสะท้อนถึงสิ่งนั้น ซึ่งอาจแก้ปัญหาการวาดภาพ LCP ได้เช่นกัน ในการทำเช่นนั้น เราเพียงแค่ใส่พาดหัวไว้เหนือรูปภาพของผู้เขียน และเพิ่มขนาดฟอนต์บนมือถืออีกเล็กน้อย นี่อาจฟังดูเป็นกลอุบายที่จะหลอก Core Web Vital SEO Gods โดยเสียค่าใช้จ่ายของผู้ใช้ แต่ในกรณีนี้ มันช่วยทั้งคู่! แม้ว่าไซต์จำนวนมากพยายามที่จะแฮ็คอย่างรวดเร็วและง่ายดายหรือเพิ่มประสิทธิภาพให้กับ GoogleBot มากกว่าผู้ใช้จริง แต่นี่ไม่ใช่กรณีดังกล่าว และเราค่อนข้างสบายใจกับการตัดสินใจที่นี่ อันที่จริง การปรับแต่งเพิ่มเติมจะลบรูปภาพของผู้เขียนในมุมมองอุปกรณ์เคลื่อนที่โดยสิ้นเชิง ซึ่งมีพื้นที่จำกัด และบทความนั้นในปัจจุบันมีลักษณะเช่นนี้บนมือถือ โดยเน้นองค์ประกอบ LCP:

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

และนั่นเป็นหนึ่งในสิ่งสำคัญที่ฉันชอบเกี่ยวกับ Core Web Vitals: พวกเขากำลังวัดประสบการณ์ของผู้ใช้

เพื่อปรับปรุงตัวชี้วัด คุณต้องปรับปรุงประสบการณ์

“

และตอนนี้เราก็ทำเสร็จแล้ว ข้อความดึงเร็วกว่าภาพมาก ดังนั้นควรแยกแยะปัญหา LCP ขอบคุณมากและราตรีสวัสดิ์!

ฉันเกลียดกราฟ CWV ใน Google Search Console…

เราผิดหวังอีกครั้ง นั่นไม่ได้แก้ปัญหา และไม่นานก่อนที่กราฟ Google Search Console จะกลับมาเป็นสีเหลือง:

ณ จุดนี้ เราควรพูดถึงการจัดกลุ่มเพจและ Core Web Vitals ให้มากขึ้นอีกนิด คุณอาจสังเกตเห็นจากกราฟด้านบนว่ากราฟทั้งหมดแกว่งไปมาในครั้งเดียว แต่ก็มีกลุ่มแกนหลักประมาณ 1,000 หน้าที่เป็นสีเขียวเกือบตลอดเวลา ทำไมถึงเป็นอย่างนั้น?

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

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

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

อย่างไรก็ตาม ที่อาจสร้างความสับสนได้ก็คือเมื่อหน้ามีผู้เข้าชมมากพอที่จะได้คะแนน Core Web Vitals ของตัวเองและผ่าน แต่กลับรวมเข้ากับกลุ่มที่ล้มเหลว คุณสามารถเรียก CrUX API สำหรับทุกหน้าในไซต์ของคุณ ดูว่าหน้าส่วนใหญ่ส่งผ่าน จากนั้นให้สับสนเมื่อหน้าเดียวกันนั้นแสดงว่าล้มเหลวใน Search Console เนื่องจากถูกรวมกลุ่มไว้ในกลุ่มที่มี URL ที่ล้มเหลวและส่วนใหญ่ การรับส่งข้อมูลสำหรับกลุ่มนั้นมีความล้มเหลว ฉันยังสงสัยว่า Search Console ควรใช้ข้อมูล Core Web Vital ระดับหน้าเมื่อมี แทนที่จะใช้ข้อมูลการจัดกลุ่มเสมอ

อย่างไรก็ตาม นั่นถือเป็นการแกว่งตัวครั้งใหญ่ โดยทั่วไป บทความทั้งหมด (ซึ่งมีประมาณ 3,000 รายการ) ดูเหมือนจะอยู่ในการจัดกลุ่มหน้าเดียวกัน (ไม่สมเหตุสมผล!) และการจัดกลุ่มหน้านั้นผ่านหรือล้มเหลว เมื่อเปลี่ยน กราฟจะเคลื่อนที่อย่างรวดเร็ว

คุณยังรับข้อมูลโดยละเอียดเพิ่มเติมเกี่ยวกับ Core Web Vitals ผ่าน CrUX API ได้อีกด้วย มีให้ที่ระดับต้นทาง (เช่น สำหรับทั้งไซต์) หรือสำหรับ URL แต่ละรายการ (ซึ่งมีข้อมูลเพียงพอ) แต่ไม่น่ารำคาญที่ระดับการจัดกลุ่มเพจ ฉันได้ติดตาม LCP ระดับต้นทางโดยใช้ CrUX API เพื่อรับการวัดที่แม่นยำยิ่งขึ้นของ LCP และมันแสดงให้เห็นเรื่องราวที่น่าสลดใจเช่นกัน:

เราจะเห็นได้ว่าเราไม่เคย "แก้ปัญหา" นี้ได้จริงๆ และจำนวนหน้า "ดี" (เส้นสีเขียวด้านบน) ยังคงอยู่ใกล้อัตราการผ่าน 75% มากเกินไป นอกจากนี้ คะแนน p75 LCP (เส้นประซึ่งใช้แกนขวา) ไม่เคยเคลื่อนห่างจากเกณฑ์ 2500 มิลลิวินาทีมากนัก ไม่น่าแปลกใจเลยที่หน้าต่างๆ ที่ผ่านไปและล้มเหลวจะพลิกกลับไปกลับมา วันที่แย่นิดหน่อย ด้วยการโหลดหน้าเว็บที่ช้าอีกสองสามหน้า ก็เพียงพอแล้วที่จะพลิกการจัดกลุ่มทั้งหน้าเป็นหมวดหมู่ "ต้องปรับปรุง" เราต้องการอะไรมากกว่านี้เพื่อให้มีพื้นที่ว่างในการรับ "วันที่เลวร้าย" เหล่านี้

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

แต่รอสักครู่ Smashing Magazine เป็นเว็บไซต์ที่รวดเร็ว การเรียกใช้ผ่านเครื่องมือประสิทธิภาพเว็บ เช่น Lighthouse และ WebPageTest แสดงให้เห็นว่า — แม้ในความเร็วเครือข่ายที่ช้าลง และมันก็ทำทุกอย่างถูกต้อง! มันถูกสร้างขึ้นเป็นตัวสร้างไซต์แบบคงที่ดังนั้นจึงไม่จำเป็นต้องมีการสร้างฝั่งเซิร์ฟเวอร์ใด ๆ มันรวมทุกอย่างสำหรับการระบายสีเริ่มต้นดังนั้นจึงไม่มีข้อ จำกัด ในการโหลดทรัพยากรอื่นนอกเหนือจาก HTML เอง Netlify โฮสต์บน CDN ดังนั้น ควรอยู่ใกล้ผู้ใช้

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

ขุดลึกลงไปในตัวชี้วัด

Smashing Magazine ไม่มีโซลูชัน RUM ดังนั้นเราจึงเจาะลึกข้อมูลรายงานประสบการณ์ผู้ใช้ Chrome (CrUX) ที่ Google รวบรวมสำหรับเว็บไซต์ 8 ล้านอันดับแรกหรือมากกว่านั้น จากนั้นจึงทำให้ข้อมูลนั้นพร้อมสำหรับการสืบค้นในรูปแบบต่างๆ เป็นข้อมูล CrUX นี้ที่ขับเคลื่อนข้อมูล Google Search Console และส่งผลต่ออันดับในท้ายที่สุด เราใช้ CrUX API ด้านบนแล้ว แต่ตัดสินใจเจาะลึกทรัพยากร CrUX อื่นๆ

เราใช้แผนผังเว็บไซต์และสคริปต์ของ Google ชีตเพื่อดูข้อมูล CrUX ทั้งหมดสำหรับทั้งไซต์ที่พร้อมใช้งาน (ตั้งแต่นั้นมา Fabian Krumbholz ได้สร้างเครื่องมือที่ครอบคลุมมากขึ้นเพื่อทำให้สิ่งนี้ง่ายขึ้น!) และแสดง ผลลัพธ์แบบผสมสำหรับหน้าต่างๆ บางหน้าผ่านไป ในขณะที่บางหน้า โดยเฉพาะหน้าเก่า ล้มเหลว

แดชบอร์ด CrUX ไม่ได้บอกเรามากจริงๆ ว่าเรายังไม่รู้ในกรณีนี้: LCP นั้นอยู่ในแนวเขต และน่าเสียดายที่ไม่มีแนวโน้มลดลง:

การเจาะลึกสถิติอื่นๆ (TTFB, First Paint, Online, DOMContentLoaded) ไม่ได้บอกใบ้อะไรเราเลย อย่างไรก็ตาม มีการใช้งานมือถือเพิ่มขึ้นอย่างเห็นได้ชัด:

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

สิ่งหนึ่งที่ฉันต้องการดูคือการกระจายของการจราจรทั่วโลก เราสังเกตเห็นว่าใน Google Analytics มีการเข้าชมจำนวนมากจากอินเดียไปยังบทความเก่า — นั่นอาจเป็นปัญหาหรือไม่

การเชื่อมต่อของอินเดีย

ข้อมูล CrUX ระดับประเทศไม่มีอยู่ในแดชบอร์ด CrUX แต่มีให้ในชุดข้อมูล BigQuery CrUX และการเรียกใช้แบบสอบถามในนั้นที่ระดับต้นทาง www.smashingmagazine.com จะแสดงค่า LCP ที่แตกต่างกันอย่างมาก (รวม SQL แท็บที่สองของลิงก์นั้น btw ในกรณีที่คุณต้องการลองสิ่งเดียวกันบนโดเมนของคุณเอง) จาก 10 ประเทศชั้นนำใน Google Analytics เรามีข้อมูลดังต่อไปนี้:

ปริมาณการใช้ข้อมูลในอินเดียเป็นสัดส่วนใหญ่สำหรับ Smashing Magazine (16%) และไม่เป็นไปตามเป้าหมายของ LCP ที่ระดับต้นทาง นั่นอาจเป็นปัญหาและแน่นอนว่า ควรค่าแก่การตรวจสอบเพิ่มเติม นอกจากนี้ยังมีข้อมูลของฟิลิปปินส์และปากีสถานที่มีคะแนนต่ำมาก แต่นั่นเป็นปริมาณการเข้าชมที่ค่อนข้างน้อย

ณ จุดนี้ ฉันมีความสงสัยในสิ่งที่เกิดขึ้นที่นี่ และวิธีแก้ปัญหาที่เป็นไปได้ ดังนั้นฉันจึงขอให้ Smashing Magazine ติดตั้งไลบรารี web-vitals เพื่อรวบรวมข้อมูล RUM และโพสต์กลับไปที่ Google Analytics เพื่อทำการวิเคราะห์ หลังจากรวบรวมได้สองสามวัน เราใช้รายงาน Web Vitals เพื่อให้ข้อมูลมากมายแก่เราในรูปแบบที่ไม่เคยเห็นมาก่อน โดยเฉพาะอย่างยิ่ง รายละเอียดระดับประเทศ:

และมันก็เป็น ประเทศชั้นนำทั้งหมดในการวิเคราะห์ มี คะแนน LCP ที่ดีมาก ยกเว้นหนึ่ง: อินเดีย Smashing Magazine ใช้ Netlify ซึ่งเป็น CDN ระดับโลกและมีสาขาในมุมไบ ดังนั้นจึงควรมีประสิทธิภาพเหมือนประเทศอื่นๆ แต่บางประเทศก็ช้ากว่าประเทศอื่นๆ (เพิ่มเติมในภายหลัง)

อย่างไรก็ตาม ปริมาณการใช้มือถือในอินเดียอยู่เกินขีดจำกัด 2500 และเป็นเพียงประเทศที่มีผู้เข้าชมมากที่สุดเป็นอันดับสอง แน่นอนว่าคะแนนที่ดีของสหรัฐฯ ก็น่าจะเพียงพอแล้วที่จะชดเชยได้หรือไม่ กราฟสองอันด้านบนนี้แสดงลำดับประเทศตามปริมาณการใช้ข้อมูล แต่ CrUX นับทราฟฟิกบนมือถือและเดสก์ท็อปแยกกัน (และแท็บเล็ต btw แต่ดูเหมือนไม่มีใครสนใจเรื่องนี้เลย!) จะเกิดอะไรขึ้นหากเรา กรองการเข้าชมเป็นการเข้าชมบนมือถือ เท่านั้น และอีกขั้นหนึ่ง — แค่ปริมาณการใช้งาน Chrome บนมือถือ (เนื่องจาก Chrome เท่านั้นที่ฟีด CrUX และ Chrome เท่านั้นที่นับรวมใน CWV) ถ้าอย่างนั้นเราก็ได้ภาพที่น่าสนใจมากขึ้น:

จริงๆ แล้วอินเดียเป็นผู้เข้าชม Chrome บนมือถืออันดับต้นๆ เลยทีเดียว — เกือบสามเท่าของผู้เข้าชมสูงสุดรายถัดไป (สหรัฐอเมริกา)! ฟิลิปปินส์ที่มีคะแนนต่ำก็พุ่งขึ้นไปอยู่อันดับสามเช่นกัน และไนจีเรียและปากีสถานที่มีคะแนนต่ำก็อยู่ใน 10 อันดับแรกด้วย ตอนนี้คะแนน LCP โดยรวมที่แย่บนมือถือเริ่มสมเหตุสมผลแล้ว

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

นอกจากนี้ เนื่องจาก CrUX วัดจากผู้ใช้ Chrome เท่านั้น ซึ่งหมายความว่าประเทศที่มี iPhone มากกว่า (เช่น สหรัฐอเมริกา) จะมีสัดส่วนผู้ใช้อุปกรณ์พกพาที่น้อยกว่ามากใน CrUX และใน Core Web Vitals ดังนั้นจึงขยายผลกระทบของประเทศเหล่านั้นเพิ่มเติม

Core Web Vitals เป็นสากล

Core Web Vitals ไม่มีเกณฑ์ที่แตกต่างกันในแต่ละประเทศ และไม่สำคัญว่าไซต์ของคุณจะถูกเข้าชมโดยประเทศต่างๆ หรือไม่ — เพียงแค่ลงทะเบียนผู้ใช้ Chrome ทั้งหมดเหมือนกัน Google ได้ยืนยันเรื่องนี้มาก่อนแล้ว ดังนั้น Smashing Magazine จะไม่ได้รับการจัดอันดับสำหรับคะแนนที่ดีในสหรัฐอเมริกา และจะไม่ได้รับสำหรับผู้ใช้ในอินเดีย ผู้ใช้ทั้งหมดจะเข้าสู่กลุ่ม ละลาย และหากคะแนนสำหรับการจัดกลุ่มเพจเหล่านั้นไม่ตรงตามเกณฑ์ สัญญาณการจัดอันดับสำหรับผู้ใช้ทั้งหมดจะได้รับผลกระทบ

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

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

Core Web Vitals ควรแยกตามประเทศหรือไม่

ในแง่หนึ่ง ดูเหมือนว่าไม่ยุติธรรมที่จะยึดเว็บไซต์ให้เป็นมาตรฐานเดียวกัน หากโครงสร้างพื้นฐานแตกต่างกันมาก เหตุใด Smashing Magazine จึงควรถูกลงโทษหรือจัดให้อยู่ในมาตรฐานที่สูงกว่าเว็บไซต์ที่คล้ายกันซึ่งมีให้อ่านโดยนักออกแบบและนักพัฒนาจากโลกตะวันตกเท่านั้น ควร Smashing Magazine บล็อกผู้ใช้ชาวอินเดียเพื่อให้ Core Web Vitals มีความสุข (ฉันต้องการชี้แจงอย่างชัดเจนว่าสิ่งนี้ ไม่เคย เกิดขึ้นในการสนทนาดังนั้นโปรดใช้สิ่งนี้ในขณะที่ผู้เขียนชี้ประเด็นและไม่ว่องไวใน Smashing!)

ในทางกลับกัน การ "ยอมแพ้" ในบางประเทศโดยยอมรับความเสี่ยงด้านความช้าและผลักไสพวกเขาให้อยู่ระดับล่างอย่างถาวรซึ่งส่วนใหญ่อยู่ในนั้น นักอ่านชาวอินเดียโดยเฉลี่ยไม่ได้ตำหนิความผิดพลาดของ Smashing Magazine ที่ว่าโครงสร้างพื้นฐานของพวกเขาช้ากว่าและในหลาย ๆ ด้าน คนเหล่านี้สมควร ได้ รับการเน้นย้ำและพยายามมากกว่าที่จะน้อยกว่า!

และไม่ใช่แค่การถกเถียงกันเรื่องประเทศร่ำรวยกับประเทศยากจน ลองมาดูตัวอย่างเว็บไซต์ภาษาฝรั่งเศสที่มุ่งเป้าไปที่ผู้อ่านในฝรั่งเศส ได้รับทุนจากการโฆษณาหรือการขายจากฝรั่งเศส และมีเว็บไซต์ที่รวดเร็วในประเทศนั้น อย่างไรก็ตาม หากเว็บไซต์ดังกล่าวมีชาวแคนาดาฝรั่งเศสจำนวนมากอ่าน แต่ประสบปัญหาเนื่องจากบริษัทไม่ได้ใช้ CDN ทั่วโลก บริษัทนั้นควรประสบปัญหาใน French Google Search เนื่องจากผู้ใช้ในแคนาดาไม่เร็วเท่าเหล่านั้นหรือไม่ บริษัทควรถูก “เรียกค่าไถ่” จากการคุกคามของ Core Web Vitals และต้องลงทุนใน CDN ทั่วโลกเพื่อให้ผู้อ่านชาวแคนาดาเหล่านั้นและ Google มีความสุขหรือไม่

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

แนวคิดหนึ่งอาจเป็นการรักษาขีดจำกัดให้เท่าเดิม แต่ ให้วัดตามประเทศ ไซต์ Google Search ของฝรั่งเศสสามารถเพิ่มอันดับให้กับผู้ใช้ที่เป็นภาษาฝรั่งเศส (เนื่องจากผู้ใช้เหล่านั้นผ่าน CWV สำหรับไซต์นี้) ในขณะที่ Google Search Canada อาจไม่ให้ (เพราะพวกเขาล้มเหลว) ที่จะยกระดับสนามแข่งขันและวัดไซต์ของแต่ละประเทศแม้ว่าเป้าหมายจะเหมือนกันก็ตาม

ในทำนองเดียวกัน Smashing Magazine อาจมีอันดับที่ดีในสหรัฐอเมริกาและประเทศอื่น ๆ ที่พวกเขาผ่าน แต่ได้รับการจัดอันดับเทียบกับไซต์อินเดียอื่น ๆ (ซึ่งข้อเท็จจริงที่พวกเขาอยู่ในส่วน "ต้องปรับปรุง" อาจยังดีกว่าไซต์จำนวนมากที่นั่น สมมติ พวกเขาทั้งหมดประสบกับข้อจำกัดด้านประสิทธิภาพเดียวกัน)

น่าเศร้าที่ฉันคิดว่ามันจะส่งผลในทางลบ โดยที่บางประเทศกลับถูกละเลยอีกครั้ง ในขณะที่ไซต์ต่าง ๆ ให้เหตุผลในการลงทุนด้านประสิทธิภาพเว็บสำหรับประเทศที่ทำกำไรได้มากกว่าเท่านั้น นอกจากนี้ ดังที่ตัวอย่างนี้แสดงให้เห็นแล้ว Core Web Vitals นั้นซับซ้อนอยู่แล้วโดยไม่ต้องนำมิติเพิ่มเติมมาเกือบ 200 มิติเข้าไปด้วยการมีมิติข้อมูลสำหรับทุกประเทศในโลก!

แล้วจะแก้ไขอย่างไร?

ในที่สุดเราก็รู้แล้วว่าทำไม Smashing Magazine ถึงพยายามไม่ผ่าน Core Web Vitals แต่ถ้ามีอะไรเกิดขึ้นล่ะ? ผู้ให้บริการโฮสต์ (Netlify) มี Mumbai CDN อยู่แล้ว ซึ่งควรให้การเข้าถึงที่รวดเร็วสำหรับผู้ใช้ชาวอินเดีย นี่เป็นปัญหาของ Netlify ที่ต้องปรับปรุงหรือไม่ เราได้ปรับไซต์ให้เหมาะสมที่สุดเท่าที่จะเป็นไปได้ ดังนั้นนี่เป็นเพียงสิ่งที่พวกเขาจะต้องอยู่ด้วยหรือไม่ ไม่ได้ ตอนนี้เรากลับมาที่แนวคิดของเราจากก่อนหน้านี้: เพิ่มประสิทธิภาพแบบอักษรเว็บอีกเล็กน้อย

เราสามารถใช้ตัวเลือกที่รุนแรงในการไม่ส่งแบบอักษรเลย หรือบางทีอาจจะไม่ส่งฟอนต์ไปยังบางตำแหน่ง (ถึงแม้จะซับซ้อนกว่าก็ตาม เนื่องจากลักษณะ SSG ของเว็บไซต์ของ Smashing Magazine) อีกทางหนึ่ง เราอาจรอและโหลดแบบอักษรในส่วนหน้า ตามเกณฑ์บางอย่าง แต่อาจทำให้แบบอักษรอื่นช้าลงในขณะที่เราประเมินเกณฑ์นั้น หากมีเพียงสัญญาณเบราว์เซอร์ที่ใช้งานง่ายสำหรับเวลาที่เราควรดำเนินการที่รุนแรงนี้ บางอย่างเช่นส่วนหัว SaveData ซึ่งมีไว้สำหรับสิ่งนี้!

SaveData และ prefers-reduced-data

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

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

ข้อมูลบันทึกข้อมูลมีอยู่ในสองวิธี (ในเร็วๆ นี้จะเป็น 3 วิธี):

1. ส่วนหัว SaveData จะถูกส่งไปในแต่ละคำขอ HTTP ซึ่งช่วยให้แบ็กเอนด์แบบไดนามิกเปลี่ยน HTML ที่ส่งคืนได้
2. NetworkInformation.saveData JavaScript API ซึ่งช่วยให้สคริปต์ส่วนหน้าตรวจสอบและดำเนินการตามนั้นได้
3. คิวรี่สื่อที่ prefers-reduced-data กำลังจะมีขึ้น ซึ่งช่วยให้ CSS ตั้งค่าตัวเลือกต่างๆ ได้ขึ้นอยู่กับการตั้งค่านี้ มีให้ใช้งานหลังแฟล็กใน Chrome แต่ยังไม่ได้เปิดโดยค่าเริ่มต้นในขณะที่เสร็จสิ้นการทำให้เป็นมาตรฐาน

ดังนั้น คำถามคือ ผู้อ่านนิตยสาร Smashing หลายคน (และโดยเฉพาะอย่างยิ่งในประเทศที่ประสบปัญหากับ Core Web Vitals) ใช้ตัวเลือกนี้และนี่คือสิ่งที่เราสามารถใช้เพื่อให้บริการพวกเขาในไซต์ที่เร็วขึ้นหรือไม่ เมื่อเราเพิ่มสคริปต์ web-vitals กล่าวถึงข้างต้น เรายังตัดสินใจวัดสิ่งนั้น เช่นเดียวกับประเภทการเชื่อมต่อที่มีประสิทธิภาพ คุณสามารถดูสคริปต์แบบเต็มได้ที่นี่ หลังจากปล่อยให้รวบรวมได้สักพัก เราสามารถแสดงผลลัพธ์ในแดชบอร์ด /Google Analytics แบบธรรมดา ร่วมกับเวอร์ชันเบราว์เซอร์ Chrome:

ข่าวดีก็คือ ผู้ใช้มือถือชาวอินเดียส่วนใหญ่ (ประมาณสองในสาม) ได้ ตั้งค่านี้ไว้ ECT มีประโยชน์น้อยกว่าโดยส่วนใหญ่แสดงเป็น 4g ฉันเคยโต้แย้งมาก่อนว่า API นี้มีประโยชน์น้อยลงเรื่อยๆ เนื่องจากผู้ใช้ส่วนใหญ่จัดอยู่ในการตั้งค่า 4g นี้ การใช้ค่านี้อย่างมีประสิทธิภาพสำหรับการโหลดครั้งแรกนั้นเต็มไปด้วยปัญหา

ข่าวดีเพิ่มเติมเนื่องจากผู้ใช้ส่วนใหญ่ดูเหมือนจะใช้ Chrome เวอร์ชันล่าสุด ดังนั้นจะได้รับประโยชน์จากคุณลักษณะที่ใหม่กว่า เช่น การสืบค้นสื่อที่ prefers-reduced-data เมื่อพร้อมใช้งานโดยสมบูรณ์

Ilya from the Smashing team applied the JavaScript API version to their font-loader script so additional fonts are not loaded for these users. The Smashing folks also applied the prefers-reduce-data media query to their CSS so fallback fonts are used rather than custom web fonts for the initial render, but this will not be taking effect for most users until that setting moves out of the experimental stage.

I Love That Graph In Google Search Console

And did it work? Well, we'll let Google Search Console tell that store as it showed us the good news a couple of weeks later:

Additionally, since this was introduced in mid-November, the original level LCP score has steadily ticked downwards:

There's still not nearly enough headroom to make me comfortable, but I'm hopeful that this will be enough for now, and will only improve when the prefers-reduced-data media query comes into play — hopefully soon.

Of course, a surge in traffic from mobile users with bad connectivity could easily be enough to flip the site back into the amber category, which is why you want that headroom, so I'm sure the Smashing team will be keeping a close eye on their Google Search Console graph for a bit longer, but I feel we've made the best efforts basis to improve the experience of users so I am hopeful it will be enough.

Impact Of The User Experience Ranking Factor

The User Experience ranking factor is supposed to be a small differentiator at the moment, and maybe we worried too much about a small issue that is, in many ways outside of our control? If Smashing Magazine is borderline, and the impact is small, then maybe the team should worry about other issues instead of obsessing over this one? But I can understand that and, as I said, Smashing Magazine are knowledgeable in performance and so understand why they wanted to solve — or at the very least understand! — this issue.

So, was there any impact? Interestingly we did see a large uptick in search impression in the last week at the same time as it flipped to green:

It's since reverted back to normal, so this may have been an unrelated blip but interesting nonetheless!

บทสรุป

So, an interesting case study with a few important points to take away:

• When RUM (including CrUX or Google Search Console) tells you there's a problem, there probably is! It's all too easy to try to compare your experiences and then blame the metric.
• Implementing your own RUM solution gives you access to much more valuable data than the high-level data CrUX is intended to provide, which can help you drill down into issues, plus also give you potentially more information about the devices your site visitors are using to visit your site.
• Core Web Vitals are global, and that causes some interesting challenges for global sites like Smashing Magazine. This can make it difficult to understand CrUX numbers unless you have a RUM solution and perhaps Google Search Console or CrUX could help surface this information more?
• Chrome usage also varies throughout the world, and on mobile is biased towards poorer countries where more expensive iPhones are less prevalent.
• Core Web Vitals are getting much better at measuring User Experience. But that doesn't mean every user has to get the same user experience — especially if they are telling you (through things like the Save Data option) that they would actually prefer a different experience.

I hope that this case study helps others in a similar situation, who are struggling to understand their Core Web Vitals. And I hope you can use the information here to make the experience better for your website visitors.

มีความสุขในการเพิ่มประสิทธิภาพ!

Note: It should be noted that Vitaly, Ilya and others at the Smashing team did all the work here, and a lot more performance improvements were not covered in the above article. I just answered a few queries for them on this specific problem over the last 6 months and then suggested this article might make an interesting case study for other readers to learn from.