أساسيات الويب الأساسية - Wix مقابل WordPress ، Shopify مقابل Shopware - ما هو الأسرع؟
نشرت: 2022-04-17- ملخص لنتائج سرعة الصفحة الرئيسية
- لماذا وقت تحميل الموقع مهم؟
- كيف يتم قياس أداء الموقع؟
- CMS: Jimdo الأسرع ، بل Wix أبطأ من WordPress
- أنظمة المتاجر: Shopify في منتصف الميدان ، WooCommerce في الأسفل
- CDNs. المواقع السريعة تستخدم Fastly
- الخلفية: ماذا (وكيف) قمنا بالقياس
- خاتمة
ستكون سرعة تحميل مواقع الويب عاملاً رسميًا في تصنيف Google العام المقبل ، وبما أن عملية التحسين ليست سهلة ، يجب أن تبدأ الآن.
لمساعدتك ، إليك ملخص سريع لأهم النتائج من تحليلنا:
ملخص لنتائج سرعة الصفحة الرئيسية
- 29 ٪ من أوقات التحميل في المملكة المتحدة غير مقبولة ، وفقًا لتوقعات Google: فهي أعلى من 2.5 ثانية كحد أقصى.
- ومع ذلك ، فإن الاتجاه يشير إلى الاتجاه الصحيح . زادت نسبة مواقع الويب السريعة بنسبة 2 في المائة في الأشهر الأخيرة.
- الوصول إلى مواقع الويب من المملكة المتحدة ليس بالسرعة التي يمكن أن يكون . تتصدر أوروبا سويسرا والسويد والنرويج وألمانيا.
- يوضح Jimdo أن CMS المستندة إلى مجموعة النظراء يمكن أن توفر قيمًا جيدة جدًا لـ Core Web Vitals. ولكن يمكن للمصدر المفتوح أيضًا القيام بذلك أيضًا - حيث يكون الخطأ Typo3 أبطأ قليلاً.
- لا يوجد CMS أبطأ من Wix . إنه حامل الملاعق الخشبية من فئة CMS. في المركز الأخير خلف WordPress ، يُظهر أن الحلول المستندة إلى السحابة ليست سريعة دائمًا.
- تقدم Lightspeed نظام متجر سريع للغاية. Shopify موجود فقط في النصف السفلي من القائمة. تعد WooCommerce الإضافية لـ WordPress هي أبطأ نظام متجر.
- لغة البرمجة ليست مهمة لتقنيات الويب: هناك أطر عمل سريعة في Ruby (on Rails) و PHP (Yii & Laravel) و Python (Django) ولغات أخرى. الزاوي فقط بطيء حقًا.
- لا يؤدي AMP تلقائيًا إلى مواقع ويب سريعة . فقط حوالي 70٪ من صفحات AMP تفي بمعايير Core Web Vitals.
إذا كان لديك المزيد من الوقت ، فإليك التحليل الكامل لجميع البيانات والعديد من النتائج الأخرى المثيرة للاهتمام حول أوقات التحميل والأنظمة السريعة والبطيئة والوصلات التي تقف وراءها.
لماذا وقت تحميل الموقع مهم؟
تعتبر تجربة المستخدم من أهم عوامل نجاح المواقع الإلكترونية. تعتبر أوقات التحميل أساس تجربة مستخدم جيدة لأنه إذا كان الزائر مضطرًا للانتظار (طويلاً) حتى يتم تحميل الصفحة ، فسوف يقفز ويبحث عن مصدر آخر.
في إحدى الدراسات ، وجدت Google أن زيادة وقت التحميل من ثانية واحدة إلى ثلاث ثوانٍ تؤدي إلى زيادة بنسبة 32 بالمائة في معدل الارتداد . إذا زاد وقت التحميل إلى خمس ثوانٍ ، يزداد احتمال مغادرة الزائر للصفحة بنسبة تصل إلى 90 بالمائة.
كيف يتم قياس أداء الموقع؟
هناك مجموعة متنوعة من الأدوات والأساليب لجعل تجربة المستخدم على مواقع الويب قابلة للقياس. باستخدام Core Web Vitals ، توفر Google ثلاثة أرقام رئيسية موحدة وقابلة للمقارنة. ستصبح مؤشرات الويب الحيوية الأساسية هذه أيضًا عاملاً تصنيفيًا في العام المقبل (2021) ، لذلك سيكون لها تأثير مباشر على موضع الصفحة في نتائج Google.
لقد أظهرنا بالفعل الخلفية وطرق القياس المختلفة وطرق تحسين عناصر الويب الحيوية الأساسية الثلاثة في مقال آخر. إذن هذا مجرد تذكير سريع:
- أكبر رسم محتوى (LCP) - الوقت الذي يستغرقه تحميل أكبر جزء من المحتوى. جيد: أقل من 2.5 ثانية.
- أول تأخير في الإدخال (FID) - الوقت حتى يتمكن المستخدم من التفاعل مع الصفحة. جيد: أقل من 0.1 ثانية.
- التحول في التخطيط التراكمي (CLS) - مؤشر لمدى تغير التخطيط أثناء التحميل. جيد: أقل من 0.1.
في هذا التحليل ، استخدمنا قيمة أكبر رسم محتوي ( LCP ) ، باستثناء الرسوم البيانية الأولى التي توضح جميع القياسات الثلاثة. من بين العناصر الحيوية الأساسية الثلاثة للويب ، هذه هي القيمة الأولية لقياس وقت تحميل الصفحة.
المملكة المتحدة - 29٪ من المواقع ليست بالسرعة الكافية
بالنسبة للخطوة الأولى ، قمنا بتحليل كيفية الوصول إلى مواقع الويب من المملكة المتحدة لأداء الشخصيات الرئيسية الثلاثة لـ Core Web Vitals . حددت Google ثلاث مناطق لكل منها:
- جيد (أخضر ) إذا كانت القيمة في حدود توقعات Google ،
- بحاجة إلى تحسين (أصفر) إذا كان أعلى من التوقعات ، ولكن لم يبتعد كثيرًا عنها و
- سيء (أحمر) إذا كانت القيمة المقاسة بعيدة عن الأهداف.
على هذا الأساس ، فيما يلي النتائج الخاصة بالمملكة المتحدة استنادًا إلى العناصر الأساسية الثلاثة للويب.
مع أكبر محتوى محتوى (LCP) ، 70٪ من جميع النتائج جيدة بالفعل. صنفت Google 12.9٪ من النتائج بأنها سيئة. LCP هو الرقم الرئيسي لأساسيات الويب الأساسية ، لأنه يعكس بشكل مباشر وقت التحميل الفعلي.
أول تأخير للإدخال (FID ) ، أي الوقت حتى التفاعل ، له أفضل القيم: 90٪ من عمليات الوصول جيدة بالفعل و 2٪ فقط صنفتها Google على أنها سيئة. إذا كان لا يزال لديك بعض الأعمال التي يتعين عليك القيام بها هنا ، فسيتعين عليك الإسراع حتى لا تتخلف عن الركب.
مع تغيير التخطيط التراكمي (CLS) ، تغيير التخطيط أثناء عملية التحميل ، من الملاحظ أن مواقع الويب إما تجتاز هذا الاختبار (باللون الأخضر) أو تفشل تمامًا (باللون الأحمر) - لا يوجد سوى حالات قليلة تتطلب التحسين فقط. (الأصفر).
الاتجاه الإيجابي: تزداد سرعة مواقع الويب قليلاً كل شهر
لفهم كيف تغيرت أوقات التحميل في الأشهر القليلة الماضية ، يُظهر التقييم التالي التغييرات الشهرية لأكبر لوحة محتوى خلال الأشهر الأخيرة:
التقدم ليس سريعًا ، لكن هناك اتجاه إيجابي طفيف. منذ نوفمبر 2019 ، انخفض عدد القياسات السيئة بنحو نقطتين مئويتين وزادت القياسات الجيدة من 73٪ إلى 75٪. الاتجاه إيجابي: مواقع الويب تزداد سرعة كل شهر.
الأجهزة اللوحية هي مجرد أجهزة كمبيوتر مكتبية سيئة
ننتقل إلى التحليل التالي حيث نفصل التقييم وفقًا لنوع الجهاز : سطح المكتب والهاتف المحمول والجهاز اللوحي. ها هي النتائج:
ليس من المستغرب أن يتم تحميل مواقع الويب بشكل أسرع على سطح المكتب مقارنةً بالهاتف المحمول. يعد الاتصال بالإنترنت السلكي في كثير من الأحيان والمزيد من قوة الحوسبة أمرًا حاسمًا هنا. ومع ذلك ، فإن الفرق بين سطح المكتب والهاتف المحمول أقل من المتوقع .
يعد الأداء الضعيف للأجهزة اللوحية أمرًا مثيرًا للاهتمام. أحد التفسيرات المحتملة هو أن الأجهزة اللوحية عادةً ما ترى إصدار سطح المكتب لمواقع الويب من خلال شاشتها الأكبر - لكن أجهزة الأجهزة اللوحية أكثر قابلية للمقارنة مع الهواتف الذكية. هذا يؤدي إلى أداء أقل بكثير في وقت التحميل.
المركز العشرون: يحتاج الوصول إلى موقع الويب من إنجلترا إلى تحسين
تعتمد القيم التي يقاسها المستخدم النهائي لـ Core Web Vitals جزئيًا فقط على أداء موقع الويب: تؤثر السرعة والإنتاجية والكمون لاتصال المستخدمين بالإنترنت أيضًا على النتيجة.
بصفتك مشغل موقع ، لا توجد طريقة لتحسين اتصال زوار موقعك بالإنترنت ، ولكن تحليل "أساسيات الويب الأساسية" لكل بلد يوضح هذه الاختلافات بوضوح شديد. فيما يلي تقييم مجموعة مختارة من البلدان:
في الصين وكوريا الجنوبية ، تتطابق نسبة 82٪ من جميع مواقع الويب مع توقعات أداء Google - وهي قيمة عالية والرائدة على مستوى العالم إلى حد بعيد. تليها دول الشمال (السويد والنرويج والدنمارك) وأيضًا اليابان وتايوان.
تحتل ألمانيا المركز التاسع في هذا التحليل: ثلاثة أرباع جميع طلبات المستخدمين تتوافق بالفعل مع توقعات سرعة Google. تحتل إنجلترا المرتبة 20 مما قد يعكس كمية المحتوى التي يتم استهلاكها من خارج الدولة ، ولا سيما من الولايات المتحدة الأمريكية ، وربما من الخدمات في أجزاء أخرى من أوروبا.
أوقات التحميل في روسيا والولايات المتحدة قابلة للمقارنة تقريبًا. تظهر القيم الضعيفة لتايلاند وفيتنام أنه لا يمكن دائمًا مساواة آسيا بالإنترنت السريع.
تُظهر كيريباتي ، وهي دولة جزرية في المحيط الهادئ ، آثار موقع بعيد للغاية واتصال بالإنترنت عبر الأقمار الصناعية: فقط حوالي ربع جميع عمليات الوصول جيدة بالفعل. تم تصنيف ما يقرب من 60٪ من عمليات الوصول على أنها سيئة من قِبل Google.
CMS: Jimdo الأسرع ، بل Wix أبطأ من WordPress
أنظمة إدارة المحتوى ( CMS ) هي العمود الفقري للإنترنت: يتم تشغيل معظم مواقع الويب على رأس هذه البرامج. من مصفف الشعر المجاور إلى SMB إلى الموقع الذي يستقبل ملايين الزوار كل يوم.

لقد قمنا بدمج قاعدة بياناتنا لتقنيات الويب مع قياسات Core Web Vitals حتى نتمكن من تقييم سرعات التحميل لأنظمة إدارة المحتوى الأكثر استخدامًا. دعنا ننتقل مباشرة إلى التحليل:
يقدم Jimdo ، مصمم مواقع الويب من هامبورغ ، ألمانيا ، أفضل أداء لـ Largest Contentful Paint. أكثر من 82٪ من عمليات الوصول إلى مواقع الويب التي تعمل على Jimdo تلبي توقعات أداء Google.
يُظهر Typo3 أنه حتى نظام إدارة المحتوى المستضاف ذاتيًا يمكنه أيضًا تقديم أداء جيد جدًا ، كما يظهر في المركز الثاني في التقييم. غالبًا ما يتذكر أي شخص تعرض للتطور باستخدام Typo3 التعقيد بالرعب. ومع ذلك ، هذا لا يؤثر على سرعة CMS المستندة إلى PHP.
WordPress ، إلى حد بعيد CMS الأكثر انتشارًا ، يتخلف كثيرًا في المرتبة الثانية عن المركز الأخير . يعمل ما يقرب من نصف مواقع الويب على WordPress - ولكن هناك أيضًا العديد ممن يستخدمونها ولا يضعون قيمة كبيرة في أوقات التحميل الجيدة. تصنف Google حوالي 20٪ من الزيارات على مواقع الويب استنادًا إلى WordPress على أنها سيئة ، و 21٪ أخرى بحاجة إلى تحسين.
حقيقة أن WordPress لا يحمل الملعقة الخشبية في هذا التحليل يرجع الفضل في ذلك إلى المزود الذي يحمل اسم Wix . يوفر هذا الحل السحابي فقط حوالي نصف جميع عمليات الوصول مع وقت تحميل جيد. ما يقرب من ربعهم صنفوا "حيوية الويب الأساسية" من Google على أنها سيئة .
هذا الأداء الضعيف جدير بالملاحظة بشكل خاص عندما تفكر في أن كل من الفائز في هذا التحليل (Jimdo) والخاسر (Wix) لهما نفس شروط البدء : الحلول السحابية التي يتحكم فيها الموفر في النظام بأكمله ويمكنه تحسين كل جزء (ولكن من الواضح أنه لا لا تفعل ذلك دائما).
أنظمة المتاجر: Shopify في منتصف الميدان ، WooCommerce في الأسفل
في وقت مبكر من عام 2006 ، قررت أمازون أن أوقات التحميل التي زادت بمقدار 0.1 ثانية تؤدي إلى انخفاض بنسبة 1٪ في المبيعات. لم يتحسن ذلك في آخر 14 عامًا. تعتبر أوقات التحميل الجيدة ذات أهمية أساسية للمحلات التجارية عبر الإنترنت.
ينتج عن الجمع بين قاعدة بيانات التكنولوجيا لدينا والبيانات الخاصة بأوقات التحميل التحليل التالي لجميع أنظمة المتاجر التي رأيناها كثيرًا في البرية المفتوحة للإنترنت:
الفائز ، Lightspeed ، يرقى إلى مستوى اسمه. المجالات التي تستخدم Lightspeed تساهم في تصنيف 93٪ "جيد" لأكبر رسم محتوى. فقط 2٪ تم تصنيفهم على أنهم سيئون. هذه هي أفضل الأرقام التي قمنا بقياسها في هذا التحليل في جميع التقييمات.
تتمتع Lightspeed بالميزة المتعلقة بالنظام وهي أنها حل سحابي. يتحكم الموفر في النظام بأكمله ويمكنه تحسين جميع المجالات للسرعة. يُظهر الحل المفتوح المصدر osCommerce أنه يمكن أيضًا تحقيق أوقات تحميل جيدة جدًا من خلال المتاجر ذاتية الاستضافة بنسبة جيدة جدًا تبلغ 84 ٪.
نجم الرماية الحالي Shopify يجعله فقط في النصف السفلي من التحليل. على الرغم من أنها تستخدم ، من حيث المبدأ ، نفس بنية خط الأساس مثل Lightspeed (يستضيفها المزود نفسه بالكامل) ، إلا أن هذه الميزة لا يتم تحويلها إلى أوقات تحميل أعلى من المتوسط.
ملحق WordPress WooCommerce يتخلف كثيرًا في المكان الأخير. يفي حاليًا ما يقل قليلاً عن نصف متاجر WooCommerce بمواصفات Google. 26٪ هي نسبة مقلقة في الواقع سيئة . حل الاستضافة ذاتية التشغيل مع مزودي الخدمات الجماعية ذوي الأداء المنخفض واضح هنا.
تقنيات الويب: AMP أبطأ من المتوقع
يتعامل هذا التقييم مع مجموعة متنوعة من تقنيات الويب: بدءًا من تقنيات الواجهة الخلفية لإنشاء مواقع الويب إلى مكتبات JavaScript و CSS للتصميم والتفاعل إلى Google AMP .
يسرد الجدول التالي فقط التقنيات ذات الاستخدامات الأكثر تحديدًا في بياناتنا. تم استبعاد تقنيات الويب الأقل استخدامًا. بالطبع ، يمكن فقط تقييم مواقع الويب المتاحة للجمهور. هنا التحليل:
يعتبر Ruby on Rails ، وهو إطار قائم على Ruby تم تطويره بواسطة مؤسس Basecamp ، الرائد إلى حد بعيد: ما يقرب من 85 ٪ من جميع مواقع الويب المزودة بهذه التقنية تقدم مواقع الويب ضمن الحدود التي وضعتها Google للحصول على تصنيف جيد لأكبر محتوى محتوى.
لكن أطر PHP مثل Yii (74٪) أو Laravel (73٪) تقدم أيضًا أوقاتًا جيدة. حتى لا يشعر أحد بالإهمال: يتم تمثيل Python أيضًا بشكل جيد في إطار عمل Django (75٪) و ASP.NET (77٪) يحتل المركز الثاني. ماذا نتعلم من هذا؟ السرعة لا تعتمد على لغة البرمجة بل على التنفيذ.
من الملاحظ أن AMP ليست من أسرع التقنيات. تُعد Accelerated Mobile Pages (AMP) مشتقًا من HTML تدفعه Google بشكل أساسي. يجب أن تعني القيود العديدة أن صفحات AMP يتم تحميلها على الهاتف المحمول بشكل أسرع بكثير من صفحات HTML التقليدية.
النتائج غير مقنعة: أقل من 70٪ من نطاقات AMP تفي بمتطلبات Google. من الواضح أن Google قد أدركت هذا بالفعل وستقوم في المستقبل أيضًا بتوريث امتيازات AMP في مربع Top Stories إلى المواقع التي تتمتع بأساسيات الويب الأساسية السريعة.
لن تكون AMP ضرورية بعد الآن لعرض القصص في "أهم الأخبار" على الجوّال ؛ سيكون مفتوحًا على أي صفحة .
مدونة Google Webmaster Central ، تقييم تجربة الصفحة للحصول على ويب أفضل
تقنية الويب الوحيدة التي تفشل في جعل أكثر من نصف المجالات تفي بمتطلبات Google هي Angular . ومن المفارقات ، أنه تم تطوير وتقديم إطار عمل لتطبيقات الواجهة الأمامية بواسطة Google ...
CDNs. المواقع السريعة تستخدم Fastly
توفر شبكات توصيل المحتوى (CDNs) خوادم موزعة في جميع أنحاء العالم بحيث يمكن أن يغطي المحتوى مسارات نقل أقصر وبالتالي أسرع إلى زائر الموقع. بالإضافة إلى المتخصصين مثل Akamai ، يقدم كبار مزودي الخدمات السحابية شبكات CDN.
في جوهرها ، تعمل جميع شبكات CDN بشكل مشابه. لا يمكنهم تغيير الحدود المادية لبنيتهم أيضًا. لذلك ، في التحليل التالي ، يجب التمييز بين السببية والارتباط :
لا يمكن الافتراض أن شبكات CDN الأسرع هي سبب الرائد ، ولكن مشغلي مواقع الويب المهتمين بالأداء قد يتراجعون عن شبكات CDN هذه.
المجالات التي تعتمد على Fastly كحمل CDN ، في المتوسط ، أسرع بكثير من تلك التي تعتمد على مزودين آخرين. غوغل في المرتبة الثانية ، أما أمازون ومايكروسوفت (أزور) فهما ليسا ببعيد عن الركب.
حقيقة أن Akamai يمكن العثور عليه في الخلف يمكن أن يكون له علاقة بعملاء Akamai النموذجيين: فهذه شركات دولية كبيرة إلى حد ما تعمل في كثير من الأحيان على أنظمة قديمة بطيئة - وليس أفضل شرط مسبق لتقديم مواقع ويب حديثة وسريعة.
لا يقدم Fireblade ، في الجزء السفلي من هذا التحليل ، شبكة CDN كلاسيكية ، ولكنه يوفر جدار حماية لتطبيق الويب : يقوم التطبيق بتصفية حركة مرور الإنترنت بحثًا عن مكالمات يحتمل أن تكون خطرة ويمنعها. أولئك الذين يتعين عليهم التراجع عن مثل هذه البنية ، في المتوسط ، سيعملون أيضًا على تشغيل تطبيقات الويب القديمة وغير المحسّنة ، وبالتالي لديهم بالفعل عيوب هيكلية في هذا التقييم.
الخلفية: ماذا (وكيف) قمنا بالقياس
قياس سرعات التحميل له تاريخ طويل: من القياس الأصلي لبداية تسليم HTML النقي ( TTFB ، الوقت حتى البايت الأول) إلى First Contentful Paint إلى القيم الثلاث المقاسة الحالية لـ Core Web Vitals باستخدام Largest Contentful Paint حيث أن المقياس المركزي قد تغير كثيرًا.
للتحليل ، استخدمنا قاعدة الحساب الرسمية لـ Google Core Web Vitals. هناك طريقتان مختلفتان للقياس لهذا: البيانات المختبرية ، أي القيم التي تم قياسها بنفسك في ظل ظروف المختبر الخاصة بك والبيانات الميدانية . يتم قياسها بواسطة لوحة المستخدم. قمنا بتقييم البيانات الميدانية لهذا التحليل. في SISTRIX ، يمكنك الوصول إلى كل من البيانات المختبرية والميدانية. في المجموع ، قمنا بتحليل أوقات تحميل 18.5 مليون نطاق.
باستثناء التقييمات الثلاثة الأولى ، والتي تتعلق حصريًا بالقيم المقاسة من المملكة المتحدة ، فإن التحليلات المتبقية تشمل قيمًا مُقاسة من جميع أنحاء العالم. يتم أيضًا تقييم قيم سطح المكتب والجوّال والجهاز اللوحي هناك.
لقد قمنا بدمج هذه القيم المقاسة مع اكتشاف التكنولوجيا في SISTRIX حتى نتمكن من الإدلاء ببيانات حول حلول البرامج ومجموعات التكنولوجيا. للتعرف على التكنولوجيا ، نقوم بانتظام بالزحف إلى أجزاء كبيرة من الإنترنت ومقارنة الميزات الموجودة ("بصمات الأصابع") بقائمتنا التي تضم أكثر من 1000 تقنية إنترنت ذات صلة. لقد قمنا فقط بتضمين مجموعات التكنولوجيا الأساسية والويب الحيوية في التحليل النهائي الذي يحدث مع عدد كافٍ من المجالات لتحقيق أهمية إحصائية.
خاتمة
تعمل Google على نقل تجربة المستخدم إلى دائرة الضوء من خلال جعل Core Web Vitals عامل ترتيب رسميًا. تمكنا في تحليلنا من إظهار مدى اتساع نطاق القيم حاليًا. اعتمادًا على البرامج والتكنولوجيا المستخدمة ، يتم تمثيل كل شيء بين "الكمال بالفعل" و "كومة من العمل".
مثل الكثير في مُحسّنات محرّكات البحث ، يجب أن يكون تحسين أوقات التحميل عملية مستمرة . إنها ليست مهمة لمرة واحدة ، ولكنها عملية مستمرة ومراقبة. سيتطلب اهتمامًا منتظمًا وستحتاج الأهداف إلى تعديل من وقت لآخر.
لا يعد تحسين أوقات التحميل مهمة تحسين محركات البحث الأساسية - ومع ذلك سيكون للتغيير تأثير على الأداء العضوي لموقع الويب في نتائج البحث. يعد تحسين محركات البحث (SEO) مرة أخرى وظيفة مقطعية يجب أن تجمع بين العديد من مجالات الشركة.
نحن أنفسنا أهملنا أوقات تحميل موقعنا لفترة طويلة. لقد تناولنا الموضوع في الأسابيع القليلة الماضية ولاحظنا مقدار الجهد (جدًا) الذي تتطلبه القيم الجيدة. ومع ذلك ، فإن الأمر يستحق كل هذا العناء: إذ إن Google ليست سعيدة به فحسب ، بل يشكرنا المستخدمون الحقيقيون على وجه الخصوص. لذلك: لا تنم عن الموضوع . من الأفضل أن نبدأ هذا العام بدلاً من تأجيله إلى العام المقبل.