أداة مجانية: الأداء

اختبار سرعة الموقع

نحمّل صفحتك كما يحمّلها هاتف متوسط الفئة على اتصال 4G بطيء، ونقيس سرعة ظهور المحتوى الرئيسي ومقدار تحرّك عناصر الصفحة، ونُظهر ما يجعلها ثقيلة. وعندما تتوفر لدى Google بيانات مستخدمين فعليين لموقعك، تراها أيضًا.

مجاني. ينتهي عادةً في أقل من دقيقة.

ما تفحصه هذه الأداة

  • هاتف على شبكة 4G بطيئة

    تُحمَّل الصفحة في Chromium كهاتف من فئة Moto G Power (412 × 823) بزمن انتقال 150 ms، وسرعة تنزيل نحو 1.6 Mbps ورفع 750 Kbps، ومعالج أبطأ بمقدار 4×. وهذه هي إعدادات المحاكاة التي يستخدمها Lighthouse في اختبارات الجوال.

  • سرعة عرض أكبر محتوى مرئي (LCP)

    متى اكتمل عرض أكبر صورة أو كتلة نص في الشاشة الأولى، وأي عنصر كان.

  • متغيّرات التصميم التراكمية (CLS)

    مقدار تحرّك المحتوى المرئي بشكل غير متوقع أثناء تحميل الصفحة.

  • إجمالي وقت الحظر (TBT)

    المدة التي أبقت فيها النصوص البرمجية المتصفح مشغولًا لدرجة لا يستجيب معها للمس: الجزء الذي يتجاوز 50 ms من كل مهمة طويلة، مجموعًا. وهو البديل المعملي لمقياس Interaction to Next Paint (INP).

  • ما تنزّله الصفحة

    إجمالي البايتات والطلبات، مقسّمة إلى صور ونصوص برمجية وCSS وخطوط، والحصة القادمة من جهات خارجية.

  • الصور الثقيلة والملفات التي تعيق العرض

    الصور التي يتجاوز حجمها 150 KB أو التي يفوق عرضها بكثير المساحة التي تُعرض فيها، وملفات CSS والنصوص البرمجية التي تؤخّر العرض الأول.

  • بيانات المستخدمين الفعليين من Chrome

    تقرير تجربة المستخدم في Chrome (Chrome UX Report) من Google لأصل موقعك على الهواتف عند المئين 75: LCP وINP وCLS، عندما تتوفر لدى Google حركة زيارات كافية للموقع.

ما لا يمكنها فحصه

  • إعطاء الأرقام نفسها في كل تشغيل. تتفاوت النتائج المعملية بحسب الشبكة وحمل الخادم والنصوص البرمجية للجهات الخارجية، لذا قارن الاتجاهات بدلًا من التشغيلات المنفردة.
  • مطابقة PageSpeed Insights تمامًا. فكلاهما يحاكي هاتفًا بإعدادات مشابهة، لكنهما يعملان على أجهزة وشبكات مختلفة.
  • قياس INP في الاختبار المعملي. يحتاج INP إلى تفاعلات حقيقية، لذا يعرض الاختبار المعملي TBT وتعرض البيانات الميدانية INP عند توفرها.
  • عرض بيانات ميدانية لكل موقع. يغطي Chrome UX Report آخر 28 يومًا، ولا يشمل إلا الأصول التي تحظى بحركة زيارات كافية من Chrome.
  • اختبار أكثر من الصفحة الواحدة التي تُدخلها. يختبر تقرير الأداء المدفوع 3 صفحات أساسية ويرتّب الأسباب مع الإصلاحات.

لماذا يهم ذلك

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

مؤشرات أداء الويب الأساسية (Core Web Vitals) هي مقاييس Google لهذه التجربة: التحميل (LCP) والاستجابة (INP) والثبات البصري (CLS). تستخدمها Google في الترتيب، لكنها تقول إن تجربة الصفحة الجيدة لا تتقدّم على المحتوى ذي الصلة. وأثرها الأكبر يقع على الناس: فالصفحة البطيئة أو التي تقفز عناصرها تخسر زوارها قبل أن يقرؤوا أي شيء.

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

كيف تقرأ النتائج

سرعة عرض أكبر محتوى مرئي (LCP)
جيد إذا كان أقل من 2.5 s، وضعيف إذا تجاوز 4 s. إذا كان عنصر LCP صورة، فحجمها وأولوية تحميلها هما الأهم؛ وإذا كان نصًا، فانظر في خطوط الويب وملفات CSS التي تعيق العرض.
متغيّرات التصميم التراكمية (CLS)
جيد إذا كان أقل من 0.1، وضعيف إذا تجاوز 0.25. وهو رقم بلا وحدات يجمع بين مقدار ما تحرّك من الشاشة والمسافة التي تحرّكها.
إجمالي وقت الحظر (TBT)
جيد إذا كان أقل من 200 ms، وضعيف إذا تجاوز 600 ms. ويُنبئ ارتفاع TBT ببطء الاستجابة للمس لدى المستخدمين الفعليين.
البايتات والطلبات
لا يوجد حد رسمي؛ انظر إلى النوع الغالب. فالصور عادةً هي الحصة الأكبر، وارتفاع حصة الجهات الخارجية يشير إلى التطبيقات والوسوم والأدوات المضمّنة.
الصور الثقيلة
كل صورة يتجاوز حجمها 150 KB، أو تُنزَّل بعرض يفوق بكثير عرض ظهورها، مع حجم ملفها وأبعادها.
الملفات التي تعيق العرض
ملفات CSS والنصوص البرمجية المتزامنة التي يجب على المتصفح تنزيلها قبل أن يتمكن من عرض أي شيء.
البيانات الميدانية (المئين 75)
مستخدمو Chrome الفعليون على الهواتف خلال آخر 28 يومًا. ويعني المئين 75 أن ثلاثًا من كل أربع عمليات تحميل للصفحة كانت بهذه السرعة على الأقل. يكون INP جيدًا إذا كان أقل من 200 ms، وضعيفًا إذا تجاوز 500 ms.
لا توجد بيانات ميدانية
لا تملك Google حركة زيارات كافية من Chrome لأصل موقعك. وهذا لا يقول شيئًا عن سرعتك؛ اعتمد على النتائج المعملية.

كيف تصلح أكثر المشكلات شيوعًا

  • صورة LCP بطيئة

    قدّم الصورة الرئيسية بالحجم الذي تُعرض به، باستخدام srcset، وبتنسيق WebP أو AVIF. لا تستخدم معها التحميل الكسول (lazy loading)، وأضف fetchpriority="high"، وضعها في HTML بوصفها عنصر img بدلًا من تحميلها من نص برمجي أو خلفية CSS.

  • محتوى يقفز أثناء التحميل

    امنح الصور ومقاطع الفيديو والعناصر المضمّنة سمتي width وheight أو خاصية CSS aspect-ratio. احجز مساحة للأشرطة وإشعارات ملفات تعريف الارتباط والإعلانات، أو اعرضها طبقاتٍ علوية لا تدفع المحتوى إلى الأسفل. ولخطوط الويب، استخدم font-display: optional أو خطًا احتياطيًا بمقاس مطابق.

  • إجمالي وقت حظر مرتفع

    أزل أولًا التطبيقات والوسوم والإضافات التي لم تعد تستخدمها؛ فنصوصها البرمجية كثيرًا ما تبقى بعد توقفك عن استخدامها. حمّل أدوات الدردشة والمراجعات والتحليلات باستخدام defer أو بعد أن تصبح الصفحة تفاعلية. وفي Shopify، تحقق من Online Store › Themes › Customize › App embeds.

  • CSS والنصوص البرمجية التي تعيق العرض

    أضف defer إلى النصوص البرمجية التي لا تحتاج إلى التنفيذ قبل العرض الأول، وضمّن مباشرةً (inline) القدر الصغير من CSS الذي تحتاجه الشاشة الأولى، واستغنِ عن أوراق الأنماط الخاصة بميزات لا تستخدمها الصفحة.

  • صور ثقيلة جدًا

    غيّر أبعاد الصور قبل رفعها (عرض نحو 2000 px يكفي تمامًا لشريط بعرض الصفحة كاملًا) واضغطها. يمكن لـ Shopify وWordPress تقديم نسخ أصغر تلقائيًا عندما يطلبها القالب، لذا تحقق من أن قالبك يستخدم أحجام صور متجاوبة.

أسئلة حول هذه الأداة

لماذا تختلف نتائجي عن PageSpeed Insights؟

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

ما قيمة LCP الجيدة؟

2.5 ثانية أو أقل في 75% على الأقل من عمليات تحميل الصفحة، وفقًا لموقع web.dev. وما يتجاوز 4 ثوانٍ يُعدّ ضعيفًا.

لماذا لا توجد بيانات مستخدمين فعليين لموقعي؟

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

لماذا الاختبار على هاتف بطيء بدلًا من حاسوب مكتبي؟

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

ماذا حدث لمقياس First Input Delay؟

حلّ مقياس Interaction to Next Paint (INP) محل First Input Delay ضمن مؤشرات أداء الويب الأساسية (Core Web Vitals) في مارس 2024. ويراعي INP تأخر التفاعلات طوال الزيارة، لا التفاعل الأول وحده.

يبدأ تقرير الأداء ($55، دفعة واحدة) من الفحص المجاني الكامل، ويضيف صفحات أكثر، والتغيير المطلوب لكل نتيجة، وملف PDF، وإعادة اختبار للتحقق من إصلاحاتك.

عن تقرير الأداء