I guess the way I think of it... if I am visiting a site or web app, I am actively opting to expend the energy required to render the page. Obviously if the pag

I guess the way I think of it... if I am visiting a site or web app, I am actively opting to expend the energy required to render the page. Obviously if the page is not visible, and not doing a background task like playing audio, then I expect its CPU consumption to be negligible. So, first and foremost, use the page visibility API. If I'm low on battery and choose to open that webpage, and now the WebGL charts are static bitmaps, my first reaction is going to be WTF. Now I want a button synonymous with 'Show Desktop Site' -- I guess we could label it the 'Stop Fucking With Me' button. All code should be aware of the CPU that it is consuming. More efficient code is not just better for battery, but also likely more responsive and better for multitasking. So the question becomes, not how do we reduce CPU and possibly even improve UX, but in what cases would we make the CPU requirement dynamic, and when/where might the trade-offs be made to ultimately improve the user experience. So first is Page Visibility, as discussed. The very next area where I would consider making CPU usage dynamic is not a battery state, but rather it's an overall device performance adjustment. If someone visits with an iPhone 4 versus a 6s, they have dramatically different amounts of compute available. I would consider investing in dynamic CPU consumption based on a device performance flag a lot sooner than I would do it based on remaining charge, because I think it would improve the UX for a large percentage of users every time they used the site. It's also a static setting from the perspective of the device owner, so they are not seeing changing UX on their device potentially from one moment to the next. > None of the above need to significantly increase development or testing costs. I can only offer my opinion based on my experience, but trying to alter functionality to reduce CPU load based on dynamically changing battery metrics across a pool of devices which may behave inconsistently... this is really not simple to code and test and maintain over time. We have a hard enough time just trying to efficiently serve device-specific assets (like lower res images to mobile) and that's based on a static/fixed user-agent string, not a dynamic header, and sites get it wrong so often that user-agents added a special button to try to turn it off!