ปัจจุบันทรัพยากรของบุคคลที่สาม (เช่น การฝังและสคริปต์) มีการใช้อย่างแพร่หลายบนเว็บ แพลตฟอร์มเหล่านี้ให้บริการโซลูชันแบบพร้อมใช้งานทันทีสำหรับการฝังโซเชียลมีเดีย, วิดีโอ, Analytics, แชทสด, การโฆษณา, การทดสอบ A/B, การปรับเปลี่ยนในแบบของคุณ และอื่นๆ การฝังของบุคคลที่สามเป็นส่วนที่จำเป็นของเว็บไซต์สมัยใหม่ ซึ่งช่วยให้เจ้าของเว็บไซต์สามารถมุ่งเน้นที่ประสิทธิภาพหลัก ขณะเดียวกันก็ลดภาระของฟังก์ชันมาตรฐานแต่สำคัญต่อผู้ให้บริการภายนอกเข้ามา
เมื่อหน้าเว็บทั้งบุคคลที่หนึ่งและบุคคลที่สามทำงานด้วยกัน ก็เป็นไปได้ที่หน้าเว็บจะให้ประสบการณ์ที่ยอดเยี่ยมแก่ผู้ใช้ อย่างไรก็ตาม ทั้งทีมวิศวกรและทีมธุรกิจต้องทำงานอย่างหนักและมักถูกมองข้ามซึ่งส่งผลให้หน้าเว็บมีประสิทธิภาพน้อยกว่าหน้าเว็บที่มีประสิทธิภาพ รวมถึงมีผลลบต่อเมตริกที่เน้นผู้ใช้เป็นหลัก เช่น Core Web Vitals ซึ่งจะส่งผลเสียต่อทั้ง 2 ฝ่ายและทำให้เกิดโอกาสที่ธุรกิจต่างๆ พลาดไป เราควรปรับปรุงให้ดีขึ้นไหม
เรามีวิสัยทัศน์ในอนาคตเกี่ยวกับเว็บที่สคริปต์และทรัพยากรของบุคคลที่สามมอบคุณค่าทางธุรกิจที่ต้องการ โดยลดทอนประสิทธิภาพหรือประสบการณ์ของผู้ใช้เว็บไซต์ที่ใช้สคริปต์หรือเบราว์เซอร์ในเบราว์เซอร์ ซึ่งจะช่วยให้ผู้ใช้โหลดหน้าเว็บได้เร็วขึ้น
ในช่วงปีที่ผ่านมา เราได้พิจารณา หารือ และทดลองความเป็นไปได้มากมายที่อาจปกป้องประสบการณ์ของผู้ใช้จากผลกระทบที่เป็นอันตรายจากสคริปต์ของบุคคลที่สามโดยไม่ลดคุณค่าทางธุรกิจของผู้ที่เป็นเจ้าของเว็บไซต์
ในโพสต์นี้เราต้องการแชร์ข้อมูลเกี่ยวกับการทดลองบางส่วนของเรา เราหวังว่านี่จะเป็นการเริ่มต้นกระบวนการในการส่งเสริมความโปร่งใสและระดับการเข้าถึงระหว่าง User Agent, ธุรกิจ และผู้ให้บริการบุคคลที่สาม รวมทั้งช่วยปูทางสู่เว็บที่เร็วขึ้น
เจาะลึกเกี่ยวกับบุคคลที่สาม
บุคคลที่สามคือทรัพยากรที่ให้บริการโดยผู้ให้บริการภายนอกเว็บไซต์ คุกกี้ไม่ได้อยู่ภายใต้การควบคุมของเจ้าของเว็บไซต์โดยตรง แต่อยู่ในการควบคุมของเจ้าของเว็บไซต์ ทรัพยากรของบุคคลที่สาม ได้แก่
- โฮสต์บนต้นทางที่แชร์และสาธารณะที่แตกต่างจากต้นทางของเว็บไซต์หลัก
- ไม่ได้เขียนหรือได้รับอิทธิพลจากเจ้าของเว็บไซต์แต่ละราย
- เว็บไซต์จำนวนมากใช้กันอย่างแพร่หลาย
ตั้งแต่การช่วยสร้างรายได้ (ผ่านโฆษณา) ไปจนถึงการมอบโอกาสทางการตลาดที่ดีขึ้น (การฝังโซเชียลมีเดีย) บุคคลที่สามสามารถตอบสนองวัตถุประสงค์ทางธุรกิจที่หลากหลาย หมวดหมู่ทั่วไปของบุคคลที่สามมีดังนี้
แหล่งที่มา: บุคคลที่สามตามหมวดหมู่
หมวดหมู่ | คำจำกัดความ |
---|---|
การโฆษณา | สคริปต์ที่ใช้สำหรับการแสดงโฆษณาหรือวัดประสิทธิภาพโฆษณา |
วิดีโอ | สคริปต์ที่เปิดใช้ฟังก์ชันโปรแกรมเล่นวิดีโอและสตรีมมิง |
ไลบรารีที่โฮสต์ | การผสมของไลบรารีโอเพนซอร์สที่โฮสต์แบบสาธารณะ |
เนื้อหา | สคริปต์จากผู้ให้บริการเนื้อหาหรือการติดตามแอฟฟิลิเอตสำหรับการเผยแพร่โดยเฉพาะ |
ความสำเร็จของลูกค้า | สคริปต์จากผู้ให้บริการการสนับสนุนลูกค้า/การตลาดที่เสนอโซลูชันการแชทและการติดต่อ |
โฮสติ้ง | สคริปต์จากแพลตฟอร์มเว็บโฮสติ้ง |
Marketing | สคริปต์จากเครื่องมือทางการตลาดที่เพิ่มป๊อปอัป จดหมายข่าว และอื่นๆ |
โซเชียล | สคริปต์ที่เปิดใช้ฟีเจอร์โซเชียล |
Tag Manager | สคริปต์ที่โหลดสคริปต์อื่นๆ จำนวนมากและเริ่มต้นงานจำนวนมาก |
Analytics | สคริปต์ที่วัดหรือติดตามผู้ใช้และการดำเนินการของผู้ใช้ |
แพลตฟอร์มความยินยอมในการใช้คุกกี้ | สคริปต์ที่อนุญาตให้เว็บไซต์ขอความยินยอมจากผู้ใช้ (GDPR, ePR, CCPA) อย่างมีข้อมูลและโปร่งใส |
ยูทิลิตี | สคริปต์ที่เป็นยูทิลิตีสำหรับนักพัฒนาซอฟต์แวร์ (ไคลเอ็นต์ API, การตรวจสอบเว็บไซต์, การตรวจจับการฉ้อโกง และอื่นๆ |
อื่นๆ | สคริปต์เบ็ดเตล็ดที่ส่งผ่านต้นทางที่ใช้ร่วมกันโดยไม่มีหมวดหมู่หรือการระบุแหล่งที่มาที่แน่นอน |
สคริปต์และไลบรารีของบุคคลที่สามเหล่านี้ช่วยให้นักพัฒนาเว็บใช้ประโยชน์จากโซลูชันที่ผ่านการทดลองและทดสอบเพื่อติดตั้งใช้งานฟีเจอร์มาตรฐานได้แล้ว แทนที่จะต้องสร้างใหม่ ดังนั้น ผู้ให้บริการบุคคลที่สามจึงลดเวลาในการพัฒนา และช่วยให้ธุรกิจเปิดตัวหรืออัปเกรดผลิตภัณฑ์ได้เร็วขึ้น จึงไม่น่าแปลกใจที่กว่า 94% ของเว็บไซต์ทั้งหมดบนเดสก์ท็อปและอุปกรณ์เคลื่อนที่นั้นใช้บุคคลที่สาม
บุคคลที่สามส่งผลต่อประสิทธิภาพอย่างไร
โดยหลักการแล้ว นักพัฒนาซอฟต์แวร์ของบุคคลที่สามคือผู้เชี่ยวชาญด้านฟีเจอร์เฉพาะที่ให้บริการ ผู้ให้บริการบุคคลที่สามที่ได้รับความนิยมส่วนใหญ่ผ่านการปรับปรุงหลายครั้ง และอาจคาดหวังได้ว่าโค้ดของตนจะได้รับการเพิ่มประสิทธิภาพเพื่อเป้าหมายทางธุรกิจของตน ซึ่งอาจรวมหรือไม่รวมประสิทธิภาพของหน้าเว็บที่ใช้โค้ดดังกล่าวก็ได้ อย่างไรก็ตาม เรารู้ว่าแม้แต่บุคคลที่สามที่ได้รับการเพิ่มประสิทธิภาพมากที่สุดก็ส่งผลต่อประสิทธิภาพด้วย สาเหตุหลักของผลกระทบดังกล่าวมีดังนี้
ต้นทุนในการดำเนินการด้านขนาดและสคริปต์: บุคคลที่สามมักจะมุ่งหวังที่จะให้ฟังก์ชันการทำงานที่สำคัญ "เฉพาะ" โดยการวางองค์ประกอบ
<script>
หรือ<iframe>
ลงในหน้าเว็บ จากนั้นองค์ประกอบเหล่านี้จะดึงสคริปต์และทรัพยากรซึ่งมีขนาดที่มากและใช้เวลาในการดาวน์โหลดและเรียกใช้นานกว่า เมื่อมี JavaScript มากเกินไป เทรดหลักจะไม่ว่างอีกต่อไป บล็อกการแสดงผล และทําให้การโต้ตอบของผู้ใช้ล่าช้า เราพบว่าบุคคลที่สามชั้นนำบางรายบล็อกเทรดหลักจาก 42 มิลลิวินาทีเป็น 1.6 วินาที สําหรับเว็บไซต์ที่วิเคราะห์มากกว่า 50% เทรดหลักที่บล็อกส่งผลให้มีเวลาในการบล็อกทั้งหมด (TBT) สูง ซึ่งเป็นหนึ่งในเมตริกที่มีผลต่อคะแนนประสิทธิภาพของเว็บไซต์ นอกจากนี้ ยังทําให้การตอบสนองล่าช้าต่อการโต้ตอบของผู้ใช้และทำให้เมตริกการโต้ตอบกับ 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% อยู่แล้ว" - เว็บของบุคคลที่สาม
หน้าที่แสดงผลอย่างรวดเร็วและโต้ตอบได้ภายในกรอบเวลาที่เหมาะสมนั้นสำคัญต่อประสบการณ์ของผู้ใช้ที่ดีซึ่งวัดโดย 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 และรายงานประสบการณ์ของผู้ใช้ Chrome เราเสนอที่จะปรับปรุง API และเครื่องมือต่างๆ ที่มีอยู่ เพื่อให้นักพัฒนาซอฟต์แวร์เว็บไซต์เข้าใจถึงผลกระทบของบุคคลที่สามทุกรายที่ตนใช้ในทุกๆ หน้า เครื่องมือเหล่านี้จะยังให้ความรู้แก่พวกเขาเกี่ยวกับการดําเนินการที่จะช่วยลดผลกระทบ (เช่น เลื่อนเวลาออกไปหรือใช้ส่วนหน้า) และสำรวจโซลูชันอื่นๆ ที่เป็นไปได้ (บุคคลที่สามหรือ DIY อื่นๆ) ที่มีข้อดีข้อเสีย สําหรับ API การตรวจสอบประสิทธิภาพเว็บ เรากําลังสํารวจวิธีขยายการครอบคลุมทรัพยากรแบบข้ามต้นทางโดยไม่กระทบต่อความเป็นส่วนตัวและความปลอดภัยของผู้ใช้
**ช่วยให้ธุรกิจมีเส้นทางแสงสว่างเพียงพอเพื่อโหลดทรัพยากรของบุคคลที่สามได้อย่างมีประสิทธิภาพ**
เราจึงต้องการเสนอมาตรฐานใหม่ที่สนับสนุนให้เบราว์เซอร์เปรียบเทียบวิธีโหลดทรัพยากรของบุคคลที่หนึ่งกับบุคคลที่สามอย่างชาญฉลาดยิ่งขึ้น เพื่อให้ผู้ใช้ได้รับประสบการณ์การโหลดที่ดีขึ้น หลังจากนั้น เราจะไฮไลต์ข้อเสนอเหล่านี้บางส่วน เช่น เนื้อหาที่ฝังของบุคคลที่สามสำหรับการโหลดแบบ Lazy Loading โดยค่าเริ่มต้น หรือการใช้ลำดับความสำคัญของทรัพยากรที่แตกต่างออกไปกับทรัพยากรของบุคคลที่สามซึ่งอาจไม่สำคัญต่อเนื้อหาเริ่มแรกที่ผู้ใช้อาจสนใจมากที่สุด นี่เป็นเพียงแนวคิดส่วนเล็กๆ ที่เรากำลังประเมินในพื้นที่นี้ เราจึงอยากร่วมงานกับทั้งผู้เชี่ยวชาญด้านประสิทธิภาพเว็บและชุมชนในวงกว้างเพื่อสร้างผลงานนี้
ในทำนองเดียวกัน เรายังอยากแก้ไขปัญหานี้ในเฟรมเวิร์ก JavaScript และระบบจัดการเนื้อหา (CMS) ที่เหมาะสมมากกว่า โปรเจ็กต์ต่างๆ เช่น Aurora และทีมประสิทธิภาพของ WordPress ได้สอนเราถึงความสำคัญของค่าเริ่มต้นที่มีให้ใช้งานในตัว ซึ่งจะแก้ไขปัญหาการโหลดที่ทราบแล้ว ค่าเริ่มต้นที่อยู่ในเฟรมเวิร์กและ CMS จะช่วยนำทางธุรกิจตลอดเส้นทางที่มีแสงสว่างเพียงพอ และยังมีประโยชน์ต่อ User Agent (เช่น Chrome) ด้วย โดยเป็นคำแนะนำที่ช่วยให้ใช้การเรียนรู้เพื่อเพิ่มประสิทธิภาพการโหลดหน้าเว็บและ 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 จะโหลดแบบ Lazy Loading นอกหน้าจอ <img>
และ <iframe>
สําหรับผู้ใช้โหมด Lite เราอาจขยายการให้บริการฟีเจอร์นี้ไปยังผู้ใช้ทุกคนเพื่อเลื่อนเวลาโหลดองค์ประกอบ <iframe>
ที่ระบุว่าเป็นการฝังของบุคคลที่สาม จนกว่าผู้ใช้จะเลื่อนไปยังตำแหน่งดังกล่าว ซึ่งจะช่วยเร่งการโหลดส่วนอื่นๆ ของหน้าเว็บ, ปรับปรุง Core Web Vitals, ลดการใช้หน่วยความจำ และบันทึกข้อมูล
นี่คือการสาธิตที่ใช้ Lazy Loading เพื่อโหลดวิดีโอ YouTube แบบ Lazy Loading ในหน้าเว็บ โดยทั่วไปแล้ว การฝังวิดีโอ YouTube รายการเดียวจะเพิ่ม JavaScript ขนาด 500-600 KB ลงในหน้าเว็บ เราพยายามเพิ่มประสิทธิภาพบล็อกโพสต์ด้วยการฝังวิดีโอดังกล่าว 14 ครั้งโดยใช้ Lazyล่ะ ผลลัพธ์นี้มีแนวโน้มที่ดีในด้านเวลาในการโหลดหน้าเว็บและการประหยัดข้อมูล
ก่อน | หลัง | |
---|---|---|
ข้อมูล | 15.4 เมกะไบต์ | 6.1 เมกะไบต์ |
เวลาในการบล็อกทั้งหมด | 3.2 วินาที | 1.6 วินาที |
ดูข้อมูลเพิ่มเติมเกี่ยวกับงานนี้ได้ที่ชุดข้อความ intent-to-experiment และคำอธิบายแบบ Blink-dev และส่วนขยายการทดสอบ
การควบคุมของบุคคลที่สามที่กำหนดเป้าหมาย
ทีมต่างๆ มักจะเพิ่มสคริปต์ของบุคคลที่สามโดยไม่มีกระบวนการควบคุมดูแลแบบองค์รวม ทีมวิศวกรของ The Telegraph ชี้แจงว่า "ทุกคนต้องการ "แท็กนั้น" ในหน้าเว็บที่จะสร้างรายได้ให้องค์กร" ซึ่งอาจเพิ่มภาระในการจัดการผลกระทบด้านประสิทธิภาพอย่างต่อเนื่อง
การควบคุมสคริปต์ของบุคคลที่สามที่มีการกำหนดเป้าหมายเป็นความต้องการที่จะควบคุมบุคคลที่สามบางประเภทที่เฉพาะเจาะจงเพื่อลดผลกระทบของพวกเขา ซึ่งจะช่วยให้เบราว์เซอร์โหลดเนื้อหาสำคัญและบุคคลที่สามที่สำคัญได้ก่อนเวลา ในขณะที่ระบบจะควบคุมเนื้อหาที่โหลดได้อย่างปลอดภัยในภายหลัง
การปรับปรุง RUM API
นอกจากนี้ เรายังกำลังพิจารณาที่จะปรับปรุง RUM API ให้รวมข้อมูลที่เกี่ยวข้องในการประเมินประสิทธิภาพของบุคคลที่สามด้วย การเพิ่มประสิทธิภาพมีดังนี้
<iframe>
การรายงาน: เรากำลังพัฒนาโซลูชันที่สามารถใช้ประโยชน์จาก 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 สำหรับความคิดเห็นและการสนับสนุน