23 ਸਤੰ 2025·8 ਮਿੰਟ
ZSTD vs Brotli vs GZIP: API ਕੰਪਰੈਸ਼ਨ ਚੁਣਨਾ
ZSTD, Brotli ਅਤੇ GZIP ਦੀ ਤੁਲਨਾ ਕਰੋ: APIs ਲਈ ਸਪੀਡ, ਰੇਸ਼ੋ, CPU ਲਾਗਤ, ਅਤੇ JSON ਅਤੇ ਬਾਈਨਰੀ ਪੇਲੋਡਾਂ ਲਈ ਪ੍ਰੈਡੈਕਟਿਕਲ ਡਿਫਾਲਟ ਸਫ਼ਰ-ਜੇ-ਸੰਪਰੋਡਕਸ਼ਨ ਵਿੱਚ।
ZSTD, Brotli ਅਤੇ GZIP ਦੀ ਤੁਲਨਾ ਕਰੋ: APIs ਲਈ ਸਪੀਡ, ਰੇਸ਼ੋ, CPU ਲਾਗਤ, ਅਤੇ JSON ਅਤੇ ਬਾਈਨਰੀ ਪੇਲੋਡਾਂ ਲਈ ਪ੍ਰੈਡੈਕਟਿਕਲ ਡਿਫਾਲਟ ਸਫ਼ਰ-ਜੇ-ਸੰਪਰੋਡਕਸ਼ਨ ਵਿੱਚ।
Accept-Encoding (ਕਲਾਇਂਟ ਕੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ) ਅਤੇ Content-Encoding (ਸਰਵਰ ਨੇ ਕੀ ਚੁਣਿਆ)।\n\n### APIs ਵਾਸਤੇ ਇਹ ਕੀ ਕਰਦਾ ਹੈ\n\nਕੰਪਰੈਸ਼ਨ ਮੁੱਖ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦਿੰਦਾ ਹੈ:\n\n- ਘੱਟ ਬੈਂਡਵਿਡਥ: ਛੋਟੀਆਂ ਰਿਸਪੌਂਸ ਰਾਹੀਂ ਘੱਟ ਬਾਈਟ ਖਪਤ ਹੁੰਦੀ ਹੈ।\n- ਸੀਮਿਤ ਲਿੰਕਾਂ 'ਤੇ ਘੱਟ ਲੈਟੇਨਸੀ: ਘੱਟ ਬਾਈਟ ਅਕਸਰ ਮੋਬਾਇਲ, ਭਰੀ Wi‑Fi ਜਾਂ ਰੀਜਨ ਟ੍ਰੈਫਿਕ 'ਤੇ ਤੇਜ਼ ਡਾਊਨਲੋਡ ਦਿੰਦੇ ਹਨ।\n- ਘੱਟ ਆਉਟਗੋਇੰਗ ਖ਼ਰਚਾ: ਜੇ ਤੁਸੀਂ ਆਉਟਬਾਉਂਡ ਡੇਟਾ ਲਈ ਪੈਸਾ ਦਿੰਦੇ ਹੋ, ਤਦ ਟ੍ਰਾਂਸਫਰ ਸਾਈਜ਼ ਘਟਾਉਣਾ ਸਿੱਧਾ ਬਿੱਲ ਘਟਾ ਸਕਦਾ ਹੈ।\n\nਇਸ ਦੇ ਬਦਲੇ ਵਿੱਚ ਸਪੱਠ ਤੌਰ 'ਤੇ ਖ਼ਰਚਾ ਹੈ: ਕੰਪਰੈਸ਼ਨ ਬੈਂਡਵਿਡਥ ਬਚਾਉਂਦੀ ਹੈ ਪਰ CPU (ਕੰਪਰੈਸ/ਡੀਕੰਪਰੈਸ) ਅਤੇ ਕਈ ਵਾਰ ਮੈਮੋਰੀ (ਬਫਰ) ਲਾਉਂਦਾ ਹੈ। ਕੀ ਇਹ ਲਾਭਦਾਇਕ ਹੈ ਇਹ ਤੁਹਾਡੀ ਬੋਟਲਨੇਕ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।\n\n### ਕਦੋਂ ਕੰਪਰੈਸ਼ਨ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ\n\nਕੰਪਰੈਸ਼ਨ ਅਕਸਰ ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਚਮਕਦੀ ਹੈ ਜਦੋਂ ਰਿਸਪੌਂਸ:\n\n- ਟੈਕਸਟ-ਭਾਰੀ ਅਤੇ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹੋਣ, ਜਿਵੇਂ JSON, GraphQL ਰਿਸਪੌਂਸ, HTML, ਜਾਂ ਲੌਗ।\n- ਦਰਮਿਆਨੇ ਤੋਂ ਵੱਡੇ, ਜਿੱਥੇ几十 ਜਾਂ ਸੌਆਂ KB ਘਟਾਉਣਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।\n- ਧੀਮੀਆਂ ਜਾਂ ਮਹਿੰਗੀਆਂ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਸਰਵ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਜਿਵੇਂ ਮੋਬਾਇਲ, ਅੰਤਰਰਾਸ਼ਟਰੀ ਕਲਾਇਂਟ, ਜਾਂ ਕ੍ਰਾਸ-ਰੀਜਨ ਕਾਲ।\n\nਜੇ ਤੁਸੀਂ ਵੱਡੇ JSON ਲਿਸਟਾਂ (ਕੈਟਾਲੋਗ, ਖੋਜ ਨਤੀਜੇ, ਐਨਾਲਿਟਿਕਸ) ਵਾਪਸ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਕੰਪਰੈਸ਼ਨ ਅਕਸਰ ਸੋਖਾ ਅਤੇ ਤੇਜ਼ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ।\n\n### ਕਦੋਂ ਇਹ ਘੱਟ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ\n\nਕੰਪਰੈਸ਼ਨ ਅਕਸਰ CPU ਲਈ ਬੇਕਾਰ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਰਿਸਪੌਂਸ:\n\n- ਛੋਟੇ (ਉਦਾਹਰਨ ਲਈ ਸੈਕੜੇ ਬਾਈਟ) ਹੁੰਦੇ ਹਨ। ਹੈਡਰ + CPU ਓਵਰਹੈੱਡ ਬਚਤ ਨੂੰ ਓਵਰਵੇਟ ਕਰ ਸਕਦਾ ਹੈ।\n- ਪਹਿਲਾਂ ਹੀ ਕੰਪਰੈੱਸਡ ਹਨ (JPEG/PNG, MP4, ZIP, ਬਹੁਤ PDF)। ਦੁਬਾਰਾ ਕੰਪਰੈਸ਼ਨ ਅਕਸਰ ਘੱਟ ਬਚਤ ਦਿੰਦਾ ਹੈ ਜਾਂ ਆਕਾਰ ਵਧਾ ਵੀ ਸਕਦਾ ਹੈ।\n- CPU-ਬਾਊਂਡ ਸਰਵਿਸਜ਼ (ਹੌਟ ਐਂਡਪੋਇੰਟ ਜੋ ਪਹਿਲਾਂ ਹੀ ਗਣਨਾ ਨਾਲ ਝੁਝ ਰਹੇ ਹੋਣ)। ਕੰਪਰੈਸ਼ਨ ਲਗਾਉਣ ਨਾਲ ਟੇਲ ਲੈਟੇਨਸੀ ਵਧ ਸਕਦੀ ਹੈ।\n\n### ਇੰਨੇ ਗਾਈਡਲਾਈਨ ਤੁਹਾਡੇ ਫੈਸਲੇ ਲਈ\n\nਜਦੋਂ ਤੁਸੀਂ ZSTD vs Brotli vs GZIP ਵਿਚੋਂ ਚੋਣ ਕਰ ਰਹੇ ਹੋ, ਤਦ ਅਮਲ ਵਿੱਚ ਫੈਸਲਾ ਆਮ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਤਿੰਨ ਬਿੰਦੂਆਂ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦਾ ਹੈ:\n\n1. ਸਾਈਜ਼ ਘਟਾਉਣਾ (ਕੰਪਰੈਸ਼ਨ ਰੇਸ਼ੋ)\n2. ਲੈਟੇਨਸੀ (ਸਰਵਰ TTFB ਅਤੇ ਕਲਾਇਂਟ ਡੀਕੋਡ ਸਮੇਤ)\n3. ਕਲਾਇਂਟ ਸਪੋਰਟ (ਤੁਹਾਡੇ ਕਾਲਰ ਅਤੇ ਮਧ੍ਯਸਥ ਕੀ ਸਹਿਯੋਗ ਕਰਦੇ ਹਨ)\n\nਬਾਕੀ ਲੇਖ ਇਹਨਾਂ ਤਿੰਨ ਨੂੰ ਤੁਹਾਡੇ API ਅਤੇ ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ ਲਈ ਸੰਤੁਲਿਤ ਕਰਨ ਬਾਰੇ ਹੈ।\n\n## ZSTD vs Brotli vs GZIP: ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਨਜ਼ਰ\n\nਤਿੰਨੋ ਹੀ ਪੇਲੋਡ ਦਾ ਆਕਾਰ ਘਟਾਉਂਦੇ ਹਨ, ਪਰ ਉਹ ਵੱਖ-ਵੱਖ ਸੀਮਾਵਾਂ—ਸਪੀਡ, ਕੰਪਰੈਸ਼ਨ ਰੇਸ਼ੋ ਅਤੇ ਕੰਪੈਟੀਬਿਲਟੀ—ਤੇ ਮੁਹਾਰਤ ਰੱਖਦੇ ਹਨ।\n\n### ਇੱਕ-ਦ੍ਰਿਸ਼ਟਿ ਸਾਰ\n\n- ZSTD (Zstandard): ਜਦੋਂ ਤੁਹਾਨੂੰ ਨਿਯਤ CPU ਅਤੇ ਘੱਟ ਲੈਟੇਨਸੀ ਚਾਹੀਦੀ ਹੈ, APIs ਲਈ ਅਕਸਰ ਸਭ ਤੋਂ ਵਧੀਆ ਸੰਤੁਲਨ। ਚੰਗਾ ਰੇਸ਼ੋ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਮੰਦ ਹੋਏ।\n- Brotli: ਅਕਸਰ ਟੈਕਸਟ-ਭਾਰੀ ਰਿਸਪੌਂਸਾਂ (JSON, HTML ਵਰਗੇ) 'ਤੇ ਸਭ ਤੋਂ ਛੋਟਾ ਬਾਈਟਸ ਦਿੰਦਾ ਹੈ। ਉੱਚ ਸੈਟਿੰਗਾਂ CPU ਮਹਿੰਗੀ ਹੋ ਸਕਦੀਆਂ ਹਨ।\n- GZIP: “ਹਰ ਜਗ੍ਹਾ ਕੰਮ ਕਰਦਾ” ਵਿਕਲਪ। ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਅਤੇ ਆਪਰੇਸ਼ਨ ਲਈ ਆਸਾਨ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਨਵੀਆਂ ਵਿਕਲਪਾਂ ਨਾਲ ਤੁਲਨਾ ਵਿੱਚ ਧੀਮਾ ਅਤੇ/ਜਾਂ ਵੱਡਾ ਹੁੰਦਾ ਹੈ।\n\n### ਆਮ ਤਾਕਤਾਂ (ਅਤੇ APIs ਲਈ ਕੀ ਮਤਲਬ)\n\nZSTD ਦੀ ਤੇਜ਼ੀ: ਜਦੋਂ ਤੁਹਾਡਾ API ਟੇਲ ਲੈਟੇਨਸੀ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋਵੇ ਜਾਂ ਸਰਵਰ CPU ਬਾਊਂਡ ਹੋਣ, ਤਦ ZSTD ਵਧੀਆ ਹੈ। ਇਹ ਇੰਨਾ ਤੇਜ਼ ਕੰਪਰੈਸ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਬਹੁਤ ਵਾਰ ਨੈਟਵਰਕ ਸਮੇਂ ਨਾਲ ਤੁਲਨਾ ਕਰਨ 'ਤੇ ਓਹਲਾ ਓਵਰਹੈੱਡ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਦਰਮਿਆਨੇ ਤੋਂ ਵੱਡੇ JSON ਰਿਸਪੌਂਸਾਂ ਲਈ।\n\nBrotli ਕੰਪਰੈਸ਼ਨ ਰੇਸ਼ੋ: ਜਦੋਂ ਬੈਂਡਵਿਡਥ ਪ੍ਰਾਇਮਰੀ ਸੀਮਿਤੀ ਹੋਵੇ (ਮੋਬਾਇਲ ਕਲਾਇਂਟ, ਮਹਿੰਗਾ ਆਉਟਗੋਇੰਗ, CDN-ਭਾਰੀ ਡਿਲਿਵਰੀ) ਅਤੇ ਰਿਸਪੌਂਸ ਜ਼ਿਆਦਾਤਰ ਟੈਕਸਟ-ਭਾਰੀ ਹੋਣ, ਤਦ Brotli ਅਕਸਰ ਛੋਟਾ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ। ਛੋਟੇ ਪੇਲੋਡ ਵੀ ਵਧੀਆ ਲਾਭ ਦੇ ਸਕਦੇ ਹਨ ਭਾਵੇਂ ਕੰਪਰੈਸ਼ਨ ਵਧੇਰੇ ਸਮਾਂ ਲਵੇ।\n\nGZIP ਦੀ ਕੰਪੈਟੀਬਿਲਟੀ: ਜਦੋਂ ਤੁਹਾਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਲਾਇਂਟ ਸਪੋਰਟ ਚਾਹੀਦੀ ਹੋਵੇ (ਪੁਰਾਣੇ SDKs, ਐਂਬੇਡਿਡ ਕਲਾਇਂਟ, ਲੈਗੇਸੀ ਪ੍ਰਾਕਸੀ), ਤਾਂ ਇਹ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੈ। ਇਹ ਇੱਕ ਸੁਰੱਖਿਅਤ ਬੇਸਲਾਈਨ ਹੈ ਭਾਵੇਂ ਇਹ ਸਰਵੋਤਮ ਨਾ ਹੋਵੇ।\n\n### “ਕੰਪਰੈਸ਼ਨ ਲੈਵਲ” ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ\n\nਕੰਪਰੈਸ਼ਨ "ਲੇਵਲ" ਉਹ ਪ੍ਰੀਸੈਟ ਹਨ ਜੋ CPU ਸਮਾਂ ਦਾ ਵਪਾਰ ਛੋਟੇ ਆਊਟਪੁੱਟ ਨਾਲ ਕਰਦੇ ਹਨ:\n\n- ਨਿਮਨੇ ਲੈਵਲ: ਤੇਜ਼ ਕੰਪਰੈਸ਼ਨ, ਵੱਡੇ ਪੇਲੋਡ। ਰੀਅਲ-ਟਾਈਮ APIs ਲਈ ਚੰਗੇ।\n- ਉੱਚੇ ਲੈਵਲ: ਛੋਟੇ ਪੇਲੋਡ, ਪਰ ਸਲੋ ਕੰਪਰੈਸ਼ਨ (ਕਈ ਵਾਰ ਜ਼ਿਆਦਾ ਮੈਮੋਰੀ). ਵੱਡੇ,-cacheable ਰਿਸਪੌਂਸ ਲਈ ਵਧੀਆ।\n\nਸਭ ਤੋਂ ਲਈ, ਡੀਕੰਪਰੈਸ਼ਨ ਤਿੰਨਾਂ ਲਈ ਅਮੂਮਨ ਕੰਪਰੈਸ਼ਨ ਨਾਲੋਂ ਕਾਫ਼ੀ ਸਸਤਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਬਹੁਤ ਉੱਚੇ ਲੈਵਲ ਕਲਾਇਂਟ CPU/ਬੈਟਰੀ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਇਲ 'ਤੇ।\n\n### ਸਧਾਰਨ ਨਿਯਮ\n\n- ਡਿਫਾਲਟ ਚੋਣ: ਜ਼ਿਆਦਾਤਰ JSON/REST/GraphQL APIs ਲਈ ZSTD ਵਰਤੋਂ ਜੇ ਲੈਟੇਨਸੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।\n- Brotli 'ਤੇ ਸਵਿੱਚ ਕਰੋ: ਜਦੋਂ ਤੁਸੀਂ ਸਭ ਤੋਂ ਘੱਟ ਬਾਈਟਸ ਲਈ ਅਨਕੋਲੀ ਹੋ (ਟੈਕਸਟ-ਭਾਰੀ, CDN ਡਿਲਿਵਰੀ, ਧੀਮੀ ਨੈੱਟਵਰਕ) ਅਤੇ ਤੁਸੀਂ ਵਧੇਰੇ CPU ਬਹਿਸ ਕਰ ਸਕਦੇ ਹੋ।\n- GZIP ਨਾਲ ਰਹੋ: ਜੇ ਤੁਹਾਨੂੰ ਚੌੜੀ ਕੰਪੈਟੀਬਿਲਟੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਤੁਹਾਡੀ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਨਵੇਂ ਐਨਕੋਡਿੰਗਾਂ ਨੂੰ ਸਹਾਰ ਨਹੀਂ ਦਿੰਦੀ।\n\n## ਰੇਸ਼ੋ ਵర్సਸ ਲੈਟੇਨਸੀ: ਮੁੱਖ ਵਪਾਰ\n\nਕੰਪਰੈਸ਼ਨ ਅਕਸਰ ਇਹ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ ਕਿ “ਛੋਟੇ ਰਿਸਪੌਂਸ = ਤੇਜ਼ APIs।” ਧੀਮੀਆਂ ਜਾਂ ਮਹਿੰਗੀਆਂ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਇਹ ਅਕਸਰ ਸਹੀ ਹੁੰਦਾ ਹੈ—ਪਰ ਇਹ ਆਟੋਮੈਟਿਕ ਨਹੀਂ ਹੈ। ਜੇ ਕੰਪਰੈਸ਼ਨ ਸਰਵਰ CPU 'ਤੇ ਕਾਫ਼ੀ ਸਮਾਂ ਜੋੜ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਘੱਟ ਬਾਈਟ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਧੀਮੀਆਂ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।\n\n### ਸਮਾਂ ਕਿੱਥੇ ਖਰਚ ਹੁੰਦਾ ਹੈ\n\nਇੱਕ ਵਾਰ ਇਹ ਵੱਖਰਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ:\n\n- ਕੰਪਰੈਸ਼ਨ ਸਮਾਂ (ਸਰਵਰ-ਸਾਈਡ): ਸਰਵਰ ਦੇ ਬਾਈਟ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀਤਾ ਕੰਮ। ਇਹ ਸਿੱਧਾ ਰਿਸਪੌਂਸ ਸਮੇਂ (TTFB) ਵਿੱਚ ਵਾਧਾ ਕਰ ਸਕਦਾ ਹੈ।\n- ਡੀਕੰਪਰੈਸ਼ਨ ਸਮਾਂ (ਕਲਾਇਂਟ-ਸਾਈਡ): ਬਾਈਟ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕੀਤਾ ਕੰਮ। ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਰੈਸ਼ਨ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਸਸਤਾ, ਪਰ ਨੀਤੀ ਪਾਵਰਡ ਡਿਵਾਈਸਾਂ ਜਾਂ ਹਾਈ-ਥਰੂਪੁਟ ਕਲਾਇਂਟਾਂ 'ਤੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ।\n\nਉੱਚ ਕੰਪਰੈਸ਼ਨ ਰੇਸ਼ੋ ਟਰਾਂਸਫਰ ਸਮਾਂ ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਜੇ ਕੰਪਰੈਸ਼ਨ 15–30 ms ਪ੍ਰਤੀ ਰਿਸਪੌਂਸ ਵਧਾ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਤੇਜ਼ ਕਨੈਕਸ਼ਨ 'ਤੇ ਤੁਸੀਂ ਜਿੱਤ ਦੇ ਬਜਾਏ ਨੁਕਸਾਨ ਵਿੱਚ ਰਹਿ ਸਕਦੇ ਹੋ।\n\n### ਲੋਡ ਹੇਠਾਂ ਟੇਲ-ਲੈਟੇਨਸੀ ਜਾਲ\n\nਲੋਡ ਹੇਠਾਂ, ਕੰਪਰੈਸ਼ਨ p95/p99 ਲੈਟੇਨਸੀ ਨੂੰ p50 ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੈ। ਜਦੋਂ CPU ਵਰਤੋਂ ਵਧਦੀ ਹੈ, ਬੇਨਤੀਆਂ ਕਤਾਰ ਵਿੱਚ ਲੱਗਦੀਆਂ ਹਨ। ਕਤਾਰਬੱਧੀ ਛੋਟੇ ਪ੍ਰਤੀ-ਬੇਨਤੀ ਖ਼ਰਚਿਆਂ ਨੂੰ ਵੱਡੇ ਦੇਰੀਆਂ ਵਿੱਚ ਬਦਲ ਦੇਂਦੀ ਹੈ—ਔਸਤ ਲੈਟੇਨਸੀ ਠੀਕ ਲੱਗ ਸਕਦੀ ਹੈ, ਪਰ ਸਭ ਤੋਂ ਧੀਮੇ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੇ ਹਨ।\n\n### ਇਸਨੂੰ ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਫੀਚਰ ਵਾਂਗ ਮਾਪੋ\n\nਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। A/B ਟੈਸਟ ਜਾਂ ਸਟੇਜਡ ਰੋਲਆਉਟ ਚਲਾਓ ਅਤੇ ਮੁਕਾਬਲਾ ਕਰੋ:\n\n- p50 ਅਤੇ p95 ਲੈਟੇਨਸੀ (ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ p99)\nThe server picks one and declares what it used:
\n```http
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: zstd
\nਜੇ ਕਲਾਇਂਟ Accept-Encoding: gzip ਭੇਜਦਾ ਹੈ ਤੇ ਤੁਸੀਂ Content-Encoding: br ਨਾਲ ਜਵਾਬ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਉਹ ਕਲਾਇਂਟ ਬਾਡੀ ਪਾਰਸ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਕਲਾਇਂਟ ਕੋਈ Accept-Encoding ਨਹੀਂ ਭੇਜੇ, ਤਾਂ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਹੈ ਕਿ ਕੋਈ ਕੰਪਰੈਸ਼ਨ ਨਾ ਭੇਜੋ।\n\n### ਸਰਵਰ-ਸਾਈਡ ਪ੍ਰਾਇਓਰਿਟੀ ਕ੍ਰਮ ਚੁਣਨਾ\n\nAPI ਲਈ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਕ੍ਰਮ ਅਕਸਰ ਹੋ ਸਕਦਾ ਹੈ:
\n- zstd ਪਹਿਲਾਂ (ਚੰਗੀ ਸਪੀਡ/ਰੇਸ਼ੋ ਸੰਤੁਲਨ)
br (ਅਕਸਰ ਛੋਟਾ, ਕਦੇ-ਕਦੇ ਹੌਲੀ)gzip (ਵੱਧ ਤੋਂ ਵਿਆਪਕ ਕੰਪੈਟੀਬਿਲਟੀ)
\nਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ: zstd > br > gzip।\n\nਇਸ ਨੂੰ ਸਾਰਥਕ ਨਾ ਸਮਝੋ: ਜੇ ਤੁਹਾਡਾ ਟ੍ਰੈਫਿਕ ਜ਼ਿਆਦਾਤਰ ਬ੍ਰਾਊਜ਼ਰ ਹੈ, ਤਾਂ br ਨੂੰ ਉੱਚ ਪ੍ਰਾਇਰਟੀ ਮਿਲ ਸਕਦੀ ਹੈ; ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪੁਰਾਣੇ ਮੋਬਾਇਲ ਕਲਾਇਂਟ ਹਨ, ਤਾਂ gzip ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ “ਚੰਗਾ” ਵਿਕਲਪ ਹੋ ਸਕਦਾ ਹੈ।\n\n### Vary: Accept-Encoding ਅਤੇ ਕੈਸ਼ਿੰਗ
\nਜੇ ਇੱਕ ਰਿਸਪੌਂਸ ਕਈ ਐਨਕੋਡਿੰਗਜ਼ ਵਿੱਚ ਸਰਵ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਜੋੜੋ:
\n```http
Vary: Accept-EncodingUse response compression when responses are text-heavy (JSON/GraphQL/XML/HTML), medium-to-large, and your users are on slow/expensive networks or you pay meaningful egress costs. Skip it (or use a high threshold) for tiny responses, already-compressed media (JPEG/MP4/ZIP/PDF), and CPU-bound services where extra per-request work will hurt p95/p99 latency.
Because it trades bandwidth for CPU (and sometimes memory). Compression time can delay when the server starts sending bytes (TTFB), and under load it can amplify queueing—often hurting tail latency even if average latency improves. The “best” setting is the one that reduces end-to-end time, not just payload size.
A practical default priority for many APIs is:
zstd first (fast, good ratio)br (often smallest for text, can cost more CPU)gzip (widest compatibility)Always base the final choice on what the client advertises in , and keep a safe fallback (usually or ).
Start low and measure.
Use a minimum response size threshold so you don’t burn CPU on tiny payloads.
Tune per endpoint by comparing bytes saved vs added server time and the impact on p50/p95/p99 latency.
Focus on content types that are structured and repetitive:
Compression should follow HTTP negotiation:
Accept-Encoding (e.g., zstd, br, gzip)Content-EncodingIf the client doesn’t send , the safest response is typically . Never return that the client didn’t advertise, or you risk client failures.
Add:
Vary: Accept-EncodingThis prevents CDNs/proxies from caching (say) a gzip response and incorrectly serving it to a client that didn’t request or can’t decode gzip (or zstd/br). If you support multiple encodings, this header is essential for correct caching behavior.
Common failure modes include:
Roll it out like a performance feature:
API ਇੰਸਟੈਂਸਾਂ 'ਤੇ CPU ਵਰਤੋਂ ਅਤੇ ਸੈਚੁਰੇਸ਼ਨ
ਰਿਸਪੌਂਸ ਆਕਾਰਾਂ ਅਤੇ TTFB\n\nਵਾਸਤਵਿਕ ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ ਅਤੇ ਪੇਲੋਡ ਨਾਲ ਟੈਸਟ ਕਰੋ। “ਚੰਗਾ” ਕੰਪਰੈਸ਼ਨ ਲੈਵਲ ਉਹ ਹੈ ਜੋ ਕੁੱਲ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ, ਸਿਰਫ਼ ਬਾਈਟ ਨਹੀਂ।\n\n## ਸਰਵਰ ਅਤੇ ਕਲਾਇਂਟ 'ਤੇ CPU ਅਤੇ ਮੈਮੋਰੀ ਖ਼ਰਚੇ\n\nਕੰਪਰੈਸ਼ਨ ਮੁਫ਼ਤ ਨਹੀਂ—ਇਹ ਦੋਹਾਂ ਅੰਤਾਂ 'ਤੇ ਕੰਮ ਨੂੰ ਬਦਲਦਾ ਹੈ। APIs ਵਿੱਚ, ਇਹ ਰਿਕੁਐਸਟ ਹੈਂਡਲਿੰਗ ਸਮੇਂ, ਵੱਡੇ ਮੈਮੋਰੀ ਫੁਟਪ੍ਰਿੰਟ ਅਤੇ ਕਈ ਵਾਰ ਕਲਾਇਂਟ-ਪੱਖੀ ਧੀਮਾਪਨ ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।\n\n### CPU ਕਿੱਥੇ ਖਰਚ ਹੁੰਦਾ ਹੈ\n\nਜ਼ਿਆਦਾਤਰ CPU ਰਿਸਪੌਂਸ ਕੰਪਰੈਸ਼ਨ 'ਤੇ ਖਰਚ ਹੁੰਦਾ ਹੈ। ਕੰਪਰੈਸ਼ਨ ਪੈਟਰਨ ਲੱਭਦਾ ਹੈ, ਸਟੇਟ/ਡਿਕਸ਼ਨਰੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਐਨਕੋਡ ਕੀਤਾ ਆਉਟਪੁੱਟ ਲਿਖਦਾ ਹੈ।\n\nਡੀਕੰਪਰੈਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਸਸਤਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਹਮੇਸ਼ਾਂ ਸਬੰਧਤ ਹੈ:
ਸਰਵਰ ਕੁਝ ਹਾਲਤਾਂ ਵਿੱਚ ਰਿਸਪੌਂਸ ਨੂੰ ਡੀਕੰਪਰੈਸ਼ਨ ਕਰ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਵਧੇਰੇ ਹੈ)।
ਕਲਾਇਂਟ JSON ਪਾਰਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡੀਕੰਪਰੈਸ਼ਨ ਕਰਦੇ ਹਨ।\n\nਜੇ ਤੁਹਾਡਾ API ਪਹਿਲਾਂ ਹੀ CPU-ਬਾਊਂਡ ਹੈ, ਤਾਂ ਉੱਚ ਕੰਪਰੈਸ਼ਨ ਲੈਵਲ ਲਾਉਣ ਨਾਲ ਟੇਲ ਲੈਟੇਨਸੀ ਵਧ ਸਕਦੀ ਹੈ ਭਾਵੇਂ ਪੇਲੋਡ ਛੋਟੇ ਹੋਣ।\n\n### ਮੈਮੋਰੀ ਵਿਚਾਰ \nਕੰਪਰੈਸ਼ਨ ਕੁਝ ਢੰਗਾਂ ਨਾਲ ਮੈਮੋਰੀ ਵਰਤੋਂ ਵਧਾ ਸਕਦੀ ਹੈ:
ਬਫਰ: ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਇਨਪੁਟ/ਆਉਟਪੁੱਟ ਬਫਰਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ; ਵੱਡੇ ਪੇਲੋਡ ਵੱਡੇ ਬਫਰ ਮੰਗਦੇ ਹਨ।
ਫੁੱਲ ਬਫਰਿੰਗ بمੁਕਾਬਲੇ ਸਟ੍ਰੀਮਿੰਗ: ਸਟ੍ਰੀਮਿੰਗ ਕੰਪਰੈਸ਼ਨ ਵੱਡੇ ਰਿਸਪੌਂਸ ਲਈ ਜਲਦੀ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਪੀਕ ਮੈਮੋਰੀ ਘਟਾ ਸਕਦੀ ਹੈ, ਜਦਕਿ ਫੁੱਲ ਬਫਰਿੰਗ ਪੀਕ ਮੈਮੋਰੀ ਵਧਾ ਸਕਦੀ ਹੈ।\n\nਕੰਟੇਨਰਾਇਜ਼ਡ ਮਾਹੌਲ ਵਿੱਚ, ਵਧੇਰੇ ਪੀਕ ਮੈਮੋਰੀ OOM kills ਜਾਂ ਕੰਟੇਨਰ ਡੈਂਸੀਟੀ ਘਟਾਉਣ ਵਾਲੇ ਨਤੀਜੇ ਹੋ ਸਕਦੇ ਹਨ।\n\n### ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਕੰਟੇਨਰ ਲਿਮਿਟਾਂ 'ਤੇ ਪ੍ਰਭਾਵ \nਕੰਪਰੈਸ਼ਨ ਪ੍ਰਤੀ-ਰਿਸਪੌਂਸ CPU ਚਕ੍ਰ ਘਟਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪ੍ਰਤੀ-ਇੰਸਟੈਂਸ থਰੂਪੁੱਟ ਘਟਦਾ ਹੈ। ਇਹ ਆਟੋਸਕੇਲਿੰਗ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਖ਼ਰਚ ਵਧਾ ਸਕਦਾ ਹੈ। ਆਮ ਪੈਟਰਨ: ਬੈਂਡਵਿਡਥ ਘਟਦੀ ਹੈ, ਪਰ CPU ਖ਼ਰਚ ਵਧਦਾ ਹੈ—ਸਹੀ ਚੋਣ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਹੈ ਕਿ ਤੁਹਾਡੇ ਲਈ ਕਿਹੜਾ ਸਰੋਤ ਸੰਕਰਾ ਹੈ।\n\n### ਕਲਾਇਂਟ 'ਤੇ ਡੀਕੰਪਰੈਸ਼ਨ ਦੀ ਤੇਜ਼ੀ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ\n\nਮੋਬਾਇਲ ਜਾਂ ਘੱਟ-ਸ਼ਕਤੀ ਵਾਲੇ ਡਿਵਾਈਸਾਂ 'ਤੇ, ਡੀਕੰਪਰੈਸ਼ਨ ਰੇਂਡਰਿੰਗ, JavaScript ਇਕਜ਼ੈਕਿਊਸ਼ਨ ਅਤੇ ਬੈਟਰੀ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ। ਇੱਕ ਫਾਰਮੈਟ ਜੋ ਕੁਝ KB ਬਚਾਉਂਦਾ ਹੈ ਪਰ ਡੀਕੰਪਰੈਸ਼ਨ ਵਿੱਚ ਵਧੇਰਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ ਉਹ ਸਲੂਕੇਤਮ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਵਿੱਚ ਸੁਨੇਹਾ ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹੈ।\n\n## APIs ਲਈ ZSTD: ਤਾਕਤਾਂ, ਸੀਮਾਵਾਂ ਅਤੇ ਸਮਝਦਾਰ ਡਿਫਾਲਟ\n\nZstandard (ZSTD) ਇੱਕ ਆਧੁਨਿਕ ਕੰਪਰੈਸ਼ਨ ਫਾਰਮੈਟ ਹੈ ਜੋ ਵਧੀਆ ਰੇਸ਼ੋ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ ਬਿਨਾਂ ਤੁਹਾਡੇ API ਨੂੰ ਜ਼ਿਆਦਾ ਧੀਮਾ ਕੀਤੇ। ਬਹੁਤ ਸਾਰੇ JSON-ਭਾਰੀ APIs ਲਈ, ਇਹ ਇੱਕ ਮਜ਼ਬੂਤ “ਡਿਫਾਲਟ” ਹੈ: GZIP ਨਾਲੋਂ ਨਜ਼ਰ ਆਉਣਯੋਗ ਛੋਟੇ ਰਿਸਪੌਂਸ ਸੰਭਵ ਕਰਦਾ ਹੈ ਸਮਾਨ ਜਾਂ ਘੱਟ ਲੈਟੇਨਸੀ 'ਤੇ, ਅਤੇ ਕਲਾਇਂਟਾਂ 'ਤੇ ਬਹੁਤ ਤੇਜ਼ ਡੀਕੰਪਰੈਸ਼ਨ।\n\n### ZSTD ਸਭ ਤੋਂ ਵਧੀਆ ਕਿੱਥੇ ਹੈ\n\nZSTD ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅੰਤ-ਟੂ-ਅੰਤ ਸਮਾਂ ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਸਭ ਤੋਂ ਛੋਟੇ ਬਾਈਟ। ਇਹ ਤੇਜ਼ ਕੰਪਰੈਸ਼ਨ ਅਤੇ ਬਹੁਤ ਤੇਜ਼ ਡੀਕੰਪਰੈਸ਼ਨ ਦਿੰਦਾ ਹੈ—ਉਹ APIs ਲਈ ਲਾਭਕਾਰੀ ਜਿੱਥੇ ਹਰ ਮਿਲੀਸੈਕੰਡ ਦੀ ਗਿਣਤੀ ਹੁੰਦੀ ਹੈ।\n\nਇਹ ਛੋਟੇ ਤੋਂ ਵੱਡੇ ਪੇਲੋਡ ਲਈ ਵੀ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਛੋਟੇ-ਦਰਮਿਆਨੇ JSON ਵਿੱਚ ਮਤਲਬਪੂਰਨ ਲਾਭ ਮਿਲਦੇ ਹਨ, ਜਦਕਿ ਵੱਡੇ ਰਿਸਪੌਂਸ ਹੋਰ ਵੀ ਆਪਣੇ ਹਿੱਸੇ ਪਾ ਸਕਦੇ ਹਨ।\n\n### APIs ਲਈ ਸੋਝੀਮੰਦ ਕੰਪਰੈਸ਼ਨ ਲੈਵਲ\n\nਜ਼ਿਆਦਾਤਰ APIs ਲਈ, ਨੀਵੇਂ ਲੈਵਲ (ਆਮ ਤੌਰ 'ਤੇ 1–3) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਹ ਅਕਸਰ ਲੈਟੇਨਸੀ/ਸਾਈਜ਼ ਭੇਦ ਲਈ ਸਭ ਤੋਂ ਚੰਗਾ ਸੰਤੁਲਨ ਦਿੰਦੇ ਹਨ।\n\nਉੱਚੇ ਲੈਵਲ ਸਿਰਫ਼ ਵਰਤੋ ਜਦੋਂ:\n\n- ਪੇਲੋਡ ਵੱਡੇ ਹਨ (ਸੈਂਕੜੇ KB ਤੋਂ MB)
ਬੈਂਡਵਿਡਥ ਮਹਿੰਗੀ ਜਾਂ ਸੀਮਿਤ ਹੈ
ਤੁਸੀਂ ਮਾਪਿਆ ਹੈ ਕਿ CPU ਬੋਟਲਨੇਕ ਨਹੀਂ ਹੈ\n\nਇੱਕ ਵਿਚਾਰਧਾਰਕ ਰਾਹ ਇਹ ਹੈ ਕਿ ਗਲੋਬਲ ਲਈ ਨੀਵਾਂ ਡਿਫਾਲਟ ਰਾਹ ਰੱਖੋ, ਫਿਰ ਕੁਝ “ਵੱਡੇ ਰਿਸਪੌਂਸ” ਐਂਡਪੋਇੰਟਾਂ ਲਈ ਲੈਵਲ ਵਧਾਓ।\n\n### ਸਟ੍ਰੀਮਿੰਗ ਅਤੇ ਡਿਕਸ਼ਨਰੀ ਮੋਡ\n\nZSTD ਸਟ੍ਰੀਮਿੰਗ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ, ਜੋ ਵੱਡੇ ਰਿਸਪੌਂਸ ਲਈ ਪੀਕ ਮੈਮੋਰੀ ਘਟਾ ਸਕਦਾ ਹੈ ਅਤੇ ਜਲਦੀ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।\n\nਡਿਕਸ਼ਨਰੀ ਮੋਡ ਉਨ੍ਹਾਂ APIs ਲਈ ਵੱਡਾ ਫਾਇਦਾ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਬਹੁਤ ਸਮਾਨ ਆਬਜੈਕਟ ਵਾਪਸ ਦਿੰਦੇ ਹਨ (ਦੁਹਰਾਏ ਜਾਂਦੇ ਕੀਜ਼, ਸਥਿਰ ਸਕੀਮਾ)। ਇਹ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ালী ਹੁੰਦਾ ਹੈ ਜਦੋਂ:\n\n- ਪੇਲੋਡ ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ ਛੋਟੇ ਪਰ ਬਾਰੰਬਾਰ ਹੋਂਦਿਆ ਹਨ
ਤੁਸੀਂ ਵਰਜ਼ਨਡ ਡਿਕਸ਼ਨਰੀਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਮੈਨੇਜ ਕਰ ਸਕਦੇ ਹੋ\n\n### ਤੁੱਲ-ਸਹਿਯੋਗ ਦੀਆਂ ਸੀਮਾਵਾਂ ਤੇ ਧਿਆਨ\n\nਸਰਵਰ-ਸਾਈਡ ਸਹਿਯੋਗ ਕਈ ਸਟੈਕਾਂ ਵਿੱਚ ਸੌਖਾ ਹੈ, ਪਰ ਕਲਾਇਂਟ ਕੰਪੈਟੀਬਿਲਟੀ ਫੈਸਲਾ ਕਰਨ ਵਾਲੀ ਹੋ ਸਕਦੀ ਹੈ। ਕੁਝ HTTP ਕਲਾਇਂਟ, ਪ੍ਰਾਕਸੀ ਅਤੇ ਗੇਟਵੇਜ਼ ਮਹਿਸੂਲ ਤੌਰ 'ਤੇ Content-Encoding: zstd ਨੂੰ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਐਡਵਰਟਾਈਜ਼ ਨਹੀਂ ਕਰਦੇ।\n\nਜੇ ਤੁਹਾਡੇ ਤੀਜੇ-ਪੱਖੀ ਉਪਭੋਗਤਾ ਹਨ, ਤਾਂ ਫਾਲਬੈਕ ਰੱਖੋ (ਆਮ ਤੌਰ 'ਤੇ GZIP) ਅਤੇ ZSTD ਨੂੰ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਸਰਗਰਮ ਕਰੋ ਜਦੋਂ Accept-Encoding ਵਿੱਚ ਉਹ ਸਪষ্ট ਤੌਰ 'ਤੇ ਸ਼ਾਮِل ਹੋਵੇ।\n\n## APIs ਲਈ Brotli: ਜਦੋਂ ਇਹ ਜਿੱਤਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਨਹੀਂ\n\nBrotli ਖ਼ਾਸ ਕਰਕੇ ਟੈਕਸਟ ਨੂੰ ਬਹੁਤ ਘੱਟ ਕਰਨ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ। JSON, HTML ਅਤੇ ਹੋਰ “ਸ਼ਬਦ-ਭਾਰੀ” ਪੇਲੋਡਾਂ 'ਤੇ ਇਹ ਅਕਸਰ GZIP ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਉੱਚ ਲੈਵਲਾਂ 'ਤੇ।\n\n### Brotli ਕਿੱਥੇ ਜਿੱਤਦਾ ਹੈ\n\nਟੈਕਸਟ-ਭਾਰੀ ਰਿਸਪੌਂਸ Brotli ਦਾ ਮਿੱਠਾ ਸਥਾਨ ਹੈ। ਜੇ ਤੁਹਾਡੀ API ਵੱਡੇ JSON ਦਸਤਾਵੇਜ਼ (ਕੈਟਾਲੋਗ, ਖੋਜ ਨਤੀਜੇ, ਕਾਂਫਿਗ ਬਲੌਬ) ਭੇਜਦੀ ਹੈ, ਤਾਂ Brotli ਕਾਫ਼ੀ ਬਾਈਟ ਘਟਾ ਸਕਦਾ ਹੈ, ਜੋ ਧੀਮੀ ਨੈੱਟਵਰਕ 'ਤੇ ਮਦਦਗਾਰ ਹੈ ਅਤੇ ਆਉਟਗੋਇੰਗ ਖ਼ਰਚ ਘਟਾ ਸਕਦਾ ਹੈ।\n\nBrotli ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਵੀ ਮਜ਼ਬੂਤ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਵਾਰੀ ਕੰਪਰੈਸ ਕਰਕੇ ਬਹੁਤ ਵਾਰੀ ਸਰਵ ਕਰੋ (cacheable responses, versioned resources). ਇਨ੍ਹਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਉੱਚ-ਲੇਵਲ Brotli ਲਾਇਕਦਾਰ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ CPU ਖ਼ਰਚ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਅਮੋਰਟਾਈਜ਼ਡ ਹੋ ਜਾਂਦਾ ਹੈ।\n\n### Brotli ਕਿੱਥੇ ਨਿਰਾਸ਼ ਕਰਦਾ ਹੈ\n\nਜਿਨ੍ਹਾਂ API ਰਿਸਪੌਂਸਾਂ ਨੂੰ ਹਰ ਬੇਨਤੀ 'ਤੇ ਡਾਈਨਾਮਿਕ ਤੌਰ 'ਤੇ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਲਈ Brotli ਦੇ ਬਿਹਤਰ ਰੇਸ਼ੋ ਅਕਸਰ ਉੱਚੇ ਲੈਵਲਾਂ 'ਤੇ ਮਿਲਦੇ ਹਨ ਜੋ CPU ਮਹਿੰਗਾ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਲੈਟੇਨਸੀ ਵਧਾ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਕੰਪਰੈਸ਼ਨ ਸਮਾਂ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋ, ਤਾਂ ZSTD ਜਾਂ ਇੱਕ ਢੰਗ-ਨਾਲ-ਸੈਟ ਕੀਤਾ GZIP ਇਸ ਤੋਂ ਵੱਡਾ ਫਾਇਦਾ ਦੇ ਸਕਦੇ ਹਨ।\n\nਇਹ ਵੀ ਉਨ੍ਹਾਂ ਪੇਲੋਡਾਂ ਲਈ ਘੱਟ ਮਨੋਗਾਂ ਹਨ ਜੋ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਪਰੈਸ ਨਹੀਂ ਹੁੰਦੀਆਂ (ਪਹਿਲਾਂ ਹੀ ਕੰਪਰੈੱਸਡ ਡੇਟਾ, ਬਾਈਨਰੀ ਫਾਰਮੈਟ)। ਇਨ੍ਹਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਤੁਸੀਂ ਬਸ CPU ਖ਼ਰਚ ਕਰ ਰਹੇ ਹੋ।\n\n### ਕਾਰਗੁਜ਼ਾਰੀ ਲੈਵਲ ਲਈ ਪ੍ਰਯੋਗਾਤਮਕ ਸਲਾਹ\n\n- ਰੰਟਾਈਮ ਕੰਪਰੈਸ਼ਨ: ਨੀਵੇਂ ਲੈਵਲ (ਆਮ ਤੌਰ 'ਤੇ 1–4) ਵਰਤੋ ਤਾਂ ਕਿ CPU ਸਪਾਈਕ ਨਾ ਹੋਣ।\n- ਪ੍ਰੀਕੰਪਰੈਸਡ/ਸਟੈਟਿਕ: ਉੱਚੇ ਲੈਵਲ (ਅਕਸਰ 8–11) ਵਧੀਆ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਖ਼ਰਚ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਅਮੋਰਟਾਈਜ਼ਡ ਹੋ।\n\n### ਕਲਾਇਂਟ ਸਪੋਰਟ ਨੋਟਸ\n\nਬ੍ਰਾਊਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ HTTPS 'ਤੇ Brotli ਨੂੰ ਵਧੀਆ ਸਹਿਯੋਗ ਦਿੰਦੇ ਹਨ, ਇਸੀ ਕਰਕੇ ਇਹ ਵੈੱਬ ਟ੍ਰੈਫਿਕ ਲਈ ਪ੍ਰਸਿੱਧ ਹੈ। ਨਾਨ-ਬ੍ਰਾਊਜ਼ਰ API ਕਲਾਇਂਟਾਂ (ਮੋਬਾਇਲ SDKs, IoT ਡਿਵਾਈਸ, ਬੁਜ਼ੁਰਗ HTTP ਸਟੈਕ) ਲਈ ਸਮਰਥਨ ਅਸਮੰਜਸਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ—ਇਸ ਲਈ ਸਹੀ Accept-Encoding ਸਮਝੌਤਾ ਅਤੇ ਇੱਕ ਫਾਲਬੈਕ (ਅਕਸਰ GZIP) ਰੱਖੋ।\n\n## APIs ਲਈ GZIP: ਕੰਪੈਟੀਬਿਲਟੀ ਅਤੇ ਪ੍ਰਾਇਕਟਿਕਲ ਕਾਰਗੁਜ਼ਾਰੀ\n\nGZIP ਅਜੇ ਵੀ API ਕੰਪਰੈਸ਼ਨ ਲਈ ਡਿਫਾਲਟ ਜਵਾਬ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਭ ਤੋਂ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਵਿਕਲਪ ਹੈ। ਲਗਭਗ ਹਰ HTTP ਕਲਾਇਂਟ, ਬ੍ਰਾਊਜ਼ਰ, ਪ੍ਰਾਕਸੀ ਅਤੇ ਗੇਟਵੇ ਅਨੁਭਵ Content-Encoding: gzip ਨੂੰ ਸਮਝਦਾ ਹੈ, ਅਤੇ ਇਹ ਭਰੋਸੇਯੋਗਤਾ ਉਸ ਵੇਲੇ ਮਤਲਬ ਰੱਖਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੀ ਰਾਹ ਦੀ ਨਿਗਰਾਨੀ ਨਹੀਂ ਕਰਦੇ।\n\n### ਇਹ ਕਿਉਂ ਆਮ ਹੈ\n\nਫਾਇਦਾ ਇਹ ਨਹੀਂ ਕਿ GZIP ਸਭ ਤੋਂ ਚੰਗਾ ਹੈ—ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਹ ਘਣਸ਼:ਚ ਕਰਨ ਵਾਲੀ ਚੋਣ ਨਹੀਂ ਹੁੰਦੀ। ਕਈ ਸੰਗਠਨਾਂ ਕੋਲ ਇਸ ਤੇ ਸਾਲਾਂ ਦਾ ਅਨੁਭਵ ਹੈ, ਵੈੱਬ ਸਰਵਰਾਂ ਵਿੱਚ ਸਮਝਦਾਰ ਡਿਫਾਲਟ ਹਨ, ਅਤੇ ਅਧਿਕਤਮ ਮਧ੍ਯਸਥਾਂ ਨਾਲ ਘੱਟ ਅਚਾਨਕ ਸਮੱਸਿਆਵਾਂ ਆਉਂਦੀਆਂ ਹਨ।\n\n### APIs ਲਈ ਪ੍ਰਾਇਕਟਿਕਲ ਕੰਪਰੈਸ਼ਨ ਲੈਵਲ\n\nAPI ਪੇਲੋਡਾਂ (ਅਕਸਰ JSON) ਲਈ, ਮਿਡ-ਟੂ-ਲੋ ਲੈਵਲ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਹਨ। ਲੈਵਲ ਜਿਵੇਂ 1–6 ਅਕਸਰ ਬਹੁਤ ਸਾਰੀ ਬਚਤ ਦਿੰਦੇ ਹਨ ਜਦਕਿ CPU ਠੀਕ ਰੱਖਦੇ ਹਨ।\n\nਬਹੁਤ ਉੱਚ ਲੈਵਲ (8–9) ਥੋੜ੍ਹੀ ਹੋਰ ਬਚਤ ਦਿੰਦੇ ਹਨ, ਪਰ ਡਾਇਨਾਮਿਕ ਟ੍ਰੈਫਿਕ ਜਿੱਥੇ ਲੈਟੇਨਸੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਉਨ੍ਹਾਂ ਲਈ ਵਾਧੂ CPU ਆਮ ਤੌਰ 'ਤੇ ਲਾਇਕਦਾਰ ਨਹੀਂ ਹੁੰਦਾ।\n\n### ਆਧੁਨਿਕ CPUs 'ਤੇ ਇਹ ਕਿਵੇਂ ਤੁਲਨਾ ਕਰਦਾ ਹੈ\n\nਆਧੁਨਿਕ ਹਾਰਡਵੇਅਰ 'ਤੇ, GZIP ਆਮ ਤੌਰ 'ਤੇ ਇਹੋ ਜਿਹੇ ਰੇਸ਼ੋ 'ਤੇ ZSTD ਨਾਲੋਂ ਧੀਮਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਟੈਕਸਟ ਪੇਲੋਡਾਂ 'ਤੇ Brotli ਦੇ ਬਹੁਤਰੇ ਰੇਸ਼ੋ ਨਾਲ ਮੁਕਾਬਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਰੀਅਲ API ਵਰਕਲੋਡਾਂ 'ਚ, इसका मतलब ਹੈ:
ZSTD ਅਕਸਰ speed-per-byte-saved 'ਤੇ ਜਿੱਤਦਾ ਹੈ।
Brotli ਬਹੁਤ compressible text 'ਤੇ ਆਕਾਰ 'ਚ ਜਿੱਤ ਸਕਦਾ ਹੈ, ਪਰ ਸੈਟਿੰਗਾਂ ਤੇ منحصر ਹੋ ਕੇ ਵਧੇਰੇ CPU ਲੈ ਸਕਦਾ ਹੈ।
GZIP ਮੁਕਾਬਲੇ ਵਿੱਚ ਟਿਕਿਆ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਈ ਸਟੈਕਾਂ 'ਚ ਵਧੀਆ ਢੰਗ ਨਾਲ ਅਾਪਟੀਮਾਈਜ਼ਡ ਹੈ।\n\n### ਕੰਪੈਟੀਬਿਲਟੀ ਏਜ ਕੇਸز (ਪੁਰਾਣੇ ਕਲਾਇਂਟ ਅਤੇ ਮਧ੍ਯਸਥ) \nਜੇ ਤੁਹਾਨੂੰ ਪੁਰਾਣੇ ਕਲਾਇਂਟ, ਐਂਬੇਡਿਡ ਡਿਵਾਈਸ, ਕਾਰਪੋਰੇਟ ਪ੍ਰਾਕਸੀ, ਜਾਂ ਲੈਗੇਸੀ ਗੇਟਵੇਜ਼ ਦਾ ਸਹਿਯੋਗ ਕਰਨਾ ਹੈ, ਤਾਂ GZIP ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੈ। ਕੁਝ ਮਧ੍ਯਸਥ ਅਣਜਾਣ encoding ਨੂੰ ਹਟਾ ਸਕਦੇ ਹਨ, ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਪਾਸ-ਥਰੂ ਨਹੀਂ ਕਰਦੇ, ਜਾਂ ਨੈਗੋਸ਼ੀਏਸ਼ਨ ਨੂੰ ਭੰਗ ਕਰ ਸਕਦੇ ਹਨ—ਇਹ ਸਮੱਸਿਆਵਾਂ GZIP ਨਾਲ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ।\n\nਜੇ ਤੁਹਾਡਾ ਮਾਹੌਲ ਮਿਲਾ-ਜੁਲਾ ਜਾਂ ਅਣਿਸ਼ਚਿਤ ਹੈ, ਤਾਂ GZIP ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੀ ਰਾਹ 'ਤੇ ਕੰਟਰੋਲ ਰੱਖਦੇ ਹੋ ਤਾਂ ZSTD/Brotli ਸ਼ਾਮِل ਕਰੋ) ਇਹ ਇੱਕ ਵਿਸ਼ਵਾਸਯੋਗ ਰੋਲਆਉਟ ਰਣਨੀਤੀ ਹੈ।\n\n## ਪੇਲੋਡ ਕਿਸਮਾਂ: ਕੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਪਰੈਸ ਹੁੰਦਾ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ)\n\nਕੰਪਰੈਸ਼ਨ ਦੇ ਫਾਇਦੇ ਸਿਰਫ਼ ਐਲਗੋਰਿਦਮ 'ਤੇ ਨਹੀਂ ਨਿਰਭਰ; ਸਭ ਤੋਂ ਵੱਡਾ ਕਾਰਕ ਹੈ ਉਹ ਡੇਟਾ ਕਿਸਮ ਜੋ ਤੁਸੀਂ ਭੇਜਦੇ ਹੋ। ਕੁਝ ਪੇਲੋਡ ZSTD, Brotli ਜਾਂ GZIP ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ਯੋਗ ਘਟਦੇ ਹਨ; ਹੋਰ ਬਹੁਤ ਘੱਟ ਅਤੇ ਸਿਰਫ CPU ਜ਼ਾੜਦੇ ਹਨ।\n\n### ਵਧੀਆ ਉਮੀਦਵਾਰ (ਉੱਚ ਫੇਦਾ)\n\nਟੈਕਸਟ-ਭਾਰੀ ਰਿਸਪੌਂਸ ਬਹੁਤ ਵਧੀਆ ਕੰਪਰੈਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਦੁਹਰਾਏ ਜਾਂਦੇ ਕੀਜ਼, ਹੋਵਾਂਤੇ ਅਤੇ ਪੈਟਰਨ ਰੱਖਦੇ ਹਨ।\n\n- JSON (ਆਮ REST ਰਿਸਪੌਂਸ ਸਮੇਤ)
GraphQL responses (ਅਕਸਰ ਦੁਹਰਾਏ ਖੇਤਰਾਂ ਨਾਲ verbose)
XML ਅਤੇ HTML
ਵੱਡੇ ਪਲੈਨ-ਟੈਕਸਟ ਲੌਗ ਅਤੇ ਐਰਰ ਟ੍ਰੇਸ \nਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਜਿੰਨਾ ਵਧੇਰਾ ਦੁਹਰਾਅ ਅਤੇ ਰਚਨਾ, ਉਤਨਾ ਵਧੀਆ ਰੇਸ਼ੋ।\n\n### ਬਾਈਨਰੀ ਪੇਲੋਡ: “ਸ਼ਾਇਦ” (ਪਹਿਲਾਂ ਮਾਪੋ) \nਬਾਈਨਰੀ ਫਾਰਮੈਟ ਜਿਵੇਂ Protocol Buffers ਅਤੇ MessagePack JSON ਨਾਲੋਂ compact ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ “ਰੈਂਡਮ” ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਵੀ ਦੁਹਰਾਏ ਟੈਗ, ਸਮਾਨ ਰਿਕਾਰਡ ਲੇਆਊਟ ਅਤੇ ਪੈਟਰਨ ਰੱਖ ਸਕਦੇ ਹਨ।\n\nਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਉਹ ਅਕਸਰ ਫਿਰ ਵੀ ਕੰਪਰੈਸ ਹੋ ਸਕਦੇ ਹਨ, ਖ਼ਾਸ ਕਰਕੇ ਵੱਡੇ ਰਿਸਪੌਂਸ ਜਾਂ ਲਿਸਟ-ਭਾਰੀ ਐਂਡਪੋਇੰਟਾਂ ਲਈ। ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਜਵਾਬ ਹੈ ਤੁਹਾਡੇ ਅਸਲ ਟ੍ਰੈਫਿਕ ਨਾਲ ਮਾਪਣਾ।\n\n### ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਰੈਸ ਕਰਨ ਲਾਇਕ ਨਹੀਂ (ਪਹਿਲਾਂ ਹੀ ਕੰਪਰੈਸਡ) \nਕਈ ਫਾਰਮੈਟ ਪਹਿਲਾਂ ਹੀ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਕੰਪਰੈਸ ਕਰਦੇ ਹਨ। ਉਨ੍ਹਾਂ 'ਤੇ HTTP ਰਿਸਪੌਂਸ ਕੰਪਰੈਸ਼ਨ ਲਗਾਉਣ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੀ ਬਚਤ ਹੁੰਦੀ ਹੈ ਅਤੇ ਰਿਸਪੌਂਸ ਸਮਾਂ ਵਧ ਸਕਦਾ ਹੈ। \n- Images: JPEG, PNG, WebP
Video/audio: MP4 (ਅਤੇ ਸਮਾਨ)
Archives: ZIP, gzip files
PDF: ਅਕਸਰ ਪਹਿਲਾਂ ਹੀ ਕੰਪਰੈਸਡ ਹੁੰਦੇ ਹਨ
\nਇਨ੍ਹਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਰੈਸ਼ਨ ਨੂੰ Content-Type ਦੇ ਆਧਾਰ 'ਤੇ ਬੰਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।\n\n### ਪ੍ਰਾਇਕਟਿਕਲ ਹਿਊਰਿਸਟਿਕ (ਇਸਨੂੰ ਸਧਾਰਨ ਰੱਖੋ)
\nਇੱਕ ਸੋਝੀਮੰਦ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ Content-Encoding ਨੂੰ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਨਿਊਨਤਮ ਰਿਸਪੌਂਸ ਸਾਈਜ਼ ਥ੍ਰੈਸ਼ੋਲਡ ਰੱਖੋ।
\n- ਇੱਕ ਨਿਯਮਤ ਨਿਯਮ: ਅਕਸਰ ਕੁਝ KB ਤੋਂ ਘੱਟ ਨਾਂ ਕੰਪਰੈਸ ਕਰੋ\n- ਹਮੇਸ਼ਾਂ ਵੱਡੇ ਟੈਕਸਟ ਰਿਸਪੌਂਸਜ਼ ਨੂੰ ਕੰਪਰੈਸ ਕਰੋ; ਛੋਟੇ JSON ਲਈ ਛੋਟੇ-ਥ੍ਰੈਸ਼ੋਲਡ ਰੱਖੋ\n\nਇਸ ਨਾਲ CPU ਉਹਨਾਂ ਪੇਲੋਡਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਰਹਿੰਦਾ ਹੈ ਜਿੱਥੇ ਕੰਪਰੈਸ਼ਨ ਵਾਕਈ ਬੈਂਡਵਿਡਥ ਬਚਾਉਂਦਾ ਅਤੇ ਅੰਤ-ਟੂ-ਅੰਤ ਕਾਰਗੁਜ਼ਾਰੀ ਸੁਧਾਰਦਾ ਹੈ।\n\n## HTTP ਹੈਡਰ ਅਤੇ ਨੈਗੋਸ਼ੀਏਸ਼ਨ: ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕਰਨਾ\n\nਕੰਪਰੈਸ਼ਨ ਸਿਰਫ਼ ਤਦ ਹੀ ਸੁਚੱਜੇ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਕਲਾਇਂਟ ਤੇ ਸਰਵਰ ਕਿਸੇ ਐਨਕੋਡਿੰਗ 'ਤੇ ਰਾਜੀ ਹੋਣ। ਇਹ ਸਹਿਮਤੀ Accept-Encoding (ਕਲਾਇਂਟ) ਅਤੇ Content-Encoding (ਸਰਵਰ) ਰਾਹੀਂ ਹੁੰਦੀ ਹੈ।\n\n### Accept-Encoding ਅਤੇ Content-Encoding (ਸਧਾਰਨ ਉਦਾਹਰਨ)
\nA client advertises what it can decode:
\n```http
GET /v1/orders HTTP/1.1
Host: api.example
Accept-Encoding: zstd, br, gzip
\nਬਿਨਾਂ ਇਸਦੇ, CDN ਜਾਂ ਪ੍ਰਾਕਸੀ ਇੱਕ ਐਨਕੋਡਡ ਵਰਜਨ (ਉਦਾਹਰਨ ਲਈ `gzip`) ਨੂੰ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਉਸਨੂੰ ਕਿਸੇ ਕਲਾਇਂਟ ਨੂੰ ਦੇ ਸਕਦੇ ਹਨ ਜਿਸਨੇ ਉਹ ਐਨਕੋਡਿੰਗ ਨਹੀਂ ਮੰਗੀ।\n\n### ਐਜ ਕੇਸ ਅਤੇ ਸੁਰੱਖਿਅਤ ਫਾਲਬੈਕ
\nਕੁਝ ਕਲਾਇਂਟ ਸਹਿਯੋਗ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ ਪਰ ਡਿਕੋਡਰ ਤਰੁੱਟੀ ਵਾਲੇ ਹੋ ਸਕਦੇ ਹਨ। ਸਥਿਰ ਰਹਿਣ ਲਈ:
\n- ਇੱਕ ਜਾਣਿਆ-ਪਸੰਦ ਫਾਲਬੈਕ ਰੱਖੋ: ਜੇ `zstd` ਲਈ ਡੀਕੋਡ ਤਰੁੱਟੀਆਂ ਵਧਣ, ਤਦ ਅਸਥਾਈ ਤੌਰ 'ਤੇ `gzip` ਤੇ ਵਾਪਸ ਆਓ।
- ‘Problem’ user agents ਜਾਂ SDK ਵਰਜ਼ਨਾਂ ਲਈ allowlists ਵਿਚਾਰੋ।
- ਆਮ ਐਂਡਪੋਇੰਟਾਂ (auth, webhooks) ਲਈ, ਕੰਪਰੈਸ਼ਨ ਬੰਦ ਕਰੋ ਜਾਂ ਸਿਰਫ਼ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੰਪੈਟੀਬਲ ਵਿਕਲਪ ਵਰਤੋ।\n\nਨੈਗੋਸ਼ੀਏਸ਼ਨ ਦਾ ਮਕਸਦ ਹਰ ਬਾਈਟ ਨਾ ਕੱਟਣਾ, ਬਲਕਿ ਕਦੇ ਵੀ ਕਲਾਇਂਟ ਨੂੰ ਤੋੜਨਾ ਨਹੀਂ ਹੋਣਾ।\n\n## HTTP/2, HTTP/3, CDNs, ਅਤੇ ਗੇਟਵੇਜ਼\n\nAPI ਕੰਪਰੈਸ਼ਨ ਇਕ ਵੱਖਰੀ ਚੀਜ਼ ਨਹੀਂ। ਤੁਹਾਡਾ ਟਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ, TLS ਓਵਰਹੈੱਡ, ਅਤੇ ਕੋਈ CDN ਜਾਂ ਗੇਟਵੇ ਵਿਚਕਾਰ ਵਾਸਤਵਿਕ ਨਤੀਜੇ ਬਦਲ ਸਕਦੇ ਹਨ—ਜਾਂ ਗਲਤ ਕੰਫਿਗਰ ਹੋਣ 'ਤੇ ਚੀਜ਼ਾਂ ਟੁੱਟ ਵੀ ਸਕਦੀਆਂ ਹਨ।\n\n### HTTP/2 ਅਤੇ HTTP/3: ਮਲਟੀਪਲੈਕਸਿੰਗ, head-of-line, ਅਤੇ ਕੀ ਬਦਲਦਾ ਹੈ\n\nHTTP/2 ਨਾਲ, ਇੱਕ TCP ਕੰਨੈਕਸ਼ਨ 'ਤੇ ਕਈ ਬੇਨਤੀਆਂ ਸ਼ੇਅਰ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਕਨੈਕਸ਼ਨ ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਪੈਕਟ ਲਾਸ ਤਾਂ ਹੋਣ 'ਤੇ ਸਾਰੇ ਸਟ੍ਰੀਮ ਸਟਾਲ ਹੋ ਸਕਦੇ ਹਨ। ਕੰਪਰੈਸ਼ਨ ਰਿਸਪੌਂਸ ਬਾਡੀ ਨੂੰ ਛੋਟਾ ਕਰਕੇ ਇਸ ਦੀ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ।\n\nHTTP/3 QUIC (UDP) 'ਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਸਟ੍ਰੀਮਾਂ ਵਿਚਕਾਰ TCP-ਸਤਰ head-of-line ਬਲਾਕਿੰਗ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਫਿਰ ਵੀ, ਪੇਲੋਡ ਆਕਾਰ ਮਹੱਤਵਪੂਰਨ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਨੁਕਸਾਨ ਅਕਸਰ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਕੰਪਰੈਸ਼ਨ ਫਾਇਦੇ ਦੇਵੇਗਾ—ਜ਼ਿਆਦਾਤਰ ਤੌਰ 'ਤੇ ਬੈਂਡਵਿਡਥ ਬਚਤ ਅਤੇ “ਟਾਈਮ ਟਿਲ ਲਾਸਟ ਬਾਈਟ” ਵਿੱਚ ਤੇਜ਼ੀ ਦੇ ਕੇ।\n\n### TLS ਇੰਟਰੈਕਸ਼ਨ: CPU ਬਡਜਟ ਬਾਰੇ ਨਾ ਭੁੱਲੋ\n\nTLS ਪਹਿਲਾਂ ਹੀ CPU ਖ਼ਪਤ ਕਰਦਾ ਹੈ (ਹੈਂਡਸ਼ੇਕ, ਇਨਕ੍ਰਿਪਸ਼ਨ/ਡੀਕ੍ਰਿਪਸ਼ਨ)। ਉੱਚ ਲੈਵਲ ਕੰਪਰੈਸ਼ਨ ਜੋੜਣ ਨਾਲ ਤੁਸੀਂ CPU ਸੀਮਾਵਾਂ 'ਤੇ ਪਹੁੰਚ ਸਕਦੇ ਹੋ। ਇਸ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ “ਤੇਜ਼ ਕੰਪਰੈਸ਼ਨ ਨਾਲ ਚੰਗਾ ਰੇਸ਼ੋ” ਵਾਲੀ ਸੈਟਿੰਗ ਆਮ ਤੌਰ 'ਤੇ “ਅਧਿਕਤਮ ਰੇਸ਼ੋ” ਨਾਲੋਂ ਵਧੀਆ ਰਹਿੰਦੀ ਹੈ।\n\n### CDNs ਅਤੇ API ਗੇਟਵੇਜ਼: auto-compress, pass-through, ਜਾਂ strip
\nਕੁਝ CDN/ਗੇਟਵੇ ਕੁਝ MIME ਟਾਈਪਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਕੰਪਰੈਸ ਕਰਦੇ ਹਨ, ਜਦਕਿ ਹੋਰ ਉਹ ਜੋ ਓਰੀਜਿਨ ਭੇਜਦਾ ਹੈ ਉਸਨੂੰ ਪਾਸ-ਥਰੂ ਕਰਦੇ ਹਨ। ਕੁਝ ਗਲਤ ਕੰਫਿਗਰ ਹੋਣ 'ਤੇ `Content-Encoding` ਨੂੰ ਬਦਲ ਜਾਂ ਹਟਾ ਵੀ ਸਕਦੇ ਹਨ।\n\nਰੋਟ ਪ੍ਰਤੀ ਵਿਹੈਵਿਅਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ `Vary: Accept-Encoding` ਸੰਰੱਖਿਤ ਹੈ ਤਾਂ ਜੋ ਕੈਸ਼ਾਂ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੰਪ੍ਰੈੱਸਡ ਵਰਜਨ ਨਾ ਸੇਵਾ ਕਰਣ।\n\n### ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀ: edge vs origin (ਅਤੇ ਕਈ ਵਰਜਨ)
\nਜੇ ਤੁਸੀਂ edge 'ਤੇ ਕੈਸ਼ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਹਰ ਐਨਕੋਡਿੰਗ ਲਈ ਵੱਖ-ਵੱਖ ਵਰਜਨ ਸਟੋਰ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ (gzip/br/zstd) ਬਜਾਏ ਹਰ ਹਿਟ 'ਤੇ ਦੁਬਾਰਾ ਕੰਪਰੈਸ ਕਰਨ ਦੇ। ਜੇ ਤੁਸੀਂ origin 'ਤੇ ਕੈਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ edge ਨੂੰ negotiated ਵੱਖ-ਵੱਖ ਐਨਕੋਡਿੰਗਜ਼ ਲਈ ਕੰਟੈਨ-ਕੈਸ਼ ਕਰਨ ਦੇਣ 'ਤੇ ਸੋਚੋ।\n\nਮੁੱਖ ਗੱਲ ਪੱਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਠੀਕ `Content-Encoding`, ਠੀਕ `Vary`, ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਕਿ ਕੰਪਰੈਸ਼ਨ ਕਿੱਥੇ ਹੋ ਰਹੀ ਹੈ।\n\n## ਸੁਝਾਅ ਡਿਫਾਲਟ ਅਤੇ ਟਿਊਨਿੰਗ ਪਲੇਬੁੱਕ\n\n### ਕਿਸ ਪਰੀਸਥਿਤੀ ਲਈ ਕੀ ਡਿਫਾਲਟ\n\nBrowser-facing APIs ਲਈ, ਜਦੋਂ ਕਲਾਇਂਟ `Accept-Encoding: br` ਐਡVERTISE ਕਰਦਾ ਹੈ ਤਾਂ **Brotli** ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਬ੍ਰਾਊਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ Brotli ਨੂੰ ਅEfficient ਤਰੀਕੇ ਨਾਲ ਡੀਕੋਡ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਟੈਕਸਟ ਰਿਸਪੌਂਸਾਂ 'ਤੇ ਬਹੁਤਰੀਨ ਸਾਈਜ਼ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ।\n\nInternal service-to-service APIs ਲਈ, ਜਦੋਂ ਦੋਹਾਂ ਪਾਸੇ ਤੁਹਾਡਾ ਕੰਟਰੋਲ ਹੋਵੇ, ਤਾਂ **ZSTD** ਨੂੰ ਡਿਫਾਲਟ ਰੱਖੋ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ GZIP ਨਾਲੋਂ ਤੇਜ਼ ਅਤੇ ਸਮਾਨ ਜਾਂ ਬਿਹਤਰ ਰੇਸ਼ੋ ਦਿੰਦਾ ਹੈ।\n\nPublic APIs ਲਈ ਜੋ ਵਿਭਿੰਨ SDKs ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, **GZIP** ਨੂੰ ਯੂਨੀਵਰਸਲ ਬੇਸਲਾਈਨ ਰੱਖੋ ਅਤੇ ਚਾਹੇ ਤਾਂ ZSTD ਇੱਕ opt-in ਵਜੋਂ ਸ਼ਾਮਿਲ ਕਰੋ। ਇਸ ਨਾਲ ਪੁਰਾਣੇ HTTP ਸਟੈਕਾਂ ਨੂੰ ਤੋੜਣ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।\n\n### ਸੰਰਚਿਤ ਸ਼ੁਰੂਆਤੀ ਲੈਵਲ\n\nਉਹ ਲੈਵਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਮਾਪਣ ਲਈ ਆਸਾਨ ਅਤੇ ਚੌਕਸੀ ਤੋਂ ਬਿਨਾਂ ਹੋਣ:
\n- **Brotli:** ਲੈਵਲ **4–6** for dynamic API responses (ਉੱਚ ਲੈਵਲ ਸਰਵਰ CPU ਬਢ਼ਾ ਸਕਦੇ ਹਨ)
- **ZSTD:** ਲੈਵਲ **3–5** for general-purpose API payloads
- **GZIP:** ਲੈਵਲ **5–6** (ਉੱਚ ਲੈਵਲ ਅਕਸਰ diminishing returns ਦਿੰਦੇ ਹਨ)
\nਜੇ ਤੁਹਾਨੂੰ ਵਧੀਕ ਰੇਸ਼ੋ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਪ੍ਰੋਡਕਸ਼ਨ-ਜੈਸੀ ਪੇਲੋਡ ਨਮੂਨਾਂ ਨਾਲ ਵੈਧ ਕਰੋ ਅਤੇ p95/p99 ਨੋਟ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਲੈਵਲ ਵਧਾਉ।\n\n### ਨਿਯੂਨਤਮ ਸਾਈਜ਼ ਥ੍ਰੈਸ਼ੋਲਡ (ਅਤੇ ਟਿਊਨਿੰਗ)
\nਛੋਟੇ ਰਿਸਪੌਂਸਾਂ 'ਤੇ ਕੰਪਰੈਸ਼ਨ CPU ਬਚਤ ਤੋਂ ਜ਼ਿਆਦਾ ਖ਼ਰਚ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ:
\n- **1–2 KB ਤੋਂ ਘੱਟ** 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਰੈੱਸ ਨਾ ਕਰੋ
- ਜੇ ਤੁਸੀਂ CPU-ਬਾਊਂਡ ਹੋ ਜਾਂ ਬਹੁਤ chatty APIs ਹਨ: **4 KB** 'ਤੇ ਵਿਚਾਰ ਕਰੋ
\nਤੁਨ ਕਰੋ ਦੁਆਰਾ ਮੁਕਾਬਲਾ ਕਰਨ: (1) ਬਾਈਟਸ ਬਚਤ, (2) ਸਰਵਰ ਸਮੇਂ 'ਚ ਵਾਧਾ, (3) ਅੰਤ-ਟੂ-ਅੰਤ ਲੈਟੇਨਸੀ ਵਿੱਚ ਬਦਲਾਅ।\n\n### ਨਿਕਸ-ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ
\nਕੰਪਰੈਸ਼ਨ ਨੂੰ ਇੱਕ **feature flag** ਦੇ ਪਿੱਛੇ ਰੋਲਆਉਟ ਕਰੋ, ਫਿਰ **per-route config** ਸ਼ਾਮਿਲ ਕਰੋ (ਉਦਾਹਰਨ ਦੇ तौर ਤੇ `/v1/search` ਲਈ ਏਨਬਲ ਕਰੋ, ਛੋਟੇ ਐਂਡਪੋਇੰਟਾਂ ਲਈ ਵੱਖਰਾ ਰੱਖੋ)। ਇਕ **ਕਲਾਇਂਟ opt-out** ਦੇਣ ਲਈ `Accept-Encoding: identity` ਵਰਤੋਂ troubleshooting ਲਈ। ਹਮੇਸ਼ਾਂ `Vary: Accept-Encoding` ਜੋੜੋ ਤਾਂ ਕਿ ਕੈਸ਼ ਸਹੀ ਰਹਿਣ।\n\n### ਆਧੁਨਿਕ build-and-ship ਵਰਕਫਲੋਜ਼ 'ਚ ਇਹ ਕਿੱਥੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ\n\nਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ APIs ਜਨਰੇਟ ਕਰਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, React ਫਰੰਟਐਂਡ ਦੇ ਨਾਲ Go + PostgreSQL ਬੈਕਐਂਡ), ਤਾਂ ਕੰਪਰੈਸ਼ਨ ਉਹਨਾਂ “ਛੋਟੇ ਕੰਫਿਗ ਨોબਜ਼” ਵਿੱਚੋਂ ਇੱਕ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸਦਾ ਵੱਡਾ ਪ੍ਰਭਾਵ ਹੋ ਸਕਦਾ ਹੈ।\n\nOn **Koder.ai**, ਟੀਮਾਂ ਅਕਸਰ ਇਸ ਪਹੁੰਚ 'ਤੇ ਪਹਿਲਾਂ ਪਹੁੰਚ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਡਿਪਲੋਇ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਫਿਰ ਪਰਫਾਰਮੈਂਸ ਵਿਹਾਰ (ਜਿਵੇਂ response compression ਅਤੇ cache headers) ਨੂੰ ਟਿਊਨ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਐਂਡਪੋਇੰਟ ਅਤੇ ਪੇਲੋਡ ਸ਼ੇਪ ਸਥਿਰ ਹੋ ਜਾਂਦੇ ਹਨ। ਪ੍ਰਯੋਗਿਕ ਸਿੱਖਿਆ ਇਹੀ ਹੈ: ਕੰਪਰੈਸ਼ਨ ਨੂੰ ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਫੀਚਰ ਸਮਝੋ, ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਸ਼ਿਪ ਕਰੋ, ਅਤੇ p95/p99 ਮਾਪੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰੋ।\n\n## ਰੋਲਆਉਟ, ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ\n\nਕੰਪਰੈਸ਼ਨ ਬਦਲਾਅ ਆਸਾਨੀ ਨਾਲ ਸ਼ਿਪ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਪਰ ਅਚਾਨਕ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ। ਇਸਨੂੰ ਇਕ ਪ੍ਰੋਡਕਸ਼ਨ ਫੀਚਰ ਵਾਂਗ ਰੋਲਆਉਟ ਕਰੋ: ਧੀਰੇ-ਧੀਰੇ, ਪ੍ਰਭਾਵ ਮਾਪੋ, ਅਤੇ ਰੋਲਬੈਕ ਆਸਾਨ ਰੱਖੋ।\n\n### ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੋਲਆਉਟ ਯੋਜ਼ਨਾ\n\nਸ਼ੁਰੂ ਕਰੋ ਇੱਕ **canary** ਨਾਲ: ਨਵਾਂ `Content-Encoding` (ਉਦਾਹਰਨ ਲਈ, `zstd`) ਇੱਕ ਛੋਟੀ ਟ੍ਰੈਫਿਕ ਸਲਾਈਸ ਜਾਂ ਇੱਕ ਅੰਦਰੂਨੀ ਕਲਾਇਂਟ ਲਈ ਚਾਲੂ ਕਰੋ।\n\nਫਿਰ **ਧੀਰੇ-ਧੀਰੇ ਰੈਂਪ** (ਉਦਾਹਰਨ: 1% → 5% → 25% → 50% → 100%), ਅਤੇ ਜੇ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਨੁਕਸਾਨ ਹੋਵੇ ਤਾਂ ਰੁਕ ਜਾਓ।\n\nਆਸਾਨ **ਰੋਲਬੈਕ** ਰਾਹ ਰੱਖੋ:
\n- ਗੇਟਵੇ/ਸਰਵਿਸ 'ਤੇ ਫੀਚਰ ਫਲੈਗ ਜੋ ਕੰਪਰੈਸ਼ਨ ਬੰਦ ਕਰ ਦੇਵੇ (ਜਾਂ `gzip` ਤੇ ਫਾਲਬੈਕ)
- ਕੁਝ ਐਂਡਪੋਇੰਟ ਨੂੰ ਬਾਹਰ ਰੱਖਣ ਦਾ ਤਰੀਕਾ (ਫਾਇਲ ਡਾਊਨਲੋਡ, ਪਹਿਲਾਂ ਹੀ ਕੰਪਰੈੱਸਡ ਮੀਡੀਆ)
- ਇੱਕ ਤੇਜ਼ config-ਕੇਵਲ ਡਿਪਲੋਯ, ਕੋਡ ਡਿਪਲੋਯ ਨਹੀਂ।\n\n### ਕੀ ਮਾਪਣਾ ਹੈ (ਅਤੇ ਕਿਉਂ)
\nਕੰਪਰੈਸ਼ਨ ਨੂੰ ਦੋਹਾਂ ਪਰਫਾਰਮੈਂਸ ਅਤੇ ਰਿਲਾਇਬਿਲਟੀ ਬਦਲਾਅ ਵਜੋਂ ਟਰੇਕ ਕਰੋ:
\n- **CPU** (ਸਰਵਰ ਅਤੇ ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਕਲਾਇਂਟ): ਉੱਚ ਕੰਪਰੈਸ਼ਨ ਲੈਵਲ CPU ਸਪਾਈਕ ਕਰ ਸਕਦੇ ਹਨ।
- **Latency percentiles** (p50/p95/p99): ਕੰਪਰੈਸ਼ਨ ਅਕਸਰ ਔਸਤ ਲੈਟੇਨਸੀ ਸੁਧਾਰਦਾ ਹੈ ਪਰ ਟੇਲ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ।
- **Response sizes:** ਵਾਇਰ ਬਾਈਟਸ ਪ੍ਰਤੀ ਐਂਡਪੋਇੰਟ ਅਤੇ "ਕੰਪਰੈੱਸਡ vs ਅਨਕੰਪਰੈੱਸਡ" ਡੈਲਟਾ।
- **Error rates:** `4xx/5xx`, ਕਲਾਇਂਟ ਡੀਕੋਡ ਐਰਰ ਅਤੇ ਟਾਈਮਆਉਟਸ।\n\n### ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਚੈੱਕਲਿਸਟ\n\nਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਆਮ ਸ਼ੱਕਲਾਂ ਇਹ ਹਨ:
\n- **ਡਬਲ-ਕੰਪਰੈਸ਼ਨ:** upstream ਸੇਵਾ ਪਹਿਲਾਂ ਹੀ ਕੰਪਰੈੱਸ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਫਿਰ gateway/ CDN ਦੁਬਾਰਾ ਕਰ ਦਿੰਦਾ ਹੈ।
- **ਗਲਤ ਹੈਡਰ:** `Content-Encoding` ਸੈੱਟ ਹੈ ਪਰ ਬਾਡੀ ਕੰਪਰੈੱਸਡ ਨਹੀਂ ਹੈ (ਜਾਂ ਉਲਟ)।
- **ਖਰਾਬ ਨੈਗੋਸ਼ੀਏਸ਼ਨ:** `Accept-Encoding` ਨੂੰ ਇਗਨੋਰ ਕਰਨਾ ਜਾਂ ਐਸਾ ਐਨਕੋਡਿੰਗ ਵਾਪਸ ਕਰਨਾ ਜੋ ਕਲਾਇਂਟ ਨੇ ਐਡਵਰਟਾਈਜ਼ ਨਹੀਂ ਕੀਤਾ।
- **ਕੋਰੱਪਟ ਸਟਰੀਮਜ਼:** truncated bodies, ਗਲਤ `Content-Length`, ਜਾਂ ਪ੍ਰਾਕਸੀ/CDN ਦਖ਼ਲਅੰਦਾਜ਼ੀ।\n\n### ਕਲਾਇਂਟ ਉਮੀਦਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ
\nਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਐਨਕੋਡਿੰਗਜ਼ ਸਮਰਥਿਤ ਹਨ, ਉਦਾਹਰਣਾਂ ਸਹਿਤ:
\n- ਕਲਾਇਂਟ ਕੀ ਭੇਜਣ: `Accept-Encoding: zstd, br, gzip`
- ਉਹ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਗੇ: `Content-Encoding: zstd` (ਜਾਂ ਫਾਲਬੈਕ)
\nਜੇ ਤੁਸੀਂ SDK ਭੇਜਦੇ ਹੋ, ਤਾਂ ਛੋਟੇ, copy-pasteable ਡੀਕੋਡ ਉਦਾਹਰਨ ਸ਼ਾਮਿਲ ਕਰੋ ਅਤੇ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕਿਸ ਨਿਊਨਤਮ ਵਰਜ਼ਨ ਤੋਂ Brotli ਜਾਂ Zstandard ਸਹਿਯੋਗ ਹੁੰਦਾ ਹੈ।
Accept-EncodinggzipidentityHigher levels usually give diminishing size wins but can spike CPU and worsen p95/p99.
A common approach is to enable compression only for text-like Content-Type values and disable it for known already-compressed formats.
Accept-EncodingContent-EncodingContent-Encoding says gzip but body isn’t gzip)Accept-Encoding)Content-Length when streaming/compressingWhen debugging, capture raw response headers and verify decompression with a known-good tool/client.
If tail latency rises under load, lower the level, increase the threshold, or switch to a faster codec (often ZSTD).