JSON कम्प्रेशन ग़लत क्रम में करना बंद करें: minify vs gzip vs brotli, मापा गया
मुख्य बात: मिनिफ़ाई कच्ची JSON का 30-50% काटता है, लेकिन gzip उसका अधिकांश लाभ मिटा देता है। असली आकृतियों पर मापी गई संख्याएँ, साथ ही वे चार स्थितियाँ जहाँ मिनिफ़ाई चीज़ें बदतर बनाता है।
मुख्य निष्कर्ष: पहले ट्रांसपोर्ट कम्प्रेशन को संरचनात्मक ट्रिमिंग से अलग करें। यदि gzip या brotli अभी तक चालू नहीं है, तो सर्वर कॉन्फ़िगरेशन ठीक करें — अकेले gzip -6 94.5% तक पहुँचता है और minify के लिए केवल 0.9 पॉइंट छोड़ता है। minify का पूरा 46.3% तभी मिलता है जब बाइट बिल स्थानीय रूप से दर्ज हो: अनुरोध बॉडी, Lambda का 6 MB, Firestore का 1 MiB, या डिस्क और लॉग में लिखी जाने वाली JSON।
आपके पसंदीदा मिनिफ़ायर पर लगा "35% बचाया" बैज ईमानदार है - यह कच्चे बाइट्स मापता है। आपकी API gzip या brotli के ऊपर चलती है, और वे दोनों ठीक वही अतिरेक खा जाते हैं। दोनों संख्याओं को गुणा करने पर आपको ग़लत उत्तर मिलता है।
1. "कम्प्रेशन" को दो अलग चीज़ों में बाँटें
जिसे लोग JSON कम्प्रेशन कहते हैं, वह असल में दो असंबंधित ऑपरेशन हैं, और उन्हें मिला देना ही हर ग़लत निष्कर्ष की शुरुआत है।
| minify (व्हाइटस्पेस हटाएँ) | gzip / brotli (ट्रांसपोर्ट कम्प्रेशन) | |
|---|---|---|
| प्रकृति | एक दस्तावेज़ रूपांतरण | एक ट्रांसपोर्ट रूपांतरण |
| आउटपुट | अब भी वैध, अब भी पढ़ने योग्य JSON टेक्स्ट | बाइनरी; डिकोड होने तक अनुपयोगी |
| लाभ कहाँ मिलता है | डिस्क, मेमोरी, लॉग, आकार सीमाएँ | केवल वायर पर और कैश में |
| डिकोडिंग के बाद | बाइट्स छोटे रहते हैं | बाइट्स मूल आकार में लौट आते हैं |
| इसका मालिक कौन | आपकी बिल्ड स्क्रिप्ट, आपके सीरियलाइज़र आर्ग्युमेंट | Nginx, CDN, सर्वर फ़्रेमवर्क |
आख़िरी दो पंक्तियाँ ही मायने रखती हैं। प्लेटफ़ॉर्म सीमाएँ डिकोडिंग के बाद मापी जाती हैं: AWS Lambda की 6 MB पेलोड सीमा, Firestore की प्रति-दस्तावेज़ 1 MiB सीमा। gzip चालू करने से वहाँ एक भी बाइट नहीं मिलता, क्योंकि दोनों डिकोड किए गए परिणाम को गिनते हैं।
2. minify ठीक एक चीज़ हटाता है: संरचनात्मक व्हाइटस्पेस
RFC 8259 किसी भी संरचनात्मक कैरेक्टर के आसपास व्हाइटस्पेस (space, \t, \n, \r) की अनुमति देता है। JSON दस्तावेज़ में और कुछ भी वैकल्पिक नहीं है: कुंजी नाम डेटा हैं, संख्याएँ हर अंक रखती हैं, और स्ट्रिंग सामग्री बाइट-दर-बाइट अछूती रहती है।
इससे पूरा ऑपरेशन एक पंक्ति का हो जाता है:
const minified = JSON.stringify(JSON.parse(pretty));
// RFC 8259 संरचनात्मक कैरेक्टरों के आसपास ही व्हाइटस्पेस की अनुमति देता है,
// इसलिए स्ट्रिंग के अंदर के स्पेस डेटा हैं, फ़ॉर्मेटिंग नहीं
JSON.stringify(JSON.parse('{"note": "two spaces"}'));
// {"note":"two spaces"} - दोनों भीतरी स्पेस सुरक्षित हैं
तीन ऑपरेशन अलग से बताने लायक हैं जिन्हें "कम्प्रेशन" के अंतर्गत रखा जाता है लेकिन वे वास्तव में दस्तावेज़ बदलते हैं: जिन कुंजियों का मान null है उन्हें हटाना, फ़्लोट गोल करना, और कुंजी क्रम बदलना। वे दस्तावेज़ को फ़ॉर्मेट करने के बजाय बदलते हैं, इसलिए "डीप कम्प्रेशन" का विज्ञापन करने वाले किसी भी उपकरण को इसे सक्षम करने से पहले आपके ग्राहक की सहमति चाहिए।
चूँकि minify केवल व्हाइटस्पेस हटाता है, इसका लाभ लगभग पूरी तरह इस पर निर्भर करता है कि आपकी फ़ाइल का कितना हिस्सा इंडेंटेशन है। नीचे की तालिकाओं में यह बार-बार दिखेगा।
3. मापन: चार दस्तावेज़, तीन gzip स्तर, और brotli
वातावरण: Node v22.13.1, स्तर 1 / 6 / 9 पर zlib.gzipSync, अपनी डिफ़ॉल्ट क्वालिटी (11) पर brotliCompressSync। चार नमूने जानबूझकर वे आकृतियाँ कवर करते हैं जो आप वास्तव में भेजते हैं: 50 नेस्टेड ऑर्डर (गहरी संरचना, दोहराई गई कुंजियाँ), 6-स्तरीय कॉन्फ़िग (लंबी कुंजियाँ, छोटे मान), 200-पंक्ति लॉग ऐरे (लंबी स्ट्रिंग्स, लगभग कोई इंडेंटेशन नहीं), और इस साइट की असली media-manifest.json (मिश्रित आकार, URL-भारी स्ट्रिंग्स)।
पहला चरण: कच्चे बाइट्स।
| नमूना | pretty (2 स्पेस) | pretty (4 स्पेस) | minify के बाद | minify बचाता है |
|---|---|---|---|---|
| 50 नेस्टेड ऑर्डर | 29,551 B | 40,761 B | 15,881 B | 46.3% |
| 6-स्तरीय कॉन्फ़िग | 25,450 B | 38,012 B | 11,679 B | 54.1% |
| 200-पंक्ति लॉग ऐरे | 14,582 B | 14,982 B | 13,981 B | 4.1% |
| media-manifest.json | 25,149 B | 28,114 B | 21,222 B | 15.6% |
यहीं से वह "35% बचाया" बैज आता है, और यह झूठ नहीं बोल रहा। समस्या दूसरे चरण में दिखती है।
दूसरा चरण: हर वेरिएंट को कम्प्रेस करें, फिर पूछें कि minify अब भी कितना जोड़ता है।
| नमूना | gzip -1 के ऊपर | gzip -6 के ऊपर | gzip -9 के ऊपर | brotli के ऊपर |
|---|---|---|---|---|
| 50 नेस्टेड ऑर्डर | 21.0% | 17.0% | 8.9% | 10.6% |
| 6-स्तरीय कॉन्फ़िग | 74.2% | 59.1% | 58.0% | 56.4% |
| 200-पंक्ति लॉग ऐरे | -0.7% | -0.4% | 0.6% | -0.3% |
| media-manifest.json | 1.5% | 1.0% | 1.0% | 1.6% |
वही नेस्टेड ऑर्डर दस्तावेज़ जो अपने कच्चे बाइट्स का 46.3% खो देता है, gzip -6 के साथ आते ही उसका केवल 17.0% बचाता है। लॉग ऐरे तो सीधे नकारात्मक हो जाता है: minify-फिर-compress क्रम pretty मूल को कम्प्रेस करने से थोड़ा बड़ा है। नकारात्मक होना बग नहीं है, यह ठीक वही है जिसकी आपको अपेक्षा करनी चाहिए, और अगला अनुभाग इसका कारण बताता है।
तीसरा चरण: मूल pretty दस्तावेज़ की तुलना में कुल कमी - वह संख्या जो वास्तव में वायर पर जाती है।
| नमूना | केवल gzip -6 | minify + gzip -6 | minify + brotli |
|---|---|---|---|
| 50 नेस्टेड ऑर्डर | 94.5% | 95.4% | 96.9% |
| 6-स्तरीय कॉन्फ़िग | 96.0% | 98.4% | 99.0% |
| 200-पंक्ति लॉग ऐरे | 89.9% | 89.9% | 95.0% |
| media-manifest.json | 83.5% | 83.6% | 86.1% |
4. gzip minify का श्रेय क्यों खा जाता है
gzip LZ77 के बाद Huffman कोडिंग है। LZ77 की मुख्य चाल है "32 KB विंडो में पीछे देखो, दोहराया गया क्रम खोजो, उसे (दूरी, लंबाई) पॉइंटर से बदलो।" इंडेंटेशन उस चाल का सबसे आसान लक्ष्य है: हर नेस्टिंग स्तर स्पेस की एक समान लड़ी पैदा करता है, और दर्जनों सन्निकट पंक्तियाँ वही संयोजन दोहराती हैं। फिर Huffman उच्च-आवृत्ति प्रतीकों को छोटे कोड सौंपता है, इसलिए \n प्लस आठ स्पेस जैसे पैटर्न - जो एक ही फ़ाइल में हज़ार बार आ सकता है - अंततः दो या तीन बिट का हो जाता है।
तो minify जो बाइट्स हटाता है, वे ठीक वही बाइट्स हैं जिन्हें कम्प्रेसर लगभग मुफ़्त में सिकोड़ देता। स्वयं करने का अर्थ है कम्प्रेसर जो पहले से उत्कृष्ट है उसी काम को दोहराना, और आपका 46% 17% में सिमट जाता है। ऊपर की तालिका के पीछे यही पूरी कहानी है।
नकारात्मक लॉग-ऐरे परिणाम अपनी व्याख्या का हक़दार है। वह नमूना लगभग पूरी तरह लंबी स्ट्रिंग्स (लॉग पंक्तियाँ, URL, base64) है, यानी कम दोहराव और उच्च एंट्रॉपी - कम्प्रेसर के लिए हटाने को बहुत कम अतिरेक। pretty संस्करण में न्यूलाइन्स संयोगवश मैचर को स्थिर सीमाएँ देते हैं। उन्हें हटाएँ और LZ77 वे एंकर खो देता है: इस नमूने में, gzip -1 पर pretty मूल को कम्प्रेस करने से 1,508 बाइट मिलते हैं, जबकि minify-फिर-compress से 1,518 बाइट। दस बाइट बदतर।
परिमाण के अनुसार क्रमबद्ध करें तो लीवर इस तरह पंक्तिबद्ध होते हैं:
| लीवर | मूल pretty दस्तावेज़ की तुलना में बचत (नेस्टेड ऑर्डर) | लागत |
|---|---|---|
| minify | 46.3% (केवल कच्चे बाइट्स) | पठनीयता गई; बिल्ड चरण चाहिए |
| gzip -6 | 94.5% | थोड़ा सर्वर CPU; लगभग शून्य कॉन्फ़िग |
| minify + gzip -6 | 95.4% | ऊपर के दोनों, जोड़े हुए |
| minify + brotli | 96.9% | HTTPS और brotli मॉड्यूल चाहिए; स्थिर संपत्तियाँ पहले से कम्प्रेस करें |
0 से 94.5% की छलांग gzip का काम है। 94.5% से 95.4% की छलांग - दस में से नौ पॉइंट - minify का है। यह तालिका तय करती है कि आपका प्रयास कहाँ लगना चाहिए।
5. कम्प्रेशन स्तर छिपा हुआ चर है
कोई भी तर्क जो एक निश्चित gzip स्तर मान लेता है, रेत पर खड़ा है, क्योंकि स्तर सीधे minify के सीमांत मूल्य को बदलता है:
| ट्रांसपोर्ट सेटिंग | minify अब भी जो अतिरिक्त बाइट्स बचाता है (नेस्टेड ऑर्डर) |
|---|---|
gzip -1 (Nginx gzip_comp_level डिफ़ॉल्ट) |
21.0% |
| gzip -6 (अधिकांश मानक लाइब्रेरी में डिफ़ॉल्ट) | 17.0% |
| gzip -9 | 8.9% |
| brotli (डिफ़ॉल्ट क्वालिटी) | 10.6% |
आपका ट्रांसपोर्ट कम्प्रेशन जितना कमज़ोर, minify उतना ही अधिक लाभ देता है। इससे एक व्यावहारिक नियम मिलता है: सामान्य Nginx इंस्टॉल पर जहाँ gzip_comp_level अब भी 1 है, minify आपको 21% देता है। एक बार 9 पर ट्यून करने या brotli पर स्विच करने के बाद, यह 9-11% रह जाता है और आप आम तौर पर इसे छोड़ सकते हैं।
किसी भी तरफ़ बहस करने से पहले, मापें कि आप वास्तव में किस स्तर पर हैं:
# एक ही प्रतिक्रिया को तीन Accept-Encoding मानों के साथ लाएँ और तुलना करें कि क्या आया
for enc in identity gzip br; do
size=$(curl -s -o /dev/null -w '%{size_download}' \
-H "Accept-Encoding: $enc" https://api.example.com/v1/orders)
echo "$enc -> $size bytes"
done
तीन संख्याएँ एक साथ तीन प्रश्नों का उत्तर देती हैं: कम्प्रेशन चालू है या नहीं, किस स्तर पर, और minify के लिए कितनी जगह बची है। यदि identity और gzip लगभग समान लौटते हैं, तो कम्प्रेशन बिल्कुल सक्रिय नहीं है - और ठीक करने वाली चीज़ Nginx है, आपकी JSON नहीं:
gzip on;
gzip_comp_level 6;
gzip_min_length 256; # छोटी प्रतिक्रियाएँ छोड़ें, वे केवल बढ़ती हैं
gzip_types application/json application/javascript text/css;
6. minify वास्तव में कब लाभ देता है
एक परीक्षण इसे तय करता है: क्या आपके द्वारा बचाए गए बाइट्स कहीं दर्ज होंगे, या आप किसी ऐसी सीमा से टकराएँगे जो कच्चे बाइट्स गिनती है? यदि हाँ, तो पूरा 46% मिलता है। यदि उत्तर "यह केवल वायर पर मौजूद है" है, तो इसका असली मूल्य 17% है।
पहला, HTTP अनुरोध बॉडी। अधिकांश सर्वर अनुरोध बॉडी को डीकम्प्रेस नहीं करते, और gzip लगभग विशेष रूप से प्रतिक्रियाओं के लिए कॉन्फ़िगर होता है। आप जो JSON POST करते हैं, उसका आम तौर पर कोई ट्रांसपोर्ट-परत संरक्षण नहीं होता, इसलिए minify की बचत पूरे दाम पर मिलती है। यही बात webhook कॉलबैक, MQTT टेलीमेट्री, और उन WebSocket फ़्रेमों पर लागू होती है जिन्होंने permessage-deflate पर बात नहीं की।
दूसरा, कठोर बाइट सीमा वाले चैनल - और उनमें से हर एक डिकोड किए गए बाइट्स गिनता है:
| चैनल | सीमा | क्या gzip मदद कर सकता है? |
|---|---|---|
| AWS Lambda सिंक्रोनस पेलोड | 6 MB | नहीं, डिकोडिंग के बाद मापा जाता है |
| Firestore एकल दस्तावेज़ | 1 MiB | नहीं |
| Kafka एकल संदेश (डिफ़ॉल्ट) | 1 MB | नहीं, ब्रोकर-साइड कम्प्रेशन एक अलग परत है |
| localStorage कोटा | ~5 MB (कैरेक्टरों में गिना) | नहीं |
| GET अनुरोध URL | सर्वर-निर्भर, 8 KB आम है | नहीं |
इस श्रेणी में minify अनुकूलन नहीं है, यह उस अनुरोध के बीच का अंतर है जो जमा होता है और उसके बीच जो विफल होता है। URL क्वेरी स्ट्रिंग में JSON एम्बेड करना सबसे तीखा मामला है: URL कभी कम्प्रेस नहीं होते और उनकी लंबाई सीमा होती है, इसलिए पहले minify करें, फिर तय करें कि base64 की ज़रूरत है या नहीं।
तीसरा, डिस्क या लॉग में लिखी गई JSON। लॉग और इंडेक्स शाब्दिक बाइट्स संग्रहित करते हैं जिनमें कोई ट्रांसपोर्ट परत शामिल नहीं होती। एक चेतावनी है जो लोगों को फँसाती है: minify तभी मदद करता है जब आप शुरू से pretty JSON लिख रहे थे। उस 200-पंक्ति लॉग नमूने ने केवल 4.1% बचाया, क्योंकि उसकी पंक्तियाँ पहले से कॉम्पैक्ट थीं और इंडेंटेशन फ़ाइल का लगभग कोई हिस्सा नहीं था। इसके विपरीत, यदि आपका लॉगर JSON.stringify(obj, null, 2) कॉल करता है, तो तीसरा आर्ग्युमेंट हटाना मुफ़्त का पैसा है।
एक आख़िरी टिप्पणी: जब कच्चे बाइट्स वाकई तंग हों, कुंजी नाम आम तौर पर इंडेंटेशन से बड़ा लीवर होते हैं। media-manifest.json पर, उसकी 14 अद्वितीय कुंजियों को k0 से k13 तक बदलने से minified रूप 21,222 B से 18,887 B हो जाता है - और 11.0%। कम्प्रेस करने पर, वह शेष बढ़त gzip -6 के तहत 2.4% और brotli के तहत 1.3% रह जाती है। तंत्र ऊपर के सब कुछ जैसा ही है: इंडेंटेशन और कुंजी नाम दोनों दोहराई गई संरचनात्मक जानकारी हैं, और कम्प्रेसर किसी भी तरह वही लाभांश लेता है।
7. चार स्थितियाँ जहाँ यह उल्टा पड़ता है
जिन फ़ाइलों को आप कमिट करते हैं उन्हें minify न करें। "qty": 2 को 3 में बदलें और pretty फ़ाइल git diff में एक साफ़ पंक्ति दिखाती है; minified फ़ाइल पूरी पंक्ति फिर से लिखती है, और सैकड़ों फ़ील्ड के साथ आप बदलाव ढूँढ ही नहीं पाएँगे। यह वही तंत्र है जो JSON मर्ज कॉन्फ़्लिक्ट कैसे सुलझाएँ में कवर है - diff टूल प्रति पंक्ति काम करते हैं, इसलिए एक-पंक्ति JSON हर संपादन को "पूरी पंक्ति भिन्न" बना देता है। रिपॉज़िटरी में pretty फ़ाइलें रखें और केवल बिल्ड आउटपुट में या स्टोरेज में लिखते समय minify करें।
छोटी प्रतिक्रियाएँ कम्प्रेस न करें। केवल {"ok": true} वाली प्रतिक्रिया इंडेंटेशन जोड़ने पर 16 बाइट है, और gzip -6 के बाद 36 बाइट - बीस बाइट बड़ी, क्योंकि gzip की अपनी डिक्शनरी और हेडर जगह घेरते हैं। यह सैद्धांतिक नहीं है; ठीक इसीलिए gzip_min_length मौजूद है। इसका Nginx डिफ़ॉल्ट 20 बाइट उत्पादन के लिए बहुत कम है, जहाँ 256 सामान्य न्यूनतम है।
तेज़ पार्सिंग की अपेक्षा न करें। उसी ऑर्डर सेट को 4,000 रिकॉर्ड तक बढ़ाने पर, pretty दस्तावेज़ 2,374,378 बाइट है जबकि minified 1,282,358 - 46% छोटा - फिर भी JSON.parse का माध्यिका समय केवल 5.7 ms से 5.0 ms तक जाता है, लगभग 12% तेज़। आकार आधा करने से समय आधा नहीं होता, क्योंकि पार्सर अपना अधिकांश बजट स्ट्रिंग्स काटने और संख्याएँ बदलने में खर्च करता है; व्हाइटस्पेस छोड़ना गौण है। पार्स लागत वास्तव में कुंजी गिनती और स्ट्रिंग सामग्री से तय होती है, जिसे बड़ी JSON फ़ाइलों का पार्सिंग, रेंडरिंग और स्ट्रीमिंग विस्तार से समझाता है।
इसे पहले से brotli या gzip -9 चला रही सेवा पर बाद में न जोड़ें। लाभ 9-11% तक गिर जाता है, जबकि लागत - डिबग करते समय पठनीयता का स्थायी नुकसान - बनी रहती है। इसके बजाय जाँचें कि gzip_types में application/json शामिल है या नहीं। बहुत सी साइटें gzip सक्षम करती हैं और केवल text/html कम्प्रेस करती हैं, JSON को पूरी तरह अकम्प्रेस्ड छोड़ देती हैं; उस स्थिति में minify पहला कदम नहीं है, अपना कॉन्फ़िग ठीक करना है।
8. निर्णय तालिका: कौन-सा कदम पहले
| आपकी स्थिति | पहले यह करें | minify का स्थान |
|---|---|---|
| कोई ट्रांसपोर्ट कम्प्रेशन नहीं | Nginx gzip_types कॉन्फ़िगर करें या CDN ऑटो-कम्प्रेशन सक्षम करें |
छोड़ें; लाभ का दस में से नौ वाष्पित हो जाता है |
| gzip -1 चल रहा है (Nginx डिफ़ॉल्ट) | gzip_comp_level को 6 करें |
दूसरा, 21% के लायक |
| पहले से brotli या gzip -9 पर | लंबी कुंजियाँ जाँचें, पेजिनेशन जोड़ें या फ़ील्ड ट्रिम करें | छोड़ें; केवल 9-11% बचा है |
| Lambda 6 MB या Firestore 1 MiB से टकराव | सीधे minify करें; पूरा 46% गिना जाता है | पहला |
| POST बॉडी, webhooks, MQTT | सीधे minify करें; ट्रांसपोर्ट यहाँ शायद ही लागू हो | पहला |
| Git में जाने वाली कॉन्फ़िग फ़ाइलें | उन्हें pretty रखें | केवल बिल्ड आउटपुट में |
| लॉग, टेलीमेट्री, ऑफ़लाइन डंप | अपने लॉगर में null, 2 आर्ग्युमेंट हटाएँ |
वही ही पहला कदम है |
एक वाक्य का नियम: देखें कि आप किस बाइट लेजर को छोटा करना चाह रहे हैं - स्थानीय रूप से दर्ज एक (डिस्क, कोटा, प्लेटफ़ॉर्म सीमा, अनुरोध बॉडी) या केवल वायर पर मौजूद एक। स्थानीय पहले का अर्थ minify है; केवल-वायर का अर्थ पहले brotli या gzip चालू करना।
व्यवहार में, पुष्टि करने के लिए ऊपर का curl लूप चलाएँ कि ट्रांसपोर्ट कम्प्रेशन सक्रिय है, फिर एक नमूना JSON Minify उपकरण से गुज़ारें और उसकी बचत संख्या पढ़ें। यदि वह संख्या 40% से ऊपर है जबकि curl identity और gzip को लगभग समान आकार पर बताता है, तो आपकी अड़चन सर्वर कॉन्फ़िगरेशन है, JSON नहीं। यदि दोनों curl संख्याएँ पहले से करीब हैं, तो इस दस्तावेज़ में देने को बहुत कम बचा है और इसके बजाय आपको फ़ील्ड ट्रिम करना या पेजिनेट करना चाहिए - जो JSON API कॉन्ट्रैक्ट डिज़ाइन के मूल बिंदु का विषय है।
क्या minified JSON अब भी वैध JSON है?
हाँ। minify केवल वह व्हाइटस्पेस हटाता है जिसकी RFC 8259 संरचनात्मक कैरेक्टरों के आसपास अनुमति देता है और स्ट्रिंग सामग्री को कभी नहीं छूता, इसलिए JSON.parse मूल के समान मान पैदा करता है। एकमात्र क्षति मानवीय पठनीयता है।
brotli या gzip?
उसी minified नमूने पर, brotli 96.9% बचाता है और gzip -6 95.4% - एक संकीर्ण अंतर। गतिशील प्रतिक्रियाओं के लिए CPU कम रखने हेतु gzip -6 का उपयोग करें, और brotli को HTTPS से दी जाने वाली स्थिर संपत्तियों के लिए रखें जिन्हें आप .br फ़ाइलों में पहले से कम्प्रेस कर सकते हैं।
मैंने अपनी JSON minify की लेकिन API तेज़ नहीं हुई। क्यों?
curl -sI से प्रतिक्रिया में Content-Encoding: gzip हेडर जाँचें। बहुत से Nginx सेटअप gzip_types को केवल text/html पर डिफ़ॉल्ट करते हैं, इसलिए JSON कभी कवर ही नहीं हुआ - और आपके 46% का पाँचवाँ हिस्से से भी कम वायर तक पहुँचा।
क्या कॉन्फ़िग फ़ाइलें minified रूप में कमिट की जानी चाहिए?
नहीं। Diff टूल पंक्ति-दर-पंक्ति तुलना करते हैं, इसलिए एक-पंक्ति JSON हर संपादन को "पूरी पंक्ति बदली" बना देता है, और कॉन्फ़्लिक्ट सुलझाने में आपके बचाए बाइट्स से कहीं अधिक खर्च होता है। रिपॉज़िटरी में pretty संस्करण रखें और बिल्ड समय पर minify करें।
gzip फ़ायदेमंद होने से पहले प्रतिक्रिया कितनी बड़ी होनी चाहिए?
सामान्य सीमा 256 बाइट से 1 KB है। {"ok": true} जितनी छोटी प्रतिक्रिया - इंडेंटेशन के साथ 16 बाइट - gzip -6 के तहत 36 बाइट हो जाती है, क्योंकि डिक्शनरी और हेडर उनकी वसूली से अधिक खर्च करते हैं। gzip_min_length ठीक यही नियंत्रित करता है।