Large JSON payloads slow your app down (and how to fix it)
JSON is convenient. But past a certain size, the performance impact is real: long response times, excessive memory usage, slow APIs.
I've hit these problems quite a lot on .NET projects. The main cause? Oversized JSON payloads and unoptimized requests.
Why it slows things down
Saturated memory: JSON is verbose, every field counts. Loading everything in memory risks an OutOfMemoryException.
Costly deserialization: Newtonsoft.Json is mature but slower on large volumes, and deserialization eats CPU and memory.
Slowed-down APIs: superfluous data wastes bandwidth and increases processing time.
When is it "too big"?
- ✅ Under 100 KB: optimal performance;
- ⚠️ 100 to 500 KB: watch zone;
- 🚨 500 KB to 10 MB: optimization required;
- ❌ Over 10 MB: change of format needed.
How to improve performance
System.Text.Json (preferred): 20 to 40% faster than Newtonsoft on large volumes on average, roughly 40% less memory allocation, built-in since .NET 6.
Payload optimization: targeted DTOs instead of full entities, list pagination, server-side filtering, limit over-fetching.
True JSON streaming (recommended from 500 KB according to Microsoft): Utf8JsonReader for genuinely progressive parsing. Careful: DeserializeAsync still loads everything into memory. Streaming reduces GC pressure.
API compression (recommended from 1 KB responses): Gzip or Brotli cut JSON by 40 to 70%, simple to configure, immediate bandwidth ROI.
Binary formats (when performance is critical): MessagePack (3 to 5x faster on average), Protobuf (ideal for microservices), gRPC (optimal for service-to-service communication).
Takeaway: adopt System.Text.Json, optimize your payloads, stream when needed, compress your APIs, and consider binary formats for critical paths.
This article comes from one of my LinkedIn posts (in French): join the discussion ↗