תאריך פרסום: 22 בספטמבר 2025, תאריך עדכון אחרון: 7 בינואר 2026
למשתמשים, אין דבר מתסכל יותר מדף אינטרנט שפתאום מאט מאוד, מרוקן את הסוללה או צורך את כל חבילת הגלישה החודשית. לפעמים, הבעיה היא לא בתוכן שהם באו לראות, אלא במודעה שמוצגת ברקע.
כדי להגן על חוויית המשתמש, Chrome אוכף מגבלות על המשאבים שמודעה יכולה להשתמש בהם. כשמודעה חורגת מהמגבלות האלה – והופכת למודעה כבדה – Chrome מסיר אותה מהזיכרון כדי לפנות משאבים במכשיר.
במסמך הזה מוסבר איך פועל מנגנון ההתערבות, מהם ערכי הסף הספציפיים שקשורים אליו ומהן כמה שיטות מומלצות שיעזרו לכם לוודא שהמודעות יפעלו בצורה חלקה.
מהי התערבות לטיפול בבעיות של מודעות כבדות?
ההתערבות הכבדה בנושא מודעות היא מנגנון ב-Chrome שעוקב אחרי השימוש במשאבים של מסגרות מודעות. אם מודעה צורכת כמות לא פרופורציונלית של רוחב פס או של כוח עיבוד של המעבד (CPU), Chrome יבטל את הטעינה של מסגרת המודעה הספציפית הזו.
במקום המודעה, המשתמש יראה תיבה אפורה עם ההודעה המודעה הוסרה, בדרך כלל עם הקישור פרטים שבו מוסבר שהמודעה השתמשה ביותר מדי משאבים.
מתי מודעה נחשבת כבדה?
דפדפן Chrome קובע שמודעה היא כבדה על סמך שלושה ערכי סף ספציפיים. אם משתמש לא יצר אינטראקציה עם מודעה והיא עומדת באחד מהקריטריונים הבאים, היא תוסר:
- שימוש ברשת: המודעה משתמשת ביותר מארבעה מגה-בייט של רוחב פס ברשת.
- שימוש שיא במעבד: המודעה משתמשת בשרשור הראשי למשך יותר מ-15 שניות בכל חלון של 30 שניות.
- סה"כ שימוש במעבד: המודעה משתמשת בשרשור הראשי במשך יותר מ-60 שניות בסך הכול. כל המשאבים שמשמשים את כל ה-iframes הצאצאים של מסגרת המודעה נספרים במסגרת המגבלות של ההתערבות במודעה הזו.
מהם הטריגרים הנפוצים להצגת ההודעה הזו?
יש סוגים מסוימים של התנהגויות מודעות שסביר יותר שיפעילו את ההתערבויות האלה מאחרים. הנה כמה מהגורמים הנפוצים:
- מדיה לא דחוסה: טעינה של תמונות גדולות מאוד עם דחיסה לא טובה.
- Heavy Javascript: ביצוע פעולות נרחבות, כמו פענוח קובצי וידאו באמצעות JavaScript.
- חישובים כבדים: ביצוע חישובים מורכבים ברקע.
- תוכן וידאו ללא תנועות: טעינה של קובצי וידאו גדולים לפני שהמשתמש מקיים אינטראקציה עם מודעה.
מה קורה כשמסירים מודעה?
כש-Chrome מזהה שמודעה חרגה מספי המשקל של מודעה כבדה, הוא פועל באופן מיידי כדי להגן על משאבי המכשיר של המשתמש.
חוויית המשתמש
מנקודת המבט של המשתמש, המודעה מוסרת באופן מיידי. במקום זאת, ב-Chrome מוצגת תיבה אפורה עם ההודעה: המודעה הוסרה. אם המשתמש ילחץ על פרטים בתוך המאגר, הוא יראה הסבר ספציפי.
חוויית המפתחים
בנוסף, Chrome יוצר דוח התערבות באמצעות Reporting API כדי שתדעו בדיוק מה קרה. בעבר, הדוחות האלה נשלחו רק למסגרת המודעה עצמה ולמסגרות הצאצא שלה. עם זאת, לבעלי תוכן דיגיטלי לא הייתה דרך לדעת שמודעות בדפים שלהם הוסרו. כדי לפתור את הבעיה הזו, Chrome הרחיב את מנגנון הדיווח. דוחות על התערבות נשלחים עכשיו למסגרת ההטמעה (ההורה של מסגרת המודעה הבסיסית) בנוסף למסגרת המודעה עצמה. הדוחות שנשלחים למסגרת ההטמעה כוללים את מזהה מסגרת הצאצא ואת כתובת ה-URL של מסגרת המודעה.
כדי להגדיר את הדף לדוחות HTTP, התגובה צריכה לכלול את הכותרת Report-To:
Reporting-Endpoints: default="https://example.com/reports"
בקשת ה-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?utm_source=devtools"
}
}]
המסגרת להטמעה תקבל דוח דומה, שיישלח לכתובת ה-URL של המסגרת להטמעה, אבל ההודעה תכיל גם את מזהה מסגרת הצאצא ואת כתובת ה-URL הספציפית של מסגרת הצאצא:
...
"message": "Ad was removed because its CPU usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384?utm_source=devtools (id=123;url=http://example2.com/pre-redirect-ad-url.html)"
...
Javascript API מספק את ReportingObserver עם method observe() שאפשר להשתמש בו כדי להפעיל קריאה חוזרת (callback) שסופקה בהתערבויות. האפשרות הזו שימושית אם רוצים לצרף מידע נוסף לדוח כדי לעזור בניפוי הבאגים.
// callback that will handle intervention reports
function sendReports(reports) {
for (let report of reports) {
// Log the `report` json using 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 (לדוגמה, מודעה), צריך להשתמש באירוע pagehide כדי לוודא שהקריאה החוזרת (callback) של הדיווח מתעדת את דוח ההתערבות לפני שהדף נעלם.
window.addEventListener('pagehide', (event) => {
// pull all pending reports from the queue
let reports = observer.takeRecords();
sendReports(reports);
});
קובץ ה-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',
},
},
];
שיטות מומלצות למפתחים
כדי שהמודעות שלכם לא יופיעו בבאנר של מודעות כבדות, מומלץ לפעול לפי השיטות המומלצות הבאות:
- דרישה לאינטראקציה של המשתמש עם תוכן כבד: קריטריוני ההתערבות חלים על מודעות שהמשתמש לא ביצע איתן אינטראקציה. אם משתמש לוחץ על המודעה או מקיש עליה, מגבלות המשאבים כבר לא חלות. במקרים של חוויות משתמש עם וידאו או מדיה עשירה, כדאי לחכות למחווה של המשתמש (כמו 'לחיצה להפעלה') לפני טעינה של נכסים כבדים.
- אופטימיזציה של תמונות וסרטונים: חשוב לוודא שהתמונות דחוסות והסרטונים מותאמים לאינטרנט. מומלץ להימנע מטעינה אוטומטית של קובצי וידאו גדולים. במקום זאת, כדאי להשתמש ב-placeholder קליל עד שהמשתמש יבצע אינטראקציה.
- בדיקת השימוש במעבד: אנימציות מורכבות או פעולות Javascript שמפעילות פריסה וציור רציפים יכולות לגרום לעלייה חדה בשימוש במעבד. אפשר להשתמש בכלים כדי לזהות צווארי בקבוק בקוד שעלולים לגרום ל-thread הראשי להיות עמוס למשך תקופות ארוכות.
- מעקב אחרי מסגרות צאצא: חשוב לזכור שספירת המשאבים כוללת את כל מה שנמצא ב-iframe של המודעה. אם המודעה טוענת פיקסלים למעקב או מסגרות משנה של צד שלישי, השימוש שלהם במשאבים נספר במגבלה.
- בידוד תוכן שאינו מודעה: צריך להפריד בין מסגרות של תוכן שאינו מודעה לדומיינים שונים או לדפוסים שקל לזהות, שלא סביר שייחשבו לדומיינים של מודעות על ידי ספק רשימת המסננים בהתאם למדיניות שלו.
איך מנפים באגים ומאבחנים את הסיבה להתערבות
כדי לפתור בעיות שקשורות להפרעות משמעותיות בהצגת מודעות בצורה יעילה, קודם צריך להבין איך לוגיקת הזיהוי של Chrome מזהה תוכן כמודעה, ואז להשתמש בכלים מובנים למפתחים כדי לבדוק את הטריגרים הספציפיים של המשאבים שהובילו להסרה.
איך Chrome מזהה את נוכחות המודעה?
Chrome מתייג תוכן כמודעה על ידי השוואת בקשות למשאבים לרשימת סינון. לוגיקת הזיהוי חלה על תוכן בתוך iframes. המסגרת הראשית של הדף אף פעם לא נחשבת קשורה למודעות, גם אם היא מכילה סקריפטים של מודעות. שימו לב: אם מתבצעת טעינה של iframe ממקור שתואם לרשימת המסננים, הוא ייחשב כמודעה גם אם נטען מהמסגרת הזו תוכן אחר שאינו מודעה. דוגמה לכך היא נגן וידאו שנטען ב-iframe שתויג כמודעה, אבל יכול להיות שייטען בו גם תוכן שאינו מודעה.
איך מאמתים את זיהוי המודעות?
מפתחים יכולים להשתמש בכלי הפיתוח ל-Chrome כדי לבדוק באופן ויזואלי אם Chrome זיהה בהצלחה את התוכן שלהם כמודעה.
- הדגשת מסגרות של מודעות: בחלונית Rendering (עיבוד), בוחרים באפשרות Highlight Ad Frames (הדגשת מסגרות של מודעות). המסגרות של המודעות שזוהו יוצגו באדום במסך.
- הערה על אלמנט: בחלונית Elements (אלמנטים), אם זוהו מודעות ב-iframe, תוצג הערה על מודעה לצד תג הפתיחה
<iframe>. - פעילות ברשת: בחלונית Network, מסננים בקשות על סמך
Is ad-relatedערך בוליאני. - סטטוס המודעה: בחלונית האפליקציה בקטע Frames, פריים עם תג מודעה יכלול מאפיין
Ad Status.
איך מאבחנים את הסיבה להתערבות
Chrome מספק כלים לביקורת ולשיפור האיכות והביצועים של דפי אינטרנט. מריצים את Lighthouse בכלי הפיתוח של Chrome כדי לקבל דוחות על הביצועים של הדף. אפשר גם לעיין באוסף המאמרים web.dev/fast ולקרוא מידע נוסף על Web Vitals.
השימוש ברשת
פותחים את החלונית Network בכלי הפיתוח ל-Chrome כדי לראות את הפעילות הכוללת ברשת של המודעה. כדי לקבל תוצאות עקביות בטעינות חוזרות, מסמנים את האפשרות השבתת המטמון.
בתחתית הדף יופיע הערך שהועבר עבור הדף כולו. כדי להגביל את הבקשות רק לאלה שקשורות למודעה, משתמשים בשדה הקלט Filter (סינון) בחלק העליון.
אם מצאתם את הבקשה הראשונית להצגת המודעה, למשל המקור של ה-iframe, תוכלו להשתמש בכרטיסייה Initiator (יוזם) בתוך הבקשה כדי לראות את כל הבקשות שהיא מפעילה.
מיון הרשימה הכוללת של הבקשות לפי גודל הוא דרך טובה לזהות משאבים גדולים מדי. הגורמים הנפוצים לבעיה הם תמונות וסרטונים שלא עברו אופטימיזציה.
בנוסף, מיון לפי שם יכול לעזור לזהות בקשות חוזרות. יכול להיות שלא מדובר במשאב גדול יחיד שגורם להתערבות, אלא במספר גדול של בקשות חוזרות שחורגות מהמגבלה באופן מצטבר.
שימוש ביחידות עיבוד מרכזיות (CPU)
החלונית Performance בכלי הפיתוח תעזור לכם לאבחן בעיות בשימוש במעבד. פותחים את תפריט הגדרות הצילום. משתמשים בתפריט הנפתח CPU כדי להאט את המעבד ככל האפשר. ההתערבויות שקשורות למעבד (CPU) יופעלו בסיכוי גבוה יותר במכשירים עם עוצמת עיבוד נמוכה מאשר במכונות פיתוח מתקדמות.
לאחר מכן, לוחצים על הלחצן הקלטה כדי להתחיל בהקלטת הפעילות. מומלץ להתנסות בהקלטה בזמנים שונים ולמשך פרקי זמן שונים, כי טעינה של נתוני מעקב ארוכים יכולה להימשך זמן רב. אחרי שההקלטה נטענת, אפשר להשתמש בציר הזמן העליון כדי לבחור חלק מההקלטה. מתמקדים באזורים בגרף בצבע צהוב, סגול או ירוק מלא שמייצגים סקריפטים, עיבוד וציור.
מעיינים בכרטיסיות Bottom-Up, Call Tree ו-Event Log בתחתית. מיון העמודות האלה לפי Self Time (זמן עצמי) ו-Total Time (זמן כולל) יכול לעזור לזהות צווארי בקבוק בקוד.
קובץ המקור המשויך מקושר גם הוא, כך שאפשר לעבור לחלונית Sources כדי לבדוק את העלות של כל שורה.
בעיות נפוצות שכדאי לחפש כאן הן אנימציות לא מותאמות שגורמות לפריסה ולציור רציפים, או פעולות יקרות שמוסתרות בספרייה כלולה.
איך מדווחים על התערבויות שגויות?
אם תוכן שאינו מודעה תויג כתוכן כזה, כדאי לשנות את הקוד כדי שלא יתאים לכללי הסינון, או לפנות ישירות למנהלי EasyList כדי לשנות את כללי הסינון. חשוב לזכור שההתערבות בנוגע למודעות כבדות לא משפיעה על מסגרות עם תנועת משתמש, ולכן אפשר להחריג סרטונים על ידי דרישה של לחיצה על לחצן הפעלה לפני טעינת התוכן. אם רשימת EasyList לא תואמת לתוכן שלכם, ומסיבה כלשהי Chrome סיווג את התוכן כקשור למודעות, אתם יכולים לדווח על בעיה ב-Chrome באמצעות התבנית הזו. כשמדווחים על בעיה, צריך לכלול צילום מסך של דוח ההתערבות ודוגמה לכתובת URL שבה אפשר לשחזר את הבעיה.