Lighthouse من Google

الخلاصة — Lighthouse هي أداة مجانية من Google تُقيّم صفحة الويب من 0 إلى 100 في أمور مثل السرعة وإمكانية الوصول. تُشغّل الصفحة في “مختبر” مُبطّأ — هاتف بطيء افتراضي على شبكة بطيئة — لذا غالبًا ما تكون النتيجة أقل مما يبدو عليه موقعك في الواقع. إنها قائمة مهام رائعة للتحسينات، لكن النتيجة المرتفعة لا ترفعك في ترتيب نتائج Google.

ما هو Lighthouse

Google Lighthouse هي أداة مجانية ومفتوحة المصدر من الفريق الذي يقف خلف Chrome. توجّهها إلى عنوان URL، فتُجري سلسلة من الفحوصات على الصفحة، وتمنحك بطاقة تقرير بدرجات في أربعة مجالات: الأداء (مدى سرعة تحميل الصفحة)، إمكانية الوصول (هل يمكن للأشخاص ذوي الإعاقة استخدامها)، أفضل الممارسات (النظافة العامة للويب)، وتحسين محركات البحث (فحوصات أساسية لملاءمة محركات البحث).

تتراوح كل درجة من 0 إلى 100، مع نطاقات لونية لتعرف في لمحة كيف كان أداؤك:

• 0–49 أحمر — ضعيف
• 50–89 برتقالي — يحتاج إلى تحسين
• 90–100 أخضر — جيد

الشيء الوحيد الذي يجب فهمه أولاً

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

لهذا السبب يمكنك تشغيل Lighthouse على موقع يُحمَّل فورًا على حاسوبك المحمول السريع وما زلت ترى درجة أداء تبلغ 55. أنت لا ترى ما أنت تشعر به — بل ترى ما قد يشعر به هاتف اقتصادي على شبكة متوسطة. معلومات مفيدة، لكنها ليست الشيء نفسه.

Lighthouse ليس PageSpeed Insights (بالضبط)

ربما رأيت Lighthouse دون أن تعرف ذلك. عندما تُشغّل صفحة عبر PageSpeed Insights (الأداة على الويب في pagespeed.web.dev)، فإن درجات “المختبر” التي يعرضها لك هي Lighthouse. يغلّف PageSpeed Insights أداة Lighthouse ويضيف مجموعة ثانية من الأرقام من المستخدمين الحقيقيين (بيانات ميدانية من تقرير تجربة مستخدم Chrome (CrUX)). مزيد من التفاصيل حول هذا التمييز في النسخة المتقدمة.

الأسطورة الكبيرة التي يجب التخلص منها

النتيجة المثالية في Lighthouse لا تعني ترتيبًا متقدمًا. Lighthouse أداة مفيدة للعثور على أشياء لإصلاحها، لكن النتيجة نفسها ليست ما تستخدمه Google لترتيبك. أرقام الأداء التي تهتم بها Google فعليًا للترتيب تأتي من المستخدمين الحقيقيين، وليس من مختبر Lighthouse. السعي للحصول على 100 رائع لزوارك — فقط لا تتوقع أن يكون رمزًا سريًا للترتيب.

تريد أوزان المقاييس، ولماذا تقفز الدرجات بين عمليات التشغيل، وكيف يرتبط Lighthouse بالضبط بـ Core Web Vitals؟ انتقل إلى علامة التبويب المتقدمة.

الخلاصة — Lighthouse هي أداة مفتوحة المصدر وآلية تُدقق صفحة في ظروف مختبرية (محاكاة 4G بطيئة + خنق CPU بمقدار 4×) وتُقيّم الأداء، وإمكانية الوصول، وأفضل الممارسات، وتحسين محركات البحث — تم إسقاط PWA في Lighthouse 12. درجة الأداء هي متوسط مرجح لخمسة مقاييس مختبرية: TBT 30%، LCP 25%، CLS 25%، FCP 10%، Speed Index 10%. النطاقات: 0–49 أحمر، 50–89 برتقالي، 90–100 أخضر. إنها بيانات مختبرية، لذا فهي ليست إشارة ترتيب Core Web Vitals، ولا يمكنها قياس INP بالطريقة التي تقيسها البيانات الميدانية (تستخدم TBT كبديل)، وتختلف من تشغيل إلى آخر. تُشغّل نصف المختبر في PageSpeed Insights؛ يضيف PSI بيانات CrUX الميدانية فوقها. الحصول على 100 لا يشتري ترتيبًا.

ما هو Lighthouse فعليًا

وصف Google الرسمي المختصر هو التعريف الأنظف: “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (ترجمة) «Lighthouse هي أداة مفتوحة المصدر وآلية لمساعدتك على تحسين جودة صفحات الويب.» الآليات بسيطة بنفس القدر — “give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” (ترجمة) «أعطِ Lighthouse عنوان URL لتدقيقه، فيُجري سلسلة من عمليات التدقيق على الصفحة، ثم يُنشئ تقريرًا عن مدى جودة أداء الصفحة.»

تُقيّم أربع فئات اليوم: الأداء، وإمكانية الوصول، وأفضل الممارسات، وتحسين محركات البحث. إذا قرأت أدلة أقدم تقول خمسًا، فهي قديمة — تمت إزالة فئة PWA في Lighthouse 12 (حوالي 2024)، بعد معايير التثبيت المحدثة من Chrome. لذا إذا كانت مقالة مدونة لا تزال تستشهد بدرجة PWA، فهذه علامة على أنها تسبق الإصدار الحالي.

الإطار الحاسم هو كلمة واحدة: مختبر. يقوم Lighthouse بتحميل صفحتك في بيئة محاكاة خاضعة للتحكم، وليس من زوارك الحقيقيين. هذه الحقيقة الواحدة تفسر تقريبًا كل الالتباس الذي يشعر به الناس تجاهه.

كيف يعمل Lighthouse — ظروف المختبر

بشكل افتراضي، يستخدم Lighthouse الاختناق المحاكى، وهو يخنق بشكل قوي. تحاكي الإعدادات الافتراضية تقريبًا جهازًا محمولًا متوسط المستوى على اتصال Slow 4G:

• الشبكة: إعداد Slow 4G للجوال — حوالي 150 مللي ثانية من زمن الاستجابة و1,6 ميجابت/ثانية للتنزيل / 750 كيلوبت/ثانية للرفع. يصف Google هذا بأنه يحاكي “the ~85th percentile mobile connection speed even when run on much faster fiber connections.” (ترجمة) «سرعة اتصال الجوال عند الشريحة المئوية 85 تقريبًا حتى عند تشغيله على اتصالات ألياف أسرع بكثير.»
• وحدة المعالجة المركزية: مضاعف 4× ثابت لوحدة المعالجة المركزية، يحاكي معالج هاتف متوسط المستوى على أجهزة سطح المكتب الأسرع.

هذا مقصود. لا يحاول Lighthouse أن يخبرك “هذه هي سرعة موقعك للجميع.” إنه يختبر الصفحة تحت ضغط ضد مجموعة أبطأ من المتوسط حتى تظهر المشكلات التي يخفيها جهاز الكمبيوتر المحمول السريع. لهذا السبب يمكن لموقع يبدو فوريًا لك أن يسجل 60 — أنت تستخدم MacBook عالي الأداء على اتصال ألياف؛ الاختبار هو هاتف Android اقتصادي على شبكة متوسطة.

فارق دقيق يستحق التوضيح: الاختناق المحاكى (الافتراضي) ليس هو نفسه DevTools / الاختناق المطبق. الاختناق المحاكى يصمم كيف كانت الصفحة ستُحمَّل تحت تلك الظروف بناءً على ملاحظة أولية غير مخنوقة — يلاحظ Google أن هذا الأسلوب “both very fast and deterministic.” (ترجمة) «سريع جدًا وحتمي.» الاختناق بنمط DevTools يبطئ الطلبات فعليًا، وهو ما يقول Google إنه “not a sufficient model of a slow connection.” (ترجمة) «ليس نموذجًا كافيًا لاتصال بطيء.» للقياس القابل للتكرار، يُفضل الوضع المحاكى الافتراضي.

درجة الأداء — كيف تُحسب

درجة الأداء هي “The Performance score is a weighted average of the metric scores.” (ترجمة) «درجة الأداء متوسط مرجح لدرجات المقاييس.» تم تعيين هذه الأوزان في Lighthouse 10 وتبقى الجدول المنشور الحالي. Lighthouse 13 (الذي تم طرحه في 2026) يذكر ذلك صراحةً: لقد دمج مجموعة من عمليات تدقيق الأداء غير المُسجلة في “Insights” مشتركة تُستخدم أيضًا في لوحة أداء DevTools، لكنه يذكر أنه “no changes to the performance scoring” (ترجمة) «لا توجد تغييرات على تسجيل الأداء» في هذا الإصدار — يعتمد التسجيل على المقاييس أدناه، وليس على أسماء عمليات التدقيق، وتلك لم تتغير. خمسة مقاييس تشكل الدرجة:

بعض الأشياء التي يجب استيعابها هنا:

• TBT يحمل الوزن الأكبر (30%). إنه وكيل المختبر للاستجابة. تأخير الإدخال الأول (FID) قد اختفى، وكذلك المقاييس الأقدم مثل Time to Interactive وFirst Meaningful Paint — تم إيقافها.
• مؤشر السرعة هو مقياس Lighthouse، وليس مقياس Core Web Vital. لا يزال يحسب 10% من درجة أداء Lighthouse على الرغم من أنه ليس واحدًا من CWV ذات الصلة بالترتيب في Google.
• يتم تسجيل كل مقياس مقابل منحنى، وليس حدًا ثابتًا. يأخذ Lighthouse القيمة الخام (عادةً بالمللي ثانية) ويحولها إلى توزيع لوغاريتمي طبيعي مبني من بيانات أرشيف HTTP الواقعية. نقاط التحكم في Google: الشريحة المئوية 25 من تلك البيانات تحصل على درجة 50، والشريحة المئوية 8 تحصل على 90. لذا فإن 90+ تعني أنك تقريبًا في أعلى ~8% من الصفحات على هذا المقياس — ولهذا السبب يصعب الفوز بآخر نقاط قليلة.
• فقط درجات المقاييس تحرك الرقم. أقسام الفرص والتشخيصات في التقرير هي إرشادات — تخبرك بماذا تصلح — لكنها لا تغير درجة الأداء مباشرة. إصلاحها يحسن المقاييس، والمقاييس تحرك الدرجة.

لماذا تتغير درجتك بين عمليات التشغيل

هذه هي الشكوى التي أسمعها كثيرًا: “I ran it twice and got 84 then 91 — is it broken?” (ترجمة) «شغّلته مرتين وحصلت على 84 ثم 91 — هل هو معطل؟» لا. Google صريحة: “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse.” (ترجمة) «الكثير من التباين في درجة الأداء الإجمالية وقيم المقاييس ليس بسبب Lighthouse.» عندما يقفز الرقم، عادةً ما تكون الظروف الأساسية هي التي تتغير:

• اختبارات A/B أو إعلانات مختلفة يتم عرضها في كل تحميل
• تغييرات توجيه الإنترنت — سواء شبكتك المحلية أو المسار الأطول عبر المناطق الذي يقطعه الطلب
• خادم الويب نفسه يستجيب بسرعات غير متناسقة
• الاختبار على أجهزة مختلفة (كمبيوتر مكتبي سريع مقابل كمبيوتر محمول متعب) — خنق المعالج نسبي للجهاز المضيف، لذا فإن مضاعف “4×” يعني شيئًا مختلفًا على جهاز سريع مقارنة بجهاز بطيء
• إضافات المتصفح التي تحقن JavaScript أو طلبات شبكة إضافية
• برامج مكافحة الفيروسات أو عمليات خلفية أخرى تتنافس على الموارد

على سبيل المثال: قم بتشغيل نفس الرابط مرتين وتمريرة واحدة تصادف تحميل إعلان أثقل أو تلتقط استجابة خادم أبطأ — تعكس عمليات التدقيق في تلك التمريرة هذا التحميل الواحد، وليس عيبًا أدخلته أنت. تعامل معها كعينة واحدة، وليس كحكم.

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

كيفية تشغيل Lighthouse بمسؤولية

استخدم Lighthouse كأداة تشخيص خاضعة للتحكم، وليس كحكم بنقرة واحدة:

1. اختبر الرابط المنشور الفعلي، وليس قالبًا مختلفًا أو بناءً محليًا غير منشور.
2. طابق ملف تعريف الجهاز وطريقة الخنق وإصدار Lighthouse وحالة التخزين المؤقت والمصادقة وحالة الموافقة والموقع الجغرافي للاختبار لكل مقارنة.
3. ابدأ كل تشغيل بانتقال جديد. تغيير حجم صفحة سطح مكتب محملة بالفعل إلى منفذ عرض للجوال لا يعيد إنتاج انتقال للجوال أو تسلسل طلبات أو استجابة خادم.
4. قم بتشغيله ثلاث مرات على الأقل. أبلغ عن الوسيط كنتيجة رئيسية واحتفظ بالتشغيلات الفردية والنطاق والطوابع الزمنية والتحذيرات والتتبعات بحيث يكون أي شذوذ مرئيًا بدلاً من تجاهله بصمت.
5. قارن قبل وبعد في ظل نفس الظروف. إذا كانت خدمة الاختبار تعمل من منطقة أخرى، فسجل ذلك: المسافة الشبكية الإضافية أو حافة CDN مختلفة يمكن أن تغير توقيتات الخادم والتحميل دون تغيير في الكود.
6. تحقق من CrUX بشكل منفصل قبل تقديم ادعاء حول مستخدمين حقيقيين. وسيط مختبري أفضل يدعم “هذا التغيير حسّن هذا الاختبار الخاضع للتحكم”، وليس “المستخدمون الآن يجتازون Core Web Vitals”.

الأدلة تدعم استنتاجات مختلفة:

هذا يتبع نموذج Lighthouse القائم على التوزيع لتباين الدرجات ويحافظ على التمييز بين المختبر والميدان. Evidence for this claim Lighthouse performance scores are weighted from lab metrics; 90–100 is good, 50–89 needs improvement, and 0–49 is poor. Scope: Current published Lighthouse performance-scoring model; metric weights can change by Lighthouse version. Confidence: high · Verified: 2026-07-14 Chrome Developers: Performance scoring

Lighthouse مقابل PageSpeed Insights — التمييز المهم

يتم الخلط بينهما باستمرار، لذا كن دقيقًا:

• Lighthouse هو المحرك. ينتج بيانات مختبرية — درجات الأداء، وإمكانية الوصول، وأفضل الممارسات، وتحسين محركات البحث.
• PageSpeed Insights هو واجهة ويب تشغّل Lighthouse وتضيف بيانات ميدانية من تقرير تجربة Chrome (CrUX) — مؤشرات Core Web Vitals حقيقية من مستخدمين حقيقيين مجهولين، تظهر عندما تتوفر بيانات كافية لعنوان URL أو المصدر.

لذا في PSI أنت تنظر إلى مجموعتي بيانات مختلفتين جنبًا إلى جنب. قسم “البيانات الميدانية” في الأعلى (مستخدمون حقيقيون، من CrUX) منفصل عن قسم بيانات Lighthouse “المختبرية” أسفله — وغالبًا ما يختلفان. عندما يقول شخص “درجة PageSpeed Insights الخاصة بي”، فإنه يقصد دائمًا تقريبًا درجة أداء Lighthouse، وليس البيانات الميدانية.

Lighthouse وCore Web Vitals — كيف يرتبطان

يقيس Lighthouse بعض مؤشرات Core Web Vitals في المختبر: يبلغ عن LCP وCLS كمقاييس مختبرية. لكن هناك حدًا صارمًا:

لا يمكن لـ Lighthouse قياس INP بالطريقة التي يقيسها الميدان. يتطلب التفاعل حتى الطلاء التالي (INP) تفاعلات حقيقية من المستخدمين لقياسه — لا يوجد مستخدم حقيقي ينقر في تشغيل مختبري. لذا يستخدم Lighthouse إجمالي وقت الحظر (TBT) كبديل مختبري للاستجابة. يرتبط TBT بـ INP، لكن اجتياز TBT لا يضمن اجتياز INP للمستخدمين الحقيقيين. إنهما مرتبطان، وليسا متماثلين.

هذا هو جوهر الفجوة بين المختبر والميدان. البيانات الميدانية — من CrUX، التي تظهر في Search Console وأعلى PageSpeed Insights — هي ما يعكس المستخدمين الحقيقيين وما يغذي إشارات تجربة الصفحة من Google. بيانات Lighthouse المختبرية مخصصة لتصحيح الأخطاء واكتشاف الانحدارات قبل النشر. إرشادات Google نفسها هي “prioritize field data to understand real-world user experiences” (ترجمة) «إعطاء الأولوية للبيانات الميدانية لفهم تجارب المستخدمين في العالم الحقيقي» واستخدام “lab data for debugging and testing features before launch.” (ترجمة) «البيانات المختبرية لتصحيح الأخطاء واختبار الميزات قبل النشر.»

أين تشغّله

نفس المحرك، أسطح مختلفة:

• Chrome DevTools — مدمج في المتصفح (لوحة Lighthouse). الأفضل للصفحات خلف تسجيل الدخول، حيث يمكنك تدقيق الصفحات المصادق عليها.
• PageSpeed Insights — واجهة الويب بدون تثبيت على pagespeed.web.dev؛ تشغّل Lighthouse وتضيف بيانات CrUX الميدانية.
• CLI — npm install -g lighthouse، ثم lighthouse <url>؛ قابل للبرمجة.
• وحدة Node — استيرادها برمجيًا في أدواتك وCI الخاصة بك.
• Lighthouse CI — الإعداد الرسمي لاكتشاف انحدارات الأداء في كل نشر. سير العمل هو جمع → تأكيد → رفع: collect يشغّل Lighthouse عدة مرات ضد عنوان URL (ثلاث مرات افتراضيًا) ويأخذ التقرير الوسيط بدلاً من الثقة بمرور واحد؛ assert يتحقق من ذلك التقرير مقابل عتبات تقوم بتكوينها — اضبطها على warn أو error لكل فئة أو مقياس؛ upload يخزن التقرير حتى تتمكن من تتبع خطوط الاتجاه عبر الإصدارات. تعامل مع العتبات كسياسة انحدار لفريقك، وليس كحكم على البيانات الميدانية أو ضمان ترتيب — إنها تلتقط “هذا أصبح أسوأ”، وليس تصديق “هذا سريع للمستخدمين”.
• إضافة Chrome — موجودة، لكن DevTools هو المسار الموصى به داخل المتصفح.

تتطلب سير عمل CLI وNode تثبيت Chrome محليًا للقيادة.

الخرافات التي تستحق التفنيد

• “Lighthouse score 100 = higher rankings.” (ترجمة) «درجة Lighthouse 100 = ترتيب أعلى.» لا. درجة الأداء هي بيانات مختبرية؛ ليست إشارة ترتيب. تستخدم إشارات تجربة الصفحة من Google بيانات ميدانية لمؤشرات Core Web Vitals (CrUX)، وحتى ذلك هو إشارة خفيفة واحدة من بين العديد — الصلة وجودة المحتوى تهيمنان. اهدف إلى درجة قوية لأنها جيدة للمستخدمين، وليس لأنها رافعة ترتيب.
• “Lighthouse = field data / what real users experience.” (ترجمة) «Lighthouse = بيانات ميدانية / ما يختبره المستخدمون الحقيقيون.» لا. إنها ظروف مختبرية مخنوقة أسوأ مما يراه معظم المستخدمين الحقيقيين. المستخدمون الحقيقيون لديهم مخابئ دافئة، وbfcache، وأجهزة متنوعة. Lighthouse هو اختبار إجهاد شبه أسوأ حالة، وليس قراءة لمتوسط المستخدمين.
• “PageSpeed Insights is Lighthouse.” (ترجمة) «PageSpeed Insights هو Lighthouse.» جزئيًا. يشغّل PSI Lighthouse للقسم المختبري ويضيف CrUX للقسم الميداني. الأرقام الميدانية — المرتبطة بتجربة الصفحة — هي CrUX، وليس Lighthouse.
• “The PWA category still counts.” (ترجمة) «فئة PWA لا تزال تُحتسب.» لا تحتسب. تمت إزالة PWA كفئة مُسجلة في Lighthouse 12.

الخلاصة

Lighthouse هي واحدة من أكثر الأدوات المجانية فائدة في تحسين محركات البحث التقني وأداء الويب — طريقة سريعة وقابلة للتكرار لاكتشاف ما يبطئ الصفحة والحماية من الانحدارات في CI. فقط أمسكها على الارتفاع الصحيح: إنها تشخيص مخبري، وليست حكمًا على تجربة المستخدم الحقيقية وليست درجة ترتيب. استخدمها للاكتشاف والإصلاح؛ استخدم بيانات الحقل (CrUX، Core Web Vitals في Search Console) للحكم على ما إذا كان المستخدمون الحقيقيون يستمتعون بالفعل.

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

نظرة مختصرة على النسخة المتقدمة:

• Lighthouse = أداة تدقيق مخبرية آلية مفتوحة المصدر من فريق Chrome. أعطها عنوان URL؛ تقوم بتدقيق الصفحة وتسجيل الأداء، إمكانية الوصول، أفضل الممارسات، SEO. تمت إزالة PWA في Lighthouse 12 (~2024).
• مخبري، وليس ميداني. يقوم بتحميل الصفحة تحت محاكاة خنق — تقريبًا Slow 4G + 4× CPU — عن طريق التصميم، لإظهار ما تعاني منه الأجهزة/الشبكات الأبطأ. لهذا السبب يمكن أن يحصل موقع “سريع” على درجة منخفضة.
• درجة الأداء = متوسط مرجح لخمسة مقاييس مخبرية: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. تمت إزالة FID وFirst Meaningful Paint.
• النطاقات: 0–49 أحمر (ضعيف)، 50–89 برتقالي (يحتاج تحسينًا)، 90–100 أخضر (جيد). يتم تعيين درجات المقاييس على منحنى HTTP Archive لوغاريتمي طبيعي، لذا النقاط العليا هي الأصعب. الفرص/التشخيصات توجه الإصلاحات لكنها لا تغير الدرجة مباشرة.
• تختلف الدرجات من تشغيل إلى آخر — الإعلانات، اختبارات A/B، الإضافات، ظروف الشبكة/الخادم، وحمل الجهاز (خنق وحدة المعالجة المركزية نسبي بالنسبة للمضيف). تعامل معها كتوزيع، وليس رقمًا واحدًا؛ قم بالتشغيل في وضع التصفح الخاص مع تعطيل الإضافات، وسجل إصدار Lighthouse والإعدادات التي استخدمتها.
• Lighthouse CI يؤتمت هذا: يجمع عدة تشغيلات (ثلاثة افتراضيًا)، يأخذ الوسيط، ويؤكد عتبات فريقك — سياسة لالتقاط الانحدارات، وليست حكمًا على بيانات الحقل.
• Lighthouse ≠ PageSpeed Insights: PSI يشغل Lighthouse (مخبري) و يضيف بيانات حقل CrUX (مستخدمون حقيقيون). غالبًا ما يختلفان.
• Lighthouse يقيس LCP/CLS في المختبر لكنه لا يستطيع قياس INP بالطريقة التي يفعلها الحقل — يستخدم TBT كبديل. بيانات الحقل (CrUX) هي ما يعكس المستخدمين الحقيقيين ويغذي إشارات تجربة الصفحة.
• ليست إشارة ترتيب. درجة 100 لا تعني ترتيبًا أعلى، والدرجة المخبرية المنخفضة لا تعني تجربة مستخدم حقيقية سيئة. استخدم Lighthouse للتصحيح؛ استخدم بيانات الحقل للحكم.

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

وثائق المصدر الأساسي من فريق Google Chrome.

• نظرة عامة على Lighthouse — ما هو Lighthouse، وفئات التدقيق، وكل طريقة لتشغيله (DevTools، CLI، Node، PageSpeed Insights، الإضافة، Lighthouse CI).
• تسجيل أداء Lighthouse — أوزان المقاييس، ونطاقات الألوان 0–49 / 50–89 / 90–100، ومنحنى التسجيل اللوغاريتمي الطبيعي.
• تدقيقات PWA في Lighthouse — يحمل إشعار الإهمال لفئة PWA المحذوفة.
• خنق Lighthouse (GitHub) — الخنق المحاكى مقابل المطبق، وإعداد Slow 4G، ومضاعف 4× CPU.
• سجل تغييرات Lighthouse (GitHub) — تغييرات v12: إزالة PWA، إزالة First Meaningful Paint، رفع INP.
• حاسبة تسجيل Lighthouse — أدخل قيم المقاييس وشاهد درجة الأداء الناتجة؛ مفيدة لتحديد الأهداف.

مخبري مقابل ميداني (web.dev)

• مقاييس الأداء التي تركز على المستخدم — لماذا الاختبار المخبري “ليس بالضرورة انعكاسًا لكيفية تجربة المستخدمين الفعليين لموقعك.”

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

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

ما هو Lighthouse وكيف يعمل

• “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (ترجمة) «Lighthouse هي أداة مفتوحة المصدر وآلية لمساعدتك على تحسين جودة صفحات الويب.» — developer.chrome.com، نظرة عامة على Lighthouse. الانتقال إلى الاقتباس
• “Give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” (ترجمة) «أعطِ Lighthouse عنوان URL لتدقيقه، فيقوم بتشغيل سلسلة من عمليات التدقيق على الصفحة، ثم يُنشئ تقريرًا حول مدى جودة أداء الصفحة.» — developer.chrome.com، نظرة عامة على Lighthouse. الانتقال إلى الاقتباس

كيف تعمل درجة الأداء

• “The Performance score is a weighted average of the metric scores.” (ترجمة) «درجة الأداء متوسط مرجح لدرجات المقاييس.» — developer.chrome.com, Lighthouse performance scoring. الانتقال إلى الاقتباس
• “Once Lighthouse has gathered the performance metrics (mostly reported in milliseconds), it converts each raw metric value into a metric score from 0 to 100 by looking where the metric value falls on its Lighthouse scoring distribution.” (ترجمة) «بعد أن تجمع Lighthouse مقاييس الأداء (المبلّغ عنها غالبًا بالمللي ثانية)، تحول كل قيمة خام إلى درجة مقياس من 0 إلى 100 بالنظر إلى موضعها في توزيع تسجيل Lighthouse.» — developer.chrome.com, Lighthouse performance scoring. الانتقال إلى الاقتباس
• حول نطاقات الدرجة: “0 to 49 (red): Poor” (ترجمة) «من 0 إلى 49 (أحمر): ضعيف» — مع 50–89 برتقالي (يحتاج إلى تحسين) و90–100 أخضر (جيد). الانتقال إلى الاقتباس

لماذا تختلف الدرجات

• “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse. When your Performance score fluctuates it’s usually because of changes in underlying conditions.” (ترجمة) «الكثير من التباين في درجة الأداء الإجمالية وقيم المقاييس ليس بسبب Lighthouse؛ فعندما تتذبذب درجة الأداء يكون ذلك عادةً بسبب تغير الظروف الأساسية.» — developer.chrome.com, Lighthouse performance scoring. الانتقال إلى الاقتباس

المختبر مقابل الميدان

• “While testing in the lab is a reasonable proxy for performance, it isn’t necessarily reflective of how actual users experience your site.” (ترجمة) «رغم أن الاختبار في المختبر بديل معقول للأداء، فإنه لا يعكس بالضرورة كيفية تجربة المستخدمين الفعليين لموقعك.» — web.dev, User-centric performance metrics. الانتقال إلى الاقتباس

الحصول على قراءة موثوقة من Lighthouse — قائمة تحقق

قبل أن تعتمد على درجة Lighthouse، تأكد من أن الرقم يعني شيئًا:

• قم بتشغيله في نافذة التصفح الخفي مع تعطيل الإضافات (الإضافات تحقن JavaScript وتُحرف النتيجة).
• قم بتشغيله عدة مرات وانظر إلى النطاق — تعامل معه كتوزيع، وليس كرقم واحد.
• تأكد من أنك تقارن نفس عامل الشكل في كل مرة (الجوال مقابل سطح المكتب — يختلف الاختناق).
• اعرف مجموعة البيانات التي تقرأها: مختبري (Lighthouse) مقابل ميداني (CrUX) في PageSpeed Insights. لا تخلط بينهما.
• لأسئلة الترتيب/تجربة الصفحة، انظر إلى البيانات الميدانية (Core Web Vitals في Search Console / CrUX)، وليس درجة Lighthouse المخبرية.
• تذكر أن Lighthouse لا يمكنه قياس INP بنفس الطريقة التي يقيسها الميدان — TBT هو وكيل، وليس ضمانًا.
• أصلح من قوائم الفرص/التشخيصات، لكن تحقق من التغيير من خلال مراقبة المقياس (فقط المقاييس تغير النتيجة).
• للقياس المتكرر في الأتمتة، استخدم Lighthouse CI مع ميزانيات بدلاً من التقدير البصري للتشغيلات الفردية.
• تحكم في ما تعرضه الصفحة عند التحميل: لافتات ملفات تعريف الارتباط/الموافقة، حالة تسجيل الدخول، والذاكرة المؤقتة (باردة مقابل دافئة) كلها تغير عمليات التدقيق التي تعمل — اختر حالة واحدة وكن متسقًا بشأنها.
• انتبه إلى المحتوى غير الحتمي — اختبارات A/B، والإعلانات الدوارة، وغيرها من البرامج النصية الخارجية يمكن أن تقدم حمولة مختلفة في كل تشغيل وتُحرف النتيجة بشكل مستقل عن أي شيء غيرته.
• دع الصفحة تنتهي فعليًا من التحميل قبل تشغيل التدقيق (أو استخدم وضعًا ينتظر ذلك) — قطع التشغيل مبكرًا يقرأ الصفحة بشكل خاطئ.
• سجل إصدار Lighthouse وإعدادات التشغيل (الوضع، طريقة الاختناق، الجهاز) بجانب النتيجة — “نفس” النتيجة من إصدار مختلف أو تكوين مختلف ليست قابلة للمقارنة فعليًا.
• تجاهل أي دليل لا يزال يسجل فئة PWA — تمت إزالتها في Lighthouse 12.

درجة أداء Lighthouse — ورقة غش

المقاييس الخمسة وأوزانها (ترجيح Lighthouse 10)

متقاعد / مُزال: FID، الوقت حتى التفاعل، أول رسم ذو معنى.

نطاقات ألوان النتيجة

مُخطط على منحنى أرشيف HTTP اللوغاريتمي الطبيعي: ~النسبة المئوية 25 → 50، ~النسبة المئوية 8 → 90. النقاط الأخيرة هي الأصعب في كسبها.

الظروف المخبرية الافتراضية

• الشبكة: جوال 4G بطيء (~150 مللي ثانية زمن الوصول، ~1,6 ميجابت/ثانية للتنزيل / 750 كيلوبت/ثانية للرفع)
• وحدة المعالجة المركزية: مضاعف 4× ثابت (جوال متوسط المستوى على أجهزة سطح المكتب)
• الاختناق: محاكى افتراضيًا (سريع، حتمي)، وليس مطبقًا من DevTools

Lighthouse مقابل PageSpeed Insights

حقائق سريعة

• الفئات اليوم: الأداء، إمكانية الوصول، أفضل الممارسات، SEO (تمت إزالة PWA في Lighthouse 12).
• إنها ليست إشارة ترتيب. 100 ≠ ترتيب أعلى.
• لا يمكنها قياس INP مثل الميدان — تستخدم TBT كبديل.
• النتائج تختلف من تشغيل لآخر — هذا متوقع.

طرق تشغيل Lighthouse (والأدوات ذات الصلة)

• Chrome DevTools — لوحة Lighthouse — مدمج في Chrome؛ الأفضل لتدقيق الصفحات التي تتطلب تسجيل دخول.
• PageSpeed Insights (pagespeed.web.dev) — لا يتطلب تثبيتًا؛ يشغل Lighthouse ويضيف بيانات CrUX الميدانية بجانبه.
• Lighthouse CLI — npm install -g lighthouse، ثم lighthouse <url>؛ قابل للبرمجة، يتطلب Chrome محليًا.
• وحدة Lighthouse Node — يمكنك دمجها في أدواتك الخاصة برمجيًا.
• Lighthouse CI (@lhci/cli) — شغّل Lighthouse في كل نشر، وحدد الميزانيات، وافشل البناء عند الانحدارات. الأداة المناسبة لمنع انزلاق النتيجة بصمت.
• حاسبة نتائج Lighthouse (scorecalc) — أدخل قيم المقاييس لرؤية نتيجة الأداء الناتجة وتحديد أهداف واقعية.
• إضافة Chrome — متاحة، لكن DevTools هو المسار الموصى به داخل المتصفح.

للحصول على بيانات المستخدمين الحقيقيين (الميدانية) لمقارنتها بهذه الأدوات المختبرية، انظر إلى تقرير Core Web Vitals في Google Search Console وقسم CrUX الميداني في PageSpeed Insights.

عادات Lighthouse تخلق ثقة زائفة

• السعي للوصول إلى 100 كهدف تجاري. النتيجة المختبرية المثالية ليست تعزيزًا للترتيب وقد تصرف الانتباه عن Core Web Vitals الميدانية ونتائج المستخدمين الحقيقيين. استخدم التقرير للعثور على الاختناقات، ثم تحقق من استفادة المستخدمين.
• التعامل مع تشغيل واحد كحكم نهائي. Lighthouse اختبار محاكى ويتغير بشكل طبيعي. شغّله عدة مرات تحت نفس الظروف وابحث عن نمط ثابت بدلاً من التفاعل مع نتيجة واحدة.
• تسمية TBT المختبرية بنفس اسم INP الميداني. TBT وكيل مختبرى مفيد لحظر الخيط الرئيسي؛ INP يقيس التفاعلات الحقيقية في الميدان. TBT جيد هو دليل، وليس إثباتًا، على أن INP جيد.
• إصلاح كل تدقيق بالترتيب المدرج. تقديرات الفرص تتداخل، وبعض التدقيقات لها تأثير ضئيل على الاختناق الفعلي للصفحة. ابدأ بالتتبع، والمقاييس ذات الوزن الأكبر، والموارد المسؤولة عنها.
• مقارنة نتائج الجوال وسطح المكتب مباشرة. ملفات المحاكاة وتوزيعات النتائج مختلفة. قارن المتشابه مع المتشابه.

تغيرات نتيجة Lighthouse بين التشغيلات

العرض: نفس الصفحة تنتقل بين نطاقات الألوان دون نشر.

السبب المحتمل: استجابة خادم متغيرة، أو نصوص طرف ثالث، أو حمل آلة مشترك، أو إعدادات اختبار مختلفة غيّرت التشغيل المحاكى.

الإصلاح والتأكيد: طابق عنوان URL، وملف الجهاز، والاختناق، وحالة التخزين المؤقت، وموقع الاختبار؛ شغّل عدة اختبارات؛ ثم قارن التتبع الوسيط وتوقيتات المقاييس.

Core Web Vitals الميدانية ناجحة لكن Lighthouse أحمر

العرض: بيانات PSI الميدانية ناجحة بينما نتيجة أداء Lighthouse ضعيفة.

السبب المحتمل: القسمان يقيسان مجموعات مختلفة: CrUX يلخص المستخدمين الحقيقيين على مر الزمن، بينما يشغل Lighthouse تحميل صفحة محاكى واحد.

الإصلاح والتأكيد: تعامل مع التقييم الميداني كنتيجة للمستخدم واستخدم التتبع المختبرى لإعادة إنتاج وتشخيص سيناريو جهاز بطيء. أكد أي إصلاح في كل من التشغيلات المختبرية المتكررة ونافذة الإبلاغ الميدانية التالية.

Lighthouse لا يمكنه قياس INP

العرض: التقرير يعرض TBT لكن لا توجد قيمة INP مختبرية.

السبب المحتمل: INP يتطلب تفاعلات حقيقية عبر زيارة الصفحة؛ تشغيل Lighthouse الذي يركز على التنقل فقط ليس لديه تاريخ تفاعل تمثيلي.

الإصلاح والتأكيد: استخدم TBT والتتبع للعثور على المهام الطويلة في المختبر، ثم قم بقياس INP باستخدام البيانات الميدانية أو تسجيل يركز على التفاعل.

تدقيق يستمر بعد الإصلاح الواضح

العرض: Lighthouse لا يزال يشير إلى مورد بعد تحسينه أو إزالته.

السبب المحتمل: استجابة مخزنة مؤقتًا، أو قالب آخر، أو نسخة طرف ثالث، أو طلب مختلف في السلسلة لا يزال يطلق التدقيق.

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

اختبر نفسك: Google Lighthouse

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

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

رسمي

• نظرة عامة على Lighthouse — المرجع النهائي لما هو وكيف وأين يتم التشغيل.
• تسجيل أداء Lighthouse — الأوزان والنطاقات ومنحنى التسجيل.
• وثائق تقييد Lighthouse (GitHub) — شروط المختبر بالتفصيل.
• حاسبة تسجيل Lighthouse — هندسة عكسية لأهداف المقاييس للحصول على درجة.
• مقاييس الأداء التي تركز على المستخدم — حجة المختبر مقابل المستخدمين الحقيقيين، من Google.

أين يتناسب Lighthouse

• اقرن درجة المختبر بـ بيانات ميدانية: تقرير Core Web Vitals في Google Search Console وقسم CrUX في PageSpeed Insights. يجد المختبر المشاكل؛ وتخبرك البيانات الميدانية ما إذا كان المستخدمون الحقيقيون يشعرون بها.

من جميع أنحاء الصناعة

• الاختلافات بين البيانات الميدانية وبيانات المختبر (web.dev) — تحليل Google الخاص لمتى تثق بأرقام المختبر مقابل الميدان ولماذا تتباعد.
• Core Web Vitals (web.dev) — المرجع الأساسي حول مقاييس CWV التي يمكن لـ Lighthouse قياسها والتي لا يمكنه قياسها، بما في ذلك فجوة INP.
• Largest Contentful Paint (web.dev) — غوص عميق في عتبات LCP ولماذا تختلف قراءات المختبر والميدان غالبًا.
• Lighthouse CI على GitHub — المستودع الرسمي ودليل الإعداد لدمج Lighthouse في خطوط CI/CD الآلية.
• HTTP Archive Web Almanac — فصل الأداء — بيانات سنوية عن درجات Lighthouse الواقعية ومعدلات اجتياز Core Web Vitals عبر ملايين الصفحات؛ مفيد لقياس درجاتك مقارنة بالويب بشكل عام.
• web.dev — قياس أداء الصفحة — نقطة البداية الموصى بها من Google لدمج نتائج Lighthouse مع أدوات البيانات الميدانية.

أرقام تستحق الاستشهاد

• أوزان درجة الأداء (Lighthouse 10): TBT 30%، LCP 25%، CLS 25%، FCP 10%، Speed Index 10%. المصدر
• نطاقات الدرجات: 0–49 أحمر (ضعيف)، 50–89 برتقالي (يحتاج تحسينًا)، 90–100 أخضر (جيد). تقابل 90 تقريبًا النسبة المئوية الثامنة من بيانات HTTP Archive؛ و50 تقابل النسبة المئوية الخامسة والعشرين. المصدر
• التقييد الافتراضي: جوال Slow 4G (~150 مللي ثانية زمن انتقال، ~1,6 ميجابت/ثانية تنزيل) بالإضافة إلى مضاعف وحدة معالجة مركزية 4× — محاكاة تقريبًا النسبة المئوية الخامسة والثمانين لاتصال الجوال. المصدر
• الفئات: أربع اليوم (Performance، Accessibility، Best Practices، SEO) — تمت إزالة PWA في Lighthouse 12 (~2024). المصدر

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