--- term: 'Optimierung von API-Payloads' seoTitle: 'API-Payload-Optimierung: kleinere, schnellere Antworten' headline: 'Was ist die Optimierung von API-Payloads?' slug: payload-optimierung category: api-realtime shortDefinition: 'Die API-Payload-Optimierung ist eine Praxis, die verkleinert, was eine API sendet – weniger Felder, kleinere Seiten, Kompression – für schnelle Antworten.' relatedTerms: - overfetching-underfetching - graphql-vs-rest - n-plus-one-query-problem - api-rate-limiting-throttling - cdn-content-delivery-network contrastsWith: - overfetching-underfetching faq: - question: 'Was ist die Optimierung von API-Payloads?' answer: 'Die Praxis, das zu minimieren, was eine API-Antwort transportiert: nur die benötigten Felder auswählen, Listen paginieren, die Bytes auf der Leitung komprimieren und die Übertragung ganz überspringen, wenn der Client die Daten schon hat. Das Ziel ist für Nutzer sichtbar – schnellere Bildschirme, besonders in Mobilfunknetzen – und betrieblich: weniger Bandbreite, leichtere Server, kleinere Rechnungen.' - question: 'Wie verkleinere ich eine API-Antwort?' answer: 'Nach Wirkung sortiert: Felder auswählen – die meisten Antworten tragen weit mehr, als der Bildschirm rendert; paginieren – jede Liste begrenzen; komprimieren – Standardkodierungen schrumpfen JSON praktisch kostenlos um 70–90 %; und über den Cache revalidieren – ein 304 Not Modified überträgt fast nichts. Die ersten beiden verkleinern den eigentlichen Payload, die letzten beiden das, was über die Leitung geht.' - question: 'Wie stark verkleinert Kompression JSON?' answer: 'JSON ist sich wiederholender Text, und genau den lieben Kompressoren: Reduktionen von 70–90 % sind Routine, moderne Kodierungen liegen noch ein Stück über der klassischen. Zwei Einschränkungen: Kompression verkleinert die Übertragung, nicht das Parsen – eine Antwort von 2 MB bleibt nach dem Entpacken 2 MB Parse-Arbeit – und Payloads unter etwa einem Kilobyte lohnen die Kompression nicht.' - question: 'Was ist ein Sparse Fieldset?' answer: 'Nach bestimmten Feldern fragen statt nach ganzen Ressourcen – ein fields-Parameter in REST-Konventionen, select() in den Query-Buildern der SDKs oder in GraphQL die Query selbst. Das bekämpft Overfetching an der Quelle: Ein Listenbildschirm, der drei Felder braucht, hat nichts damit zu tun, vierzig pro Zeile zu bekommen.' - question: 'Was ist eine gute Payload-Größe für eine API?' answer: 'Praxisbudgets aus der mobilen Entwicklung: unter ~50 KB für Listenantworten, unter ~20 KB für eine einzelne Ressource, unter ~10 KB für alles auf dem kritischen Renderpfad – jeweils komprimiert auf der Leitung gemessen. Wichtiger als die genauen Zahlen ist, dass es Budgets überhaupt gibt: Was gegen ein Budget gemessen wird, bleibt klein.' - question: 'Wirkt sich die Payload-Größe wirklich auf die Latenz aus?' answer: 'Unmittelbar, und auf Mobilgeräten stärker, als die Intuition nahelegt: Die Übertragungszeit wächst mit den Bytes bei begrenzter Bandbreite, große Payloads erstrecken sich über mehrere Roundtrips, während die Verbindung hochfährt, und die Parse-Kosten landen auf schwachen Geräten. Die Payload-Größe speist Time-to-First-Byte und Largest Contentful Paint – eine Metrik der Nutzererfahrung in Backend-Verkleidung.' - question: 'Wie funktionieren ETags und 304-Antworten?' answer: 'Der Server versieht eine Antwort mit einem Versionsfingerabdruck; der Client schickt ihn bei der nächsten Anfrage zurück; unveränderte Inhalte bekommen ein 304 Not Modified mit leerem Body – die billigste Payload-Optimierung überhaupt: den Payload gar nicht zu senden. Sie passt naturgemäß zu Daten, die oft gelesen und selten geändert werden.' - question: 'Offset- oder Cursor-Paginierung für große Listen?' answer: 'Cursor, für alles Tiefe oder Lebendige: konstante Kosten in jeder Tiefe und Stabilität bei gleichzeitigen Schreibvorgängen, während Offsets linear langsamer werden und Zeilen überspringen oder doppeln können, sobald sich die Daten verschieben. Offsets bleiben legitim für flache, seitennummerierte Admin-Ansichten. So oder so sind unpaginierte Listen der Payload-Fehler, der mit Ihrem Erfolg wächst.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'HTTP Content-Encoding — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Encoding' - name: 'HTTP ETag and conditional requests — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag' - name: 'JSON:API specification — sparse fieldsets' url: 'https://jsonapi.org/format/#fetching-sparse-fieldsets' - name: 'SDK query documentation' url: 'https://docs.parseplatform.org/js/guide/#queries' cta: title: 'Schlanke Payloads von Haus aus' text: 'Die Back4app-SDKs machen die beiden größten Optimierungen zu Einzeilern: select() liefert nur die Felder, die der Bildschirm braucht, limit() begrenzt jede Seite – über komprimierte, cachefreundliche APIs, die die Plattform für Sie bereitstellt.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-27' translationKey: api-payload-optimization --- **Die API-Payload-Optimierung ist eine Praxis, die verkleinert, was eine API sendet – weniger Felder, kleinere Seiten, Kompression – für schnelle Antworten.** Sie ist der Anteil des Backends an der Performance des Frontends: Jedes überflüssige Kilobyte, das eine API verschickt, wird auf jedem Gerät, in jedem Netz, bei jedem Rendern erneut bezahlt – und die größten Gewinne liegen meist einen Parameter weit entfernt. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Die großen vier | Feldauswahl · Paginierung · Kompression · Cache-Validierung | | Reihenfolge der Wirkung | Auswählen und paginieren verkleinern die Daten; komprimieren und 304 verkleinern die Leitung | | Die Budgets | ~50 KB Listen · ~20 KB Einzelressource · ~10 KB kritischer Pfad (komprimiert) | | Das Messmittel | Content-Length in den DevTools oder mit curl – dann mit TTFB und LCP verknüpfen | | Die Falle | Kompression verdeckt Speck: Die Übertragung schrumpft, das Parsen nicht | ## Ein durchgerechnetes Beispiel: 85 KB → 4 KB ```text GET /articles → 85,5 KB (50 vollständige Zeilen, je 40 Felder) 1 · Felder auswählen, die der Bildschirm zeigt GET /articles?fields=title,summary,publishedAt → 15,5 KB (-82 %: Overfetching weg) 2 · Auf das Sichtbare paginieren …&limit=20 → 6,2 KB (begrenzte Seite) 3 · Auf der Leitung komprimieren Content-Encoding: br → ~1,4 KB übertragen (nochmals -77 %) 4 · Beim erneuten Besuch revalidieren If-None-Match: "v42" → 304 → ~0,1 KB (nichts geändert, nichts gesendet) ``` Die Schritte 1 und 2 als Anwendungscode – das SDK-Idiom, das Schlankheit zum Standard macht: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Ship the fields the screen needs — nothing else const query = new Parse.Query('Article'); query.equalTo('status', 'published'); query.select('title', 'summary', 'publishedAt'); // sparse fieldset query.limit(20); // bounded page const articles = await query.find(); // Full rows: ~14 KB each. This payload: ~0.4 KB each. Same screen. ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Ship the fields the screen needs — nothing else final query = QueryBuilder(ParseObject('Article')) ..whereEqualTo('status', 'published') ..keysToReturn(['title', 'summary', 'publishedAt']) // sparse fieldset ..setLimit(20); // bounded page final response = await query.query(); // Full rows vs selected fields: the mobile radio notices the difference. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Ship the fields the screen needs — nothing else let query = Article.query("status" == "published") .select("title", "summary", "publishedAt") // sparse fieldset .limit(20) // bounded page query.find { result in if case .success(let articles) = result { render(articles) } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Ship the fields the screen needs — nothing else val query = ParseQuery.getQuery("Article") query.whereEqualTo("status", "published") query.selectKeys(listOf("title", "summary", "publishedAt")) // sparse fieldset query.limit = 20 // bounded page query.findInBackground { articles, e -> if (e == null) render(articles) } ``` ## Wohin die Bytes und die Millisekunden gehen ```mermaid flowchart LR accTitle: Wo sich die Antwortzeit einer API ansammelt accDescr: Die Latenz einer Antwort summiert sich über die Ausführung der Abfrage, die Serialisierung der ausgewählten Felder, die Kompression, die Übertragung über das Netz im Verhältnis zur Payload-Größe sowie das Parsen und Rendern auf dem Client. Q["Abfrage
(weniger auswählen → weniger tun)"] --> S["Serialisieren
Felder × Zeilen"] S --> C["Komprimieren
70–90 % weniger auf der Leitung"] C --> T["Übertragen
Bytes ÷ Bandbreite – die Mobilfunksteuer"] T --> P["Parsen + rendern
hier kehrt die unkomprimierte Größe zurück"] ``` Das Diagramm trägt die beiden ehrlichen Fußnoten. **Kompression betrifft nur die Übertragung:** Der Client parst die *entpackten* Bytes, daher schlägt strukturelles Kürzen (Felder, Seiten) die Kompression allein – beides verstärkt sich, in genau dieser Reihenfolge. **An der Übertragung leidet das Mobilgerät:** Begrenzte Bandbreite und das Hochfahren der Verbindung lassen große Payloads mehrere Roundtrips überspannen – so wird aus Backend-JSON ein LCP-Problem im Frontend. ## Techniken zur Payload-Reduktion, nach Wirkung sortiert | Technik | Typische Einsparung | Aufwand | Das Kleingedruckte | | --- | --- | --- | --- | | Feldauswahl / [Sparse Fieldsets](https://jsonapi.org/format/#fetching-sparse-fieldsets) | 30–80 % | Ein Parameter | Bildschirme ändern sich – Auswahl ehrlich halten | | Paginierung (begrenzte Seiten) | Unbegrenzt → begrenzt | Ein Parameter | Cursor für die Tiefe, Offsets für flache Admin-Ansichten | | Kompression ([Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Encoding)) | 70–90 % der Übertragung | Serverkonfiguration | Unter ~1 KB überspringen; Parsen bleibt unberührt | | [ETags / 304](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag) | ~100 % bei unverändert | Mittel | Am besten bei oft gelesen, selten geändert | | Anfragen bündeln (Batching) | Roundtrips, keine Bytes | Mittel | Verwandt mit der [N+1-Lösung](/glossary/de/n-plus-1-problem/) | | Binärformate | 60–80 % vs. rohes JSON | Hoch | Kostet Werkzeuge und Debugbarkeit – für interne heiße Pfade | | Delta-Synchronisierung | Nur das Geänderte | Hoch | Die Endstufe für Offline-First-Apps | ## Messen: die fehlende Disziplin Der meiste Payload-Speck überlebt, weil niemand hinsieht. Die Prüfung ist ein einziges Flag: `curl -so /dev/null -w '%{size_download}'` pro Endpoint (oder die Größenspalte in den Entwicklerwerkzeugen des Browsers – mit Blick auf *transferred* gegenüber *resource*, deren Verhältnis Ihre Kompressionsrate ist). Stellen Sie die Zahlen den Budgets gegenüber – 50/20/10 KB komprimiert für Listen, Einzelressourcen und kritischen Pfad – und verdrahten Sie die Prüfung für die wichtigen Endpoints in der CI. Payloads regressieren wie Abfragen still und leise unter Feature-Druck; Budgets sorgen dafür, dass "nur noch ein Feld" auf eine Zahl trifft statt auf ein Schulterzucken. ## Typische Anwendungsfälle - **Mobile Listenbildschirme** – der kanonische Gewinn: Zeilen mit vierzig Feldern auf die drei gekürzt, die die Zelle rendert. - **Märkte mit langsamen Netzen** – Payload-Disziplin ist Barrierefreiheit; Budgets sind gelebter Respekt vor Nutzern im 3G-Netz. - **APIs mit hohem Traffic** – Bytes × Anfragen × Egress-Gebühren: Payload zu kürzen heißt buchstäblich die Rechnung zu kürzen. - **Dashboard-Aggregationen** – serverseitig berechnete Zusammenfassungen, statt Rohzeilen zu verschicken, die der Browser dann summiert. - **Offline-First-Synchronisierung** – Delta-Payloads und Validatoren, damit sich wieder verbindende Clients Änderungen holen und nicht ganze Welten. ## Welche Technik zuerst? Eine Entscheidungsmatrix | Symptom | Greifen Sie zu | | --- | --- | | Antworten tragen Felder, die kein Bildschirm zeigt | Feldauswahl – noch heute | | Listen wachsen mit Ihrer Nutzerzahl | Paginierung mit Cursors | | Die Übertragung ist groß, die Daten stimmen | Kompressionskonfiguration | | Clients holen unveränderte Daten erneut | ETags und 304 | | Viele kleine aufeinanderfolgende Aufrufe | Batching / Includes | | Interne Kommunikation zwischen Diensten überwiegt | Binärformate, vorher gemessen | Die Reihenfolgeregel: **Struktur vor Leitung** – reparieren Sie, was Sie senden, bevor Sie optimieren, wie es reist; Kompression auf Speck angewendet ist Speck mit Schleife. ## Grenzen und Trade-offs - **Auswahl koppelt Clients an Felder.** Sparse Fieldsets, die von der Oberfläche abdriften, erzeugen Fehler durch fehlende Daten; generierte Typen und Code-Reviews halten die Auswahl ehrlich. - **Caching bringt Korrektheitsarbeit mit.** Validatoren müssen sich tatsächlich ändern, wenn die Daten sich ändern; ein veraltetes 304 ist ein Fehler mit dem Abzeichen einer Optimierung. - **Binärformate gehen zulasten der Menschen.** Rechnen Sie die Einsparung auf der Leitung gegen jede Debugging-Sitzung auf, die den Verkehr nicht mehr lesen kann – meist nur auf internen Pfaden ein guter Tausch. - **Kompression kostet CPU** – bei mittleren Stufen kaum, bei Maximalstufen messbar; justieren Sie, statt aufzudrehen. - **Optimierung kann Modellierungsprobleme verdecken.** Wenn jeder Bildschirm tiefes Kürzen braucht, stimmen womöglich die Formen der API nicht – manchmal ist die Lösung [das Abfragemodell](/glossary/de/graphql-vs-rest/) und nicht die Diät. ## Payload-Optimierung mit Back4app Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die beiden wirkungsvollsten Techniken sind SDK-Einzeiler – [`select()` und `limit()`](https://docs.parseplatform.org/js/guide/#queries) in den Code-Tabs oben –, ergänzt um GraphQL-Feldauswahl, wenn Clients die Antworten selbst formen wollen. Die Leitungsseite kommt verwaltet: komprimierte Übertragung, cachefreundliche Datei-URLs abseits des API-Pfads und Cloud Code für serverseitige Aggregation, wenn der billigste Payload die Zusammenfassung ist, die Sie vor dem Senden berechnet haben. Schlank aus Gewohnheit, nicht aus Kampagne.