Performance lessons from 2026

At the start of the year, we made an internal decision to make web performance a cross-cutting axis in all our projects, not an optional extra. Four months later, with several projects already in production, we want to share what we learned.

What we already knew

Established practices still work. Optimizing images, reducing JavaScript, avoiding render-path blocking, using local fonts instead of external services. Nothing new. The difference is that in 2026 browsers are stricter and users less patient than ever.

Core Web Vitals as a starting point

We start every audit with Core Web Vitals, not because they’re perfect, but because they give us a common language with non-technical clients. When an LCP drops from 4 seconds to 1.2, that’s an easy conversation to have.

What surprised us

Three discoveries changed how we work this year:

Fonts are still the bottleneck

We assumed fonts were already a solved problem with font-display: swap and preloads. Turns out they’re not. On Latin American mobile connections, poorly configured fonts still cause perceptible layout shifts even in 2026.

Edge isn’t always the answer

We deployed several projects on edge functions and discovered that for certain patterns — especially APIs with many dependencies — edge introduces additional latency on cold starts. The simple rule “edge is faster” is false.

Modern frameworks are increasingly lightweight

Astro, in particular, surprised us. Complex sites that weighed 280KB of JavaScript in Next.js dropped to less than 30KB in Astro without sacrificing interactivity.

What we’ll do differently

For the rest of the year, our approach will be even more radical: performance budgets per project, continuous monitoring in production, and, when possible, frameworks that ship less JavaScript by default. Speed is no longer a nice-to-have. It’s a product decision.