NYTimes redesign causes Opera 12's Javascript to spike CPU
-
rseiler last edited by
Ever since the redesign of the site a few weeks ago, I've found the oddest thing with Opera 12.16: if you open an article on the site, minimize the browser (or not), and let it sit for a period of time (around an hour, but I haven't timed it), it will suddenly start taking CPU. One tab takes about 10% on my Core i5, and several tabs take about 25%. So, it's more or less a whole core out of the four that I have.
If you refresh the page(s), the "timer" resets and the CPU drops back to 0 or thereabouts...until the next time.
If you disable Javascript on nytimes.com, the problem never materializes in the first place.
It doesn't happen in other browsers.
I have no idea what this could be or how to go about troubleshooting. I also have no idea why a page that's sitting there doing absolutely nothing would look any different to Opera an hour from now as it does right now. My wild guess is that some sort of script is kicking in behind the scenes on the site, and Opera very much doesn't like it.
-
stng last edited by
Try Opera 12.14.
12.15/12.16 has broken web-sites compatibility.
But, of course, there is no guarantee.
I'll try to mask Opera as IE10 later to check the problem. -
rseiler last edited by
I'll try that, but I'd be very surprised if it makes a difference. 12.16 didn't have a problem with the old version of the site, and I can't think of a site where 12.16 is a problem while 12.14 isn't.
I haven't tried masking yet, but for this sort of problem it would also be very surprising.
-
blackbird71 last edited byOriginally posted by rseiler:
Ever since the redesign of the site a few weeks ago, I've found the oddest thing with Opera 12.16: if you open an article on the site, minimize the browser (or not), and let it sit for a period of time (around an hour, but I haven't timed it), it will suddenly start taking CPU. One tab takes about 10% on my Core i5, and several tabs take about 25%. So, it's more or less a whole core out of the four that I have.
If you refresh the page(s), the "timer" resets and the CPU drops back to 0 or thereabouts...until the next time.
If you disable Javascript on nytimes.com, the problem never materializes in the first place.
It doesn't happen in other browsers.
I have no idea what this could be or how to go about troubleshooting. I also have no idea why a page that's sitting there doing absolutely nothing would look any different to Opera an hour from now as it does right now. My wild guess is that some sort of script is kicking in behind the scenes on the site, and Opera very much doesn't like it.
Your guess is probably not as wild as you describe. A number of sites use scripts plus cookies (with internal timing or expiration data) to trigger updating of parts of a page automatically, or to call out to another external site for certain updates periodically. This is typically done using JavaScript, and it's all normally reset each time the page is first loaded or manually reloaded thereafter. There are a variety of ways where the scripting interpreter in a browser may misread a data auto-update instruction or be led astray by a value retrieved from a cookie and go off into some loop that ties up more and more processor cycles or RAM. And since each browser brand generally has its own unique or somewhat-modified scripting engine, you will see variation from brand to brand in how they behave against certain sites' coding.
-
stng last edited by
Confirmed. Opera 12.x getting a terrible javascript-lag on nytimes.com.
I'll continue experiments with a browser's masquerading. -
rseiler last edited by
No change with 12.14 or spoofing, so blackbird71, thanks for that explanation. Might there be a way of spotting the offender in Dragonfly? I did look, but nothing jumped out at me, though I'm no expert at using it. What about from viewing the page source? With that, I'm thinking that we might be able to selectively block the script in question via urlfilter.ini--as long as there's some commonality in the script's URL from article to article. I do see a couple .js references in the source that I'll test.
-
rseiler last edited by
The well-initiated might be able to draw some clues as to what's going on from this behind-the-scenes article about the site redesign, which employs things like Backbone.js.
http://open.blogs.nytimes.com/2014/01/08/the-technology-behind-the-nytimes-com-redesign
-
rseiler last edited by
The "solution" I've taken to is leaving JS disabled on nytimes.com and various sub-domains.
Still, if anyone knows of something less Draconian (perhaps including just the right thing in urlfilter.ini), it would be great to know. Most pages are perfectly readable without JS, but you miss all the extras like slideshows.
