تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تقدّم "إحصاءات PageSpeed" تقارير عن تجربة المستخدم في صفحة معيّنة على كلّ من الأجهزة
الجوّالة وأجهزة الكمبيوتر المكتبي، وتقدّم اقتراحات حول كيفية تحسين تلك الصفحة.
توفر PSI بيانات كل من المعمل والميدان حول الصفحة. تكون بيانات المختبر مفيدة لتصحيح أخطاء
المشاكل، لأنّه يتم جمعها في بيئة خاضعة للرقابة. ومع ذلك، قد لا
التقاط المعوقات في العالم الحقيقي. تكون بيانات الحقل مفيدة لتسجيل بيانات مستخدم حقيقي
المستخدم - ولكن لديها مجموعة محدودة أكثر من المقاييس. اطّلِع على كيفية التفكير
في أدوات السرعة للحصول على مزيد من المعلومات عن نوعَي البيانات.
لعرض بيانات تجربة المستخدِم لصفحة معيّنة، يجب أن تتوفّر بيانات كافية لدمجها في مجموعة بيانات CrUX. قد لا تتوفّر بيانات كافية للصفحة إذا كانت
قد تم نشرها مؤخرًا أو إذا كانت تحتوي على عدد قليل جدًا من العيّنات من مستخدمين حقيقيين. وعندما يحدث ذلك، ستعود سرعة التحميل إلى
الدقة على مستوى المصدر، والتي تشمل جميع تجارب المستخدمين على جميع صفحات
الموقع الإلكتروني. في بعض الأحيان قد يحتوي المصدر أيضًا على بيانات غير كافية، وفي هذه الحالة ستكون PSI
ويتعذّر عليك إظهار أي بيانات لتجربة المستخدم الحقيقية.
تقييم جودة التجارب
تصنف PSI جودة تجربة المستخدم في ثلاث مجموعات: جيدة، بحاجة إلى تحسين،
أو سيء. تضع PSI الحدود الدنيا التالية بما يتوافق مع مبادرة
مؤشرات أداء الويب:
جيد
بحاجة إلى تحسين
سيئ
سرعة عرض المحتوى على الصفحة
[0، 1800 ملي ثانية]
[1800ms, 3000ms]
أكثر من 3000 ملي ثانية
سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)
[0، 2500 ملي ثانية]
(2500 ملي ثانية، 4000 ملي ثانية]
أكثر من 4000 ملّي ثانية
متغيّرات التصميم التراكمية (CLS)
[0, 0.1]
[0.1, 0.25]
أكثر من 0.25
مدى استجابة الصفحة لتفاعلات المستخدم (INP)
[0, 200ms]
[200 ملي ثانية، 500 ملي ثانية]
أكثر من 500 ملي ثانية
TTFB (إصدار تجريبي)
[0، 800 ملي ثانية]
[800ms, 1800ms]
أكثر من 1800 ملّي ثانية
التوزيع وقيم المقياس المحدّدة
تعرِض تجربة الصفحة توزيعًا لهذه المقاييس حتى يتمكّن المطوّرون من فهم نطاق تجربتَي
الصفحة أو المصدر. ينقسم هذا التوزيع إلى ثلاث فئات:
جيد، بحاجة إلى تحسين، ضعيف، التي يتم تمثيلها بأشرطة خضراء وكهرمانية وحمراء.
على سبيل المثال، إنّ ظهور% 11 ضمن شريط الكهرمان الخاص بمقياس LCP يشير إلى أنّ% 11 من جميع قيم LCP المرصودة
تقع بين 2500 ملّي ثانية و4,000 ملّي ثانية.
فوق أشرطة التوزيع، يعرض مؤشر PSI الشريحة المئوية الخامسة والسبعون لجميع المقاييس. يتم اختيار الشريحة المئوية
التسعون ليتمكّن المطوّرون من فهم تجارب المستخدمين المقلقة
على موقعهم الإلكتروني. ويتم تصنيف قيم مقاييس الحقل هذه على أنها
جيد/بحاجة إلى تحسين/ضعيف من خلال تطبيق نفس المعايير الموضحة أعلاه.
مؤشرات أداء الويب الأساسية
مؤشرات أداء الويب الأساسية هي مجموعة شائعة من إشارات الأداء المهمة
جميع تجارب الويب. مقاييس "مؤشرات أداء الويب الأساسية" هي مدى استجابة الصفحة لتفاعلات المستخدم (INP) وسرعة عرض أكبر محتوى مرئي (LCP) ومتغيّرات التصميم التراكمية (CLS)، ويمكن جمعها
على مستوى الصفحة أو المصدر. بالنسبة إلى التجميعات التي تتضمّن بيانات كافية في جميع
ثلاثة مقاييس، يجتاز التجميع تقييم Core Web Vitals إذا كانت الشرائح المئوية الخامسة والسبعين
جميع المقاييس الثلاثة جيّدة وبخلاف ذلك، لن يجتاز التجميع التقييم. إذا كانت عملية جمع البيانات
لا تتضمّن بيانات كافية لمقياس مدى استجابة الصفحة لتفاعلات المستخدم، ستجتاز التقييم إذا كانت الشريحة المئوية الـ
الـ 75 لكل من LCP وCLS "جيّد". إذا لم تتوفّر بيانات كافية لكلّ من LCP أو CLS، لا يمكن تقييم التجميع على مستوى الصفحة أو
المصدر.
الاختلافات بين البيانات الميدانية في PSI وCrUX
يتمثل الفرق بين بيانات الحقل في PSI مقارنةً بمجموعة بيانات CrUX على BigQuery في أنّه يتم تعديل بيانات PSI يوميًا،
في حين يتم تعديل مجموعة بيانات BigQuery شهريًا وتقتصر على البيانات على مستوى المصدر.
يمثّل كلا مصدرَي البيانات فترات 28 يومًا متتالية.
التشخيص المعملي
تستخدِم PSI Lighthouse لتحليل عنوان URL المحدّد في بيئة اصطناعية
للفئات "الأداء" و"تسهيل الاستخدام" و"أفضل الممارسات" و"تحسين محركات البحث".
النتيجة
في أعلى القسم، تظهر الدرجات لكل فئة، ويتم تحديدها من خلال تشغيل Lighthouse
لجمع المعلومات التشخيصية عن الصفحة وتحليلها. يُعدّ تحقيق نتيجة 90 أو أعلى
جيدًا. تشير النتيجة من 50 إلى 89 إلى أنّ هناك حاجة إلى تحسين، وتكون النتيجة أقل من 50 إذا كان الأداء ضعيفًا.
يتم الإشارة إلى المحتوى الذي "بحاجة إلى تحسين" من خلال مربّع معلوماتي برتقالي
يُشار إلى الأداء السيئ بمثلث تحذير أحمر.
عمليات التدقيق
ضمن كل فئة، تتوفّر عمليات تدقيق تقدّم معلومات عن كيفية تحسين تجرب
ة المستخدم في الصفحة. اطّلِع على مستندات Lighthouse للحصول على تفاصيل
عن تقسيم عمليات التدقيق في كل فئة.
الأسئلة الشائعة
ما هي ظروف الجهاز والشبكة التي تستخدمها أداة Lighthouse لمحاكاة تحميل صفحة؟
في الوقت الحالي، يحاكي Lighthouse شروط تحميل الصفحة لجهاز من المستوى المتوسط (Moto G4)
على شبكة الجوّال للأجهزة الجوّالة
جهاز كمبيوتر مكتبي في وضع المحاكاة من خلال اتصال سلكي للكمبيوتر المكتبي. يتم أيضًا تشغيل PageSpeed في أحد مراكز بيانات Google
التي يمكن أن تختلف استنادًا إلى ظروف الشبكة، ويمكنك التحقّق من الموقع الجغرافي الذي تم فيه الاختبار
من خلال الاطّلاع على مجموعة البيئة في تقرير Lighthouse:
ملاحظة: سيُبلغ PageSpeed عن التشغيل في إحدى المناطق التالية: أمريكا الشمالية أو أوروبا أو آسيا.
لماذا تتناقض البيانات الميدانية مع بيانات المختبر في بعض الأحيان؟
تعرض بيانات الحقل تقريرًا تاريخيًا حول مستوى أداء عنوان URL معيّن، وتمثّل
بيانات أداء مجهولة الهوية من مستخدمين فعليين على مجموعة متنوعة من الأجهزة والشبكات
الظروف. تستند بيانات المختبر إلى عملية تحميل محاكية لصفحة على جهاز واحد ومجموعة ثابتة
من حالات الشبكة. ونتيجةً لذلك، قد تختلف القيم.
اطّلِع على أسباب اختلاف بيانات المختبر عن بيانات الحقل
(وما يجب فعله حيال ذلك) للحصول على مزيد من المعلومات.
لماذا يتم اختيار الشريحة المئوية الخامسة والسبعين لجميع المقاييس؟
هدفنا هو التأكّد من أنّ الصفحات تعمل بشكل جيد لمعظم المستخدمين. بالتركيز على الخامس والسبعين
بالنسبة المئوية للمقاييس، فإن ذلك يضمن تقديم الصفحات لتجربة مستخدم جيدة
في ظل أصعب ظروف الجهاز والشبكات.
اطّلِع على تحديد الحدود الدنيا لمقاييس "مؤشرات أداء الويب الأساسية"
للحصول على مزيد من المعلومات.
ما الدرجة الجيدة لبيانات المعمل؟
تُعدّ أي نتيجة خضراء (90 أو أكثر) جيدة، ولكن يُرجى العِلم أنّ الحصول على بيانات جيدة في المختبر لا يشير بالضرورة إلى أنّ تجارب المستخدمين الفعليين ستكون جيدة أيضًا.
لماذا تتغيّر نتيجة الأداء من عملية تنفيذ إلى أخرى؟ لم أُجري أي تغيير على صفحتي.
يتمّ إدخال التفاوت في قياس الأداء من خلال
عدد من القنوات ذات مستويات مختلفة من التأثير. تشمل المصادر الشائعة لعدم ثبات المقياس
مدى توفّر الشبكة المحلية وتوفّر أجهزة العميل وازدحام موارد العميل
.
Why is the real-user CrUX data not available for a URL or origin?
يجمع "تقرير تجربة المستخدم" في Chrome بيانات السرعة الفعلية من
المستخدِمين الذين فعّلوا الميزة ويتطلب
أن يكون عنوان URL متاحًا للجميع
(قابلاً للزحف والفهرسة)
وأن يتضمّن عددًا كافيًا من العيّنات المختلفة التي تقدّم عرضًا تمثيليًا مجهول الهوية
لأداء عنوان URL أو المصدر.
هل لديك أسئلة أخرى؟
إذا كان لديك سؤال محدد ويمكن الإجابة عنه حول استخدام "إحصاءات PageSpeed"،
اطرح سؤالك باللغة الإنجليزية على موقع Stack Overflow.
إذا كانت لديك ملاحظات أو أسئلة عامة حول "إحصاءات PageSpeed"، أو أردت بدء
مناقشة عامة، يمكنك إنشاء سلسلة رسائل في القائمة البريدية.
إذا كانت لديك أسئلة عامة حول مقاييس "مؤشرات أداء الويب"، ابدأ سلسلة محادثات في مجموعة المناقشة web-vitals-feedback.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003ePageSpeed Insights (PSI) assesses the performance of web pages on both mobile and desktop, offering suggestions for optimization by analyzing lab and real-world data.\u003c/p\u003e\n"],["\u003cp\u003ePSI utilizes the Chrome User Experience Report (CrUX) for real-world data, measuring metrics like First Contentful Paint (FCP), Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP).\u003c/p\u003e\n"],["\u003cp\u003eLab data is generated through Lighthouse, simulating page load and providing diagnostics on performance, accessibility, best practices, and SEO.\u003c/p\u003e\n"],["\u003cp\u003ePSI categorizes user experiences into Good, Needs Improvement, and Poor based on established thresholds for key performance metrics.\u003c/p\u003e\n"],["\u003cp\u003eCore Web Vitals, a subset of critical performance signals, includes LCP, CLS, and INP, and their assessment determines the overall page experience quality.\u003c/p\u003e\n"]]],["PageSpeed Insights (PSI) analyzes page performance on mobile and desktop, offering lab and field data. Field data, powered by the Chrome User Experience Report (CrUX), reflects real-world user experiences, measuring metrics like First Contentful Paint (FCP), Interaction to Next Paint (INP), Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Time to First Byte (TTFB), and the quality of them. PSI classifies experiences as Good, Needs Improvement, or Poor. Lab data uses Lighthouse to simulate page loads, providing diagnostic scores and metrics.\n"],null,["PageSpeed Insights (PSI) reports on the user experience of a page on both mobile and desktop\ndevices, and provides suggestions on how that page may be improved.\n\n\nPSI provides both lab and field data about a page. Lab data is useful for debugging\nissues, as it is collected in a controlled environment. However, it may not\ncapture real-world bottlenecks. Field data is useful for capturing true, real-world user\nexperience - but has a more limited set of metrics. See [How To Think\nAbout Speed Tools](/web/fundamentals/performance/speed-tools) for more information on the two types of data.\n\nReal-user experience data\n\n\nReal-user experience data in PSI is powered by the [Chrome User Experience\nReport](/web/tools/chrome-user-experience-report) (CrUX) dataset. PSI reports real users' [First\nContentful Paint](https://web.dev/articles/fcp) (FCP), [Interaction to Next Paint](https://web.dev/articles/inp) (INP),\n[Largest Contentful Paint](https://web.dev/articles/lcp) (LCP), and [Cumulative Layout\nShift](https://web.dev/articles/cls) (CLS) experiences over the previous 28-day collection period. PSI also reports\nexperiences for the experimental metric [Time to First Byte](https://web.dev/articles/ttfb) (TTFB).\n\n\nIn order to show user experience data for a given page, there must be sufficient data for it\nto be included in the CrUX dataset. A page might not have sufficient data if it has been\nrecently published or has too few samples from real users. When this happens, PSI will fall\nback to origin-level granularity, which encompasses all user experiences on all pages of the\nwebsite. Sometimes the origin may also have insufficient data, in which case PSI will be\nunable to show any real-user experience data.\n\nAssessing quality of experiences\n\n\nPSI classifies the quality of user experiences into three buckets: Good, Needs Improvement,\nor Poor. PSI sets the following thresholds in alignment with the\n[Web Vitals](https://web.dev/articles/vitals) initiative:\n\n| | Good | Needs Improvement | Poor |\n|---------------------|---------------|-------------------|-------------|\n| FCP | \\[0, 1800ms\\] | (1800ms, 3000ms\\] | over 3000ms |\n| LCP | \\[0, 2500ms\\] | (2500ms, 4000ms\\] | over 4000ms |\n| CLS | \\[0, 0.1\\] | (0.1, 0.25\\] | over 0.25 |\n| INP | \\[0, 200ms\\] | (200ms, 500ms\\] | over 500ms |\n| TTFB (experimental) | \\[0, 800ms\\] | (800ms, 1800ms\\] | over 1800ms |\n\nDistribution and selected metric values\n\n\nPSI presents a distribution of these metrics so that developers can understand the range of\nexperiences for that page or origin. This distribution is split into three categories:\nGood, Needs Improvement, and Poor, which are represented by green, amber, and red bars.\nFor example, seeing 11% within LCP's amber bar indicates that 11% of all observed LCP values\nfall between 2500ms and 4000ms.\n\n\nAbove the distribution bars, PSI reports the 75th percentile for all metrics. The 75th\npercentile is [selected](#why-is-the-75th-percentile-chosen-for-all-metrics) so that developers can understand the most\nfrustrating user experiences on their site. These field metric values are classified as\ngood/needs improvement/poor by applying the same thresholds shown above.\n\nCore Web Vitals\n\n\nCore Web Vitals are a common set of performance signals critical to\nall web experiences. The Core Web Vitals metrics are INP, LCP, and CLS, and they may be\naggregated at either the page or origin level. For aggregations with sufficient data in all\nthree metrics, the aggregation passes the Core Web Vitals assessment if the 75th percentiles\nof all three metrics are Good. Otherwise, the aggregation does not pass the assessment. If the\naggregation has insufficient data for INP, then it will pass the assessment if both the 75th\npercentiles of LCP and CLS are Good. If either LCP or CLS have insufficient data, the page or\norigin-level aggregation cannot be assessed.\n\nDifferences between Field Data in PSI and CrUX\n\n\nThe difference between the field data in PSI versus the\n[CrUX dataset on BigQuery](https://developer.chrome.com/docs/crux/guides/bigquery) is that PSI's data is updated daily,\nwhile the BigQuery dataset is updated monthly and limited to origin-level data.\nBoth data sources represent trailing 28-day periods.\n\nLab diagnostics\n\n\nPSI uses [Lighthouse](https://developer.chrome.com/docs/lighthouse/) to analyze the given URL in a simulated\nenvironment for the Performance, Accessibility, Best Practices, and SEO categories.\n\nScore\n\n\nAt the top of the section are scores for each category, determined by running Lighthouse\nto collect and analyze diagnostic information about the page. A score of 90 or above is\nconsidered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor.\n\nMetrics\n\n\nThe Performance category also has the page's performance on different metrics, including:\n[First Contentful Paint](https://web.dev/articles/fcp),\n[Largest Contentful Paint](https://web.dev/articles/lcp),\n[Speed Index](https://developer.chrome.com/docs/lighthouse/performance/speed-index/),\n[Cumulative Layout Shift](https://web.dev/articles/cls),\n[Time to Interactive](https://developer.chrome.com/docs/lighthouse/performance/interactive/),\nand [Total Blocking Time](https://web.dev/articles/tbt).\n\nEach metric is [scored](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring/) and labeled with a icon:\n\n- Good is indicated with a green circle\n- Needs Improvement is indicated with amber informational square\n- Poor is indicated with a red warning triangle\n\nAudits\n\n\nWithin each category are audits that provide information on how to improve the page's user\nexperience. See the [Lighthouse documentation](https://developer.chrome.com/docs/lighthouse/) for a detailed\nbreakdown of each category's audits.\n\nFrequently asked questions (FAQs)\n\nWhat device and network conditions does Lighthouse use to simulate a page load?\n\n\nCurrently, Lighthouse simulates the page load conditions of a mid-tier device (Moto G4) device\non a [mobile network](https://github.com/GoogleChrome/lighthouse/blob/master/docs/throttling.md) for mobile, and an\nemulated-desktop with a wired connection for desktop. PageSpeed also runs in a Google\ndatacenter that can vary based on network conditions, you can check the location that the test\nwas by looking at the Lighthouse Report's environment block:\n\n\nNote: PageSpeed will report running in one of: North America, Europe, or Asia.\n\nWhy do the field data and lab data sometimes contradict each other?\n\n\nThe field data is a historical report about how a particular URL has performed, and represents\nanonymized performance data from users in the real-world on a variety of devices and network\nconditions. The lab data is based on a simulated load of a page on a single device and fixed\nset of network conditions. As a result, the values may differ.\nSee [Why lab and field data can be different\n(and what to do about it)](https://web.dev/articles/lab-and-field-data-differences) for more info.\n\nWhy is the 75th percentile chosen for all metrics?\n\n\nOur goal is to make sure that pages work well for the majority of users. By focusing on 75th\npercentile values for our metrics, this ensures that pages provide a good user experience\nunder the most difficult device and network conditions.\nSee [Defining the Core Web Vitals metrics thresholds](https://web.dev/articles/defining-core-web-vitals-thresholds)\nfor more info.\n\nWhat is a good score for the lab data?\n\n\nAny green score (90+) is considered good, but note that having good lab data does not\nnecessarily mean real-user experiences will also be good.\n\nWhy does the performance score change from run to run? I didn't change anything on my page!\n\n\n[Variability](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring/#fluctuations) in performance measurement is introduced via a\nnumber of channels with different levels of impact. Several common sources of metric\nvariability are local network availability, client hardware availability, and client resource\ncontention.\n\nWhy is the real-user CrUX data not available for a URL or origin?\n\n\nChrome User Experience Report aggregates real-world speed data from\n[opted-in users](https://developer.chrome.com/docs/crux/methodology) and\nrequires that a URL must be public\n([crawlable and indexable](https://developer.chrome.com/docs/lighthouse/seo/is-crawlable/))\nand have sufficient number of distinct samples that provide a representative, anonymized view\nof performance of the URL or origin.\n\nMore questions?\n\n\nIf you've got a question about using PageSpeed Insights that is specific and answerable,\nask your question in English on [Stack Overflow](https://stackoverflow.com/questions/tagged/pagespeed-insights).\n\n\nIf you have general feedback or questions about PageSpeed Insights, or you want to start a\ngeneral discussion, start a thread in the [mailing list](https://groups.google.com/forum/#!forum/pagespeed-insights-discuss).\n\n\nIf you have general questions about the Web Vitals metrics, start a thread in the [web-vitals-feedback](https://groups.google.com/g/web-vitals-feedback) discussion group.\n\nFeedback\n\nWas this page helpful? \nYes Great! Thank you for the feedback. If you have a specific, answerable question about using PageSpeed Insights, ask the question in English on [Stack\n| Overflow](https://stackoverflow.com/questions/tagged/pagespeed-insights). For general questions, feedback, and discussion, start a thread in the [mailing list](https://groups.google.com/forum/#!forum/pagespeed-insights-discuss).\nNo Sorry to hear that. If you have a specific, answerable question about using PageSpeed Insights, ask the question in English on [Stack\n| Overflow](https://stackoverflow.com/questions/tagged/pagespeed-insights). For general questions, feedback, and discussion, start a thread in the [mailing list](https://groups.google.com/forum/#!forum/pagespeed-insights-discuss)."]]
