الصفحة البطيئة المهمة ليست الصفحة الرئيسية

ملخص

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

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

خذ سيناريو عاشه كثير منا. أنت فريق التسويق بأكمله لشركة برمجيات B2B متوسطة الحجم. يحتوي الموقع على صفحة رئيسية ومدونة ومركز مساعدة وخمس صفحات هبوط مرتبطة بحملات إعلانية محددة. قرأ مديرك مقالًا عن Core Web Vitals أو سمع شكوى من عميل. التعليمات واضحة: اجعله أسرع.

كيف تتصرف في الساعة التالية يحدد ما إذا كنت ستقضي الشهر التالي في ضغط الصور أو في القيام بعمل يغير الأرقام المهمة.

ابدأ بالصفحة التي تجني المال، وليس بالصفحة التي تسبب الإحراج

المبدأ: عمل التسريع له عائد، وهذا العائد يعتمد على حركة المرور وقيمة التحويل. الصفحة ذات الحركة المنخفضة ولكن التحويل المرتفع قد تهم الشركة أكثر من الصفحة الرئيسية، حتى لو كانت أبطأ.

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

أنت لا تصلح الصفحة الرئيسية أولاً. أنت تصلح الصفحة التي تجني المال. هذا ليس خيارًا تقنيًا، بل خيارًا تجاريًا. إذا بدا أن التدقيق الفني الشامل هو الرد الصحيح، قاومه للحظة. التدقيق ينتج قائمة؛ لا يخبرك من أين تبدأ. تدقيق تحسين محركات البحث الفني المُحكَم هو أداة قرار، وليس رد فعل مذعور.

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

قسّم "سريع" إلى "مقاس" و "محسوس"

الخطوة الثانية هي الفصل بين ما تقوله اختبارات الأداء عن صفحتك وما يختبره المستخدمون الحقيقيون. توثق وثائق Google لمقاييس Core Web Vitals ثلاثة مقاييس تُحتسب في ترتيب البحث: Largest Contentful Paint (التحميل), Interaction to Next Paint (الاستجابة), و Cumulative Layout Shift (الاستقرار البصري). إنها مهمة لأنها تتبع اللحظات التي تؤثر على ما إذا كان شخص ما يستطيع استخدام الصفحة فعليًا.

في السيناريو، تفتح صفحة الهبوط في أداة اختبار الأداء وتحصل على درجة معقولة. ولكن عندما تقارن ذلك بالبيانات الميدانية في Google Search Console — التي تعكس تجارب الزوار الحقيقية — تظهر الصفحة بطيئة بشكل متكرر. هذه هي الإشارة المهمة. لا تزال الاختبارات المعملية مفيدة بعد إجراء تغيير، للمقارنة قبل وبعد. لكن البيانات الميدانية هي الحقيقة الأساسية للأشخاص الذين نقرّوا على إعلانك من أجهزة واتصالات متنوعة.

بدلًا من هذا	ابدأ بهذا	لماذا
درجة PageSpeed كرقم واحد	البيانات الميدانية لـ Core Web Vitals	البيانات الميدانية تأتي من مستخدمين حقيقيين، وليس من خادم اختبار
"الموقع بطيء"	أي الصفحات تدعم أهداف العمل	الصفحات السريعة غير المفيدة لا تولّد عملاء محتملين
إعادة بناء نظام إدارة المحتوى	ضغط الصور وتنظيف السكربتات	الإصلاحات منخفضة المخاطر تحقق معظم الفائدة

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

أصلح الأشياء الرخيصة قبل الأشياء المكلفة

المبدأ الثالث: لا تدع مشروع الأداء يتضخم ليصبح إعادة تصميم. معظم التحسينات التي تحرّك تجربة المستخدم فعليًا غير براقة ورخيصة.

انظر إلى صفحة الهبوط وحدد الأسباب الواضحة. الصور عبارة عن لقطات شاشة بدقة كاملة. هناك سكربت تابع لجهة خارجية على الصفحة لم يعد أحد يستطيع التعرف عليه. خط ويب يمنع عرض النص. هذه مشاكل مألوفة.

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

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

أضف البيانات المنظمة بينما أنت في الكود على أي حال

هذه هي الطبقة التي تفاجئ المدير. بعد إجراء الإصلاحات الرخيصة، تكون بالفعل داخل الصفحة. هذه هي اللحظة المناسبة لإضافة شيء ليس سرعة على الإطلاق: البيانات المنظمة.

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

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

ترجم الإصلاحات إلى "هل حققت المال؟"

الجزء الصعب ليس العمل التقني. إنه الطريقة التي تقدم بها الأمر لمدير غير تقني.

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

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

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

ماذا تفعل يوم الاثنين القادم

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

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