تتيح واجهة برمجة التطبيقات CrUX History API وصولًا في وقت استجابة سريع إلى بيانات تجربة المستخدم الحقيقية السابقة على مدار ستة أشهر بدقة الصفحة والمصدر.
حالة الاستخدام الشائعة
تسمح CrUX History API بطلب البحث عن مقاييس تجربة المستخدم السابقة لعنوان URI محدّد، مثل "الحصول على مؤشرات تجربة المستخدم السابقة لأصل https://example.com
".
تتّبع واجهة برمجة التطبيقات History API البنية نفسها المتّبعة في CrUX API اليومية باستثناء القيم التي يتم تقديمها في مصفوفة، ويتم تصنيف المفاتيح بأسماء جمع (على سبيل المثال، histogramTimeseries
بدلاً من histogram
، أو p75s
بدلاً من p75
).
مفتاح واجهة برمجة تطبيقات CrUX
وكما هي الحال في واجهة برمجة التطبيقات اليومية، يتطلب استخدام واجهة برمجة التطبيقات CrUX History API توفُّر مفتاح Google Cloud API يتم توفيره لاستخدام Chrome UX Report API
. يمكن استخدام المفتاح نفسه لواجهة Daily and History API.
الحصول على مفتاح واجهة برمجة التطبيقات واستخدامه
الحصول على مفتاحأو أنشئ حسابًا في صفحة بيانات الاعتماد.
بعد حصولك على مفتاح واجهة برمجة التطبيقات، يمكن لتطبيقك إلحاق مَعلمة طلب البحث.
key=yourAPIKey
إلى جميع عناوين URL للطلبات.
يمكن تضمين مفتاح واجهة برمجة التطبيقات بأمان في عناوين URL. ولا يحتاج إلى أي ترميز.
الاطّلاع على أمثلة على طلبات البحث
نموذج البيانات
يوضّح هذا القسم بالتفصيل بنية البيانات في الطلبات والردود.
تسجيل
هي معلومة واضحة عن صفحة أو موقع إلكتروني. يمكن أن يتضمّن السجلّ بيانات محدّدة لأحد المعرّفات ولمجموعة محدّدة من السمات. ويمكن أن يحتوي السجلّ على بيانات لمقياس واحد أو أكثر.
المعرفات
تحدد المعرّفات السجلات التي يجب البحث عنها. وفي CrUX، هذه المعرّفات هي صفحات الويب والمواقع الإلكترونية.
الأصل
عندما يكون المعرِّف مصدرًا، يتم تجميع كل البيانات المتوفّرة لجميع الصفحات في هذا المصدر معًا. على سبيل المثال، لنفترض أنّ مصدر http://www.example.com
يتضمّن صفحات على النحو الموضّح في خريطة الموقع هذه:
http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html
ويعني هذا أنّه عند طلب البحث في تقرير تجربة المستخدم على Chrome مع ضبط المصدر على http://www.example.com
، سيتم عرض بيانات http://www.example.com/
وhttp://www.example.com/foo.html
وhttp://www.example.com/bar.html
مجمّعة معًا، لأنّ هذه الصفحات ضمن هذا المصدر.
عناوين URL
عندما يكون المعرّف هو عنوان URL، لن يتم عرض سوى البيانات الخاصة بعنوان URL هذا المحدَّد. جارٍ إعادة النظر في خريطة موقع المصدر "http://www.example.com
":
http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html
وإذا تم ضبط المعرّف على عنوان URL بقيمة http://www.example.com/foo.html
، سيتم عرض بيانات تلك الصفحة فقط.
الأبعاد
تحدِّد السمات مجموعة معيّنة من البيانات التي يتم تجميع سجلّ وفقًا لها. على سبيل المثال، يشير شكل الجهاز PHONE
إلى أنّ السجلّ يحتوي على معلومات حول عمليات التحميل التي تمت على جهاز جوّال.
لا تتوفّر CrUX History API إلا بشكل مجمّع حسب سمة شكل الجهاز. هذه فئة عامة من الأجهزة مقسّمة إلى PHONE
وTABLET
وDESKTOP
.
المقياس
نعرض مقاييس في السلاسل الزمنية للتجميعات الإحصائية، وهي المدرجات التكرارية والنسب المئوية والكسور.
المدرجات التكرارية
عندما يتم التعبير عن المقاييس في صفيف تكراري، فإن كل إدخال للسلسلة الزمنية يمثل النسبة المئوية عمليات تحميل الصفحات التي اندرج فيها المقياس ضمن فاصل زمني، بشكلٍ يتناسب مع الكل يتم عرض نقاط البيانات بترتيب تواريخ فترة جمع البيانات التي تعرضها واجهة برمجة التطبيقات أيضًا، وتكون النقطة الأولى هي الفترة الأقدم والنقطة الأخيرة هي أحدث فترة جمع.
يظهر المدرّج التكراري لثلاثة صناديق لمثال لمقياس على النحو التالي:
{
"histogramTimeseries": [
{
"start": 0,
"end": 2500,
"densities": [0.9190, 0.9203, 0.9194, 0.9195, 0.9183, 0.9187]
},
{
"start": 2500,
"end": 4000,
"densities": [0.0521, 0.0513, 0.0518, 0.0518, 0.0526, 0.0527]
},
{
"start": 4000,
"densities": [0.0288, 0.0282, 0.0286, 0.0285, 0.0290, 0.0285]
}
],
}
تشير هذه البيانات إلى أنّ 91.90% من عمليات تحميل الصفحات قد شهدت نموذج قيمة المقياس بين 0 و2,500 ملي ثانية لفترة جمع البيانات الأولى في السجلّ، تليها 92.03% و91.94%... لا يتضمّن هذا المدرج التكراري وحدات المقياس، وسنفترض في هذه الحالة بالملي ثانية.
بالإضافة إلى ذلك، شهدت 5.21% من عمليات تحميل الصفحات نموذج قيمة المقياس بين 2,500 و4,000 ملّي ثانية في فترة جمع البيانات الأولى في السجلّ، وشهدت 2.88% من عمليات تحميل الصفحات قيمة أكبر من 4,000 ملّي ثانية في فترة جمع البيانات الأولى في السجلّ.
الشرائح المئوية
قد تحتوي المقاييس أيضًا على سلاسل زمنية من الشرائح المئوية التي يمكن أن تكون مفيدة لإجراء تحليل إضافي.
يتم عرض نقاط البيانات بترتيب تواريخ فترة جمع البيانات التي تعرضها واجهة برمجة التطبيقات أيضًا، وتكون النقطة الأولى هي الفترة الأقدم والنقطة الأخيرة هي أحدث فترة جمع.
{
"percentilesTimeseries": {
"p75s": [1362, 1352, 1344, 1356, 1366, 1377]
},
}
ويمكن أن تعرض هذه الشرائح المئوية قيم مقياس معيّنة بالنسبة المئوية المحدّدة لذلك المقياس. وتستند هذه القيم إلى المجموعة الكاملة من البيانات المتاحة وليس البيانات النهائية المربوطة، لذا لا تتطابق بالضرورة مع الشريحة المئوية المستورَدة التي تستند إلى المدرّج التكراري النهائي المثبّت.
الكسور
يمكن التعبير عن المقاييس في شكل سلاسل زمنية للكسور المصنّفة؛ يصف كل تصنيف تحميل صفحة في علامة نفسها. يتم عرض نقاط البيانات بترتيب تواريخ فترة جمع البيانات التي تعرضها واجهة برمجة التطبيقات أيضًا، وتكون النقطة الأولى هي الفترة الأقدم والنقطة الأخيرة هي أحدث فترة جمع.
مثال:
{
"fractionTimeseries": {
"desktop": {"fractions": [0.3195, 0.2115, 0.1421]},
"phone": {"fractions": [0.6295, 0.7544, 0.8288]},
"tablet": {"fractions": [0.051, 0.0341, 0.029]}
}
}
في هذا المثال، تشير أحدث نقطة بيانات إلى أنّ 14.21% من عمليات تحميل الصفحات كانت من أجهزة الكمبيوتر المكتبي و 82.88% من الهواتف.
أنواع قيم المقاييس
بما أنّ CrUX History API تستخدم أنواع قيم المقاييس نفسها، يمكنك الرجوع إلى المستندات اليومية حول أنواع قيم مقاييس واجهة برمجة التطبيقات CrUX للحصول على مزيد من التفاصيل.
أهلية المقاييس
استنادًا إلى معايير الأهلية، قد يكون المصدر أو عنوان URL مؤهَّلاً فقط لبعض فترات جمع البيانات التي تغطيها واجهة برمجة التطبيقات CrUX History API. في هذه الحالات، ستعرض واجهة برمجة التطبيقات CrUX History API "NaN"
لكثافة histogramTimeseries
وnull
لمدة percentilesTimeseries
لفترات جمع البيانات التي لا تتضمّن بيانات مؤهَّلة. وسبب الاختلاف هو أن كثافات المدرج التكراري تكون دائمًا أرقامًا، بينما يمكن أن تكون القيم المئوية أرقامًا أو سلاسل (تستخدم متغيّرات التصميم التراكمية (CLS) السلاسل، حتى إذا كانت تبدو كأرقام).
على سبيل المثال، إذا لم تتضمّن الفترة الثانية أي بيانات مؤهَّلة، سيظهر ذلك على النحو التالي:
{
"histogramTimeseries": [
{
"start": 0,
"end": 2500,
"densities": [0.9190, "NaN", 0.9194, 0.9195, 0.9183, 0.9187]
},
{
"start": 2500,
"end": 4000,
"densities": [0.0521, "NaN", 0.0518, 0.0518, 0.0526, 0.0527]
},
{
"start": 4000,
"densities": [0.0288, "NaN", 0.0286, 0.0285, 0.0290, 0.0285]
}
],
"percentilesTimeseries": {
"p75s": [1362, null, 1344, 1356, 1366, 1377]
},
}
بالنسبة إلى عناوين URL أو المصادر التي لا تستوفي معايير الأهلية بمرور الوقت، قد تلاحظ عدم توفُّر العديد من الإدخالات.
فترات جمع البيانات
تحتوي واجهة برمجة التطبيقات CrUX History API على عنصر collectionPeriods
يضم مصفوفة من حقلَي firstDate
وendDate
يمثّلان تاريخَي البدء والانتهاء لكل فترة تجميع. على سبيل المثال:
"collectionPeriods": [{
"firstDate": { "year": 2022, "month": 7, "day": 10 },
"lastDate": { "year": 2022, "month": 8, "day": 6 }
}, {
"firstDate": { "year": 2022, "month": 7, "day": 17 },
"lastDate": { "year": 2022, "month": 8, "day": 13 }
}, {
"firstDate": { "year": 2022, "month": 7, "day": 24 },
"lastDate": { "year": 2022, "month": 8, "day": 20 }
}, {
"firstDate": { "year": 2022, "month": 7, "day": 31 },
"lastDate": { "year": 2022, "month": 8, "day": 27 }
}, {
"firstDate": { "year": 2022, "month": 8, "day": 7 },
"lastDate": { "year": 2022, "month": 9, "day": 3 }
}, {
"firstDate": { "year": 2022, "month": 8, "day": 14 },
"lastDate": { "year": 2022, "month": 9, "day": 10 }
}
]
تظهر فترات جمع البيانات هذه بترتيب تصاعدي وتمثّل النطاق الزمني لكل نقطة من نقاط البيانات في الأقسام الأخرى من الردّ.
يتم تحديث History API كل يوم إثنين وهي تتضمن البيانات حتى يوم السبت السابق (وفقًا للتأخُّر العادي الذي يبلغ يومين). ويحتوي على بيانات الأسابيع الـ 25 السابقة، وهي فترة جمع واحدة في الأسبوع.
ويعني ذلك تداخل فترات جمع البيانات، لأنّ كل فترة جمع تحتوي على البيانات المجمّعة للأيام الـ 28 السابقة، وأن فترات جمع البيانات تتم على أساس أسبوعي. وهي تشبه المتوسط المتحرك للبيانات، حيث يتم تضمين ثلاثة أسابيع من البيانات في كل فترة لاحقة، وأسبوع واحد مختلف.
أمثلة على طلبات البحث
يتم إرسال طلبات البحث ككائنات JSON باستخدام طلب POST إلى https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=[YOUR_API_KEY]"
مع تضمين بيانات الطلب ككائن JSON في نص POST.
يُرجى العلم أنّه يتم استخدام queryHistoryRecord
بدلاً من queryRecord
في CrUX API اليومية.
مثال على النص:
{
"origin": "https://example.com",
"formFactor": "PHONE",
"metrics": [
"largest_contentful_paint",
"experimental_time_to_first_byte"
]
}
على سبيل المثال، يمكن طلب ذلك من curl
باستخدام سطر الأوامر التالي (مع استبدال API_KEY
بالمفتاح):
curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=API_KEY' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{"formFactor":"PHONE","origin":"https://www.example.com","metrics":["largest_contentful_paint", "experimental_time_to_first_byte"]}'
تتوفّر البيانات على مستوى الصفحة من خلال واجهة برمجة التطبيقات عن طريق إدخال سمة url
في طلب البحث، بدلاً من origin
:
{
"url": "https://example.com/page",
"formFactor": "PHONE",
"metrics": [
"largest_contentful_paint",
"experimental_time_to_first_byte"
]
}
إذا لم يتم ضبط السمة metrics
، سيتم عرض جميع المقاييس المتاحة:
cumulative_layout_shift
first_contentful_paint
first_input_delay
interaction_to_next_paint
largest_contentful_paint
experimental_time_to_first_byte
navigation_types
round_trip_time
form_factors
(يتم الإبلاغ عنه فقط إذا لم يتم تحديدformFactor
في الطلب)
في حال عدم تقديم قيمة formFactor
، سيتم تجميع القيم على مستوى جميع أشكال الأجهزة.
راجِع دليل استخدام واجهة برمجة تطبيقات سجلّ CrUX للاطّلاع على مزيد من الأمثلة على طلبات البحث.
مسار البيانات
تتم معالجة مجموعة بيانات CrUX من خلال مسار لدمج البيانات وتجميعها وتصفيتها قبل أن تصبح متاحة من خلال واجهة برمجة التطبيقات.
متوسط التحرك
بيانات تقرير تجربة المستخدم على Chrome هي متوسط التحرك خلال 28 يومًا للمقاييس المجمّعة. وهذا يعني أنّ البيانات المقدَّمة في تقرير تجربة المستخدم على Chrome في أي وقت هي في الواقع بيانات مجمّعة خلال آخر 28 يومًا.
تحتوي History API على عدد من فترات جمع البيانات، تمتد كل منها على مدار 28 يومًا. ويعني ذلك تداخل فترات جمع البيانات، لأنّ كل فترة جمع تحتوي على البيانات المجمّعة للأيام الـ 28 السابقة، وأن فترات جمع البيانات تتم على أساس أسبوعي. وهي تشبه المتوسط المتحرك للبيانات، حيث يتم تضمين ثلاثة أسابيع من البيانات في كل فترة لاحقة، وأسبوع واحد مختلف.
التحديثات الأسبوعية
يتم تحديث History API كل يوم اثنين في الساعة 04:00 بالتوقيت العالمي المنسق تقريبًا، وتتضمّن بيانات حتى يوم السبت السابق (وفقًا للفترة المتأخّرة المعتادة التي تبلغ يومَين). ويتضمّن بيانات آخر 25 أسبوعًا (6 أشهر تقريبًا)، مع فترة جمع واحدة في الأسبوع.
لم يتم الاتفاق على مستوى الخدمة لأوقات التحديث. يتم إجراؤه على أساس أفضل جهد كل يوم.
المخطط
هناك نقطة نهاية واحدة لواجهة برمجة التطبيقات CrUX History API تقبل طلبات HTTP POST
. تعرض واجهة برمجة التطبيقات عنصر record
يحتوي على metrics
واحد أو أكثر يتوافق مع بيانات الأداء حول المصدر أو الصفحة المطلوبة.
طلب HTTP
POST https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord
يستخدِم عنوان URL بنية تحويل ترميز gRPC.
نص الطلب
تستخدم CrUX History API نصوص الطلبات نفسها مثل CrUX API، باستثناء عدم توفّر حقل الطلب effectiveConnectionType
.
على سبيل المثال، لطلب قيم "سرعة عرض أكبر محتوى مرئي" على الكمبيوتر المكتبي للصفحة الرئيسية web.dev:
{
"origin": "https://web.dev/",
"formFactor": "DESKTOP",
"metrics": [
"largest_contentful_paint"
]
}
نص الاستجابة
تعرض الطلبات الناجحة ردودًا تحتوي على كائن record
وurlNormalizationDetails
في البنية التالية:
{
"record": {
"key": {
object (Key)
},
"metrics": [
string: {
object (Metric)
}
]
},
"urlNormalizationDetails": {
object (UrlNormalization)
}
}
على سبيل المثال، يمكن أن يكون الردّ على نص الطلب في الطلب السابق كالتالي:
{
"record": {
"key": {
"origin": "https://web.dev"
},
"metrics": {
"largest_contentful_paint": {
"histogramTimeseries": [{
"start": 0, "end": 2500, "densities": [
0.9190, 0.9203, 0.9194, 0.9195, 0.9183, 0.9187, ...
]
}, {
"start": 2500, "end": 4000, "densities": [
0.0521, 0.0513, 0.0518, 0.0518, 0.0526, 0.0527, ...
]
}, {
"start": 4000, "densities": [
0.0288, 0.0282, 0.0286, 0.0285, 0.0290, 0.0285, ...
]
}
],
"percentilesTimeseries": {
"p75s": [
1362, 1352, 1344, 1356, 1366, 1377, ...
]
}
}
},
"collectionPeriods": [{
"firstDate": { "year": 2022, "month": 7, "day": 10 },
"lastDate": { "year": 2022, "month": 8, "day": 6 }
}, {
"firstDate": { "year": 2022, "month": 7, "day": 17 },
"lastDate": { "year": 2022, "month": 8, "day": 13 }
}, {
"firstDate": { "year": 2022, "month": 7, "day": 24 },
"lastDate": { "year": 2022, "month": 8, "day": 20 }
}, {
"firstDate": { "year": 2022, "month": 7, "day": 31 },
"lastDate": { "year": 2022, "month": 8, "day": 27 }
}, {
"firstDate": { "year": 2022, "month": 8, "day": 7 },
"lastDate": { "year": 2022, "month": 9, "day": 3 }
}, {
"firstDate": { "year": 2022, "month": 8, "day": 14 },
"lastDate": { "year": 2022, "month": 9, "day": 10 }
}, {
...
}
]
}
}
المفتاح
تحدِّد Key
جميع السمات التي تعرِّف هذا السجلّ على أنّه فريد.
{
"formFactor": enum (FormFactor),
// Union field url_pattern can be only one of the following:
"origin": string,
"url": string
// End of list of possible types for union field url_pattern.
}
الحقول | |
---|---|
formFactor |
شكل الجهاز هو فئة الجهاز التي استخدمها جميع المستخدمين للوصول إلى الموقع الإلكتروني الخاص بهذا السجلّ. إذا لم يتم تحديد شكل الجهاز، سيتم عرض بيانات مجمّعة تتضمن جميع أشكال الأجهزة. |
حقل الاتحاد url_ . نمط عنوان URL هو عنوان URL الذي ينطبق عليه السجلّ. يمكن أن يكون url_ واحدًا فقط مما يلي: |
|
origin |
يحدد الأصل المصدر الذي من أجله هذا السجلّ. ملاحظة: عند تحديد مصدر، يتم تجميع بيانات عمليات التحميل ضمن هذا المصدر لكل الصفحات في بيانات تجربة المستخدم على مستوى المصدر. |
url |
تحدّد الدالة ملاحظة: عند تحديد |
المقاييس
metric
هو مجموعة من بيانات تجربة المستخدم لمقياس واحد لأداء الويب، مثل سرعة عرض أول محتوى مرئي. يتضمّن هذا المرجع رسمًا بيانيًا لملخّص استخدام Chrome في العالم الفعلي كسلسلة من bins
.
{
"histogramTimeseries": [
{
object (Bin)
}
],
"percentilesTimeseries": {
object (Percentiles)
}
}
أو
"fractionTimeseries": {
object (Fractions)
}
الحقول | |
---|---|
histogramTimeseries[] |
يشير ذلك المصطلح إلى المدرّج التكراري للسلسلة الزمنية لتجارب المستخدم في أحد المقاييس. سيحتوي المدرج التكراري للسلاسل الزمنية على سلة واحدة على الأقل، وسيصبح مجموع كثافات كل السلال ما يصل إلى 1 تقريبًا. سيتم وضع علامة |
percentilesTimeseries |
الشرائح المئوية المفيدة الشائعة للمقياس سيكون نوع القيمة للقيم المئوية هو نفسه أنواع القيم المحددة لسلال المدرج التكراري. سيتم وضع علامة |
fractionTimeseries |
يحتوي هذا العنصر على سلاسل زمنية للكسور المصنّفة، التي تضيف ما يصل إلى 1 تقريبًا لكل إدخال. يتم تقريب الكسور إلى 4 منازل عشرية. يتم التعبير عن الإدخالات غير المتوفّرة على هيئة "NaN"` في جميع الكسور. |
المربع
السمة bin
هي جزء منفصل من البيانات يمتد من البداية إلى النهاية، أو إذا لم يتم تحديد أي نهاية من البداية إلى اللانهاية الموجبة.
يتم تحديد قيم البداية والنهاية للسلة في نوع قيمة المقياس الذي يمثله. على سبيل المثال، يتم قياس سرعة عرض أول محتوى مرئي بالملّي ثانية، ويتم عرضه كعدد صحيح، وبالتالي فإنّ سلال البيانات المترية الخاصة بها ستستخدم int32s لتحديد نوعَي البداية والنهاية. ومع ذلك، يتم قياس متغيّرات التصميم التراكمية بعدد عشري لا وحدات، ويتم عرضه كسلسلة عشرية مرمّزة كسلسلة، وبالتالي تستخدِم سلال المقاييس الخاصة بها سلاسل لنوع القيمة الخاص بها.
{
"start": value,
"end": value,
"densities": [number, number, number...etc.]
}
الحقول | |
---|---|
start |
البداية هي بداية سلة البيانات. |
end |
End هي نهاية سلة البيانات. إذا لم تتم تعبئة الانتهاء، فهذا يعني أن السلة لا تحتوي على نهاية وتكون صالحة من البداية إلى +inf. |
densities |
سلسلة زمنية لنسبة المستخدمين الذين واجهوا قيمة هذه السلة للمقياس المعني. يتم تقريب الكثافة إلى 4 أماكن عشرية. |
الشرائح المئوية
يحتوي Percentiles
على قيم اصطناعية لمقياس معيّن بنسبة مئوية إحصائية معيّنة. وتُستخدم هذه العوامل لتقدير قيمة المقياس وفقًا لتجربة نسبة من المستخدمين من إجمالي عدد المستخدمين.
{
"P75": value
}
الحقول | |
---|---|
p75s |
السلاسل الزمنية للقيم التي شهدت عمليات تحميل الصفحات بنسبة 75% من خلال المقياس المعيّن لهذه القيمة أو أقل منها. |
الكسور
يحتوي Fractions
على سلاسل زمنية للكسور المصنّفة التي تضيف ما يصل إلى 1 تقريبًا، لكل إدخال.
يصف كل تصنيف تحميل الصفحة بطريقة ما، وبالتالي فإن المقاييس ممثلة بهذه الطريقة
على أنها تنتج قيمًا مميزة بدلاً من قيم عددية،
تعبر الكسور عن عدد المرات التي يتم فيها قياس قيمة مميزة معينة.
{
"label_1": { "fractions": array[fraction]},
"label_1": { "fractions": array[fraction]},
...
"label_n": { "fractions": array[fraction]}
}
تشبه قيم الكثافة في سلال المدرّجات التكرارية إلى حد كبير، كل fraction
يمثل رقمًا
0.0 <= value <= 1.0
، ويصل مجموعها إلى 1.0 تقريبًا. عندما يكون المقياس غير متاح
لفترة تجميع معينة، سيتم تطبيق الإدخال المقابل
"NaN" في جميع صفائف الكسور.
الحقول | |
---|---|
p75s |
السلاسل الزمنية للقيم التي شهدت عمليات تحميل الصفحات بنسبة 75% من خلال المقياس المعيّن لهذه القيمة أو أقل منها. |
UrlNormalization
عنصر يمثل إجراءات التسوية المتخذة لتسوية عنوان URL لزيادة فرصة نجاح البحث. هذه هي تغييرات مبرمَجة بسيطة يتم إجراؤها عند البحث عن url_pattern
المقدَّم، ومن الواضح أنّه يتعذّر عليه تنفيذ ذلك. ولا يتم التعامل مع الإجراءات المعقّدة، مثل عمليات إعادة التوجيه التالية.
{
"originalUrl": string,
"normalizedUrl": string
}
الحقول | |
---|---|
originalUrl |
عنوان URL الأصلي المطلوب قبل أي إجراءات تسوية. |
normalizedUrl |
عنوان URL بعد أي إجراءات تسوية. هذا عنوان URL صالح لتجربة مستخدم يمكن البحث عنه بشكل معقول. |
حدود المعدل
تتشارك واجهة برمجة التطبيقات CrUX History API الحد الأقصى نفسه مع CrUX API لعدد 150 طلب بحث في الدقيقة لكل مشروع على Google Cloud لأي من واجهات برمجة التطبيقات التي يتم تقديمها بدون رسوم. ويمكن الاطّلاع على هذا الحدّ واستخدامك الحالي في Google Cloud Console. يجب أن تكون هذه الحصة الكبيرة كافية للغالبية العظمى من حالات الاستخدام، ولا يمكن الدفع مقابل حصة أكبر.