Measured, and repeatable.

The short version

First map image, desktop

45ms

From the start of the page load, with nothing cached.

Script run before that image

4.6ms

The loader is 7.5 KB gzipped.

Main thread per frame while dragging

1.70ms

Out of the 16.7 ms a frame has at 60 frames a second.

Same drag, low-end phone profile

7.46ms

CPU slowed six times.

In the browser

One visit is: load the page with nothing cached, move the pointer onto the map, drag it, zoom in three levels, then replace the markers with 2,000 and with 10,000. Each figure is the median of 5 visits in Chromium 158.

The device profiles

• Desktop. Desktop, 1280×800, CPU as it is, no network limit.
• Laptop hidpi. High-density laptop, 1440×900 at 2×, CPU as it is, no network limit.
• Phone mid. Mid-range phone, 390×844 at 3×, CPU 4× slower, 9 Mbps down with 60 ms latency.
• Phone low. Low-end phone, 360×780 at 2×, CPU 6× slower, 1.6 Mbps down with 150 ms latency.

The phone profiles slow the CPU and the network of the test machine. They imitate slower devices; they are not measurements on real phones.

Other browser engines

The same visit in the other engines, on the desktop and laptop profiles. CPU and network limits, script time and memory are only available in Chromium, so those rows are left out here.

Drawing a picture on the server

Time for one HTTP request to the image service, running locally with map data on the same machine. “First” is a picture that has to be drawn. “Again” is the same address a second time, answered from cache.

A deployed service adds the time to fetch map data, which depends on where that data is kept. Run the suite against your own deployment with bun run bench --url https://your-domain.

The renderer by itself

The Rust renderer, compiled natively, turning vector tiles into a JPEG. Median of 30 runs, in milliseconds.

How this was measured

• The machine

  Apple M5 Pro, 18 cores, 48 GB of memory, macOS, arm64. Source at commit 4331ed4.

• No network in the way

  The image service and the map data run on the test machine, so results do not depend on a connection or on what happens to be cached elsewhere. The phone profiles add a network limit on purpose.

• The slower path to the first image

  The test page lets the script create the first image. A page that puts the image in its HTML, as the guides recommend, shows it sooner, because nothing waits for a script.

• Medians, fresh every time

  Each visit starts in a new browser profile with an empty cache, against an image service that has already drawn the pictures, as a service in use has. The tables show the median; the result file also holds the fastest run and the 90th percentile.

Timings change from machine to machine and from run to run. Compare numbers measured on the same machine, and treat differences of a few percent as noise.