ভুল ক্রমে JSON কম্প্রেশন বন্ধ করুন: minify বনাম gzip বনাম brotli, মাপা ফল

মূল কথা: প্রথমে স্থানান্তর কম্প্রেশনকে কাঠামোগত ছাঁটাই থেকে আলাদা করুন। gzip বা brotli এখনও চালু না থাকলে সার্ভার কনফিগ ঠিক করুন — কেবল gzip -6 দিয়েই ৯৪.৫% পৌঁছে যায় আর মিনিফাইয়ের মূল্য থাকে মাত্র ০.৯ পয়েন্ট। মিনিফাইয়ের পূর্ণ ৪৬.৩% কাজে লাগে কেবল যখন বাইটের বিল স্থানীয়ভাবে রেকর্ড হয়: রিকোয়েস্ট বডি, Lambda-র ৬ MB, Firestore-এর ১ MiB, বা ডিস্কে ও লগে লেখা JSON।

আপনার প্রিয় মিনিফায়ারে "৩৫% সাশ্রয়" ব্যাজটি সৎ — এটি কাঁচা বাইট মাপে। আপনার API gzip বা brotli-র উপর চলে, আর ওই দুটো ঠিক একই পুনরাবৃত্তি খেয়ে ফেলে। দুই সংখ্যা গুণ করলে ভুল উত্তর পাবেন।

১. "কম্প্রেশন"-কে দুই আলাদা জিনিসে ভাগ করুন

যাকে মানুষ JSON কম্প্রেশন বলে তা আসলে দুটি অসম্পর্কিত ক্রিয়া, আর এই গুলিয়ে ফেলাই প্রতিটি ভুল সিদ্ধান্তের শুরু।

শেষ দুই সারি মূল। প্ল্যাটফর্মের সীমা ডিকোডের পর মাপা হয়: AWS Lambda-র ৬ MB পেললোড ক্যাপ, Firestore-এর প্রতি-ডকুমেন্ট ১ MiB ক্যাপ। gzip চালু করলে সেখানে এক বাইটও বাঁচে না, কারণ দুইটিই ডিকোড করা ফল গোনে।

২. minify ঠিক একটি জিনিসই সরায়: কাঠামোগত হোয়াইটস্পেস

RFC 8259 যেকোনো কাঠামোগত অক্ষরের চারপাশে হোয়াইটস্পেস (space, \t, \n, \r) অনুমোদন করে। JSON ডকুমেন্টে আর কিছুই ঐচ্ছিক নয়: কি-নাম ডেটা, সংখ্যা প্রতিটি অঙ্ক রাখে, আর স্ট্রিংয়ের কন্টেন্ট বাইট-প্রতি-বাইট অপরিবর্তনীয়।

তাই পুরো কাজটি এক লাইন:

复制const minified = JSON.stringify(JSON.parse(pretty));
// RFC 8259 allows whitespace only around structural characters,
// so spaces inside a string are data, not formatting
JSON.stringify(JSON.parse('{"note": "two spaces"}'));
// {"note":"two spaces"} - both inner spaces are preserved

উল্লেখের যোগ্য তিনটি ক্রিয়া যা "কম্প্রেশন"-এর খাতায় পড়ে কিন্তু আসলে ডকুমেন্ট বদলায়: null মানের কি ফেলে দেওয়া, ফ্লোট রাউন্ড করা, আর কি-এর ক্রম বদলানো। এগুলো পুনঃফরম্যাট নয়, ডকুমেন্ট বদলায়, তাই "গভীর কম্প্রেশন" বিজ্ঞাপন দেওয়া যেকোনো টুল চালু করার আগে আপনার ভোক্তার অনুমোদন দরকার।

মিনিফাই কেবল হোয়াইটস্পেস সরায়, তাই এর লাভ প্রায় পুরোটাই নির্ভর করে আপনার ফাইলের কত অংশ ইনডেন্টেশন তার উপর। নিচের টেবিলগুলোতে এটি বারবার দেখা যাবে।

৩. পরিমাপ: চার ডকুমেন্ট, তিন gzip স্তর, প্লাস brotli

পরিবেশ: Node v22.13.1, স্তর ১ / ৬ / ৯-এ zlib.gzipSync, ডিফল্ট কোয়ালিটিতে (১১) brotliCompressSync। চারটি নমুনা সচেতনভাবেই আপনি বাস্তবে পাঠানো আকৃতিগুলো ঢাকে: ৫০টি নেস্টেড অর্ডার (গভীর কাঠামো, পুনরাবৃত্ত কি), ৬-স্তরের কনফিগ (দীর্ঘ কি, খাটো মান), ২০০-লাইনের লগ অ্যারে (দীর্ঘ স্ট্রিং, প্রায় কোনো ইনডেন্টেশন নেই), এবং এই সাইটের বাস্তব media-manifest.json (মিশ্র আকৃতি, URL-প্রধান স্ট্রিং)।

ধাপ এক: কাঁচা বাইট।

"৩৫% সাশ্রয়" ব্যাজ এখান থেকেই আসে, আর এটি মিথ্যা বলছে না। সমস্যা দেখা দেয় ধাপ দুইয়ে।

ধাপ দুই: প্রতিটি সংস্করণ কম্প্রেস করুন, তারপর জিজ্ঞাসা করুন মিনিফাই এখনও কতটা যোগ করে।

যে নেস্টেড অর্ডার ডকুমেন্ট কাঁচা বাইটের ৪৬.৩% হারায়, gzip -6 চালু হলেই তার মধ্যে কেবল ১৭.০% টিকে থাকে। লগ অ্যারে সরাসরি ঋণাত্মক হয়: মিনিফাই-তারপর-কম্প্রেস প্রিটি মূল কম্প্রেস করার চেয়ে সামান্য বড়। ঋণাত্মক কোনো বাগ নয়, এটাই আপনার প্রত্যাশা করা উচিত, আর পরের অংশে কারণ ব্যাখ্যা করা হয়েছে।

ধাপ তিন: মূল প্রিটি ডকুমেন্টের বিপরীতে মোট হ্রাস — এই সংখ্যাটাই আসলে তারে যায়।

৪. gzip কেন minify-র কৃতিত্ব খেয়ে ফেলে

gzip হলো LZ77-এর পর Huffman কোডিং। LZ77-এর মূল কৌশল "৩২ KB উইন্ডোতে পিছনে তাকাও, পুনরাবৃত্ত ক্রম খোঁজো, (দূরত্ব, দৈর্ঘ্য) পয়েন্টার দিয়ে প্রতিস্থাপন করো।" ইনডেন্টেশন ওই কৌশলের সবচেয়ে সহজ লক্ষ্য: প্রতিটি নেস্টিং স্তর একই স্পেস-সিরিজ উৎপন্ন করে, আর ডজন ডজন পাশাপাশি লাইন একই সমন্বয় পুনরাবৃত্তি করে। Huffman তারপর উচ্চ-কম্পাঙ্কের চিহ্নকে ছোট কোড দেয়, তাই \n প্লাস আট স্পেসের মতো ক্রম — যা একটি ফাইলে হাজারবার ফিরে আসতে পারে — শেষে দুই-তিন বিটে পড়ে।

তাই মিনিফাই যে বাইট মোছে তা ঠিক সেই বাইটগুলো যা কম্প্রেসর প্রায় বিনা খরচে চেপে দিত। নিজে করলে কম্প্রেসর ইতিমধ্যে যেটি সবচেয়ে ভালো করে তা আবার করছেন, আর আপনার ৪৬% নেমে আসে ১৭%-এ। উপরের টেবিলের পেছনের পুরো কাহিনি এটাই।

ঋণাত্মক লগ-অ্যারে ফলের আলাদা ব্যাখ্যা দরকার। সেই নমুনা প্রায় পুরোটাই দীর্ঘ স্ট্রিং (লগ লাইন, URL, base64), মানে কম পুনরাবৃত্তি ও উচ্চ এনট্রপি — কম্প্রেসরের সরানোর জন্য সামান্য পুনরাবৃত্ততাই আছে। প্রিটি সংস্করণের নিউলাইনগুলো দৈবক্রমে ম্যাচারের স্থিতিশীল সীমানা দেয়। সেগুলো সরালে LZ77 সেই নোঙর হারায়: এই নমুনায় gzip -1-এ প্রিটি মূল কম্প্রেস করলে ১,৫০৮ বাইট, আর মিনিফাই-তারপর-কম্প্রেস করলে ১,৫১৮ বাইট। দশ বাইট খারাপ।

মাত্রা অনুযায়ী সাজালে লিভারগুলো এরকম দাঁড়ায়:

০ থেকে ৯৪.৫%-এ লাফ gzip-এর কাজ। ৯৪.৫% থেকে ৯৫.৪%-এ লাফ — নয় দশমিক এক পয়েন্ট — মিনিফাইয়ের। এই টেবিলই ঠিক করে আপনার পরিশ্রম কোথায় যাওয়া উচিত।

৫. কম্প্রেশন স্তর লুকানো চলক

একটি নির্দিষ্ট gzip স্তর ধরে নেওয়া যেকোনো যুক্তি বালির উপর দাঁড়ানো, কারণ স্তরটি সরাসরি মিনিফাইয়ের প্রান্তিক মূল্য বদলায়:

আপনার পরিবহন কম্প্রেশন যত দুর্বল, মিনিফাই তত লাভজনক। এখান থেকে ব্যবহারিক নিয়ম: স্টক Nginx ইনস্টলে যেখানে gzip_comp_level এখনও ১, মিনিফাই ২১% দেয়। ৯-এ টিউন বা brotli-তে সরানোর পর তা ৯–১১%-এ নেমে আসে আর সাধারণত বাদ দিতে পারেন।

যুক্তি দেওয়ার আগে মাপুন আপনি আসলে কোন স্তরে:

复制# Fetch the same response with three Accept-Encoding values and compare what landed
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

তিনটি সংখ্যা একসঙ্গে তিনটি প্রশ্নের উত্তর দেয়: কম্প্রেশন আদৌ চালু কি না, কোন স্তরে, আর মিনিফাইয়ের জন্য কত জায়গা বাকি। identity ও gzip প্রায় একই ফিরে এলে কম্প্রেশন একেবারেই সক্রিয় নয় — আর ঠিক করার জিনিস Nginx, আপনার JSON নয়:

复制gzip on;
gzip_comp_level 6;
gzip_min_length 256;      # skip tiny responses, they only grow
gzip_types application/json application/javascript text/css;

৬. কখন মিনিফাই সত্যিই লাভজনক

একটি পরীক্ষাই ঠিক করে: আপনার বাঁচানো বাইট কি কোথাও রেকর্ড হবে, না কি কাঁচা বাইট গোনা এমন সীমায় পৌঁছাবেন? হ্যাঁ হলে পূর্ণ ৪৬% কাজে লাগে। উত্তর যদি "এটি কেবল তারে থাকে" হয়, তাহলে ১৭% এর প্রকৃত মূল্য।

প্রথমত, HTTP রিকোয়েস্ট বডি। বেশিরভাগ সার্ভার রিকোয়েস্ট বডি ডিকম্প্রেস করে না, আর gzip প্রায় একচেটিয়াভাবে রেসপন্সের জন্য কনফিগ করা হয়। আপনি POST করা JSON-এ সাধারণত কোনো পরিবহন-স্তরের সুরক্ষা নেই, তাই মিনিফাইয়ের সাশ্রয় পূর্ণ দামে আসে। একই কথা webhook কলব্যাক, MQTT টেলিমেট্রি, এবং permessage-deflate নিয়ে আলোচনা হয়নি এমন WebSocket ফ্রেমে।

দ্বিতীয়ত, কঠোর বাইট সিলিংযুক্ত চ্যানেল — আর তাদের প্রত্যেকটি ডিকোড করা বাইট গোনে:

এই শ্রেণিতে মিনিফাই অপ্টিমাইজেশন নয়, বরং একটি সফল রিকোয়েস্ট আর একটি ব্যর্থ রিকোয়েস্টের পার্থক্য। URL কোয়েরি স্ট্রিংয়ে JSON ঢোকানো সবচেয়ে তীক্ষ্ণ ক্ষেত্র: URL কখনো কম্প্রেস হয় না আর এর দৈর্ঘ্য ক্যাপ আছে, তাই আগে মিনিফাই করুন, তারপর ভাবুন base64 আদৌ দরকার কি না।

তৃতীয়ত, ডিস্ক বা লগে লেখা JSON। লগ ও ইনডেক্স আক্ষরিক বাইট রাখে, কোনো পরিবহন স্তর নেই। একটি সতর্কতা মানুষকে পা পিছলায়: মিনিফাই কেবল সাহায্য করে যদি আপনি শুরু থেকেই প্রিটি JSON লিখতেন। সেই ২০০-লাইনের লগ নমুনা মাত্র ৪.১% বাঁচায়, কারণ এর লাইনগুলো আগেই কম্প্যাক্ট ছিল আর ইনডেন্টেশন ফাইলের প্রায় শূন্য অংশ। উল্টো, আপনার লগার যদি JSON.stringify(obj, null, 2) কল করে, তৃতীয় আর্গুমেন্ট বাদ দেওয়াই বিনা খরচের লাভ।

শেষ নোট: কাঁচা বাইট সত্যিই টান হলে, কি-নাম সাধারণত ইনডেন্টেশনের চেয়ে বড় লিভার। media-manifest.json-এ এর ১৪টি অনন্য কি k0 থেকে k13 দিয়ে বদলালে মিনিফাইড রূপ ২১,২২২ B থেকে ১৮,৮৮৭ B-এ নামে — আরও ১১.০%। কম্প্রেস করলে সেই অবশিষ্ট প্রান্ত gzip -6-এ ২.৪% ও brotli-তে ১.৩%-এ সংকুচিত হয়। উপরের সবকিছুর মতো একই কার্যপদ্ধতি: ইনডেন্টেশন ও কি-নাম — দুটোই পুনরাবৃত্ত কাঠামোগত তথ্য, আর কম্প্রেসর দুই ক্ষেত্রেই একই লাভ দাবি করে।

৭. চার ক্ষেত্র যেখানে এটি উল্টো ফল দেয়

আপনি যেসব ফাইল কমিট করেন সেগুলো মিনিফাই করবেন না। "qty": 2-কে ৩ করুন — প্রিটি ফাইলে git diff-এ একটি পরিচ্ছন্ন লাইন দেখায়; মিনিফাইড ফাইলে পুরো লাইন আবার লেখা হয়, আর শত শত ফিল্ডে পরিবর্তনটি একেবারেই খুঁজে পাবেন না। এটি JSON মার্জ কনফ্লিক্ট কীভাবে মেটাবেন-এ বর্ণিত একই কার্যপদ্ধতি — ডিফ টুল লাইন ধরে কাজ করে, তাই এক-লাইনের JSON প্রতিটি সম্পাদনাকে "পুরো লাইন আলাদা" বানায়। রিপোজিটরিতে প্রিটি ফাইল রাখুন আর কেবল বিল্ড আউটপুটে বা স্টোরেজে লেখার সময় মিনিফাই করুন।

অতি ছোট রেসপন্স কম্প্রেস করবেন না। কেবল {"ok": true} ধারণকারী রেসপন্স ইনডেন্টেশন যোগ করলে ১৬ বাইট, আর gzip -6-এর পর ৩৬ বাইট — বিশ বাইট বড়, কারণ gzip-এর নিজের ডিকশনারি ও হেডার জায়গা নেয়। এটি তাত্ত্বিক নয়; এজন্যই gzip_min_length আছে। এর Nginx ডিফল্ট ২০ বাইট প্রোডাকশনের জন্য অনেক কম, যেখানে সাধারণত ২৫৬ তলানি।

দ্রুততর পার্সিং প্রত্যাশা করবেন না। একই অর্ডার সেট ৪,০০০ রেকর্ডে স্কেল করলে প্রিটি ডকুমেন্ট ২,৩৭৪,৩৭৮ বাইট বনাম মিনিফাইড ১,২৮২,৩৫৮ — ৪৬% ছোট — তবু মধ্যমা JSON.parse সময় কেবল ৫.৭ ms থেকে ৫.০ ms-এ সরে, প্রায় ১২% দ্রুত। আকার অর্ধেক করলে সময় অর্ধেক হয় না, কারণ পার্সার তার বাজেটের বেশিরভাগ খরচ করে স্ট্রিং কাটা ও সংখ্যা রূপান্তরে; হোয়াইটস্পেস এড়ানো প্রাসঙ্গিক মাত্র। পার্স খরচ আসলে চালায় কি-সংখ্যা ও স্ট্রিং-কন্টেন্ট, যা বড় JSON ফাইল পার্সিং, রেন্ডারিং ও স্ট্রিমিং-এ বিস্তারিত ভাঙা হয়েছে।

brotli বা gzip -9 ইতিমধ্যে চলা সার্ভিসে এটি পরে বসাবেন না। লাভ ৯–১১%-এ নামে, অথচ খরচ — ডিবাগের সময় পাঠযোগ্যতার স্থায়ী ক্ষতি — থেকে যায়। এর বদলে দেখুন gzip_types আদৌ application/json ঢাকে কি না। অনেক সাইট gzip চালু করে কেবল text/html কম্প্রেস করে, JSON সম্পূর্ণ অকম্প্রেসড রেখে; সেই অবস্থায় মিনিফাই ধাপ এক নয়, আপনার কনফিগ ঠিক করাই ধাপ এক।

৮. সিদ্ধান্ত টেবিল: কোন ধাপ আগে

এক-বাক্যের নিয়ম: দেখুন আপনি কোন বাইট খাতা ছোট করতে চান — স্থানীয়ভাবে রেকর্ড হওয়া একটি (ডিস্ক, কোটা, প্ল্যাটফর্ম সীমা, রিকোয়েস্ট বডি) নাকি কেবল তারে থাকা একটি। স্থানীয় হলে আগে মিনিফাই; কেবল-তার হলে আগে brotli বা gzip চালু করুন।

অনুশীলনে উপরের curl লুপ চালিয়ে নিশ্চিত করুন পরিবহন কম্প্রেশন চালু, তারপর একটি নমুনা JSON মিনিফাই টুল-এ ঢুকিয়ে তার সাশ্রয় সংখ্যা পড়ুন। সংখ্যাটি ৪০%-এর উপরে অথচ curl identity ও gzip-কে প্রায় সমান আকার জানায়, তাহলে আপনার bottleneck সার্ভার কনফিগ, JSON নয়। দুই curl সংখ্যা ইতিমধ্যে কাছাকাছি হলে এই নথির দেওয়ার আর বেশি কিছু নেই, বরং ফিল্ড ছাঁটা বা পেজিনেট করা উচিত — যা JSON API চুক্তি নকশার মূল বিষয়-এর বিষয়।

মিনিফাইড JSON কি এখনও বৈধ JSON?

হ্যাঁ। মিনিফাই কেবল RFC 8259 যে হোয়াইটস্পেস কাঠামোগত অক্ষরের চারপাশে অনুমোদন করে তা সরায় আর স্ট্রিং-কন্টেন্ট কখনো ছোঁয় না, তাই JSON.parse মূলের সমান মান দেয়। একমাত্র ক্ষতি মানুষের পাঠযোগ্যতা।

brotli নাকি gzip?

একই মিনিফাইড নমুনায় brotli ৯৬.৯% বাঁচায় আর gzip -6 ৯৫.৪% — ব্যবধান সংকীর্ণ। ডাইনামিক রেসপন্সে CPU কম রাখতে gzip -6 ব্যবহার করুন, আর brotli রাখুন HTTPS-এ দেওয়া স্ট্যাটিক অ্যাসেটের জন্য যা আপনি .br ফাইলে আগেই কম্প্রেস করতে পারেন।

আমি JSON মিনিফাই করেছি কিন্তু API দ্রুত হয়নি কেন?

curl -sI দিয়ে রেসপন্সে Content-Encoding: gzip হেডার আছে কি না দেখুন। অনেক Nginx সেটআপে gzip_types ডিফল্টে কেবল text/html, তাই JSON কখনো ঢাকা পড়েনি — আর আপনার ৪৬%-এর এক-পঞ্চমাংশেরও কম তারে পৌঁছেছে।

কনফিগ ফাইল কি মিনিফাই করে কমিট করা উচিত?

না। ডিফ টুল লাইন ধরে তুলনা করে, তাই এক-লাইনের JSON প্রতিটি সম্পাদনাকে "পুরো লাইন বদলেছে" বানায়, আর কনফ্লিক্ট মেটানোর খরচ বাঁচানো বাইটের চেয়ে অনেক বেশি। রিপোজিটরিতে প্রিটি সংস্করণ রাখুন আর বিল্ডের সময় মিনিফাই করুন।

gzip লাভজনক হতে রেসপন্স কত বড় হওয়া উচিত?

সাধারণ থ্রেশহোল্ড ২৫৬ বাইট থেকে ১ KB। {"ok": true}-এর মতো ছোট রেসপন্স — ইনডেন্টেশনসহ ১৬ বাইট — gzip -6-এ ৩৬ বাইটে বাড়ে, কারণ ডিকশনারি ও হেডার যা পুনরুদ্ধার করে তার চেয়ে বেশি খরচ করে। এটাই gzip_min_length নিয়ন্ত্রণ করে।