From 4.2s to 0.9s load time: what actually mattered

An internal application took over four seconds to become usable. After measuring, three changes were enough to bring that under one second. Here they are, ordered by real impact.

Measure before touching the code#

The first step was not an optimisation but a measurement. Without a precise profile you optimise at random and lose time on invisible details.

The metrics I watch:

• LCP (Largest Contentful Paint) — when the user sees the main content
• TBT (Total Blocking Time) — how long the page stays frozen
• JavaScript transferred — often the real culprit

In our case the diagnosis was blunt: 1.8 MB of JavaScript shipped on first load.

1. Split the bundle by route#

The application loaded all of its code, including the report editor that only 5% of users ever opened.

const ReportEditor = lazy(() => import("./ReportEditor"));

Result: -62% JavaScript on first load. This single change produced the largest gain, for roughly two hours of work.

2. Replace oversized libraries#

One date-manipulation library accounted for 71 KB compressed, for three formatting calls. The built-in Intl.DateTimeFormat was enough.

new Intl.DateTimeFormat("en-US", { dateStyle: "long" }).format(date);

A useful habit: before installing a package, check its real weight and ask whether the platform already does the job.

3. Serve images in the right format and size#

Images 2000 px wide were displayed in 320 px thumbnails. Switching to a modern format and appropriate sizes removed nearly 900 KB.

The results#

Change	LCP gain
Route-based splitting	-1.7 s
Lighter libraries	-0.5 s
Optimised images	-1.1 s

The main lesson: gains rarely come from micro-optimising code. They come from what you choose not to send to the browser.