Ik gebruik zelf Firefox (126.0) met (onder meer) uBlock Origin op Linux. In Firefox kan je door "about:performance" in de adresbalk in te typen geheugen- en CPU-gebruik voor allerlei onderdelen van Firefox zien, zoals van de processen en van tabs. Door deze tab naar een ander venster te verplaatsen kan ik de website en de performance-gegevens tegelijk in beeld hebben. uBlock Origin heb ik ingesteld om default geen inhoud van andere domeinen toe te staan en om JavaScript volledig te blokkeren.
Bij
https://rtl.nl/[*] zag ik inderdaad een hoog CPU-gebruik (alleen als de tab geselecteerd is), waarvan een flink deel in het centrale Firefox-proces zit en een kleiner deel in de tab voor de RTL-site. Best opmerkelijk dat het CPU-gebruik hoog was terwijl juist alle JavaScript geblokkeerd was, maar ik ben dat vaker tegengekomen (daar kom ik zo op terug).
Ik probeerde de website in een "maagdelijke" Firefox te openen (in een Firejail-sandbox die geen toegang geeft tot mijn home-directory met cache, instellingen en de hele rimram, zodat die "denkt" voor het eerst opgestart te worden, met default-instellingen draait en geen add-ons gebruikt), en daar viel meteen op dat het CPU-gebruik, na een korte piek bij het laden van de pagina, laag was.
Toen heb ik in mijn primaire browser uBlock even helemaal uitgeschakeld voor die website, en daar werd het CPU-gebruik toen ook laag. Ik heb uBlock weer aangezet en het CPU-gebruik schoot (na een reload) weer omhoog.
Het is niet voor het eerst dat ik zoiets zie, ik ben het incidenteel ook bij andere websites tegengekomen. Wat hier aan de hand lijkt te zijn is dat, juist omdat je ongewenste inhoud blokkeert, iets in de code van die website als een gek blijft proberen iets te laden waar de toegang toe geblokkeerd is en dat in zo'n hoog tempo doet dat dat het hoge CPU-gebruik veroorzaakt. Dat kan duidelijk niet door geblokkeerde JavaScript gedaan worden, wellicht zit het op de een of andere manier in de CSS.
Ik weet niet of ik dit op moet vatten als bewust terugpesten van mensen die ongewenste meuk blokkeren of dat het een bug is die alleen optreedt in een configuratie die voor de makers van de website simpelweg niet interessant is om te testen. En ik overzie ook niet hoe dit nou precies werkt, websites als die van RTL zitten razend ingewikkeld in elkaar en ik heb helemaal geen zin om een mega-inspanning te gaan leveren om dit te doorgronden.
Ik heb geen ervaring met ChromeOS Flex of met PiHole, en dus overzie ik niet hoe makkelijk het is om in jouw opzet even een vergelijkbare proef te doen. Misschien kan je het doen door tijdelijk een nieuwe user op je systeem aan te maken die "schoon" is qua beschermende extra's, daar de test mee te doen, en dan die user weer te verwijderen van je systeem; misschien is het veel makkelijker. Hoe dan ook, als je dit beeld kan bevestigen weet je dat je om RTL te kunnen gebruiken dingen moet toelaten die je eigenlijk wilt blokkeren, en dan heb je daar afwegingen over te maken en wellicht moeizaam uitzoekwerk te doen om boven water te krijgen wat je dan precies toe moet laten.
[*] Neem gewoon de URL op waar je het over hebt en gebruik ook de URL-tags om ernaar te verwijzen, alsjeblieft. Ik word een beetje moe van de neiging van bezoekers van deze website om dat soort basale dingen vooral niet te doen. Mensen die jou proberen te helpen moeten toch wel even naar die site kijken willen ze kunnen zien wat er aan de hand is, en je verwijst hier niet naar een website die erop gericht is om bezoekers te beschadigen (als ik de algemeen voorkomende grensoverschrijdingen door advertienetwerken niet meereken althans). Security.nl laat de volledige URL zien in hyperlinks die je opneemt, en je mag van mensen hier verwachten dat ze in staat zijn om daar even naar te kijken voor ze erop klikken, en ook dat ze zich sowieso al wapenen tegen schadelijke dingen, met bijvoorbeeld een PiHole, uBlock, uMatrix of iets dergelijks.