ToolBox Image — لماذا بنينا ToolBox Image ليعمل بالكامل في متصفحك

معظم أدوات الصور المجانية على الإنترنت تعمل بنفس الطريقة: تقوم بتحميل ملف إلى الخادم الخاص بهم، يقوم الخادم بمعالجته، ثم تقوم بتنزيل النتيجة. هذا النموذج بسيط في البناء، لكن له تكاليف خفية — خصوصيتك، فواتير الخادم الخاصة بهم، وحدود على حجم الملف والإنتاجية.

ToolBox Image يتبع نهجاً مختلفاً. التطبيق بأكمله — فك التشفير، التشفير، الضغط، تغيير الحجم، تحويل التنسيق — يعمل في متصفحك. لا يوجد خادم للتحميل إليه. صورك لا تغادر جهازك أبداً. هذه الهندسة المعمارية كانت اختياراً متعمداً، وشكلت كل قرار اتخذناه بشأن المنتج.

لماذا النهج القائم على المتصفح أولاً؟

البديل الواضح هو الهندسة التقليدية من جانب الخادم. تقوم بتحميل صورة، يقوم الخادم بمعالجتها باستخدام أداة مثل ImageMagick أو Sharp، ويرسل النتيجة مرة أخرى. هذا يعمل، لكنه يخلق مجموعة من المشاكل التي يصعب حلها:

• الخصوصية. يجب على المستخدمين الثقة بأنك لن تخزن أو تحلل أو تسرب صورهم. للمستندات الحساسة — الصور الطبية، نماذج التصميم، الصور الشخصية — من الصعب كسب تلك الثقة.
• التكلفة. كل عملية ضغط تعمل على بنيتك التحتية. كلما زاد نجاحك، زاد ما تدفعه. هذا يخلق ضغطاً للحد من أحجام الملفات، أو إضافة طوابير انتظار، أو تقديم مستويات مدفوعة.
• زمن الاستجابة. تحميل ملف بحجم 100 ميغابايت عبر اتصال بطيء يستغرق دقائق قبل أن يبدأ المعالجة. للمستخدمين في المناطق ذات الاتصال الضعيف، الأداة غير قابلة للاستخدام فعلياً.
• التوسع. خادم واحد يمكنه التعامل مع عشرات عمليات الضغط المتزامنة. لكن ماذا عن الآلاف؟ تحتاج إلى مجموعات التوسع التلقائي، موازنات التحميل، نقاط نهاية CDN — كل هذا يضيف تعقيداً وتكلفة.

نموذج المتصفح أولاً يحل كل هذا مرة واحدة. المعالجة مجانية (دورات وحدة المعالجة المركزية للمستخدم)، خاصة (لا بيانات تغادر الجهاز)، وقابلة للتوسع بلا حدود (كل مستخدم يجلب أجهزته الخاصة).

كيف يعمل: WebAssembly و Web Workers

قبل عشر سنوات، كان تشغيل برامج ترميز الصور في المتصفح مستحيلاً. اليوم، يتيح لنا WebAssembly تجميع مكتبات C و Rust مباشرة إلى تنسيق يمكن للمتصفح تنفيذه بسرعة قريبة من الأصلية. نقوم بتجميع mozJPEG من Mozilla، و libwebp من Google، و مشفر AVIF libaom — جميعها مكتوبة بلغة C — إلى WebAssembly. المتصفح يشغلها بكفاءة كما لو كانت مثبتة بشكل أصلي.

لكن الترميز أحادي الخيط بطيء للدفعات الكبيرة. هنا يأتي دور Web Workers. كل عامل يعمل على نواة وحدة معالجة مركزية منفصلة، ونقوم بإنشاء عدد من العمال بعدد أنوية الجهاز. على كمبيوتر محمول حديث بـ 8 أنوية، هذا يعني 8 صور يتم ضغطها في وقت واحد. دفعة من 200 صورة كانت ستستغرق دقائق على خيط واحد تنتهي في ثوانٍ.

ما تخلينا عنه

النهج القائم على المتصفح أولاً ليس مجانياً. المقايضة الأكثر أهمية هي الذاكرة. علامة تبويب المتصفح لديها وصول إلى ذاكرة الوصول العشوائي للجهاز، لكن تعطل علامة تبويب واحدة لأن صورة تجاوزت الذاكرة المتاحة هو تجربة سيئة. نحدد الملفات الفردية بـ 100 ميغابايت وأحجام الدفعات بـ 200 ملف للبقاء ضمن الحدود الآمنة.

تخلينا أيضاً عن ميزات جانب الخادم مثل التخزين الدائم، توصيل البريد الإلكتروني، والتحليلات. لا توجد قاعدة بيانات للصور المضغوطة، ولا نشرة إخبارية، ولا تتبع لأي التنسيقات يفضلها المستخدمون. هذا متسق فلسفياً مع موقفنا من الخصوصية، لكنه يعني أننا لا نستطيع تقديم ميزات مثل "الضغطات الحديثة" أو "الإعدادات المحفوظة بين الجلسات".

ماذا بعد

المتصفح يصبح بيئة تشغيل شرعية للتطبيقات الحساسة للأداء. مع اكتساب WebAssembly لجمع القمامة، والمعالجة المتعددة الخيوط، ودعم SIMD، يمكن لجزء أكبر من حزمة التطبيقات الانتقال إلى جانب العميل. نحن نستكشف WebGPU لمعالجة أسرع للبكسلات وواجهة برمجة تطبيقات الوصول إلى نظام الملفات لتكامل سلس للمجلدات.

حالياً، الضاغط يعمل ويعالج آلاف الصور يومياً — جميعها تبقى في المكان الذي تنتمي إليه.