Single-image tests cover normal editor actions and the lossless JPEG metadata cleanup path.
Measured browser-local processing
QuokkaPix browser image processing benchmark
QuokkaPix processes images and PDF files in the browser, so speed depends on the local device. This page publishes a repeatable benchmark instead of a vague performance claim: 10 full benchmark passes, desktop and mobile Chromium projects, image workflows, PDF tools and local background AI cold/warm runs.
Success rate100%200 successful measured entries across 10 full runs.
Batch median912 msFive-file WebP ZIP workflow on desktop Chromium.
Scenario median991 msResize, compress and metadata cleanup in one batch scenario.
AI warm median5,675 msFast background model after the local model is already loaded.
What was measured
The benchmark uses Playwright against the production build, uploads local fixture files through the same browser file input that people and agents use, waits for QuokkaPix to finish, then reads the result manifest and output metadata. It is not a synthetic JavaScript loop.
Batch tests cover five input files, ZIP output and a repeatable resize + compress + metadata scenario.
PDF tools are tested as separate local document workflows, not as image conversions.
The fast background model is measured once cold and once warm in the same browser context.
Fast overview
Bars show median wall-clock time. Lower is faster. The AI cold rows are intentionally much longer because the first run can include model loading and initialization.
Full aggregate table
Each row is grouped by browser project, benchmark case and run label. The table uses successful runs only for median and average values, while success rate includes failures if any occur.
| Project | Case | Run | Success | Median | Average | Min / max | Processing median | Output median | Peak JS heap |
|---|---|---|---|---|---|---|---|---|---|
| desktop | Background AI fast model cold/warmbackground-ai-fast-cold-warm |
cold | 10/10 | 11,898 ms | 11,910 ms | 11,463 ms / 12,424 ms | 11,783 ms | 100.9 KB | 9.5 MB |
| desktop | Background AI fast model cold/warmbackground-ai-fast-cold-warm |
warm | 10/10 | 5,675 ms | 5,621 ms | 5,287 ms / 5,742 ms | 5,536 ms | 100.9 KB | 9.5 MB |
| desktop | Five-file batch compress to ZIPbatch-compress-zip |
run | 10/10 | 912 ms | 920 ms | 883 ms / 976 ms | 728 ms | 42.2 KB | 9.5 MB |
| desktop | JPEG metadata cleanupmetadata-lossless-jpeg |
run | 10/10 | 73 ms | 73 ms | 66 ms / 79 ms | 4 ms | 27.7 KB | 10.1 MB |
| desktop | PDF extract pages to PDFpdf-extract |
run | 10/10 | 344 ms | 425 ms | 254 ms / 680 ms | 219 ms | 12.7 KB | 10.1 MB |
| desktop | PDF merge two documentspdf-merge |
run | 10/10 | 260 ms | 314 ms | 237 ms / 707 ms | 194 ms | 25.0 KB | 9.5 MB |
| desktop | PDF split to ZIPpdf-split |
run | 10/10 | 438 ms | 469 ms | 371 ms / 625 ms | 270 ms | 37.8 KB | 10.1 MB |
| desktop | Scenario resize + compress + metadatascenario-web-optimization |
run | 10/10 | 991 ms | 975 ms | 885 ms / 1,020 ms | 807 ms | 32.6 KB | 48.1 MB |
| desktop | Single image compress to WebPsingle-compress-webp |
run | 10/10 | 558 ms | 572 ms | 543 ms / 708 ms | 474 ms | 9.4 KB | 10.1 MB |
| desktop | Single image resize fitsingle-resize-fit |
run | 10/10 | 555 ms | 562 ms | 518 ms / 718 ms | 392 ms | 19.5 KB | 10.1 MB |
| mobile | Background AI fast model cold/warmbackground-ai-fast-cold-warm |
cold | 10/10 | 11,813 ms | 11,823 ms | 11,560 ms / 12,119 ms | 11,717 ms | 100.9 KB | 9.8 MB |
| mobile | Background AI fast model cold/warmbackground-ai-fast-cold-warm |
warm | 10/10 | 5,666 ms | 5,604 ms | 5,287 ms / 5,691 ms | 5,551 ms | 100.9 KB | 9.8 MB |
| mobile | Five-file batch compress to ZIPbatch-compress-zip |
run | 10/10 | 887 ms | 898 ms | 832 ms / 1,005 ms | 726 ms | 42.2 KB | 9.5 MB |
| mobile | JPEG metadata cleanupmetadata-lossless-jpeg |
run | 10/10 | 68 ms | 67 ms | 61 ms / 73 ms | 4 ms | 27.7 KB | 10.1 MB |
| mobile | PDF extract pages to PDFpdf-extract |
run | 10/10 | 246 ms | 342 ms | 233 ms / 632 ms | 175 ms | 12.7 KB | 10.1 MB |
| mobile | PDF merge two documentspdf-merge |
run | 10/10 | 250 ms | 266 ms | 244 ms / 382 ms | 193 ms | 25.0 KB | 9.5 MB |
| mobile | PDF split to ZIPpdf-split |
run | 10/10 | 383 ms | 419 ms | 367 ms / 552 ms | 226 ms | 37.8 KB | 9.8 MB |
| mobile | Scenario resize + compress + metadatascenario-web-optimization |
run | 10/10 | 937 ms | 928 ms | 848 ms / 1,003 ms | 799 ms | 32.6 KB | 48.1 MB |
| mobile | Single image compress to WebPsingle-compress-webp |
run | 10/10 | 545 ms | 548 ms | 532 ms / 580 ms | 465 ms | 9.4 KB | 10.1 MB |
| mobile | Single image resize fitsingle-resize-fit |
run | 10/10 | 517 ms | 518 ms | 512 ms / 533 ms | 394 ms | 19.5 KB | 10.1 MB |
How to read the numbers
Wall time is the user-visible wait
Wall time starts after files are uploaded into the browser and ends when the editor reaches a terminal status. It includes local JavaScript, browser export, ZIP/PDF assembly and result state updates.
Processing time comes from the manifest
The QuokkaPix result manifest reports the internal processing duration where available. It is useful for debugging, while wall time is closer to what a person or agent feels.
Memory is sampled, not invented
Chromium exposes sampled JavaScript heap through performance.memory in this benchmark environment. That is not full process RAM, so the page labels it as sampled JS heap only.
Coverage checklist
| Area | Covered benchmark cases | What this proves | What it does not prove |
|---|---|---|---|
| Core image tools | Resize, WebP compression, JPEG metadata cleanup | The main browser export path completes on desktop and mobile projects. | It does not test every possible input format, quality value or crop geometry. |
| Batch and scenarios | Five-file ZIP and scenario builder batch | Queue processing, ZIP output and chained settings work through the public agent surface. | It does not replace separate stress testing for 50 large files on low-memory phones. |
| PDF tools | Split, extract and merge | The PDF mode accepts PDF files and produces ZIP/PDF outputs locally. | It does not benchmark very large scanned PDFs or encrypted documents. |
| Background AI | Fast model cold and warm | The local model path completes and warm runs are faster after initialization. | It does not compare visual mask quality against external AI services. |
| Agent compatibility | All tests run through window.QuokkaPixAgent | The same runtime used by local agents can apply settings, upload files, start runs and read manifests. | Paid x402 settlement is tested elsewhere and is not part of this browser performance page. |
Are these results normal?
Yes, for this kind of browser-only editor the numbers are healthy. Metadata cleanup and PDF assembly are fast. Batch ZIP and scenario work are around the one-second range on the measured desktop and mobile Chromium projects. The background AI fast model is the slowest path, which is expected because local AI has to load and run a segmentation model in the browser. The useful signal is that all 200 measured entries completed successfully and warm AI runs were materially faster than cold runs.
Document operations are not the bottleneck in the measured fixture set.
Five-file batch export completes quickly enough for normal local use and agent checks.
The first local AI run is slower because the model path is cold.
Warm AI is faster after the model is initialized in the browser context.
Methodology and limitations
Repeatability
The public numbers come from 10 full benchmark passes. For each case, the page shows medians, averages, minimums and maximums instead of a single best run.
Fixture size
The fixtures are intentionally small and deterministic. They prove that core paths work and provide a stable baseline. They do not claim the same timing for a 60 MB image or a 200-page PDF.
Browser dependence
QuokkaPix uses browser APIs, workers and local encoders. Different browsers, graphics drivers, CPU throttling, mobile battery state and cache state can change results.
Privacy boundary
The benchmark uploads files only into the local browser page. It does not call a server-side image processing API because QuokkaPix does not provide one for normal image processing.
FAQ
Should these numbers be used as an absolute performance promise?
No. They are measured results for one benchmark environment and fixture set. They are useful as a baseline and as proof that the browser workflows complete reliably.
Why not publish one average number?
A single average hides cold starts, slow outliers and different workflow costs. Median, min and max show the real spread more honestly.
Does this benchmark cover real users and agents?
It covers the same browser runtime surface used by people and agents: file input, settings, start, status and result manifest. It does not replace production analytics or paid x402 settlement tests.