ทรัพยากรของบุคคลที่สาม (เช่น ชิ้นงานและสคริปต์) นั้นใช้กันอย่างแพร่หลายในเว็บในปัจจุบัน แพลตฟอร์มเหล่านี้มีโซลูชันสำเร็จรูปสําหรับการฝังโซเชียลมีเดีย วิดีโอ ข้อมูลวิเคราะห์ แชทสด การโฆษณา การทดสอบ A/B การปรับให้เหมาะกับผู้ใช้แต่ละราย และอื่นๆ ชิ้นงานของบุคคลที่สามเป็นส่วนสำคัญของเว็บไซต์สมัยใหม่ที่ช่วยให้ผู้เป็นเจ้าของเว็บไซต์มุ่งเน้นที่ความสามารถหลักของตนได้ ขณะที่ผู้ให้บริการภายนอกจะเป็นผู้ดูแลฟังก์ชันมาตรฐานแต่สําคัญ
เมื่อทั้งบุคคลที่หนึ่งและบุคคลที่สามในหน้าเว็บทํางานร่วมกันอย่างสอดคล้องกัน หน้าเว็บก็อาจมอบประสบการณ์การใช้งานที่ยอดเยี่ยมให้แก่ผู้ใช้ได้ อย่างไรก็ตาม การดำเนินการนี้ต้องใช้ความพยายามอย่างมากจากทั้งทีมวิศวกรและทีมธุรกิจ และมักถูกมองข้าม ส่งผลให้หน้าเว็บมีประสิทธิภาพต่ำและส่งผลเสียต่อเมตริกที่เน้นผู้ใช้ เช่น Core Web Vitals ซึ่งส่งผลเสียต่อทั้ง 2 ฝ่ายและทำให้พลาดโอกาสทางธุรกิจ เราช่วยปรับปรุงอะไรได้บ้าง
เรามีวิสัยทัศน์ในอนาคตของเว็บที่สคริปต์และทรัพยากรของบุคคลที่สามให้คุณค่าทางธุรกิจตามที่ตั้งใจไว้โดยที่ประสิทธิภาพหรือประสบการณ์ของผู้ใช้เว็บไซต์ที่ใช้สคริปต์และทรัพยากรดังกล่าวในเบราว์เซอร์แทบไม่เปลี่ยนแปลง ซึ่งจะช่วยให้ผู้ใช้ได้รับประสบการณ์การโหลดหน้าเว็บที่เร็วขึ้น
ตลอดปีที่ผ่านมา เราได้พิจารณา พูดคุย และทดสอบความเป็นไปได้หลายอย่างซึ่งอาจช่วยปกป้องประสบการณ์ของผู้ใช้จากผลกระทบที่เสียเปรียบของสคริปต์ของบุคคลที่สาม โดยไม่ลดคุณค่าทางธุรกิจของเจ้าของเว็บไซต์
เราต้องการแชร์ข้อมูลเกี่ยวกับการทดสอบบางอย่างผ่านโพสต์นี้ เราหวังว่านี่จะเป็นจุดเริ่มต้นของกระบวนการที่จะส่งเสริมความโปร่งใสและการแสดงผลระหว่าง User Agent, ธุรกิจ และผู้ให้บริการบุคคลที่สาม รวมถึงปูทางไปสู่เว็บที่เร็วขึ้น
เจาะลึกเกี่ยวกับบุคคลที่สาม
บุคคลที่สามคือทรัพยากรที่ให้บริการโดยผู้ให้บริการภายนอกเว็บไซต์ โฆษณาเหล่านี้ไม่ได้อยู่ภายใต้การควบคุมโดยตรงของเจ้าของเว็บไซต์ แต่แสดงขึ้นเมื่อเจ้าของเว็บไซต์อนุมัติ ทรัพยากรของบุคคลที่สาม ได้แก่
- โฮสต์อยู่ในต้นทางที่แชร์และสาธารณะซึ่งแตกต่างจากต้นทางของเว็บไซต์หลัก
- ไม่ได้เขียนขึ้นหรือได้รับอิทธิพลจากเจ้าของเว็บไซต์บุคคลธรรมดา
- เว็บไซต์ต่างๆ ใช้กันอย่างแพร่หลาย
บุคคลที่สามมีวัตถุประสงค์ทางธุรกิจที่หลากหลาย ตั้งแต่การช่วยสร้างรายได้ (ผ่านโฆษณา) ไปจนถึงการมอบโอกาสทางการตลาดที่ดีขึ้น (การฝังโซเชียลมีเดีย) หมวดหมู่ทั่วไปของบุคคลที่สาม ได้แก่
แหล่งที่มา: บุคคลที่สามตามหมวดหมู่
หมวดหมู่ | คำจำกัดความ |
---|---|
การโฆษณา | สคริปต์ที่ใช้แสดงโฆษณาหรือวัดประสิทธิภาพโฆษณา |
วิดีโอ | สคริปต์ที่เปิดใช้ฟังก์ชันการทำงานของโปรแกรมเล่นวิดีโอและสตรีมมิง |
ไลบรารีที่โฮสต์ | ไลบรารีโอเพนซอร์สที่โฮสต์แบบสาธารณะหลายรายการ |
เนื้อหา | สคริปต์จากผู้ให้บริการเนื้อหาหรือการติดตามของบริษัทในเครือที่เจาะจงการเผยแพร่ |
ความสำเร็จของลูกค้า | สคริปต์จากผู้ให้บริการฝ่ายสนับสนุนลูกค้า/การตลาดที่เสนอโซลูชันการแชทและการติดต่อ |
โฮสติ้ง | สคริปต์จากแพลตฟอร์มเว็บโฮสติ้ง |
การตลาด | สคริปต์จากเครื่องมือทางการตลาดที่เพิ่มป๊อปอัป จดหมายข่าว และอื่นๆ |
โซเชียล | สคริปต์ที่เปิดใช้ฟีเจอร์โซเชียล |
Tag Manager | สคริปต์ที่โหลดสคริปต์อื่นๆ จำนวนมากและเริ่มงานหลายรายการ |
Analytics | สคริปต์ที่วัดหรือติดตามผู้ใช้และการกระทำของผู้ใช้ |
แพลตฟอร์มความยินยอมในการใช้คุกกี้ | สคริปต์ที่ช่วยให้เว็บไซต์ขอความยินยอมจากผู้ใช้ (GDPR, ePR, CCPA) ในลักษณะที่โปร่งใสและแจ้งให้ทราบ |
อรรถประโยชน์ | สคริปต์ที่เป็นยูทิลิตีสำหรับนักพัฒนาซอฟต์แวร์ (ไคลเอ็นต์ API, การตรวจสอบเว็บไซต์, การตรวจจับการประพฤติมิชอบ และอื่นๆ |
อื่นๆ | สคริปต์เบ็ดเตล็ดที่ส่งผ่านต้นทางที่แชร์โดยไม่มีหมวดหมู่หรือการระบุแหล่งที่มาที่ชัดเจน |
สคริปต์และไลบรารีของบุคคลที่สามเหล่านี้ช่วยให้นักพัฒนาเว็บใช้ประโยชน์จากโซลูชันที่ผ่านการทดสอบแล้วเพื่อติดตั้งใช้งานฟีเจอร์มาตรฐานแทนที่จะต้องคิดค้นสิ่งใหม่ บุคคลที่สามจึงช่วยประหยัดเวลาในการพัฒนาและช่วยให้ธุรกิจเปิดตัวหรืออัปเกรดผลิตภัณฑ์ได้เร็วขึ้น จึงไม่แปลกใจเลยที่เว็บไซต์ทั้งหมดกว่า 94% บนเดสก์ท็อปและอุปกรณ์เคลื่อนที่ใช้บุคคลที่สาม
บุคคลที่สามส่งผลต่อประสิทธิภาพอย่างไร
โดยหลักการแล้ว นักพัฒนาแอปบุคคลที่สามควรเป็นผู้เชี่ยวชาญด้านเนื้อหาของฟีเจอร์ที่ตนนำเสนอ บุคคลที่สามที่ได้รับความนิยมมากที่สุดได้ผ่านการพัฒนาหลายครั้ง และเราคาดหวังได้ว่าโค้ดของบุคคลที่สามเหล่านั้นจะได้รับการเพิ่มประสิทธิภาพเพื่อเป้าหมายทางธุรกิจของตนเอง ซึ่งอาจรวมถึงหรือไม่ได้รวมถึงประสิทธิภาพของหน้าเว็บที่ใช้โค้ดดังกล่าว อย่างไรก็ตาม เราทราบดีว่าบุคคลที่สามที่เพิ่มประสิทธิภาพมาอย่างดีแล้วก็ยังส่งผลต่อประสิทธิภาพ สาเหตุหลักที่ทำให้เกิดผลกระทบนี้ ได้แก่
ขนาดและต้นทุนการเรียกใช้สคริปต์: บุคคลที่สามมักมุ่งมั่นที่จะมอบฟังก์ชันการทำงานที่สำคัญ "เพียง" โดยการวางองค์ประกอบ
<script>
หรือ<iframe>
ลงในหน้าเว็บ จากนั้นองค์ประกอบเหล่านี้จะดึงสคริปต์และทรัพยากรที่มีขนาดใหญ่และใช้เวลานานในการดาวน์โหลดและดำเนินการ JavaScript มากเกินไปจะทำให้เทรดหลักทำงานนานขึ้น บล็อกการแสดงผล และทำให้การโต้ตอบของผู้ใช้ล่าช้า บุคคลที่สามรายใหญ่บางรายได้บล็อกชุดข้อความหลักตั้งแต่ 42 มิลลิวินาทีถึง 1.6 วินาทีในเว็บไซต์กว่า 50% ที่วิเคราะห์ เทรดหลักที่ถูกบล็อกส่งผลให้เวลาในการบล็อกทั้งหมด (TBT) สูง ซึ่งเป็นเมตริกที่ส่งผลต่อคะแนนประสิทธิภาพของเว็บไซต์ นอกจากนี้ ยังทำให้การตอบสนองต่อการโต้ตอบของผู้ใช้ล่าช้าและทำให้เมตริก Interaction to Next Paint (INP) ที่ใช้ในการวัดการตอบสนองของเว็บไซต์ลดลง ดังนั้น ค่าใช้จ่ายในการเรียกใช้สคริปต์จึงส่งผลต่อประสิทธิภาพอย่างมากจํานวน: โดยเฉลี่ยแล้ว เว็บไซต์ใช้บุคคลที่สามประมาณ 21 รายในอุปกรณ์เคลื่อนที่และเว็บ บ่อยครั้งที่แท็กของบุคคลที่สามจะเพิ่มโดยเครื่องมือจัดการแท็กที่ทีมเทคนิค/ทีมพัฒนาไม่ได้ควบคุมโดยตรง ทีมอื่นๆ อาจเพิ่มแท็กที่ไม่จำเป็นได้โดยไม่ต้องผ่านกระบวนการตรวจสอบและจะไม่มีการนำแท็กดังกล่าวออก เนื่องจากอาจส่งผลต่อประสบการณ์ของผู้ใช้ น้ำหนักหน้าเว็บ หรือการใช้งาน CPU อย่างมาก การสร้างกระบวนการจัดการจะช่วยจัดการสถานการณ์ดังกล่าวและช่วยให้นักพัฒนาแอปตรวจสอบผลกระทบของผู้ให้บริการแต่ละรายได้ การที่นักพัฒนาแอปมีข้อมูลพร้อมใช้งานสำหรับบุคคลที่สามทั้งหมดที่ให้บริการฟังก์ชันหนึ่งๆ พร้อมผลกระทบด้านประสิทธิภาพ ประโยชน์ และข้อเสียเพื่อเปรียบเทียบก็จะช่วยได้ ปัญหาอีกอย่างหนึ่งที่ทีมต้องเผชิญคือแท็กของบุคคลที่สามในหลายเว็บไซต์จะทํางานในเวอร์ชันที่ใช้งานจริงเท่านั้น แต่ไม่ทํางานในสภาพแวดล้อมการพัฒนา ซึ่งทําให้นักพัฒนาซอฟต์แวร์ทดสอบแท็กได้ยากขึ้น
เครือข่าย: เนื่องจากมีการโฮสต์บุคคลที่สามในต้นทางที่แตกต่างกัน เบราว์เซอร์จึงต้องสร้างการเชื่อมต่อจำนวนมากขึ้นเพื่อดาวน์โหลดเนื้อหาจากบุคคลที่สาม การเชื่อมต่อต่างๆ ไม่สามารถประสานงานการดาวน์โหลดตามลําดับความสําคัญได้ จึงทําให้เครือข่ายมีการแข่งขันกัน ซึ่งอาจทำให้หน้าเว็บโหลดช้าลงอีกหากไม่พิจารณาการเพิ่มประสิทธิภาพที่เหมาะสม
การจัดลําดับ: บุคคลที่สามสามารถบล็อกเธรดหลักและแย่งแบนด์วิดท์กับทรัพยากรสําคัญอื่นๆ อย่างไรก็ตาม ในบางกรณี บุคคลที่สามคือทรัพยากรสําคัญที่จําเป็นสําหรับการแสดงผลหน้าเว็บ การจัดลําดับทรัพยากรของบุคคลที่หนึ่งและบุคคลที่สามอย่างเหมาะสมจําเป็นเมื่อเว็บไซต์ใช้บุคคลที่สามหลายราย นักพัฒนาเว็บควรทราบถึงตัวเลือกต่างๆ ที่มีให้เพื่อเพิ่มประสิทธิภาพการจัดลำดับ
ด้วยเหตุนี้ บุคคลที่สามจึงส่งผลต่อองค์ประกอบใดๆ หรือทั้งหมดของ Core Web Vitals ได้ บุคคลที่สามส่วนใหญ่ส่งผลเสียต่อ Largest Contentful Paint (LCP) และ First Input Delay (FID) การฝัง YouTube บล็อกเธรดหลักเป็นเวลา 4.5 วินาทีสำหรับ 10% ของเว็บไซต์บนอุปกรณ์เคลื่อนที่ และอย่างน้อย 1.6 วินาทีสำหรับ 50% ของเว็บไซต์ที่ศึกษา ลองนึกถึงความรู้สึกหงุดหงิดของผู้ใช้หากพบหน้าเว็บที่มีสคริปต์ดังกล่าว 20 รายการในการเชื่อมต่อที่ช้า ภาพต่อไปนี้จาก thirdpartyweb.today แสดงบุคคลที่สามที่ส่งผลต่อประสิทธิภาพมากที่สุดในปัจจุบัน
"ในเว็บไซต์ยอดนิยมประมาณ 4 ล้านแห่ง ต้นทางประมาณ 2, 700 แห่งคิดเป็นสัดส่วนประมาณ 57% ของเวลาในการเรียกใช้สคริปต์ทั้งหมด โดยเอนทิตี 50 อันดับแรกคิดเป็นสัดส่วนประมาณ 47% อยู่แล้ว" - third-party-web
หน้าเว็บที่แสดงผลอย่างรวดเร็วและโต้ตอบได้ภายในกรอบเวลาที่เหมาะสมเป็นสิ่งจําเป็นสําหรับประสบการณ์การใช้งานที่ดีตามที่วัดโดย Core Web Vitals UX ที่ดีมักจะหมายถึงธุรกิจที่เติบโตสําหรับเว็บไซต์ ซึ่งอาจหมายถึงธุรกิจที่เติบโตสําหรับบุคคลที่สามที่ใช้ การทํางานร่วมกันเพื่อลดผลกระทบจากบุคคลที่สามอาจเป็นผลดีสําหรับทุกคนในห่วงโซ่
เราทราบว่า Google จำหน่ายสคริปต์ของบุคคลที่สามที่ใช้กันโดยทั่วไปหลายรายการ เช่น Google Tag Manager, การฝัง YouTube และ ReCaptcha เป็นต้น เราตระหนักดีว่าสคริปต์บางรายการของเราอาจส่งผลต่อประสิทธิภาพของ Core Web Vitals น้อยกว่า และเรามุ่งมั่นที่จะหาวิธีปรับปรุงผลกระทบนี้หากเป็นไปได้
Chrome จะช่วยคุณได้อย่างไร
ประสิทธิภาพของทรัพยากรของบุคคลที่สามที่ไม่ดีเป็นปัญหาที่นักพัฒนาแอปพบอยู่เสมอ ซึ่งจำเป็นต้องมีการเปลี่ยนแปลงแบบก้าวกระโดดในการเปลี่ยนแปลงของระบบนิเวศพื้นฐาน Chrome ต้องการสำรวจพื้นที่นี้เพื่อให้ได้ผลลัพธ์ต่อไปนี้
ค้นหาวิธีโหลดทรัพยากรของบุคคลที่สามบนเว็บที่ดีขึ้นโดยไม่ทำให้ประสบการณ์ของผู้ใช้หรือผลลัพธ์ทางธุรกิจลดลง
เราทราบดีว่าคงจะดำเนินการต่อได้ยากหากไม่ทำงานร่วมกับพาร์ทเนอร์ ธุรกิจ บุคคลที่สาม และนักพัฒนาแอป เราต้องการเปิดพื้นที่ให้พูดคุยเกี่ยวกับความเป็นไปได้และแลกเปลี่ยนแนวคิดผ่านคำอธิบายและข้อกำหนดเฉพาะแบบสาธารณะ นักพัฒนาแอปจะมีเวลาแสดงความคิดเห็นและทดสอบผลกระทบของข้อเสนอเหล่านี้
ช่วยให้ผู้ใช้สคริปต์ของบุคคลที่สามระบุแหล่งที่มาของต้นทุนในเครื่องมือและในสนามได้ดีขึ้น มีเส้นทางที่ชัดเจนและเหมาะสมสำหรับการใช้งาน รวมถึงสิ่งจูงใจที่ดียิ่งขึ้นในระหว่างการเขียนเพื่อให้แน่ใจว่าสคริปต์จะทำงานได้ดีที่สุดโดยค่าเริ่มต้น
เราต้องการปรับปรุงทุกเลเยอร์ เช่น User Agent, เฟรมเวิร์ก และสคริปต์ของบุคคลที่สาม เพื่อลดผลกระทบด้านประสิทธิภาพของบุคคลที่สาม นอกจากนี้ เรายังตั้งใจที่จะให้ข้อมูลเชิงลึกที่เพียงพอเพื่อช่วยเจ้าของเว็บไซต์ใช้แนวทางปฏิบัติแนะนำเกี่ยวกับสคริปต์ที่ฝังแต่ละรายการ รวมถึงทางเลือกที่เร็วขึ้น (หากมี)
แนวทางที่เสนอ
เราขอแนะนําแนวทาง 3 ด้านเพื่อให้บรรลุผลลัพธ์เหล่านี้...
**ช่วยให้นักพัฒนาซอฟต์แวร์ระบุแหล่งที่มาของผลกระทบจากบุคคลที่สามได้ละเอียดยิ่งขึ้นผ่าน RUM และในเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ของ Chrome**
RUM หมายถึงข้อมูลเมตริกของผู้ใช้จริง (หรือที่เรียกว่าข้อมูลภาคสนาม) ซึ่งมีให้ผ่าน API การตรวจสอบประสิทธิภาพเว็บ เครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ของ Chrome ได้แก่ Lighthouse, Chrome DevTools และรายงานประสบการณ์ของผู้ใช้ Chrome เราขอเสนอให้ปรับปรุง API และเครื่องมือที่มีอยู่เพื่อให้นักพัฒนาเว็บไซต์เข้าใจผลกระทบของบุคคลที่สามทุกรายที่ใช้ในหน้าเว็บทุกหน้า เครื่องมือนี้จะให้ความรู้แก่ผู้เผยแพร่โฆษณาเกี่ยวกับการดำเนินการที่ทำได้เพื่อลดผลกระทบ (เช่น การเลื่อนหรือการใช้ Facade) รวมถึงสำรวจโซลูชันอื่นๆ ที่เป็นไปได้ (บุคคลที่สามรายอื่นหรือ DIY) พร้อมข้อดีข้อเสีย สําหรับ API การตรวจสอบประสิทธิภาพเว็บ เรากําลังหาวิธีขยายความครอบคลุมของทรัพยากรข้ามแหล่งที่มาโดยไม่กระทบต่อความเป็นส่วนตัวและความปลอดภัยของผู้ใช้
**ช่วยให้ธุรกิจมีเส้นทางที่ชัดเจนในการโหลดทรัพยากรของบุคคลที่สามอย่างมีประสิทธิภาพ**
เราต้องการเสนอมาตรฐานใหม่ที่จะกระตุ้นให้เบราว์เซอร์ใช้วิธีโหลดทรัพยากรของบุคคลที่หนึ่งและบุคคลที่สามอย่างชาญฉลาดมากขึ้นเพื่อมอบประสบการณ์การโหลดที่ดียิ่งขึ้นให้แก่ผู้ใช้ เราจะไฮไลต์ข้อเสนอเหล่านี้บางส่วนในภายหลัง เช่น การโหลดแบบเลื่อนเวลาในการฝังของบุคคลที่สามโดยค่าเริ่มต้น หรือการใช้การจัดลําดับความสําคัญของทรัพยากรที่แตกต่างกันกับทรัพยากรของบุคคลที่สามที่อาจไม่สําคัญมากนักต่อเนื้อหาเริ่มต้นที่ผู้ใช้อาจให้ความสําคัญมากที่สุด นี่เป็นเพียงไอเดียบางส่วนที่เรากำลังประเมินในเรื่องนี้ และเรายินดีที่จะทำงานร่วมกับทั้งผู้เชี่ยวชาญด้านประสิทธิภาพเว็บและชุมชนในวงกว้างเพื่อกำหนดแนวทางการทำงานนี้
ในทำนองเดียวกัน เราต้องการแก้ไขปัญหาดังกล่าวในเฟรมเวิร์ก JavaScript และระบบจัดการเนื้อหา (CMS) ตามความเหมาะสม โปรเจ็กต์อย่าง Aurora และ ทีมประสิทธิภาพของ WordPress ทำให้เราทราบถึงความสำคัญของค่าเริ่มต้นที่รวมไว้ซึ่งช่วยแก้ปัญหาการโหลดที่ทราบอยู่แล้ว ค่าเริ่มต้นที่ฝังอยู่ในเฟรมเวิร์กและ CMS จะนำทางธุรกิจไปตามเส้นทางที่ชัดเจน นอกจากนี้ ข้อมูลนี้ยังเป็นประโยชน์ต่อ User Agent (เช่น Chrome) ในฐานะคำแนะนำที่ช่วยให้ใช้วิธีการแก้ปัญหาแบบเฮuristic เพื่อเพิ่มประสิทธิภาพการโหลดหน้าเว็บและ CWV ได้ คำแนะนำดังกล่าวจะช่วยให้ User Agent ตัดสินใจได้ว่าควรโหลดบุคคลที่สามที่เฉพาะเจาะจงเมื่อใดและอย่างไรในวงจรชีวิตของหน้าเว็บ (เช่น คอมโพเนนต์สคริปต์ Next.js มีค่าเริ่มต้นที่โหลดสคริปต์ของบุคคลที่สามหลังจากที่หน้าเว็บเป็นแบบอินเทอร์แอกทีฟ)
**สร้างแรงจูงใจให้บุคคลที่สามลดผลกระทบต่อประสิทธิภาพผ่านความพยายามที่โปร่งใสยิ่งขึ้น**
ปัจจุบันนักพัฒนาแอปบุคคลที่สามไม่มีสิทธิ์เข้าถึงข้อมูลที่จำเป็นต่อการทําความเข้าใจผลกระทบของสคริปต์ต่อเว็บไซต์โดยรวม เราวางแผนที่จะแก้ไขปัญหานี้และจัดหาเครื่องมือวิเคราะห์ผลกระทบให้แก่ผู้ให้บริการเหล่านี้ รวมถึงเปรียบเทียบกับผลิตภัณฑ์อื่นๆ ในตลาดที่ให้คุณค่าเดียวกัน นอกจากนี้ เรายังต้องการช่วยให้นักพัฒนาแอปใช้ข้อมูลเพื่อวิเคราะห์สาเหตุของผลกระทบเพื่อให้สามารถลดผลกระทบได้ตั้งแต่ต้น เราจะต้องระบุบุคคลที่สามทั้งหมด รวมถึงบุคคลที่สามที่ Google เป็นผู้เขียน เพื่อให้ดำเนินการนี้สำเร็จ
ความท้าทาย
การดำเนินการที่ยิ่งใหญ่ขนาดนี้ย่อมมีปัญหาอยู่บ้าง ความท้าทายหลักๆ ที่เราต้องพิจารณามีดังนี้
- บุคคลที่สามเป็นปัญหาที่ส่งผลกระทบข้ามสายงาน ซึ่งรวมถึงโฆษณา ข้อมูลวิเคราะห์ การจัดการแท็ก ยูทิลิตี และอื่นๆ อีกมากมาย แต่ละด้านต้องพิจารณาชุดข้อกำหนดและการแลกเปลี่ยนที่ไม่ซ้ำกัน เช่น
- การตัดสินใจเพิ่มประสิทธิภาพการโหลดโฆษณาขึ้นอยู่กับการแลกเปลี่ยนระหว่างรายได้กับประสบการณ์ของผู้ใช้ หากแสดงโฆษณาก่อนเวลา โฆษณาจะบล็อกเนื้อหาที่มีคุณค่า และหากแสดงโฆษณาช้าเกินไป ผู้ใช้อาจไม่เห็นโฆษณา
- สคริปต์ Analytics จะเพิ่มขนาดหน้าเว็บ แต่ให้ข้อมูลที่เป็นประโยชน์เกี่ยวกับการกระทำของผู้ใช้แก่ธุรกิจ
เราหวังว่าจะได้เป็นพาร์ทเนอร์กับบุคคลที่สามในหมวดหมู่ต่างๆ เข้าใจความแตกต่างที่เกี่ยวข้อง แก้ปัญหาการแลกเปลี่ยน และสร้างแรงจูงใจที่เหมาะกับทุกคน เราตระหนักดีว่าต้องทํางานร่วมกับหน่วยงานต่างๆ ในแต่ละพื้นที่แยกกันเพื่อให้กลยุทธ์ของเรามีประสิทธิภาพ ซึ่งรวมถึงพาร์ทเนอร์ภายในของเรา เช่น Google Tag Manager, Google Ads และ YouTube
เราต้องการระบุแหล่งที่มาที่ละเอียดยิ่งขึ้นให้แก่ทั้งนักพัฒนาเว็บไซต์และนักพัฒนาบุคคลที่สาม กระบวนการนี้ต้องใช้ความพยายามอย่างรอบคอบในการระบุข้อมูลที่มีความเกี่ยวข้องมากที่สุดในการวัดผล ระบุแหล่งที่มาอย่างถูกต้องและละเอียด และระบุแนวทางที่ถูกต้อง ท้ายที่สุดแล้ว การคำนวณประสิทธิภาพของบุคคลที่สามหนึ่งๆ เทียบกับคู่แข่งควรมีความโปร่งใสสำหรับทุกคน
เราขอเสนอให้ปรับปรุง Chrome เพื่อให้ใช้การเพิ่มประสิทธิภาพที่จะช่วยสร้างสมดุลที่เหมาะสมในการกำหนดลำดับความสำคัญของการโหลดทรัพยากรของบุคคลที่สามเทียบกับทรัพยากรของบุคคลที่หนึ่ง การเปลี่ยนแปลงที่มีประโยชน์จะพร้อมใช้งานเป็นมาตรฐานในเบราว์เซอร์ทุกรุ่น แต่อาจใช้เวลาสักระยะ เช่น แอตทริบิวต์
loading
สำหรับองค์ประกอบ<img>
และ<iframe>
มีให้บริการใน Chrome/Edge ตั้งแต่ปี 2019 แต่พร้อมใช้งานใน Safari ในปี 2022 เท่านั้น ผู้ใช้ทรัพยากรของบุคคลที่สามจะต้องตรวจสอบว่าได้เพิ่มประสิทธิภาพสำหรับเบราว์เซอร์อื่นๆ ด้วยจนกว่าฟีเจอร์จะได้รับการทำให้เป็นมาตรฐาน เราจะช่วยเหลือโดยไฮไลต์เรื่องนี้ในคำแนะนำที่เกี่ยวข้องหากต้องการดำเนินโปรเจ็กต์นี้ เราจะต้องมีส่วนร่วมกับพาร์ทเนอร์และนักพัฒนาแอปไม่เพียงเพื่อช่วยให้เข้าใจข้อกำหนดเฉพาะเท่านั้น แต่ยังเพื่อทดสอบโซลูชันเวอร์ชันทดลองในวงกว้าง แสดงความคิดเห็น ปรับปรุง และดัดแปลงตามที่จำเป็น การเปลี่ยนแปลงจะต้องมีการวางแผนเพื่อให้มีกรอบเวลาที่เหมาะสมสำหรับการทดสอบและการประเมิน
ข้อเสนอมาตรฐานเบื้องต้น
เราได้ทำการทดสอบเบื้องต้นเพื่อพัฒนาฟีเจอร์ที่เปิดใช้เพื่อเพิ่มประสิทธิภาพกระบวนการโหลดของบุคคลที่สามได้ เรายินดีกับผลลัพธ์ที่ได้ และตอนนี้สามารถพูดคุยเกี่ยวกับฟีเจอร์ 2 รายการนี้ได้
LazyEmbeds
ก่อนหน้านี้ Chrome จะโหลดแบบเลื่อนองค์ประกอบ <img>
และ <iframe>
ที่อยู่นอกหน้าจอสำหรับผู้ใช้โหมด Lite ฟีเจอร์นี้อาจขยายการให้บริการไปยังผู้ใช้ทุกคนเพื่อเลื่อนการโหลดองค์ประกอบ <iframe>
ที่ระบุว่าเป็นการฝังของบุคคลที่สามจนกว่าผู้ใช้จะเลื่อนไปใกล้องค์ประกอบดังกล่าว ซึ่งอาจช่วยเร่งการโหลดส่วนอื่นๆ ของหน้าเว็บ ปรับปรุง Core Web Vitals ลดการใช้หน่วยความจํา และประหยัดอินเทอร์เน็ต
ต่อไปนี้เป็นตัวอย่างการใช้ LazyEmbeds เพื่อโหลดวิดีโอ YouTube แบบ Lazy Load ในหน้าเว็บ โดยปกติแล้วการฝังวิดีโอ YouTube รายการเดียวจะเพิ่ม JavaScript ประมาณ 500-600 KB ลงในหน้าเว็บ เราพยายามเพิ่มประสิทธิภาพบล็อกโพสต์ที่มีการฝังวิดีโอดังกล่าว 14 รายการโดยใช้ LazyEmbeds ผลลัพธ์ที่ได้มีความน่าพอใจในด้านเวลาในการโหลดหน้าเว็บและประหยัดอินเทอร์เน็ต
ก่อน | หลัง | |
---|---|---|
ข้อมูล | 15.4 MB | 6.1 MB |
เวลาทั้งหมดในการบล็อก | 3.2 วินาที | 1.6 วินาที |
ดูข้อมูลเพิ่มเติมเกี่ยวกับงานนี้ได้ที่คำอธิบายและชุดข้อความแสดงเจตนาทดสอบและส่วนขยายการทดสอบใน blink-dev
การจํากัดของบุคคลที่สามที่กําหนดเป้าหมาย
ทีมต่างๆ มักเพิ่มสคริปต์ของบุคคลที่สามโดยไม่มีกระบวนการควบคุมดูแลที่ครอบคลุม ทีมวิศวกรของ The Telegraph อธิบายว่า "ทุกคนต้องการ "แท็กนั้น" ในหน้าเว็บที่จะทำให้องค์กรมีรายได้" ซึ่งอาจเพิ่มภาระในการจัดการผลกระทบด้านประสิทธิภาพอย่างต่อเนื่อง
การจำกัดสคริปต์ของบุคคลที่สามที่กำหนดเป้าหมายจะเสนอการจำกัดบุคคลที่สามบางประเภทที่เฉพาะเจาะจงเพื่อลดผลกระทบ วิธีนี้จะช่วยให้เบราว์เซอร์โหลดเนื้อหาหลักและบุคคลที่สามที่สำคัญได้ตั้งแต่เนิ่นๆ ส่วนเนื้อหาที่โหลดได้ภายหลังจะได้รับการจำกัด
การปรับปรุง RUM API
นอกจากนี้ เรายังพิจารณาที่จะปรับปรุง RUM API ให้รวมข้อมูลที่จะใช้ประเมินประสิทธิภาพของบุคคลที่สามด้วย การปรับปรุงมีดังนี้
การรายงาน
<iframe>
: เรากําลังพัฒนาโซลูชันที่สามารถใช้ประโยชน์จาก Performance Timeline API สําหรับการรายงานข้ามเฟรม ซึ่งจะช่วยให้ผู้เขียนหน้าระดับบนสุดตรวจสอบข้อมูลประสิทธิภาพของ iframe ของบุคคลที่สามที่ร่วมมือกันซึ่งฝังอยู่ในหน้าได้การระบุแหล่งที่มาของงานที่ใช้เวลานาน: Long Tasks API ใน RUM จะช่วยให้เจ้าของเว็บไซต์ระบุงานที่ใช้เวลานานซึ่งใช้ชุดข้อความหลักเป็นเวลานานและทำให้โต้ตอบล่าช้า
การอัปเดตเพิ่มเติม
เรายังคงทดสอบไอเดียต่างๆ ดังกล่าวอยู่และหวังว่าจะเผยแพร่คำอธิบายและร่างข้อกำหนดสำหรับการเปลี่ยนแปลงใน GitHub บุคคลที่สามและเจ้าของเว็บไซต์ที่ต้องการเป็นพาร์ทเนอร์กับเราหรือแสดงความคิดเห็นสามารถมีส่วนร่วมในการสนทนาผ่านช่องทางเหล่านี้ นอกจากนี้ บุคคลที่สามยังเริ่มมุ่งเน้นที่การเพิ่มประสิทธิภาพสำหรับเมตริก Core Web Vitals และ INP เพื่อให้แน่ใจว่าข้อมูล Core Web Vitals/INP ที่ไม่เป็นไปตามเกณฑ์ไม่ได้มาจากบุคคลที่สาม ในระหว่างนี้ ผู้ที่กำลังมองหาข้อมูลอัปเดตอยู่สามารถดูโพสต์ในกลุ่ม blink-dev
เราหวังว่าจะได้สำรวจปัญหานี้เพิ่มเติมและแชร์สิ่งที่ได้เรียนรู้กับชุมชน
ขอขอบคุณเป็นพิเศษ Leena Sohoni-Kasture, Jeremy Wagner, Gilberto Cocchi, Kenji Baheux, Kouhei Ueno, Kentaro Hara, Alex N. Jose, Melissa Mitchell, Yoav Weiss, Shunya Shishido และ Minoru Chikamune สำหรับความคิดเห็นและความช่วยเหลือ