تجربة قياس عمليات التنقّل البسيطة

Barry Pollard

Yoav Weiss

سعت مبادرة مؤشرات أداء الويب الأساسية منذ إطلاقها إلى قياس تجربة المستخدم الفعلية لموقع إلكتروني، بدلاً من قياس التفاصيل الفنية حول كيفية إنشاء الموقع الإلكتروني أو تحميله. تم إنشاء مقاييس "مؤشرات أداء الويب الأساسية" الثلاثة كمقاييس تركّز على المستخدم، وهي تطوّر في المقاييس الفنية الحالية، مثل DOMContentLoaded أو load التي تقيس التوقيتات التي غالبًا ما تكون غير مرتبطة بكيفية تقدير المستخدمين لأداء الصفحة. لهذا السبب، يجب ألا تؤثر التكنولوجيا المستخدَمة لإنشاء الموقع الإلكتروني على النتيجة التي يوفّرها الموقع الإلكتروني.

يكون الواقع دائمًا أصعب قليلاً من المثالية، ولم تكن البنية الشائعة لتطبيق الصفحة الواحدة متوافقة بشكل كامل مع مقاييس "مؤشرات أداء الويب الأساسية". وبدلاً من تحميل صفحات ويب فردية ومميزة أثناء تنقل المستخدم في الموقع، تستخدم تطبيقات الويب هذه ما يُعرف باسم "عمليات التنقل البسيطة"، حيث يتم تغيير محتوى الصفحة باستخدام JavaScript بدلاً من ذلك. في هذه التطبيقات، يتم استيعاب بنية صفحة الويب التقليدية من خلال تغيير عنوان URL ودفع عناوين URL السابقة في سجل المتصفح للسماح لأزرار الرجوع وللأمام بالعمل كما يتوقع المستخدم.

ويستخدم العديد من أطر عمل JavaScript هذا النموذج، ولكن بشكلٍ مختلف لكل منها. ولأنّ هذا الأمر يختلف عمّا يفهمه المتصفّح عادةً على أنّه "صفحة"، كان من الصعب دائمًا قياس هذا الأمر: أين يجب رسم الخط بين التفاعل على الصفحة الحالية أم اعتبارها صفحة جديدة؟

يدرس فريق Chrome هذا التحدي منذ فترة، ويسعى إلى توحيد تعريف "التنقل البسيط" وكيفية قياس مؤشرات "Core Web Vitals" وفقًا لذلك، بالطريقة نفسها التي يتم بها قياس المواقع الإلكترونية التي يتم تنفيذها في البنية التقليدية متعددة الصفحات (MPA). وفي حين لا يزال الفريق في مراحله الأولى، فإنّه مستعد الآن لإتاحة ما تم تنفيذه على نطاق أوسع للمواقع الإلكترونية التي يمكنها تجربتها. سيتيح ذلك للمواقع الإلكترونية تقديم ملاحظات وآراء بشأن النهج حتى الآن.

ما المقصود بالتنقل البسيط؟

لقد توصلنا إلى التعريف التالي لالتنقل البسيط:

• يبدأ المستخدم عملية التنقّل.
• وينتج عن عملية التنقّل تغيير مرئي للمستخدم في عنوان URL وتغيير السجلّ.
• ينتج عن التنقّل تغيير في نموذج العناصر في المستند (DOM).

بالنسبة إلى بعض المواقع الإلكترونية، قد تؤدي هذه المؤشرات إلى نتائج موجبة خاطئة (بأنّ المستخدمين لن يفكروا في حدوث عملية "انتقال" بالفعل) أو نتائج سلبية خاطئة (حيث يعتبر المستخدم أنّ عملية "التنقل" قد حدثت على الرغم من عدم استيفاء هذه المعايير). نحن نرحّب بالملاحظات والآراء في مستودع مواصفات التنقّل الآمن بشأن الإرشادات.

كيف ينفِّذ Chrome التنقلات البسيطة؟

بعد تفعيل إرشادات التنقّل الآمن (مزيد من المعلومات حول هذا الموضوع في القسم التالي)، سيغيّر Chrome الطريقة التي يُعدّ بها بعض مقاييس الأداء:

• سيتم إطلاق حدث soft-navigation PerformanceTiming بعد رصد كل عملية تنقّل مرنة.
• ستوفّر واجهة برمجة تطبيقات الأداء إمكانية الوصول إلى إدخال التوقيت soft-navigation على النحو المنبعث من حدث PerformanceTiming soft-navigation.
• وستتم إعادة ضبط مقاييس سرعة عرض أوّل محتوى (FP) وسرعة عرض أول محتوى مرئي (FCP) وسرعة عرض أكبر محتوى مرئي (LCP)، وستتم إعادة إطلاقها عند التكرار المناسب لها. (ملاحظة: لا يتم تنفيذ FP وFCP).
• ستتم إضافة سمة navigationId إلى كلّ من توقيتات الأداء (first-paint وfirst-contentful-paint وlargest-contentful-paint وfirst-input-delay وevent وlayout-shift) بما يتوافق مع إدخال التنقّل الذي كان الحدث مرتبطًا به، ما يتيح احتساب متغيّرات التصميم التراكمية (CLS) ومدى استجابة الصفحة لتفاعلات المستخدم (INP).

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

ما هي المشاكل التي قد تنتج عن تفعيل ميزة "التنقل البسيط" في Chrome؟

وفي ما يلي بعض التغييرات التي يجب أن يضعها مالكو المواقع الإلكترونية في الاعتبار بعد تفعيل هذه الميزة:

• وقد يتم إعادة إطلاق أحداث FP وFCP وLCP الإضافية في عمليات التنقل السهلة. سيتجاهل تقرير تجربة المستخدم على Chrome (CrUX) هذه القيم الإضافية، ولكن قد يؤثر ذلك في أي عملية مراقبة لقياس المستخدم (RUM) على موقعك الإلكتروني. يُرجى الرجوع إلى مزود RUM إذا كانت لديك أي استفسارات بشأن تأثير ذلك في القياسات. راجِع القسم الخاص بقياس "مؤشرات أداء الويب الأساسية" لعمليات التنقّل البسيطة.
• قد تحتاج إلى تضمين سمة navigationID الجديدة (والاختيارية) في إدخالات الأداء في رمز تطبيقك باستخدام هذه الإدخالات.
• لن يتوفّر هذا الوضع الجديد إلا في المتصفّحات المستندة إلى Chromium. وعلى الرغم من توفُّر عدد كبير من المقاييس الجديدة فقط في المتصفِّحات المستنِدة إلى Chromium، تتوفّر بعض المقاييس (FCP وLCP) في المتصفّحات الأخرى، وقد لا يكون بعض المستخدمين قد تمت الترقية إلى أحدث إصدار من المتصفِّحات المستنِدة إلى Chromium. لذا، يُرجى الانتباه إلى أنّ بعض المستخدمين قد لا يبلّغون عن مقاييس التنقّل البسيط.
• كميزة تجريبية جديدة لا يتم تفعيلها تلقائيًا، يجب أن تختبر المواقع الإلكترونية هذه الميزة لضمان عدم حدوث أي آثار جانبية أخرى غير مقصودة.

لمزيد من المعلومات حول طريقة قياس المقاييس الخاصة بعمليات التنقّل السهلة، يُرجى الاطّلاع على قسم "قياس مؤشرات أداء الويب الأساسية لكل عملية تنقل آمن".

كيف يمكنني تفعيل "التنقل البسيط" في Chrome؟

لا تكون ميزة التنقُّل البسيط مُفعّلة تلقائيًا في متصفِّح Chrome، ولكنها متاحة للتجربة من خلال تفعيل هذه الميزة صراحةً.

بالنسبة إلى مطوّري البرامج، يمكن تفعيل هذا الخيار من خلال تفعيل علامة الميزات التجريبية للنظام الأساسي للويب في chrome://flags/#enable-experimental-web-platform-features أو باستخدام وسيطة سطر الأوامر --enable-experimental-web-platform-features عند تشغيل Chrome.

كيف يمكنني قياس عمليات التنقّل البسيطة؟

بعد تفعيل تجربة التنقّل الآمن، ستُعِدّ المقاييس تقارير باستخدام واجهة برمجة تطبيقات PerformanceObserver كالمعتاد. ومع ذلك، هناك بعض الاعتبارات الإضافية التي يجب أخذها في الاعتبار لهذه المقاييس.

الإبلاغ عن عمليات التنقّل البسيطة

يمكنك استخدام PerformanceObserver لمراقبة عمليات التنقّل السريعة. في ما يلي مثال لمقتطف رمز يُسجِّل إدخالات التنقّل الآمن في وحدة التحكّم، بما في ذلك عمليات التنقّل البسيطة السابقة في هذه الصفحة باستخدام الخيار buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

ويمكن استخدام هذه الميزة لإنهاء مقاييس الصفحة الكاملة خلال عملية التنقّل السابقة.

يمكنك الإبلاغ عن المقاييس مقابل عنوان URL المناسب.

بما أنّه لا يمكن الاطّلاع على عمليات التنقّل البسيطة إلا بعد حدوثها، يجب وضع اللمسات الأخيرة على بعض المقاييس عند انتهاء هذا الحدث، ثم إعداد تقارير عنها لعنوان URL السابق، لأنّ عنوان URL الحالي سيعكس الآن عنوان URL المعدَّل للصفحة الجديدة.

ويمكن استخدام السمة navigationId لـ PerformanceEntry المناسب لربط الحدث بعنوان URL الصحيح. يمكن البحث عن ذلك باستخدام PerformanceEntry API:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

يجب استخدام pageUrl هذا لإعداد التقارير عن المقاييس مقابل عنوان URL الصحيح، بدلاً من عنوان URL الحالي الذي قد يكون تم استخدامه في الماضي.

الحصول على startTime من التنقلات السهلة

يمكن الحصول على وقت بدء التنقّل بطريقة مشابهة:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime هو وقت التفاعل الأولي (على سبيل المثال، النقر على زر) الذي بدأ التنقّل السهل.

يتم تسجيل جميع توقيتات الأداء، بما في ذلك توقيتات التنقلات السهلة، كوقت من "الحد الأقصى" الأولي وقت التنقل في الصفحة. وبالتالي، يجب أن يكون وقت بدء التنقّل البسيط مطلوبًا لتحديد أوقات مقاييس تحميل التنقّل الآمن (على سبيل المثال، LCP)، بالنسبة إلى وقت التنقّل السهل هذا بدلاً من ذلك.

قياس "مؤشرات أداء الويب الأساسية" لكل عملية تنقّل سهلة

لتضمين إدخالات مقياس التنقّل البسيط، عليك تضمين includeSoftNavigationObservations: true في استدعاء observe لمراقب الأداء.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

يجب إضافة علامة includeSoftNavigationObservations إضافية إلى طريقة observe بالإضافة إلى تفعيل ميزة التنقّل الآمن في Chrome. تهدف عملية الموافقة الصريحة هذه على مستوى "مراقب الأداء" إلى ضمان عدم دهشة مراقبي الأداء الحاليين بهذه الإدخالات الإضافية، إذ يجب أخذ بعض الاعتبارات الإضافية في الاعتبار عند محاولة قياس "مؤشرات أداء الويب الأساسية" لعمليات التنقل السهلة.

سيتم عرض التوقيتات بالنسبة إلى التوقيت "الصعب" الأصلي. وقت بدء التنقل. بالتالي لاحتساب سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) لانتقال سريع مثلاً، ستحتاج إلى تحديد توقيت سرعة عرض أكبر جزء من المحتوى على الصفحة وطرح وقت بدء التنقّل البسيط المناسب كما هو مفصّل سابقًا للحصول على توقيت مرتبط بالتنقل السهل. على سبيل المثال، بالنسبة إلى سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP):

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

عادةً ما يتم قياس بعض المقاييس طوال عمر الصفحة: على سبيل المثال، يمكن أن يتغيّر مقياس LCP إلى أن يحدث تفاعل. يمكن تعديل متغيّرات التصميم التراكمية (CLS) و"مدى استجابة الصفحة لتفاعلات المستخدم" (INP) إلى أن يتم الانتقال إلى صفحة أخرى. وبالتالي فإن كل عملية "تنقل" (بما في ذلك شريط التنقّل الأصلي) قد تحتاج إلى إنهاء مقاييس الصفحة السابقة عند حدوث كل انتقال بسيط جديد. وهذا يعني أن الحروف الأولية مقاييس التنقل في وقت سابق من هذا المعتاد.

وبالمثل، عند البدء في قياس مقاييس عملية التنقّل الإلكترونية الجديدة لهذه المقاييس طويلة الأمد، يجب "إعادة ضبط" المقاييس. أو "تمت إعادة إعداده" وتتم معالجتها كمقاييس جديدة، بدون ذاكرة للقيم التي تم ضبطها في "الصفحات" السابقة.

كيف يجب التعامل مع المحتوى الذي يظل كما هو بين عمليات التنقل؟

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

على سبيل المثال، خذ صفحة تتضمن صورة بانر كبيرة تمثل عنصر LCP، ولكن النص الموجود أسفلها يتغيّر مع كل تنقل سلس. عند التحميل الأوّلي للصفحة، يتم وضع علامة على صورة البانر باعتبارها عنصر LCP ويتم تحديد توقيت سرعة عرض أكبر جزء من المحتوى على الصفحة. وفي عمليات التنقّل اللاحقة، سيكون النص الظاهر أسفله هو أكبر عنصر تم تلوينه بعد التنقّل السلس وسيكون هو عنصر LCP الجديد. ومع ذلك، إذا تم تحميل صفحة جديدة تحتوي على رابط لصفحة معيّنة في عنوان URL للتنقّل السهل، ستكون صورة البانر عبارة عن رسم جديد، وبالتالي ستكون مؤهَّلة ليتم اعتبارها عنصر سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP).

يبيّن هذا المثال أنّ عنصر LCP للتنقّل البسيط يمكن الإبلاغ عنه بشكل مختلف استنادًا إلى طريقة تحميل الصفحة، تمامًا كما يمكن أن يؤدي تحميل صفحة تحتوي على رابط ارتساء إلى أسفل الصفحة إلى ظهور عنصر LCP مختلف.

كيف يمكن قياس TTFB؟

وقت تحميل أول بايت (TTFB) لتحميل الصفحة التقليدي هو الوقت الذي يتم فيه عرض أول وحدات بايت من الطلب الأصلي.

بالنسبة للتنقل السلس، هذا سؤال أكثر تعقيدًا. هل علينا قياس الطلب الأول الذي تم تقديمه للصفحة الجديدة؟ ماذا لو كان المحتوى بأكمله متوفرًا في التطبيق ولم تتوفّر أي طلبات إضافية؟ ماذا لو تم إجراء هذا الطلب مسبقًا من خلال جلب مسبق؟ ماذا لو كان الطلب غير مرتبط بالتنقل الآمن من منظور المستخدم (على سبيل المثال، طلب إحصاءات)؟

هناك طريقة أبسط وهي الإبلاغ عن 0TFB أثناء عمليات التنقل السهلة، بالطريقة نفسها التي ننصح بها لاستعادة ميزة "التخزين المؤقت للصفحات". هذه هي الطريقة التي تستخدمها مكتبة web-vitals للتنقلات السريعة.

في المستقبل، قد نوفّر طرقًا أكثر دقة لمعرفة الطلب الذي يمثّل "طلب التنقّل" في ميزة "التنقُّل البسيط". سيكون بإمكانها الحصول على قياسات أكثر دقة لـ TTFB. لكن هذا ليس جزءًا من التجربة الحالية.

كيف يمكن قياس كل من الإصدار القديم والجديد؟

خلال هذه التجربة، ننصحك بمواصلة قياس "مؤشرات أداء الويب الأساسية" بالطريقة الحالية، بناءً على القيم "الصعبة". عمليات التنقّل في الصفحات لتتطابق مع البيانات التي ستقيسها CrUX وتُبلغ عنها كمجموعة بيانات رسمية لمبادرة "مؤشرات أداء الويب الأساسية".

ويجب قياس هذه العمليات أيضًا للسماح لك بمعرفة كيفية قياسها في المستقبل، ولمنحك الفرصة لتقديم ملاحظات إلى فريق Chrome حول آلية عمل هذا التنفيذ عمليًا. سيساعدك هذا أنت وفريق Chrome في تطوير واجهة برمجة التطبيقات من الآن فصاعدًا.

لقياس كليهما، يجب أن تكون على دراية بالأحداث الجديدة التي قد يتم إصدارها أثناء وضع "التنقل البسيط" (على سبيل المثال، أحداث "سرعة عرض أكبر محتوى مرئي" (FCP) متعددة وأحداث إضافية لسرعة عرض أكبر محتوى مرئي (LCP)) والتعامل معها بشكل مناسب من خلال الانتهاء من هذه المقاييس في الوقت المناسب، مع تجاهل الأحداث المستقبلية التي تنطبق فقط على عمليات التنقّل السهلة.

استخدام مكتبة web-vitals لقياس مؤشرات "Core Web Vitals" في عمليات التنقّل السهلة الاستخدام

وتتمثل أسهل طريقة لمراعاة جميع الفروق الدقيقة في استخدام مكتبة web-vitals JavaScript التي تتوافق مع إصدار تجريبي بسيط من التنقلات في soft-navs branch منفصلة (متوفّرة أيضًا على npm وunpkg). يمكن قياس ذلك بالطريقة التالية (مع استبدال doTraditionalProcessing وdoSoftNavProcessing حسب الحاجة):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

تأكَّد من تسجيل المقاييس في عنوان URL الصحيح كما هو موضّح سابقًا.

تعرض مكتبة web-vitals المقاييس التالية لعمليات التنقّل البسيطة:

هل ستصبح هذه التغييرات جزءًا من قياسات "مؤشرات أداء الويب الأساسية"؟

تجربة التنقّل الآمن هذه هي بالضبط تجربة. لذلك، نريد تقييم المؤشرات ومعرفة ما إذا كانت تعكس تجربة المستخدم بدقة أكبر قبل أن نتّخذ أي قرار بشأن دمج هذه المؤشرات في مبادرة "مؤشرات أداء الويب الأساسية". نحن متحمسون جدًا لإمكانية إجراء هذه التجربة، ولكن لا يمكننا تقديم ضمانات بشأن ما إذا كان سيحل محل القياسات الحالية أو موعده.

نحن نقدّر جهود مطوّري البرامج على الويب الملاحظات على التجربة، والاستدلالات المستخدمة، وما إذا كنت تشعر أنها تعكس التجربة بدقة أكبر. إنّ مستودع GitHub للتنقّل بسلاسة هو أفضل مكان لتقديم هذه الملاحظات، على الرغم من أنّ الأخطاء الفردية المتعلّقة بتنفيذ Chrome والتي يجب إبرازها في أداة تتبُّع مشاكل Chrome.

كيف سيتم الإبلاغ عن عمليات التنقّل البسيطة في تقرير تجربة المستخدم على Chrome؟

ولم يتقرّر أيضًا سوى الطريقة التي سيتم بها تسجيل بيانات الانتقالات البسيطة في تقرير تجربة المستخدم على Chrome، وما إذا كانت هذه التجربة ناجحة. وليس من الضروري أن تتم معاملتهم بالطريقة نفسها التي يعامل بها المشاركون "الأولويات" الحالية. والتنقل.

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

لذلك، قد نقرر الإبلاغ عن عمليات التنقل السهلة هذه بشكل منفصل في تقرير تجربة المستخدم على Chrome أو قد نقيّمها عند احتساب "مؤشرات أداء الويب الأساسية" لصفحة معيّنة أو مجموعة معيّنة من الصفحات. وقد نتمكن أيضًا من استثناء التنقل الجزئي للتحميل بشكل كامل، مع تطوّر الموجِّه.

وسيركّز الفريق على التنفيذ التقني والإرشادي، ما يتيح لنا الحكم على نجاح هذه التجربة، وبالتالي لم يتم اتخاذ قرار بشأن هذه الجوانب.

ملاحظات

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

• إرشادات التنقّل البسيط وتوحيد المقاييس
• مشاكل تنفيذ Chrome لهذه الإرشادات
• يمكنك الاطّلاع على الملاحظات العامة حول مؤشرات أداء الويب على الرابط web-vitals-feedback@googlegrouops.com.

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

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

الخاتمة

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

شكر وتقدير

صورة مصغّرة بواسطة جوردان مدريد على إلغاء البداية