دراسة حالة للتغييرات التي نفذها GoDaddy لتحسين أداء المواقع الإلكترونية لملايين المواقع الإلكترونية، ما يساعدها في تحقيق نتائج جيدة في "إحصاءات PageSpeed" ونتائج "مؤشرات أداء الويب الأساسية"
GoDaddy هي أكبر منصة خدمات في العالم لروّاد الأعمال حول العالم. في إطار سعينا لمساعدة منتدانا العالمي الذي يضم أكثر من 20 مليون عميل ورائد أعمال في كل مكان، نمنحهم جميع المساعدة والأدوات التي يحتاجونها للنمو على الإنترنت.
في عام 2019، أطلق فريق GoDaddy ميزة "المواقع الإلكترونية + التسويق" مع التزامها بتقديم أدوات وخدمات سهلة الاستخدام ومساعدة مالكي الأنشطة التجارية في تحقيق أهدافهم. ومن خلال دمج "مواقع الويب + التسويق" بين عملية إنشاء المواقع الإلكترونية وأدوات التسويق والتجارة الإلكترونية، يتم الجمع بينها وبين أفضل الإرشادات لمساعدة العملاء على تحقيق النجاح في مشاريعهم الجديدة.
منذ إطلاق المواقع الإلكترونية + التسويق، أصبح الأداء جزءًا مهمًا من المنتج وتم مراقبته والعمل عليه بنشاط. في هذه المقالة، سنراجع رحلة GoDaddy، بدءًا من استخدام اختبار الأداء في المختبر إلى استخدام البيانات الواقعية مع "مؤشرات أداء الويب الأساسية"، وسنستعرض سلسلة التحسينات التي تم إجراؤها على المنتج للحصول على معدل نجاح عالي جدًا في المواقع الإلكترونية الخاصة بعملائنا.
تتبُّع الأداء باستخدام Lighthouse
لقد اعتمدنا على بيانات Lighthouse في تتبُّع الأداء. في كل مرة يتم نشر موقع إلكتروني على المنصة، نقيس أدائه باستخدام أداتنا الداخلية المسماة Lighthouse4u التي توفّر Google Lighthouse كخدمة https://github.com/godaddy/lighthouse4u. وقد منحنا هذا مؤشرًا جيدًا على مستوى أداء المواقع الإلكترونية بشكل عام في إعدادات ميزة اختبارية.
بما أنّ ملايين المواقع الإلكترونية التي نستضيفها على منصتنا تتضمّن مجموعة كبيرة من الميزات والمحتوى، كان من المهم دمج بيانات الأداء مع البيانات الوصفية لكل موقع إلكتروني يتم اختباره (مثل النموذج المستخدَم ونوع التطبيقات المصغّرة المعروضة وما إلى ذلك). وقد سمح لنا هذا باستخلاص نتائج حول ميزات الموقع الإلكتروني التي كان أداؤها منخفضًا، مع توفير إحصاءات عن المواضع التي ينبغي البحث فيها عن التحسينات.
على سبيل المثال، ساعدنا ذلك في تحديد أنّ "نمط النافذة المنبثقة" كان له تأثير سلبي على سرعة الصفحة، بينما كان أداء المواقع الإلكترونية التي تتضمّن هذه الميزة أقل بمقدار 12 نقطة من تلك التي لم تحقّقها. بعد إجراء تعديلات على الرمز بهدف تأجيل تحميل JavaScript، أدخلنا تحسينات على نتيجتنا في Lighthouse بنقطتين. استطعنا تطبيق ما تعلّمته على ميزات أخرى، مثل "بانر ملفات تعريف الارتباط" الذي يظهر بعد تحميل الصفحة بوقت قصير.
وبالإضافة إلى فحص المواقع التي تحتوي على مشاكل استنادًا إلى الميزات، أجرينا تحليلاً لحزمة JavaScript وتبيّن لنا أنّ جزءًا كبيرًا من حجمها يأتي من اعتماديات خارجية (immutable.js ومسودة.js). وتم تقليل حجم الحزمة من خلال إعادة هيكلة المستهلكين إلى اعتماد التحميل الكسول حسب الطلب. وقد أدّى ذلك إلى انخفاض بنسبة تزيد عن% 50 في حجم حزمة JavaScript الشائعة، والتي ارتفعت من أكثر من 200 كيلوبايت إلى حوالي 90 كيلوبايت (تم تصغيرها). سمح حجم الحزمة الأصغر للمتصفح بتحميل مواد عرض خارجية وتنفيذ نصوص برمجية مهمة في مرحلة مبكرة من التحميل الأولي للموقع الإلكتروني، ما أدى إلى تحقيق زيادة في سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) ومهلة الاستجابة الأولى (FID).
بفضل جهودنا المستمرة، ارتفع متوسط نتيجة Lighthouse في موقع العملاء الإلكتروني من حوالي 40 نقطة في تشرين الثاني (نوفمبر) 2020 إلى أكثر من 70 نقطة في أيار (مايو) 2021. ومع ذلك، لم تنجح جميع محاولاتنا وفوجئنا أحيانًا عندما لم تكن النتائج متسقة دائمًا بين ما تم اختباره في بيئات الاختبار المحلية والنتائج التي حصلنا عليها في هذا المجال. كانت نتائج المعمل مفيدة حقًا، ولكن حان الوقت للتركيز على تجارب المستخدم الحقيقية التي يتم رصدها في هذا المجال.
تتبُّع بيانات المستخدمين باستخدام "مؤشرات أداء الويب الأساسية"
بعد إضافة مكتبة web-vitals إلى المواقع الإلكترونية لعملائنا، تمكّنا من قياس البيانات المتوفّرة على أجهزة فعلية من زوّار فعليين، حيث لا تكون الأجهزة أو سرعة الشبكة أو تفاعل المستخدم (مثل التمرير أو النقر) في خط الأساس نفسه كما هو الحال في الإعدادات المعملية باستخدام Lighthouse. كانت هذه خطوة كبيرة في الاتجاه الصحيح، حيث أصبح لدينا الآن بيانات تمثل ما كان يختبره زوّار موقعنا على الويب.
التركيز على الرابط الأضعف: متغيّرات التصميم التراكمية (CLS)
منحنا تحليل البيانات الجديدة منظورًا جديدًا حول ما كان يجب القيام به لتحسين سرعة موقع الويب. نتيجة العمل الذي بذلناه لتحسين نتيجة Lighthouse، بلغ مقياس LCP والذي يبلغ 75% 860 ملي ثانية، بينما كانت قيمة FID (مهلة الاستجابة الأولى) نفسها عند الحد الأدنى أقل من 10 ملي ثانية، ولذلك حقّقنا معدّل نجاح مرتفعًا لهذَين المقياسَين على المواقع الإلكترونية للعملاء: 78% و 98% على التوالي. مع ذلك، تبدو أرقام متغيّرات التصميم التراكمية (CLS) مختلفة تمامًا عمّا اعتدنا عليه في استخدام Lighthouse. كانت متغيّرات التصميم التراكمية (CLS) عند الشريحة المئوية الخامسة والسبعين تبلغ 0.17، أي أعلى من الحدّ الأدنى البالغ 0.1 "للاجتياز"، وبالتالي كان معدّل النجاح لدينا% 47 فقط من جميع مواقعنا الإلكترونية.
أدى هذا المقياس إلى خفض معدل النجاح الإجمالي لدينا إلى 40٪، لذلك قررنا وضع هدف طموح ليزيد عن 60٪ بحلول نهاية شهر آب (أغسطس) 2021. ولإجراء ذلك، يجب أن نركّز على متغيّرات التصميم التراكمية (CLS).
في الواقع، يتفاعل المستخدمون مع الصفحة وينتقلون إلى ما بعد محتوى "الجزء المرئي من الصفحة"، وهو ما تجذبه "مؤشرات أداء الويب الأساسية" بشكل أفضل. بسبب تباين طريقة تفاعل المستخدمين مع الموقع الإلكتروني أثناء تحميله في البداية، اختلفت متغيّرات التصميم التراكمية (CLS) عن البيانات المعملية والميدانية.
الطريق نحو اجتياز جميع "مؤشرات أداء الويب الأساسية"
يتطلّب تحسين الأداء التجربة والخطأ، ولا تؤدي كل محاولة إلى تحقيق النتيجة المرجوّة. ولكن إليك بعض التحسينات التي ساعدتنا في تحقيق أهدافنا.
أدّى حجز مساحة لتحميل الصور إلى تحسين نتيجة متغيّرات التصميم التراكمية (CLS) بشكل كبير، لأنّه يمنع تغيُّر المحتوى أسفل الصور. استخدمنا السمة aspect-ratio في CSS لحلّ هذه المشكلة في المتصفّحات المتوافقة. وبالنسبة إلى التطبيقات التي لم يتم تحميلها، تم تحميل صورة عنصر نائب شفافة تم تخزينها مؤقتًا وبحجم لا يتجاوز بضع بايت، وبالتالي يتم تحميلها بشكل فوري تقريبًا.
وقد سمح لنا سلوك الصورة العام هذا بحساب ارتفاع الصورة النهائية مسبقًا أثناء العرض من جهة الخادم، وذلك استنادًا إلى عرض إطار العرض ونسبة عرض إلى ارتفاع الصورة. وقد أدّى ذلك إلى تضمين ترميز HTML مع إبقاء مساحة عمودية محجوزة بشكل مناسب للصورة النهائية. وقد كان هذا التحسّن ملحوظة على الأجهزة الجوّالة بشكل خاص، نظرًا لعرض الصور على كامل إطار عرض الإعلانات على الأجهزة الجوّالة.
بعض المكونات على مواقع العملاء الإلكترونية تتضمن محتوًى ديناميكيًا (مثل قائمة بمراجعات العملاء الخارجيين)، ولا يمكن تحويلها إلى محتوى CSS فقط للاستفادة من مزايا أداء العرض من جهة الخادم. هذه مناطق يصعب تحسين متغيّرات التصميم بسبب اختلاف المحتوى (وبالتالي الارتفاع). في تلك الحالات، قمنا بلف المكون في حاوية مع تطبيق min-height، المحدد مسبقًا بناءً على ملاحظة متوسط الارتفاع لكل من المكونات المحددة. تتم إزالة min-height بعد انتهاء عرض المكوّن الديناميكي الداخلي. على الرغم من أنه لم يكن مثاليًا، فقد سمح لنا هذا الحل بتقليل تغيُّر التصميم كثيرًا.
مع التركيز على تحسينات متغيّرات التصميم التراكمية (CLS)، واصلنا العمل على تطوير سرعة LCP. إنّ الصور على العديد من المواقع الإلكترونية هي السبب الأكثر مساهمة في تحسين سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)، وكان ذلك من مجالات التحسين الواضحة بالنسبة إلينا. لقد أجرينا تحسينات على الصور ذات التحميل الكسول باستخدام IntersectionObserver، ولكنّنا أدركنا أنّه لم يتم ضبط أحجام الصور على النحو الأمثل لكل نقطة توقّف (الأجهزة الجوّالة، والأجهزة اللوحية، وأجهزة الكمبيوتر المكتبي، وأجهزة الكمبيوتر المكتبي الكبيرة)، لذا عدّلنا رمز إنشاء الصور لتثبيت الصور وتغيير حجمها لكل نقطة فاصلة، ثم تعديل درجة الدقة مرة أخرى استنادًا إلى كثافة وحدات البكسل. على سبيل المثال، تم خفض حجم صورة كبيرة معيّنة من 192 كيلوبايت إلى 102 كيلوبايت.
لعرض المواقع الإلكترونية على الأجهزة ذات الاتصال الضعيف بالشبكة، أضفنا رمزًا لخفض جودة الصورة ديناميكيًا استنادًا إلى سرعة الاتصال. يمكن إجراء ذلك باستخدام السمة downlink التي يعرضها navigator.connection. نطبّق معلَمات طلبات البحث المستندة إلى عنوان URL لتقليل جودة الصور من خلال واجهة برمجة التطبيقات لمواد العرض استنادًا إلى حالات الشبكة هذه.
يتم تحميل عدد من الأقسام في مواقع العملاء بشكل ديناميكي. بما أنّنا نعرف الأقسام التي سيتم عرضها على موقع إلكتروني معيّن عند نشرها، استخدمنا تلميح مورد rel=preconnect لإعداد الاتصال وعمليات تأكيد الاتصال الضرورية مسبقًا. نستخدم أيضًا تعديلات الموارد لتحميل الخطوط والموارد المهمة الأخرى بسرعة.
عند إنشاء مواقعهم، يضيف العملاء أقسامًا متنوعة قد تحتوي على نصوص برمجية مضمنة للسماح بوظائف مختلفة. لا يؤدي تضمين هذه النصوص البرمجية في جميع صفحات HTML دائمًا إلى تحقيق أفضل أداء. وقد قرّرنا استخدام هذه النصوص البرمجية خارجيًا للسماح للمتصفح بتحميل محتوى النص البرمجي وتحليله بشكل غير متزامن. ويمكن أيضًا مشاركة النصوص البرمجية الخارجية حديثًا بين الصفحات. وقد سمح ذلك بتحقيق مكاسب إضافية في الأداء من خلال التخزين المؤقت في المتصفّح وCDN. وقد احتفظنا بالنصوص البرمجية المهمة بشكل مضمّن لكي يتمكّن المتصفّح من تحليلها وتنفيذها بشكل أسرع.
النتائج
من خلال التركيز على نتائج متغيّرات التصميم التراكمية (CLS)، ارتفع معدّل النجاح في "مؤشرات أداء الويب الأساسية" من% 40 إلى %70 تقريبًا، ما يعني تحسّنًا بنسبة %75.
ومع عودة المستخدمين إلى منصتنا لإجراء تعديلات وإعادة نشر مواقعهم الإلكترونية، يحصلون على آخر التحسينات في الأداء. ونتيجةً لذلك، يتزايد عدد المواقع الإلكترونية التي اجتازت الاختبار "مؤشرات أداء الويب الأساسية" بشكل منتظم كما هو موضّح في الرسم البياني أدناه:
الاستنتاجات
يعتمد العثور على مجالات لتحسين الأداء وتتبع التقدم بنجاح على الأدوات المستخدمة للقياس. كانت أداة Lighthouse مفيدة لقياس الأداء في الجزء المرئي من الصفحة ضمن "إعداد الميزة الاختبارية"، ولكنّها لم ترصد بدقة مشاكل الأداء التي حدثت فقط من تفاعلات المستخدمين (مثل التنقّل في الصفحة).
من خلال تتبُّع "مؤشرات أداء الويب الأساسية" مع البيانات الوصفية، أصبح بإمكاننا عرض وتحسين وقياس تأثير التحسينات. وبفضل جهودنا الرامية إلى تحسين نتائج "مؤشرات أداء الويب الأساسية"، يمكن للفريق تحديد الأنماط غير الأداء واستبدالها في قاعدة الرموز البرمجية. في بعض الأحيان، لم يكن للتغييرات الواعدة سوى التأثير الذي توقعناه تقريبًا، وأحيانًا حدث العكس. إنه ليس عالمًا نقيًا، لذا عليك أن تستمر في المحاولة.