BenchmarkXPRT Blog banner

Tag Archives: Edge

WebXPRT 5: AI tests now, lots of room for growth

In past blog posts, we’ve discussed our goal of developing one or more experimental WebXPRT workloads focused on local, browser-side AI technologies. While many of us regularly interact with cloud-based AI apps and services through a browser, on-device AI capabilities are growing rapidly, and we want WebXPRT to continue to evolve with them.

There are several driving factors behind that growth. Web API technologies keep maturing, giving browsers direct access to the hardware they need for real inference work. Advanced GPU and NPU technology is now widely available in consumer devices, so the local computing power necessary to run AI applications on-device is in reach for many users. And for many organizations, there are compelling reasons to execute increasingly vital work like LLM inferencing and agentic coding tasks on local machines—such as data privacy, regulatory compliance, and cost control.

The reasons for the experimental workload approach

The expansion of on-device AI is exactly the type of shift we built the experimental workload concept to capture. As we shared when we first announced the WebXPRT 5 workload lineup, an experimental workload section gives us the flexibility to put cutting-edge measurement tools in users’ hands—even if those tools won’t yet run on every platform WebXPRT has traditionally supported. Experimental scores stay separate from the main overall score and are completely optional, so we can add tests without affecting comparability or asking anyone to retest. That approach maintains WebXPRT’s strengths while preparing the benchmark for the future—and giving all of us valuable information today.

The AI functions that WebXPRT 5 measures today

WebXPRT 5 already includes four workloads that utilize AI capabilities: Video Background Blur with AI, Detect Faces with AI, Image Classification with AI, and Document Scan with AI. These workloads use machine learning—computer vision and OCR models such as a Caffe-based face detector, SqueezeNet for image labeling, and an LSTM-based OCR engine. WebXPRT’s ability to measure how well devices handle those types of workloads has real value, and it reflects the kinds of light browser-side inference tasks that have been in widespread use for a while.

We recognize, though, that there’s a clear need for more demanding local, browser-based AI workloads—especially LLM inference. We’re targeting that need with our experimental work. Like pretty much everyone else, we’re also developing in the midst of an incredibly dynamic technical environment. We want to purposefully move forward without sacrificing WebXPRT’s stability and reliability for the sake of expedience.

The main decisions we face

Choosing a Web AI framework. We’re still researching our open-source framework options, including candidates like ONNX Runtime Web, Transformers.js, MediaPipe, and TensorFlow.js. The ground here continues to shift. For example, Transformers.js v4 now supports a WebGPU backend and spans a very broad range of model architectures. So, one of our ongoing challenges is picking a durable foundation.

Choosing a web API. Of the primary options we’re investigating, WebGPU now has the broadest browser support (Chrome, Edge, and partial support in Firefox and Safari). WebNN remains the most promising option in the long term because it can directly target NPUs, but it’s still not ready for production—its W3C spec only reached Candidate Recommendation status in early 2026, and browser support outside of flagged, experimental builds isn’t there yet. Our web API outlook hasn’t changed much from before: WebGPU is the most practical path today, and WebNN may be an exciting possibility for tomorrow.

Choosing and sizing workloads. We’ll ideally find workloads demanding enough to genuinely stress new hardware, but light enough to run on slightly older gear without forcing huge model downloads or overextending the test’s runtime. The sweet spot for browser inference today tends to be small, quantized models, and memory ceilings and cold-start downloads are real constraints. Striking the right balance is another part of the challenge we’re working through.

We appreciate your patience

We’ve been talking about experimental WebXPRT AI workloads for a while. While we wish we already had everything worked out, we think the end product will be worth the wait. We appreciate your patience as we work through the details, and we’ll keep updating you here in the blog as we make progress.

As always, we’re open to suggestions. If you have ideas for a browser-based AI workload scenario, a framework or API you think we should weigh, a browser-based AI application you want us to consider, or any other related thoughts, please let us know!

Justin

Thinking through a potential WebXPRT 4 battery life test

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

Comparing the WebXPRT 4 performance of five popular browsers

Every so often, we like to refresh a series of in-house WebXPRT comparison tests to see if recent updates have changed the performance rankings of popular web browsers. We published our most recent comparison last February, when we used WebXPRT 4 to compare the performance of five browsers on the same system.

For this round of tests, we used the same Dell XPS 13 7930 laptop as last time, which features an Intel Core i3-10110U processor and 4 GB of RAM, running Windows 11 Home updated to version 23H2 (22631.307). We installed all current Windows updates, and updated each of the browsers under test: Brave, Google Chrome, Microsoft Edge, Mozilla Firefox, and Opera.

After the update process completed, we turned off updates to prevent them from interfering with test runs. We ran WebXPRT 4 three times on each of the five browsers. The score we post for each browser is the median of the three test runs.

In our last round of tests, the range between high and low scores was tight, with an overall difference of only 4.3 percent. Edge squeaked out a win, with a 2.1 percent performance advantage over Chrome. Firefox came in last, but was only one overall score point behind the tied score of Brave and Opera.

In this round of testing, the rank order did not change, but we saw more differentiation in the range of scores. While the performance of each browser improved, the range between high and low scores widened to a 19.1 percent difference between first-place Edge and last-place Firefox. The scores of the four Chromium-based browsers (Brave, Opera, Chrome, and Edge) all improved by at least 21 points, while the Firefox score only improved by one point. 

Do these results mean that Microsoft Edge will always provide a faster web experience, or Firefox will always be slower than the others? Not necessarily. It’s true that a device with a higher WebXPRT score will probably feel faster during daily web activities than one with a much lower score, but your experience depends in part on the types of things you do on the web, along with your system’s privacy settings, memory load, ecosystem integration, extension activity, and web app capabilities.

In addition, browser speed can noticeably increase or decrease after an update, and OS-specific optimizations can affect performance, such as with Edge on Windows 11 and Chrome on Chrome OS. All these variables are important to keep in mind when considering how WebXPRT results may translate to your everyday experience.

Have you used WebXPRT 4 to compare browser performance on the same system? Let us know how it turned out!

Justin

A new playing field for WebXPRT

WebXPRT is one of the go-to benchmarks for evaluating browser performance, so we’re always interested in browser development news. Recently, Microsoft created a development channel where anyone can download early versions of an all-new Microsoft Edge browser. Unlike previous versions of Edge, Microsoft constructed the new browser using the Chromium open-source project, the same foundation underlying the Google Chrome browser and Chrome OS.

One interesting aspect of the new Edge development strategy is the changes that Microsoft is making to more than 50 services that Chromium has included. If you use Chrome daily, you’ve likely become accustomed to certain built-in services such as ad block, spellcheck, translate, maps integration, and form fill, among many others. While each of these is useful, a large number of background services running simultaneously can slow browsing and sap battery life. In the new Edge, Microsoft is either reworking each service or removing it altogether, with the hope of winning users by providing a cleaner, faster, and more power-efficient experience. You can read more about Microsoft’s goals for the new project on the Microsoft Edge Insider site.

As we’ve discussed before, many factors contribute to the speed of a browsing experience and its WebXPRT score. It’s too early to know how the new Microsoft Edge will stack up against other browsers, but when the full version comes out of development, you can be sure that we’ll be publishing some comparison scores. I’ve installed the Dev Channel version of Edge on my personal machine and run WebXPRT 3. While I can’t publish the scores from this early version, I can tell you that the results were interesting. Have you run WebXPRT 3 on the new Microsoft Edge? How do you think it compares to competitors? We’d love to hear your thoughts.

Justin

Check out the other XPRTs:

Forgot your password?