Optimize for Battery Level

[00:00:00]
>> Matias Gonzalez: One last trick that can be really useful. If your user has a laptop that has a battery and that person is running low on battery and we throw a bunch of complex effects to that computer, it's also not going to perform because any computer with low battery is a bad computer basically, so we also want to measure usually the battery level of our users.

[00:00:31]
If we're taking all of this careful like the complexity of the site, we might as well just measure the battery. So I've already prepared a hook for that called use battery. It's basically going to subscribe for the get battery navigator API which is going to give us like a lot of information about the battery of the user. So first it's going to return if it's supported, then it's also going to tell us if it's already loaded.

[00:01:09]
We can fetch the battery level if it's charging and how much time does it guess it will take until the discharging and the charging time of it. So I'm going to go and use battery. So I can add this to my logic here, so if the battery is supported and the battery is already fetched, I can add some custom logic for it. If it's not supporting that means the user is just on a device that's just plugged, so we don't need to worry about that.

[00:02:03]
So what I could do is, how much battery do I have? 48%. OK, if my user has less than 50% of battery, let's disable the web wheel, so battery level is less than 0.5, that's also return false. So if I go, I can see that it disabled the effects because I am below the threshold that I have just set. I usually do like 0.3 something like that, and it's not plugged, so it's not battery charging.

[00:02:48]
So if we are on low battery and we're not charging our device, I can just disable like all of these complex effects. So in this case, I'm charging so I can see all of the effects. I'm also over 30%, so I usually add this logic when I see that the site is getting like more and more expensive and you're I guess that it's not going to perform well on a low spec device.

[00:03:26]
To really test, nothing beats actually having an older computer where you can just play around, or a phone, that is in my experience like the ultimate way to actually test with a low spec. Chrome has some way to simulate lower CPU timing so I can go into performance and actually throttle my CPU. But again, this is not floating the ship, so in this case, just going to work fine.

[00:04:02]
But you might find this useful, you have a lot of logic on your CPU and you want to test what happens on a lower spec device. Also, we can test what happens if I am, if I have like a worst internet connection that can be enabled through network and throttle your network and you can even simulate being offline completely and see what happens to your website if you have no internet connection, or if you are in a slower 4G.

[00:04:39]
It's not real, it adds some fake delays, so it might be even slower, but it's good enough to just test what happens to your website on those situations. I guess, so like what I kind of what you've been doing here, I've in my back of my mind, I'm thinking about like progressive enhancement versus graceful degradation. Yeah, seems like we're more doing the latter here.

[00:05:06]
Like I could see in a world where like when we did that animation with the rover, where you may have like built the static version out first and then layered the on top. Is that, are you usually working? Are you usually doing the degrading thing? Or, it's kind of an opinion, yeah, I mean, depending on the use case, but also, depending on like who's your client and who are going to be the users of your client, so if like the vast majority is going to just open on like a MacBook and a good iPhone, then you can just do degradation, because you might also hurt the performance for the user that actually have a Mac because they will first render the simpler version and they will switch, so maybe you just want to like go ahead and initialize like Three.js or whatever you have, and then if you detect that it's not a device that you might have like just switch that off.

[00:06:18]
If you want to take that to the extreme, maybe you can measure that on the server and just reply with a website that's already adapted to the device. That can also happen. I think I haven't really answered your question, but yeah, I just kind of, it depends, it depends. Yeah, it depends, it depends. I mean, when you're thinking about reduced motion, then yes, it's good to like make it progressive because it's going to be easier.

[00:06:56]
Also, one thing I haven't mentioned, when you do the reduced motion version that is usually useful for mobile too, so you can use that layout, that layout for mobile because it's just one thing stuck below the other. So it's not that it will add a lot of time to the development timeline anyway, because you already have to do a simpler version for like a mobile device.

[00:07:23]
Do you ever find it helpful or a good strategy to notify the user that the experience is being throttled for their device or just have it happen without them knowing? No, I usually have that happen without them knowing, yeah. And usually with 3D and shaders I don't disable the experience altogether. I just tweak some parameters to make it like easier to run, so the user shouldn't really notice, apart from the experience like running well.

[00:08:01]
But yeah, on some devices you can, yeah, if it was your crashes altogether, you can just display some image as a safety measure. But most of the users won't hit that anyway. Do you always implement reduced motion for accessibility? If you have like an animation like that, I try to have brushes where the timeline didn't enable us like, like you should always try to as much as possible, then sometimes you have the reality of timelines, and also depend on like how much parallax do you have running around.