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

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

Marco Prontera
Marco Prontera
Gilberto Cocchi
Gilberto Cocchi

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

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

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

เหตุใด PubTech จึงให้ความสำคัญกับประสิทธิภาพ

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

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

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

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

วิธีวัด INP

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

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

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

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

เราใช้กลยุทธ์ต่างๆ ในการสร้างรายได้ใน CMP ของ PubConsent เพื่อปรับปรุง INP

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

เมธอด 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);
  });
};
ขั้นตอนที่แสดงวิธีเพิ่มประสิทธิภาพงานที่ใช้เวลานานซึ่งบล็อกไม่ให้อินเทอร์เฟซผู้ใช้อัปเดตหลังจากที่ผู้ใช้คลิกปุ่ม "ยอมรับทั้งหมด" ใน CMP ของ PubConsent ตอนนี้ 5 ขั้นตอนจะทำงานเมื่อเป็นไปได้ ซึ่งช่วยให้อินเทอร์เฟซผู้ใช้อัปเดตการแสดงผลได้เร็วขึ้น
ภาพแสดงวิธีที่การแสดงผลโดยใช้ yieldToMainBackground ช่วยเบราว์เซอร์ให้แสดงผล Paint ถัดไป (การปิด UI ของ CMP ในกรณีนี้) ได้เร็วขึ้น

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

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

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

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

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

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

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

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

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

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

ผลลัพธ์

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

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

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

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

บทสรุป

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

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

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