Study blames Javascript, CSS, ads for low mobile battery life

The BBC posted an article about a recent study by Stanford of battery life in mobile devices as they visited various web sites. The tests were only done on a single phone OS (Android) and I assume the default webkit browser which supports Javascript and much of the latest CSS developments.

The study was presented at the World Wide Web conference 2012 in Lyon according to the article, but I can’t find where on the site anything about it might have been posted.

Related: Free apps drain batteries too (often via ads)

Gmail, the most “green” mobile site we found, uses HTML
links to open email messages that the user clicks on. The desktop
version of Gmail uses Javascript instead. Our experiments
suggest that using links instead of Javascript greatly reduces the
rendering energy for the page. Thus, by designing the mobile
version of the site differently than its desktop version, Gmail
was able to save energy on the phone.

AOL is able to save rendering energy by using a simple HTML
table element to position elements on the page. Other sites that
position elements using CSS need far more energy to render.

I don’t know… It sounds to me like a payed study, targeted to make certain devices and technologies look bad, made by techs that have many to learn yet.

It sounds like a presentation done by hacks for their clueless bosses to get a raise or funds for toga parties. They throw number in there like there’s no tomorrow, while their final conclusions are the most obvious one could draw, without the need of any “study”.

That might make sense itmitică except the study was conducted by a university. . .

It also makes practical sense, the more client side work done in applying placement and processing data the more power the phone uses to process it. The bigger question would be How significant the difference actually is.

My thoughts exactly.

If heavy vs light pages means a difference of a few minutes of battery life, then that doesn’t seem terribly significant. But if the difference turns out to be a few hours of battery life, then that is definitely significant.

… and universities extra budgeting comes from contracts with private companies.

What I find the most stupid in their findings is the overall conclusion that “using” a smartphone will make its battery discharge. I have another “finding” for them: even when my smartphone is off its battery is discharging.

You’ll notice the “findings” don’t tackle WPh, put the Android in the line of fire, and pretty much slams iPh. Coincidence? I believe not. :slight_smile: I question their purpose only because they’ve taken a basic truth and they’ve put a spin to it.

[FONT=Verdana]Without going into the specifics of whether large tables with inline formatting use less processing power than CSS, it’s definitely true that bloated sites absolutely hammer the phones. I tend to only check a limited number of sites on my mobile, and the worst one that I use regularly is Sitepoint Forums :frowning: The massive amount of scripting and hidden content makes it painfully slow to use, and means that after a few minutes it gets really hot and the battery indicator is amost visibly ticking down. My experience is that Javascript is the principal culprit behind this.

(I’m not saying that Sitepoint Forums is by any means the worst site for this, just using it as an example, whereas most large feature-rich sites I would leave until I had desktop access).[/FONT]

I’ll admit SPF is not what it should be, mobile wise. But…

Let me ask you this: if SPF were a game, would you still complain about the battery drainage?
Let me ask you this: if SPF were a movie, would you still complain about the battery drainage?
Let me ask you this: if SPF were a tune, would you still complain about the battery drainage?

How come, suddenly, CSS and JS are in the hot spot? Because it’s flash going and they’re taking its place? The study should reveal first that device battery is not well suited. Secondly, that mobile OSs are next in line, performance wise. Thirdly, that mobile UAs are not doing a decent job… ntly time, CSS and JS should be wisely used.

I’m gonna have to dismiss this because of it’s very finger pointed nature in something that has soooooooooooooooooo many layers to it.

Shhh! My common sense is tingling.

While I don’t completely buy the tables over css layouts part (though depending on the layout it is possible…) the rest of it makes sense.

Anything that takes more CPU time to do is going to chew more battery. Javascript being an interpreted language sucks cpu like candy, PARTICULARLY if you have timed events like animations. CSS animations be they GPU or CPU bound inherently are going to suck more juice than having things not animated. Memory access consumes more power on DRAM since instead of just paying the refresh, you have the ‘double duty cycle’ – this means larger files and larger images are going to cost battery life. Rescaling large images to smaller dynamically client-side is going to suck cpu. Rendering more complex shapes like CSS3 transitions, allocating pre-render buffers for webfonts not installed on the host OS, these all should have significant impact not just on performance, but also on battery life.

Large images in particular can cause real drain because they have to be decoded; that 260k jpeg might look cool, but decoded it takes a megabyte or more of RAM on devices that typically have less than 64 megs free by the time the OS and applications are loaded. That means dipping into the fixed storage to swap, consuming even more power. (and shortening the life of said storage since, well… it is flash RAM!) … and that’s without talking the overhead of running the decoder algorythm… especially since jpeg is lightweight compared to what PNG uses. (zLib) – to put that in perspective that’s like saying a rhino is lightweight compared to an elephant.

There was an article by one of the android devs a year or two ago (my google-fu is failing me) where it was said smartphone battery life could be doubled by killing all the cutesy transition animations. Stood out in my mind because I’m not a big fan of stupid animated transitions in the first place. I click on something or tell the computer to do something I want it done NOW, not sit there waiting for some stupid animated dog to ask me if it can help me.

… and to be honest, fade, genie, and other transitions are as annoying to me as Clippy or Rover. Rank right up there with the idiocy of rotating image banners sucking down space for nothing useful – well, apart from hiding the lack of real content on the page.

Because the real problem with flash wasn’t with flash – which is great for games or video delivery. The problem was people using it on websites for garbage that shouldn’t even BE on websites. The problem isn’t the technology, it’s how it’s being used, overused, abused, mishandled, and thrown at EVERYTHING ‘just because we can’.

Think of it like the idiots who use javascript to replicate the TARGET attribute, just to get their code to validate; without understanding WHY it was deprecated and why 99% of websites have no business doing that in the first blasted place!

Though you are right – they should be wisely used; I say use with an eye-dropper everywhere, and drop certain effects completely for mobile. Just slapping endless effects on a page “because you can” is the real problem, regardless of technology.

See this online manual I’m trying to read right now for a new language, that uses a 3.5 megabyte javascript train wreck (as a single file!) to deliver 16 pages averaging 12k of plaintext each using ajax… pretty much buries the needle on one CPU core on my laptop – I shudder to think what it would do on a handheld.


BTW the “related post” I linked to about ads, mentions more phones… but also mentioned they could not measure anything on iPhone because Apple locks something up they need access to, according to them.

Get this, said disaster is featured in a article on the homepage here at Sitepoint:

The docs for “opa” (interesting the article has NO links to the project’s pages…) are the offending part:

Gives a blank page scripting off, uses 3.5 megs as a single file of html/script/css to deliver 10k slices of HTML that appear to be loaded either via DHTML/AJAX; when the entire “manual” part of the site shouldn’t even break 300k. The >1 minute first-load is truly horrifying, much less the complete inaccessible content-less train-wreck.

Off Topic:

I pity anyone trying to learn that language, and like a lot of recent ‘innovations’ wonder how anyone could be dumb enough to want to use it. Poster child for everything wrong with the “but JavaScript and client side processing makes it cool” crowd. Of course my being an old-timer means I don’t trust the idea of a language that compiles to two separate ones and markup. If that site is typical of what “Opa” makes, I would wave everyone off from it.

… and on topic, that’s the type of page that would probably suck a laptop/handheld battery dry… Well hang on, lemme drag out my netbook. I know in ‘normal’ use it loses about 1% every three minutes (battery is starting to go, no shame to it, it’s 4 years old).

From a full charge browsing a few of my normal places to go for ten minutes it lost 3% battery. Charge it back up, go to that site… hey look, it consumed 3% battery just loading that page, which took a minute and 22 seconds – so that’s a massive spike in power consumption. According to Speedfan my poor little 1.6 single core atom was having a heart attack… Dipped into the page file (so hard disk activity too!), buried the needle on the physical core… and this is a 1.6ghz ‘proper’ CPU. Try this on a 800mhz ARM11 with 256 megs of RAM? (like the Pi) You’ll kill the poor thing. Even a 1.5ghz ARM Cortex A8 would struggle since most of them top out at 512 megs of RAM (like the iPhone).

Probably why when I order a tablet this next paycheck (or at least that’s my plan), I’m getting a $130 el-cheapo off DX since it’s a 1.5ghz A8 with SHOCK a gig of RAM (and 1024x800 at 7" and 1.3mp camera and capacitive screen and 8 gigs of in-built with a socket that can take either TF or microSD) … though more RAM also means lower battery life, it could mean longer life by not running out of memory and trying to use flash as swap.

Off Topic:

It’s worth considering an app like Tapatalk, if it’s available for your device. Seems to cut out most of the unnecessary stuff and leave you with just the basics. Pretty nice.

Off Topic:


[ot]It’s worth considering an app like Tapatalk, if it’s available for your device. Seems to cut out most of the unnecessary stuff and leave you with just the basics. Pretty nice.


Of course it is available for everything…except Windows Phone…bah!

Off Topic:

O well, that’s no problem, as no self-respecting web developer would use a Windows mobile device anyway. Um … right? :eek: :shifty: :lol:

Off Topic:

I don’t know about Windows Mobile…but Windows Phone is completely different…tho I’m sure you know that. :stuck_out_tongue:

Off Topic:

Ha ha, don’t assume I know anything (it’s very dangerous. :slight_smile: ) To be honest, I’m a bit confused by the difference between Windows phone and mobile. I’m not very experienced with mobiles, and there is a pretty confusing range of offerings out there. Is it Windows Mobile that still (or until recently) operated on IE7 or something? Jeesh. Anyhow, anything with the name Windows in it scares me.

What OS do you have on your phone? … Or is Win Phone an OS? (It would be nice if their site actually said what the **** it is.)

Off Topic:

Windows Phone, is was a complete departure from Windows Mobile, was written from the ground up. The latest version of Windows Phone 7.5 (Mango) runs a modified version of IE9 the differences can be seen here:

Windows Phone is…hardware (strict guidelines) and an OS.

Off Topic:

On their site they talk about Nokias and whatnot, making it sound like an OS … but its name suggests otherwise. Very confusing. Beats me how they sell anything.

Off Topic:

Yes, Nokia lost Linux (Meebo) and switched to MS Windows.

I blame my engine for poor mileage.

Might as well add HTML to that list. What are we left with than? – that’s right no website, stupid study.

The hardware sucks. If people weren’t releasing things before they were ready for prime time we wouldn’t have these issues. Though we probably wouldn’t have smart phones or tablets either at this point.