ننصحك بجمع البيانات حول "مؤشرات أداء الويب" الخاصة بموقعك الإلكتروني كخطوة أولى نحو تحسينها. سيجمع التحليل المتكامل بيانات الأداء من كل من البيئات الواقعية والمختبرية. يتطلّب قياس "مؤشرات أداء الويب" إجراء تغييرات بسيطة على الرمز ويمكن تنفيذه باستخدام أدوات مجانية.
قياس "مؤشرات أداء الويب" باستخدام بيانات RUM
تسجِّل بيانات مراقبة المستخدم الفعلي (RUM)، المعروفة أيضًا باسم بيانات الحقول، الأداء الذي يختبره المستخدمون الفعليون للموقع الإلكتروني. تستخدم Google بيانات RUM فقط لتحديد ما إذا كان الموقع الإلكتروني يستوفي الحدود المقترَحة في "مؤشرات أداء الويب الأساسية".
الخطوات الأولى
إذا لم يتوفر لديك إعداد RUM، ستزودك الأدوات التالية سريعًا ببيانات حول الأداء الفعلي لموقعك على الويب. وتستند كل هذه الأدوات إلى مجموعة البيانات الأساسية نفسها (تقرير تجربة مستخدم Chrome)، ولكن لها حالات استخدام مختلفة قليلاً:
- إحصاءات PageSpeed (PSI): توفّر لك إحصاءات PageSpeed تقارير حول الأداء المجمّع على مستوى الصفحة وعلى مستوى المصدر خلال آخر 28 يومًا. بالإضافة إلى ذلك، تقدِّم اقتراحات حول كيفية تحسين الأداء. إذا كنت تبحث عن إجراء واحد للبدء بقياس مؤشرات أداء الويب لموقعك الإلكتروني وتحسينها، ننصحك باستخدام أداة PSI لفحص أداء موقعك الإلكتروني. تتوفّر أداة PSI على الويب وAPI.
- Search Console: تعرض خدمة Search Console بيانات الأداء لكل صفحة على حدة. وهذا يجعلها مناسبة تمامًا لتحديد صفحات معينة تحتاج إلى تحسين. وعلى عكس "إحصاءات PageSpeed"، تتضمن تقارير Search Console بيانات الأداء السابق. لا يمكن استخدام Search Console إلا مع المواقع الإلكترونية التي تملكها والتي تم إثبات ملكيتها.
- لوحة بيانات CrUX: لوحة بيانات CrUX هي لوحة بيانات مُنشأة مسبقًا تعرض بيانات CrUX لمصدر من اختيارك. وهي تستند إلى "مركز البيانات" وتستغرق عملية الإعداد حوالي دقيقة. بالمقارنة مع "إحصاءات PageSpeed" وSearch Console، يتضمن إعداد تقارير لوحة بيانات CrUX المزيد من السمات. على سبيل المثال، يمكن تقسيم البيانات حسب الجهاز ونوع الاتصال.
مع أنّ الأدوات المذكورة أعلاه مناسبة تمامًا "للبدء" في قياس "مؤشرات أداء الويب"، إلا أنّها قد تكون مفيدة في سياقات أخرى أيضًا. وعلى وجه الخصوص، يتوفّر كلّ من CrUX وPSI كواجهة برمجة تطبيقات ويمكن استخدامهما في إنشاء لوحات البيانات وغيرها من التقارير.
جارٍ جمع بيانات RUM
ومع أنّ الأدوات المستندة إلى تقرير تجربة المستخدم على Chrome هي نقطة انطلاق جيدة للتحقّق من أداء "مؤشرات أداء الويب"، ننصحك بشدة باستخدام ذاكرة RUM خاصة بك. يمكن لبيانات RUM التي تجمعها بنفسك تقديم تعليقات فورية أكثر تفصيلاً عن أداء موقعك. وهذا يسهّل تحديد المشاكل واختبار الحلول الممكنة.
يمكنك جمع بيانات RUM باستخدام مزود RUM مخصص، أو عن طريق إعداد أدواتك الخاصة.
يتخصص مزوّدو RUM المتخصصون في جمع بيانات RUM وإعداد تقارير عنها. لاستخدام "مؤشرات أداء الويب الأساسية" مع هذه الخدمات، يمكنك أن تطلب من موفّر RUM أن يفعّل ميزة مراقبة "مؤشرات أداء الويب الأساسية" لموقعك الإلكتروني.
إذا لم يكن لديك مزوّد RUM، قد يكون بإمكانك زيادة إعداد التحليلات الحالي لجمع هذه المقاييس وإعداد تقارير عنها باستخدام مكتبة JavaScript web-vitals. في ما يلي شرح أكثر تفصيلاً لهذه الطريقة.
مكتبة JavaScript لسيرة الويب
إذا كنت تنفّذ إعداد RUM بنفسك في "مؤشرات أداء الويب"، فإنّ أسهل طريقة لجمع قياسات "مؤشرات أداء الويب" هي استخدام مكتبة JavaScript web-vitals. web-vitals هي مكتبة صغيرة نموذجية (حوالي 1 كيلوبايت) توفّر واجهة برمجة تطبيقات ملائمة لجمع كل مقياس من مقاييس "مؤشرات أداء الويب" القابلة للقياس وإعداد التقارير عنها.
لا تعرض واجهات برمجة التطبيقات للأداء المضمّن في المتصفح جميع المقاييس التي تشكّل "مؤشرات أداء الويب"، بل يتم إنشاؤها فوقها. على سبيل المثال، يتم تنفيذ متغيّرات التصميم التراكمية (CLS) باستخدام Layout Instability API. باستخدام web-vitals، لا داعي للقلق بشأن تنفيذ هذه المقاييس بنفسك، إذ يضمن ذلك أيضًا أن البيانات التي تجمعها تطابق المنهجية وأفضل الممارسات لكل مقياس.
لمزيد من المعلومات عن تنفيذ web-vitals، يمكنك مراجعة المستندات ودليل أفضل الممارسات لقياس "مؤشرات أداء الويب" في الحقل.
تجميع البيانات
من الضروري الإبلاغ عن القياسات التي يتم جمعها من خلال "web-vitals". إذا تم قياس هذه البيانات بدون إعداد تقارير عنها، لن تظهر لك أبدًا. تتضمّن مستندات web-vitals أمثلة توضّح كيفية إرسال البيانات إلى نقطة نهاية عامة لواجهة برمجة التطبيقات أو إحصاءات Google أو إدارة العلامات من Google.
إذا كانت لديك أداة مفضلة لإعداد التقارير، ننصحك باستخدامها. وإذا لم يكن الأمر كذلك، تكون خدمة "إحصاءات Google" مجانية ويمكن استخدامها لهذا الغرض.
عند التفكير في الأداة التي يجب استخدامها، من المفيد التفكير في من سيحتاج إلى الوصول إلى البيانات. عادةً ما تحقِّق الأنشطة التجارية أكبر مكاسب في الأداء عندما تكون الشركة بأكملها، بدلاً من قسم واحد، مهتمة بتحسين الأداء. يُرجى الاطّلاع على مقالة إصلاح سرعة الموقع الإلكتروني على عدّة وظائف لمعرفة كيفية الحصول على موافقة من مختلف الأقسام.
تفسير البيانات
عند تحليل بيانات الأداء، من المهم الانتباه إلى أطراف التوزيع. غالبًا ما تكشف بيانات RUM أن الأداء يختلف بشكل كبير - فبعض المستخدمين يتمتعون بتجارب سريعة والبعض الآخر تجارب بطيئة. ومع ذلك، يمكن أن يؤدي استخدام الوسيط لتلخيص البيانات إلى إخفاء هذا السلوك بسهولة.
في ما يخص "مؤشرات أداء الويب"، يستخدم محرّك بحث Google النسبة المئوية للتجارب "الجيدة" بدلاً من إحصاءات مثل الوسطاء أو المتوسطات، لتحديد ما إذا كان الموقع الإلكتروني أو الصفحة يستوفي الحدود التي يُنصح بها. وعلى وجه التحديد، إذا كان الموقع الإلكتروني أو الصفحة يستوفيان حدود "مؤشرات أداء الويب الأساسية"، يجب أن تستوفي% 75 من زيارات الصفحة الحدّ الأدنى "الجيد" لكل مقياس.
قياس "مؤشرات أداء الويب" باستخدام البيانات المعملية
يتم جمع بيانات المختبر، المعروفة أيضًا باسم البيانات الاصطناعية، من بيئة خاضعة للرقابة، بدلاً من مستخدمين فعليين. على عكس بيانات RUM، يمكن جمع البيانات المعملية من بيئات ما قبل الإنتاج، وبالتالي دمجها في سير عمل المطورين وعمليات الدمج المستمرة. من الأمثلة على الأدوات التي تجمع البيانات الاصطناعية Lighthouse وWebPageTest.
الاعتبارات
ستكون هناك دائمًا تناقضات بين بيانات RUM وبيانات المختبر، خاصةً إذا كانت ظروف الشبكة أو نوع الجهاز أو مكان بيئة المختبر تختلف بشكل كبير عن ظروف المستخدمين. مع ذلك، هناك بعض الاعتبارات المهمة التي يجب مراعاتها عند جمع البيانات المعملية حول مقاييس "مؤشرات أداء الويب" تحديدًا:
- متغيّرات التصميم التراكمية (CLS): يمكن أن يكون متغيّرات التصميم التراكمية التي تم قياسها في بيئات الاختبار أقل بشكل مصطنع من متغيّرات التصميم التراكمية (CLS) المرصودة في بيانات RUM. يُعرف متغيّرات التصميم التراكمية (CLS) بأنّه "إجمالي كل نتائج متغيّرات التصميم الفردية لكل متغيّرات تصميم غير متوقّعة تحدث خلال مدة عرض الصفحة بأكملها". ومع ذلك، عادةً ما يختلف عمر الصفحة إلى حد كبير استنادًا إلى ما إذا كان يتم تحميلها من قِبل مستخدم حقيقي أو أداة قياس أداء اصطناعية. فالعديد من أدوات الميزات الاختبارية تحمّل الصفحة فقط، ولا تتفاعل معها. ونتيجةً لذلك، فإنّها تلتقط فقط متغيّرات التصميم التي تحدث أثناء التحميل الأولي للصفحة. وعلى النقيض من ذلك، تسجِّل متغيّرات التصميم التراكمية (CLS) التي تقيسها أدوات RUM متغيّرات التصميم غير المتوقّعة التي تحدث طوال عمر الصفحة بالكامل.
- مهلة الاستجابة الأولى (FID): لا يمكن قياس مهلة الاستجابة الأولى في بيئات الميزات الاختبارية لأنّها تتطلّب تفاعل المستخدم مع الصفحة. ونتيجةً لذلك، يكون إجمالي وقت الحظر (TBT) هو الخادم الوكيل الموصى به للمختبرات من أجل مقياس FID. تقيس ميزة TBT "إجمالي المدة بين "سرعة عرض أول محتوى مرئي" و"وقت التفاعل" الذي يتم خلاله حظر الصفحة من الاستجابة للبيانات التي أدخلها المستخدم. على الرغم من أنّه يتم احتساب FID وTBT بشكل مختلف، إلا أنّ كلاهما انعكاس لسلسلة محادثات رئيسية محظورة أثناء عملية بدء التشغيل. عند حظر سلسلة التعليمات الرئيسية، يتأخر المتصفِّح في الاستجابة لتفاعلات المستخدمين. وتقيس FID التأخير الذي يحدث في المرة الأولى التي يحاول فيها المستخدم التفاعل مع صفحة، إن وجد.
الأدوات
يمكن استخدام هذه الأدوات لجمع قياسات معملية لمؤشرات أداء الويب:
- إضافة Web Vitals من Chrome: تقيس إضافة "مؤشرات أداء الويب" في Chrome مقاييس "مؤشرات أداء الويب الأساسية" (LCP وFID وCLS) لصفحة معيّنة وتنشئ تقريرًا بها. تهدف هذه الأداة إلى تزويد مطوّري البرامج بملاحظات حول الأداء في الوقت الفعلي أثناء إجرائهم تغييرات على الرمز.
- Lighthouse: تقدِّم أداة Lighthouse تقارير عن LCP وCLS وTBT، وتسلّط الضوء أيضًا على التحسينات المحتملة في الأداء. تتوفّر أداة Lighthouse في "أدوات مطوري البرامج في Chrome" كإضافة في Chrome وكحزمة npm. يمكن أيضًا دمج Lighthouse في سير عمل الدمج المستمر من خلال Lighthouse CI.
- WebPageTest: تتضمّن WebPageTest مؤشرات أداء الويب كجزء من تقاريرها العادية. ويكون WebPageTest مفيدًا في جمع المعلومات عن "مؤشرات أداء الويب" وفقًا لشروط معيّنة للجهاز والشبكة.