كيفية تحسين Wix لأداء المواقع الإلكترونية من خلال تطوير البنية الأساسية

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

بفضل الاستفادة من المعايير المتّبعة في المجال ومقدّمي خدمات السحابة الإلكترونية وإمكانات شبكة توصيل المحتوى (CDN)، بالإضافة إلى إعادة صياغة كبيرة لوقت تشغيل موقعنا الإلكتروني، ساهمت البياناتCrUXHTTPArchive

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

نظرة عامة

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

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

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

التحدث بلغة مشتركة

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

عدّلنا جميع أدوات المراقبة والمناقشات الداخلية لتشمل المقاييس المعايير المتّبعة في المجال، مثل مؤشرات أداء الويب التي تشمل ما يلي:

مدى تعقيد الموقع الإلكتروني ونتائج الأداء

من السهل جدًا إنشاء موقع إلكتروني يتم تحميله على الفور شرط أن تجعله بسيطًا للغاية باستخدام HTML فقط ويعرضه عبر شبكة توصيل المحتوى (CDN).

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

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

الرحلة

في البداية، كان هناك HTML

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

الماضي: العرض من جهة العميل (CSR)

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

تمكّنا CSR من استخدام مستند HTML مشترك، والذي كان فارغًا في الأساس. كل ما تم فعله هو بدء تنزيل التعليمات البرمجية المطلوبة والبيانات التي تم استخدامها بعد ذلك لإنشاء رمز HTML الكامل على جهاز العميل.

اليوم: العرض من جهة الخادم (SSR)

قبل بضع سنوات، انتقلنا إلى العرض من جهة الخادم (SSR)، حيث كان ذلك مفيدًا لكلٍ من تحسين محركات البحث والأداء، وتحسين الأوقات الأولية لظهور الصفحة، وضمان فهرسة أفضل لمحركات البحث التي لا تدعم بالكامل إمكانية تشغيل JavaScript.

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

لمحة عن التخزين المؤقت في مواقع جغرافية متعددة

كان HTML لكل موقع إلكتروني ثابتًا في الغالب، ولكن كان يحتوي على بعض التنبيهات:

1. حيث يتم تغييره بشكل متكرر. في كل مرة يُعدِّل فيها أحد المستخدمين موقعه الإلكتروني أو يُجري تغييرات في بيانات الموقع الإلكتروني، مثل التغييرات في مستودع متجر المواقع الإلكترونية.
2. كان يحتوي على بيانات وملفات تعريف ارتباط معيّنة خاصة بالزائر، ما يعني أنّ شخصين يزوران الموقع الإلكتروني نفسه سيظهران محتوى HTML مختلفًا إلى حدٍ ما. على سبيل المثال، لدعم ميزات المنتجات، مثل تذكُّر العناصر التي يضعها الزائر في سلة التسوق، أو المحادثة التي بدأها الزائر مع النشاط التجاري في وقت سابق، وغير ذلك.
3. ليست كل الصفحات قابلة للتخزين المؤقت. على سبيل المثال، الصفحة التي تحتوي على رمز مستخدم مخصص تعرض الوقت الحالي كجزء من المستند غير مؤهلة للتخزين المؤقت.

في البداية، اتّبعنا النهج الآمن نسبيًا للتخزين المؤقت لرمز HTML بدون بيانات الزائر، ثم عدّلنا أجزاء معيّنة فقط من استجابة HTML بسرعة لكل زائر، لكل نتيجة ذاكرة تخزين مؤقت.

حل داخلي لشبكة توصيل المحتوى (CDN)

وفعلنا ذلك من خلال نشر حل داخلي: باستخدام Varnish HTTP Cache في إنشاء الخادم الوكيل والتخزين المؤقت، وكافكا لرسائل الإبطال، وخدمة مستندة إلى Scala/Netty، والتي تعمل على إنشاء خوادم وكيلة لاستجابات HTML هذه، مع تغيير تنسيق HTML وإضافة بيانات وملفات تعريف ارتباط خاصة بالزائر إلى الاستجابة المخزّنة مؤقتًا.

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

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

تقليل التعقيدات

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

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

التخزين المؤقت للمتصفح (والاستعدادات لشبكات توصيل المحتوى (CDN))

وكانت الخطوة التالية هي إزالة هذه البيانات الخاصة بالزائر من ملف HTML بالكامل، واستردادها من نقطة نهاية منفصلة، يطلبها العميل لهذا الغرض، بعد وصول رمز HTML.

نقلنا هذه البيانات وملفات تعريف الارتباط بعناية إلى نقطة نهاية جديدة، والتي تُسمى عند كل تحميل صفحة، ولكنها تعرض ملف JSON رفيعًا، وهو مطلوب فقط لعملية تحويل صفحة الويب إلى صفحة ديناميكية، للوصول إلى التفاعل مع الصفحة بالكامل.

وقد سمح لنا هذا بتفعيل التخزين المؤقت في المتصفّح بلغة HTML، ما يعني أنّ المتصفّحات تحفظ الآن استجابة HTML للزيارات المتكررة، وتطلب من الخادم فقط التحقّق من أنّ المحتوى لم يتغيّر. ويتم ذلك باستخدام HTTP ETag، وهو في الأساس معرّف يتم تعيينه لإصدار معيّن من مورد HTML. إذا ظل المحتوى كما هو، ترسل خوادمنا الاستجابة 304 لم يتم التعديل إلى العميل، بدون نص.

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

نظام أسماء النطاقات وطبقة المقابس الآمنة وHTTP/2

مع تمكين التخزين المؤقت، تم تقليل أوقات الانتظار، وأصبحت الأجزاء المهمة الأخرى من الاتصال الأولي أكثر أهمية. مكننا تحسين البنية الأساسية للشبكات والمراقبة من تحسين أوقات نظام أسماء النطاقات والاتصال وطبقة المقابس الآمنة.

تم تفعيل HTTP/2 لجميع نطاقات المستخدمين، ما يقلّل من مقدار الاتصالات المطلوبة والنفقات العامة التي تنتج مع كل اتصال جديد. كان هذا التغيير سهل النشر نسبيًا، مع الاستفادة في الوقت نفسه من مزايا الأداء والمرونة المتوفّرة مع HTTP/2.

ضغط Brotli (مقارنةً بـ gzip)

في العادة، يتم ضغط جميع ملفاتنا باستخدام الضغط gzip، وهو خيار ضغط HTML الأكثر شيوعًا على الويب. تم تنفيذ بروتوكول الضغط هذا في البداية قبل 30 عامًا تقريبًا!

يقدّم ضغط Botli الجديد تحسينات للضغط بدون أيّ مساومة تقريبًا، كما أصبح أكثر رواجًا تدريجيًا، كما هو موضّح في فصل ضغطالويب السنوي. وقد كان متوافقًا مع جميع المتصفحات الرئيسية لفترة من الوقت.

لقد مكننا دعم Brotli على خوادم nginx الوكيلة لدى جميع العملاء الذين يستخدمونه.

أدى الانتقال لاستخدام ضغط Brotli إلى تقليل متوسط أحجام نقل الملفات بنسبة 21% إلى 25%، ما يؤدي إلى تقليل استخدام معدل نقل البيانات وتحسين أوقات التحميل.

شبكات توصيل المحتوى (CDN)

اختيار شبكة توصيل المحتوى (CDN) الديناميكية

في Wix، لطالما استخدمنا شبكات توصيل المحتوى (CDN) لعرض جميع رموز JavaScript والصور على المواقع الإلكترونية للمستخدمين.

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

قريبًا... نطاقات المستخدمين التي تعرضها شبكات توصيل المحتوى (CDN)

الجزء الأخير من اللغز هو عرض الجزء الأخير والأكثر أهمية، من خلال شبكة توصيل المحتوى (CDN): HTML من نطاق المستخدم.

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

نعمل حاليًا على الدمج مع العديد من مزوّدي شبكة توصيل المحتوى (CDN) لدعم عرض موقع Wix بالكامل مباشرةً من مواقع شبكة توصيل المحتوى (CDN) بهدف تحسين توزيع خوادمنا في جميع أنحاء العالم وبالتالي تحسين أوقات الاستجابة. ويشكّل هذا تحديًا بسبب العدد الضخم من النطاقات التي نعرضها، والتي تتطلب إنهاء طبقة المقابس الآمنة (SSL) على الحافة.

يؤدي الدمج مع شبكات توصيل المحتوى (CDN) إلى تقريب مواقع Wix الإلكترونية من العملاء أكثر من أي وقت مضى وتحسين تجربة التحميل، ويشمل ذلك استخدام تقنيات أحدث مثل HTTP/3 بدون أي جهد إضافي من جانبنا.

---

بضع كلمات حول مراقبة الأداء

إذا كنت تدير موقعًا إلكترونيًا على Wix، قد تتساءل عن كيفية ترجمة ذلك الموقع الإلكتروني إلى نتائج أداء موقعك الإلكتروني في Wix، ومقارنة ذلك بالمنصات الأخرى.

تم نشر معظم العمل المنجز أعلاه في العام الماضي، ولا يزال بعضه قيد الطرح.

نشرت دار "تقويم الويب" من HTTPأرشفة مؤخرًا إصدار 2020 الذي يتضمن فصلاً ممتازًا حول تجربة مستخدم نظام إدارة المحتوى (CMS). ضع في اعتبارك أن العديد من الأرقام الموضحة في هذه المقالة تعود إلى منتصف عام 2020.

نحن نتطلّع إلى الاطّلاع على التقرير المعدَّل في عام 2021، ونراقب باستمرار تقارير CrUX عن مواقعنا الإلكترونية، فضلاً عن مقاييس الأداء الداخلي لدينا.

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

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

الخلاصة

نأمل أن تلهمك خبرتنا لتبني ثقافة مبنية على الأداء في مؤسستك وأن التفاصيل الواردة أعلاه مفيدة وقابلة للتطبيق على منصتك أو موقعك الإلكتروني.

خلاصة القول:

• اختر مجموعة من المقاييس التي يمكنك تتبعها باستمرار باستخدام الأدوات المعتمدة من قبل الصناعة. ننصحك باستخدام "مؤشرات أداء الويب الأساسية".
• يمكنك الاستفادة من التخزين المؤقت في المتصفّح وشبكات توصيل المحتوى (CDN).
• عليك نقل البيانات إلى HTTP/2 (أو HTTP/3 إن أمكن).
• استخدام ضغط Brotli

نشكرك على معرفة قصتنا، وندعوك لطرح الأسئلة ومشاركة الأفكار على Twitter وGitHub والانضمام إلى المحادثة حول أداء الويب على قنواتك المفضّلة.

إذًا، كيف يبدو أداء موقعك الإلكتروني الأخير على Wix؟