Maps are a classic case where naïve "render everything" doesn't work. You can't put a billion DOM elements on a page; you can't fetch a billion tiles. The solution is a layered system: tile pyramid → viewport-aware loading → off-main-thread decode → Canvas/WebGL render → smooth pan/zoom.

Tile pyramid

The world is divided into a quadtree:

• Zoom 0: 1 tile covers the whole world (256×256).
• Zoom 1: 2×2 = 4 tiles.
• Zoom 2: 4×4 = 16 tiles.
• Zoom N: 2^N × 2^N tiles.

Each tile has a deterministic URL: /tiles/z/x/y.png (or .webp / .pbf for vector).

At any moment, only the visible tiles at the current zoom need to be loaded.

Viewport-aware loading

function visibleTiles(center, zoom, viewport) {
  const tileSize = 256;
  const minTileX = Math.floor((center.x - viewport.width / 2) / tileSize);
  const maxTileX = Math.ceil((center.x + viewport.width / 2) / tileSize);
  // … similar for y
  const tiles = [];
  for (let x = minTileX - 1; x <= maxTileX + 1; x++) {
    for (let y = minTileY - 1; y <= maxTileY + 1; y++) {
      tiles.push({ z: zoom, x, y });
    }
  }
  return tiles;  // ~20-30 tiles at typical viewport
}

The +1 / -1 padding (overscan) preloads adjacent tiles for smooth pan.

Caching

• Browser HTTP cache: tile URLs are versioned; Cache-Control: public, max-age=31536000, immutable.
• CDN edge: tiles are perfect CDN content — static, high hit rate, globally requested.
• In-memory tile cache (JS map): keep recently-rendered tile imagery as decoded textures. Evict LRU when cache exceeds N tiles.
• Service worker: optional, for offline maps.

Fetching at scale

• HTTP/2 multiplexing: 20 tiles in parallel over one connection, no 6-per-origin limit.
• AbortController: cancel in-flight requests for tiles no longer visible (rapid pan).
• Priority queue: tiles at the center of the viewport get higher priority than edge tiles.

Decode

Decoding a PNG/WebP for each tile is CPU work. Off the main thread:

// Worker
self.onmessage = async (e) => {
  const blob = await fetch(e.data.url).then(r => r.blob());
  const bitmap = await createImageBitmap(blob);  // off-main-thread decode
  self.postMessage({ tileKey: e.data.tileKey, bitmap }, [bitmap]);
};

OffscreenCanvas + worker pipeline keeps the main thread free for pan/zoom interaction.

Render: Canvas/WebGL

DOM with thousands of <img> elements is a non-starter. Choices:

Canvas 2D: simpler, fine for raster tiles. Compose tiles + overlays per frame.

WebGL (or WebGPU): higher throughput, GPU shader pipeline, can render vector tiles (Mapbox GL, MapLibre style). Smooth zoom, rotation, 3D terrain.

Pan/zoom

The handler must be cheap:

let panX = 0, panY = 0, raf = 0;
canvas.addEventListener('pointermove', e => {
  if (dragging) {
    panX = e.clientX - startX;
    panY = e.clientY - startY;
    if (!raf) raf = requestAnimationFrame(applyPan);
  }
});
function applyPan() {
  raf = 0;
  canvas.style.transform = `translate3d(${panX}px, ${panY}px, 0)`;  // compositor-only
}

During the pan, use CSS transform on the entire canvas → compositor-only, no per-frame redraw. On pointerup, commit the new center, recalculate visible tiles, redraw at native position. This decouples pan smoothness from tile rendering cost.

For zoom, the same: scale-transform the canvas during pinch/wheel, then on settle, re-render at the new zoom level using the next zoom's tiles.

Predictive prefetch

When the user is panning in a direction, prefetch tiles in that direction:

const direction = { x: panVelocity.x > 0 ? 1 : -1, y: panVelocity.y > 0 ? 1 : -1 };
const predictedTiles = visibleTiles(center + 2 * direction, zoom, viewport);
predictedTiles.forEach(prefetchTile);

For zoom, prefetch the next zoom level's tiles when the user starts pinching in.

Vector tiles + WebGL

Modern maps (Mapbox, MapLibre, Google Maps Vector) ship vector tiles (.pbf) that the client renders via WebGL:

• Smaller bytes (text-encoded geometry vs pixel data).
• Smooth zoom (geometry scales without resampling).
• Dynamic styling (light/dark mode without re-fetching).
• Rotation, 3D buildings, terrain.

Cost: more client CPU/GPU work. Worth it for desktop and modern mobile.

UI responsiveness

• All decode work on workers.
• Render on Canvas/WebGL, not DOM.
• Pan/zoom via CSS transform during gesture, full redraw on settle.
• RAF-coalesce all updates.
• Throttle tile-fetch requests (don't spam on every micro-move).

Memory management

• Bounded tile cache (e.g., 256 tiles ≈ 64MB at 256×256 RGBA).
• LRU eviction.
• Release decoded ImageBitmaps when evicted.
• For mobile, lower the budget.

Pitfalls

• DOM-based map → unscalable.
• Per-event DOM mutation → janky pan.
• Synchronous decode → main thread blocked → INP regression.
• Unbounded cache → OOM after long browsing.
• No abort on rapid pan → wasted bandwidth.
• No prefetch on continued pan → tiles pop in late.

Mental model

Maps are a streaming system: tiles are content fetched and decoded on demand, rendered via GPU, with predictive prefetch hiding latency. Every layer (network, decode, render, interaction) must be tuned independently because each can be the bottleneck.