रिस्पॉन्स साइज़ एनालाइज़र

सर्वर सहायता परफ़ॉर्मेंस

कोई सार्वजनिक URL fetch करें या बॉडी चिपकाएँ और transfer साइज़, gzip/brotli अनुमान, हेडर का बोझ तथा यह देखें कि कौन-से JSON फ़ील्ड सबसे ज़्यादा बाइट लेते हैं।

गोपनीयता: जहाँ संभव हो प्रोसेसिंग आपके ब्राउज़र में होती है। नेटवर्क जाँच मुत्क़न बैकएंड के माध्यम से की जाती है और संग्रहीत नहीं की जाती।

रिस्पॉन्स साइज़ एनालाइज़र कैसे इस्तेमाल करें

  1. स्रोत चुनें: रिस्पॉन्स बॉडी चिपकाएँ (जो आपके ब्राउज़र में ही रहती है) या कोई सार्वजनिक URL डालें।
  2. चाहें तो रिस्पॉन्स हेडर भी चिपकाएँ, ताकि हेडर का बोझ और Content-Type शामिल हो जाए।
  3. "Analyze" दबाकर कच्चा, minified, gzip और brotli साइज़ साथ-साथ देखें।
  4. "सबसे बड़े JSON फ़ील्ड" खोलकर वे प्रॉपर्टी ढूँढें जिन्हें छाँटना या पेजिनेट करना फ़ायदेमंद है।
  5. सुझाव लागू करें (compression, minification, sparse fieldset) और दोबारा जाँचें।

रिस्पॉन्स साइज़ एनालाइज़र की खूबियाँ

  • बॉडी को निजी तौर पर चिपकाएँ, या relay के ज़रिये कोई सार्वजनिक URL fetch करें
  • कच्चे बाइट, अक्षर, हेडर का बोझ और कुल transfer साइज़
  • बाइट एन्ट्रॉपी और दोहराव से gzip तथा brotli साइज़ के अनुमान (कुछ भी अपलोड किए बिना)
  • JSON ढाँचे का भार: minified साइज़, whitespace का हिस्सा, key की संख्या और गहराई
  • उन JSON फ़ील्ड की रैंकिंग जो सबसे ज़्यादा बाइट जोड़ते हैं
  • काम के सुझाव: compression चालू करें, minify करें, पेजिनेट करें या फ़ील्ड कम करें

रिस्पॉन्स साइज़ एनालाइज़र का उदाहरण

सुंदर ढंग से फ़ॉर्मेट की गई product सूची

इनपुट:

{
  "data": [ { "id": 1, "name": "Sample product 1", "description": "…" }, … ],
  "meta": { "page": 1, "total": 6 }
}

आउटपुट:

Body: 3.9 KB · Headers: 142 B · Total: 4.0 KB
gzip (est.): 1.1 KB (72% smaller) · brotli (est.): 0.9 KB
JSON minified: 3.1 KB (20% whitespace)
Largest fields: data 97% · data[0].description 15% · data[0].images 8%

रिस्पॉन्स साइज़ एनालाइज़र के बारे में अक्सर पूछे जाने वाले सवाल

gzip साइज़ का अनुमान कैसे लगता है?

स्थानीय रूप से, बॉडी की बाइट एन्ट्रॉपी और उसमें मौजूद दोहराव से — ब्राउज़र में कोई compressor नहीं चलता। असली gzip/brotli नतीजे आमतौर पर इस अनुमान के ±15% के भीतर रहते हैं।

हेडर का बोझ किसे गिना जाता है?

हर हेडर पंक्ति ("Name: value" और CRLF)। बड़ी cookie और लंबे कस्टम हेडर हर रिक्वेस्ट व रिस्पॉन्स के साथ जाते हैं, इसलिए 2 KB की JSON बॉडी पर 4 KB का हेडर ब्लॉक ठीक करने लायक़ है।

सबसे बड़े JSON फ़ील्ड कैसे चुने जाते हैं?

टूल हर प्रॉपर्टी को serialise करके UTF-8 बाइट के हिसाब से रैंक करता है, जिसमें नेस्टेड पाथ और ऐरे के शुरुआती आइटम भी शामिल हैं, ताकि आप देख सकें कि पेलोड पर किन फ़ील्ड का दबदबा है।

क्या fetch मोड compressed बॉडी डाउनलोड करता है या कच्ची?

relay identity encoding माँगता है ताकि कच्चा साइज़ मापा जा सके; origin का Content-Encoding हेडर बताता है कि वह सामान्य रूप से compression करता है या नहीं।

क्या मेरी चिपकाई हुई बॉडी कहीं अपलोड होती है?

नहीं। paste मोड पूरी तरह आपके ब्राउज़र में चलता है; सिर्फ़ fetch मोड में URL relay को भेजा जाता है।

तकनीकी नोट्स

compression का अनुमान बॉडी की order-0 Shannon एन्ट्रॉपी और दोहराई गई 8-अक्षरी विंडो के हिस्से को मिलाकर लगाया जाता है, जो LZ77 back-reference का सस्ता अनुमान है। यह गणना नियतात्मक है, पहले 256 KB पर चलती है और फिर पूरी लंबाई के अनुपात में बढ़ा दी जाती है।

फ़ील्ड का भार हर प्रॉपर्टी को JSON.stringify से serialise करके UTF-8 बाइट गिनकर निकाला जाता है, जिसमें key और separator भी शामिल हैं। ऐरे को पूरा एक इकाई मानकर मापा जाता है और नेस्टेड पाथ के लिए उनके पहले 20 ऑब्जेक्ट आइटम खंगाले जाते हैं।