تحسين سرعة LCP باستخدام Signed Exchange

كيفية قياس عمليات التبادل الموقَّعة وتحسينها للاستفادة منها إلى أقصى حدّ

Devin Mullins

تبادلات البيانات الموقَّعة (SXG) هي وسيلة لتحسين سرعة صفحتك، وبشكل أساسي سرعة عرض أكبر محتوى مرئي (LCP). عندما تشير المواقع الإلكترونية (حاليًا "بحث Google") إلى صفحة، يمكنها التحميل المُسبَق لها في ذاكرة التخزين المؤقت للمتصفّح قبل أن ينقر المستخدم على الرابط.

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

يستخدم معظم الأشخاص الذين ينشرون ملفّات SXG اليوم ميزة عمليات التبادل الموقَّعة التلقائية (ASX) السهلة الاستخدام من Cloudflare (على الرغم من توفّر خيارات مفتوحة المصدر أيضًا):

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

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

• تحليل أداء SXG باستخدام WebPageTest
• تصحيح أخطاء مسار SXG إذا تبيّن من خطوة "التحليل" أنّه لا يعمل
• تحسين الصفحات لميزة "التحميل المُسبَق لشبكة الزيارات المجمّعة" (SXG)، بما في ذلك ضبط max-age الأمثل وتحميل الموارد الفرعية التي تمنع العرض مُسبَقًا
• قياس تحسين SXG باستخدام "إحصاءات Google" من خلال اختيار مجموعات التجربة ومجموعات التحكّم المناسبة

مقدمة

ملف SXG هو ملف يحتوي على عنوان URL ومجموعة من عناوين استجابة HTTP ونص الاستجابة، وكلّها موقَّعة بشكل مشفّر باستخدام شهادة Web PKI. عندما يحمِّل المتصفّح ملف SXG، يتحقّق من كلّ ما يلي:

• لم تنته صلاحية SXG.
• يتطابق التوقيع مع عنوان URL والعناوين والنص والشهادة.
• الشهادة صالحة وتتطابق مع عنوان URL.

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

في ما يتعلّق بخدمة "بحث Google"، تسمح آلية SXG بجلب الصفحات مسبقًا في نتائج البحث. بالنسبة إلى الصفحات التي تتيح استخدام ملفات SXG، يمكن لمحرّك بحث Google تحميل نسخة الصفحة المخزّنة مؤقتًا مسبقًا، والتي يتم استضافتها على webpkgcache.com. ولا تؤثّر عناوين URL هذه على webpkgcache.com في عرض الصفحة أو سلوكها، لأنّ المتصفّح يحترم عنوان URL الأصلي والموقَّع. يمكن أن تؤدي ميزة "التحميل المُسبَق" إلى تحميل صفحتك بشكل أسرع بكثير.

التحليل

للاستفادة من مزايا عمليات SXG، ابدأ باستخدام أداة اختبار لتحليل أداء SXG في ظروف يمكن تكرارها. يمكنك استخدام WebPageTest لمقارنة عمليات العرض بدون انقطاع وLCL مع وبدون ميزة "التحميل المُسبَق لمحتوى XML خارج الصفحة".

أنشئ اختبارًا بدون SXG على النحو التالي:

• انتقِل إلى WebPageTest وسجِّل الدخول. يؤدي تسجيل الدخول إلى حفظ سجلّ الاختبار لتسهيل المقارنة لاحقًا.
• أدخِل عنوان URL الذي تريد اختباره.
• انتقِل إلى الإعداد المتقدّم. (ستحتاج إلى الإعداد المتقدّم لاختبار SXG، لذا يساعد استخدامها هنا في ضمان تطابق خيارات الاختبار).
• في علامة التبويب إعدادات الاختبار، قد يكون من المفيد ضبط "الاتصال" على شبكة الجيل الرابع وزيادة "عدد الاختبارات المطلوب إجراؤها" إلى 7.
• انقر على بدء الاختبار.

أنشئ اختبارًا باستخدام SXG باستخدام الخطوات نفسها المذكورة أعلاه، ولكن قبل النقر على بدء الاختبار، انتقِل إلى علامة التبويب النص البرمجي والصق النص البرمجي WebPageTest التالي وعدِّل عنوانَي URL navigate وفقًا للتوجيهات:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

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

لتحديد عنوان URL الثاني navigate، انتقِل إلى صفحتك باستخدام إضافة Chrome الخاصة بأداة التحقّق من صحة SXG، وانقر على رمز الإضافة للاطّلاع على عنوان URL الخاص بذاكرة التخزين المؤقت:

بعد اكتمال هذين الاختبارَين، انتقِل إلى سجلّ الاختبارات، واختَر الاختبارَين، ثم انقر على مقارنة:

أضِف &medianMetric=LCP إلى عنوان URL المخصّص للمقارنة كي يختار WebPageTest الإجراء الذي يتضمن متوسط LCP لكلّ جانب من جوانب المقارنة. (الإعداد التلقائي هو المتوسط حسب "مقياس السرعة").

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

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

تصحيح الأخطاء

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

النشر

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

تُستخدَم الإضافة لجلب عنوان URL الحالي باستخدام عنوان طلب Accept يشير إلى أنّها تفضّل استخدام إصدار SXG. إذا ظهرت لك علامة اختيار (✅) بجانب "المصدر"، يعني ذلك أنّه تمّ عرض SXG، ويمكنك الانتقال إلى قسم الفهرسة.

إذا ظهرت علامة X (❌)، يعني ذلك أنّه لم يتم عرض ملف SXG:

إذا كان بروتوكول ASX في Cloudflare مفعّلاً، يكون السبب الأكثر ترجيحًا لظهور علامة X (❌) هو أنّ عنوان استجابة التحكّم في ذاكرة التخزين المؤقت يمنع ذلك. يفحص ASX العناوين التي تحمل الأسماء التالية:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

إذا كان أيٌّ من هذه العناوين يحتوي على أيٍّ من قيم العناوين التالية، سيؤدي ذلك إلى منع إنشاء ملف SXG:

• private
• no-store
• no-cache
• max-age أقل من 120، ما لم يتم إلغاؤه من خلال s-maxage أكبر من أو يساوي 120

لا تنشئ أداة ASX جدول SXG في هذه الحالات لأنّه قد يتم تخزين جداول SXG وإعادة استخدامها لعدد زيارات ومزوّرين متعدّدين.

من الأسباب الأخرى المحتمَلة لظهور علامة الحذف (❌) هو توفُّر أحد عناوين الاستجابة هذه التي تعتمد على الحالة، باستثناء Set-Cookie. تزيل ASX رأس Set-Cookie للامتثال لمواصفات SXG.

هناك سبب آخر محتمل وهو توفُّر عنوان استجابة Vary: Cookie. يُجلب Googlebot ملفات SXG بدون بيانات اعتماد المستخدمين وقد يعرضها لزوّار متعدّدين. إذا كنت تعرض صفحات HTML مختلفة للمستخدمين المختلفين استنادًا إلى ملفات تعريف الارتباط الخاصة بهم، قد يواجهون تجربة غير صحيحة، مثل عرض الصفحة بعد تسجيل الخروج.

بدلاً من إضافة Chrome، يمكنك استخدام أداة مثل curl:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

أو dump-signedexchange:

dump-signedexchange -verify -uri $URL

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

الفهرسة

تأكَّد من أنّ محرّك بحث Google قد فهرس مجموعات SXG بنجاح. افتح "أدوات مطوّري البرامج في Chrome"، ثم أجرِ بحثًا على Google عن صفحتك. إذا تم فهرستها كملف SXG، سيتضمّن رابط Google المؤدي إلى صفحتك data-sxg-url يشير إلى نسخة webpkgcache.com:

إذا اعتقد محرّك بحث Google أنّه من المرجّح أن ينقر المستخدم على النتيجة، سيحمّلها مسبقًا أيضًا:

يوجّه العنصر <link> المتصفّح إلى تنزيل ملف SXG في ذاكرة التخزين المؤقت الخاصة بالجلب المُسبَق. عندما ينقر المستخدم على عنصر <a>، سيستخدم المتصفّح ملف SXG المخزّن مؤقتًا لعرض الصفحة.

يمكنك أيضًا الاطّلاع على دليل على الترجيع المُسبَق من خلال الانتقال إلى علامة التبويب "الشبكة" في "أدوات المطوّر" والبحث عن عناوين URL تحتوي على webpkgcache.

إذا كان <a> يشير إلى webpkgcache.com، هذا يعني أنّ فهرسة "بحث Google" لبيانات التبادل الموقَّعة تعمل بشكل صحيح. يمكنك التخطّي إلى قسم نقل البيانات.

بخلاف ذلك، قد يكون محرّك بحث Google لم يُعيد الزحف إلى صفحتك بعد منذ تفعيل SXG. جرِّب أداة فحص عنوان URL في Google Search Console:

يشير توفّر العنوان digest: mi-sha256-03=... إلى أنّ محرّك بحث Google زحف بنجاح إلى إصدار SXG.

إذا لم يكن عنوان digest متوفّرًا، قد يشير ذلك إلى أنّه لم يتم عرض ملف SXG على Googlebot أو أنّه لم يتم تعديل الفهرس منذ تفعيل ملفات SXG.

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

العرض

عندما يفهرِّس محرّك بحث Google ملف SXG، يرسل نسخته إلى ذاكرة التخزين المؤقت لخدمة SXG من Google، والتي تتحقّق من توافقها مع متطلبات ذاكرة التخزين المؤقت. تعرِض إضافة Chrome النتيجة التالية:

إذا ظهرت علامة اختيار (✅)، يمكنك الانتقال إلى تحسين.

وفي حال عدم استيفائه للمتطلبات، ستظهر علامة علامة متقاطعة (❌) ورسالة تحذير توضّح السبب:

في هذه الحالة، ستعمل الصفحة كما كانت تعمل قبل تفعيل SXG. سيضيف محرّك بحث Google رابطًا يؤدي إلى الصفحة على مضيفها الأصلي بدون ميزة "التحميل المُسبَق" لملف SXG.

في حال انتهاء صلاحية النسخة المخزّنة مؤقتًا وإعادة جلبها في الخلفية، ستظهر لك ساعة رملية (⌛):

تتضمّن أيضًا مستندات المطوّرين في Google حول SXG تعليمات حول الاستعلام عن ذاكرة التخزين المؤقت يدويًا.

تحسين

إذا كانت إضافة أداة التحقّق من صحة SXG في متصفّح Chrome تعرض كل علامات الاختيار (✅)، يعني ذلك أنّ لديك ملف SXG يمكن عرضه للمستخدمين. تابِع القراءة لمعرفة كيفية تحسين صفحة الويب للحصول على أقصى تحسّن في مقياس LCP من خلال SXG.

max-age

عند انتهاء صلاحية ملفات SXG، ستسترجع ذاكرة التخزين المؤقت لـ SXG من Google نسخة جديدة في الخلفية. أثناء انتظار عملية الجلب هذه، يتم توجيه المستخدمين إلى الصفحة على مضيفها الأصلي، والتي لا يتم جلبها مسبقًا. كلما زادت المدة التي تضبط فيها Cache-Control: max-age، قلّت وتيرة حدوث عملية الجلب هذه في الخلفية، وبالتالي زادت وتيرة تقليل LCP من خلال الترجيع المُسبَق.

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

• max-age=86400 (يوم واحد) أو أكثر يُحقّق أداءً جيدًا
• max-age=120 (دقيقتان) لا

نأمل أن نتعرّف على مزيد من المعلومات عن القيم بين هاتين القيمتَين، وذلك أثناء دراستنا للبيانات بشكل أكبر.

وكيل المستخدم

في إحدى المرات، لاحظتُ زيادة في مقياس LCP عند استخدام ملف SXG تمّ تحميله مسبقًا. أجريتُ اختبار WebPageTest، وقارنتُ بين متوسط النتائج بدون ميزة "التحميل المُسبَق لمحتوى SXG" ومعها. النقر على بعد أدناه:

لقد لاحظتُ أنّ ميزة "التحميل المُسبَق" تعمل. تتم إزالة ملف HTML من المسار الحرج، وبالتالي يمكن تحميل جميع الموارد الفرعية في وقت أبكر. ولكنّ LCP، وهو الخط الأخضر المتقطّع، زاد من ثانيتَين إلى 2.1 ثانية.

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

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

بعد النقر على "بعد"، لاحظت أنّ وقت LCP الذي تمّ جلبه مسبقًا ينخفض إلى 1.3 ثانية:

تكون ملفات SXG مفعَّلة لجميع أشكال الأجهزة. للاستعداد لذلك، تأكَّد من أنّ أحد الإجراءَين التاليَين صحيح:

• لا Vary صفحتك حسب User-Agent (على سبيل المثال، تستخدم تصميمًا سريع الاستجابة أو عناوين URL منفصلة للأجهزة الجوّالة/أجهزة الكمبيوتر المكتبي).
• إذا كانت صفحتك تستخدم العرض الديناميكي، ستضيف تعليقًا توضيحيًا بأنّها مخصّصة للأجهزة الجوّالة أو أجهزة الكمبيوتر المكتبي فقط باستخدام <meta name=supported-media content=...>.

الموارد الفرعية

يمكن استخدام ملفات SXG لتحميل الموارد الفرعية مسبقًا (بما في ذلك الصور) مع ملف HTML. ستفحص خدمة Cloudflare ASX صفحات HTML بحثًا عن عناصر <link rel=preload> من المصدر نفسه (الطرف الأول) وستحوّلها إلى رؤوس روابط متوافقة مع SXG. يمكنك الاطّلاع على التفاصيل في رمز المصدر هنا وهنا.

إذا كان يعمل، سترى عمليات تحميل مُسبَق إضافية من "بحث Google":

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

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

لا تتحقّق أداة التحقّق من صحة SXG حاليًا من الموارد الفرعية. لتصحيح الأخطاء، استخدِم curl أو dump-signedexchange في الوقت الحالي.

القياس

بعد تحسين سرعة عرض أكبر محتوى مرئي (LCP) في WebPageTest، من المفيد قياس تأثير ميزة "التحميل المُسبَق" لملف SXG في الأداء العام لموقعك الإلكتروني.

المقاييس من جهة الخادم

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

المقاييس من جهة العميل

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

بدلاً من ذلك، أجد أنّه من المفيد "تكبير" عمليات تحميل الصفحات التي يُحتمل أن تكون متأثرة، وتقديمها على النحو التالي: "تؤثر ملفات SXG في% X من مشاهدات الصفحة، ما يؤدي إلى تحسين سرعة LCP بمقدار Y ملي ثانية في الشريحة المئوية 75".

لا يتم حاليًا تحميل SXG مسبقًا إلا في حالات معيّنة:

• متصفّح Chromium (مثل Chrome أو Edge باستثناء iOS)، الإصدار M98 أو إصدار أحدث
• Referer: google.com أو نطاقات بحث Google الأخرى (يُرجى العِلم أنّه في "إحصاءات Google"، تنطبق علامة الإحالة على كل مشاهدات الصفحة في الجلسة، في حين لا ينطبق التلفّع المُسبَق لملفّات SXG إلا على أول مشاهدة للصفحة، المرتبطة مباشرةً من "بحث Google").

اطّلِع على قسم "الدراسة المعاصرة" لمعرفة كيفية قياس "X% من مشاهدات الصفحة" و"تحسين LCP بمقدار Y ملي ثانية".

دراسة معاصرة

عند الاطّلاع على بيانات مراقبة المستخدِمين الفعليين (RUM)، يجب تقسيم عمليات تحميل الصفحات إلى عمليات تحميل SXG وغير SXG. عند إجراء ذلك، من الضروري حصر مجموعة عمليات تحميل الصفحات التي تطّلع عليها، لكي تتطابق الجهة غير المزوّدة بميزة SXG مع شروط الأهلية للحصول على هذه الميزة، وذلك لتجنّب الانحياز في الاختيار. بخلاف ذلك، ستظهر جميع العناصر التالية فقط في مجموعة عمليات تحميل الصفحات غير المستندة إلى SXG، والتي قد تختلف فيها قيمة LCP بشكلٍ أساسي:

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

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

أنشِئ شريحة جمهور مخصّصة باسم "SXG counterfactual" باستخدام الفلاتر التالية مع بعضها:

• referrer يبدأ بـ https://www.google.
• يتطابق Browser تمامًا مع Chrome
• Browser يتطابق الإصدار مع التعبير العادي ^(9[8-9]|[0-9]{3})
• يتطابق isSXG تمامًا مع false

أنشئ نسخة من هذه الشريحة باسم "SXG"، باستثناء أنّ isSXG يتطابق تمامًا مع true.

في نموذج موقعك الإلكتروني، أضِف المقتطف التالي فوق مقتطف "إحصاءات Google". هذه بنية خاصة ستغيّر ASX القيمة false إلى true عند إنشاء SXG:

<script data-issxg-var>window.isSXG=false</script>

خصِّص النص البرمجي لإعداد تقارير "إحصاءات Google" على النحو المُقترَح لتسجيل LCP. إذا كنت تستخدِم gtag.js، عدِّل الأمر 'config' لضبط السمة المخصّصة (استبدِل 'dimension1' و'dimension2' بالأسماء التي تنصح "إحصاءات Google" باستخدامها):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

إذا كنت تستخدم analytics.js، عدِّل الأمر 'create' على النحو الموضّح هنا.

بعد الانتظار لبضعة أيام لجمع بعض البيانات، انتقِل إلى تقرير "أحداث "إحصاءات Google وأضِف ميزة التوغّل في شريحة الجمهور المستندة إلى البيانات (SXG). من المفترض أن يؤدي ذلك إلى ملء القيمة X في العبارة "تؤثر إعلانات الشبكات الإعلانية المتجاوبة على X% من مشاهدات الصفحة":

أخيرًا، انتقِل إلى تقرير "مؤشرات الأداء الرئيسية للويب"، واختَر "اختيار الشرائح"، ثمّ اختَر "الحالة الافتراضية لتجربة المستخدم" و"تجربة المستخدم".

انقر على "إرسال"، ومن المفترض أن تظهر لك توزيعات LCP للشريطَين. من المفترض أن يؤدي ذلك إلى ملء القيمة Y في "تحسين سرعة LCP بمقدار Y ملي ثانية في الشريحة المئوية الخامسة والسبعين":

المحاذير

بعد تطبيق جميع الفلاتر أعلاه، يجب أن تتألف عمليات تحميل الصفحات المضادة للفرضيات في SXG من عناصر مثل ما يلي:

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

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

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

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

دراسة ما قبل/ما بعد

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

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

• قد تؤدي إصدارات المتصفّح الجديدة أو التحسينات في أجهزة المستخدمين إلى تسريع تحميل الصفحات.
• قد يؤدي حدث مهم، مثل عطلة، إلى تغيير عدد الزيارات عن المعتاد.

من المفيد أيضًا الاطّلاع على مقياس LCP العام للنسبة المئوية التسعون قبل إجراء التغيير وبعده، لتأكيد الدراسات أعلاه. إنّ الاطّلاع على مجموعة فرعية من السكان لا يقدّم لنا بالضرورة معلومات عن المجموعة ككل. على سبيل المثال، لنفترض أنّ تقنية SXG تحسّن 10% من عمليات تحميل الصفحات بمقدار 800 مللي ثانية.

• إذا كانت هذه هي أسرع 10% من عمليات تحميل الصفحات، لن يؤثّر ذلك في الشريحة المئوية الـ 75 على الإطلاق.
• إذا كانت هذه الصفحات هي أبطأ 10% من عمليات تحميل الصفحات، ولكنّها كانت أبطأ من سرعة LCP في الشريحة المئوية الـ 75 بأكثر من 800 ملي ثانية، لن تؤثّر هذه الصفحات في الشريحة المئوية الـ 75 على الإطلاق.

هذه أمثلة متطرفة، ومن المرجّح أنّها لا تعبّر عن الواقع، ولكن نأمل أن توضّح المشكلة. من الناحية العملية، من المرجّح أن تؤثّر علامة SXG في الشريحة المئوية الخامسة والسبعين لمعظم المواقع الإلكترونية. غالبًا ما تكون عمليات التنقّل بين المواقع الإلكترونية من بين العمليات الأبطأ، وتكون التحسينات الناتجة عن الترجيع المُسبَق كبيرة.

إيقاف بعض عناوين URL

أخيرًا، يمكن أن تكون إحدى طرق مقارنة أداء SXG هي إيقاف SXG لبعض المجموعات الفرعية من عناوين URL على موقعك الإلكتروني. على سبيل المثال، يمكنك ضبط عنوان CDN-Cache-Control: no-store لمنع Cloudflare ASX من إنشاء SXG. لا أنصح بذلك.

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

دراسة فترة الانتظار

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

تتضمّن دراسة فترة الانتظار السمات التالية:

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

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

الخاتمة

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

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

لمزيد من المعلومات عن عمليات التبادل الموقَّعة، اطّلِع على مستندات web.dev ومستندات "بحث Google".