In recent blog posts, we’ve discussed some of the technical considerations we’re working through on our path toward a future AI-focused WebXPRT 4 auxiliary workload. While we’re especially excited about adding to WebXPRT 4’s AI performance evaluation capabilities, AI is not the only area of potential WebXPRT 4 expansion that we’ve thought about. We’re always open to hearing suggestions for ways we can improve WebXPRT 4, including any workload proposals you may have. Several users have asked about the possibility of a WebXPRT 4 battery life test, so today we’ll discuss what one might look like and some of the challenges we’d have to overcome to make it a reality.
Battery life tests
fall into two primary categories: simple rundown tests and performance-weighted
tests. Simple rundown tests measure battery life during extreme idle periods
and loops of movie playbacks, etc., but do not reflect the wide-ranging mix of
activities that characterize a typical day for most users. While they can be
useful for performing very specific apples-to-apples comparisons, these tests don’t
always give consumers an accurate estimate of the battery life they would
experience in daily use.
In contrast,
performance-weighted battery life tests, such as the one in CrXPRT 2, attempt to reflect
real-world usage. The
CrXPRT battery life test simulates common daily usage patterns for Chromebooks
by including all the productivity workloads from the performance test, plus
video playback, audio playback, and gaming scenarios. It also includes periods
of wait/idle time. We believe this mixture of diverse activity and idle time better
represents typical real-life behavior patterns. This makes the resulting
estimated battery life much more helpful for consumers who are trying to match
a device’s capabilities with their real-world needs.
From a technical standpoint,
WebXPRT’s cross-platform nature presents us with several challenges that we did
not face while developing the CrXPRT battery life test for ChromeOS. While the WebXPRT
performance tests run in almost any browser, cross-browser differences and
limitations in battery life reporting may restrict any future battery life test
to a single browser or browser family. For instance, with the W3C Battery Status API, we can currently query battery status data from non-mobile
Chromium-based browsers (e.g., Chrome, Edge, Opera, etc.), but not from Firefox
or Safari. If a WebXPRT 4 battery life test supported
only a single browser family, such as Chromium-based browsers, would you still
be interested in using it? Please let us know.
A browser-based battery life
workflow also presents other challenges that we do not face in native client
applications, such as CrXPRT:
- A
browser-based battery life test may require the user to check the starting and
ending battery capacities, with no way for the app to independently verify data
accuracy.
- The
battery life test could require more babysitting in the event of network
issues. We can catch network failures and try to handle them by reporting
periods of network disconnection, but those interruptions could influence the
battery life duration.
- The
factors above could make it difficult to achieve repeatability. One way to address
that problem would be to run the test in a standardized lab environment with a
steady internet connection, but a long list of standardized environmental
requirements would make the battery life test less attractive and less
accessible to many testers.
We’re not sharing these thoughts to make a WebXPRT 4 battery life test seem like an impossibility. Rather, we want to offer our perspective on what the test might look like and describe some of the challenges and considerations in play. If you have thoughts about battery life testing, or experience with battery life APIs in one or more of the major browsers, we’d love to hear from you!
Justin
