หน้านี้ได้รับการแปลโดย Cloud Translation API

การจัดการการแทรกแซงโฆษณาที่ใช้ทรัพยากรมาก

Rowan Merewood

Twitter GitHub กลิทช์ Mastodon

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

Chrome กำหนดขีดจำกัดทรัพยากรที่โฆษณาอาจใช้และยกเลิกการโหลดโฆษณานั้นหากมีการใช้งานเกินขีดจำกัด อ่านรายละเอียดเพิ่มเติมได้ในประกาศในบล็อก Chromium กลไกที่ใช้ในการยกเลิกการโหลดโฆษณาคือการแทรกแซงโฆษณาอย่างหนัก

เกณฑ์โฆษณาที่ใช้ทรัพยากรมาก

ระบบจะถือว่าโฆษณาหนักหากผู้ใช้ไม่ได้โต้ตอบกับโฆษณา (เช่น ไม่ได้แตะหรือคลิกโฆษณา) และโฆษณาเป็นไปตามเกณฑ์ข้อใดข้อหนึ่งต่อไปนี้

ใช้เทรดหลักรวมแล้วมากกว่า 60 วินาที
ใช้เทรดหลักนานกว่า 15 วินาทีในหน้าต่าง 30 วินาทีใดก็ได้
ใช้แบนด์วิดท์ของเครือข่ายมากกว่า 4 เมกะไบต์

ทรัพยากรทั้งหมดที่ใช้โดย iframe ระดับล่างของเฟรมโฆษณาจะนับรวมในขีดจำกัดสำหรับการแทรกแซงโฆษณานั้น โปรดทราบว่าขีดจำกัดของเวลาเทรดหลักต่างจากเวลาที่ผ่านไปตั้งแต่โหลดโฆษณา ขีดจำกัดจะขึ้นอยู่กับระยะเวลาที่ CPU ใช้ในการเรียกใช้โค้ดของโฆษณา

การทดสอบการฝึกฝน

การฝึกฝนดังกล่าวรวมอยู่ใน Chrome 85 แต่โดยค่าเริ่มต้น เกณฑ์จะเพิ่มข้อผิดพลาดและความแปรปรวนบางอย่างเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้

การตั้งค่า chrome://flags/#heavy-ad-privacy-mitigations เป็นปิดใช้จะนำการป้องกันเหล่านั้นออก ซึ่งหมายความว่าจะมีการใช้ข้อจำกัดต่างๆ ตามขีดจำกัดโดยเฉพาะ วิธีนี้ควรช่วยให้แก้ไขข้อบกพร่องและทดสอบได้ง่ายขึ้น

หมายเหตุ: Chrome เวอร์ชันก่อนหน้านี้มีแฟล็ก #heavy-ad-privacy-mitigations-opt-out และ #enable-heavy-ad-intervention สำหรับการทดสอบครั้งแรก หรือนำแฟล็กเหล่านี้ออกแล้ว

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

คุณดูการฝึกฝนที่ใช้กับเนื้อหาตัวอย่างได้ใน heavy-ads.glitch.me นอกจากนี้คุณยังใช้เว็บไซต์ทดสอบนี้เพื่อโหลด URL ที่กำหนดเองเป็นวิธีที่ทดสอบเนื้อหาของคุณเองได้อย่างรวดเร็วอีกด้วย

โปรดตระหนักว่าการทดสอบมีเหตุผลหลายประการที่อาจขัดขวางไม่ให้เกิดการฝึกฝน

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

สิ่งที่ต้องทำ

คุณแสดงโฆษณาจากผู้ให้บริการที่เป็นบุคคลที่สามในเว็บไซต์ของคุณ

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

คุณแสดงโฆษณาของบุคคลที่หนึ่งในเว็บไซต์ หรือแสดงโฆษณาสำหรับโฆษณาแบบดิสเพลย์ของบุคคลที่สาม

อ่านต่อเพื่อให้แน่ใจว่าคุณใช้การตรวจสอบที่จำเป็นผ่าน Reporting API สำหรับการแทรกแซงโฆษณาขนาดใหญ่

คุณสร้างเนื้อหาโฆษณา หรือดูแลรักษาเครื่องมือในการสร้างเนื้อหาโฆษณา

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

จะเกิดอะไรขึ้นเมื่อมีการนำโฆษณาออก

การฝึกฝนใน Chrome จะได้รับการรายงานผ่านชื่อที่เหมาะสม Reporting API พร้อมกับประเภทรายงานintervention คุณใช้ Reporting API เพื่อรับการแจ้งเตือนเกี่ยวกับการแทรกแซงผ่านทางคำขอ POST ที่ส่งไปยังปลายทางการรายงานหรือภายใน JavaScript ได้

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

หากต้องการกำหนดค่าหน้าเว็บสำหรับรายงาน HTTP การตอบกลับควรมีส่วนหัว Report-To:

Report-To: { "url": "https://example.com/reports", "max_age": 86400 }

คำขอ POST ที่ทริกเกอร์จะมีรายงานดังนี้

POST /reports HTTP/1.1
Host: example.com
…
Content-Type: application/report

[{
 "type": "intervention",
 "age": 60,
 "url": "https://example.com/url/of/ad.html",
 "body": {
   "sourceFile": null,
   "lineNumber": null,
   "columnNumber": null,
   "id": "HeavyAdIntervention",
   "message": "Ad was removed because its CPU usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384"
 }
}]

หมายเหตุ: ควรระบุค่า null การฝึกฝนจะทำงานเมื่อถึงจำนวนที่กำหนด แต่จุดที่เฉพาะเจาะจงในโค้ดไม่ได้เป็นปัญหาเสมอไป

JavaScript API ให้เมธอด observe() แก่ ReportingObserver ซึ่งใช้ทริกเกอร์โค้ดเรียกกลับที่ระบุไว้เมื่อการฝึกฝนได้ ซึ่งจะเป็นประโยชน์ในกรณีที่คุณต้องการแนบข้อมูลเพิ่มเติมไปกับรายงานเพื่อช่วยในการแก้ไขข้อบกพร่อง

// callback that will handle intervention reports
function sendReports(reports) {
  for (let report of reports) {
    // Log the `report` json via your own reporting process
    navigator.sendBeacon('https://report.example/your-endpoint', report);
  }
}

// create the observer with the callback
const observer = new ReportingObserver(
  (reports, observer) => {
    sendReports(reports);
  },
  { buffered: true }
);

// start watching for interventions
observer.observe();

อย่างไรก็ตาม เนื่องจากการแทรกแซงจะนำหน้าเว็บออกจาก iframe จริงๆ คุณควรเพิ่ม Safesafe เพื่อให้แน่ใจว่ามีการจับภาพหน้าจอจริงๆ ก่อนที่หน้าเว็บจะหายไปทั้งหมด เช่น โฆษณาภายใน iframe สำหรับวิธีนี้ คุณสามารถฮุกโค้ดเรียกกลับเดียวกันนี้ลงในเหตุการณ์ pagehide

window.addEventListener('pagehide', (event) => {
  // pull all pending reports from the queue
  let reports = observer.takeRecords();
  sendReports(reports);
});

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

JSON ที่ได้จาก JavaScript ที่ได้จะคล้ายกับที่ส่งในคำขอ POST ดังนี้

[
  {
    type: 'intervention',
    url: 'https://example.com/url/of/ad.html',
    body: {
      sourceFile: null,
      lineNumber: null,
      columnNumber: null,
      id: 'HeavyAdIntervention',
      message:
        'Ad was removed because its network usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384',
    },
  },
];

การวินิจฉัยสาเหตุของการฝึกฝน

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

คุณอาจพบว่าการทดสอบโฆษณาในบริบทแยกต่างหากมากขึ้นนั้นมีประโยชน์ คุณสามารถใช้ตัวเลือก URL ที่กำหนดเองใน https://heavy-ads.glitch.me เพื่อทดสอบกับ iframe สำเร็จรูปที่ติดแท็กโฆษณา คุณสามารถใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อตรวจสอบเนื้อหาที่แท็กเป็นโฆษณา ในแผงการแสดงผล (เข้าถึงได้ผ่านเมนู 3 จุด ⋮ จากนั้นเลือกเครื่องมือเพิ่มเติม > การแสดงผล) เลือก "ไฮไลต์เฟรมโฆษณา" หากทดสอบเนื้อหาในหน้าต่างระดับบนสุดหรือบริบทอื่นๆ ที่ไม่ได้ติดแท็กเป็นโฆษณา ระบบจะไม่ทริกเกอร์การฝึกฝน แต่คุณยังตรวจสอบเกณฑ์ด้วยตัวเองได้

สถานะโฆษณาของเฟรมจะแสดงในแผงองค์ประกอบด้วยโดยเพิ่มคำอธิบายประกอบ ad หลังแท็กเปิด <iframe> ข้อมูลนี้ดูในแผงแอปพลิเคชันในส่วนเฟรมได้ด้วย โดยเฟรมที่แท็กโฆษณาจะมีแอตทริบิวต์ "สถานะโฆษณา"

การใช้งานเครือข่าย

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

*แผงเครือข่ายในเครื่องมือสำหรับนักพัฒนาเว็บ*

ค่าที่โอนที่ด้านล่างของหน้าจะแสดงจำนวนเงินที่โอนสำหรับทั้งหน้าเว็บ ลองใช้อินพุตตัวกรองที่ด้านบนเพื่อจำกัดคำขอให้แสดงเฉพาะคำขอที่เกี่ยวข้องกับโฆษณาเท่านั้น

หากเห็นคำขอเริ่มต้นของโฆษณา เช่น แหล่งที่มาของ iframe คุณสามารถใช้แท็บ Initiator ภายในคำขอเพื่อดูคำขอทั้งหมดที่ทริกเกอร์

แท็บผู้เริ่มคำขอ — *แท็บผู้เริ่มต้นสำหรับคำขอ*

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

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

การใช้งาน CPU

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

*เปิดใช้การควบคุมเครือข่ายและ CPU ในแผงประสิทธิภาพ*

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

สำรวจแท็บ Bottom-Up Call Tree และบันทึกเหตุการณ์ที่ด้านล่าง การจัดเรียงคอลัมน์เหล่านั้นตามเวลาของตนเองและเวลารวมจะช่วยระบุจุดคอขวดในโค้ดได้

จัดเรียงตามเวลาของตัวคุณเองในแท็บ "ล่างขึ้นบน" — *จัดเรียงตามเวลาของตนเองในแท็บ "ล่างขึ้นบน"*

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

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

วิธีรายงานการแทรกแซงที่ไม่ถูกต้อง

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