ماذا يفعل LCP بأربع ثوانٍ بمعدّل تحويل صفحة الدفع لديك
أربع ثوانٍ تبدو قليلة. عند الدفع، هي الفرق بين عملية بيع مكتملة وسلّة مهجورة.
العميل اتخذ قرار الشراء بالفعل. وضع المنتج في السلّة، أخرج البطاقة من المحفظة، ضغط على إتمام الطلب. ثم يبقى محدّقًا في شاشة شبه فارغة لأربع ثوانٍ.
هذه الثواني الأربع هي مقياس Largest Contentful Paint لديك. إنه الوقت حتى يظهر أكبر عنصر مرئي في الصفحة. في صفحة الدفع، يكون عادةً ملخّص الطلب أو زر الدفع. وما دام لم يظهر، فلا شيء أمام العميل يفعله. مجرّد انتظار وشكّ.
الشكّ هو المشكلة. الـ LCP البطيء لا يُعطّل الصفحة وحدها. يُعطّل قرار الشراء الذي اتُّخذ بالفعل.
الرقم الذي يجب أن تعرفه
تحدّد Google ثلاث فئات للـ LCP. حتى 2.5 ثانية: جيد. بين 2.5 و4 ثوانٍ: يحتاج إلى تحسين. فوق 4 ثوانٍ: ضعيف. صفحة الدفع لديك عند 4 ثوانٍ تقف على الجانب الأسوأ تمامًا من هذا الحدّ.
وهذا ليس أمرًا شكليًا. نشرت Google نفسها أنه كلما ارتفع زمن التحميل من ثانية واحدة إلى ثلاث ثوانٍ، يرتفع احتمال مغادرة المستخدم للصفحة بنسبة 32%. ومن ثانية إلى خمس ثوانٍ، يرتفع بنسبة 90%. صفحة الدفع لديك تعيش في منطقة الخطر هذه بالضبط.
قاست Akamai، في دراسة للبيع بالتجزئة عبر الإنترنت عام 2017، أن تأخيرًا بمقدار 100 ميلي ثانية فقط يخفض معدّل التحويل بنسبة 7%. مئة ميلي ثانية. أنت لديك أربعة آلاف ميلي ثانية زيادة عمّا يجب.
لماذا صفحة الدفع هي أسوأ مكان للبطء
هناك فرق بين صفحة عرض منتجات بطيئة وصفحة دفع بطيئة. في صفحة العرض، العميل يتصفّح. صبره أكبر لأن نيّته لا تزال غير محسومة.
في صفحة الدفع، النيّة في ذروتها والصبر في حضيضه. العميل بذل المجهود الذهني لاتخاذ قرار إنفاق المال. كل ثانية انتظار تفتح نافذة للتردّد. يتذكّر أنه لا يحتاج تلك السلعة فعلًا. يفكّر في مقارنة الأسعار في مكان آخر. يصله إشعار فيغادر.
أنت لا تخسر زائرًا فضوليًا. أنت تخسر عملية بيع كنت قد ربحتها بالفعل.
ما الذي يلتهم عادةً ثوانيك الأربع
في معظم صفحات الدفع البطيئة، السبب ليس غامضًا. إنه متوقّع. انظر إلى النمط المعتاد:
- نصوص برمجية من أطراف خارجية تحجب عرض الصفحة — أدوات الدردشة، بكسلات إعادة التسويق، مديرو الوسوم المحمّلون بشكل متزامن في أعلى الصفحة.
- صور المنتج بلا أبعاد محدّدة، وبلا صيغة حديثة (AVIF أو WebP)، وبلا تحميل كسول صحيح، مما يجبر المتصفّح على الانتظار.
- استجابة بطيئة من الخادم — زمن مرتفع حتى أول بايت (Time to First Byte) لأن الصفحة تُولَّد عند الطلب بلا تخزين مؤقت، بدل تقديمها معروضة مسبقًا.
- خطوط ويب تحجب النص حتى يكتمل تنزيلها، فيبقى زر الدفع مخفيًا أطول مما ينبغي.
- إفراط في JavaScript يجب تنزيله وتحليله وتنفيذه قبل أن تصبح الصفحة قابلة للاستخدام.
انتبه إلى تفصيل مهم. لا تكاد أيٌّ من هذه المشكلات تتعلق بتصميم الصفحة. كلها قرارات هندسية. لهذا يستثمر كثيرون في إعادة تصميم صفحة الدفع دون أن يتحرّك معدّل التحويل. المشكلة لم تكن يومًا في لون الزر.
كيف تعالج هذا بجدّية
أولًا، قِس ببيانات مستخدمين حقيقيين، لا على حاسوبك المحمول بخط ألياف بصرية فقط. يُظهر لك تقرير Chrome User Experience Report و Search Console الـ LCP الذي يعانيه عملاؤك الحقيقيون، على هواتفهم، على شبكتهم. تلك هي الحقيقة التي تهم.
بعد ذلك، حدّد عنصر الـ LCP الفعلي في صفحة الدفع لديك. أدوات مطوّري Chrome تخبرك بالضبط أيّ عنصر هو. لا تخمّن. حسّن هذا العنصر أولًا، فهو الذي يحدّد المقياس.
- اعرض صفحة الدفع مسبقًا أو قدّمها من تخزين مؤقت لخفض زمن أول بايت إلى ما دون 800 ميلي ثانية.
- أجّل أو حمّل بشكل غير متزامن كل النصوص الخارجية — بكسل Facebook لا يحتاج إلى حجب زر الدفع.
- قدّم الصور الحرجة بصيغة AVIF أو WebP، بأبعاد صريحة وأولوية عالية لعنصر الـ LCP.
- استخدم font-display swap ليظهر النص فورًا، دون انتظار الخط.
- احذف JavaScript غير اللازم للعرض الأول وقسّم الحزمة.
يستحق فعل هذا قبل أي حملة مدفوعة لجلب الزيارات. لا معنى للدفع لجلب عملاء إلى صفحة دفع تفقدهم في الثواني الأربع الأولى. أنت تملأ دلوًا مثقوبًا.
الحساب الذي لا أحد يريد إجراءه
خذ معدّل هجر السلّة لديك. قاطعه مع بيانات الـ LCP من Search Console. إن كانت صفحة الدفع لديك فوق 4 ثوانٍ على الهاتف، فجزء من خسارتك ليس اعتراضًا على السعر ولا نقصًا في الثقة. إنه مجرّد بطء.
والبطء هو مشكلة التحويل الوحيدة التي تُحلّ دون تغيير كلمة واحدة من نصوصك ولا سنت واحد من سعرك. تُحلّ بالهندسة. إنه من أعلى الاستثمارات عائدًا التي يمكن لمشروع عبر الإنترنت أن يقوم بها.
قِس الـ LCP لديك هذا الأسبوع. إن كان عند 4 ثوانٍ، فأنت تعرف الآن أين التسريب.