วิธีที่แพลตฟอร์มการจัดการความยินยอมของ PubTech ลด INP ของเว็บไซต์ของลูกค้าได้มากถึง 64% และเพิ่มการมองเห็นโฆษณาได้ถึง 1.5%

วิธีที่ PubConsent CMP ลด INP ของลูกค้าได้ถึง 64% โดยใช้กลยุทธ์ผลตอบแทนที่ใช้ API เครื่องจัดตารางเวลาของเบราว์เซอร์เพื่อแก้ปัญหาการปรับเปลี่ยนตามอุปกรณ์ที่ตรวจพบโดยใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

Marco Prontera
Marco Prontera
Gilberto Cocchi
Gilberto Cocchi

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

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

การใช้เมตริก Interaction to Next Paint (INP) ช่วยให้ PubTech ค้นพบปัญหาเกี่ยวกับการตอบสนองของ CMP ได้ ในกรณีศึกษานี้ PubTech ได้แสดงให้เห็นถึงวิธีการแก้ไขปัญหาด้วยการตอบสนองในแพลตฟอร์ม PubConsent CMP และวิธีการปรับปรุง INP ก่อนที่จะกลายเป็นหนึ่งใน Core Web Vitals ในเดือนมีนาคม 2024 ซึ่งแสดงให้เห็นถึงความมุ่งมั่นในการจัดหาประสิทธิภาพที่ดีที่สุดเท่าที่จะเป็นไปได้ในผลิตภัณฑ์ CMP

เหตุใด PubTech จึงสนใจประสิทธิภาพ

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

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

เมื่อพิจารณาความสำคัญของฟังก์ชันที่ CMP มีและผลกระทบที่อาจมีต่อประสิทธิภาพ PubTech ได้ตั้งเป้าหมายต่อไปนี้

  1. ลดผลกระทบที่ผลิตภัณฑ์ PubConsent CMP มีต่อ INP
  2. ลดงานที่ใช้เวลานานซึ่งมาจากผลิตภัณฑ์ CMP
  3. ลดเวลาในการบล็อกทั้งหมด (TBT) ซึ่งอาจส่งผลเสียต่อ INP ของหน้าเว็บ

วิธีวัด INP

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

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

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

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

ในการปรับปรุง INP เราได้นำกลยุทธ์ผลตอบแทนต่างๆ มาใช้ใน PubConsent CMP

ให้งานที่มีลำดับความสำคัญสูง

เมธอด yieldToMainUiBlocking ที่แสดงในข้อมูลโค้ดต่อไปนี้ออกแบบมาเพื่อเพิ่มประสิทธิภาพงาน JavaScript ที่มีลำดับความสำคัญสูงโดยให้ผลตอบแทนด้วย scheduler.yield (หากมี) แต่กลับไปใช้ postTask ที่มีลำดับความสำคัญ user-blocking (สูง) หากมี postTask และสุดท้ายจะกลับไม่มีการเปลี่ยนแปลงใดๆ

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

function yieldToMainUiBlocking () {
  return new Promise((resolve) => {
    if ('scheduler' in window) {
      if ('yield' in window.scheduler) {
        return window.scheduler.yield().then(() => resolve(true));
      }

      if ('postTask' in window.scheduler) {
        return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
      }
    }

    resolve(false);
  });
};

ผลตอบแทนในงานระดับปานกลางและในเบื้องหลัง

เมธอด yieldToMainBackground ที่แสดงในข้อมูลโค้ดต่อไปนี้จะใช้เพื่อแบ่งงานที่ยาวซึ่งมีลำดับความสำคัญ user-visible (ปานกลาง) หรือ background ตรรกะจะใช้ scheduler.yield() หากพร้อมใช้งาน แต่จะแตกต่างกันด้วยการใช้ postTask ที่มีลำดับความสำคัญปานกลาง และสุดท้ายจะกลับไปใช้ setTimeout ในเบราว์เซอร์ที่ไม่ใช่ Chromium

function yieldToMainBackground () {
  return new Promise((resolve) => {
    if ('scheduler' in window) {
      if ('yield' in window.scheduler) {
        return window.scheduler.yield().then(() => resolve(true));
      }

      if ('postTask' in window.scheduler) {
        return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
      }
    }

    setTimeout(() => { resolve(true) }, 0);
  });
};
โฟลว์แสดงระยะเวลาของงานซึ่งบล็อกไม่ให้อินเทอร์เฟซผู้ใช้อัปเดตหลังจากที่ผู้ใช้คลิกปุ่ม "ยอมรับทั้งหมด" ใน PubConsent CMP แล้ว ตอนนี้ทั้ง 5 ขั้นตอนจะให้ผลดีที่สุดเท่าที่ทำได้ ซึ่งช่วยให้อินเทอร์เฟซผู้ใช้อัปเดตการแสดงผลได้เร็วขึ้น
การนำเสนอแบบเห็นภาพว่าการใช้ yieldToMainBackground ช่วยให้เบราว์เซอร์แสดงผลการแสดงผลครั้งถัดไป (ปิด UI ของ CMP ในกรณีนี้) ได้เร็วขึ้นอย่างไร

PubTech ลด TBT ด้วยการเพิ่มประสิทธิภาพเลย์เอาต์การแสดงผลได้อย่างไร

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

ภาพหน้าจอของแผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ซึ่งแสดงส่วนของการติดตามที่มีสแต็กการเรียกใช้กิจกรรมเพื่อปิดกล่องโต้ตอบ UI ใน PubConsent CMP งานปิดกล่องโต้ตอบ UI จะทริกเกอร์การลบโหนด DOM ที่เพิ่มความล่าช้าในการนำเสนอของการโต้ตอบ

เราได้แนะนำโซลูชันที่ทีมเรียกว่า "การลดการแสดงผลแบบ Lazy Loading" เพื่อจัดการกับปริมาณการแสดงผลที่เพิ่มขึ้นซึ่งจำเป็นต่อการนำองค์ประกอบออกจาก DOM วิธีนี้จะนำกฎ CSS display: none ไปใช้กับกล่องโต้ตอบความยินยอมของ CMP ก่อนหลังจากที่ผู้ใช้ให้ความยินยอมในการซ่อน จากนั้นการนำโหนด DOM ที่เชื่อมโยงกับกล่องโต้ตอบ CMP ออกจะย้ายไปยังช่วงเวลาถัดไปเมื่อเบราว์เซอร์ไม่มีการใช้งานโดยใช้ requestIdleCallback ซึ่งวิธีนี้พบว่ารวดเร็วกว่าการนำโหนด DOM ออกในขณะที่ผู้ใช้ปิดกล่องโต้ตอบความยินยอม

ภาพหน้าจอของแผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ซึ่งแสดงการติดตามเหมือนกับก่อนหน้านี้แต่ได้รับการเพิ่มประสิทธิภาพ เมื่อกล่องโต้ตอบของ PubConsent CMP ปิดอยู่ การดำเนินการเริ่มต้นคือการซ่อนโดยใช้กฎการแสดงผล CSS: ไม่มี จากนั้นเมื่อไม่มีการใช้งานเบราว์เซอร์ในภายหลัง จึงจะนำโหนด DOM ออก
ภาพหน้าจอของเครื่องมือสำหรับนักพัฒนาเว็บที่ไฮไลต์การปรับปรุง INP โดยการเปลี่ยนงานการนำ DOM ออก

PubTech ลด INP เพิ่มเติมโดยการปรับปรุงไลบรารี TCF ของ IAB ได้อย่างไร

หลังจากแก้ไขปัญหาการตอบสนองส่วนใหญ่ของ CMP เรียบร้อยแล้ว เราพบโอกาสในการปรับปรุงเพิ่มเติมในทรัพยากร Dependency หลักอย่างหนึ่ง ซึ่งก็คือไลบรารีกรอบความโปร่งใสและความยินยอม (TCF) ของ IAB

คอมโพเนนต์ที่มีต้นทุนทางการคำนวณมากที่สุดของไลบรารีนี้คือ "สร้างสตริง" และ "ส่งความยินยอม" คอมโพเนนต์เหล่านี้เป็นส่วนประกอบที่สำคัญของไลบรารี TCF ของ IAB การเพิ่มประสิทธิภาพต่อไปนี้กับคอมโพเนนต์เหล่านี้ถูกนำไปใช้ใน Fork ที่แยกต่างหากสำหรับความต้องการของ PubTech โดยเฉพาะ

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

การเพิ่มประสิทธิภาพครั้งแรกช่วยลดเวลาที่ CMP ใช้ในการเรียกกลับของบุคคลที่สามแต่ละครั้งที่เชื่อมต่อกับไลบรารี TCF ของ IAB การเพิ่มประสิทธิภาพรายการที่ 2 ลดระยะเวลาการประมวลผลที่เกิดจากคอมโพเนนต์ "สร้างสตริง" ซึ่งการเพิ่มประสิทธิภาพนี้ช่วยให้ลดการวนซ้ำได้สูงสุด 60% ที่ดำเนินการทุกครั้งที่ผู้ใช้แสดงความยินยอม

ผลลัพธ์

การใช้กลยุทธ์ผลตอบแทนเดิมและการเพิ่มประสิทธิภาพเลย์เอาต์การแสดงผลแบบใหม่ INP ของ CMP เพิ่มขึ้นถึง 65% การตอบสนองประสบการณ์ของผู้ใช้ CMP ใน PubConsent CMP ดีขึ้นอย่างมาก และสำหรับโฆษณาบางประเภท การมองเห็นโฆษณายังเพิ่มขึ้นถึง 1.5% โดยการเพิ่มประสิทธิภาพเมื่อมีการขอโฆษณา

นอกเหนือจากการปรับปรุงเหล่านี้แล้ว ในไลบรารี TCF ของ IAB ยังพบว่า INP ดีขึ้นถึง 77% บนอุปกรณ์เคลื่อนที่ ซึ่งเป็นผลมาจากการลดงานยาวๆ ที่เกิดจาก TCF ได้ถึง 85% วิธีนี้ช่วยลดค่าใช้จ่ายของการเรียกกลับของบุคคลที่สามที่ดำเนินการไปตลอดทั้งวงจรของหน้าเว็บได้อย่างมาก

จำนวนต้นทางที่ผ่าน INP เมื่อใช้ PubConsent CMP เพิ่มขึ้นมากกว่า 400% เพิ่มขึ้นจาก 13% เป็น 55% บนอุปกรณ์เคลื่อนที่ สำหรับลูกค้าบางราย จำนวน INP ของหน้าเว็บลดลงเกินครึ่งหนึ่งจาก 470 มิลลิวินาทีเป็น 230 มิลลิวินาที อันเนื่องมาจากการเพิ่มประสิทธิภาพ PubTech SDK ที่เกิดขึ้น

ภาพหน้าจอของอัตราการส่งผ่าน INP ต้นทางสำหรับเว็บไซต์ที่ใช้ PubTech CMP ส่วนในเดสก์ท็อป อัตราการสอบผ่านจะเพิ่มขึ้นเป็น 99.12% จากประมาณ 84% บนอุปกรณ์เคลื่อนที่ อัตราการส่งผ่านจะเพิ่มขึ้นเป็น 55.46% จากประมาณ 22%
อัตราการส่งผ่าน INP ต้นทางสำหรับเว็บไซต์ที่ใช้ PubTech CMP ตามที่รายงานในที่เก็บถาวรของ HTTP และรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX)
ภาพหน้าจอของแดชบอร์ดที่แสดง INP จากข้อมูล RUM ที่เปอร์เซ็นไทล์ที่ 75 ตั้งแต่เดือนกรกฎาคม/ส.ค. 2023 INP ต่ำกว่า 500 มิลลิวินาที แต่ภายในกลางเดือนกุมภาพันธ์ 2024 INP ต่ำกว่า 200 มิลลิวินาทีเท่านั้น ซึ่งทำให้อยู่ในเกณฑ์ "ดี"
แนวโน้มการปรับปรุงข้อมูล INP บนอุปกรณ์เคลื่อนที่ของลูกค้า PubConsent ซึ่งสัมพันธ์กับการเปลี่ยนแปลงของ SDK ที่อธิบายไว้ในกรณีศึกษานี้

บทสรุป

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

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

ขอขอบคุณ Luca Coppola, CTO ของ PubTech ที่สนับสนุนผลงานด้านนวัตกรรมนี้ รวมถึงขอขอบคุณ Jeremy Wagner, Michal Mocny และ Rick Viscomi จาก Google