perf: gzip-compress JSON responses for startup-path API endpoints#550
Closed
sam-saffron-jarvis wants to merge 3 commits intoSamSaffron:mainfrom
Closed
perf: gzip-compress JSON responses for startup-path API endpoints#550sam-saffron-jarvis wants to merge 3 commits intoSamSaffron:mainfrom
sam-saffron-jarvis wants to merge 3 commits intoSamSaffron:mainfrom
Conversation
Add writeJSONGzip helper that transparently gzip-compresses JSON responses when the client sends Accept-Encoding: gzip and the payload exceeds 512 bytes. Apply to the three endpoints the web UI calls on every page load: - GET /v1/sessions (up to 100 sessions, ~10-20 KB uncompressed) - GET /v1/models (hundreds of IDs for OpenRouter, ~10-50 KB) - GET /v1/providers (provider list with embedded model arrays) Uses gzip.BestSpeed (level 1) rather than BestCompression — dynamic API responses aren't cached, so encode time matters more than ratio. JSON typically achieves 70-80% reduction even at speed level. Adds four unit tests: large-payload compression, no-Accept-Encoding passthrough, small-payload bypass, and handleSessions integration.
Same pattern as the startup-path endpoints: compress when the client sends Accept-Encoding: gzip and the body exceeds 512 bytes. The status poll already short-circuits with 304 when content is unchanged, so gzip only applies to the first response (no ETag yet) and polls after a change — both cases benefit from reduced wire size.
This was referenced May 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Add
writeJSONGzip, a helper that transparently gzip-compresses JSON API responses when the client sendsAccept-Encoding: gzipand the payload exceeds 512 bytes.Apply it to the three endpoints the web UI calls on every page load:
GET /v1/sessionsGET /v1/modelsGET /v1/providersWhy
All browsers send
Accept-Encoding: gzipby default. JSON is extremely compressible (typically 70–80% ratio). These three requests sit on the critical path of every page load — they blockhideStartupSplash. Compressing them reduces startup latency on any connection slower than localhost.Uses
gzip.BestSpeed(level 1) rather thanBestCompression— dynamic API responses are not cached, so encode time matters more than ratio.The 512-byte threshold avoids compressing tiny error responses where gzip header overhead would exceed the savings.
Tests
TestWriteJSONGzip_CompressesLargeResponse— large payload is gzip-compressed and round-trips correctlyTestWriteJSONGzip_NoCompressionWithoutAcceptEncoding— plain JSON returned when client doesn't advertise gzipTestWriteJSONGzip_SkipsCompressionForSmallPayload— payloads ≤512 B are sent uncompressedTestHandleSessions_GzipCompressed— integration test through the fullhandleSessionshandler