Google+‎

ملخّص

تعمل +Google بشكل كامل في الاستجابة.

الانتقال إلى موقع متجاوب مع مختلف الأجهزة

Google+ هي المكان الذي يجتمع فيه الأشخاص معًا حول الاهتمامات المشتركة، من Zombie Cats (قطط الزومبي) إلى الآلات الحاسبة القديمة. حتى وقت قريب، كان لدى +Google إصداران مختلفان من موقعهما على الويب: أحدهما لأجهزة الكمبيوتر المكتبية والآخر للويب على الأجهزة الجوّالة تم تصميمه ليناسب المتصفحات القديمة.

التحديات

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

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

الحلّ

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

كانت هذه المجموعة من القيود تعني أنه كان علينا فحص كل تغيير في التعليمات البرمجية من الآن فصاعدًا. لتحقيق ذلك، أنشأنا قاعدة 6^5 للتأكد من أنه عند التحميل الأولي للصفحة، لم ننزّل أكثر من 60 ألفًا من محتوى HTML و60 ألف من JavaScript و60 كيلوبايت من CSS، وأنّ الرسوم المتحركة كانت دائمًا 60 لقطة في الثانية، وكان متوسط وقت الاستجابة 0.6 ثانية.

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

باستخدام إطار العمل الجديد هذا، بدأنا وضع نماذج أولية لإعادة استخدام +Google على الويب. بدأنا في عدم السماح بالأشياء "السيئة" ووضع قواعد صارمة للتطوير. كانت إحدى قواعدنا الرئيسية هي أنّه يجب عرض جميع صفحاتنا على الخادم والعميل على حد سواء. وباستخدام العرض من جهة الخادم، نتأكد من أنّ المستخدم يمكنه بدء القراءة فور تحميل HTML، وأنّه لا حاجة إلى تشغيل JavaScript لتحديث محتوى الصفحة. وبعد أن يتم تحميل الصفحة وينقر المستخدم على رابط، لا نريد إجراء جولة ذهاب وعودة كاملة لعرض كل شيء مرة أخرى. هنا يصبح العرض من جهة العميل مهمًا، نحتاج فقط إلى جلب البيانات والقوالب، وعرض الصفحة الجديدة على العميل. وهذا ينطوي على الكثير من المفاضلات، لذلك استخدمنا إطار عمل يسهِّل العرض من جهة الخادم ومن جهة العميل بدون الحاجة إلى تنفيذ جميع الإجراءات مرتين: على الخادم والعميل.

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

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

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

النتائج

بدون التضحية بالأداء، تمكنت +Google من إنشاء تطبيق ويب معقد باستخدام واجهة مستخدم غنية. وقد أصبح الموقع الإلكتروني الآن أسرع وأسهل من أي وقت مضى.