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

[Stomme poes]

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.

"Sites who do not [optimise for mobile], end up draining the battery of visiting phones. This can potentially reduce traffic to the site."

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)

[itmitică]

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".

[Belsnickle]

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.

[Jeff Mott]

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.

[itmitică]

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

... 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. I question their purpose only because they've taken a basic truth and they've put a spin to it.

[Stevie D]

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 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).

[itmitică]

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.

[michaeljcalkins]

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

[deathshadow60]

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.

How come, suddenly, CSS and JS are in the hot spot? Because it's flash going and they're taking its place?

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.

[Stomme poes]

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.

WTF???

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.

[deathshadow60]

WTF???

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

http://www.sitepoint.com/have-you-tried-opa/

The docs for "opa" (interesting the article has NO links to the project's pages...) are the offending part:
http://doc.opalang.org

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.

[ralph.m]

Off Topic:

the worst one that I use regularly is Sitepoint Forums 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.

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.

[logic_earth]

Off Topic:

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.

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

[ralph.m]

Off Topic:

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

O well, that's no problem, as no self-respecting web developer would use a Windows mobile device anyway. Um ... right?

[logic_earth]

Off Topic:

O well, that's no problem, as no self-respecting web developer would use a Windows mobile device anyway. Um ... right?

I don't know about Windows Mobile...but Windows Phone is completely different...tho I'm sure you know that. :P

[ralph.m]

Off Topic:

I don't know about Windows Mobile...but Windows Phone is completely different...tho I'm sure you know that. :P

Ha ha, don't assume I know anything (it's very dangerous. ) 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.)

[logic_earth]

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: http://www.ubelly.com/2011/11/the-di...nd-ie9-on-wp7/

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

[ralph.m]

Off Topic:

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

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.

[Stomme poes]

Off Topic:

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

[oddz]

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.

[Jeff Mott]

The BBC headline "Study blames JS and CSS" is certainly overly broad and simplistic, but the study itself is much more nuanced, with a lot of interesting and useful details.

[oddz]

"We hope this paper demonstrates the importance of building a mobile site optimised for mobile devices.

"Sites who do not, end up draining the battery of visiting phones. This can potentially reduce traffic to the site."

I don't think so. What average user is aware of the power consumption of a website. Efficiency as in load time yes, but not power consumption.

"Thus, by designing the mobile version of the site differently than its desktop version, Gmail was able to save energy on the phone."

I have never understood why sites are to blame for this considering the desktop web existed far before mobile web. Therefore, everyone should be pointed fingers at the manufacturers for giving a false impression in regards to their devices supporting the internet. If a device can not run in an effective manor with a standard website than it is not practical and the device should not be marketed with such a feature. A mobile site is convenience it should not be a necessity to make up for the lack of integrity on behalf of a device. A device that existed far after the desktop web. By submitting to this logic we essentially give in to manufacturers releasing things far before they are adequate and that is utter bull sh*t. Why should developers be the ones to cover their mistakes. If anything lets expose them. I fully understand there needs to be a balance between the hardware capabilities and software resource consumption when determining features and implementations but given the mobile webs initial goal was to recreate the desktop experience on a mobile device standard websites should have run effectively before the technology was released. I think the whole thing is absurd but manufacturers will keep on releasing technology before it is ready so yeah…

[Stevie D]

If a device can not run in an effective manor with a standard website than it is not practical and the device should not be marketed with such a feature. A mobile site is convenience it should not be a necessity to make up for the lack of integrity on behalf of a device. A device that existed far after the desktop web. By submitting to this logic we essentially give in to manufacturers releasing things far before they are adequate and that is utter bull sh*t. Why should developers be the ones to cover their mistakes. If anything lets expose them. I fully understand there needs to be a balance between the hardware capabilities and software resource consumption when determining features and implementations but given the mobile webs initial goal was to recreate the desktop experience on a mobile device standard websites should have run effectively before the technology was released. I think the whole thing is absurd but manufacturers will keep on releasing technology before it is ready so yeah…

It depends what you mean by "a standard website". Phones can cope absolutely fine with standard websites, it's websites that add layer upon layer of complexity on top of that that can cause problems. Mobile phone users are not the only people who might struggle with "advanced" websites – just ask Jason how long some of those sites would take to download on his wilderness connection.

The mobile web's initial goal was not to recreate the desktop experience. Early mobile phone browsers had no layout or graphics capabilities, just plain text – it was like having Lynx all over again. They even recommended writing sites in WML, which was a cut-down language, because they recognised that full-blown HTML might be difficult for the devices to cope with. It's only more recently that mobile browsers have started to emulate the desktop experience. As there's pretty much no upper limit on the resources that a site could require, if the author is determined enough, waiting until the device could cope with any website would be a fool's game.

Besides, even resource-intensive websites can work fine on mobile devices, it just means that the battery doesn't last long. Just the same as if you're using the in-built GPS or video camera. Phones aren't intended to be used continuously for these, they are add-ons that are extra to the core purpose of being a phone, so it is not surprising that they don't work quite as well as dedicated devices.

[Stomme poes]

Phones aren't intended to be used continuously for these, they are add-ons that are extra to the core purpose of being a phone, so it is not surprising that they don't work quite as well as dedicated devices.

I'm starting to wonder if this is still true. Phones aren't phones anymore. They're little computers that happen to be able to make calls.

Remember the excitement in the post "Now you can order Dominos Pizza with your iPhone!"

[ralph.m]

I'm starting to wonder if this is still true. Phones aren't phones anymore. They're little computers that happen to be able to make calls.

I splurged and got myself an iPhony this year. 99% of the time I use it to check emails and surf the web. Very occasionally it rings, and scares the hell out of me, and I have to remember what to do. (I also have to find out how to turn the ringtone volume down.) So I agree that these aren't really phones any more, but little computers that also can make phone calls.