ما الذي يجب قياسه لتحسين الأداء؟

استراتيجيات لقياس الأداء في كل مرحلة من مسار الإحالة الناجحة للشراء.

مارتن شيرل

Twitter GitHub

تكون الخطوات المختلفة لمسار الشراء عرضة لمشاكل الأداء بطرق مختلفة، وبالتالي تحتاج إلى قياسات وتحسينات مختلفة:

مسار الإحالة الناجحة:

سنتناول في هذا الدليل كيفية قياس الخطوات المختلفة. لذلك ننصحك بالنظر إلى المعمل بالإضافة إلى البيانات الميدانية.

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

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

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

الاستكشاف

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

من منظور المستخدم، تكون أهم المقاييس هي:

• سرعة عرض المحتوى على الصفحة (FCP): الوقت الذي ينظر فيه المستخدم في شاشة فارغة يحدث هذا عندما يرتد معظم المستخدمين، لأنهم لا يرون التقدم.
• سرعة عرض أوّل محتوى مفيد على الصفحة (FMP): عندما يبدأ المستخدم في الاطّلاع على المحتوى الرئيسي الذي جذب المستخدم من أجله وغالبًا ما تكون هذه الصورة الرئيسية، ولكن بالنسبة إلى الصفحة المقصودة، قد تكون عبارة عن عبارة تحث المستخدم على اتخاذ إجراء مثل زر شراء، لأنّ المستخدم قد وصل بنيّة واضحة (من خلال حملة إعلانية موجَّهة مثلاً).
• مهلة الاستجابة لأوّل إدخال (FID): هو الوقت الذي يحتاجه الموقع الإلكتروني للتفاعل مع البيانات الأولى التي أدخلها المستخدم. وقد يؤدي الاستخدام المفرط لرموز JavaScript ومشكلات تحميل مواد العرض الأخرى إلى حظر ذلك، مما يؤدي إلى إخفاق النقرات أو النقرات وإدخالات خاطئة ومغادرة الصفحة.

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

التفاعل والإحالة الناجحة

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

في هذه المرحلة، من المهم أن يكون لديك تنقلات وتفاعلات سريعة ومتجاوبة. ولسوء الحظ، ليس من السهل قياس التدفق الكامل لأحداث التنقل والتفاعل في الميدان، حيث يسلك كل مستخدم مسارات مختلفة عبر الصفحة. لذلك ننصح بقياس الوقت اللازم لتحقيق الأهداف الفرعية للإحالات الناجحة أو الأهداف الفرعية للإحالات الناجحة ("Time-to-Action") عن طريق البرمجة النصية وقياس التدفق في الاختبار المعملي، وذلك لمقارنة الأداء مع مرور الوقت أو مع المنافسين.

هناك طريقتان مناسبتان لإجراء ذلك:

WebPageTest

يوفّر WebPageTest حلاً مرنًا للغاية للنصوص البرمجية. الفكرة الأساسية هي:

• اطلب من WebPageTest التنقل بين صفحات التدفق باستخدام الأمر navigate.
• إذا لزم الأمر، يمكنك النقر على الأزرار من خلال الأوامر clickAndWait وملء الحقول النصية من خلال setValue. وفي اختبار التطبيقات ذات الصفحة الواحدة، استخدِم الأوامر clickAndWait بدلاً من الأوامر navigate لجميع الخطوات التي تلي الخطوة الأولى، لأنّ navigate ستُجري عملية تحميل كاملة بدلاً من تحميل الصفحة الافتراضية البسيط.
• احرص على دمج الخطوات المختلفة للتدفق في التحليل من خلال combineSteps لإنتاج تقرير نتائج إجمالي واحد للتدفق الكامل.

يمكن أن يظهر هذا النص البرمجي على النحو التالي:

combineSteps
navigate    https://www.store.google.com/landingpage
navigate    https://www.store.google.com/productpage
clickAndWait    innerText=Buy Now
navigate    https://www.store.google.com/basket
navigate    https://www.store.google.com/checkout

عند استخدام نص كهذا، يمكنك قياس الأداء ومقارنته بسهولة مع مرور الوقت. ويمكن إجراء ذلك آليًا من خلال WebPageTest API.

محرك العرائس

هناك خيار رائع آخر لاختبار النصوص البرمجية، وهو عبر Chrome بلا واجهة مستخدم رسومية، والذي يمكن التحكم فيه من خلال Node API Puppeteer. والفكرة العامة هي بدء تشغيل المتصفح من خلال Puppeteer، والانتقال إلى الصفحة المقصودة من خلال وظيفة goto، وإدخال JavaScript لملء الحقول، أو النقر على الأزرار والمتابعة من خلال مسار الإحالة الناجحة من خلال المزيد من الانتقال إلى الطلبات حسب الحاجة.

وكمقياس، يمكن قياس مدة التدفق مباشرةً، ولكن يمكنك أيضًا جمع قيم FCP أو FMP أو TTI للتحميلات الفردية للتدفق. يقدّم خيار اختبار أداء الموقع الإلكتروني باستخدام Puppeteer نظرة عامة حول كيفية الحصول على مقاييس الأداء من خلال Puppeteer. يمكن أن يبدو نص برمجي للعقدة مبسطًا للغاية على النحو التالي:

const puppeteer = require('puppeteer');
(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  const start = performance.now();
  await page.goto('https://www.store.google.com/landingpage');
  await page.goto('https://www.store.google.com/productpage');
  // click the buy button, which triggers overlay basket
  await page.click('#buy_btn');
  // wait until basket overlay is shown
  await page.waitFor('#close_btn');
  await page.goto('https://www.store.google.com/basket');
  await page.goto('https://www.store.google.com/checkout');
  console.log('Flow took ' + parseInt((performance.now() - start)/1000) + ' seconds');
  await browser.close();
})();

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

إعادة التفاعل

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

يوفّر Webpagetest خيارات لاختبار التحميل الأول وتكرار التحميل أيضًا.

ولتكوين شعور أفضل بأداء الزيارات المتكررة في الحقل، استخدِم حزمة الإحصاءات التي اخترتها لتقسيم مقاييس الأداء حسب نوع المستخدم. وفي ما يلي مثال على هذا التقرير في "إحصاءات Google":

يمكن استخدام تقرير مخصّص في "إحصاءات Google" للإبلاغ عن مقاييس السرعة للمستخدمين الجدد والمكرّري الزيارة.

سيمنحك تقرير كهذا التقرير أوقات تحميل الصفحات للمستخدمين الجدد والمكرّري الزيارة أيضًا.

ملخّص

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