फ़ाइल प्रोसेस करते समय ब्राउज़र की मेमोरी सीमाएँ

मेरी फ़ाइल तो सिर्फ़ 15 MB की है। फिर टैब की मेमोरी फुल क्यों हो गई?

5 मिनट का पठन · 17 अगस्त 2026 को समीक्षित

डिस्क पर पड़ी फ़ाइल कम्प्रेस्ड रूप होती है

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

गणित सीधा है। मेमोरी में एक पिक्सेल आम तौर पर चार बाइट का होता है — रेड, ग्रीन, ब्लू और अल्फ़ा। 4000 × 3000 की तस्वीर में 1.2 करोड़ पिक्सेल होते हैं, यानी डीकोड की गई बिटमैप करीब 48 MB की। जिस JPEG से वह आई थी वह शायद 4 MB का रहा होगा। काम शुरू होने से पहले ही फ़ाइल बारह गुना बड़ी हो चुकी थी।

और एक कॉपी से कभी काम नहीं चलता

एक असल पाइपलाइन एक साथ कई कॉपियाँ पकड़े रखती है: कम्प्रेस्ड इनपुट बाइट, डीकोड की गई सोर्स बिटमैप, नए डाइमेंशन वाली आउटपुट बिटमैप, एन्कोडर के अंदरूनी बफ़र, और कम्प्रेस्ड नतीजा। जो टूल साथ में प्रीव्यू भी दिखाता है वह एक और कॉपी रखता है। ऊपर वाली 4000 × 3000 तस्वीर के लिए दो से तीन सौ मेगाबाइट का पीक वर्किंग सेट बिल्कुल आम बात है — उस फ़ाइल के लिए जो देखने में 4 MB की थी।

PDF रास्टराइज़ेशन पन्ना-दर-पन्ना ठीक ऐसा ही करता है: 300 DPI पर रेंडर किया गया A4 पन्ना करीब 2480 × 3508 पिक्सेल का होता है, यानी डीकोड होने पर करीब 35 MB, और जो टूल एक साथ कई पन्ने रेंडर करता है वह इसे उतने ही गुना कर देता है। वीडियो इससे भी भारी पड़ता है, क्योंकि डीकोडर को एक ही समय कई रेफ़रेंस फ़्रेम मेमोरी में रखने पड़ते हैं।

असली सीमाएँ कहाँ हैं

• किसी टैब का मेमोरी बजट ब्राउज़र तय करता है, साइट नहीं, और वह मशीन में लगी कुल मेमोरी से कम होता है। दूसरे टैब व्यस्त हों तो यह और घट जाता है।
• आम 32-बिट मेमोरी मॉडल के लिए बने WebAssembly मॉड्यूल ज़्यादा से ज़्यादा चार गिबीबाइट एड्रेस कर सकते हैं, और ब्राउज़र अक्सर हर इंस्टेंस को इससे काफ़ी कम देते हैं।
• हर अलग बफ़र की अपनी अधिकतम लंबाई होती है, जो किसी पेज को मिल सकने वाली कुल मेमोरी से कहीं कम है।
• मोबाइल ऑपरेटिंग सिस्टम हद से ज़्यादा बड़े हो चुके टैब को बंद कर देते हैं — बिना किसी चेतावनी के, और बिना कोई ऐसी एरर दिए जिसे पेज पकड़ सके।
• ग्राफ़िक्स मेमोरी एक अलग और छोटा पूल है। प्लेटफ़ॉर्म की अधिकतम डाइमेंशन से बड़ा Canvas बस फ़ेल हो जाता है, चाहे सिस्टम मेमोरी कितनी भी खाली हो।

इनमें से कोई भी सीमा एक ऐसे नंबर के रूप में प्रकाशित नहीं होती जिसे आप देखकर पता कर लें, क्योंकि ये ब्राउज़र, उसके वर्ज़न, डिवाइस और बाकी चल रही चीज़ों पर निर्भर करती हैं। असली दिक्कत यही है: कोई टूल यह पूछ ही नहीं सकता कि उसे कितनी मेमोरी इस्तेमाल करने की इजाज़त है।

फ़ोन सबसे सख़्त मामला क्यों हैं

फ़ोन में फ़िज़िकल मेमोरी कम होती है, डेस्कटॉप जैसा स्वैप नहीं होता, और ऑपरेटिंग सिस्टम बैकग्राउंड प्रोसेस से मेमोरी वापस छीनने में बहुत आक्रामक रहता है। जिस पल आप किसी मैसेज का जवाब देने लगते हैं, ब्राउज़र टैब बैकग्राउंड प्रोसेस बन जाता है। इसीलिए मोबाइल ब्राउज़र और सख़्त बजट रखते हैं और टैब को जल्दी हटा देते हैं, और यह हटना आपको एरर की तरह नहीं, बल्कि पेज के रीलोड होकर आपका काम गँवा देने की तरह दिखता है।

इसका व्यावहारिक नतीजा यह है कि जो काम लैपटॉप पर पूरा हो जाता है, वही उसी फ़ाइल के साथ फ़ोन पर नामुमकिन हो सकता है। यह टूल की खराबी नहीं है। यह हार्डवेयर की सीमा है, और ईमानदार जवाब यही है कि आधे रास्ते क्रैश होने के बजाय शुरू करने से पहले ही इसे बता दिया जाए।

एक सावधान टूल कैसा बर्ताव करता है

• कुछ भी अलॉट करने से पहले वह डीकोडेड डाइमेंशन से वर्किंग सेट का अनुमान लगाता है, और जो काम साफ़ तौर पर नहीं समाएगा उससे मना कर देता है।
• सीमित क्षमता वाले डिवाइस पर वह पूरा बैच समानांतर चलाने के बजाय एक बार में एक ही फ़ाइल प्रोसेस करता है।
• वह पेज और उसके वर्कर के बीच बफ़र कॉपी करने के बजाय ट्रांसफ़र करता है, ताकि बड़ी फ़ाइल मेमोरी में दो बार मौजूद न रहे।
• हर नतीजा लिखे जाते ही वह उसे रिलीज़ कर देता है, और उन अस्थायी URL को रद्द कर देता है जो वरना डेटा को ज़िंदा रखते।
• जहाँ फ़ॉर्मैट इजाज़त देता है, वह पूरे डॉक्यूमेंट को मेमोरी में लादने के बजाय पन्ना-दर-पन्ना या फ़्रेम-दर-फ़्रेम स्ट्रीम करता है।
• वह जितने पिक्सेल स्वीकार करेगा उस पर सीमा लगाता है, और यही चीज़ ऐसी छोटी फ़ाइल को टैब गिराने से रोकती है जो फैलकर विशाल Canvas बन जाती है।

काम फ़ेल हो जाए तो आप क्या कर सकते हैं

• बाकी टैब बंद करें। वे उसी बजट के लिए होड़ कर रहे हैं, और ब्राउज़र उसे बराबरी से नहीं बाँटते।
• एक बार में कम फ़ाइलें प्रोसेस करें। एक-एक की कतार धीमी ज़रूर है, पर पूरी होने की संभावना कहीं ज़्यादा।
• पहले डाइमेंशन घटाएँ। सबसे लंबे किनारे को आधा करने पर वर्किंग सेट एक-चौथाई रह जाता है, और अक्सर आपको यही चाहिए भी था।
• बड़े PDF को बाँटें और उसके हिस्सों को अलग-अलग प्रोसेस करें।
• सबसे बड़े कामों के लिए डेस्कटॉप मशीन पर चले जाएँ। यह लोकल प्रोसेसिंग की नाकामी नहीं है; यह आपके पास मौजूद हार्डवेयर का सही इस्तेमाल है।
• अगर कोई टैब कई दिनों से खुला है तो ब्राउज़र रीस्टार्ट करें। लंबे समय तक खुले टैब मेमोरी जमा कर लेते हैं, जिसे रीलोड छोड़ देता है।

हर अनुमान की अपनी सीमा है

ब्राउज़र उपलब्ध मेमोरी के बारे में सिर्फ़ एक मोटा-सा संकेत देते हैं, और कुछ तो कुछ भी नहीं बताते। इसलिए कोई लोकल टूल आपको जो आँकड़ा दिखाता है वह फ़ाइल के अपने डाइमेंशन और पाइपलाइन के एक सतर्क मॉडल से बना अनुमान होता है, ऑपरेटिंग सिस्टम से ली गई रीडिंग नहीं। यह तय करने के लिए उपयोगी है कि काम शुरू किया जाए या नहीं। यह इस बात का वादा नहीं है कि काम पूरा होगा, क्योंकि जो चीज़ फ़ैसला करती है — अगले तीस सेकंड में डिवाइस का बाकी हिस्सा क्या कर रहा है — वह किसी वेब पेज को दिखती ही नहीं।

इसके लिए टूल

• छवि संपीड़ित करें
• PDF से JPG
• वीडियो संपीड़ित करें

स्रोत

• W3C — WebAssembly Core Specification, memory model
• W3C — Device Memory API, and why the value is coarse
• WHATWG — HTML Standard, transferable objects

और गाइड

सभी FileSlimmer गाइड