> For the complete documentation index, see [llms.txt](https://docs.solanavibestation.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solanavibestation.com/developers/getting-started/response-compression.md). # Response Compression Solana Vibe Station supports **zstd** response compression on all JSON-RPC endpoints. By adding a single request header, you can shrink RPC responses by up to **80–90%** — cutting your bandwidth bill, speeding up large reads, and reducing time-to-first-byte on slow or metered connections. Compression is **opt-in** and **fully transparent**: you ask for it with a header, and any HTTP client that understands zstd decodes it automatically. Responses are byte-for-byte identical once decompressed — nothing about your application logic changes. {% hint style="info" %} **TL;DR** — Send `Accept-Encoding: zstd` with your requests. That's it. If your HTTP client supports zstd (most modern ones do), you get smaller responses and lower bandwidth usage for free. {% endhint %} *** ### Why use it RPC responses are JSON, and JSON compresses extremely well — it's highly repetitive (field names, base58/base64 strings, structural punctuation). zstd (Zstandard) is a modern compression algorithm from Meta that gives ratios comparable to or better than gzip while decompressing much faster, so the client-side cost is negligible. The payoff is largest on exactly the calls that hurt the most today: big account scans and full blocks. | Method | Uncompressed | With zstd | Savings | | --------------------------------- | ------------ | ------------------------ | ------------ | | `getClusterNodes` | \~1.67 MB | \~0.30 MB | **\~82%** | | `getBlock` (full transactions) | \~4.4 MB | \~0.65 MB | **\~85%** | | `getProgramAccounts` (large sets) | multi-MB | typically 80–90% smaller | **\~80–90%** | *Figures are representative; your exact ratio depends on the response contents.* **What this means for you** * **Lower bandwidth costs.** If you or your infrastructure pay for egress/ingress, compressed responses can cut transfer volume on read-heavy workloads by 4–10×. * **Faster large responses.** Less data on the wire means quicker downloads, especially over mobile, VPN, or long-haul links. * **No change to your data.** You receive the same JSON you always have — only the bytes in transit are compressed. *** ### How to use it Add the `Accept-Encoding` header to your request: ``` Accept-Encoding: zstd ``` When the proxy sees this header, it compresses eligible responses and returns: ``` Content-Encoding: zstd ``` Your HTTP client detects `Content-Encoding: zstd` and decompresses the body before handing it to your code. If your client does **not** send the header (or doesn't support zstd), you get an ordinary uncompressed response — so it's always safe to enable. #### curl Modern curl (7.72.0+, built with zstd) decodes it for you automatically: ```bash curl --zstd https://.rpc.solanavibestation.com/?api_key= \ -X POST \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"getClusterNodes"}' ``` > `--zstd` both sends `Accept-Encoding: zstd` and transparently decompresses the response. If your curl is older or wasn't built with zstd, request the raw compressed bytes and decode them with the `zstd` CLI: ```bash curl -s https://.rpc.solanavibestation.com/?api_key= \ -X POST \ -H "Content-Type: application/json" \ -H "Accept-Encoding: zstd" \ -d '{"jsonrpc":"2.0","id":1,"method":"getClusterNodes"}' | zstd -d ``` #### JavaScript / TypeScript Browsers negotiate encodings automatically — `fetch` in a modern browser will request and decode zstd for you with no code changes. In Node.js, zstd decoding in the built-in `fetch` requires **Node 22.15+ / 23+**. On those versions, decoding is automatic: ```js const res = await fetch( "https://.rpc.solanavibestation.com/?api_key=", { method: "POST", headers: { "Content-Type": "application/json", "Accept-Encoding": "zstd", }, body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "getClusterNodes" }), } ); const data = await res.json(); // already decompressed ``` > The official `@solana/web3.js` `Connection` uses your runtime's HTTP stack. If that stack supports zstd, you benefit automatically; if not, requests fall back to uncompressed responses transparently. #### Python `requests` doesn't decode zstd out of the box. Install the `zstandard` package and decode manually, or use a client that negotiates it for you (e.g. `httpx` with zstd support): ```python import requests, zstandard r = requests.post( "https://.rpc.solanavibestation.com/?api_key=", headers={"Content-Type": "application/json", "Accept-Encoding": "zstd"}, json={"jsonrpc": "2.0", "id": 1, "method": "getClusterNodes"}, ) if r.headers.get("Content-Encoding") == "zstd": body = zstandard.ZstdDecompressor().decompress(r.content) else: body = r.content import json data = json.loads(body) ``` #### Rust `reqwest` decodes zstd automatically when built with the `zstd` feature: ```toml reqwest = { version = "0.12", features = ["json", "zstd"] } ``` With the feature enabled, `reqwest` sends `Accept-Encoding: zstd` and decompresses responses for you — no manual handling required. *** ### What gets compressed Compression applies to **JSON-RPC response bodies** (`Content-Type: application/json`). A few rules keep it efficient: * **Only responses above \~256 bytes are compressed.** Tiny responses (e.g. `getHealth`, a single `getSlot`) are sent uncompressed, because compressing a few bytes adds overhead without saving anything. This is expected — don't be surprised to see no `Content-Encoding` header on small replies. * **Already-compressed responses are passed through, not re-compressed.** The `/historical` endpoint already serves zstd from its backend; if you request zstd there, you get that compressed stream directly, and if you don't, it's decompressed for you. Either way you get correct data. * **Compression is applied per-request.** Sending the header on one request and not another is fine; each response is handled independently. **Availability** zstd response compression is enabled on all standard **JSON-RPC endpoints** across tiers and regions, including the `/historical` path. It does **not** apply to gRPC/streaming endpoints, which use their own framing. *** ### Frequently asked questions **Do I have to change my requests or parse responses differently?** No. The only change is one request header. Decompression is handled by your HTTP client, and the JSON you get back is identical. **Is there a downside or extra cost?** No. Compression is free to use, decompression is very fast with minimal overhead, and if your client can't handle zstd you simply get an uncompressed response. There is no separate charge and it does not affect your rate limits. **Does it count against my rate limit differently?** No. Rate limiting is based on the requests and methods you call, not on response size or encoding. Compression changes only the bytes on the wire. **Why did I get an uncompressed response even though I sent the header?** Two common reasons: the response was below the \~256-byte minimum (small responses are intentionally not compressed), or your HTTP client stripped/renegotiated the `Accept-Encoding` header. Check for the `Content-Encoding: zstd` response header to confirm what you received. **Can I use gzip instead?** These endpoints are optimized for zstd, which outperforms gzip on JSON-RPC payloads in both ratio and speed. We recommend `Accept-Encoding: zstd`. **My client doesn't support zstd — what should I do?** You can keep making uncompressed requests as you do today (everything continues to work), decode manually using a zstd library (see the examples above), or upgrade to a client/runtime version with built-in zstd support. *** ### Recommendation If you make read-heavy calls — `getProgramAccounts`, `getBlock`, `getClusterNodes`, batched account lookups, historical queries — **enable zstd**. For most workloads it's a one-line change that cuts response bandwidth several-fold with no downside. Send `Accept-Encoding: zstd`, confirm you see `Content-Encoding: zstd` on large responses, and enjoy the savings.