Skip to content

Raspberry Pi Chrome ARM64 vs Chromium vs Firefox Benchmark

Google Chrome ARM64, Raspberry Pi OS Chromium, and Firefox should be compared on the same Raspberry Pi, OS, display session, pages, and profile state. This guide supplies a reproducible test protocol and blank result tables; it does not present estimated browser performance as measured data.

What to compare

Question Metric
Which starts fastest? Process launch to DevTools/readiness endpoint or first usable window
Which uses less memory? Total proportional set size after the same tabs and idle period
Which loads the workload faster? Navigation timing and task completion, not one visual impression
Which handles video best? Dropped frames, CPU, temperature, throttling, and power
Which meets synchronization needs? Supported bookmarks, passwords, history, and tab behavior
Which remains stable? Crashes, renderer kills, tab reloads, and errors over a fixed soak test

Browser roles before performance

Browser Package source Account synchronization
Google Chrome ARM64 Google's official ARM64 Debian package/repository Google Chrome Sync
Chromium Raspberry Pi OS repository No supported private Google Chrome Sync; use separate services/extensions
Firefox Raspberry Pi OS/Debian repository Firefox Sync

Do not choose only by a synthetic score. Package trust, update path, required extensions, account model, codec behavior, and application compatibility may decide the result.

Record the test system

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
mkdir -p "$HOME/browser-bench"

{
  date --iso-8601=seconds
  cat /proc/device-tree/model
  cat /etc/os-release
  uname -a
  echo "session=${XDG_SESSION_TYPE:-unknown}"
  echo "desktop=${XDG_CURRENT_DESKTOP:-unknown}"
  google-chrome-stable --version 2>/dev/null || true
  chromium --version 2>/dev/null || true
  firefox --version 2>/dev/null || true
  free -h
  vcgencmd get_throttled
  vcgencmd measure_temp
} | tee "$HOME/browser-bench/system.txt"

Also record:

  • Pi model and RAM
  • power supply and external power-meter model
  • case, cooling policy, ambient temperature
  • monitor resolution and refresh rate
  • Wayland or X11
  • enabled extensions and browser policies
  • network path, DNS, and cache state
  • URLs/content hashes for local test pages

Install without mixing package sources

Use the normal Raspberry Pi OS packages for Chromium and Firefox:

1
2
sudo apt update
sudo apt install chromium firefox smem curl

Use the official Chrome ARM64 installation guide for Google Chrome. Record apt policy output:

1
2
apt policy google-chrome-stable chromium firefox \
  | tee "$HOME/browser-bench/package-policy.txt"

Do not install multiple builds from random repositories or compare a development channel against stable without labeling it.

Define two benchmark profiles

Clean-profile test

Use a new temporary profile for each repetition. This compares browser startup/runtime without personal extensions, history, or Sync data.

Real-profile test

Use a copy of a representative profile with the same extensions and settings. Do not publish the profile because it can contain tokens, cookies, history, and credentials.

Report the two profiles separately. A clean benchmark cannot predict the exact behavior of a heavily extended daily profile.

Control network variability

For browser-engine comparisons, serve fixed local content from another machine or the Pi:

1
2
3
4
mkdir -p "$HOME/browser-bench/site"
printf '<!doctype html><title>Browser test</title><h1>Ready</h1>\n' \
  > "$HOME/browser-bench/site/index.html"
python3 -m http.server 8080 --directory "$HOME/browser-bench/site"

Use http://127.0.0.1:8080/ for startup/readiness tests. For real-web tests, select a fixed URL list and run enough repetitions at comparable times. Third-party content, ads, CDN state, and network congestion make results noisier.

Measure startup readiness

For Chromium-family browsers, a remote-debugging endpoint provides a machine-readable readiness event. Save this script as measure-chromium-start.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#!/bin/bash
set -euo pipefail

browser=${1:?usage: measure-chromium-start.sh <browser-command> <port>}
port=${2:?usage: measure-chromium-start.sh <browser-command> <port>}
profile=$(mktemp -d)
log=$(mktemp)

cleanup() {
  if [[ -n "${browser_pid:-}" ]]; then
    kill "$browser_pid" 2>/dev/null || true
    wait "$browser_pid" 2>/dev/null || true
  fi
  rm -rf -- "$profile" "$log"
}
trap cleanup EXIT

start_ns=$(date +%s%N)
"$browser" \
  --user-data-dir="$profile" \
  --remote-debugging-port="$port" \
  --no-first-run \
  --disable-default-apps \
  http://127.0.0.1:8080/ >"$log" 2>&1 &
browser_pid=$!

for _ in $(seq 1 300); do
  if curl -fsS "http://127.0.0.1:$port/json/version" >/dev/null; then
    end_ns=$(date +%s%N)
    awk -v start="$start_ns" -v end="$end_ns" \
      'BEGIN {printf "%.3f\n", (end-start)/1000000000}'
    exit 0
  fi
  kill -0 "$browser_pid" 2>/dev/null || {
    sed -n '1,100p' "$log" >&2
    exit 1
  }
  sleep 0.02
done

echo 'readiness timeout' >&2
exit 1

Run one browser at a time with a different port:

1
2
3
chmod +x measure-chromium-start.sh
./measure-chromium-start.sh google-chrome-stable 9222
./measure-chromium-start.sh chromium 9223

This measures process launch to DevTools endpoint, not the first painted or interactive frame. Label it accordingly. Firefox needs a separate measurement boundary; use a visible first-usable-window test or an automation framework that supports the installed version, and do not compare unlike boundaries as one number.

Run a warm-up excluded from results, then at least ten measured repetitions. Return the system to an idle state between runs.

Measure memory fairly

Open the same URLs in the same order, wait a fixed 60 seconds, then use proportional set size:

1
sudo smem -tk -P 'chrome|chromium|firefox'

Because browsers use multiple processes, do not compare only the largest renderer's RSS. Record total PSS for all processes belonging to that browser and make sure another browser is not running.

Test at least these workloads:

  1. Blank local page
  2. Five fixed documentation pages
  3. Ten representative daily tabs
  4. One 1080p video workload
  5. A 30-minute idle period after closing tabs

Record tab reloads or renderer kills; a low memory number caused by discarded tabs is not equivalent behavior.

Measure page navigation

Use Chrome DevTools Performance/Network exports or a reproducible automation tool to capture:

  • navigation start to DOMContentLoaded
  • navigation start to load event
  • largest contentful paint where applicable
  • transferred bytes and request count
  • main-thread long tasks
  • cache state

For local pages, run cold-cache and warm-cache tests separately. For internet pages, record failures and content changes. Do not mix results collected through different ad blockers or privacy extensions.

Measure video playback

Use the same local video file or fixed stream, codec, resolution, duration, window size, and display refresh rate. Record browser media diagnostics and system state:

1
pidstat -urd -p ALL 1 | tee "$HOME/browser-bench/video-pidstat.txt"

In another terminal:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
duration=600
output="$HOME/browser-bench/video-thermal.csv"
printf 'timestamp,temp_c,arm_hz,throttled\n' > "$output"
for _ in $(seq 1 "$duration"); do
  timestamp=$(date +%s)
  temp=$(awk '{print $1/1000}' /sys/class/thermal/thermal_zone0/temp)
  arm_hz=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
  throttled=$(vcgencmd get_throttled | cut -d= -f2)
  printf '%s,%s,%s,%s\n' "$timestamp" "$temp" "$arm_hz" "$throttled" >> "$output"
  sleep 1
done

Record dropped frames from the browser's media diagnostics and external input power where possible. vcgencmd cannot provide calibrated whole-board energy.

Test account synchronization separately

Use a disposable bookmark folder and non-sensitive test entry:

  1. Add it on another device.
  2. Time until it appears on the Raspberry Pi browser.
  3. Edit it on the Pi.
  4. Confirm conflict/merge behavior on the other device.
  5. Sign out and verify local-data behavior.

Do not use production passwords for a benchmark. Browser Sync capability is a functional result, not a speed score.

Stability soak test

Run the same tab set for four or more hours and record:

  • browser crashes
  • renderer crashes
  • automatic tab discards/reloads
  • memory growth
  • maximum temperature and throttling bits
  • video dropped frames
  • extension failures
  • sleep/display-resume behavior

A benchmark that completes in one minute may miss the behavior that matters on a kiosk or daily desktop.

Blank result tables

Startup and memory

Browser/version Startup median, s Min/max, s Blank PSS, MiB 10-tab PSS, MiB Reloads
Chrome ARM64
Chromium
Firefox

Video and stability

Browser/version Dropped frames Median CPU, % Max temp, °C Energy, Wh Throttle bits Crashes
Chrome ARM64
Chromium
Firefox

Functional choice

Requirement Chrome ARM64 Chromium Firefox
Required account sync
Required extension
Kiosk policy
Video workload
Update path verified
Selected

Leave cells blank until a named physical test system produces the values. Publish raw CSV/logs and browser/package versions with the result.

Common benchmark mistakes

  • Comparing a first launch with an already-running background process
  • Using personal profiles with different extensions
  • Comparing total Chrome memory with one Firefox process
  • Mixing Wayland and X11
  • Changing monitor resolution or cooling
  • Using live websites without recording content/network variability
  • Claiming hardware video decode from low CPU alone
  • Reporting the fastest run instead of the median and range
  • Treating a synthetic score as the only browser decision
  • Publishing profile data or Sync credentials

FAQ

Which browser is fastest on Raspberry Pi 5?

It depends on the workload, versions, display backend, extensions, codec, and definition of “fast.” Run the same controlled test and publish the context.

Should I use Speedometer alone?

No. It can be one JavaScript responsiveness measure, but add startup, memory, real navigation, video, stability, and required-feature tests.

Does lower RAM use always mean a better browser?

No. A browser may discard tabs, cache less, or trade CPU for memory. Compare task completion and reload behavior alongside PSS.

Can these results be reused after a browser update?

Treat a major browser, OS, kernel, or display-stack update as a new test version. Keep old results labeled rather than silently replacing their context.