لتسريع موقعك قِس أداءه أولاً في PageSpeed Insights وتقرير Core Web Vitals داخل Search Console، ثم ابدأ بما يؤثر أكثر: ضغط الصور وتحويلها إلى WebP أو AVIF، وتأجيل سكريبتات الطرف الثالث، وتفعيل التخزين المؤقت وشبكة CDN، وتحسين استجابة الخادم. الحدود التي تعتبرها Google جيدة: LCP خلال 2.5 ثانية، وINP حتى 200 مللي ثانية، وCLS حتى 0.1.
ما هي مؤشرات Core Web Vitals وما الحد الجيد لكل منها؟
مؤشرات Core Web Vitals ثلاثة مقاييس تستخدمها Google لتقييم تجربة الزائر الفعلية: سرعة ظهور المحتوى الرئيسي (LCP)، وسرعة استجابة الصفحة للنقر والكتابة (INP)، وثبات العناصر أثناء التحميل (CLS). يُقاس كل مؤشر عند الشريحة المئوية الخامسة والسبعين من زيارات الصفحة، وبشكل منفصل للجوال وسطح المكتب؛ أي أن ثلاثة أرباع الزيارات على الأقل يجب أن تحقق الحد الجيد.
| المؤشر | ماذا يقيس؟ | جيد | يحتاج تحسيناً | ضعيف |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | زمن ظهور أكبر عنصر مرئي في الشاشة الأولى، مثل صورة الغلاف أو العنوان الرئيسي | 2.5 ثانية أو أقل | من 2.5 إلى 4 ثوانٍ | أكثر من 4 ثوانٍ |
| INP (Interaction to Next Paint) | زمن استجابة الصفحة لتفاعلات الزائر طوال الزيارة: النقر واللمس والكتابة | 200 مللي ثانية أو أقل | من 200 إلى 500 مللي ثانية | أكثر من 500 مللي ثانية |
| CLS (Cumulative Layout Shift) | مقدار تحرك عناصر الصفحة فجأة أثناء التحميل | 0.1 أو أقل | من 0.1 إلى 0.25 | أكثر من 0.25 |
مصدر الحدود: صفحات LCP وINP وCLS على web.dev.
هناك مقياس رابع مهم رغم أنه ليس من Core Web Vitals: زمن وصول أول بايت من الخادم (TTFB). توصي web.dev بأن يكون 0.8 ثانية أو أقل لمعظم المواقع، لأن الخادم البطيء يؤخر كل ما بعده، وخاصة LCP.
لماذا حلّ مؤشر INP محل FID؟
في 12 مارس 2024 أصبح INP مؤشراً رسمياً ضمن Core Web Vitals بدلاً من FID. كان FID يقيس التأخير في أول تفاعل فقط، فيبدو الموقع جيداً حتى لو تجمّد لاحقاً عند فتح القائمة أو إضافة منتج إلى السلة. أما INP فيراقب تفاعلات الزيارة كلها ويسجل أطولها مع استبعاد القيم الشاذة في الصفحات كثيرة التفاعل، لذلك يكشف مشكلات JavaScript الثقيلة التي كان FID يخفيها.
هل تؤثر سرعة الموقع على ترتيبك في Google ومبيعاتك؟
نعم، لكن بحدود واضحة. تقول Google إن مؤشرات Core Web Vitals تُستخدم في أنظمة الترتيب، وفي الوقت نفسه تعرض النتيجة الأكثر صلة بالبحث حتى لو كانت تجربة صفحتها أضعف. أي أن السرعة ترجّح كفتك عندما يتقارب محتواك مع المنافسين، ولا تعوّض محتوى لا يجيب عن سؤال الباحث.
أثر السرعة على المبيعات أوضح. في دراسة «Milliseconds Make Millions» التي أجرتها Deloitte مع Google ونُشرت عام 2020 على مواقع 37 علامة تجارية، ارتبط تحسّن سرعة موقع الجوال بمقدار 0.1 ثانية بارتفاع معدل التحويل في مواقع التجزئة بنسبة 8.4%.
كيف تقيس سرعة موقعك بشكل صحيح؟
ميّز بين نوعين من البيانات قبل أن تحكم على موقعك:
- البيانات الميدانية (Field Data): قياسات من زوار حقيقيين على أجهزتهم وشبكاتهم. يعتمد تقرير Core Web Vitals في Search Console على بيانات CrUX لآخر 28 يوماً، وهي التي تعكس تقييم Google الفعلي.
- البيانات المعملية (Lab Data): محاكاة على جهاز وشبكة محددين، مثل Lighthouse في متصفح Chrome أو WebPageTest. مفيدة لاكتشاف السبب وتجربة الإصلاح قبل نشره، لكن نتائجها تتغير من اختبار لآخر.
يعرض PageSpeed Insights النوعين معاً. اختبر أولاً الصفحات التي تجلب المال: الرئيسية، وصفحات الخدمات أو المنتجات، وصفحة الدفع. واختبر على الجوال، لأن أجهزته وشبكاته أبطأ عادةً من سطح المكتب. وإذا كانت زيارات موقعك قليلة فقد لا تتوفر له بيانات ميدانية، فاعتمد على الاختبار المعملي مؤقتاً.
ما الخطوات التي تسرّع الموقع فعلاً؟
1. الصور: الحجم والصيغة وطريقة التحميل
- حوّل صور JPG وPNG إلى WebP أو AVIF. وفق Google، صور WebP المضغوطة أصغر بنسبة 25–34% من صور JPEG المماثلة في الجودة.
- قدّم الصورة بالمقاس الذي تُعرض به فعلاً عبر srcset، بدل رفع صورة عرضها آلاف البكسلات لتظهر في مربع صغير.
- استخدم loading="lazy" للصور أسفل الشاشة الأولى فقط. صورة الغلاف التي تمثل LCP لا تُؤجَّل؛ حمّلها مبكراً عبر rel="preload" أو fetchpriority="high".
- حدد width وheight لكل صورة، واحجز مساحة كل إعلان أو بانر، حتى لا تتحرك الصفحة عند ظهورها.
2. JavaScript وCSS
فريق سنابل يوفر لك دراسة فنية مخصصة لتحديد التقنيات المناسبة وتكلفة التنفيذ الدقيقة.
- صغّر الملفات (Minification)، واحذف الأكواد غير المستخدمة (Tree Shaking)، وقسّم الكود حسب الصفحة (Code Splitting).
- أجّل سكريبتات الطرف الثالث مثل Facebook Pixel وأدوات الدردشة والخرائط باستخدام defer أو async، أو حمّلها بعد أول تفاعل.
- ضع CSS اللازم للشاشة الأولى (Critical CSS) داخل الصفحة، وحمّل الباقي لاحقاً.
- قسّم مهام JavaScript الطويلة التي تشغل الخيط الرئيسي (Main Thread)، فهي أشهر أسباب ضعف INP.
3. الخطوط العربية
ملفات الخطوط العربية كبيرة نسبياً لأنها تحمل أشكال الحرف في أول الكلمة ووسطها وآخرها. استضف الخط على نطاقك، واكتفِ بالأوزان التي تستخدمها فعلاً بصيغة WOFF2، واضبط font-display مع خط بديل قريب المقاس حتى لا يتأخر ظهور النص أو يقفز عند اكتمال تحميل الخط.
4. التخزين المؤقت (Caching)
- في المتصفح: اضبط ترويسة Cache-Control بمدة طويلة للملفات الثابتة التي يتغير اسمها مع كل إصدار، مثل الصور والخطوط وملفات CSS وJS.
- على الخادم: خزّن نتائج الاستعلامات المتكررة في Redis أو Memcached، وخزّن الصفحات التي لا تختلف من زائر لآخر، مثل المقالات وصفحات الخدمات.
5. شبكة CDN وضغط النقل
توزع شبكة CDN مثل Cloudflare الملفات الثابتة على خوادم قريبة من الزائر، وتتيح ضغط Brotli وبروتوكول HTTP/3. تفيد بشكل خاص إذا كان خادمك في أوروبا أو أمريكا وزوارك في مصر والخليج.
6. الخادم وقاعدة البيانات
أضف فهارس (Indexes) على الأعمدة التي يُبحث بها كثيراً، وتخلص من استعلامات N+1 التي تنفذ عشرات الاستعلامات لعرض قائمة واحدة، وفعّل OPcache مع إصدار PHP مدعوم إن كان موقعك مبنياً بـ Laravel. وإذا بقي TTFB مرتفعاً بعد ذلك، فالمشكلة غالباً في الاستضافة نفسها؛ راجع كيف تختار استضافة موقعك.
المواقع التي يعود إليها الزوار كثيراً تستفيد أيضاً من Service Worker يخزّن واجهة الموقع على الجهاز، وهي الفكرة التي تقوم عليها تطبيقات الويب التقدمية PWA.
ما الأخطاء التي تُبقي الموقع في النطاق الأحمر؟
| المؤشر | أسباب شائعة | الإصلاح |
|---|---|---|
| LCP | صورة غلاف ضخمة غير مضغوطة، أو صورة غلاف مؤجلة بـ lazy، أو خادم بطيء، أو ملفات CSS تحجب العرض | ضغط الصورة وتحميلها مبكراً، وتحسين TTFB، وتقليل الملفات الحاجبة |
| INP | مهام JavaScript طويلة، وسكريبتات تتبع ودردشة كثيرة، وفلاتر تعيد بناء الصفحة كاملة عند كل نقرة | تقسيم الكود وتأجيل السكريبتات، وتقليل العمل الذي يحدث بعد كل تفاعل |
| CLS | صور وإعلانات بلا أبعاد، وشريط ملفات تعريف الارتباط أو بانر يُحقن أعلى الصفحة، وتبدّل الخط عند تحميله | حجز المساحة مسبقاً، وعرض البانرات المتأخرة فوق المحتوى بدل دفعه للأسفل، وضبط الخط البديل |
من أين تبدأ إذا كان الوقت والميزانية محدودين؟
| الأولوية | الإجراء | المؤشر الذي يتحسن غالباً | الجهد |
|---|---|---|---|
| 1 | ضغط الصور وتحويلها إلى WebP أو AVIF وتحديد أبعادها | LCP وCLS | منخفض |
| 2 | تفعيل CDN وضغط Brotli | TTFB وLCP | منخفض |
| 3 | تأجيل سكريبتات الطرف الثالث وحذف غير الضروري منها | INP وLCP | منخفض إلى متوسط |
| 4 | التخزين المؤقت في المتصفح والخادم | TTFB | متوسط |
| 5 | تقسيم JavaScript وتحسين الاستعلامات أو تغيير الاستضافة | INP وTTFB | متوسط إلى مرتفع |
أعد القياس بعد كل خطوة. وإن كان موقعك متجراً، فتابع أثر التحسينات على المبيعات كما يشرح مقال تحسين معدل التحويل في المتجر الإلكتروني.
ما الأسئلة المتكررة عن تسريع المواقع؟
هل يكفي ضغط الصور لتسريع الموقع؟
لا. ضغط الصور غالباً أسهل إصلاح، لكن البطء قد يأتي من سكريبتات تتبع ثقيلة، أو استضافة مشتركة مزدحمة، أو استعلامات قاعدة بيانات بلا فهارس. افحص TTFB وINP قبل أن تفترض أن الصور هي السبب.
لماذا تتغير نتيجة PageSpeed Insights من اختبار لآخر؟
الجزء المعملي من التقرير يتأثر بحمل الخادم لحظة الاختبار، وبالإعلانات والسكريبتات الخارجية، وبموقع خادم الاختبار. قارن متوسط عدة اختبارات، واعتمد في الحكم النهائي على البيانات الميدانية في Search Console.
هل تحسين Core Web Vitals يضمن تصدّر نتائج البحث؟
لا. تنص إرشادات Google على أن النتائج الجيدة في تقرير Core Web Vitals لا تضمن الظهور في أعلى النتائج؛ المحتوى المفيد والملائم للبحث يأتي أولاً.
هل يؤثر بطء الموقع على الإعلانات الممولة؟
نعم. الزائر الذي ينتظر طويلاً يغادر قبل أن يرى العرض فتضيع قيمة النقرة، وفي Google Ads تُعد تجربة صفحة الهبوط أحد المكونات الثلاثة لنقاط الجودة (Quality Score).
سنابل شركة برمجيات في طلخا بمحافظة الدقهلية تعمل على تصميم وتطوير المواقع. لمناقشة سرعة موقعك الحالي أو بناء موقع جديد، راسلنا على واتساب +20 103 673 3131 أو عبر البريد hello@snaabble.com، وتجد العنوان وطريقة الوصول في صفحة موقعنا.
