Performance on surfaces the whole country sees

Some pages are seen by more people in a day than most products meet in their lifetime. On Mercado Libre’s retail surfaces, a regression of a few hundred milliseconds is not a technical footnote. It is measured in sales, in a currency, and someone will ask about it.

I drove the performance work across the highest-traffic surfaces of the first-party retail team between 2024 and 2025, as the most experienced engineer on the team and the one people came to with the hard questions. I can’t publish the numbers. I can publish the method, which is the part that transfers anyway.

Heroics decay, method compounds

Every large frontend has had a performance sprint. Someone gets a week, cuts the bundle in half, presents a slide with a green arrow, and six months later the page is exactly as slow as before. Nobody did anything wrong. Forty engineers each added a little.

Slowness is not the enemy. Regression is. A page that gets fast once and stays fast is a system problem, not a talent problem, and it needs three things that a sprint never gives you: a budget, a measurement people trust, and an owner for every part of the page.

Measure where the user is

The first mistake is measuring on your own machine. The median device looking at a retail page in Argentina is not a MacBook on fibre. It is a mid-range Android on a mobile network in a city that is not Buenos Aires, and the difference between the two is not a percentage. It is a different experience.

Lab metrics are for catching regressions before they ship. Field metrics are the truth. We prioritized by what real users saw, weighted by how many of them saw it. A hundred milliseconds on a page that gets a fraction of the traffic is a task. A hundred milliseconds on the page everyone lands on is an incident.

A millisecond has a price

Once you know what a millisecond is worth on a given surface, prioritization stops being a debate. You can rank every optimization by traffic multiplied by the improvement, and rank every proposed feature by traffic multiplied by the regression it will introduce.

That second list is the useful one. Performance work at scale is mostly saying no, politely and with a number, to things that would each cost very little on their own.

What actually moved things

Nothing on this list is novel. That is the point. The wins on high-traffic surfaces come from doing boring things consistently, not from clever ones occasionally.

Fewer bytes on the critical path. Everything that was not needed to render what the user came for was deferred. Every kilobyte on the first request was justified or removed.

Server-render what matters, hydrate what needs it. The content the user is looking for arrives as HTML. Interactivity arrives after, and only where there is interactivity.

Split by surface, not by module. A retail page should not download the code for a page the user is not on. Ownership boundaries, the same ones that made independent deploys possible, gave us natural split points.

Audit third-party scripts like dependencies. Every tag, every tracker, every widget was a cost with a name attached. Some earned their place. Several did not.

Reserve space. Layout shifts are performance problems that don’t show up in a waterfall. Images, ads and late content got their dimensions before they got their bytes.

Cache at the edge, aggressively, and invalidate honestly. The fastest render is the one that never reaches your servers.

Regressions are the real work

The optimizations above took weeks. Keeping them took the rest of the time, and this is where most teams stop.

Budgets lived in the pipeline. A change that pushed a surface past its budget failed the build, with the number in the failure message, before anyone had to have a conversation about it.

Field metrics had alerts, tagged by the team that owned the slice. This is where performance and platform architecture stopped being separate topics. When every part of the page has one owner, a regression is one team’s problem to fix, not five teams’ problem to argue about. The microfrontend work and the performance work were the same work from two sides.

And the standards travelled the way standards always travel: in code reviews, in the same few comments repeated until they were habits. Why is this on the critical path. Who owns this script. Where is the space for this image.

Boring on purpose

I am competitive. I want the fastest page, measurably, and I want it to be faster next quarter than it was this one. The lesson from surfaces that a whole country looks at is that you don’t get that from brilliance. You get it from a budget nobody can skip, a metric nobody can argue with, and an ownership map with no gaps, applied without drama for a very long time.

Nobody notices a fast page. That is what fast means.