Benchmark a pose model on your own device

What it runs

Google’s @mediapipe/tasks-vision package, version 1.1.1 (the stable release on the npm registry when this page was checked on 2026-10-31), loaded from cdn.jsdelivr.net only when you press Run. It runs in WebAssembly, and the package’s delegate option asks for inference on the GPU or the CPU; the benchmark times each one you tick. If the landmarker cannot be created with a delegate on your browser, that row says so instead of a number.

The model files sit on the float16/1/ path of Google’s mediapipe-models storage bucket: the package README gives that URL for lite, and Google’s Android sample downloads all three from it. On 2026-10-31 they were served at 5.5 MiB (lite), 9.0 MiB (full) and 29.2 MiB (heavy). All three produce the same output: MediaPipe’s own Tasks source declares The 33 pose landmarks. (33 points, indexed on the BlazePose 33 keypoint reference), and its num_poses option defaults to 1, which is what this page uses. Which variant to ship is the question Pose Landmarker lite vs full vs heavy answers; this page gives you your own numbers to answer it with.

Why MoveNet is not here yet

MoveNet Lightning and Thunder run in the browser through TensorFlow.js, and the TF.js pose-detection README states PoseNet and MoveNet both return 17 keypoints.. The package loads its weights from tfhub.dev unless you pass your own modelUrl, and when this page was built on 2026-10-31 we could not reach tfhub.dev to confirm those files are still served. A benchmark that might time a failed download is worse than none, so MoveNet stays out until its weight URLs can be checked. Its variants and runtimes are covered in MoveNet Lightning vs Thunder, and the head-to-head is MediaPipe vs MoveNet.

How to read the numbers

• Load is the time from asking for a model to having it ready, so on a first run it includes the download. The second delegate for the same model may be served the file from the browser’s cache, so compare loads across runs, not within one.
• Median and p95 time one call to detectForVideo, which returns the landmarks to JavaScript, after 10 warm-up frames are discarded. p95 is the frame your users notice: a good median with a long tail still stutters.
• 1000/mean fps is the ceiling inference alone allows. Loop fps is what the page actually achieved with one inference per animation frame, so it is also capped by how often the browser paints; it is the closer estimate of a live overlay.
• Pose found counts frames with a detected pose. In video mode the landmarker tracks a found pose from frame to frame, so a run with no person in view can time differently from one with a person in it. The synthetic frame is a drawn figure, not a photo, and is for timing only.
• A browser is not your app. A native Android or iOS build of the same model runs through a different runtime and delegate, and a background tab, low-power mode or a hot device all slow the loop. Run it more than once, on the lowest-end device you intend to support.

What to do with the result is the subject of real-time pose estimation and pose estimation hardware requirements; the wider choice of model is pose estimation models compared, with the native alternatives in Apple Vision vs MediaPipe and ML Kit vs MediaPipe.