Advertenties die een onevenredige hoeveelheid bronnen op een apparaat verbruiken, hebben een negatieve invloed op de gebruikerservaring: van de voor de hand liggende effecten van afnemende prestaties tot minder zichtbare gevolgen, zoals het leeglopen van de batterij of het opslokken van bandbreedte. Deze advertenties variëren van actief kwaadwillige advertenties, zoals cryptocurrency-mijnwerkers, tot echte inhoud met onbedoelde bugs of prestatieproblemen.
Chrome stelt limieten aan de bronnen die een advertentie mag gebruiken en verwijdert die advertentie als de limieten worden overschreden. Je kunt de aankondiging op de Chromium-blog lezen voor meer informatie. Het mechanisme dat wordt gebruikt voor het verwijderen van advertenties is de Heavy Ad Intervention .
Zware advertentiecriteria
Een advertentie wordt als zwaar beschouwd als de gebruiker er geen interactie mee heeft gehad (er bijvoorbeeld niet op heeft getikt of erop heeft geklikt) en de advertentie aan een van de volgende criteria voldoet:
- Gebruikt de hoofdthread in totaal ruim 60 seconden
- Gebruikt de hoofdthread gedurende meer dan 15 seconden in een venster van 30 seconden
- Gebruikt meer dan 4 megabytes aan netwerkbandbreedte
Alle bronnen die door onderliggende iframes van het advertentieframe worden gebruikt, tellen mee voor de limieten voor interventies op die advertentie. Het is belangrijk op te merken dat de tijdslimieten voor de hoofdthread niet hetzelfde zijn als de verstreken tijd sinds het laden van de advertentie. De limieten bepalen hoe lang het duurt voordat de CPU de code van de advertentie uitvoert.
Het testen van de interventie
De interventie werd geleverd in Chrome 85, maar standaard wordt er wat ruis en variabiliteit aan de drempels toegevoegd om de privacy van gebruikers te beschermen.
Als chrome://flags/#heavy-ad-privacy-mitigations instelt op Uitgeschakeld , worden deze beveiligingen verwijderd, wat betekent dat de beperkingen deterministisch worden toegepast, puur volgens de limieten. Dit zou het debuggen en testen eenvoudiger moeten maken.
Wanneer de interventie wordt geactiveerd, zou de inhoud in het iframe voor een zware advertentie moeten worden vervangen door het bericht 'Advertentie verwijderd' . Als u de meegeleverde link 'Details' volgt, ziet u een bericht waarin wordt uitgelegd: ' Deze advertentie gebruikt te veel bronnen voor uw apparaat, dus Chrome heeft deze verwijderd. '
U kunt de interventie toegepast zien op voorbeeldinhoud op heavy-ads.glitch.me. U kunt deze testsite ook gebruiken om een willekeurige URL te laden als een snelle manier om uw eigen inhoud te testen.
Houd er bij het testen rekening mee dat er een aantal redenen zijn die de toepassing van een interventie in de weg kunnen staan.
- Als u dezelfde advertentie opnieuw laadt op dezelfde pagina, wordt deze combinatie vrijgesteld van de interventie. Het kan hierbij helpen om uw browsegeschiedenis te wissen en de pagina in een nieuwe tag te openen.
- Zorg ervoor dat de pagina in focus blijft. Door de pagina op de achtergrond te plaatsen (overschakelen naar een ander venster) worden de taakwachtrijen voor de pagina gepauzeerd en wordt er dus geen CPU-interventie geactiveerd.
- Zorg ervoor dat u tijdens het testen niet op de advertentie-inhoud tikt of klikt. De interventie wordt niet toegepast op inhoud waarop gebruikersinteractie plaatsvindt.
Wat moet je doen?
U geeft advertenties van een externe aanbieder op uw site weer
Er is geen actie nodig. Houd er wel rekening mee dat gebruikers op uw site mogelijk advertenties te zien krijgen die de verwijderde limieten overschrijden.
U geeft first-party advertenties weer op uw site of u levert advertenties voor weergave door derden
Lees verder om ervoor te zorgen dat u de nodige monitoring implementeert via de Reporting API voor zware advertentie-interventies.
U maakt advertentie-inhoud of u onderhoudt een tool voor het maken van advertentie-inhoud
Lees verder om er zeker van te zijn dat u weet hoe u uw inhoud kunt testen op problemen met de prestaties en het gebruik van bronnen. Raadpleeg ook de richtlijnen op de advertentieplatforms van uw keuze, aangezien deze aanvullend technisch advies of beperkingen kunnen bieden. Zie bijvoorbeeld de Google -richtlijnen voor display-advertentiemateriaal . Overweeg configureerbare drempels rechtstreeks in uw auteurstools in te bouwen om te voorkomen dat slecht presterende advertenties in het wild terechtkomen.
Wat gebeurt er als een advertentie wordt verwijderd?
Een interventie in Chrome wordt gerapporteerd via de toepasselijk genaamde Reporting API met een intervention . U kunt de Reporting API gebruiken om op de hoogte te worden gesteld van interventies via een POST verzoek aan een rapportage-eindpunt of binnen uw JavaScript.
Deze rapporten worden geactiveerd op het hoofd-iframe met een advertentietag, samen met alle onderliggende iframes, dat wil zeggen elk frame dat door de interventie wordt verwijderd. Dit betekent dat als een advertentie afkomstig is van een bron van derden, dat wil zeggen een iframe voor meerdere sites, het aan die derde partij (bijvoorbeeld de advertentieaanbieder) is om het rapport af te handelen.
Om de pagina voor HTTP-rapporten te configureren, moet het antwoord de Report-To -header bevatten:
Report-To: { "url": "https://example.com/reports", "max_age": 86400 }
Het geactiveerde POST-verzoek bevat een rapport als dit:
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"
}
}]
De JavaScript-API voorziet de ReportingObserver van een observe() methode die kan worden gebruikt om een meegeleverde callback op interventies te activeren. Dit kan handig zijn als u aanvullende informatie aan het rapport wilt toevoegen als hulpmiddel bij het opsporen van fouten.
// 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();
Omdat de interventie de pagina echter letterlijk uit het iframe verwijdert, moet u een failsafe toevoegen om ervoor te zorgen dat het rapport definitief wordt vastgelegd voordat de pagina volledig verdwijnt, bijvoorbeeld bij een advertentie binnen een iframe. Hiervoor kunt u dezelfde callback koppelen aan de pagehide -gebeurtenis.
window.addEventListener('pagehide', (event) => {
// pull all pending reports from the queue
let reports = observer.takeRecords();
sendReports(reports);
});
Houd er rekening mee dat, om de gebruikerservaring te beschermen, de pagehide gebeurtenis de hoeveelheid werk beperkt die daarin kan gebeuren. Als u bijvoorbeeld probeert een fetch() verzoek met de rapporten te verzenden, zal dat verzoek worden geannuleerd. U moet navigator.sendBeacon() gebruiken om dat rapport te verzenden en zelfs dan is dit slechts een inspanning van de browser en geen garantie.
De resulterende JSON uit JavaScript is vergelijkbaar met die verzonden bij het POST verzoek:
[
{
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',
},
},
];
Het diagnosticeren van de oorzaak van een interventie
Advertentie-inhoud is slechts webinhoud, dus maak gebruik van tools zoals Lighthouse om de algehele prestaties van uw inhoud te controleren. De daaruit voortvloeiende audits bieden inline richtlijnen voor verbeteringen. U kunt ook de web.dev/fast-collectie raadplegen.
Mogelijk vindt u het nuttig uw advertentie in een meer geïsoleerde context te testen. U kunt de aangepaste URL-optie op https://heavy-ads.glitch.me gebruiken om dit te testen met een kant-en-klaar iframe met advertentietags. U kunt Chrome DevTools gebruiken om te valideren dat inhoud is getagd als advertentie. In het deelvenster Rendering (toegankelijk via het menu met drie stippen ⋮ en vervolgens Meer hulpmiddelen > Rendering ) selecteert u ' Advertentieframes markeren '. Als u inhoud test in het venster op het hoogste niveau of in een andere context waarin deze niet als advertentie is getagd, wordt de interventie niet geactiveerd, maar u kunt nog steeds handmatig controleren of de drempelwaarden zijn bereikt.
De advertentiestatus van een frame wordt ook weergegeven in het deelvenster Elementen , waar een ad wordt toegevoegd na de openingstag <iframe> . Dit is ook zichtbaar in het toepassingspaneel onder de sectie Frames , waar aan advertenties getagde frames het attribuut ' Advertentiestatus ' zullen bevatten.
Netwerkgebruik
Open het netwerkpaneel in Chrome DevTools om de algehele netwerkactiviteit voor de advertentie te bekijken. Zorg ervoor dat de optie " Cache uitschakelen " is aangevinkt om consistente resultaten te krijgen bij herhaaldelijk laden.
De overgedragen waarde onderaan de pagina toont u het overgedragen bedrag voor de hele pagina. Overweeg de filterinvoer bovenaan te gebruiken om de verzoeken te beperken tot de verzoeken die verband houden met de advertentie.
Als u het oorspronkelijke verzoek voor de advertentie vindt, bijvoorbeeld de bron voor het iframe, kunt u ook het tabblad Initiator binnen het verzoek gebruiken om alle verzoeken te bekijken die hierdoor worden geactiveerd.
Het sorteren van de totale lijst met verzoeken op grootte is een goede manier om te grote resources te herkennen. Veel voorkomende boosdoeners zijn afbeeldingen en video's die niet zijn geoptimaliseerd.
Bovendien kan sorteren op naam een goede manier zijn om herhaalde verzoeken te herkennen. Het kan zijn dat het niet één enkele grote hulpbron is die de interventie activeert, maar een groot aantal herhaalde verzoeken die stapsgewijs de limiet overschrijden.
CPU-gebruik
Het Prestatiepaneel in DevTools helpt bij het diagnosticeren van CPU-gebruiksproblemen. De eerste stap is het openen van het menu Opname-instellingen . Gebruik de vervolgkeuzelijst CPU om de CPU zoveel mogelijk te vertragen. Het is veel waarschijnlijker dat de interventies voor de CPU worden geactiveerd op apparaten met een lager vermogen dan op geavanceerde ontwikkelmachines.
Klik vervolgens op de knop Opnemen om te beginnen met het opnemen van activiteiten. Misschien wilt u experimenteren met wanneer en hoe lang u opneemt, omdat het laden van een lange trace behoorlijk lang kan duren. Zodra de opname is geladen, kunt u de bovenste tijdlijn gebruiken om een deel van de opname te selecteren . Focus op gebieden in de grafiek in effen geel, paars of groen die scripting, rendering en schilderen vertegenwoordigen.
Verken de tabbladen Bottom-Up , Oproepboom en Gebeurtenislogboek onderaan. Door deze kolommen te sorteren op Zelftijd en Totale tijd kunnen knelpunten in de code worden geïdentificeerd.
Het bijbehorende bronbestand is daar ook gekoppeld, zodat u het kunt volgen naar het paneel Bronnen om de kosten van elke regel te bekijken.
Veelvoorkomende problemen waar u hier op moet letten zijn slecht geoptimaliseerde animaties die een continue lay-out en verf veroorzaken, of kostbare bewerkingen die verborgen zijn in een meegeleverde bibliotheek.
Hoe u onjuiste interventies kunt melden
Chrome tagt inhoud als een advertentie door bronverzoeken te vergelijken met een filterlijst . Als niet-advertentie-inhoud is getagd, kunt u overwegen die code te wijzigen om te voorkomen dat de filterregels overeenkomen. Als u vermoedt dat een interventie verkeerd is toegepast, kunt u via dit sjabloon een probleem melden . Zorg ervoor dat u een voorbeeld van het interventierapport heeft vastgelegd en dat u over een voorbeeld-URL beschikt om het probleem te reproduceren.