كيف قررنا تحسين الصور - وأعدنا في هذه العملية تصميم الموقع ولوحة الإدارة والنهج الخاص بالواجهة

تقرير بوريس جورياتشيف ، المدير الفني لميدوزا.



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







أحد العناصر الرئيسية التي تؤثر على سرعة تحميل أي موقع تقريبًا ، وخاصةً موقع الوسائط ، هو الصور. هناك الكثير من الصور على Meduza ، وهذه طريقة قيمة للمحررين لرواية القصص. يمكن صياغة متطلبات خدمة الصور لدينا على النحو التالي:

• يجب تحميل الصورة على نظام إدارة المحتوى (نسميها "مراقب") في أسرع وقت ممكن
• يجب أن تظل الصورة جميلة وأن تبدو جيدة على جميع المنصات
• لا يتعين على القارئ الانتظار حتى يتم تحميل هذه الصورة

النهج الأول

عندما أطلقنا في عام 2014 ، بدت عملية العمل مع الصور المحملة في الشاشة على النحو التالي: تم تحميل الملف في تطبيق Rails ، باستخدام مشبك الورق و Imagemagick ، ​​وتم مسحه من البيانات الوصفية ، وضغطه بالجودة المحددة (بالنسبة إلى JPEG كان حوالي 75) و مقسم إلى ثلاثة أحجام: صغير للهواتف ، وأكبر للأجهزة اللوحية والهواتف ذات الشاشات الكبيرة ، وكبير جدًا لأجهزة الكمبيوتر. تم وضع الملفات المقطعة في التخزين السحابي AWS مع الأصل. لقد تم تقديمها (وتم تقديمها) ليس مباشرة من AWS ، ولكن من خلال CDN الخاص بنا ، الذي يخزنها مؤقتًا على خوادم الحافة الخاصة به.



واجهة برمجة التطبيقات التي تنشئ JSON للموقع والتطبيقات ، بالإضافة إلى السمات البسيطة مثل عناوين المواد ، أعطت أيضًا جزءًا كبيرًا من كود HTML ، والذي تم إدخاله في جزء "المحتوى" من المادة وتم وزنه باستخدام أنماط CSS. وكانت واجهة برمجة التطبيقات نفسها في ذلك الوقت هي نفسها لجميع العملاء: الموقع والتطبيقات والخدمات الداعمة مثل RSS والبحث.







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



كان على القسم الفني أن يستحضر أنماط الصور وطرق عرضها وأحجامها - فقد تغيرت مع التغييرات في التصميم والعناصر الجديدة على الموقع. أضفنا ودعمنا المزيد والمزيد من الحلول الغريبة.





بمرور الوقت ، أغضبت الشاشة كل من صادفها أكثر فأكثر: لقد عانى فريق التحرير من الأخطاء ، لأن إصلاح هذه الأخطاء استغرق الكثير من الوقت ، وكان المطورون غاضبين ، وقيود التصميم المبتكر لم تناسب الرؤساء - لم نتمكن من تطوير المنتج بسرعة.



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



سأكتب قريبًا منشورًا منفصلاً في مدونتنا بالتفصيل حول تغيير كلمة "Monitor" .

اعادة تشغيل

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



قررنا أن نبدأ بتطبيقات الهاتف المحمول. بحلول ذلك الوقت ، كانت لديهم بالفعل أسئلة حول التصميم و UX والسرعة ، لذلك قمنا بتنظيف التطبيقات وجعلنا واجهة برمجة التطبيقات بالطريقة التي يريدها مطورو iOS و Android.



قبل فصل واجهة برمجة التطبيقات (API) ، أظهرنا جزء المحتوى من المواد من خلال WebView ، لذلك لم نتمكن من إظهار شيء ما حصريًا في التطبيق أو حصريًا على الموقع - تم عرض كل شيء في كل مكان. الآن لدينا الفرصة لإدارة المحتوى بشكل أكثر مرونة: لإعطاء ما هو مطلوب فقط لتطبيقات الهاتف المحمول ، ولإظهار العناصر الثقيلة بطريقة مختلفة (مثل إدراج مقاطع فيديو من YouTube) ، وأخيراً لجعل Lazy Load ، والذي يسمح لك بتحميل العناصر الثقيلة تدريجياً في المادة - الصور والتضمينات.



بعد فصل التطبيقات ، ركزنا على الموقع. في هذه المرحلة ، تقرر بالفعل أننا لن نجري تغييرات على رمز الموقع الحالي ، ولكن نكتب كل شيء من البداية (نعم ، لقد شاركنا في مشروع استمر أكثر من عام مرة أخرى). في الوقت نفسه ، تم استبدال مديرنا الفني ، وفي منصبي الجديد كان عليّ تدقيق المشاريع ، وتحديد ما يمكن إغلاقه ، وتنسيقه مع رؤسائي. ورغم كل الصعوبات قرر الفريق استكمال الموقع الجديد. لكن قبل ذلك ، قررت أننا بحاجة إلى مشروع آخر.

هذه هي الطريقة التي ظهرت بها UI-kit من Medusa.

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



خذ ألعاب Medusa على سبيل المثال .... إنها تسمح لك برواية عدد كبير من القصص بطريقة مرحة. يمكن إجراؤها خصيصًا لجدول الأعمال أو بناءً على طلب المعلن. أو يمكن صنع اللعبة على أساس ما يسمى بالميكانيكا - الأشكال التي يتم استخدامها بشكل متكرر (على سبيل المثال ، هذه اختبارات).



الألعاب على Meduza: كيف نصمم ونصنع ونعيد استخدام

كود هذه الألعاب لا يكمن في كود الموقع. يتم إنشاء كل منها كخدمة مصغرة منفصلة ، مضمنة في الموقع عبر إطار iframe والتواصل مع الموقع نفسه عبر postMessage. والموقع لا يهتم حقًا بما سيتم عرضه في المكان الذي ستكون فيه اللعبة. علاوة على ذلك ، يجب أن تكون اللعبة نفسها غير منفصلة بصريًا عن الموقع: يجب أن تكون عناصر الطباعة والواجهة متماثلة.







عندما بدأنا في صنع الألعاب ، قمنا بنسخ الأنماط والأزرار وأشياء أخرى ، وبالطبع كان الأمر سريعًا وبدا جيدًا من الخارج ، لكنه كان فظيعًا من الداخل.



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



تتم كتابة جميع مشاريع Meduza على الويب في React ، ومجموعة UI-kit عبارة عن وحدة npm يتم توصيلها بكل شيء نقوم بتطويره الآن تقريبًا. والمطور ، عندما يحتاج إلى تقديم شيء ما ، يكتب شيئًا مثل هذا: كتل العرض.

ماذا تعمل، أو ماذا تفعل؟

1. لا يفكر مطور الواجهة الأمامية بالضبط في كيفية تقديم شيء ما.
2. تمت مراجعة كل شيء من قبل قسم التصميم بالفعل.
3. : UI-kit, , , . , «», .
4. — - UI-kit ( ) .

UI-kit

هناك مجموعتان من المكونات: المحتوى والواجهة الأمامية. هذه الأخيرة هي مكونات React بسيطة جدًا مثل الأزرار والأيقونات.











تعتبر مكونات المحتوى أكثر تعقيدًا بعض الشيء ، لكنها لا تزال مكونات React بسيطة للغاية ذات أنماط تمثل وحدة واحدة من المحتوى. على سبيل المثال ، هذا هو الشكل الذي يبدو عليه مكون الفقرة:







مكون "يلتقط" الكتل البسيطة







وهذا مكون يعرض صورة:







واجهة برمجة التطبيقات التي يأخذ الموقع منها البيانات ، داخل كل مادة تحتوي على مجموعة من المكونات التي يتم "عرضها" في النهاية من خلال مجموعة أدوات واجهة المستخدم ... مع الألعاب ، كل شيء يعمل بنفس الطريقة ، يذهبون لبياناتهم إلى إصداراتهم من API.

الصيحة ، لقد أعدنا التشغيل!

يوجد أدناه رسم بياني يوضح متوسط ​​وقت تحميل الصفحة. هذا مؤشر غير دقيق للغاية - يتم أخذ جميع الصفحات الموجودة على جميع الأجهزة في الاعتبار - ولكنه يعطي فكرة عن الاتجاه.







يوضح الرسم البياني كيف تغيرت سرعة الموقع خلال فترة وجود Meduza بالكامل. عندما أطلقنا لأول مرة بموقع بسيط للغاية في عام 2014 ، كان سريعًا جدًا. ولكن عندما بدأنا في إضافة ميزات جديدة ، انخفضت سرعة التنزيل.



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







ثم جاء وقت التقاط الصور أخيرًا.

الصور

كان مخطط العمل مع الصور آنذاك. جاءت الصورة من خلال واجهة برمجة التطبيقات ، حيث كان لها عنوان مثل /images/attachments/.../random.jpg . تم تقديم الملف نفسه من التخزين السحابي لـ AWS عبر شبكة CDN الخاصة بنا.







قمنا بصياغة متطلبات النظام الجديد على النحو التالي:

• يجب أن يسمح لنا الحل بتغيير حجم وجودة الصور المرسلة بسرعة
• لا يجب أن تكون باهظة الثمن
• يجب أن تكون قادرة على التعامل مع الكثير من حركة المرور

المخطط الذي كنا نسعى جاهدين من أجله تحول إلى مثل هذا. ستنشئ الواجهة الخلفية عنوان URL يلتقطه العميل - المتصفح أو التطبيق. قد يحتوي عنوان URL على معلومات حول الصورة المطلوبة والجودة والحجم الذي يجب أن تكون عليه.



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







Meduza لديها بالفعل حلول مماثلة. على سبيل المثال ، نحن بالمثل نصنع صورًا لمقتطفات من موادنا وألعابنا على الشبكات الاجتماعية - في هذه الخدمة نصنع لقطات شاشة لصفحات HTML من خلال Headless Chrome.



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



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



احتجنا أيضًا إلى دعم تنسيق صورة الويب.



مر الوقت ، وأعدنا أنفسنا ذهنيًا للانغماس في هذا المشروع. ولكن بعد ذلك قرأ أحد المبرمجين لدينا عن مكتبة imgproxy ، والتي قام رجال من Evil Martians بتحميلها إلى Open Source . وفقًا للوصف ، لقد كانت نجاحًا مثاليًا: Go ، Libvps ، صورة Docker جاهزة ، التكوين عبر Env. في نفس اليوم ، قمنا بنشر المكتبة على أجهزة الكمبيوتر المحمولة الخاصة بنا وطلبنا من DevOps اللعب بها أيضًا. كانت مهمته إحضار الخدمة ومحاولة القضاء عليها - حتى نفهم الأحمال التي ستتحملها على خوادمنا. خلال هذا الوقت ، واصل فريق الواجهة الخلفية اللعب بالمشروع على أجهزة الكمبيوتر الخاصة بهم: كتبنا نصوص روبي واتقننا الوظائف المتاحة.







عندما عادت DevOps بالحكم على إمكانية استخدام المكتبة في الإنتاج ، جمعنا عددًا كبيرًا من الصور التي تم تمريرها عبر imgproxy - كنا مهتمين بشكل أساسي بـ webp - وأخذنا توجيهات الصور الخاصة بهم. لا يمكن لموظفي القسم الفني أن يقرروا بأنفسهم ما إذا كانت هذه الجودة تناسبنا أم لا. أرسل لنا محررو الصور تعليقاتهم ، وقمنا بتعديل شيء ما ، وتأكدنا من أن الصور لم تزن كثيرًا ، وذهبنا لكتابة الشفرة الخلفية.



هنا تبين أن كل شيء بسيط للغاية: نظرًا لأنه في إصدار واجهة برمجة التطبيقات للموقع ، تم فصل الصور بالفعل بواسطة مكونات من أي شيء آخر ، قمنا ببساطة بتوسيع JSON وإضافة عناوين إضافية بأحجام وأشكال مختلفة.











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



عندما توقفت التعليقات عن الظهور ، قمنا أخيرًا بنشرها وإسقاط ذاكرة التخزين المؤقت وبدء الإنتاج.

انتاج |

يمكن تلخيص جوهر التغييرات التي أجريناها على النحو التالي: لقد قمنا بتغيير مكان صنع القرار بشأن الصورة التي يجب تقديمها بأي شكل إلى المكان الذي يتم فيه أخذ السياق في الاعتبار بشكل أفضل ويكون التنفيذ والدعم أسهل في التنفيذ.



الآن تقريبًا جميع الصور التي تراها على Meduza هي نتيجة عمل imgproxy ، وفي كل حالة لها أحجام مختلفة وجودة مختلفة في بعض الأحيان. يتم تحديد ذلك من خلال السياق - سواء كان المحتوى مفتوحًا على الويب أو تطبيق الجوال أو AMP - الذي تعرفه خدمة واجهة برمجة التطبيقات التي تنشئ الردود.