مؤشر السرعة (Speed Index)

الخلاصة — Speed Index هي نتيجة Lighthouse لمدى سرعة ظهور محتوى صفحتك أثناء التحميل. الأقل (والأسرع) أفضل، وتُقاس بالثواني. على الهاتف المحمول، أقل من 3,4 s جيد. وهي ليست Core Web Vital ولا تؤثر مباشرةً في ترتيبك على Google — لكن الإصلاحات التي تحسنها تساعد عادةً المقاييس التي تؤثر فعلاً.

ما هو Speed Index

عندما تمرر صفحة عبر Lighthouse أو PageSpeed Insights، تكون إحدى القيم التي تحصل عليها هي Speed Index. وهي تجيب عن سؤال بسيط: ما سرعة امتلاء الجزء المرئي من صفحتك؟

تحدد معظم مقاييس السرعة لحظة واحدة — مثل ظهور أول جزء من المحتوى (First Contentful Paint) أو ظهور أكبر عنصر (Largest Contentful Paint). أما Speed Index فمختلفة. إذ تراقب التحميل كله وتعطيك متوسط سرعة ظهور الأشياء. تحصل الصفحة التي ترسم كل شيء فوراً تقريباً على نتيجة منخفضة (جيدة)، بينما تحصل الصفحة التي تبقى فارغة ثم تضيف المحتوى تدريجياً على نتيجة مرتفعة (سيئة).

كيف تقرأ نتيجتك

تصنف Lighthouse Speed Index على الهاتف المحمول هكذا:

• جيد: 0 – 3,4 s (أخضر)
• يحتاج إلى تحسين: 3,4 – 5,8 s (برتقالي)
• ضعيف: أكثر من 5,8 s (أحمر)

سطح المكتب أكثر صرامة بكثير — فالجيد تقريباً أقل من 1,3 s — لأن Lighthouse يختبر الهاتف المحمول على جهاز أبطأ مُحاكى. لذلك لا تقارن قيمة سطح المكتب بقيمة الهاتف المحمول؛ فهما على مقياسين مختلفين.

هل يهم لتحسين محركات البحث؟

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

هذا لا يجعلها عديمة الفائدة. فالإصلاحات التي تحسن Speed Index — خادم أسرع، وملفات أقل تحجب الرسم، ونص يظل مرئياً أثناء تحميل الخطوط — هي الإصلاحات نفسها التي تحسن FCP وLCP. لذلك تسير Speed Index الأفضل عادةً مع LCP أفضل، وهو المقياس الذي يهم فعلاً.

إذا أردت الصيغة وتاريخ WebPageTest ومكانها في نتيجة Lighthouse والقيود التي ينبغي مراقبتها، انتقل إلى علامة التبويب Advanced.

الخلاصة — تقيس Speed Index سرعة عرض المحتوى بصرياً أثناء تحميل الصفحة — أي متوسط وقت ظهور المحتوى المرئي، وتُسجل بالثواني (الأقل أفضل). وتحسب من فيديو التحميل عبر جمع المساحة فوق منحنى التقدم البصري، ولذلك فهي مقياس مختبري فقط (غير موجود في CrUX أو بيانات PSI الحقلية أو Search Console). نشأت في WebPageTest (Pat Meenan)، وتحسبها Lighthouse عبر وحدة Speedline مفتوحة المصدر. وهي ليست Core Web Vital وليست عامل ترتيب — بل واحدة من خمسة مقاييس في Lighthouse، بوزن 10% في Lighthouse 10. على الهاتف: جيد ≤ 3,4 s، ويحتاج إلى تحسين ≤ 5,8 s، وضعيف > 5,8 s؛ والجيد على سطح المكتب ≤ نحو 1,3 s. ولا يمكن أن تكون أسرع من FCP، وتعتمد على إطار العرض، وتتحسن بالإصلاحات نفسها التي تحسن FCP/LCP. Evidence for this claim Lighthouse Speed Index estimates how quickly page contents are visually populated during a lab load. Scope: Lighthouse lab metric; results depend on test environment and viewport. Confidence: high · Verified: 2026-07-14 Chrome Developers: Speed Index

ما الذي تقيسه Speed Index فعلياً

تعريف Google في سطر واحد: “Speed Index measures how quickly content is visually displayed during page load.” (ترجمة) «يقيس Speed Index مدى سرعة عرض المحتوى بصرياً أثناء تحميل الصفحة». والكلمة الأساسية هي بصرياً. ليست Speed Index طابعاً زمنياً واحداً مثل First Contentful Paint وLargest Contentful Paint — بل نتيجة مركبة تمثل متوسط وقت عرض الأجزاء المرئية من الصفحة. الأقل أفضل، وتُبلغ بالثواني.

النموذج الذهني الأوضح لدي هو رسم مخطط: الزمن على المحور X، و«النسبة المئوية من الصفحة المكتملة بصرياً» على المحور Y، صعوداً من 0% إلى 100%. Speed Index هي المساحة فوق ذلك المنحنى. وكلما صعد المنحنى إلى 100% أسرع، صغرت المساحة وتحسنت النتيجة. تترك الصفحة الفارغة فترةً مستطيلاً كبيراً من المساحة الفارغة فوق الخط؛ أما الصفحة التي تُرسم بسرعة فلا تترك إلا القليل.

كيف تُحسب

تلتقط Lighthouse فيديو لتحميل الصفحة وتحسب التقدم البصري بين الإطارات. ويُوزن كل فاصل زمني بحسب مقدار عدم اكتمال الصفحة في تلك اللحظة — فالإطار الفارغ تماماً يُحتسب بنسبة 100%، بينما يُحتسب الإطار المرسوم في معظمه بنسبة ضئيلة. والصيغة الأصلية لـ WebPageTest هي:

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

يجعل المثال المحسوب الفكرة ملموسة. يعرض DebugBear عملية تحميل واحدة هكذا:

• اكتمال 0% (0–253 ms) → مساهمة 253,0 ms
• اكتمال 43% (253–403 ms) → مساهمة 85,5 ms
• اكتمال 98% (403–536 ms) → مساهمة 2,7 ms
• اكتمال 99% (536–653 ms) → مساهمة 1,2 ms
• الإجمالي: 342,3 ms

لاحظ الجزء الأول: عندما لا يكون أي شيء مرئياً، يسهم كل ذلك الوقت بالوزن الكامل. ولهذا لا يمكن أن تكون Speed Index أسرع من First Contentful Paint — فكل ميلي ثانية قبل رسم المحتوى الأول تُحتسب بنسبة 100%.

لا تنشئ Lighthouse تطبيقها الخاص هنا. بل تشغّل وحدة Speedline مفتوحة المصدر (من Paul Irish في الأصل)، التي تطبق منهجية التقدم البصري من الفيديو نفسها التي يستخدمها WebPageTest، بالاعتماد على آثار Chrome DevTools مع تفعيل لقطات الشاشة. ويمكن لـ Speedline حساب Speed Index قياسية (فرق المدرج التكراري بين الإطار الحالي والنهائي) أو نسخة إدراكية باستخدام SSIM؛ والنسخة القياسية هي التي تراها عادةً.

ما النتيجة الجيدة

تصنف Lighthouse 10 Speed Index اعتماداً على بيانات مواقع حقيقية من HTTP Archive، وتختلف العتبات بشدة حسب الجهاز لأن Lighthouse يحاكي جهاز هاتف محمول متوسط المستوى مع تقييد السرعة افتراضياً:

إذا رأيت معيار «أقل من 1,000 ms جيد» القديم منتشراً، فهو إرشاد قديم من WebPageTest لعصر وملف اتصال محددين — وليس معيار الهاتف المحمول الحالي في Lighthouse. اعرف دائماً الأداة وإعدادات الجهاز والشبكة التي أنتجت الرقم، لأن الصفحة نفسها تحصل على نتائج مختلفة في Lighthouse وWebPageTest وGTmetrix.

موضعها في نتيجة Lighthouse

Speed Index واحدة من خمسة مقاييس في نتيجة أداء Lighthouse 10، ووزنها 10% — وهو الوزن نفسه لـ FCP وأدنى وزن:

الخلاصة العملية: ملاحقة Speed Index بمعزل عن غيرها عائدها منخفض. يحرك Total Blocking Time (30%) وLCP وCLS (25% لكل منها) النتيجة العامة أكثر بكثير. ما لم تكن Speed Index هي المشكلة المحددة، ستحصل عادةً على فائدة أكبر من إصلاح LCP وTBT — وستتحسن Speed Index كأثر جانبي على أي حال. وفي PageSpeed Insights ستجد Speed Index في قسم المختبر (Lighthouse)، لا في قسم بيانات الحقول العلوي.

هل Speed Index من Core Web Vitals أم عامل ترتيب؟

لا في الحالتين، والتمييز مهم عندما تشرح تقريراً لأحد أصحاب المصلحة.

• ليست Core Web Vital. Core Web Vitals هي LCP وINP وCLS، وتقاس لدى مستخدمين حقيقيين عبر CrUX. ولا تنتمي Speed Index إلى هذه المجموعة ولا تظهر في تقرير Core Web Vitals في Search Console.
• ليست عامل ترتيب مباشراً. تستخدم إشارة تجربة الصفحة لدى Google بيانات الحقول لـ Core Web Vitals. أما Speed Index فتشخيص مختبري فقط لا تجمعه Google من المستخدمين الحقيقيين، ولذلك لا يوجد مسار مباشر من رقم Speed Index إلى الترتيب.

العلاقة بالترتيب غير مباشرة: فالمشكلات التي تنتج Speed Index سيئة — TTFB بطيء، وCSS/JS يحجب الرسم، ونص غير مرئي أثناء تبديل الخط — هي المشكلات نفسها التي تنتج FCP وLCP سيئين. أصلحها، وستتبع Speed Index الأفضل عادةً LCP أفضل، وهو الجزء الذي تكافئه Google فعلياً.

لماذا هي مختبرية فقط

تحتاج Speed Index إلى فيديو إطاراً بإطار لعرض الصفحة، ثم إلى معالجة الصور لحساب اكتمال العرض في كل إطار. وهذا مكلف جداً ليجري على كل زائر حقيقي، لذلك لا توجد إلا في أدوات اصطناعية/مختبرية — Lighthouse وWebPageTest وGTmetrix. ولا تحمل مراقبة المستخدمين الحقيقيين ومجموعة بيانات CrUX هذه القيمة. وإذا احتجت إلى بيانات أداء حقلية، فاستخدم Core Web Vitals؛ أما Speed Index فمخصصة لتشخيص الرسم في اختبار مضبوط.

من أين جاءت

نشأت Speed Index في WebPageTest، الذي أنشأه Pat Meenan وفتح مصدره في 2008 (وأضيف المقياس نفسه نحو 2012). وقد صُممت لسد فجوة حقيقية في مقاييس ذلك الوقت:

• قد يبدأ Render start عند بكسل واحد أو لون خلفية — وليس محتوى ذا معنى.
• يتضمن Document complete (onload) الموارد الموجودة أسفل الجزء المرئي والموارد غير ذات الصلة.

قسّمت Speed Index الفرق بقياس الاكتمال البصري للجزء المرئي عبر الزمن — وهو وكيل أفضل لما يدركه المستخدم فعلياً. واعتمدت Lighthouse هذه المنهجية لاحقاً عبر وحدة Speedline، ولهذا تشترك أرقام WebPageTest وLighthouse في أصل واحد رغم اختلاف تقييد السرعة بينهما.

كيف تحسنها

لا توجد حيلة خاصة بـ Speed Index — فإرشاد Google نفسه هو أن أي شيء تفعله لتحسين سرعة تحميل الصفحة سيحسن نتيجة Speed Index. عملياً:

• قلل زمن استجابة الخادم (TTFB). كل ميلي ثانية قبل البايت الأول هي وقت صفحة فارغة يُحتسب بالوزن الكامل.
• أزل CSS وJavaScript الحاجبين للرسم. فهما يؤخران الرسم الأول، وهو أغلى جزء في المنحنى. ضع CSS الحرج داخل الصفحة وأجّل الباقي.
• أصلح تحميل الخطوط. أثناء تبديل الخط قد يكون النص غير مرئي — فيُحتسب اكتماله 0% لذلك الجزء. يحافظ font-display: swap (أو optional) على ظهور النص. وهذا أحد التدقيقات التي تشير إليها Lighthouse صراحةً لـ Speed Index.
• قلل عمل الخيط الرئيسي وقلل وقت تنفيذ JavaScript — وهما التشخيصان الآخران اللذان تشير إليهما Lighthouse على أنهما عاليَا التأثير في Speed Index.
• أعطِ أولوية لمحتوى الجزء المرئي. تهتم Speed Index بإطار العرض المرئي فقط، لذا فإن رسم الشاشة الأولى بسرعة هو جوهر العمل.

تتداخل هذه الإصلاحات تقريباً بالكامل مع تحسين FCP وLCP — ولهذا أتعامل مع Speed Index بوصفها إشارة مؤيدة لا قائمة مهام منفصلة. قبل التصرف بناءً على رقم واحد، انظر إلى شريط لقطات التحميل (تنشئه Lighthouse وWebPageTest) لتتأكد مما يُرسم مبكراً ومما يتأخر، وقارن بين عدة عمليات تشغيل متماثلة ومتكررة لا اختبار واحد — راجع ملاحظة التباين بين التشغيلات أدناه.

قيود ينبغي معرفتها

• مختبرية فقط — لا تعكس تجربة مستخدم حقيقي، بل بيئة الاختبار وحدها.
• تعتمد على إطار العرض — تقيس المساحة المرئية، لذلك تعطي الهواتف المحمولة وأجهزة سطح المكتب نتائج مختلفة جداً (ومن ثم العتبات المختلفة).
• نقطة عمياء في SPA/AJAX — قد تبدو التطبيقات أحادية الصفحة سريعة بشكل مصطنع: يُرسم الغلاف سريعاً بينما يُحمّل المحتوى الحقيقي لاحقاً من دون تحديث الصفحة.
• أشرطة التمرير والفيديو التلقائي وطبقات الموافقة — قد يُعاقب كل ما يواصل تغيير البكسلات بعد تحميل المحتوى المهم لأنه يظل مسجلاً بوصفه «غير مكتمل»، وهي الآلية نفسها التي تعاقب أشرطة التمرير ذات الدوران التلقائي.
• ليست مقياس «التحميل الكامل» — تقيس التقدم البصري فوق الجزء المرئي، لا وقت انتهاء كل شيفرة أو صورة أو عنصر أسفل الجزء المرئي. ومقياس Visually Complete المنفصل في WebPageTest (دائماً ≥ Speed Index) هو الذي يلتقط وصول مورد محمّل كسولاً في وقت متأخر.
• التقدم البصري ليس دليلاً على الفائدة. تقيس Speed Index تغير البكسلات مقابل إطار نهائي فقط — ولا تعرف ما إذا كان الظاهر مقروءاً أو مرتباً أو متاحاً أو تفاعلياً فعلاً. قد تحصل بنية هيكلية أو غلاف سريع الرسم على نتيجة جيدة بينما يصل المحتوى الحقيقي (والقدرة على استخدامه) لاحقاً؛ وهذا نمط الفشل نفسه الذي يمثله «الرسم المبكر عديم المعنى» أعلاه، لكن من جانب المقياس.
• التباين بين التشغيلات. لأنها مشتقة من تحميل واحد مسجل، تتحرك Speed Index مع ظروف الاختبار — وتسرد إرشادات Google نفسها اختلاف الجهاز وإضافات المتصفح وبرامج مكافحة الفيروسات وحتى تغييرات الإعلانات أو اختبارات A/B بوصفها مصادر لتذبذب النتيجة لا علاقة لها بشيفرتك. قارن توزيعات عمليات تشغيل متكررة متماثلة، لا أرقاماً منفردة.

مقاييس مرتبطة

تقع Speed Index في مجموعة أداء الويب نفسها التي يقع فيها محور Core Web Vitals وجيرانه. وهي الأقرب إلى First Contentful Paint (لا يمكن لـ Speed Index تجاوز FCP) وإلى Largest Contentful Paint (الإصلاحات والأسباب الجذرية نفسها)، وتقع بجوار Total Blocking Time في نتيجة Lighthouse، وستقابلها داخل Lighthouse وPageSpeed Insights. وبالنسبة إلى مقاييس الحقول التي تحرك الترتيب فعلياً، ابدأ بمحور Core Web Vitals.

ملخص الذكاء الاصطناعي

خلاصة مكثفة لنسخة Advanced:

• Speed Index = سرعة عرض المحتوى بصرياً أثناء التحميل — نتيجة مركبة (متوسط وقت ظهور المحتوى المرئي)، وليست طابعاً زمنياً واحداً. تُسجل بالثواني؛ الأقل أفضل.
• النموذج الذهني: المساحة فوق منحنى التقدم البصري (الزمن مقابل نسبة الاكتمال البصري). وتحسب من فيديو التحميل مع وزن كل فاصل بحسب مقدار عدم اكتمال الصفحة.
• مختبرية فقط: تحتاج إلى لقطات شاشة إطاراً بإطار، لذلك لا توجد في CrUX أو بيانات PSI الحقلية أو Search Console. استخدم Core Web Vitals لبيانات الحقول.
• الأصل: WebPageTest (Pat Meenan، 2008؛ والمقياس نحو 2012). وتحسبها Lighthouse عبر وحدة Speedline مفتوحة المصدر — بالمنهجية نفسها التي يتبعها WebPageTest.
• ليست Core Web Vital وليست عامل ترتيب. المقاييس الأساسية هي LCP وINP وCLS. والعلاقة بالترتيب غير مباشرة: عادةً ما يحسن إصلاح Speed Index كلاً من FCP وLCP.
• وزن Lighthouse 10: 10% — وهو الأدنى بالتساوي مع FCP. يهم TBT (30%) وLCP/CLS (25% لكل منهما) أكثر بكثير، لذلك فملاحقة Speed Index وحدها عائدها منخفض.
• العتبات (الهاتف المحمول): جيد ≤ 3,4 s، ويحتاج إلى تحسين ≤ 5,8 s، وضعيف > 5,8 s؛ والجيد على سطح المكتب ≤ نحو 1,3 s. ولا يمكنها أن تكون أسرع من FCP وتعتمد على إطار العرض.
• الإصلاحات = إصلاحات FCP/LCP: TTFB أسرع، وموارد أقل تحجب الرسم، وfont-display: swap، وعمل أقل للخيط الرئيسي/JavaScript، وأولوية للجزء المرئي.
• القيود: قد تحصل SPA على نتيجة جيدة مصطنعة؛ وقد تُعاقب أشرطة التمرير والفيديو التلقائي وطبقات الموافقة؛ وليست مقياس «التحميل الكامل»؛ والتقدم البصري ليس دليلاً على قابلية القراءة أو الإتاحة أو الاستخدام؛ وقد يحرك التشغيل الواحد الجهاز أو الإضافات أو تغييرات الإعلانات أو A/B التي لا علاقة لها بشيفرتك.

الوثائق الرسمية

وثائق المصادر الأولية لـ Speed Index.

Google / Lighthouse

• Speed Index (تدقيق Lighthouse) — المرجع الأساسي: التعريف، وكيف تحسبها Lighthouse عبر Speedline، وعتبات النتيجة، وتدقيقات التحسين.
• تسجيل أداء Lighthouse — موضع وزن Speed Index البالغ 10% والتفصيل الكامل للمقاييس.
• تقليل عمل الخيط الرئيسي — أحد التدقيقات الثلاثة التي تشير إليها Lighthouse على أنها عالية التأثير في Speed Index.
• تقليل وقت تنفيذ JavaScript — التدقيق الثاني المشار إليه.
• ضمان بقاء النص مرئياً أثناء تحميل خط الويب (font-display) — التدقيق الثالث المشار إليه.

الأصل / التنفيذ

• Speedline (paulirish/speedline) — الوحدة مفتوحة المصدر التي تستخدمها Lighthouse لحساب Speed Index من آثار DevTools.
• مصدر Lighthouse — speed-index.js — ثابت الوصف الخاص بالتدقيق.
• WebPageTest — حول الأداة — أنشأ Pat Meenan WebPageTest وفتح مصدرها، ومنها نشأت Speed Index.

الاقتباسات من المصدر

تصريحات مسجلة. كل رابط من Google أو Lighthouse هو رابط عميق يقفز إلى المقطع المقتبس.

Google — ما الذي تقيسه Speed Index

• “Speed Index measures how quickly content is visually displayed during page load.” (ترجمة) «يقيس Speed Index مدى سرعة عرض المحتوى بصرياً أثناء تحميل الصفحة». — تدقيق Speed Index في Lighthouse. الانتقال إلى الاقتباس

Google — كيف تُضبط النتيجة

• “Your Speed Index score is a comparison of your page’s speed index and the speed indexes of real websites, based on data from the HTTP Archive.” (ترجمة) «تقارن نتيجة Speed Index لصفحتك بمؤشرات السرعة لمواقع حقيقية، استناداً إلى بيانات HTTP Archive». — تدقيق Speed Index في Lighthouse. الانتقال إلى الاقتباس

مصادر منقولة (أُعيدت صياغتها من وثائق ثانوية، وليست اقتباسات حرفية)

• تلتقط Lighthouse فيديو لتحميل الصفحة، وتحسب التقدم البصري بين الإطارات، وتنشئ النتيجة عبر وحدة Speedline — اعتماداً على مبادئ Speed Index الأصلية في WebPageTest. (تدقيق Speed Index في Lighthouse، قسم الحساب.)
• كلما ظل الإطار مرئياً مدة أطول وكانت الصفحة أقل اكتمالاً حينها، زادت مساهمته في النتيجة — وبما أن كل الوقت السابق لـ FCP يُحتسب بنسبة 100%، لا يمكن أن تكون Speed Index أسرع من First Contentful Paint. (وثائق DebugBear عن Speed Index.)
• لا تتوفر Speed Index إلا في الاختبارات الاصطناعية/المختبرية بسبب تكلفة معالجة لقطات الشاشة إطاراً بإطار. (وثائق DebugBear عن Speed Index.)
• أضيف المقياس إلى WebPageTest نحو 2012، فوق الأداة التي فتح Pat Meenan مصدرها في 2008. (KeyCDN؛ صفحة About في WebPageTest.)

ورقة غش Speed Index

العتبات (Lighthouse 10)

أوزان أداء Lighthouse 10

حقائق سريعة

• تقيس الاكتمال البصري عبر الزمن (المساحة فوق منحنى التقدم)، لا طابعاً زمنياً واحداً. الأقل أفضل.
• مختبرية فقط — ليست في CrUX أو بيانات PSI الحقلية أو Search Console.
• ليست Core Web Vital؛ وليست عامل ترتيب مباشراً.
• لا يمكنها أن تكون أسرع من FCP (فالوقت السابق لـ FCP يُحتسب بنسبة 100%).
• تعتمد على إطار العرض — تختلف نتائج الهاتف المحمول وسطح المكتب كثيراً.
• تحسبها Speedline؛ ونشأت في WebPageTest (Pat Meenan).

حسّنها (كما تحسن FCP/LCP)

• قلل TTFB (استجابة خادم أسرع).
• أزل CSS/JS الحاجبين للرسم؛ وضع CSS الحرج داخل الصفحة.
• استخدم font-display: swap / optional حتى يظل النص مرئياً.
• قلل عمل الخيط الرئيسي ووقت تنفيذ JS.
• أعطِ أولوية للرسم فوق الجزء المرئي.

لا تنخدع

• «أقل من 1,000 ms» إرشاد قديم من WebPageTest، وليس معيار الهاتف المحمول في Lighthouse.
• قد تحصل SPA على نتيجة جيدة مصطنعة؛ وقد تُعاقب أشرطة التمرير.

الأدوات التي تبلغ عن Speed Index

• Lighthouse (في Chrome DevTools أو CLI أو وحدة Node) — تبلغ عن Speed Index بوصفها واحدة من مقاييس الأداء الخمسة، وتحسبها عبر Speedline.
• PageSpeed Insights — تشغّل Lighthouse وتعرض Speed Index في قسم المختبر (Diagnostics). ملاحظة: يستخدم قسم بيانات الحقول العلوي Core Web Vitals، لذلك لا تظهر Speed Index هناك أبداً.
• WebPageTest — حيث نشأ المقياس؛ وتبلغ عن Speed Index بجوار Visually Complete ولقطات التحميل، مع ملفات اتصال قابلة للضبط.
• GTmetrix — تعرض Speed Index في واجهتها باستخدام بيانات WebPageTest؛ ولن تطابق أرقام Lighthouse بسبب اختلاف محاكاة الجهاز والشبكة.
• DebugBear — مراقبة اصطناعية مع تفصيل واضح إطاراً بإطار لكيفية حساب نتيجة Speed Index.

تذكير عند مقارنة الأدوات: تنتج الصفحة نفسها قيم Speed Index مختلفة في Lighthouse وWebPageTest وGTmetrix بسبب اختلاف تقييد السرعة وافتراضات الجهاز. قارن الحالات المتماثلة.

أخطاء Speed Index التي تهدر وقت التحسين

• تسمية Speed Index بأنها Core Web Vital. إنها مقياس تقدم بصري مختبري فقط، وليست إشارة ترتيب حقلية. استخدمها لتشخيص كيفية امتلاء الصفحة، ثم افحص Core Web Vitals الفعلية منفصلة.
• مقارنة عتبات الهاتف المحمول وسطح المكتب. تستخدم Lighthouse منحنيات نتيجة وظروف اختبار مختلفة. تتبع ملفاً واحداً عبر الزمن بدلاً من اعتبار النتيجتين متبادلتين.
• تحسين الرقم برسم مبكر عديم المعنى. قد يجعل غلاف الرأس التقدم البصري يبدأ أبكر بينما يظل المحتوى الأساسي فارغاً. راجع شريط لقطات التحميل مع المقياس.
• تحسين كل صورة قبل فحص المسار الحرج. قد يؤخر TTFB البطيء وCSS الحاجب للرسم والخطوط وJavaScript المتزامن التسلسل البصري كله. اعثر على أول عنق زجاجة في الشلال وتتبع أثره.
• توقع قيمة مستقرة من تشغيل واحد. تُشتق Speed Index من فيديو اصطناعي وتتغير مع بيئة الاختبار. كرر عمليات تشغيل قابلة للمقارنة قبل إعلان تراجع أو فوز.

اختبر نفسك: Speed Index

خمسة أسئلة سريعة حول ما تقيسه Speed Index. اختر إجابة لكل سؤال، ثم تحقق منها.

موارد تستحق وقتك

رسمية

• Speed Index — تدقيق Lighthouse — التعريف والعتبات وتدقيقات التحسين المرجعية.
• تسجيل أداء Lighthouse — أوزان المقاييس، بما فيها وزن Speed Index البالغ 10%.
• WebPageTest — حول الأداة — أصل المقياس.

التنفيذ

• paulirish/speedline — الوحدة مفتوحة المصدر التي تستخدمها Lighthouse لحساب Speed Index.

من مصادر أخرى

• DebugBear — Speed Index — أوضح مثال عملي خطوة بخطوة للحساب والعلاقة مع FCP.
• KeyCDN — Speed Index — السياق التاريخي وصيغة WebPageTest.
• Catchpoint — Speed Index — وريث مدونة WebPageTest؛ صيغة التقدم البصري وقيود SPA وأشرطة التمرير.
• Google Search Central — Core Web Vitals — يؤكد أن LCP وINP وCLS هي إشارات الترتيب؛ ولا تُذكر Speed Index، بما يعزز عدم تأثيرها المباشر في الترتيب.
• web.dev — نظرة عامة على Vitals — التعريف الموثوق لـ Core Web Vitals (LCP وINP وCLS)؛ وغياب Speed Index مفيد عند شرح سبب عدم تأثيرها في الترتيب.
• وثائق Speed Index في WebPageTest — خلفية إنشاء Pat Meenan لـ WebPageTest (فتح المصدر في 2008) ومكان نشوء مقياس Speed Index.

أرقام تستحق الاقتباس

• وزن Lighthouse: 10% من نتيجة الأداء في Lighthouse 10 — متساوٍ مع FCP وأدنى وزن، وبفارق كبير خلف TBT (30%) وLCP/CLS (25% لكل منهما). المصدر
• «جيد» على الهاتف المحمول ≤ 3,4 s؛ و«جيد» على سطح المكتب ≤ 1,3 s — عتبات Lighthouse 10 المعايرة على بيانات المواقع الحقيقية في HTTP Archive. المصدر
• Speed Index ≥ FCP دائماً — فكل الوقت قبل رسم المحتوى الأول يسهم بنسبة 100%، لذلك لا يمكن أن تكون Speed Index أسرع من First Contentful Paint. المصدر
• الأصل: WebPageTest، نحو 2012 — أضيفت فوق الأداة التي فتح Pat Meenan مصدرها في 2008. المصدر

سجل التغييرات