हर बार वही फ़ाइल कंप्रेस करना

Apache हर जवाब को भेजते समय ही कंप्रेस करता है। जो पेज हर बार अलग होता है, उसके लिए यही एकमात्र विकल्प है। लेकिन महीने में एक बार बदलने वाली स्टाइलशीट के लिए इसका मतलब है कि सर्वर हफ़्तों तक हर विज़िटर के लिए वही काम दोबारा करता है और हर बार नतीजा फेंक देता है। इसके लिए कोई कैश नहीं है।

19 अगस्त 2026 को, पहले से खुले कनेक्शन पर, इसी वेबसाइट की अपनी फ़ाइलों style.css (124 kB) और world.js (102 kB) से मापा गया:

	समय	बाइट
बिना कंप्रेशन	2.9 ms	1,24,755
gzip, हर अनुरोध पर	18.1 ms	34,995
brotli, हर अनुरोध पर	14.5 ms	32,685
world.js, gzip	47.9 ms	38,283
world.js, brotli	15.9 ms	38,086

हर अनुरोध पर अड़तालीस मिलीसेकंड का CPU समय, बाइट-दर-बाइट एक जैसा नतीजा बनाने के लिए। छोटे सर्वर पर इसे नज़रअंदाज़ नहीं किया जा सकता।

एक बार कंप्रेशन, डिस्क पर

एक बिल्ड चरण कंप्रेस की हुई फ़ाइल को मूल फ़ाइल के बगल में लिख देता है, और जब ब्राउज़र बताता है कि वह gzip स्वीकार करता है, तो एक रीराइट नियम वही फ़ाइल भेज देता है। तैयार फ़ाइल भेजने की लागत उतनी ही है जितनी किसी भी फ़ाइल को भेजने की।

brotli के बजाय gzip, एक नीरस कारण से: इस मशीन पर brotli का कोई बाइनरी इंस्टॉल नहीं है। फ़ाइलें brotli की तुलना में लगभग 7% बड़ी बनती हैं, और सर्वर का समय उसका पाँचवाँ हिस्सा है जितना हर अनुरोध पर brotli में लगता है। किसी बेहतर जवाब का इंतज़ार करने के बजाय यह सौदा अभी कर लेना ठीक था।

वर्ज़न फ़ाइल के नाम में जाता है

बिल्ड यह फ़ाइल लिखता है: style.css.<mtime>.gz, और मार्कअप में मौजूद ?v= भी फ़ाइल में बदलाव का वही समय है। रीराइट सिर्फ़ तब चलता है, जब उसी नंबर वाली फ़ाइल मौजूद हो।

इस व्यवस्था में एक ऐसा गुण है, जिसे जान-बूझकर डिज़ाइन में शामिल करना चाहिए: अगर स्टाइलशीट बदल जाए और कोई दोबारा बिल्ड करना भूल जाए, तो मार्कअप का नंबर ऐसी फ़ाइल की ओर इशारा करता है जो मौजूद नहीं है, रीराइट नहीं चलता, और Apache मूल फ़ाइल को सामान्य तरीके से भेज देता है। सबसे बुरी स्थिति यह है कि रफ़्तार का फ़ायदा नहीं मिलता। पुरानी स्टाइलशीट बाहर नहीं जा सकती। हर कैशिंग व्यवस्था को इस सवाल पर परखना चाहिए — जब कुछ गड़बड़ होती है, तो वह धीमी होती है या गलत?

बीच में छिपा बग

भेजी जा रही फ़ाइल पहले से gzip है, इसलिए बाहर जाते समय उसे दोबारा कंप्रेस नहीं किया जाना चाहिए। कॉन्फ़िगरेशन में शुरू में यह सेट किया गया था: no-gzip, जो Apache के दो कंप्रेसरों में से एक को रोकता है। दूसरा, mod_brotli, तैयार gzip फ़ाइल को मज़े से brotli से कंप्रेस करता रहा, जबकि जवाब का हेडर लगातार यही कहता रहा: gzip।

ब्राउज़रों को ऐसा कंटेंट मिला जिसे पढ़ा नहीं जा सकता था। यह पेज देखकर पकड़ में नहीं आया — यह बाइट जोड़ने पर पकड़ा गया, जब एक ऐसी संख्या सामने आई जिसका कोई मतलब नहीं बनता था। no-gzip और no-brotli दोनों ज़रूरी हैं, और इनमें से सिर्फ़ एक ही ऐसा है जो आसानी से सूझता है।