دراسة حالة عن بعض التغييرات الرئيسية التي تمّ إجراؤها في Wix لتحسين أداء تحميل المواقع الإلكترونية لملايين المواقع الإلكترونية، ما يسهّل عليها الحصول على نتائج جيدة في "إحصاءات PageSpeed" و"مؤشرات أداء الويب الأساسية"
بفضل الاستفادة من معايير المجال ومقدّمي خدمات السحابة الإلكترونية وإمكانات شبكة توصيل المحتوى (CDN)، بالإضافة إلى إعادة كتابة أساسية لوقت تشغيل موقعنا الإلكتروني، تضاعفت النسبة المئوية لمواقع Wix التي تحقّق نتائج جيدة في الشريحة المئوية الخامسة والسبعون على جميع مقاييس Core Web Vitals مقارنةً بالعام السابق، وفقًا لبيانات من CrUX و HTTPArchive.
اعتمدت Wix ثقافة تركّز على الأداء، وسنواصل طرح المزيد من التحسينات للمستخدمين. وبما أنّنا نركّز على مؤشرات الأداء الرئيسية، نتوقّع أن نرى زيادة في عدد المواقع الإلكترونية التي تستوفي الحدود الدنيا لمؤشرات أداء الويب الأساسية.
نظرة عامة
إنّ عالم الأداء معقد بشكل جميل، ويضمّ العديد من المتغيّرات والتعقيدات. تُظهر الأبحاث أنّ سرعة الموقع الإلكتروني لها أثر مباشر في معدلات الإحالات الناجحة والأرباح للأنشطة التجارية. في السنوات الأخيرة، ركّزت الصناعة بشكل أكبر على الأداء ومستوى الظهور وزيادة سرعة الويب. اعتبارًا من أيار (مايو) 2021، سيتم تضمين إشارات تجربة الصفحة في ترتيب نتائج "بحث Google".
يتمثل التحدي الفريد في Wix في توفير الدعم لملايين المواقع الإلكترونية، التي تم إنشاء بعضها قبل عدة سنوات ولم يتم تعديلها منذ ذلك الحين. لدينا العديد من الأدوات ومقالات المساعدة لمساعدة المستخدمين في معرفة الإجراءات التي يمكنهم اتّخاذها لتحليل أداء مواقعهم الإلكترونية وتحسينه.
Wix هي بيئة مُدارة ولا يمكن للمستخدم التحكّم في كل شيء. تطرح مشاركة البنى الأساسية المشتركة العديد من التحديات لجميع هذه المواقع الإلكترونية، ولكنها توفّر أيضًا فرصًا لتحسينات كبيرة على مستوى جميع المواقع، أي الاستفادة من مزايا خفض التكاليف.
التحدّث بلغة مشتركة
من بين الصعوبات الأساسية في الأداء العثور على مصطلحات شائعة لمناقشة جوانب مختلفة من تجربة المستخدم، مع مراعاة كل من الأداء الفني والأداء المتأثّر بالعوامل الذاتية. من خلال استخدام لغة مشتركة ومحدّدة جيدًا داخل المؤسسة، تمكّنا من مناقشة الأجزاء الفنية المختلفة والمفاضلات بينها وتصنيفها بسهولة، ما وضّح تقارير الأداء وساعدنا بشكل كبير في فهم الجوانب التي يجب التركيز على تحسينها أولاً.
عدّلنا جميع عمليات المراقبة والمناقشات الداخلية لتضمين مقاييس معيارية في المجال، مثل مؤشرات أداء الويب، والتي تشمل ما يلي:
نقاط أداء الموقع الإلكتروني وتعقيده
من السهل جدًا إنشاء موقع إلكتروني يتم تحميله على الفور طالما أنّه بسيط جدًا باستخدام HTML فقط وعرض المحتوى من خلال شبكة توصيل محتوى.
ومع ذلك، تصبح المواقع الإلكترونية أكثر تعقيدًا و تطورًا، وتصبح أكثر شبهاً بالتطبيقات بدلاً من المستندات، وتوفر وظائف مثل المدونات وحلول التجارة الإلكترونية والرموز المخصّصة وغيرها.
تقدّم Wix مجموعة كبيرة جدًا من نماذج التصاميم، ما يتيح لمستخدميها إنشاء موقع إلكتروني بسهولة يتضمن العديد من إمكانات النشاط التجاري. وغالبًا ما تؤدي هذه الميزات الإضافية إلى بعض تكاليف الأداء.
الرحلة
في البداية، كانت هناك لغة HTML
في كل مرة يتم فيها تحميل صفحة ويب، يبدأ ذلك دائمًا بطلب أولي إلى عنوان URL لاسترداد مستند HTML. يؤدي استجابة HTML هذه إلى تشغيل كل طلبات العميل المضافة ومنطق المتصفّح لعرض موقعك الإلكتروني. يمثّل هذا القسم أهم جزء في تحميل الصفحة، لأنّه لا يحدث أيّ شيء إلى أن يتم تلقّي بداية الاستجابة (المعروفة باسم TTFB - وقت وصول أول بايت).
في الماضي: العرض من جهة العميل (CSR)
عند تشغيل أنظمة على نطاق واسع، عليك دائمًا مراعاة التوازنات التي تحتاج إلى التفكير فيها، مثل الأداء والموثوقية والتكاليف. حتى بضع سنوات مضت، كانت Wix تستخدم ميزة المعالجة من جهة العميل (CSR)، حيث يتم إنشاء محتوى HTML الفعلي باستخدام JavaScript من جهة العميل (أي في المتصفّح)، ما يتيح لنا إتاحة استخدام عددٍ كبير من المواقع الإلكترونية بدون تكاليف تشغيلية ضخمة في الخلفية.
سمحت لنا ميزة CSR باستخدام مستند HTML شائع، وكان فارغًا في الأساس. كل ما تمّ هو بدء تنزيل الرمز والبيانات المطلوبة، والتي تم استخدامها بعد ذلك لإنشاء ملف HTML الكامل على جهاز العميل.
اليوم: العرض من جهة الخادم
قبل بضع سنوات، انتقلنا إلى العرض من جهة الخادم (SSR)، لأنّ ذلك كان مفيداً لتحسين محركات البحث والأداء على حد سواء، ما أدّى إلى تحسين أوقات ظهور الصفحة الأولية وضمان فهرسة أفضل لمحرّكات البحث التي لا تتيح استخدام JavaScript بالكامل.
أدّى هذا النهج إلى تحسين تجربة الظهور، لا سيما على الأجهزة أو اتصالات الإنترنت الأبطأ، وفتح الباب أمام المزيد من تحسينات الأداء. ومع ذلك، كان ذلك يعني أيضًا أنّه لكل طلب صفحة ويب، يتم إنشاء استجابة HTML فريدة على الفور، وهو أمر بعيد عن الأداء الأمثل، خاصةً للمواقع الإلكترونية التي تتلقّى عددًا كبيرًا من المشاهدات.
نقدّم لك ميزة التخزين المؤقت في مواقع جغرافية متعددة.
كان رمز HTML لكل موقع إلكتروني ثابتًا في الغالب، ولكن كان يتضمّن بعض التحذيرات:
- يتغيّر بشكل متكرّر. في كل مرة يعدّل فيها المستخدم موقعه الإلكتروني أو يُجري تغييرات في بيانات الموقع الإلكتروني، مثل المستودع في متجر الموقع الإلكتروني
- كان يتضمّن بيانات وملفات تعريف ارتباط معيّنة خاصة بالزائر، ما يعني أنّ شخصَين يزوران الموقع الإلكتروني نفسه سيشاهدان صفحات HTML مختلفة إلى حدّ ما. على سبيل المثال، لتفعيل ميزات المنتجات، مثل تذكُّر السلع التي وضعها الزائر في سلة التسوّق، أو المحادثة التي بدأها الزائر مع النشاط التجاري في وقت سابق، وغير ذلك.
- لا يمكن تخزين بعض الصفحات مؤقتًا. على سبيل المثال، لا تكون الصفحة التي تتضمّن رمز مستخدم مخصّصًا وتعرض الوقت الحالي كجزء من المستند مؤهّلة للتخزين المؤقت.
في البداية، اتّبعنا النهج الآمن نسبيًا المتمثّل في تخزين صفحات HTML مؤقتًا بدون بيانات الزوّار، ثم عدّلنا فقط أجزاء محدّدة من استجابة HTML على الفور لكل زائر، وذلك عند كل عملية مطابقة مع ذاكرة التخزين المؤقت.
حلّ شبكة توصيل المحتوى الداخلي
وقد تمكّنا من إجراء ذلك من خلال نشر حلّ داخلي: باستخدام Varnish HTTP Cache للتوسّط والتخزين المؤقت، وKafka لرسائل إلغاء الصلاحية، وخدمة مستندة إلى Scala/Netty تعمل كوسيط لهذه الطلبات المرسَلة بتنسيق HTML، ولكنها تُغيّر تنسيق HTML وتضيف بيانات وملفات تعريف ارتباط خاصة بالزائرين إلى الطلب المخزّن مؤقتًا.
سمح لنا هذا الحلّ بنشر هذه المكوّنات الضئيلة في العديد من المواقع الجغرافية والمناطق المتعددة لمزوّدي خدمات السحابة الإلكترونية والتي تنتشر في جميع أنحاء العالم. في عام 2019، طرحنا أكثر من 15 منطقة جديدة، وأصبح التخزين المؤقت مفعّلاً تدريجيًا لأكثر من% 90 من مشاهدات الصفحات المؤهّلة لذلك. أدّى عرض المواقع الإلكترونية من مواقع جغرافية إضافية إلى خفض وقت معالجة الشبكة بين العملاء والخوادم التي تعرِض استجابة HTML، وذلك من خلال تقريب المحتوى من هُم.
بدأنا أيضًا في تخزين بعض استجابات واجهة برمجة التطبيقات للقراءة فقط في ذاكرة التخزين المؤقت باستخدام الحلول نفسها وإلغاء صلاحية ذاكرة التخزين المؤقت عند إجراء أي تغيير على محتوى الموقع الإلكتروني. على سبيل المثال، يتم تخزين قائمة مشاركات المدونة على الموقع الإلكتروني في ذاكرة التخزين المؤقت وإلغاء صلاحيتها عند نشر مشاركات أو تعديلها.
تقليل التعقيدات
أدّى استخدام ميزة التخزين المؤقت إلى تحسين الأداء بشكل كبير، وبشكل أساسي في مرحلتَي TTFB وFCP، كما أدّى إلى تحسين الموثوقية من خلال عرض المحتوى من موقع أقرب إلى المستخدم النهائي.
ومع ذلك، أدّت الحاجة إلى تعديل رمز HTML لكلّ ردّ إلى زيادة تصاعدية في الصعوبة، ما كان سيتيح إجراء المزيد من التحسينات على الأداء في حال إزالة هذا الرمز.
التخزين المؤقت للمتصفّح (والاستعدادات لشبكات توصيل المحتوى)
~ 13%
طلبات HTML التي يتم عرضها مباشرةً من ذاكرة التخزين المؤقت للمتصفّح، ما يوفر الكثير من معدل نقل البيانات ويقلل من أوقات التحميل للمشاهدات المتكرّرة
كانت الخطوة التالية هي إزالة هذه البيانات الخاصة بالزائر من ملف HTML تمامًا، واستردادها من نقطة نهاية منفصلة يستدعيها العميل لهذا الغرض، بعد وصول ملف HTML.
نقلنا هذه البيانات وملفات تعريف الارتباط بعناية إلى نقطة نهاية جديدة يتمّ استدعاؤها عند تحميل كل صفحة، ولكنّها تعرض ملف JSON صغيرًا، وهو مطلوب فقط ل عملية الترطيب، للوصول إلى التفاعل الكامل مع الصفحة.
وقد سمح لنا ذلك بتفعيل ميزة التخزين المؤقت لصفحات HTML في المتصفّح، ما يعني أنّ المتصفّحات تحفظ الآن استجابة صفحات HTML للزيارات المتكرّرة، ولا تتصل بالخادم إلا للتحقّق من أنّ المحتوى لم يتغيّر. ويتم ذلك باستخدام علامة ETag لبروتوكول HTTP، وهي في الأساس معرّف يتم تعيينه لإصدار معيّن من مورد HTML. إذا كان المحتوى لا يزال هو نفسه، تُرسِل خوادمنا إلى العميل استجابة 304 لم يتم تعديله بدون نص.
بالإضافة إلى ذلك، يعني هذا التغيير أنّ ملف HTML لم يعُد خاصًا بالزائرين ولم يعد يحتوي على ملفات تعريف ارتباط. بعبارة أخرى، يمكن تخزينه مؤقتًا في أي مكان، ما يفتح الباب لاستخدام مقدّمي خدمات شبكة توصيل المحتوى (CDN) الذين لديهم مواقع جغرافية أفضل بكثير في مئات المواقع الجغرافية حول العالم.
بروتوكول نظام أسماء النطاقات وبروتوكول أمان طبقة النقل وHTTP/2
بعد تفعيل ميزة التخزين المؤقت، تم تقليل أوقات الانتظار وأصبحت أجزاء مهمة أخرى من العملية الأولية للاتصال أكثر فعالية. من خلال تحسين بنية شبكة المراقبة ، تمكّنا من تحسين زمن معالجة نظام أسماء النطاقات والاتصال وطبقة المقابس الآمنة (SSL).
تم تفعيل HTTP/2 لجميع نطاقات المستخدمين، مما يقلل من عدد عمليات الربط المطلوبة والتكلفة الإضافية التي تصاحب كل عملية ربط جديدة. كان هذا التغيير سهل الاستخدام نسبيًا، مع الاستفادة من مزايا الأداء والقدرة على التحمل التي تأتي مع HTTP/2.
ضغط Brotli (مقارنةً بـ gzip)
من 21 إلى 25%
تقليل متوسط حجم نقل الملفات
في السابق، كان يتم ضغط جميع ملفاتنا باستخدام ضغط gzip، وهو الخيار الأكثر شيوعًا لضغط HTML على الويب. تم تنفيذ بروتوكول الضغط هذا في البداية قبل 30 عامًا تقريبًا.
يقدّم برنامج Brotli للضغط الأحدث تحسينات في الضغط بدون أي تنازلات تقريبًا، ويزداد استخدامه رواجًا ببطء، كما هو موضّح في فصل الضغط ضمن "منجم الويب" السنوي. وقد كانت متاحة في جميع المتصفحات الرئيسية لفترة من الوقت.
لقد فعّلنا تنسيق Brotli على خوادم الوكيل nginx في نقاط الاتصال، لجميع العملاء الذين يتيحون ذلك.
أدى استخدام ضغط Brotli إلى خفض متوسط أحجام نقل الملفات بنسبة 21% إلى 25%، ما أدى إلى تقليل استخدام النطاق الترددي وتحسين أوقات التحميل.
شبكات توصيل المحتوى (CDN)
اختيار شبكة توصيل المحتوى الديناميكية
في Wix، استخدمنا دائمًا شبكات توصيل المحتوى (CDN) لعرض كل ملفَّي رمز JavaScript والصور على مواقع المستخدمين الإلكترونية.
لقد دمجنا مؤخرًا حلًّا من مقدّم خدمة نظام أسماء النطاقات (DNS) لتحديد شبكة توصيل المحتوى (CDN) الأفضل أداءً تلقائيًا وفقًا لشبكة العميل ومصدره. يتيح لنا ذلك عرض الملفات الثابتة من أفضل موقع جغرافي لكل زائر، وتجنُّب مشاكل التوفّر في شبكة توصيل محتوى معيّنة.
قريبًا، ستتوفّر نطاقات المستخدمين التي تُعرض من خلال شبكات توصيل المحتوى.
الخطوة الأخيرة هي عرض الجزء الأخير والأهم من خلال شبكة توصيل المحتوى (CDN): ملف HTML من نطاق المستخدم.
كما هو موضّح أعلاه، أنشأنا حلّاً داخليًا لتخزين ملفّات تعريف الارتباط وعرض نتائج HTML وواجهة برمجة التطبيقات الخاصة بالموقع الإلكتروني. إنّ الحفاظ على هذا الحلّ في العديد من المناطق الجديدة له أيضًا تكاليف تشغيلية، وتصبح إضافة مواقع جغرافية جديدة عملية علينا إدارتها وتحسينها باستمرار.
نحن نعمل حاليًا على الدمج مع مزوّدي شبكات توصيل المحتوى (CDN) المختلفين لتقديم موقع Wix الإلكتروني بالكامل مباشرةً من مواقع CDN لتحسين توزيع خوادمنا في جميع أنحاء العالم، وبالتالي تحسين أوقات الاستجابة بشكل أكبر. يشكّل ذلك تحدّيًا بسبب العدد الكبير من النطاقات التي نقدّمها، والتي تتطلّب إغلاق جلسة SSL في نقطة النهاية.
من خلال الدمج مع شبكات توصيل المحتوى (CDN)، تصبح مواقع Wix الإلكترونية أقرب إلى العملاء من أي وقت مضى، ويؤدي ذلك بدوره إلى تحسين تجربة التحميل، بما في ذلك تكنولوجيات جديدة، مثل HTTP/3، بدون أي جهد إضافي من جانبنا.
بضع كلمات عن مراقبة الأداء
إذا كنت تدير موقعًا إلكترونيًا على Wix، ربما تتساءل عن مدى تأثير ذلك في نتائج أداء موقعك الإلكتروني على Wix، وكيف نقارن بأنظمة المواقع الإلكترونية الأخرى.
تم تنفيذ معظم الأعمال المذكورة أعلاه في العام الماضي، وبعضها لا يزال قيد الطرح.
نشرت مجلة Web Almanac من HTTPArchive مؤخرًا إصدار 2020 الذي يتضمّن فصلاً رائعًا عن تجربة مستخدم نظام إدارة المحتوى. يُرجى العِلم أنّ العديد من الأرقام الموضّحة في هذه المقالة تعود إلى منتصف عام 2020.
نحن نتطلّع إلى الاطّلاع على التقرير المعدَّل في عام 2021، ونحن نرصد بنشاط تقارير CrUX الخاصة بمواقعنا الإلكترونية ومقاييس الأداء الداخلية.
نحن ملتزمون بتحسين أوقات التحميل باستمرار وتزويد المستخدمين بمنصّة يمكنهم من خلالها إنشاء المواقع الإلكترونية على النحو الذي يتخيلونه، بدون التأثير في الأداء.
أصدرت شركة DebugBear مؤخرًا مراجعة مهمة حول أداء أدوات إنشاء المواقع الإلكترونية، والتي تتناول بعض الجوانب التي ذكرناها أعلاه وتفحص أداء المواقع الإلكترونية البسيطة جدًا التي تم إنشاؤها على كل منصة. تم إنشاء هذا الموقع قبل عامين تقريبًا ولم يتم تعديله منذ ذلك الحين، ولكنّ المنصة تُجري تحسينات مستمرة، وبالتالي يزداد أداء الموقع الإلكتروني، ويمكن الاطّلاع على ذلك من خلال الاطّلاع على بياناته على مدار العام ونصف العام الماضيين.
الخاتمة
نأمل أن تلهمك تجربتنا لاعتماد ثقافة تركّز على الأداء في مؤسستك وأن تكون التفاصيل الواردة أعلاه مفيدة وقابلة للتطبيق على منصتك أو موقعك الإلكتروني.
باختصار:
- اختَر مجموعة من المقاييس التي يمكنك تتبُّعها باستمرار باستخدام أدوات معتمدة من العميل. ننصحك باستخدام "مؤشرات أداء الويب الأساسية".
- الاستفادة من ميزة التخزين المؤقت للمتصفّح وشبكات توصيل المحتوى (CDN)
- نقل البيانات إلى HTTP/2 (أو HTTP/3 إن أمكن)
- استخدِم ضغط Brotli.
نشكرك على الاطّلاع على قصتنا وندعوك إلى طرح الأسئلة ومشاركة الأفكار على Twitter وGitHub والانضمام إلى مناقشة أداء الويب على قنواتك المفضّلة.