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

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

تبادلات البيانات الموقَّعة (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، انتقِل إلى صفحتك باستخدام إضافة أداة التحقّق من صحة SXG في متصفّح Chrome، وانقر على رمز الإضافة للاطّلاع على عنوان URL الخاص بذاكرة التخزين المؤقت:

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

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

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

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

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

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

النشر

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

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

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

في حال تفعيل Cloudflare ASX، قد يكون السبب الأكثر احتمالاً لظهور علامة 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 قد فهرس مجموعات 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.

الحد الأقصى للسن المسموح به

عند انتهاء صلاحية ملفات 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 إلا لبرامج الزحف التي تقبل التنسيق. يمكنك حصر قياس TTFB على الطلبات الواردة من مستخدمين حقيقيين وليس من برامج التتبُّع. قد تلاحظ أنّ إنشاء ملفات SXG يزيد من وقت استجابة خادم طلبات الزاحف، ولكنّ ذلك ليس له أي تأثير في تجربة الزوّار.

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

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

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

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

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

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

دراسة معاصرة

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

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

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

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

• 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" على النحو المقترَح لتسجيل سرعة عرض أكبر محتوى مرئي. إذا كنت تستخدِم gtag.js، عدِّل الأمر 'config' لضبط السمة المخصّصة (استبدِل 'dimension1' و'dimension2' بالأسماء التي تنصح "إحصاءات Google" باستخدامها):

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

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

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

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

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

المحاذير

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

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

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

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

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

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

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

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

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

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

• وإذا كانت هذه العمليات هي الأسرع بنسبة 10% في عمليات تحميل الصفحات، لن يؤثر ذلك في الشريحة المئوية الخامسة والسبعين على الإطلاق.
• إذا كانت هذه الصفحات هي أبطأ 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".