What's going on (technically) with TheVerge.com's homepage?
September 28, 2023 7:10 AM   Subscribe

I'd never gone to The Verge's homepage until very recently, so I don't know if this is something new or not, but without fail visiting that page over the past month or two makes the fans on my laptop start blowing extremely hard within a minute or so, and sometimes sooner. I've noticed no other webpages doing this. Any idea what's going on?

If I alt-tab over to Firefox's Process Manager, I can see values in the CPU column go as high as 120% (which I wouldn't have thought possible). If Process Manager is in a tab in the same browser window, the number in the CPU column for theverge will fall down to "idle" after a bit, but if it's in a separate window, the number will continue to fluctuate around at least 22% as long as theverge is in the active tab of its own window.

I'm running Ghostery in Firefox, and this happens even after setting it to block everything it detects on the page (there were two things I saw it initially decided not to block on its own: "Hosting" from AmazonCloudfront, and "Customer Interaction" from Vox).

[Update before posting: I finally switched over to uBlock Origin instead, and the behavior has disappeared. So I guess there was something uBlock is blocking that Ghostery wasn't. I'm still curious what that thing was, and why theverge might be unique among all the sites I've visited.]

I've tried googling for anyone else discussing this, but the results for any search terms I tried are swamped by pages mentioning theverge articles about adjacent topics.

And I see Firefox has a Profiler I can reach via the right-click > Inspect pane, but it seemed fair to ask here rather than learning from scratch how that whole interface works.

Bonus question: what's going on with (sketchy) sites like fmovies dot hn (and its many sister/clone sites) showing brief but continual spikes up to 20% processor usage (both before and after switching from Ghostery to uBlock), even on their nearly blank, static landing pages? (Unlike at the Verge, these seem to happen even if in a background tab. Scrolling down the Process Manager list, nothing else in the dozens of tabs I have open come anywhere close to those numbers -- nearly all seem to be permanently sub-1% -- let alone close to the Verge's 100+% spikes.)
posted by nobody to Technology (10 answers total)
 
Not a direct answer, but do you see the behavior if you turn off both Ghostery and uBlock? If not, that could point to it actually being a problem with Ghostery.
posted by jferg at 7:16 AM on September 28, 2023


I think it is Ghostery as I have the same challenge with certain larger sites. Disabling Ghostery stops my fan winding up and allows sites to load faster. I only use it because there isn't a uBlock Origin for Safari, but I am pretty sure I will be binning Ghostery.
posted by terrapin at 7:29 AM on September 28, 2023


Response by poster: Ah, I should have thought of that. (Thanks!) I think I'd assumed anything Ghostery itself was doing would show up in the extensions section of the Process Manager list, not in the entry for the tab on which it was blocking things.

Turning off Ghostery (and uBlock), the numbers drop down to ~40% while viewing the page, and around 4-5% while foregrounded in another window -- and the fans don't start running. (With uBlock on, it's closer to 25%/1-2%.)

But still a question: is the Verge doing something unique among other media sites to cause Firefox+Ghostery to freak out so badly? (I've been using Ghostery for probably around 10 years or so, maybe more, and never noticed this happening anywhere before now.)

(And also still curious about the sketchy sites in the question's last paragraph, whose behavior neither Ghostery nor uBlock seems to block.)
posted by nobody at 7:32 AM on September 28, 2023


Potentially they are doing something sketchy. But it's more likely they have a script that is behaving badly when it can't load other scripts (that are being blocked by ghostery or whatever). Imagine a script that when it gets a failure to load a piece of dynamic content (or ad) immediately tries again. If there's no back-off or giving up, it could spend as much CPU time as it can get trying over and over again.

By the way, CPU consumption is set where "100%" is a single core of a CPU being fully consumed by a particular process. You got 120% because something was using multiple cores to a point where it summed to 120%. Imagine it was consuming 3 cores at 40% or two at 60%, etc. Pretty much every modern computer has multiple cores these days, so if an application is designed to make use of multiple cores (and many aren't), you can trivially get to over 100% CPU consumption under heavy load.
posted by Xoder at 7:38 AM on September 28, 2023 [4 favorites]


This seems like a bug in Ghostery - without access to the code, it's hard to say what specifically is going wrong. But, this can happen when the site/app does a lot of processing for whatever reason. Sometimes this is benign - I've definitely managed to do similar stuff in apps because they've ended up having to load just a ton of data for whatever reason - but sometimes this is bad or buggy code in the site itself. (I've also done this while in development and ended up needing to optimize the data that gets pulled down, or redo an algorithm that is too complex, or something along those lines. Not all devs know enough to do that or have the time to do it or are getting paid enough to care, etc.) Or, especially on sketchier sites, it could be that they're loading stuff in ways specifically to evade ad blockers.
posted by mrg at 7:38 AM on September 28, 2023 [1 favorite]


what's going on with (sketchy) sites like fmovies dot hn (and its many sister/clone sites) showing brief but continual spikes up to 20% processor usage (both before and after switching from Ghostery to uBlock), even on their nearly blank, static landing pages?

What you actually see on a page can (and often is) actually a very, very small portion of what is actually going on when a website is loaded. Websites have a "front end" and a "back end," and it's likely that the processor usage that you're seeing is going on in the "back end" and is not displayed at all on the "front end."

As others have said, it's not uncommon for scripts to go a little haywire and run for too long, run too often, etc. So essentially they probably have a bug somewhere where a script is running in a way that it shouldn't, and it's causing performance issues.

But still a question: is the Verge doing something unique among other media sites to cause Firefox+Ghostery to freak out so badly?

This is impossible to tell without being an engineer and digging into their code.
posted by anotheraccount at 10:21 AM on September 28, 2023


is the Verge doing something unique among other media sites

Anecdotal: I've noticed that all vox sites over maybe the last year have really amped up further whatever js they are doing, as far as I can tell primarily associated with dynamically loading advertising while scrolling. You probably won't get specifics here unless someone has actually done the profiling themselves or is deep in the web ad business, though, and the code they are running may well be farmed out to ad networks and the like, not theverge specifically. I should say that I don't think this is at all specific to vox, I've been noticing this across the board for sites owned by the usual tech media holding company suspects who are bent on resource extraction from their properties, e.g. G/O, gamer network, parts of conde nast, ...

I just did a quick test of theverge in chrome while scrolling, and indeed it's doing tons of stuff, basically everything I saw is about loading ads -- but I didn't do a very detailed look. (In about 15s I saw activity from on the order of 8 distinct ad networks.) The interface to profiling isn't that hard to use if you don't get more detailed answers here, here's an overview for chrome, here's one for firefox.
posted by advil at 11:39 AM on September 28, 2023


What you actually see on a page can (and often is) actually a very, very small portion of what is actually going on when a website is loaded. Websites have a "front end" and a "back end," and it's likely that the processor usage that you're seeing is going on in the "back end" and is not displayed at all on the "front end."

You're not wrong on this, but your terminology is funny. The "back end" when talking websites is typically the part that runs on the server, not anything the client's PC is doing.

What's maybe happening here is Ghostery is blocking some marketing tracker (these can get REALLY elaborate/intrusive), and The Verge's frontend code is noticing it's not there and trying really hard to inject it into the page, but eventually giving up.

(personally I just use the privacy filters in uBlock instead of Ghostery.)
posted by neckro23 at 2:26 PM on September 28, 2023 [1 favorite]


My guess: bad retry logic. The way these blockers work is they throw an error when loading an ad / sleazy Javascript. The way a complex website reacts to that error could be any number of things. One common thing is "huh, let's just try again". And again, and again, in a tight loop consuming 100% CPU.

Honestly I'm amazed this doesn't happen more with blockers. I assume it's because most web devs are themselves running blockers and fix problems like this for their own convenience.
posted by Nelson at 10:50 AM on September 29, 2023


Response by poster: Thanks so much, all these answers are great.

For what it's worth, I'd seen -- from sketchy-website supporting quarters, not from detractors -- that some of those are known to be running crypto-miners through the browser. I guess the next step would be to see what their behavior looks like with neither uBlock nor Ghostery running, to rule out what does indeed seem to be what's going on with theverge's homepage, but I'm hesitant to try that. Maybe at some point I'll dig out an older computer to give that a go on.

Thanks again!
posted by nobody at 7:17 AM on September 30, 2023


« Older Help me manage anxieties around getting in...   |   Help finding a practical, hands-on med... Newer »

You are not logged in, either login or create an account to post comments