Warum sich deine KI-gebaute App langsam anfühlt (und was du dagegen tun kannst)

Ein Guide in einfacher Sprache zu den vier Gründen, warum sich KI-gebaute Apps träge anfühlen — Bilder, Listen, Warte-Screens und die Datenbank — und der jeweilige Fix, um den du deinen KI-Builder bitten kannst.

Deine KI-gebaute App funktioniert. Die Buttons sind dort, wo sie sein sollen, die Screens passen zusammen, die Daten werden gespeichert. Aber irgendetwas fühlt sich falsch an. Seiten brauchen einen Tick zu lang zum Laden. Eine Liste mit fünfzig Einträgen hängt eine Sekunde. Auf “speichern” zu klicken lässt dich warten, dann noch ein bisschen warten, dann überlegen, ob du nochmal klicken solltest. Nichts ist kaputt — es fühlt sich nur langsam an.

Wenn du ein:e nicht-technische:r Gründer:in bist und mit einem KI-App-Builder auslieferst, ist das einer der häufigsten “Ich weiß nicht, was nicht stimmt”-Momente. Die gute Nachricht ist, dass 80 % der langsamen KI-gebauten Apps aus derselben Handvoll Gründe langsam sind. Keiner davon verlangt, dass du lernst, wie Datenbanken funktionieren. Für alle gibt es Fixes, um die du deinen KI-Builder in einfachem Deutsch bitten kannst.

Dieser Beitrag ist der Spickzettel.

Warum “langsam” meist vier Dinge sind

Wenn Nutzer:innen sagen, eine App fühle sich langsam an, meinen sie fast nie “der Server ist zu schwach”. Sie meinen eines von vier Dingen:

  1. Der erste Bildaufbau ist langsam — sie klicken auf einen Link und starren zwei Sekunden auf einen leeren Bildschirm, bevor irgendetwas erscheint.
  2. Eine lange Liste ist träge — Scrollen, Filtern oder “alle meine Projekte” laden dauert länger als das Scrollen durch Instagram.
  3. Eine Aktion dauert zu lange, ohne ihnen zu sagen, was passiert — sie klicken auf “speichern” oder “senden” und sichtbar reagiert nichts.
  4. Der Datenbank werden zu viele Fragen gestellt — Seiten, die Daten aus mehreren Quellen zeigen, holen jedes Stück einzeln und stapeln die Wartezeiten.

Das war’s. Fast jede langsame KI-gebaute App, die ich mir angeschaut habe, ist aus einem dieser vier Gründe langsam. Hier erfährst du, wie du jeden erkennst und worum du deinen Builder bitten solltest.

Grund #1 für Langsamkeit: der erste Bildaufbau

Wie es aussieht: Du klickst auf einen Link zu deiner App, die Adressleiste lädt fertig, aber die Seite ist eine oder zwei Sekunden weiß, bevor irgendetwas erscheint.

Was es meist verursacht: Die App lädt jedes Stück JavaScript, das sie eventuell braucht, bevor sie dir irgendetwas zeigt. KI-App-Builder neigen dazu, großzügig zu bündeln — lieber etwas mitnehmen als auslassen — und dieses Bündel wird größer, je mehr Features du hinzufügst.

Worum du deinen KI-Builder bitten solltest: “Der erste Seitenaufbau fühlt sich langsam an. Kannst du die JavaScript-Bundles nach Route aufteilen, damit die Startseite nicht den ganzen Admin-Bereich herunterladen muss?” Oder, einfacher: “Füge Lazy Loading für Routen hinzu, die nicht die Startseite sind.” Die meisten modernen Frameworks unterstützen das in ein, zwei Zeilen Konfiguration. Die KI weiß wie — du musst nur fragen.

Wenn du schon dabei bist: “Gibt es große Bilder auf der Landingpage, die wir optimieren könnten?” Ein 4-MB-Hero-Foto drückt die gefühlte Geschwindigkeit stärker als jedes Code-Problem.

Grund #2 für Langsamkeit: die lange Liste

Wie es aussieht: Du hast eine Liste — Projekte, Kontakte, Beiträge, irgendwas — und sobald sie über vierzig oder fünfzig Einträge hat, stottert das Scrollen oder das Filtern braucht einen spürbaren Tick.

Was es meist verursacht: Die App rendert jeden einzelnen Eintrag auf einmal auf die Seite, sogar die, die du nicht sehen kannst. Bei zehn Einträgen ist das in Ordnung. Bei fünfhundert verschluckt sich der Browser.

Worum du deinen KI-Builder bitten solltest: “Die Projektliste ist langsam, wenn es viele Einträge gibt. Können wir Paginierung hinzufügen oder die Liste virtualisieren, sodass nur die sichtbaren Zeilen gerendert werden?” Paginierung (“zeige 20 pro Seite, mit Weiter-/Zurück-Buttons”) ist der einfachste Fix. Virtualisierung (“rendere nur, was auf dem Bildschirm ist, während der Nutzer scrollt”) fühlt sich flüssiger an, ist aber etwas mehr Arbeit. Beides ist in Ordnung.

Wenn die Liste auch eine Suche oder Filter hat: “Kann das Such-Filtern auf dem Server statt im Browser passieren?” Serverseitiges Filtern bedeutet, dass der Browser immer nur die passenden Zeilen vorhält, nicht den ganzen Datensatz.

Grund #3 für Langsamkeit: das stille Warten

Wie es aussieht: Du klickst auf “speichern” oder “senden” oder “generieren”. Sichtbar passiert nichts. Zwei Sekunden später aktualisiert sich der Bildschirm und du merkst, dass es die ganze Zeit gearbeitet hat.

Was es meist verursacht: Die App leistet echte Arbeit — speichert in eine Datenbank, ruft eine API auf — aber der KI-Builder hat keinen Ladezustand hinzugefügt. Aus deiner Sicht hat der Klick also nichts getan.

Das ist eigentlich kein Performance-Problem. Es ist ein gefühltes Performance-Problem, und die sind oft schmerzhafter als echte. Eine 200-Millisekunden-Aktion ohne Rückmeldung fühlt sich langsamer an als eine 2-Sekunden-Aktion mit einem Spinner, weil das Gehirn des Nutzers im Dunkeln tappt.

Worum du deinen KI-Builder bitten solltest: “Füge jedem Button, der eine Aktion auslöst, einen Ladezustand hinzu. Zeig einen Spinner oder den Text ‘Speichern…’, während es arbeitet, und deaktiviere den Button, damit Nutzer:innen nicht doppelt klicken können.” Das ist der Performance-Fix mit dem höchsten ROI in jeder App und er kostet fast nichts.

Wenn du schon dabei bist: “Können wir bei Aktionen, deren Ergebnis wir kennen, die Oberfläche optimistisch aktualisieren — die Änderung sofort anzeigen und zurückrollen, falls der Server sie ablehnt?” Optimistische Updates sind der Grund, warum sich der “Gefällt mir”-Button in Social-Apps sofort anfühlt, selbst wenn dein Handy miserablen Empfang hat.

Grund #4 für Langsamkeit: die geschwätzige Datenbank

Wie es aussieht: Eine Seite, die eine Liste von Einträgen zeigt, jeder mit Zusatzinfos — etwa eine Liste von Projekten mit der Anzahl der Aufgaben in jedem — braucht viel länger zum Laden, als eine schlichte Liste es würde.

Was es meist verursacht: Die Seite lädt die Projekte in einer Abfrage und lädt dann die Aufgabenzahl für jedes Projekt in einer separaten Abfrage. Zehn Projekte? Elf Abfragen. Hundert Projekte? Hundertundeine. Das nennt man eine “N+1-Abfrage”, und es ist der häufigste Datenbank-Performance-Bug in KI-gebauten Apps, weil die KI für Code optimiert, der sich klar liest, nicht für Code, der effizient läuft.

Worum du deinen KI-Builder bitten solltest: “Diese Seite macht eine Abfrage pro Eintrag. Können wir alle zugehörigen Daten in einer einzigen Abfrage holen — einem Join oder einer Aggregation?” Du musst nicht wissen, was eines der beiden Wörter bedeutet. Die KI weiß es. Ihr die langsame Seite zu zeigen und zu sagen “Ich glaube, das hat ein N+1-Problem” reicht meist aus.

Du kannst N+1-Probleme ohne Werkzeuge erkennen: Öffne die Seite, zähl, wie lange sie braucht, und füge dann zehnmal so viele Einträge zur zugrunde liegenden Liste hinzu. Wenn die Seite jetzt zehnmal langsamer ist, hast du ein N+1. Wenn sie nur ein winziges bisschen langsamer ist, hast du keines.

Ein Wort zur verfrühten Optimierung

Eine Falle, in die neue Builder tappen: zu versuchen, jede Seite schnell zu machen, bevor überhaupt jemand die App nutzt. Lass es.

Performance-Arbeit hat echte Kosten. Paginierung zu einer Liste hinzuzufügen, die nie mehr als zwanzig Zeilen haben wird, ist verschwendete Mühe. Eine Seite zu optimieren, die zweimal am Tag lädt, ist verschwendete Mühe. Bundles für ein internes Tool mit drei Nutzer:innen aufzuteilen, ist verschwendete Mühe. Der richtige Zeitpunkt, eine langsame Seite zu reparieren, ist, wenn du die Seite, die Aktion und eine Person benennen kannst, die sich darüber geärgert hat.

Also bau es zuerst normal. Liefere es aus. Beobachte, wie es genutzt wird. Wenn sich etwas für eine echte Person langsam anfühlt — auch für dich —, ordne das Symptom einer der vier Kategorien oben zu und bitte um genau diesen Fix. Du bekommst eine schnellere App, ohne eine Woche an Infrastruktur zu verschwenden, die deine Nutzer:innen nie bemerken werden.

So sprichst du mit deinem KI-Builder über Geschwindigkeit

Ein Muster, das funktioniert: Beschreibe das Symptom, nicht die Lösung. Die KI ist viel besser darin, den richtigen Fix zu wählen, als du erwarten würdest, solange sie weiß, was tatsächlich falsch ist.

Gute Prompts zum Kopieren:

  • “Wenn ich die Einstellungsseite öffne, gibt es eine Sekunde Verzögerung, bevor irgendetwas erscheint. Können wir herausfinden, was den ersten Aufbau blockiert?”
  • “Das Dashboard braucht länger zum Laden als die Startseite, obwohl es weniger Daten zeigt. Können wir uns anschauen, wie es seine Daten holt?”
  • “Wenn ich auf der Profilseite auf ‘Änderungen speichern’ klicke, passiert zwei Sekunden lang nichts. Füge einen Ladezustand hinzu und stell sicher, dass der Button nicht doppelt geklickt werden kann.”
  • “Teste diese Liste mit 500 falschen Einträgen und sag mir, wo die Verlangsamungen sind.”

Der letzte ist unterschätzt. Die KI zu bitten, Testdaten zu generieren und die Seite selbst auszuprobieren, ist eines der nützlichsten Dinge, die du tun kannst. Sie findet die langsamen Stellen oft, bevor deine Nutzer:innen es tun — und schlägt den Fix in derselben Antwort vor.

Geschwindigkeit in KI-gebauten Apps ist keine Zauberei. Es geht darum zu wissen, in welchen der vier Töpfe dein Problem fällt, und in klaren Worten um den richtigen Fix zu bitten. Tu das, und aus “fühlt sich langsam an” wird “fühlt sich gut an” — mit einer Handvoll kleiner, gezielter Änderungen, nicht mit einem Neuaufbau.