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