BenchmarkXPRT Blog banner

Category: Collaborative benchmark development

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

WebXPRT 5 source code access is on the way

Recently, a member of the tech press asked us if we were planning to offer a way for users to set up an offline version of WebXPRT 5 for locally hosted tests. The short answer is “yes.”

The long answer is that the question provides us with a good opportunity to talk about XPRT source code access and let new users know how it works.

Since the early days of the BenchmarkXPRT Development Community, we’ve provided free access to the benchmark source code. We believe that by publishing XPRT code and allowing interested parties to access and review that code, we’re doing our part to encourage transparency and honesty in the benchmarking industry.

While we offer free access to the XPRT source code, our approach to derivative work differs from some traditional open-source models that encourage developers to alter products and even take them in substantially different directions. Because benchmarking requires a product that remains static to enable valid comparisons, we prioritize maintaining the integrity and consistency of the benchmark over time. So, we allow people to download the source, but we also reserve the right to control derivative works. This approach discourages a situation where someone publishes an unauthorized version of the benchmark and calls it an “XPRT.”

For WebXPRT 5, we’ll offer the code in the form of a build package—containing all the necessary files and instructions—that will be available upon request. By offering the code upon request, as opposed to posting a permanent download link, we can prevent bots or other malicious actors from downloading it. This method also lets us engage with users interested in the source code and answer their questions.

With the WebXPRT 5 build package, you’ll be able to set up your own WebXPRT 5 instance for purposes of review, internal testing, or experimentation. We do ask that you publish only test results from the official version of WebXPRT 5 that we host at WebXPRT.com.

We expect to have the build package ready within the next few weeks. When it’s available, we’ll let readers know here in the blog, and we’ll provide more details about the access and setup process.

If you have any questions about accessing the WebXPRT 5 source code, please let us know!

Justin

WebXPRT 5 GA is almost here!

Exciting news: We’re currently in the final stages of preparing for the WebXPRT 5 GA release and expect to take it live very soon!

The WebXPRT 5 Preview period has been very successful, and we appreciate the interest and engagement that we’ve seen from around the world. When we released the Preview and encouraged testers to submit and publish results, we said we’d try to limit any changes in the GA release to areas that would not affect test scores, such as the UI and non-workload features. We’re pleased to report that we’ve achieved that goal. WebXPRT 5 Preview testing results will be comparable with GA build results, so there will be no need to retest with the GA if you’ve already recorded Preview build scores.

If you haven’t yet used the WebXPRT 5 Preview, we encourage you to check out this blog post about the workload lineup. As we implied above, the seven core workloads in the Preview build will remain unchanged in the GA release. Additionally, while we are including a placeholder section for future experimental workloads, we’re not yet ready to include one in the GA release. We are actively working on candidate workloads for that section, but some of the underlying web technologies are not yet ready for widespread use. Taking the time to get these experimental workloads right means that there are really cool and all-new WebXPRT 5 capabilities that are still on the way!

Keep an eye on this space and WebXPRT.com for the GA announcement. This new chapter in the WebXPRT story will be the best one yet!

Justin

The WebXPRT 5 Preview is here!

We’re excited to announce that the WebXPRT 5 Preview is now available!

The Preview is available to everyone. You can access it at www.WebXPRT5.com or through a link on WebXPRT.com.

You are free to publish scores from testing with this Preview build; in fact, we encourage it. We want to know how it is performing for you, so we love to see both test scores and any feedback you would like to give.

We may still tweak a few things in the benchmark between this Preview and the final release. We plan to limit any potential changes, however, to areas like the UI and other features, things we do not expect to affect test scores.

Longtime WebXPRT users will notice that while the WebXPRT 5 Preview UI has a new look and feel, the basic layout has not changed. The general process for kicking off both manual and automated tests is the same as with WebXPRT 4, so the transition from WebXPRT 4 to WebXPRT 5 testing should be straightforward.

We also encourage you to check out our recent XPRT blog post on the WebXPRT 5 workload lineup for more details about what’s new in the Preview release—including more AI-oriented scenarios than ever before!

After you try the WebXPRT 5 Preview, please send us your comments. Thanks, and happy testing!

Justin

WebXPRT 5: The workload lineup

The WebXPRT 5 development process heading into the final stretch, so we’d like to share more information about the workloads you’re likely to see in the WebXPRT 5 Preview release—and when that release may be available. We’re still actively testing candidate builds, studying results from multiple system tests, and so on, so some details could change. That said, we’re now close enough to provide a clearer picture of the workload lineup.

Core workloads

WebXPRT 5 will likely include the following seven workloads:  

  • Video Background Blur with AI. Blurs the background of a video call using an AI-powered segmentation model.
  • Photo Effects. Applies a filter to six photos using the Canvas API.
  • Detect Faces with AI. Detects faces and organizes photos in an album using computer vision (OpenCV.js with Caffe Model).
  • Image Classification with AI. Labels images in an album using machine learning (OpenCV.js and ML Classify with the SqueezeNet model).
  • Document Scan with AI. Scans a document image and converts it to text using ML-based OCR (Wasm with LSTM).
  • School Science Project. Processes a DNA sequencing task using Regex and String manipulation.
  • Homework Spellcheck. Spellchecks a document using Typo.js and Web Workers.

The sub-scores for each of these tests will contribute to WebXPRT 5’s main overall score. (We’ll discuss scoring in future blogs.)

Experimental workloads

We’re currently planning to include an experimental workload section, something we’ve long discussed, in WebXPRT 5. Workloads in this section will use cutting-edge browser technologies that may not be compatible with the same broad range of platforms and devices as the technologies in WebXPRT 5’s core workloads. For that reason, we will not include the scores from the experimental section—in the Preview build and future releases—in WebXPRT 5’s main overall score.

In addition, WebXPRT 5’s experimental workloads will be completely optional.

Moving forward, WebXPRT’s experimental workload section will provide users with a straightforward way to learn how well certain browsers or systems handle new browser-based technologies (e.g., new web apps or AI capabilities). We’ll benefit from the ability to offer workloads for large-scale testing and user feedback before committing to including them as core WebXPRT workloads. Because future experimental workloads will run independently of the main test, we can add them without affecting the main WebXPRT score or requiring users to repeat testing to obtain comparable scores. We think it will be a win-win scenario in many respects.  

We’re still evaluating whether we can finish the first experimental workload in time to include it in the WebXPRT 5 Preview release, but we will definitely have at least the section and the framework for adding such a workload. When we are confident that an experimental workload is ready to go, we’ll share more information here in the blog and be all set up to incorporate it.

Timeline

If all goes well, we hope to publish the WebXPRT 5 Preview very soon, followed by a general release in early 2026. If that timeline changes significantly, we’ll provide an update here in the blog as soon as possible.

What about an “AI score”?

We’re still discussing the concept of a stand-alone WebXPRT 5 “AI score,” and we go back and forth on it. That score would combine WebXPRT’s AI-related subscores into a single score for use in AI capability comparisons. Because we’re just now beefing up WebXPRT’s AI capabilities, we’ve definitely decided not to include an AI score right now. We would love your feedback on the concept as we plan WebXPRT’s future. If that’s something that you would be interested in, please let us know!

If you have any questions about the WebXPRT 5 details we’ve shared above, please feel free to ask!

Justin

Multi-tab testing in a future version of WebXPRT?

In previous posts about our recommended best practices for producing consistent and reliable WebXPRT scores, we’ve emphasized the importance of “clean” testing. Clean testing involves minimizing the amount of background activity on a system during test runs to ensure stable test conditions. With stable test conditions, we can avoid common scenarios in which startup tasks, automatic updates, and other unpredictable processes contribute to high score variances and potentially unfair comparisons.

Clean testing is a vital part of accurate performance benchmarking, but it doesn’t always show us what kind of performance we can expect in typical everyday conditions. For example, while a browser performance test like WebXPRT can provide clean testing scores that serve as a valuable proxy for overall system performance, an entire WebXPRT test run involves only two open browser tabs. Most of us will have many more tabs open at any given time during the day. Those tabs—and any associated background services, extensions, plug-ins, or renderers—have the potential to require CPU cycles and frequently consume memory resources. Depending on the number of tabs you leave open, the performance impact on your system can be noticeable. Even with modern browser tab management and resource-saving features, a proliferation of tabs can still have a significant impact on your computing experience.

To address this type of computing, we’ve been considering the possibility of adding one or more multi-tab testing features to a future version of WebXPRT. There are several ways we could do this, including the following options:

  • We could open each full workload cycle in a new tab, resulting in seven total tabs.
  • We could open each individual workload iteration in a new tab, resulting in 42 total tabs.
  • We could allow users to run multiple full tests back-to-back while keeping the tabs from the previous test(s) open.

If we do decide to add multi-tab features to a future version of WebXPRT, we could integrate them into the main score or make them optional and thus not affect traditional WebXPRT testing. We’re looking at all these options.

Whenever we have multiple choices, we seek your input. We want to know if a feature like this is something you’d like to see. Below, you’ll find two quick survey questions that will help us gauge your interest in this topic. We would appreciate your input!

Would you be interested in using future WebXPRT multi-tab testing features?

How many browser tabs do you typically leave open at one time?

If you’d like to share additional thoughts or ideas related to possible multi-tab features, please let us know!

Justin

Check out the other XPRTs:

Forgot your password?