السرعة ومؤشرات Core Web Vitals
أعالج سبب بطء الموقع. لا العَرَض.
معظم أعمال تحسين السرعة إضافة للتخزين المؤقت، وأداة ضغط، واختبار جديد مليء بالأمل. هذا يحرّك نتيجة المختبر ويترك المشكلة الفعلية مكانها. أقيس أين يذهب الوقت فعلًا، وأصلح تلك المواضع، وأعطيك مقارنة قبل وبعد تستطيع إعادة إنتاجها على جهازك.
01عرض حيمباشرة من متصفحك
هذه الصفحة، مقيسة وأنت تقرؤها.
يستطيع أي بائع لخدمات السرعة أن يريك لقطة شاشة لتشغيل جيد. أما هذه فهي الأرقام التي سجّلها متصفحك أنت أثناء تحميل هذه الصفحة، مقارنةً بالحدود التي تعتمدها Google. افتح تبويب الشبكة وتحقّق منها.
الشيفرة والأنماط والسكربت وثلاثة خطوط — كل ما يلزم لعرض ما تقرؤه.
الوزن الوسيط لصفحة الويب كما سجّله HTTP Archive.
02التشخيصأين يذهب الوقت فعلًا
البطء عَرَض. وهذه هي الأسباب.
كل موقع بطيء تقريبًا يُرسَل إليّ يكون بطيئًا لسببين أو ثلاثة من الأسباب التالية. الغرض من التشخيص هو معرفة أيّها، لأن علاج كل سبب مختلف تمامًا — وشراء العلاج الخاطئ هو ما يجعل الناس يدفعون ثمن تحسين السرعة مرتين.
الخادم يفكر طويلًا
ارتفاع Time to First Byte يعني أن العمل يجري قبل أن يصل بايت واحد إلى المتصفح. في WordPress يكون السبب عادةً استعلامات غير مخزّنة مؤقتًا داخل حلقة قالب، أو جدول خيارات بخاصية autoload تضخّم إلى عدة ميغابايتات، أو إضافة تستدعي واجهة API خارجية أثناء عرض الصفحة. ولا يمسّ أي تحسين في الواجهة الأمامية هذا الأمر.
أكبر عنصر على الشاشة ضخم
صورة رئيسية مُصدَّرة بعرض 4000 بكسل ومقدَّمة بصيغة PNG تُفشل Largest Contentful Paint وحدها. والحل ليس لامعًا: أبعاد صحيحة، وصيغ حديثة، وsrcset كي لا تنزّل الهواتف نسخة سطح المكتب، وعرض وارتفاع صريحان، وfetchpriority على الصورة الوحيدة المهمة.
السكربتات تعيق العرض
كل سكربت متزامن في head هو إشارة توقف قبل أن يستطيع المتصفح الرسم. مديرو الوسوم، وأدوات الدردشة، وأدوات اختبار A/B، ومحمّلات الخطوط هي المشتبه بها المعتادة، وكثيرًا ما تُحمَّل في كل صفحة من أجل ميزة تُستخدم في صفحة واحدة.
الصفحة تتحرك أثناء التحميل
ينتج Cumulative Layout Shift عن عناصر تصل متأخرة دون مساحة محجوزة لها — صور بلا أبعاد، وخطوط ويب تتبدّل بحجم مختلف، ولافتات ملفات تعريف الارتباط وإعلانات تُحقن فوق المحتوى الموجود. وهو عادةً الأرخص إصلاحًا بين الثلاثة والأكثر إزعاجًا عند تجربته.
التفاعل يبدو ثقيلًا
حلّ Interaction to Next Paint محل First Input Delay في مارس 2024، وهو مقياس أصعب بكثير. يقيس المدة التي يستغرقها التفاعل حتى يُنتج استجابة مرئية، على امتداد الزيارة كلها — لا في التفاعل الأول فقط. وتفشل المواقع فيه لأن الكثير من JavaScript يتنافس على الخيط الرئيسي.
03طريقة العملتسلسل حقيقي
كيف يسير العمل.
- 01
التشخيص قبل أي عرض سعر
- أحلّل الموقع وأرسل تفصيلًا مكتوبًا لأين يذهب الوقت، مرتّبًا حسب ما يكلّفك ومدى صعوبة إصلاحه. تحتفظ بهذه الوثيقة سواء تعاقدت معي أم لا.
- 02
خط أساس من بيانات المستخدمين الفعليين
- نتائج المختبر تتقلب بين تشغيل وآخر. أسجّل أولًا بيانات المستخدمين الفعليين من Chrome UX Report، حتى نقارن في النهاية ما عاشه الزوار الحقيقيون، لا تشغيلين مختبريين في يومين مختلفين.
- 03
إصلاح الأسباب، الأكبر أولًا
- يجري العمل على بيئة الاختبار، تغييرًا واحدًا في كل مرة، ويُقاس كل تغيير منفردًا. جمع عشرة تغييرات معًا لا يخبرك بشيء عن أيّها نجح، ويتركك عاجزًا عن التراجع عن الذي أضرّ.
- 04
التحقق، ثم تسليمك الطريقة
- تحصل على المقارنة قبل وبعد، وخطوات إعادة إنتاج الاثنين، وملاحظة عمّا سيهدم العمل تدريجيًا — وعادةً ما يكون الإضافة التالية التي يثبّتها أحدهم.
04الأسئلةأسئلة متكررة، وإجابات صريحة
ما يسأل عنه الناس قبل التعاقد معي.
هل ستُصلح إضافة التخزين المؤقت مؤشرات Core Web Vitals لديّ؟
جزئيًا في أحسن الأحوال. التخزين المؤقت يحسّن زمن استجابة الخادم، وهذا يساعد Time to First Byte. لكنه لا يفعل إلا القليل لـ Largest Contentful Paint الناتج عن صورة رئيسية ضخمة، ولا شيء لتحرّك التخطيط الناتج عن عناصر بلا أبعاد، ولا شيء لـ Interaction to Next Paint الناتج عن JavaScript الثقيل. معظم المواقع تصلني وإضافة التخزين المؤقت مثبتة فيها بالفعل، ومع ذلك تفشل.
لماذا تتغير نتيجتي في PageSpeed Insights باستمرار؟
الرقم الكبير في الأعلى اختبار مختبري على جهاز بطيء محاكى، ويتغير بين تشغيل وآخر. أما القسم الذي أسفله — بيانات المستخدمين الفعليين من Chrome UX Report — فهو ما تستخدمه Google فعلًا، وهو متوسط متحرك لمدة 28 يومًا لزوار حقيقيين. تابع بيانات المستخدمين الفعليين وتجاهل التحركات الصغيرة في نتيجة المختبر.
كم يستغرق ظهور التحسن في Google؟
لأن بيانات المستخدمين الفعليين نافذة متحركة مدتها 28 يومًا، توقّع نحو أربعة أسابيع حتى ينعكس التغيير كاملًا — وأطول في المواقع قليلة الزيارات التي تحتاج وقتًا لجمع عينات كافية. ومن يعدك بتغيير فوري في الترتيب يتحدث عن نتيجة المختبر، لا عن النتيجة التي تُحتسب.
ما التحسن الذي يمكنك أن تعد به؟
لا شيء قبل أن أنظر — ولهذا يأتي التشخيص أولًا ثم عرض السعر. الموقع المثقل بالإضافات مع صورة رئيسية غير محسّنة لديه هامش سهل كبير. أما الموقع الخفيف في الواجهة الأمامية والبطيء في قاعدة البيانات فعمل مختلف بسعر مختلف. أفضّل أن أعطيك رقمًا حقيقيًا بعد ساعة من التحليل على رقم مبهر الآن.
هل أحتاج إلى إعادة بناء الموقع؟
عادةً لا. معظم مشكلات السرعة حفنة من الأسباب المحددة لا عيب جوهري، وإصلاحها أرخص بكثير من إعادة البناء. إن رأيت أنك بلغت سقف ما يستطيعه البناء الحالي فسأقول ذلك — لكن هذا استثناء، وليس من مصلحتك أن ألجأ إليه أولًا.
ما INP، وهل حلّ محل FID؟
حلّ Interaction to Next Paint محل First Input Delay كأحد مؤشرات Core Web Vitals في مارس 2024. كان FID يقيس فقط التأخير قبل أن يبدأ المتصفح في معالجة تفاعلك الأول. أما INP فيقيس المدة التي استغرقها التفاعل كله حتى يُنتج استجابة مرئية، على امتداد الزيارة كلها. وهو أصعب بكثير في اجتيازه، ويُفشَل فيه عادةً لسبب واحد: كثرة JavaScript على الخيط الرئيسي.
كان موقعي سريعًا ثم أصبح بطيئًا. ما الذي تغيّر؟
في تجربتي، دائمًا تقريبًا واحد من ثلاثة: إضافة أو سكربت تتبع أُضيف لاحقًا، أو فريق محتوى يرفع صورًا بدقتها الكاملة مباشرة من الكاميرا، أو قاعدة بيانات تضخمت بصمت — مراجعات المقالات، وبيانات مؤقتة منتهية، وجدول خيارات بخاصية autoload. والثلاثة رخيصة الإصلاح بمجرد تحديدها.
الخطوة التالية
أرسل لي الرابط. سأخبرك بما فيه من خلل.
أول ما تحصل عليه تشخيص مكتوب تحتفظ به في كل الأحوال. وإن كانت الإجابة الصادقة أن موقعك جيد بالفعل، فهذا ما ستقوله الوثيقة.