Journal

We cut a 6-second load to 1.1 seconds

No rewrite, no new framework. Most of it was images nobody had looked at since launch.

Development — 2026.01.27

The site loaded in six seconds on a mid-range phone. The team assumed the framework was at fault and had already scoped a rewrite. We asked to spend two days measuring first, because a rewrite that starts from a guess produces a fast site with the same bug.

Measure the thing users feel

Largest contentful paint on that phone was 6.0 seconds. The largest contentful element was a hero image, served at 3200 pixels wide, as a PNG, uncompressed, to a screen 390 pixels across. It was 4.4 megabytes. Nobody had looked at it since the day it was uploaded.

Resizing and re-encoding that one image took the page to 2.4 seconds. That is not a clever optimisation. It is the kind of thing that survives for years because it is invisible in every environment except the one your customers use.

The rewrite would have shipped a fast site with the same 4.4 megabyte image in it.

The rest of the way

  • Serve images at the size they render, in a modern format.
  • Move the font to the local origin and preload the one weight above the fold.
  • Defer the analytics bundle. It was blocking first paint to count first paint.
  • Split the route bundle so the home page stops downloading the dashboard.

Together those took it to 1.1 seconds. The framework was never the problem, and the rewrite was cancelled. We are not against rewrites. We are against rewrites that begin before the measurement does.

Written by Raion