سير عمل "مؤشرات أداء الويب الأساسية" باستخدام أدوات Google

يمكنك الجمع بين أدوات Google لتدقيق موقعك الإلكتروني وتحسينه ومراقبته بفعالية.

تاريخ النشر: 28 مايو 2020

مؤشرات أداء الويب الأساسية هي مجموعة من المقاييس التي تقيّم تجربة المستخدم استنادًا إلى معايير مثل أداء التحميل والاستجابة لإدخال المستخدم وثبات التصميم.

سنتناول في هذا الدليل سير عمل لتحسين "مؤشرات Core Web Vitals" لموقعك الإلكتروني، ولكن ستعتمد نقطة بداية سير العمل على ما إذا كنت تجمع بيانات ميدانية خاصة بك. قد يعتمد المكان الذي ينتهي فيه على الأدوات التي ستجدها مفيدة من Google في تشخيص مشاكل تجربة المستخدم وحلّها.

أفضل طريقة لقياس "مؤشرات أداء الويب الأساسية" هي في بيئة فعلية

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

تصف

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

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

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

تقيس Google مؤشرات Core Web Vitals من خلال تقرير تجربة المستخدم في Chrome (أو CrUX). هذه مجموعة بيانات عامة تم جمعها من مستخدمي Chrome الفعليين. وهي الأساس الذي تستند إليه العديد من أدوات Google وأدوات الجهات الخارجية التي تقدّم تقارير عن مؤشرات Core Web Vitals الخاصة بالموقع الإلكتروني.

ومع ذلك، هناك قيود على CrUX. يمكن أن يخبرك غالبًا متى تحدث مشكلة، ولكن غالبًا ما تكون البيانات غير كافية لإخبارك لماذا تحدث.

جمع بياناتك الميدانية الخاصة إذا أمكن

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

من المؤكّد أنّ الحلول المدفوعة ستقيس مؤشرات Core Web Vitals (ومقاييس الأداء الأخرى)، وستوفّر عادةً مجموعة متنوّعة من الأدوات للتعمّق في البيانات الناتجة. في المؤسسات الكبيرة التي تتوفّر لديها موارد كبيرة، قد تكون هذه هي الطريقة المفضّلة.

ومع ذلك، قد لا تكون جزءًا من مؤسسة كبيرة، أو حتى مؤسسة لديها الوسائل اللازمة لشراء حلّ تابع لجهة خارجية. في هذه الحالات، ستساعدك مكتبة web-vitals من Google في جمع جميع مقاييس Web Vitals. ومع ذلك، ستكون أنت المسؤول عن طريقة تسجيل هذه البيانات وتخزينها وتحليلها.

إذا كنت تستخدم "إحصاءات Google" حاليًا، ولكنّك لم تبدأ في جمع بيانات الحقول الخاصة بك، قد تكون لديك فرصة لاستخدام مكتبة web-vitals من أجل إرسال بيانات Web Vitals التي تم جمعها في الحقل إلى "إحصاءات Google" واستخدام عمليات التصدير في BigQuery من "إحصاءات Google‏ 4" لإعداد تقارير عن البيانات.

التعرّف على أدوات Google

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

تقرير تجربة المستخدم على Chrome (CrUX)

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

يتوفّر "تقرير تجربة المستخدم على Chrome" كمجموعة بيانات BigQuery شهرية على مستوى المصدر، أو كواجهة برمجة تطبيقات يومية على مستوى عنوان URL أو المصدر، شرط أن يتضمّن عنوان URL أو المصدر عددًا كافيًا من العيّنات في مجموعة بيانات "تقرير تجربة المستخدم على Chrome". تتوفّر بيانات CrUX من خلال أدوات CrUX المختلفة، سواء للوصول آليًا أو باستخدام أدوات مرئية.

حالات استخدام CrUX

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

يمكنك استخدام CrUX مباشرةً أو باستخدام أداة أخرى (بما في ذلك الأدوات المذكورة أدناه). يُعدّ استخدام مجموعة بيانات CrUX مباشرةً، سواء باستخدام BigQuery أو واجهة برمجة التطبيقات، مفيدًا لعرض البيانات التي لا تظهر في أدوات أخرى، على سبيل المثال، لا تتوفّر غالبًا البيانات على مستوى البلد في أدوات أخرى، أو لعرض المقاييس الإضافية في CrUX التي لا تظهر غالبًا في أدوات أخرى.

الحالات التي لا يُستخدَم فيها تقرير CrUX

لا يمثّل CrUX سوى مستخدمي Chrome، وحتى في هذه الحالة، لا يمثّل سوى مجموعة فرعية من مستخدمي Chrome. يمكن أن يتضمّن حلّ كامل لمراقبة تجربة المستخدم الحقيقية المزيد من التجارب على Chrome والمتصفّحات الأخرى التي تتوافق مع مقاييس Web Vitals.

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

بما أنّ البيانات التي يوفّرها تقرير "تجربة المستخدم على Chrome" هي متوسط متحرك على مدار آخر 28 يومًا، فهي ليست أداة مثالية أثناء التطوير، إذ سيستغرق ظهور التحسينات في مجموعة بيانات "تجربة المستخدم على Chrome" وقتًا طويلاً.

أخيرًا، بما أنّ CrUX هي مجموعة بيانات عامة، فإنّها تقتصر على مقدار المعلومات التي يمكن إتاحتها وطريقة الاستعلام عن هذه البيانات. يتيح لك تسجيل بيانات تجربة المستخدم الحقيقية جمع المزيد من التفاصيل (مثل عنصر أكبر محتوى مرئي)، وتقسيم البيانات بشكل أكبر لتحديد المشاكل. هل يحقّق المستخدمون الذين سجّلوا الدخول مؤشرات Core Web Vitals أفضل أو أسوأ من المستخدمين الذين لم يسجّلوا الدخول؟ هل يظهر عنصر LCP معيّن للمستخدمين الذين يعانون من بطء في مقياس LCP؟ ما هي التفاعلات التي تتسبّب في ارتفاع قيم FID وINP؟

‫PageSpeed Insights (PSI)

PSI هي أداة تعرض بيانات الاستخدام الفعلي من CrUX وبيانات المختبر من Lighthouse لصفحة معيّنة. يمكنك الاطّلاع على هذه الأقسام الفردية لمعرفة المزيد من التفاصيل.

حالات استخدام "مؤشر سرعة الموقع"

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

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

بما أنّ Lighthouse يتم تشغيله من الخادم، يمكنه إنشاء خط أساس أكثر اتساقًا من تشغيل Lighthouse من "أدوات المطوّرين".

الحالات التي لا يُستخدَم فيها PSI

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

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

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

أخيرًا، عندما تتوفّر بيانات على مستوى الصفحة في CrUX، ولكنها تختلف عن بيانات المختبر في Lighthouse، قد تكون الاقتراحات من Lighthouse ذات قيمة محدودة. يمكن أن يحدث ذلك بشكل خاص في مشاكل CLS بعد التحميل، وفي مؤشرات أداء الويب الأساسية المتعلقة بالتفاعل (FID وINP) التي تكون فيها عمليات التدقيق المستندة إلى المختبر أقل فائدة.

Search Console

تقيس Search Console عدد الزيارات الواردة من البحث إلى موقعك الإلكتروني ومستوى أدائه، بما في ذلك مؤشرات Core Web Vitals. وهي متاحة فقط لمالكي المواقع الإلكترونية الذين أكّدوا ملكيتهم للموقع.

من الميزات القيّمة في Search Console أنّها تجمع الصفحات المتشابهة (مثل الصفحات التي تستخدم النموذج نفسه) في تقييم مجموعة واحدة. تتضمّن Search Console أيضًا تقريرًا عن "مؤشرات أداء الويب الأساسية" استنادًا إلى بيانات الاستخدام الفعلي من CrUX.

الحالات التي يجب فيها استخدام Search Console

تُعدّ Search Console مناسبة للمطوّرين وغير المطوّرين لتقييم أداء البحث والصفحات بطرق لا تتيحها أدوات Google الأخرى. يقدّم هذا التقرير بيانات CrUX ويصنّف الصفحات حسب التشابه، ما يوفّر إحصاءات جديدة حول تأثير تحسينات الأداء في فئات الصفحات بأكملها.

الحالات التي لا يُنصح فيها باستخدام Search Console

قد لا تكون Search Console مناسبة للمشاريع التي تستخدم أدوات مختلفة تابعة لجهات خارجية وتصنّف الصفحات حسب التشابه، أو إذا لم يكن الموقع الإلكتروني ممثلاً في مجموعة بيانات CrUX.

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

منارة

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

Lighthouse-CI هي أداة ذات صلة تعمل على تشغيل Lighthouse أثناء إنشاء المشاريع ونشرها للمساعدة في اختبار تراجع الأداء. ويعرض تقرير Lighthouse مع طلبات الدمج، ويتتبّع مقاييس الأداء بمرور الوقت.

حالات استخدام Lighthouse

يُعدّ Lighthouse أداة ممتازة للعثور على فرص تحسين الأداء أثناء التطوير في كلّ من بيئات التطوير المحلية وبيئات التشغيل التجريبي. تتوفّر أداة Lighthouse CI أيضًا في مرحلتَي الإنشاء والنشر في بيئتَي العرض التجريبي والإنتاج، حيث يلزم إجراء اختبارات تراجع الأداء للحفاظ على تجارب المستخدمين الجيدة.

الحالات التي لا يُستخدَم فيها Lighthouse

لا يمكن استخدام Lighthouse (أو Lighthouse CI) كبديل لبيانات الحقل. ‫Lighthouse هي في الأساس أداة تشخيص تسرد المشاكل المحتملة وأفضل الممارسات من عملية تحميل صفحة محدّدة مسبقًا. قد لا تتطابق الاقتراحات التي يعرضها دائمًا مع الأداء الذي يلاحظه المستخدمون.

على الرغم من إمكانية استخدام Lighthouse لتشخيص المواقع الإلكترونية المباشرة من خلال أدوات مثل PageSpeed Insights، من الأفضل استخدام Lighthouse في بيئات التطوير والتكامل المستمر لمعالجة مشاكل الأداء قبل أن تصل إلى مرحلة الإنتاج.

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

لوحة "الأداء" في "أدوات مطوّري البرامج في Chrome"

أدوات مطوّري البرامج في Chrome هي مجموعة من أدوات التطوير داخل المتصفّح، بما في ذلك لوحة الأداء. لوحة "الأداء" هي أداة تجريبية تتضمّن "وضعَين":

عند فتح "لوحة الأداء" لأول مرة، ستوفّر شاشة "المقاييس المباشرة" مقياس "مؤشرات أداء الويب الأساسية" الحالي، مع إمكانية استيراد البيانات الفعلية من CrUX. وهي مفيدة كطريقة "مباشرة" لعرض الأداء أثناء التفاعل مع الصفحة في محاولة للكشف عن مشاكل الأداء، لا سيما المشاكل التي قد تظهر بعد التحميل مع مقياسَي "متغيّر التصميم التراكمي" و"مدّة التفاعل مع الصفحة".

ثانيًا، تتيح "لوحة الأداء" للمطوّرين تسجيل ملف شخصي (أو تتبُّع) لجميع أنشطة الصفحة أثناء تحميلها أو خلال فترة زمنية مسجَّلة. تقدّم طريقة العرض هذه إحصاءات مفصّلة حول كل ما يتم رصده في جميع السمات، مثل الشبكة والعرض والرسم ونشاط البرمجة النصية، بالإضافة إلى مقاييس Core Web Vitals الخاصة بالصفحة. وتتضمّن أيضًا إحصاءات مشابهة لتلك التي توفّرها أداة Lighthouse.

حالات استخدام "لوحة الأداء"

يجب أن يستخدم المطوّرون "لوحة الأداء" للحصول على إحصاءات تفصيلية حول أداء صفحة معيّنة.

يمكن استخدام "عرض المقاييس المباشرة" للتعرّف بسرعة على خصائص الأداء الحالية للصفحة، ورصد المشاكل المحتملة أثناء التفاعل مع الصفحة.

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

الحالات التي لا يُستخدَم فيها "لوحة الأداء"

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

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

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

عند العمل على تحسين تجربة المستخدم، من الأفضل اعتبار العملية دورة مستمرة. لتحسين مؤشرات Core Web Vitals ومقاييس الأداء الأخرى، يمكنك اتّباع أحد الأساليب التالية:

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

الخطوة 1: تقييم حالة الموقع الإلكتروني وتحديد فرص التحسين

من الأفضل البدء ببيانات الحقل لتقييم سلامة الموقع الإلكتروني.

  1. استخدِم إحصاءات PageSpeed للاطّلاع على مقاييس تجربة مؤشرات Core Web Vitals الإجمالية على المصدر، ومعلومات محدّدة حول عنوان URL فردي.
  2. يمكن أن تكون Search Console مفيدة لتحديد الصفحات التي تحتاج إلى تحسين، حيث تعمل ميزة تجميع الصفحات بشكل جيد لموقعك الإلكتروني.
  3. إذا كانت لديك بيانات RUM، غالبًا ما يكون هذا الخيار هو الأفضل لتحديد صفحات أو شرائح زيارات معيّنة تتضمّن مشاكل.

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

تحليل أداء الموقع الإلكتروني باستخدام "إحصاءات PageSpeed"

طريقة عرض "إحصاءات PageSpeed" لبيانات CrUX الخاصة بمؤشرات أداء الويب الأساسية لعنوان URL يتم عرض كل مؤشر من مؤشرات Core Web Vitals بشكل منفصل، مع تجميع كل مؤشر في فئات "جيّد" و"بحاجة إلى تحسين" و"بطيء" خلال آخر 28 يومًا.
تحليل أداء الموقع الإلكتروني باستخدام "إحصاءات PageSpeed"

تعرض أداة PageSpeed Insights بيانات CrUX التي تغطي آخر 28 يومًا من بيانات تجربة المستخدم في الشريحة المئوية الخامسة والسبعين. وهذا يعني أنّه إذا كانت% 75 من تجارب المستخدمين تستوفي الحدّ الأدنى المحدد لمقياس معيّن، تُصنّف التجربة على أنّها "جيدة".

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

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

تعرض "إحصاءات PageSpeed" أيضًا جميع مؤشرات Core Web Vitals الثلاثة (سرعة عرض أكبر محتوى مرئي (LCP) ومتغيّرات التصميم التراكمية (CLS) ومدى استجابة الصفحة لتفاعلات المستخدم (INP)) بالإضافة إلى مقياسَي التشخيص "الوقت اللازم لظهور أوّل بايت" (TTFB) و"سرعة عرض أوّل جزء من المحتوى على الصفحة" (FCP). هل هناك أي من مؤشرات Core Web Vitals لا يستوفي المعايير، وما هو مقدار النقص؟ سيشير ذلك إلى المجالات التي يجب أن تركّز جهودك عليها.

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

بالنسبة إلى CLS، اطّلِع على نتائج CLS في CrUX وLighthouse لمعرفة ما إذا كانت المشكلة متعلقة بـ CLS أثناء التحميل (وهي مشكلة سيرصدها Lighthouse ويقدّم نصائح بشأنها)، أو بـ CLS بعد التحميل ولن يرصدها Lighthouse. لمزيد من المعلومات، اطّلِع على دليل تحسين CLS.

لتقييم مدى التجاوب، اطّلِع على نتائج مقياس INP. راجِع عمليات تدقيق "وقت الحظر الكلّي" في Lighthouse لمعرفة ما إذا كان يتم تنفيذ الكثير من عمليات معالجة JavaScript أثناء التحميل الأولي للصفحة، ما قد يؤثر في مقياس INP. قد يكون مقياس INP صعب التحسين، لذا يُرجى الرجوع إلى دليل تحسين مقياس INP للحصول على مزيد من المعلومات.

تحديد الصفحات ذات الأداء الضعيف في Search Console

تقرير "مؤشرات أداء الويب الأساسية" في Search Console ينقسم التقرير إلى فئتَين: "أجهزة الكمبيوتر المكتبي" و"الأجهزة الجوّالة"، ويتضمّن رسومات بيانية خطية توضّح توزيع الصفحات التي تتضمّن مؤشرات Core Web Vitals في الفئات "جيّدة" و"بحاجة إلى تحسين" و"بطيئة" بمرور الوقت.
تحديد الصفحات ذات الأداء الضعيف في Search Console

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

يعرض تقرير "مؤشرات أداء الويب الأساسية" في Search Console الصورة الكاملة لأداء موقعك الإلكتروني، ولكن يمكنك أيضًا التوغّل في صفحات معيّنة تحتاج إلى الاهتمام. باستخدام Search Console، يمكنك أيضًا إجراء ما يلي:

  • تحديد مجموعات الصفحات الفردية التي تحتاج إلى تحسين وتلك التي توفّر تجربة مستخدم جيدة
  • يمكنك الحصول على بيانات تفصيلية حول الأداء حسب عنوان URL، ويتم تجميعها حسب الحالة والمقياس ومجموعات صفحات الويب المتشابهة (مثل صفحات تفاصيل المنتجات على موقع إلكتروني للتجارة الإلكترونية).
  • يمكنك الحصول على تقارير تفصيلية تصنّف عناوين URL في كل فئة من فئات جودة تجربة المستخدم على الأجهزة الجوّالة وأجهزة الكمبيوتر.

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

الخطوة 2: تصحيح الأخطاء وتحسين الأداء

في الخطوة 1، من المفترض أنّك حدّدت الصفحات التي تتطلّب تحسينات في الأداء، بالإضافة إلى مقاييس "مؤشرات أداء الويب الأساسية" التي تريد تحسينها. يمكنك استخدام أدوات Google للحصول على مزيد من المعلومات وفهم السبب الأساسي للمشكلة.

  1. الاطّلاع على عمليات التدقيق في Lighthouse للحصول على إرشادات عامة بشأن الصفحة
  2. استخدِم عرض المقاييس المباشرة في لوحة الأداء لتحليل "مؤشرات أداء الويب الأساسية" في الوقت الفعلي.
  3. استخدِم ميزة تتبُّع الأداء في لوحة "الأداء" لتصحيح الأخطاء المتعلّقة بالأداء واختبار تغييرات الرموز.

للحصول على إرشادات أكثر تفصيلاً، يُرجى الاطّلاع على الأدلة التالية:

اكتشاف فرص التحسين باستخدام Lighthouse

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

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

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

يمكنك فلترة عمليات التدقيق لتشمل مؤشرات أداء الويب الأساسية التي تهمّك فقط، وذلك للتركيز على إصلاح المشاكل المرتبطة بمقياس معيّن:

خيارات فلترة Lighthouse للمقاييس الرئيسية
خيارات فلتر Lighthouse

بالنسبة إلى مقياس INP، استخدِم عمليات تدقيق TBT لتحديد المشاكل التي يمكن أن تؤثّر في هذه المقاييس، ولكن يجب الانتباه إلى أنّ Lighthouse لا يمكنه تشخيص الكثير من المشاكل بدون تفاعلات.

التحليل في الوقت الفعلي باستخدام شاشة المقاييس المباشرة في "أدوات مطوّري البرامج في Chrome"

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

عرض المقاييس المباشرة في لوحة "الأداء" ضمن "أدوات مطوّري البرامج في Chrome"
عرض المقاييس المباشرة في لوحة "الأداء" ضمن "أدوات مطوّري البرامج في Chrome"

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

التعمّق في التفاصيل باستخدام "لوحة الأداء"

تتيح لك لوحة "الأداء" في "أدوات مطوّري البرامج في Chrome" تسجيل ملف شخصي (أو عملية تتبُّع) لجميع سلوك الصفحة خلال فترة زمنية مسجّلة.

عملية تتبُّع في لوحة "الأداء" ضمن "أدوات مطوّري البرامج في Chrome" تعرض الرسم البياني الشريطي مع تمييز مهمة طويلة
تتبُّع "لوحة الأداء" في "أدوات مطوّري البرامج في Chrome"

تتوفّر إحصاءات الأداء في اللوحة الجانبية الإحصاءات. يعرض هذا التقرير أيضًا مقاييس Core Web Vitals مع قيم تجارب المستخدمين الحقيقيين لهذه المقاييس عند توفّرها.

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

يتم عرض التوقيتات الرئيسية، مثل LCP، في التوقيتات المتاحة في أسفل التتبُّع. انقر على هذه الرموز للحصول على مزيد من التفاصيل.

يتم أيضًا تمييز "المهام الطويلة" (التي يمكن أن تؤدي إلى مشاكل في مقياس INP) بمثلثات حمراء في مخطط اللهب.

يمكن أن تساعدك هذه الميزات، بالإضافة إلى المعلومات الواردة في الأجزاء الأخرى من لوحة الأداء، في تحديد ما إذا كانت الإصلاحات تؤثر في مؤشرات Core Web Vitals الخاصة بالصفحة.

تصحيح أخطاء "مؤشرات أداء الويب الأساسية" في بيئة التشغيل

لا يمكن لأدوات الاختبار في بيئة محكومة تحديد سبب جميع المشاكل المتعلّقة بمؤشرات Core Web Vitals التي تؤثر في المستخدمين. هذا هو أحد الأسباب التي تجعل من المهم جدًا جمع بياناتك الميدانية، لأنّها تأخذ في الاعتبار عوامل لا يمكن لبيانات المختبر أخذها في الاعتبار.

يمكنك الاطّلاع على تصحيح أخطاء الأداء في بيئة التشغيل للحصول على مزيد من المعلومات.

الخطوة 3: مراقبة التغييرات

مجموعة من الرموز لأدوات Google من اليسار إلى اليمين، تمثّل الرموز "تجربة المستخدم على Chrome في BigQuery" و"واجهة برمجة التطبيقات لتجربة المستخدم على Chrome" و"واجهة برمجة التطبيقات PageSpeed Insights" و"web-vitals.js"، مع "Lighthouse CI" في أقصى اليسار.
أدوات Google لتتبُّع التغييرات

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

أظهرت

مراقبة طلبات الأداء في بيئات التكامل المستمر (CI)

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

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

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

الخاتمة

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