تحسين سرعة الموقع: دليل Core Web Vitals عملي

تعلم تحسين سرعة الموقع عبر بيانات المستخدمين وCore Web Vitals: LCP وINP وCLS، ثم أصلح الصور والخادم وJavaScript والخطوط حسب الأثر.

تحسين سرعة الموقع يعني جعل المحتوى الأساسي يظهر بسرعة، والتفاعل يستجيب بلا تأخير، والعناصر تبقى ثابتة أثناء التحميل عند أغلب المستخدمين الحقيقيين. لا تختزل السرعة في درجة Lighthouse واحدة؛ فقد يسجل الاختبار المخبري نتيجة جيدة بينما يعاني عملاء الموبايل، أو يحدث العكس بسبب جهاز الاختبار والشبكة. ابدأ ببيانات Core Web Vitals الميدانية، وحدد الصفحة أو القالب والعنصر المسؤول، ثم أصلح أكبر عنق زجاجة وقس من جديد.

ما هي Core Web Vitals الحالية؟

تحدد web.dev ثلاثة مؤشرات أساسية: Largest Contentful Paint لسرعة ظهور أكبر محتوى، وInteraction to Next Paint لاستجابة الصفحة للتفاعلات، وCumulative Layout Shift للثبات البصري. الهدف الجيد هو LCP عند 2.5 ثانية أو أقل، وINP عند 200 مللي ثانية أو أقل، وCLS عند 0.1 أو أقل. ويُقاس النجاح عند المئين الخامس والسبعين، أي أن معظم الزيارات يجب أن تحقق الحد على الموبايل والكمبيوتر.

• LCP ≤ 2.5 ثانية: ظهور المحتوى الرئيسي بسرعة.
• INP ≤ 200ms: استجابة جيدة للنقر والكتابة والتفاعل.
• CLS ≤ 0.1: تغيّر بصري محدود وغير مفاجئ.
• استخدم المئين 75 وراجع الموبايل والكمبيوتر منفصلين.

الفرق بين بيانات المختبر وبيانات المستخدمين

PageSpeed Insights يعرض بيانات ميدانية من Chrome User Experience Report عندما يتوفر حجم كافٍ، ثم نتيجة Lighthouse مخبرية في بيئة محاكاة. الميدان يجيب: ماذا حدث لمستخدمين حقيقيين خلال فترة؟ والمختبر يساعدك على تكرار مشكلة وتشخيص الملفات والعناصر. لا تقارن رقمين من مصدرين كأنهما اختبار واحد. استخدم الميدان لتحديد الأولوية، والمختبر وDevTools لفهم السبب والتحقق السريع.

قد لا تتوفر بيانات لصفحة جديدة أو قليلة الزيارات، فتظهر بيانات الأصل أو لا تظهر. عندها اجمع Web Vitals في تحليلاتك أو استخدم أدوات مراقبة حقيقية، مع احترام الخصوصية، ثم اختبر أجهزة وشبكات تمثل جمهورك. افصل القوالب: صفحة المنتج قد تكون أبطأ من المقال بسبب الصور والتقييمات والتتبع، والصفحة الرئيسية لا تمثل المتجر كله.

1) حسّن LCP: المحتوى الرئيسي أولاً

استخدم DevTools أو تقرير Lighthouse لتحديد عنصر LCP. إذا كان صورة Hero أو منتج، صغّر أبعاد الملف، واستخدم WebP أو AVIF عند الملاءمة، وقدم srcset للأحجام، ولا تجعله lazy-loaded لأنه يحتاج أولوية. يمكن استخدام preload أو fetchpriority بحذر عندما يكون المورد معروفاً في HTML. إذا كان LCP نصاً، راجع الخط ووقت الخادم والـCSS الذي يمنع الرسم.

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

2) حسّن INP: اجعل التفاعل خفيفاً

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

لا تحذف وظائف مهمة لمجرد تحسين الرقم. حمّل الميزة عند الحاجة، واستخدم Web Worker للحساب المناسب، وقلل حجم DOM، واحذر listeners عامة تنفذ عملاً على كل تمرير أو إدخال. اختبر أجهزة متوسطة لا جهاز المطور السريع. وأظهر استجابة فورية آمنة، مثل حالة تحميل أو تعطيل زر الدفع بعد الضغط، بينما يكمل النظام العمل في الخلفية.

3) حسّن CLS: احجز المساحة قبل وصول المحتوى

حدد width وheight أو aspect-ratio للصور والفيديو، واحجز مكان الإعلانات والتضمينات، ولا تحقن شريطاً أعلى المحتوى بعد بدء القراءة. استخدم transform للحركة بدلاً من خصائص تغير التخطيط عندما يناسب، وحمّل الخط بطريقة تقلل اختلاف المقاس. الاستثناءات التي يسببها تفاعل المستخدم المباشر تُعامل بصورة مختلفة، لكن القاعدة البصرية بسيطة: لا تجعل الزر يتحرك تحت إصبع العميل.

4) الصور: أصلح الحجم والصيغة وطريقة التحميل

اعرض صورة بالمقاس الذي تحتاجه تقريباً، ولا ترسل ملفاً بعرض 4000 بكسل داخل بطاقة 400 بكسل. اختر جودة تحفظ التفاصيل المهمة، واستخدم صوراً متجاوبة، وفعّل lazy loading لما تحت الطي مع استثناء LCP. ضع CDN أو خدمة تحويل صور إذا كان الكتالوج كبيراً، لكن اختبر الكاش والتوقيعات والبدائل. لا تحول كل شيء عشوائياً؛ الشعارات والرسوم المسطحة قد تناسب SVG أو PNG أكثر.

1. استخرج أكبر الصور المنقولة في Network.
2. قارن الأبعاد الأصلية بالأبعاد المعروضة.
3. حوّل الصيغة واضبط الجودة.
4. أضف srcset وsizes للمقاسات المتجاوبة.
5. استثنِ صورة LCP من lazy loading.
6. أعد القياس على شبكة وجهاز ممثلين.

5) الخطوط وCSS: أظهر المحتوى بلا انتظار طويل

استخدم أوزاناً محدودة أو variable font مناسباً، وSubset للحروف عند امتلاك مسار صحيح، وfont-display وفق تجربة العلامة. حمّل الخطوط الحرجة من مصدر موثوق مع Cache، وقلل @import المتسلسل. استخرج CSS الحرج بحذر، واحذف الأنماط غير المستخدمة بعد التحقق من الحالات الديناميكية. ملف CSS صغير لكنه محمل بعد سلسلة من الطلبات قد يؤخر الرسم أكثر من ملف أكبر مكتشف مبكراً.

6) JavaScript والأدوات الخارجية

أنشئ قائمة بكل سكربت خارجي ومالكه وهدفه وآخر استخدام له. احذف أدوات التجربة القديمة والـpixels المكررة، وحمّل الدردشة أو الخرائط أو الفيديو عند التفاعل إذا أمكن، واستخدم defer أو async وفق الاعتماد. راقب Tag Manager؛ سهولة إضافة الوسوم قد تخفي تراكماً لا يراه فريق التطوير في المستودع. ضع ميزانية أداء تمنع عودة المشكلة بعد كل حملة.

7) الخادم وقاعدة البيانات والكاش

قِس Time to First Byte وافصل وقت DNS والاتصال والخادم. راجع الاستضافة وقرب المنطقة وCDN وHTTP الحديث والضغط، ثم افحص التطبيق: استعلامات N+1، وواجهات خارجية داخل الطلب، وقوالب غير مخزنة، وجلسات أو إضافات ثقيلة. استخدم Page Cache للصفحات المناسبة وObject Cache للبيانات المتكررة، مع قواعد إبطال واضحة حتى لا تعرض سعراً أو مخزوناً قديماً.

8) ضع ميزانية أداء داخل عملية النشر

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

ترتيب عملي لإصلاح موقع بطيء

1. حدد القالب المتأثر من بيانات الميدان.
2. اختر أسوأ مؤشر وعنصر أو تفاعل مسؤول.
3. افحص Network وPerformance ومسار الخادم.
4. أصلح أكبر سبب واحد واحفظ لقطة قبل وبعد.
5. تحقق من الوظيفة والتتبع والوصول.
6. انشر وراقب الميدان خلال الفترة التالية.
7. أضف قاعدة تمنع رجوع السبب في الإصدارات المقبلة.

أسئلة شائعة عن تحسين سرعة الموقع

هل نتيجة PageSpeed 100 ضرورية؟

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

ما أهم رقم أبدأ به؟

ابدأ بالمؤشر الفاشل عند المئين 75 لأهم قالب تجاري. إذا فشل LCP على صفحات المنتج، عالج العنصر ومسار تحميله؛ وإذا فشل INP عند الفلاتر أو السلة، شخّص التفاعل نفسه.

هل الاستضافة تحل كل مشكلات السرعة؟

قد تحسن TTFB والاستقرار، لكنها لا تصغر الصور أو تقلل JavaScript أو تمنع CLS. قس وقت الخادم أولاً، ثم قرر إن كانت الترقية أو التهيئة أو الكاش هي الأولوية.

كم يستغرق ظهور التحسن في بيانات الميدان؟

الاختبار المخبري يتغير فوراً، بينما بيانات CrUX تجمع تجربة المستخدمين عبر فترة متحركة وتحتاج زيارات كافية. احتفظ بقياس قبل وبعد وراقب الاتجاه، ولا تتوقع أن تعكس اللوحة الإصلاح في اللحظة نفسها.