Post

Web performance is a marathon, not a sprint. Ship the fastest site today and in two weeks a third-party script, an unoptimised image or a CDN change will have quietly undone it. Optimising without monitoring doesn't last. 🧵 #WebPerf #RUM #CoreWebVitals

Joan León

@nucliweb.net

3 Aug

@speedcurve.com alert, fired on its own: FCP (RUM) budget breached, metric at 4.72s. Flat and green for hours, then climbing. Nobody was watching a dashboard. Synthetic gives reproducibility. RUM gives the truth: real users, real devices, real networks.

Joan León

@nucliweb.net

A fast site isn't a project you close on launch day. It's a state you have to maintain. The alert is the beginning, not the end. Now: root cause, and give users back the experience they expect.

3/8/26, 9:38 pm1 repost1 like

Joan León

@nucliweb.net

4 Aug

Update: this isn't frontend. TTFB is 27.44s of a 27.93s FCP. 98% of the time is spent waiting for the first byte, and the HTML is 15 KB.

Joan León

@nucliweb.net

4 Aug

The site is static, on Netlify. 27s to first byte means the request never resolved at the edge: cache miss to origin, cold start, or a failing PoP.

Joan León

@nucliweb.net

4 Aug

Isolated spikes off a stable ~2s baseline, different days, different countries. Not one user on a bad connection, and not bots, I checked. Which is the whole point of RUM: synthetic checks on a schedule would have missed every one.