# Live map performance check

Measured September 8, 2026 against the private deployed Space and private HF bucket. The app was running on cpu-basic. This is a small regional demo test, not a bucket capacity or production load benchmark.

## Browser experience

Three initial map idle times were **1.046 s, 1.190 s, and 1.513 s**. These start when the app script begins, so they exclude the initial download of the Hugging Face page, app JavaScript, and some external assets. They include initial map tile loading and rendering. Each initial view fetched **308.7 KiB across five ranges**, approximately 4.8% of the 6,601,156-byte archive. UI currently labels binary units as KB/MB.

| Navigation                 | Time to map idle | Cumulative PMTiles reads | Requests |
| -------------------------- | ---------------: | -----------------------: | -------: |
| Initial overview           |      1.05–1.51 s |                308.7 KiB |        5 |
| Duomo, first detailed view |          3.386 s |                 1.46 MiB |       16 |
| Ponte Vecchio              |          1.866 s |                 1.64 MiB |       18 |
| Boboli Gardens             |          2.775 s |                 1.83 MiB |       24 |
| Duomo revisit              |          1.865 s |                 1.83 MiB |       24 |

Navigation timings include the configured 1.4-second fly animation. Returning to the Duomo added no bytes or requests, demonstrating reuse of in-memory map tiles. No frame-rate or frame-jank measurement was made. The map rendered and navigation worked throughout the measured interactions. The HF wrapper logged SSE abort messages during reloads; those are not evidence of failed bucket reads.

## HTTP and storage measurements

The benchmark sent 57 requests: one instrumentation probe, eight baseline app requests, 32 sequential range requests, and 16 ranges with four concurrent workers. All completed correctly. Each range response was checked against the exact local archive bytes.

| Request                      | Samples | Median complete response | Slowest complete response | Median S3 response-header wait |
| ---------------------------- | ------: | -----------------------: | ------------------------: | -----------------------------: |
| Cached metadata app endpoint |       8 |                    71 ms |                    136 ms |                  No S3 request |
| 127 bytes                    |       8 |                   234 ms |                    313 ms |                         152 ms |
| 16 KiB                       |       8 |                   242 ms |                    376 ms |                         157 ms |
| 128 KiB                      |       8 |                   239 ms |                    806 ms |                         133 ms |
| 1 MiB                        |       8 |                   330 ms |                    446 ms |                         157 ms |
| 128 KiB, concurrency 4       |      16 |                   241 ms |                    654 ms |                         134 ms |

Four-worker batch: 16 requests / 2 MiB in 1.25 seconds, about **1.60 MiB/s aggregate**. This latency-heavy small-range batch does not measure maximum bucket throughput.

The first instrumentation probe spent 68 ms obtaining object metadata and 170 ms waiting for S3 response headers; complete response time was 419 ms. Later metadata lookups reused the server's cached metadata.

`Server-Timing: s3_headers` measures Bun's elapsed time from starting its signed S3 fetch until final response headers arrive, including gateway processing, any redirects, and network hops from the Space. It does not isolate storage-media latency or include the full response body. Complete request durations include the user's laptop network, HF Space ingress, authentication, and body download. The approximately 71 ms baseline is useful context, not an exact quantity to subtract from every sample.

The HTTP client used HTTP/1.1 and reused connections. Browser requests may use different protocols and connection scheduling. No intentional Space sleep/startup test, global-region comparison, uncached-storage guarantee, or many-user load test was performed. Small sample counts make the raw p95 values approximate; the table reports the observed maximum instead.

## Assessment and next steps

The overview is usable for a demo. New detailed views have a noticeable settling delay. S3 response-header waits are typically 130–160 ms in these samples, so reducing serial range requests and reusing previously fetched bytes should help. The 806 ms outlier includes a 626 ms S3 header wait, showing occasional upstream variation.

Potential improvements to test separately:

1. Cache immutable archive ranges with an explicit byte budget and object-version key inside the server, shared across viewers. Keep viewer authorization before cache access.
2. Replace blanket no-store for static JS/CSS with versioned assets and appropriate caching. The browser bundle is about 1 MB before transport compression.
3. Test private browser caching for immutable map versions. In-memory map caching already helped the revisit; no-store matters more across reloads.
4. Measure a direct presigned S3 browser path separately before considering it. It could remove the Space data proxy, but needs CORS and expiry handling and gives recipients temporary read access to the archive.

No caching or transport architecture changes were made during this measurement. Added server timing headers and DOM timing attributes remain available for future checks.

## Reproduce

These Florence measurements were recorded before the global-map upgrade. The current `scripts/benchmark.py` targets the planet endpoint, compares ranges within the first 5 MiB against Protomaps, and writes proofs/planet-performance.json. Run it with Python containing httpx and HF_TOKEN set. Credentials are never included in saved results. Historical browser observations remain in proofs/browser-performance.json.

## Private HTTP caching — September 8, 2026

Deployed revision: `35fb518fa5e2d60f24b940aca66bbe37e6337198`.

| Live browser load           | Initial ranges | HTTP cache hits | Range transfer bytes | Initial map idle |
| --------------------------- | -------------: | --------------: | -------------------: | ---------------: |
| First load after deployment |              5 |               0 |              317,597 |         1,157 ms |
| Warm reload                 |              5 |               5 |                    0 |           318 ms |
| Second warm reload          |              5 |               5 |                    0 |           324 ms |

The signed-in in-app browser loaded the private Space wrapper. Same-origin Resource Timing reported zero transfer size with a positive decoded body size for all five ranges on both reloads, demonstrating browser cache reuse. Timings start at app script execution, excluding page and bundle downloads; these are three observations, not a general latency guarantee. Previously measured uncached live loads took 1.05–1.51 seconds by the same idle metric.

Authenticated HTTP checks also verified deployed HTML, JS, and CSS return 200 with `private, no-cache` followed by a bodyless 304 for a matching If-None-Match. (Since moving to Bun HTML imports, the page is `no-cache` with an ETag and the hashed JS/CSS chunks are immutable.) Map ranges return 206 with `private, max-age=300`, and matching conditional range requests return bodyless 304. The browser's existing PMTiles FetchSource uses this HTTP cache without custom persistent storage or a service worker.

All eight local HTTP/PMTiles tests passed, as did TypeScript checking and the browser build. Tests cover actual archive byte equality, decoding, invalid requests, private cache policy, matching validators, and nonmatching asset validators. Archive replacement during an active viewing session and eviction/expiry behavior were not exercised in the live browser.

## Planet import repair — September 8, 2026

The first three cloud imports did not produce a bucket object. They used two cpu-xl jobs and one cpu-performance job. The last run logged a segmentation fault; the precise cause is unresolved. High job memory metrics alone did not establish an OOM. All three jobs were confirmed canceled.

The replacement importer runs on the laptop with four streaming HTTP connections, 1 MiB read buffers, and a checkpoint of completed ranges. It verifies the published BLAKE3 checksum before uploading a single object. It does not require an HF Job or a write-capable S3 credential.

A real local probe downloaded the first 64 MiB from the source in 1.57 seconds (42.7 MB/s), with curl reporting 8 MiB maximum RSS. The HF bucket API uploaded those bytes in 6.09 seconds; downloading them back and comparing SHA-256 completed in 10.54 seconds total. That combined Python probe reported 464 MiB maximum RSS, including hashing buffers. This is a transfer smoke test, not a full-archive or map-serving benchmark.

The complete 137,838,277,849-byte download finished in 1,318 seconds (104.6 MB/s average), with 94 MiB maximum download-process RSS. The complete published BLAKE3 digest matched. The initial upload used concurrency 2; after a fresh 1 GiB upload probe completed in 20.91 seconds with 2.26 GiB maximum RSS, the upload was restarted with concurrency 8 and reused stored Xet chunks. That final upload took 386.26 seconds and peaked at 2,644.6 MiB RSS. This is a resumed/deduplicated upload duration, not a cold full-file upload throughput measurement.

The live HF bucket listing now confirms `maps/planet-20260907.pmtiles` at exactly 137,838,277,849 bytes. Logs are in `proofs/planet-import-local.log` and `proofs/planet-upload-local.log`. Live verification through the private Space passed: zoom-14 tiles decoded for San Francisco, Paris, Tokyo, Cape Town, and Sydney (747–1,049 ms per tile lookup in this run). Three 4 KiB ranges at the beginning, middle, and end matched the source archive exactly. Oversized ranges returned 413. Results are in `proofs/planet-verification.txt`; these are individual observations, not a latency guarantee.