Advertenties die onevenredig veel resources op een apparaat verbruiken, hebben een negatieve invloed op de gebruikerservaring – van de voor de hand liggende effecten van slechtere prestaties tot minder zichtbare gevolgen zoals het leeglopen van de batterij of het opgebruiken van bandbreedte. Deze advertenties variëren van actief schadelijke advertenties, zoals cryptocurrency-miners, tot authentieke content met onbedoelde bugs of prestatieproblemen.
Chrome stelt limieten in voor de bronnen die een advertentie mag gebruiken en verwijdert die advertentie als de limieten worden overschreden. Lees de aankondiging op de Chromium-blog voor meer informatie. Het mechanisme dat wordt gebruikt om advertenties te verwijderen, is de Heavy Ad Intervention .
Zware advertentiecriteria
Een advertentie wordt als zwaar beschouwd als de gebruiker er geen interactie mee heeft gehad (bijvoorbeeld niet op de advertentie heeft getikt of geklikt) en als de advertentie aan een van de volgende criteria voldoet:
- Gebruikt de hoofdthread in totaal langer dan 60 seconden
- Gebruikt de hoofdthread langer dan 15 seconden in een venster van 30 seconden
- Gebruikt meer dan 4 megabytes aan netwerkbandbreedte
Alle resources die worden gebruikt door onderliggende iframes van het advertentieframe, tellen mee voor de limieten voor ingrijpen in die advertentie. Het is belangrijk om te weten dat de tijdslimieten van de hoofdthread niet gelijk zijn aan de verstreken tijd sinds het laden van de advertentie. De limieten hebben betrekking op hoe lang de CPU nodig heeft om de code van de advertentie uit te voeren.
Het testen van de interventie
De interventie is beschikbaar in Chrome 85, maar standaard worden er wat ruis en variatie aan de drempelwaarden toegevoegd om de privacy van de gebruiker te beschermen.
Door chrome://flags/#heavy-ad-privacy-mitigations in te stellen op Uitgeschakeld , worden deze beschermingen verwijderd. Dit betekent dat de beperkingen deterministisch worden toegepast, puur op basis van de limieten. Dit zou het debuggen en testen eenvoudiger moeten maken.
Wanneer de interventie wordt geactiveerd, zou de content in het iframe voor een zware advertentie vervangen moeten worden door een melding over een verwijderde advertentie . Als u de meegeleverde link 'Details' volgt, ziet u een bericht met de volgende tekst: " Deze advertentie gebruikt te veel bronnen voor uw apparaat, daarom heeft Chrome deze verwijderd. "
U kunt de interventie toegepast op voorbeeldinhoud zien 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 kunnen zijn die ervoor kunnen zorgen dat een interventie niet wordt toegepast.
- Het opnieuw laden van dezelfde advertentie op dezelfde pagina zorgt ervoor dat die combinatie niet wordt beïnvloed. Het wissen van je browsegeschiedenis en het openen van de pagina in een nieuwe tag kan hierbij helpen.
- Zorg ervoor dat de pagina de focus houdt. Als u de pagina op de achtergrond zet (overschakelt naar een ander venster), worden de taakwachtrijen voor de pagina gepauzeerd en wordt er geen CPU-ingrijpen geactiveerd.
- Zorg ervoor dat u tijdens het testen niet op advertentie-inhoud tikt of klikt. De interventie wordt namelijk niet toegepast op inhoud waarmee gebruikers interactie hebben.
Wat moet je doen?
U toont advertenties van een externe aanbieder op uw site
U hoeft geen actie te ondernemen. Houd er wel rekening mee dat gebruikers advertenties kunnen zien die de verwijderde limieten overschrijden wanneer ze op uw site zijn.
U toont advertenties van eerste partijen op uw site of u biedt advertenties aan voor weergave door derden
Lees verder om ervoor te zorgen dat u de nodige monitoring implementeert via de Reporting API voor Heavy Ad-interventies.
Je maakt advertentie-inhoud of je onderhoudt een tool voor het maken van advertentie-inhoud
Lees verder om ervoor te zorgen dat u weet hoe u uw content kunt testen op problemen met prestaties en resourcegebruik. Raadpleeg ook de richtlijnen van de advertentieplatforms van uw keuze, aangezien deze mogelijk aanvullend technisch advies of beperkingen bieden. Zie bijvoorbeeld de Google -richtlijnen voor displayadvertenties . Overweeg om configureerbare drempels rechtstreeks in uw authoringtools 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 via uw JavaScript.
Deze rapporten worden gegenereerd voor de root-iframe met advertentietag, samen met al zijn afstammelingen, d.w.z. elk frame dat door de interventie is verwijderd. Dit betekent dat als een advertentie afkomstig is van een externe bron, d.w.z. een cross-site iframe, het aan die externe partij (bijvoorbeeld de advertentieprovider) is om het rapport te verwerken.
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 dat er als volgt uitziet:
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 biedt de ReportingObserver een observe() methode die kan worden gebruikt om een opgegeven callback te activeren bij interventies. Dit kan handig zijn als u aanvullende informatie aan het rapport wilt toevoegen ter ondersteuning van debugging.
// 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 een advertentie in 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 de pagehide gebeurtenis de hoeveelheid werk die erin kan worden uitgevoerd beperkt om de gebruikerservaring te beschermen. Als u bijvoorbeeld een fetch() -verzoek met de rapporten probeert te versturen, wordt dat verzoek geannuleerd. Gebruik navigator.sendBeacon() om dat rapport te versturen. Zelfs dan is dit slechts een poging van de browser om het zo goed mogelijk te doen, geen garantie.
De resulterende JSON van de JavaScript is vergelijkbaar met die welke bij de POST aanvraag wordt verzonden:
[
{
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
Advertentiecontent is gewoon webcontent, dus gebruik tools zoals Lighthouse om de algehele prestaties van je content te controleren. De resulterende audits bieden directe begeleiding bij verbeteringen. Je kunt ook de collectie web.dev/fast raadplegen.
Het kan nuttig zijn om 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-klare iframe met advertentietags. U kunt Chrome DevTools gebruiken om te valideren of content als advertentie is getagd. Selecteer ' Advertentieframes markeren ' in het venster Rendering (toegankelijk via het menu met de drie puntjes ⋮ en vervolgens Meer tools > Rendering ). Als u content test in het bovenste venster of een andere context waar deze niet als advertentie is getagd, wordt de interventie niet geactiveerd, maar u kunt de drempelwaarden nog steeds handmatig controleren.
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 paneel Applicatie onder de sectie Frames , waar frames met advertentietags een kenmerk ' Advertentiestatus ' 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 het overgedragen bedrag voor de hele pagina. Overweeg de filterinvoer bovenaan te gebruiken om de verzoeken te beperken tot alleen de verzoeken die betrekking hebben op de advertentie.
Als u bijvoorbeeld de oorspronkelijke aanvraag voor de advertentie vindt, de bron voor het iframe, kunt u ook het tabblad Initiator in de aanvraag gebruiken om alle aanvragen te bekijken die de aanvraag activeert.
Het sorteren van de totale lijst met verzoeken op grootte is een goede manier om te grote bronnen te detecteren. Veelvoorkomende boosdoeners zijn afbeeldingen en video's die niet geoptimaliseerd zijn.
Bovendien kan sorteren op naam een goede manier zijn om herhaalde verzoeken te detecteren. Het kan zijn dat niet één grote resource de interventie activeert, maar een groot aantal herhaalde verzoeken die de limiet stapsgewijs overschrijden.
CPU-gebruik
Het paneel Prestaties in DevTools helpt bij het diagnosticeren van problemen met CPU-gebruik. De eerste stap is het openen van het menu Capture-instellingen . Gebruik de CPU- dropdown om de CPU zoveel mogelijk te vertragen. De CPU-interventies worden veel vaker geactiveerd op apparaten met een lager vermogen dan op high-end ontwikkelmachines.
Klik vervolgens op de knop Opnemen om de opname te starten. Experimenteer eventueel met wanneer en hoe lang u opneemt, aangezien het laden van een lange trace vrij lang kan duren. Zodra de opname is geladen, kunt u de bovenste tijdlijn gebruiken om een deel van de opname te selecteren . Focus op de gebieden in de grafiek in effen geel, paars of groen die scripting, rendering en schilderen vertegenwoordigen.
Verken de tabbladen Bottom-Up , Call Tree en Event Log onderaan. Door deze kolommen te sorteren op Zelftijd en Totale tijd, kunt u knelpunten in de code identificeren.
Het bijbehorende bronbestand is daar ook gekoppeld, zodat u het kunt volgen tot aan het paneel Bronnen om de kosten van elke regel te bekijken.
Vaak moet u hierbij opletten op slecht geoptimaliseerde animaties die een doorlopende lay-out en verfbewerking activeren, of op kostbare bewerkingen die verborgen zitten in een meegeleverde bibliotheek.
Hoe u onjuiste interventies kunt melden
Chrome tagt content als advertentie door bronverzoeken te vergelijken met een filterlijst . Als content die geen advertentie is, is getagd, kunt u overwegen die code te wijzigen om te voorkomen dat de filterregels worden vergeleken. Als u vermoedt dat een interventie onjuist is toegepast, kunt u een probleem melden via deze sjabloon . Zorg ervoor dat u een voorbeeld van het interventierapport en een voorbeeld-URL hebt om het probleem te reproduceren.