هل يتعطل المتصفح أثناء الرفع؟ حلول لعمليات نقل مستقرة

إذا تعطّل متصفحك في منتصف الرفع، فالسبب شبه المؤكد هو ضغط الذاكرة على علامة التبويب. Chrome يُنهي علامات التبويب التي تتجاوز نحو 2 إلى 4 جيجابايت من الذاكرة الخاصة، وخدمة النقل التي تُحمّل ملف 10 جيجابايت في كائن Blob واحد ستتجاوز هذا الحد بسهولة. الحل: استخدم خدمة تُرسل الملف في أجزاء عبر طريقة slice() في File API (معظم الخدمات الحديثة تفعل ذلك)، وأغلق كل علامات التبويب الأخرى قبل الرفع، وعطّل الإضافات التي تتدخل في طلبات fetch/XHR، وارفع من جهاز مكتبي لا حاسوب محمول على طاقة البطارية. Firefox يتعامل عادةً مع تدفقات File API الكبيرة باستهلاك أقل للذاكرة مقارنةً بـ Chromium.

لماذا تتعطل المتصفحات عند الرفع

واقعان معماريان يتصادمان. أولًا، كل علامة تبويب في المتصفح عملية مستقلة بحدّ ذاكرة خاص. Chrome يحدّ كل عملية عرض بنحو 4 جيجابايت على الأنظمة 64 بت قبل تدخّل مُنهي OOM. ثانيًا، الطريقة الساذجة لرفع ملف بـ JavaScript هي تمرير كائن File بالكامل في نص طلب fetch، وهو ما تحاول المتصفحات غالبًا تخزينه مؤقتًا في الذاكرة قبل الإرسال.

الخدمة المبنية جيدًا لا تفعل هذا أبدًا. بدلًا من ذلك، تقرأ الملف بـ File.slice(start, end) لتُنتج كائن Blob لكل جزء من 5 إلى 20 ميجابايت، ترفع الجزء، ثم تُحرره. تبقى الذاكرة محدودة عند تقريبًا حجم_الجزء × التزامن بايت بصرف النظر عن حجم الملف.

إذا كان الرفع يسير بخير عند 500 ميجابايت ثم تتحول علامة التبويب للون الرمادي عند 2 جيجابايت، فالخدمة تُحمّل الملف كاملًا قبل الإرسال. اختر خدمة مختلفة.

أغلق علامات التبويب الأخرى بلا تردد

Chrome يُشارك عملية عرض واحدة لبعض علامات التبويب المجمّعة (Site Isolation يغيّر هذا، لكن ضغط الذاكرة لا يزال مشتركًا على مستوى النظام). علامة تبويب ثانية تُشغّل YouTube بدقة 4K، وثالثة بـ Figma، ورابعة بـ Notion تستهلك كل منها 800 ميجابايت، يتراكم كل هذا. رفع 10 جيجابايت على حاسوب محمول بذاكرة 8 جيجابايت وعشر علامات تبويب مفتوحة مجازفة كبيرة.

قبل بدء رفع كبير، أغلق Chrome كاملًا وأعد فتحه بعلامة تبويب واحدة فقط لخدمة النقل. Activity Monitor على macOS أو Task Manager على Windows يجب أن يُظهر المتصفح يستهلك أقل بكثير من 2 جيجابايت في تلك العلامة الوحيدة.

عطّل الإضافات

أدوات حجب الإعلانات وإضافات الخصوصية ومديرو كلمات المرور ومحللو الشبكة (uBlock Origin وPrivacy Badger وLastPass وHTTP Toolkit) جميعها تُحقن في طلبات الشبكة. معظمها لا يسبب مشاكل. بعضها، لا سيما ذات الكود القديم، يُخزّن نص الطلب مؤقتًا لفحصه، مما يُبطل الرفع المتدفق ويُفجّر الذاكرة.

اختبر في نافذة تصفح خاص (الإضافات معطّلة بشكل افتراضي). إذا اكتمل الرفع بنجاح في التصفح الخاص، فالإضافات هي المشكلة. فعّلها واحدة تلو الأخرى لتحديد المذنب.

عطّل تسريع الأجهزة حين تكون وحدة GPU ضعيفة

الحواسيب المحمولة القديمة بوحدات GPU مدمجة كـ Intel UHD 620 أحيانًا تتعطل عند معالجة تحديث شريط التقدم وقراءة مخزن الملف في آنٍ معًا. يمكن تعطيل خيار "Use hardware acceleration when available" من Chrome في الإعدادات > النظام. هذا يُقلّل بعض السلاسة في بقية الاستخدامات لكنه يُستقر الرفعات الكبيرة على الأنظمة المحدودة الذاكرة.

بالمثل، عطّل وضع "Memory Saver" في Chrome لعلامة تبويب الرفع، إذ أُبلغ عنه أنه يُخرج علامات التبويب من الذاكرة تحت الضغط في منتصف الرفع. ثبّت علامة التبويب أو استثنها صراحةً.

انتقل إلى Firefox للملفات الكبيرة جدًا

Firefox تاريخيًا يتعامل مع File API بميزانيات ذاكرة أضيق من Chromium. عند رفع 10 جيجابايت يُكرّر Chrome التعطّل، كثيرًا ما يُكمل Firefox الوظيفة ذاتها دون مشاكل. الفارق ليس كبيرًا على الخدمات المبنية جيدًا (كلاهما يتعامل مع الرفع المتدفق بالأجزاء بشكل جيد)، لكن على الخدمات ذات التطبيقات الأقل مثالية، يكون النموذج المحافظ لذاكرة Firefox أكثر مرونة.

Safari على macOS موثوق أيضًا للرفعات الكبيرة، مع تحفّظ أن iOS Safari يُنهي علامات التبويب الخلفية بقوة.

ثبّت علامة التبويب وابقِها في المقدمة

علامات التبويب الخلفية هي أول ما يُطرد تحت ضغط الذاكرة. أبقِ علامة تبويب الرفع في المقدمة. لا تنتقل إلى نافذة أخرى لثلاثين دقيقة وتعود لتجد علامة التبويب أُعيد تحميلها. علامات التبويب "المُهمَلة" في Chrome تُظهر عنصرًا نائبًا رماديًا عند العودة، وأي رفع جارٍ يكون قد انتهى.

استخدم caffeinate على macOS بالأمر (caffeinate -s) أو عطّل وضع توفير الطاقة في Windows أثناء الرفع. الحاسوب النائم يُغلق اتصالات WebSocket وXHR، وليست كل خدمة تستطيع الاستئناف بنظافة بعدها.

ارفع من سطح المكتب لا من حاسوب محمول على البطارية

الحواسيب المحمولة تُحدّ المعالج والذاكرة بقوة على البطارية. "Low Power Mode" في macOS و"Battery Saver" في Windows يُقلّلان كليهما أولوية المهام الخلفية، مما يعني بالنسبة لعلامة تبويب تُجري تشفير AES وكتابة شبكية توقفات.

قم بتوصيل جهازك بالطاقة. عطّل أوضاع توفير البطارية. إذا كان للحاسوب المحمول خيارات لملفات تعريف أداء المعالج (Dell Power Manager أو Lenovo Vantage)، اضبطه على "Performance" طوال فترة الرفع.

أعد تشغيل المتصفح قبل البدء

Chrome وFirefox وEdge جميعها تُسرّب الذاكرة ببطء على مدار جلسات طويلة. متصفح مفتوح منذ يومين مع 40 علامة تبويب فُتحت وأُغلقت قد يحمل 2 جيجابايت من الذاكرة الميتة قبل فتح صفحة الرفع. أغلق كاملًا (Cmd+Q لا مجرد إغلاق النافذة على macOS؛ نقرة يمين على شريط المهام > إنهاء على Windows) ثم أعد الفتح.

راقب استهلاك الذاكرة عبر Activity Monitor أثناء الرفع

أثناء الرفع، راقب ذاكرة عملية المتصفح. Activity Monitor على macOS: تبويب الذاكرة، فلتر باسم المتصفح. Task Manager على Windows: تبويب التفاصيل، رتّب حسب "Memory (private working set)".

رفع متدفق بالأجزاء صحي يثبت عند بضع مئات من الميجابايت من ذاكرة المتصفح بصرف النظر عن التقدم. إذا تصاعدت الذاكرة خطيًا مع تقدم الرفع (تصل 5 جيجابايت عند 50 بالمائة من ملف 10 جيجابايت)، فالخدمة تُخزّن كل شيء مؤقتًا. هذه هي المشكلة. ابحث عن خدمة مختلفة.

استخدم خدمات مبنية للرفع الكبير عبر المتصفح

خدمة النقل المهندسة جيدًا تستخدم رفعًا متدفقًا بالأجزاء مع تجمع Web Worker للتشفير وذاكرة محدودة وإعادة محاولة صريحة على الأجزاء الفاشلة. HexaTransfer تقرأ الملفات عبر File.slice() في Web Workers، وتُشفّر بـ AES-256-GCM لكل جزء، ولا تتجاوز بضع مئات من الميجابايت من ذاكرة المتصفح سواء كنت ترسل 50 ميجابايت أو كامل سقف 10 جيجابايت لكل عملية نقل، مما يهم حين يكون متصفحك يتعامل بالفعل مع كل ما يُلقيه يومك عليه.

جرّبها على hexatransfer.com — مجاني، بدون حساب، حتى 10 جيجابايت.