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

كيفية قياس آلية Signed Exchange وتحسينها للاستفادة منها إلى أقصى حدّ

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

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

يستخدم معظم الأشخاص الذين ينشرون ملفات SXG اليوم ميزة عمليات Signed Exchange التلقائية (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 للمقارنة بين العرض الإعلاني بدون انقطاع وLCP مع الجلب المسبق SXG أو بدونه.

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

تجلب الإضافة عنوان 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 قد يتم تخزينها مؤقتًا وإعادة استخدامها لزيارات متعددة وزائرين متعددين.

من الأسباب الأخرى المحتملة لوضع علامة X (❌) توفّر أحد عناوين الاستجابة التي تتضمّن حالة محددة، باستثناء 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. وفي حال عدم إجراء ذلك، ستظهر رسالة خطأ.

الفهرسة

تأكَّد من فهرسة ملفات SXG بنجاح من خلال "بحث Google". افتح أدوات مطوري البرامج في 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 النتيجة التالية:

إذا ظهرت لك علامة اختيار (✅)، يمكنك التخطّي إلى أدوات تحسين الأداء من Google.

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

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

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

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

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

في الوقت الحالي، لا يتم إجراء الجلب المُسبَق لملفات SXG إلا في ظل ظروف معيّنة:

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

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

دراسة معاصرة

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

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

في "إحصاءات 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 بعبارة "تؤثِّر SXG في X% من مشاهدات الصفحة":

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

انقر على "إرسال"، ومن المفترض أن تظهر لك توزيعات سرعة عرض أكبر محتوى مرئي (LCP) للشريحتين. من المفترض أن يؤدي ذلك إلى ملء 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 الإجمالية التي تبلغ 75 بالمئة قبل وبعد، لتأكيد الدراسات المذكورة أعلاه. إن التعرف على مجموعة فرعية من المجموعة لا يخبرنا بالضرورة عن المجموعة بالكامل. على سبيل المثال، لنفترض أنّ آلية SXG تحسّن 10% من عمليات تحميل الصفحات بمقدار 800 ملي ثانية.

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

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

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

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

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

دراسة توجيهية

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

تحتوي دراسة توجيه الزيارات على السمات التالية:

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

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

الخاتمة

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

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

لمزيد من المعلومات حول آلية Signed Exchange، يمكنك الاطّلاع على مستندات web.dev ومستندات "بحث Google".