تقارير وأبحاث حول شوبيفاي والتجارة الإلكترونية
مؤشر Largest Contentful Paint هو مؤشر Core Web Vitals الذي تفشل فيه متاجر Shopify بأوضح صورة، ومراجعتنا الخاصة تُظهر السبب: على 15 عرضًا توضيحيًا للقوالب الرسمية، وصل أول رسم في نحو 2 إلى 5 ثوانٍ، ثم انتظر المتسوقون حتى 13.9 ثانية إضافية لوسائط الهيرو. وفي ما يلي الآلية وقائمة الإصلاحات، بالأرقام.
يقيس Largest Contentful Paint لحظة واحدة: متى ينتهي عرض أكبر عنصر ظاهر في الشاشة الأولى. وفي متجر Shopify يكون ذلك العنصر دائمًا تقريبًا صورة الهيرو، أو أول صورة منتج، أو إطار ملصق لفيديو يُشغَّل تلقائيًا، وهذا بالضبط سبب فشل نتائج LCP في Shopify. تستجيب سيرفرات المنصة بسرعة ويُرسم هيكل القالب مبكرًا؛ ثم يحدّق المتسوق في هيكل فارغ بينما تزحف ميغابايتات من وسائط الهيرو عبر اتصال الهاتف.
بياناتنا الخاصة تجعل الآلية مرئية. في 14 يوليو 2026 أجرينا 45 مراجعة Lighthouse على 15 عرضًا توضيحيًا للقوالب الرسمية، والرقم المثير للاهتمام ليس LCP نفسه بل المسافة بين First Contentful Paint وLCP. فـ FCP هو وصول الهيكل؛ والفارق من FCP إلى LCP هو وسائط الهيرو وهي تجعل الجميع ينتظر.
| العرض التوضيحي للقالب | FCP | LCP | الفارق (انتظار الهيرو) |
|---|---|---|---|
| Ultra | 1.91s | 1.91s | 0.0s |
| Boutique | 2.20s | 3.67s | 1.5s |
| Symmetry | 1.53s | 6.33s | 4.8s |
| Impression | 5.22s | 12.19s | 7.0s |
| Horizon | 3.57s | 12.32s | 8.8s |
| Motion | 1.88s | 15.78s | 13.9s |
اقرأ صف Motion مرة أخرى: أول رسم في 1.88 ثانية، أسرع من كل ما اختبرناه تقريبًا، ثم انتظار 13.9 ثانية للهيرو. كود القالب ليس عنق الزجاجة؛ بل استراتيجية الوسائط. ويحكي Horizon القصة نفسها من زاوية أخرى: إجمالي زمن الحجب فيه كان 29ms، من أفضل سلوكيات JavaScript في المراجعة، مقابل LCP بمقدار 12.32 ثانية. هندسة رائعة، وعرض ثقيل.
والمثال المضاد يُثبت أن السقف حقيقي: في العرض التوضيحي لـ Ultra عُرض أكبر عنصر مع أول رسم، 1.91 ثانية لكليهما، وهو العرض التوضيحي الوحيد من أصل 15 الذي جاء دون حد Google البالغ 2.5 ثانية. هكذا تبدو الشاشة الأولى المنضبطة في البيانات.
1. زِن وسائط الهيرو. افتح صفحتك الرئيسية في PageSpeed Insights، ووسّع تشخيص LCP وانظر ما هو عنصر LCP فعلًا. إن كان صورة بحجم 2 إلى 4MB أو فيديو، فلا شيء آخر في هذه القائمة يهم حتى يتغير ذلك. صدِّر الهيرو بالمقاس المعروض، وقدِّمه بصيغة WebP أو AVIF عبر معاملات العرض في image_url في Shopify، واضبط حدًّا أقصى للملف قرب 200KB. وإن كان الهيرو فيديو يُشغَّل تلقائيًا، فأعطه إطار ملصق خفيفًا واترك الفيديو يُحمَّل بعد أول رسم، أو انقله أسفل الشاشة الأولى.
2. أوقف التحميل المتأخر لصورة LCP. خطأ إعداد شائع في Shopify: يطبّق القالب أو أحد التطبيقات loading="lazy" على كل شيء، بما في ذلك أول صورة هيرو، وهو ما يؤخّر التنزيل الوحيد الذي يحدّد نتيجتك. ينبغي أن تُحمَّل صورة LCP بشكل فوري وبأولوية جلب عالية؛ وكل ما هو أسفل الشاشة الأولى يبقى بتحميل متأخر.
3. راجِع منظومة التطبيقات. كل تطبيق مثبّت يمكن أن يُدخل سكربتات تُشغَّل قبل أن يبدأ تنزيل الهيرو. أزِل ما لا تستخدمه فعليًا، ثم افحص كود القالب بحثًا عن وسوم سكربت يتيمة تركتها التطبيقات. وتوثيق الأداء الخاص بـ Shopify يشير إلى وزن التطبيقات كعامل رئيسي في سرعة القالب.
4. خفِّف الشاشة الأولى. عروض شرائح بخمس شرائح بحجم 2MB لكل منها، أشرطة إعلانات متحركة، أدوات محادثة تبدأ العمل فورًا: كل واحدة منها تنافس عنصر LCP. الشاشة الأولى تحتاج إلى رسالة واحدة وصورة واحدة.
5. وبعد ذلك، وبعد ذلك فقط، فكّر في القالب. اختيار القالب يحدّد سقفك. قِسنا فارقًا بمقدار 8 أضعاف بين أسرع العروض التوضيحية وأبطأها في المتجر نفسه، وتحت شروط متطابقة، وكان الفرق في معظمه انضباطًا: مقدار ما تحمله الشاشة الأولى الافتراضية للقالب. إن كنت تبحث بالفعل عن بديل، فترتيبنا الكامل لـ 15 عرضًا توضيحيًا مقيسًا هو نقطة البداية، والمزوّد الذي تصدّر عرضه التوضيحي القائمة، UTD، يعرض كل قوالبه هنا. لكن تبديل القالب في حين أن وزن الهيرو لديك 3MB لا يفعل سوى نقل المشكلة نفسها إلى خطوط أجمل.
قِس قبل وبعد، بالطريقة نفسها كل مرة. Lighthouse في Chrome DevTools أو PageSpeed Insights، ملف تعريف الهاتف، ثلاث جولات، وخُذ الوسيط، لأن الجولات المنفردة تتذبذب. راقب رقمين: LCP نفسه، والفارق من FCP إلى LCP من الرسم البياني أعلاه. إن نجحت إصلاحاتك، فسينهار الفارق أولًا، وهذه هي إشارتك إلى أن الهيرو أصبح يصل أخيرًا مع الصفحة لا بعدها. أما بيانات المستخدمين الحقيقيين في تقرير Core Web Vitals داخل Search Console فستتبع ذلك خلال أسابيع قليلة، لأن Google تقيس LCP على بيانات الميدان، لا على جولات المختبر.
السبب في الغالب الأعم هو أن أكبر عنصر ظاهر في الشاشة الأولى هو صورة هيرو ثقيلة أو فيديو يُشغَّل تلقائيًا ويبدأ تنزيله متأخرًا. وتُظهر بيانات مراجعتنا هذا النمط بوضوح: عروض توضيحية بأول رسم سريع سجّلت مع ذلك قيم LCP تتراوح بين 8 و14 ثانية عندما كانت وسائط الهيرو ثقيلة. والتطبيقات التي تُدخل سكربتات تحجب العرض تؤخر بدء ذلك التنزيل أكثر.
حدود Google هي: أقل من 2.5 ثانية جيد، وأكثر من 4 ثوانٍ ضعيف، مقيسة لمستخدمين حقيقيين على الهاتف. وللمقارنة، عرض توضيحي واحد فقط من أصل 15 عرضًا رسميًا للقوالب راجعناها تحت خفض محاكى لسرعة الهاتف جاء بأقل من 2.5 ثانية.
قد يفعل، وهو قرار السرعة الوحيد الذي تتخذه مرة واحدة. قِسنا فارقًا بمقدار 8 أضعاف في وسيط LCP على الهاتف بين أسرع عرض توضيحي لقالب (1.91s) وأبطأها (15.78s). لكن أصلِح وسائط الهيرو ومنظومة تطبيقاتك أولًا: القالب السريع مع هيرو بحجم 4MB سيفشل أيضًا.
نعم. كل تطبيق يُدخل سكربتًا إلى قالبك ينافس صورة LCP على النطاق الترددي وعلى وقت الخيط الرئيسي قبل أول رسم. راجِع تطبيقاتك المثبّتة، وأزِل ما لا تستخدمه، وتحقّق مما إذا كانت وسوم سكربت متبقية لا تزال موجودة في كود القالب بعد إلغاء التثبيت.