Foreground workloads
1. Browser
The Browser workload is designed to measure real-world browser performance in a controlled, repeatable environment. To eliminate the variability introduced by network conditions, the workload hosts all content on a local server and loads each page directly from the device under test. This ensures that the results reflect browser rendering, script execution, graphics handling, and system responsiveness rather than network speed or latency.
The workload is composed of five distinct web pages that represent common, familiar browser usage scenarios. These pages are inspired by workloads found in PCMark 10, as well as by everyday tasks users regularly perform in modern web browsers. Each page focuses on different aspects of browser performance, ranging from data heavy interactions and WebGL rendering to media playback and locally executed AI features.
The pages are executed sequentially in a fixed order, as described below.
1.1 CRM Page
The CRM Page simulates a sales manager handling orders from a large customer account. The workload reflects common day-to-day CRM tasks such as searching and filtering large order tables, sorting orders by different criteria, selecting time ranges, and displaying charts to analyze order trends over time.
1.2 Ecommerce Page
The Ecommerce Page is built around an online shopping experience within a web-based store. It serves as a WebGL use case, evaluating the time required to load and display an interactive 3D product model in the browser.
1.3 Chat Page
The Chat Page simulates everyday workplace conversations between colleagues. It reflects familiar work chat scenarios such as messaging, photo and video sharing, and includes locally hosted AI capabilities for text summarization and translation. These local AI features are intentionally included to demonstrate how sensitive data can be processed securely on device, without relying on external services.
1.4 Social Media Page
The Social Media page reflects a professional, work-oriented social networking platform. The workload focuses on common content-consumption interactions such as scrolling through a dynamic feed, opening individual posts to view details and discussions, and playing embedded videos.
1.5 Maps Page
The Maps Page is centered around the use of a modern online mapping service for navigation and location discovery. The workload includes searching for locations and nearby services, exploring areas using street view, and switching to satellite view to examine geographic details.
2. App Startup
The App Startup workload measures a common user scenario; launching an application and waiting until it becomes ready for use. Inspired by PCMark 10 and brought back by popular demand in the Procyon suite, this workload focuses on delivering a realistic day-to-day user experience. Rather than distinguishing between cold and warm startup scenarios, each application is launched with a previously saved document already opened, reflecting how users typically resume work.
The workload includes Chromium, LibreOffice Calc, LibreOffice Impress, and VSCodium. Chromium opens a PDF document, LibreOffice Impress starts with a presentation, LibreOffice Calc loads a large spreadsheet, and VSCodium opens a txt file. Each application is started multiple times across four workload runs to ensure consistent and representative measurements.
3. File Operations
The File Operations workload simulates common file management tasks, including copy, move, delete, and compress/decompress operations. Compression and decompression are performed twice: once using the system’s built-in ZIP utility and once using 7-Zip. The workload initializes files and groups them by size, then duplicates them, assigns unique random names, and converts file extensions to .dat.
Background Workloads
1. Video Call
The Video Call workload represents a realistic background activity that many users experience during a typical workday. It runs continuously for the duration of the test, providing a stable background load while other workloads are active in the foreground.
The simulated call includes multiple participants who take turns speaking. One participant represents the local user, where detection, processing, and encoding are applied to a high-quality video stream. The remaining participants stream lower-resolution video, along with additional attendees displayed as smaller thumbnails. Together, these elements create a realistic video conferencing scenario that mirrors everyday collaboration workloads running alongside other PC tasks.
This workload uses the latest Windows ML framework and, when supported by the system, takes advantage of NPU acceleration as intended for real-world use cases. If the required Windows ML Execution Providers are not present on the system, the benchmark attempts to automatically download them through windows update and install the necessary components as part of the benchmark run. For users who prefer to manage this outside of a benchmark execution, the “Set up WinML EPs” button can be used to manually verify and install the required Execution Providers in advance. When an NPU is available, the SAM 2.1 Tiny model runs on it, helping demonstrate how background AI activity can affect overall system behavior, including foreground workload responsiveness.
To reflect typical real-world usage and avoid rewarding unrealistic over-performance, key aspects of the workload are capped. Video detection is limited to 5 fps, and video streaming is capped at 30 fps, aligning with common video-conferencing requirements. These limits ensure that systems are evaluated on their ability to meet practical performance thresholds rather than exceed them, while devices that fail to sustain these levels are penalized in scoring.
2. Browser Tabs
The Tabs workload is designed to run only as a background activity, simulating a web browser with many open tabs that consume system memory. It reflects a common real-world situation where users keep numerous browser tabs open while working on other tasks.
This workload is largely passive, with only one active measurement performed during the run. It opens 30 static web pages, representing inactive tabs, along with one active foreground page in the bundled Chromium browser. The active page remains open to ensure the browser stays responsive and the tabs remain loaded.
By maintaining a large number of open tabs in the background, this workload helps illustrate the impact of sustained memory usage on overall system behaviour during everyday multitasking scenarios.