OnlineDevelopers

5 Min. Lesezeit

Performance ist ein Feature, das Nutzer spüren

Geschwindigkeit steht selten auf der Roadmap, ist aber immer Teil des Erlebnisses. Wie wir Performance als Produktentscheidung behandeln – mit Budgets statt Heldentaten.

Dieser Artikel ist derzeit auf Englisch verfügbar.

Nobody writes "make it fast" on a roadmap, yet every user feels the difference. A screen that answers instantly feels trustworthy. A screen that hesitates feels fragile, even when it is doing exactly the right thing.

Performance is not a technical afterthought. It is part of how a product communicates.

Speed is perceived, not measured

Users do not see milliseconds. They see whether the page shows something useful quickly, whether it responds when they tap, and whether things jump around while they read. Modern performance metrics such as Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift exist precisely to approximate those feelings.

That is why we treat tools like Lighthouse as a mirror, not a goal. A high score is pleasant. A product that feels instant on a mid-range phone over a busy mobile connection is the point.

Budgets beat heroics

The common pattern is familiar: the product slows down quietly over a year, then a heroic sprint wins most of it back, then it slowly drifts again. The cure is not more heroics. It is a budget.

  • Set limits early, such as how much JavaScript the first page may load or how long the main content may take to appear on a typical device.
  • Check them automatically, in the same pipeline that runs your tests, so a regression is caught the day it is introduced.
  • Make trade-offs visible. When a new library would exceed the budget, the team decides consciously, instead of discovering it months later.

Small habits that add up

  • Render the first view on the server, so users see content before the app has finished loading.
  • Load what a page needs, when it needs it. Everything else can wait for idle time or the next interaction.
  • Give images their dimensions, so nothing jumps while the page settles.
  • Serve your own fonts and keep them lean. Third-party resources fail in ways you do not control.
  • Respect people's settings. Reduced motion and reduced data preferences are signals, not edge cases.

Performance as respect

A fast product respects people's time, their devices and their data plans. It works well for users on older phones and slower networks, who are often the majority. That makes performance one of the quietest, most inclusive features you can build.

If your product has grown slow and you are not sure where the time goes, ask us. Finding it is usually faster than people expect.

Haben Sie etwas, das es wert ist, gebaut zu werden?

Teilen Sie das Problem, nicht nur die Anforderungen. Wir prüfen es, stellen die entscheidenden Fragen und schlagen einen klaren Weg vor.

Projekt einreichen