Core Web Vitals اسم غير مناسب لفكرة جيدة. تقيس هذه المقاييس ثلاثة أشياء يختبرها المتسوق مباشرة — كم من الوقت حتى تبدو الصفحة جاهزة، وكم من الوقت حتى تستجيب للنقر، وهل تتحرك تحت إصبعهم — وتبلغ Google عنها بالميلي ثانية، وهي الوحدة الأقل احتمالًا لتمويل مشروع.
هذه هي الترجمة. ثلاثة مقاييس، ما يكلفك كل منها، والسبب الخاص بـ Magento الذي يؤدي عادة إلى فشلها.
استخدم بيانات الحقل، لا بيانات المختبر. تقرير Core Web Vitals في Search Console يعرض ما اختبره الزوار الحقيقيون على أجهزة حقيقية خلال 28 يومًا متتالية. تشغيل Lighthouse على حاسوبك يعرض ما اختبره زائر واحد محاكى مرة واحدة.
Largest Contentful Paint (LCP): كم يستغرق حتى تبدو الصفحة جاهزة؟
أكبر طلاء محتوى يقيس متى ينتهي أكبر عنصر مرئي — عادة صورة رئيسية أو صورة منتج — من العرض. الحد الأقصى لجوجل هو 2.5 ثانية لتجربة جيدة، و4 ثوانٍ قبل أن يُصنف الأداء ضعيفًا.
من الناحية التجارية، LCP هو المقياس الذي يحدد ما إذا كان زائر من إعلان مدفوع سيرى منتجك. شخص نقر إعلان تسوق على هاتف باستخدام بيانات الجوال لديه فترة انتباه قصيرة وغير متسامحة؛ متجر يستغرق أربع ثوانٍ لعرض صورة منتج يدفع مقابل نقرات لا تتحول إلى مبيعات. إذا كنت تدير استحواذًا مدفوعًا، فإن LCP هو مقياس كفاءة الوسائط قبل أن يكون مقياسًا تقنيًا.
الأسباب المعتادة لمشاكل Magento
- زمن استجابة بطيء لأول بايت. فقدان ذاكرة التخزين المؤقت للصفحة كاملة، قاعدة بيانات صغيرة الحجم، أو تكوين Varnish توقف عن مطابقة هيكل URL الخاص بك. لا شيء في الواجهة الأمامية يمكنه إخفاء استجابة الخادم البطيئة.
- صور الكتالوج غير محسنة. صور المنتجات التي تم تحميلها بدقة الطباعة وتغيير حجمها في المتصفح. معالجة الصور في Magento تساعد، لكنها لا تنقذك من ملف مصدر بحجم 4 ميغابايت.
- CSS وJavaScript التي تعيق العرض. حزمة Luma الافتراضية تعيق الطلاء الأول؛ وكذلك تقريبًا كل سكربت خارجي يُضاف إلى الرأس.
- خطوط الويب بدون font-display: swap. النص موجود، جاهز، لكنه غير مرئي، ينتظر ملف الخط.
الترتيب مهم. إصلاح الصور بينما يستغرق الخادم 1.8 ثانية للرد هو تلميع السطح الخطأ. قِس زمن استجابة أول بايت أولاً؛ إذا كان فوق 600 مللي ثانية تقريبًا، فهذه هي مهمتك.
Interaction to Next Paint (INP): كم يستغرق حتى تستجيب الصفحة؟
التفاعل إلى الطلاء التالي يقيس التأخير بين نقر المتسوق على شيء واستجابة الصفحة بشكل مرئي. جيد أقل من 200 مللي ثانية؛ أي شيء يتجاوز 500 مللي ثانية يُصنف ضعيفًا ويشعر العميل بأن الموقع معطل.
INP هو المقياس الذي يكلفك عربات التسوق أكثر من الجلسات. يكون الأسوأ حيث يؤثر أكثر: اختيار لون على منتج قابل للتكوين، تغييرات الكمية في عربة صغيرة، نقرات الفلتر في صفحة الفئة، وخطوة طريقة الشحن في الدفع. متسوق ينقر على لون مرتين لأن لا شيء حدث في المرة الأولى قد أضاف سطرًا مكررًا إلى عربته أو، في الغالب، غادر.
الأسباب المعتادة لمشاكل Magento
- إعادة عرض Knockout.js على Luma. العربة الصغيرة والدفع هما أثقل واجهات Knockout في القالب، ولهذا السبب هما الأبطأ في الاستجابة.
- مديرو العلامات والسكربتات الشخصية الخارجية التي تنفذ مهام طويلة على الخيط الرئيسي بينما يحاول المتسوق استخدام الصفحة.
- التنقل الطبقي الذي يعيد تحميل الصفحة كاملة عند كل نقرة فلتر بدلاً من التحديث في المكان.
- ودجات الدردشة وودجات التقييم التي تبدأ بالتحميل بدلاً من التفاعل.
INP هو المقياس الأكثر احتمالًا أن يكون سببه شيء اشتريته وليس شيء بنيته. قم بتدقيق السكربتات الخارجية قبل تعديل القالب.
Cumulative Layout Shift (CLS): هل تتحرك الصفحة تحت إصبع المستخدم؟
التحول التراكمي في التخطيط يقيس الحركة غير المتوقعة — قفز المحتوى أثناء تحميل الصور أو اللافتات أو الويدجات المتأخرة. جيد أقل من 0.1.
CLS يكلفك بطريقتين، واحدة واضحة وأخرى غير واضحة. الواضحة هي النقرات الخاطئة: ينقر المتسوق على أضف إلى السلة، تظهر لافتة ترويجية فوقها، وينقر على شيء آخر. غير الواضحة هي الثقة. صفحة تتحرك أثناء التحميل تبدو غير محترفة، وفي الزيارة الأولى يؤثر هذا الانطباع بشكل ملموس على معدل التحويل.
الأسباب المعتادة لمشاكل Magento
- صور بدون سمات العرض والارتفاع، فلا يمكن للمتصفح حجز مساحة قبل وصول الملف.
- كتل CMS واللافتات الترويجية التي تُضاف فوق الجزء المرئي بعد الطلاء الأول.
- لافتات ملفات تعريف الارتباط والموافقة التي تدفع الصفحة للأسفل بدلاً من تغطيتها.
- ودجات الطرف الثالث — تقييمات، شارات الثقة، دردشة — تُضاف إلى حاويات بدون ارتفاع محجوز. هذا شائع جدًا، وغالبًا ما يكون قابلاً للإصلاح بسهولة.
CLS هو الأرخص من بين المقاييس الثلاثة للإصلاح والأكثر تركًا دون إصلاح، لأنه لا يبدو كمشكلة أداء. عادةً ما يكون بضع عشرات من أسطر CSS لحجز صناديق كان يجب حجزها دائمًا.
كيفية تحديد الأولويات عندما تفشل المقاييس الثلاثة معًا
نادراً ما تفشل المقاييس بالتساوي، ولا تستحق اهتمامًا متساويًا. ترتيبنا:
- CLS أولاً. الأرخص للإصلاح، الأسرع للتحقق، وهو إزالة سلبيات بحتة — لا يوجد مقايضة يجب وزنها.
- LCP ثانيًا، بدءًا بزمن استجابة أول بايت والصور. هنا يتسرب إنفاق الاستحواذ.
- INP أخيرًا، لأنه الأصعب والأكثر احتمالًا أن يتطلب إزالة شيء يحبه أحد أصحاب المصلحة.
قسّم حسب القالب قبل البدء. معظم متاجر Magento التي نفحصها لديها صفحة رئيسية ناجحة وصفحات فئة فاشلة، والعمل المطلوب على كل منها مختلف. المتوسطات العامة تخفي المشكلة التي تدفع ثمنها فعليًا.
كيف يظهر هذا على أرض الواقع
عندما تولينا متجر Careshop على Magento، كانت الشكوى الظاهرة هي المعتادة — شعور ببطء الموقع — وكانت الأسباب الأساسية موزعة على المقاييس الثلاثة والخادم خلفها. الترتيب أعلاه ليس نظريًا؛ إنه الترتيب الذي حقق نتائج دون إعادة بناء واجهة المتجر.
إذا بقيت فجوة كبيرة بعد هذا العمل، يصبح السؤال متعلقًا بالواجهة الأمامية، وقد كتبنا إطارًا مكلفًا لـ الاختيار بين Hyvä وPWA والبقاء على Luma. لا تبدأ من هناك. ابدأ بالقياس.
تحديد هدف واقعي
السعي لتحقيق درجة مثالية في Lighthouse هو استخدام غير فعّال لميزانية الهندسة. إشارة الترتيب من Google هي تقييم ناجح/راسب عند المئين الخامس والسبعين من الزيارات الحقيقية — تحتاج إلى أن تكون غالبية الجلسات الحقيقية جيدة، على القوالب المهمة. هذا هدف قابل للتحقيق على Magento دون الحاجة لإعادة بناء أي شيء.
لذا حدد الهدف على أنه: اجتياز قوالب الفئة والمنتج لجميع المقاييس الثلاثة في بيانات الميدان على الأجهزة المحمولة، مستمر على مدى نافذة 28 يومًا كاملة. هذا هدف يمكن لفريق الهندسة الالتزام به ويمكن لفريق المالية فهمه. أما الدرجة من 100 المقاسة على سطح المكتب فهي ليست كذلك.
هذا هو العمل الذي تبنى عليه مشاركاتنا في تحسين سرعة الصفحة، وللكتالوجات التجارية عادةً ما يكون أعلى الأعمال التقنية عائدًا في أي سنة معينة.
الأسئلة الشائعة
هل تؤثر Core Web Vitals بالفعل على ترتيب Google؟
هي إشارة ترتيب مؤكدة، لكنها إشارة ذات وزن نسبي أقل — فالصلة وجودة المحتوى لهما الأسبقية. الحجة التجارية الأقوى هي التحويل: نفس البطء الذي يفشل التقييم يكلفكم مبيعات بغض النظر عن تأثيره على موقعكم.
لماذا تختلف نتائج Search Console عن درجة Lighthouse لدي؟
كلاهما يقيسان أشياء مختلفة. Lighthouse اختبار مختبري على جهاز محاكٍ؛ بينما يقدم Search Console بيانات ميدانية من مستخدمي Chrome الفعليين خلال نافذة متدحرجة مدتها 28 يومًا. البيانات الميدانية هي التي تستخدمها Google وتعكس تجربة عملائكم الفعلية. توقعوا اختلاف الاثنين، وثِقوا بالبيانات الميدانية.
كم المدة قبل أن تتحرّك الأرقام بعد تطبيق التصحيح؟
نافذة البيانات الميدانية 28 يومًا، لذا فلن ينعكس التصحيح المنشور اليوم بالكامل إلا بعد 4 أسابيع، ولا يمكن الوثوق باتجاه الأداء حتى مرور 6 أسابيع. امتنعوا عن الحكم — أو الرجوع — خلال الشهر الأول.
ما المقياس الذي يجب على متجر Magento إصلاحه أولًا؟
CLS، في معظم الأحيان. هو الأرخص إصلاحًا والأسرع للتحقق، وعادةً ما يتعلق بحجز المساحة للصور والعناصر الخارجية. كما أنه المقياس الذي يُترك غالبًا غير ناجح لأنه لا يبدو كمشكلة في السرعة.
هل يمكننا اجتياز Core Web Vitals على السمة الافتراضية Luma؟
نعم. يتطلب عملاً منضبطًا — تدقيق الإضافات، تأجيل JavaScript، خط أنابيب للصور، ضبط الـcache والخادم — لكن اجتياز التقييم على Luma هدف واقعي لمعظم الكتالوجات. نقل السمة يرفع الحد الأعلى؛ لكنه ليس شرط الدخول.
اكتشفوا كم يكلفكم ذلك
سنقوم بتدقيق بيانات الميدان الخاصة بك حسب القالب، وتحديد أي من المقاييس الثلاثة يسبب المشكلة، ونخبرك بما يلزم لإصلاحها — مع احتساب امتدادات النظام بدلاً من تجاهلها. تحدث إلى فريقنا؛ نرد خلال يوم عمل.