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

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

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

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

إذا رأيت علامة زائد (❌)، يعني ذلك أنّ SXG لم يتم إرجاعها:

في حال تفعيل Cloudflare ASX، يكون السبب الأكثر احتمالاً لظهور علامة زائدة (❌) هو أنّ عنوان استجابة عنصر التحكّم في ذاكرة التخزين المؤقت يمنع ذلك. تبحث 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 مختلفًا لمستخدمين مختلفين استنادًا إلى ملف تعريف ارتباطهم، قد تظهر لهم تجربة غير صحيحة، مثل عرض تسجيل الخروج.

بدلاً من ذلك، يمكنك استخدام أداة مثل 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.

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

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

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

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

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

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

اقرأ قسم الدراسة المعاصرة لمعرفة كيفية قياس "X% من مشاهدات الصفحة" و "تحسين سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) بمقدار Y بالمللي ثانية".

دراسة معاصرة

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

• أجهزة 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" على النحو المقترَح لتسجيل سرعة LCP. إذا كنت تستخدِم 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) بمقدار ص بالملي ثانية عند الشريحة المئوية الخامسة والسبعين":

المحاذير

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

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

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

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

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

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

دراسة توجيه الزيارات إلى العملاء

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

تتضمّن الدراسة الخاصة بتوجيه الزيارات إلى العميل السمات التالية:

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

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

الخلاصة

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

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

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