عن المؤسس14 أكتوبر 20264 دقائق قراءة

عبدالله سنكر يشرح سرعة موقعك: Core Web Vitals بلغة صاحب المشروع

عبدالله سنكر يشرح Core Web Vitals بلغة صاحب المشروع: وش يقيس LCP و INP و CLS، ومن وين تجي الأرقام، ووش تطلب من مطوّرك عشان يصير موقعك أسرع فعلاً عند زوارك.

عبدالله سنكر — سرعة الموقع
AZHAL

سرعة الموقع

عبدالله سنكر

يقول لك أحد «موقعك بطيء»، تفتحه من جوالك وتشوفه طبيعي، وما تدري مين تصدّق. المشكلة إن «السرعة» كلمة واسعة. جوجل حوّلها لثلاثة مقاييس محددة اسمها Core Web Vitals، ويعتبرها من إشارات تجربة الصفحة. عبدالله سنكر يبني مواقع بـ Next.js ويراقب هذي المقاييس في مشاريعه، وهنا يشرحها لك بدون مصطلحات زيادة: وش يقيس كل واحد، ووش اللي يخرّبه عادةً.

LCP: متى يشوف الزائر الشي المهم؟

هذا المقياس يقيس الوقت حتى يظهر أكبر عنصر في الشاشة الأولى، وغالباً يكون صورة الواجهة الرئيسية أو العنوان الكبير. هو جواب سؤال الزائر: «هل الصفحة اشتغلت؟». الحد الجيد عند جوجل ٢٫٥ ثانية أو أقل. وأشهر أسباب تأخيره: صورة رئيسية حجمها كبير جداً، أو خادم بطيء الرد، أو خطوط وسكربتات تمنع الصفحة من الرسم قبل ما تتحمّل. وفي المواقع العربية يتكرر سبب محدد: صورة واجهة ضخمة عليها عنوان بخط عربي مخصص، فيتأخر الاثنين مع بعض.

INP: هل الموقع يستجيب لما أضغط؟

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

CLS: هل الصفحة تتحرك تحت يدك؟

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

من وين تجي الأرقام؟ مختبر وواقع

لما تفتح PageSpeed Insights على موقعك، تشوف نوعين من الأرقام. الأول بيانات المستخدمين الحقيقيين من تقرير تجربة مستخدمي كروم، وهي اللي تعبّر عن زوارك فعلاً، وتُحسب عند الشريحة الخامسة والسبعين: يعني ثلاثة أرباع الزيارات تقريباً لازم تكون ضمن الحد الجيد. والثاني اختبار المختبر من Lighthouse، محاكاة لجهاز وشبكة محددين، مفيد للتشخيص لكنه مو الحكم النهائي.

موقعك ممكن ياخذ درجة عالية في المختبر ويكون متعباً لزوارك الحقيقيين، لأنهم على جوالات متوسطة وشبكات متقلّبة. والمواقع الجديدة أو قليلة الزيارات ما يكون لها بيانات حقيقية كافية، فتعتمد على المختبر مؤقتاً. والبيانات الحقيقية تنقسم للجوال والكمبيوتر، ولو أغلب زوارك على الجوال، فأرقام الجوال هي اللي تبدأ منها. ولو موقعك مربوط بـ Search Console، فيه تقرير خاص يجمّع صفحاتك حسب حالتها في هذي المقاييس.

وش تطلب من مطوّرك؟

  • ضغط الصور وتقديمها بصيغ حديثة مثل WebP أو AVIF، بمقاس يناسب الشاشة، مع تحديد العرض والارتفاع. في Next.js مكوّن الصور المدمج يتكفّل بأغلب هذا.
  • تحميل الصورة الرئيسية بأولوية، وتأجيل الصور اللي تحت الشاشة الأولى.
  • تخفيف الخطوط: أوزان أقل، وتقسيم الملف للحروف المستخدمة، وإعداد font-display مناسب.
  • مراجعة كل سكربت خارجي: كل أداة تتبع أو دردشة أو خريطة تضيفها لها ثمن في سرعة الاستجابة.
  • حجز مساحة ثابتة لأي بنر أو عنصر يظهر متأخراً.
  • استضافة قريبة من جمهورك أو شبكة توزيع محتوى، عشان الخادم يرد بسرعة.

ثلاثة مفاهيم خاطئة

الأول: «الدرجة ١٠٠ في PageSpeed هي الهدف». الدرجة ملخّص لاختبار المختبر، والمهم إن المقاييس الثلاثة عند زوارك الحقيقيين في المنطقة الخضراء. الثاني: «الصفحة الرئيسية سريعة، إذن الموقع سريع». التقييم على مستوى الصفحات، وصفحة المنتج أو المقال اللي يجي لها الزوار من البحث ممكن تكون أثقل بكثير من الرئيسية. الثالث: «السرعة تكفي للتصدّر». هذي المقاييس جزء من إشارات كثيرة، والمحتوى المفيد يبقى الأساس. الموقع السريع بمحتوى ضعيف ما يتصدّر، لكن المحتوى القوي على موقع بطيء يخسر زواراً كان ممكن يكسبهم.

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

عندك فكرة؟ الاستشارة الأولى علينا

كلّم عبدالله مباشرة على واتساب — رسالتك توصل له هو، مو لرد آلي. نسمع فكرتك ونقول لك وش تحتاج وكم تكلّف، ببلاش.

مقالات ذات صلة

كل المقالات
عبدالله سنكر — وصف المنتج في المتجر الإلكتروني
AZHAL

وصف المنتج في المتجر الإلكتروني

عبدالله سنكر

13 أكتوبر 20264 دقائق قراءة

عبدالله سنكر يعيد كتابة وصف منتج من أسئلة الواتساب حتى يبيع

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

اقرأ المقال
عبدالله سنكر — التخزين المؤقت
AZHAL

التخزين المؤقت

عبدالله سنكر

13 أكتوبر 20264 دقائق قراءة

عبدالله سنكر يشرح التخزين المؤقت Caching في المواقع والتطبيقات طبقة طبقة

عبدالله سنكر يشرح التخزين المؤقت Caching في المواقع والتطبيقات طبقة طبقة: المتصفح، وشبكة التوزيع، والخادم، والجوال، ومتى يسرّع موقعك ومتى يعرض بيانات غلط.

اقرأ المقال
عبدالله عبدالرحيم بن سنكر — تعلم الذكاء الاصطناعي ذاتياً
AZHAL

تعلم الذكاء الاصطناعي ذاتياً

عبدالله عبدالرحيم بن سنكر

14 أكتوبر 20264 دقائق قراءة

عبدالله عبدالرحيم بن سنكر: خريطة تعلّم ذاتي للذكاء الاصطناعي

مسار تعلّم ذاتي في الذكاء الاصطناعي يرتّبه عبدالله عبدالرحيم بن سنكر من دوراته الفعلية في Anthropic و OpenAI Academy: بأي ترتيب تاخذها، ووش تطبّق بين كل مرحلة والثانية.

اقرأ المقال