بهینه سازی LCP با استفاده از Signed Exchanges

نحوه اندازه‌گیری و بهینه‌سازی صرافی‌های امضا شده برای بهره‌مندی بیشتر از آنها

Devin Mullins

صرافی‌های امضا شده (SXGs) وسیله‌ای برای بهبود سرعت صفحه شما هستند - عمدتاً بزرگترین رنگ محتوایی (LCP) . هنگامی که سایت‌ها (جستجوی فعلی گوگل) به یک صفحه پیوند داده می‌شوند، می‌توانند قبل از اینکه کاربر روی پیوند کلیک کند، آن را در حافظه پنهان مرورگر واکشی کنند .

این امکان وجود دارد که صفحات وبی بسازید که وقتی از قبل واکشی می شوند، نیازی به شبکه ای در مسیر حیاتی رندر صفحه ندارند! در اتصال 4G، این بارگذاری صفحه از 2.8 ثانیه به 0.9 ثانیه می رسد (0.9 ثانیه باقیمانده بیشتر بر اساس استفاده از CPU است):

توجه: قبلاً این پست از 6s به 0.9s بهبود یافته بود. این درست بود، اما سایت مورد آزمایش در آن زمان به طور غیر معمول کند بود. با این حال، ممکن است به عنوان نمونه ای از صفحات با منابع فرعی بیشتر ، سرورهای کندتر ، یا کاربرانی با انواع اتصال کندتر عمل کند.

اکثر افرادی که امروز SXG را منتشر می‌کنند از ویژگی تبادلات امضا شده خودکار (ASX) با استفاده آسان Cloudflare استفاده می‌کنند (اگرچه گزینه‌های منبع باز نیز وجود دارد):

در بسیاری از موارد، علامت زدن کادر برای فعال کردن این ویژگی برای دریافت نوع بهبود قابل توجهی که در بالا نشان داده شده است کافی است. گاهی اوقات، چند مرحله دیگر برای اطمینان از عملکرد این SXGها در هر مرحله از خط لوله، و بهینه سازی صفحات برای استفاده کامل از واکشی اولیه وجود دارد.

در چند ماه گذشته پس از راه‌اندازی Cloudflare، من در حال مطالعه و پاسخ به سؤالات در انجمن‌های مختلف بوده‌ام و یاد گرفته‌ام که چگونه به سایت‌ها در مورد چگونگی اطمینان از اینکه آنها بیشترین بهره را از استقرار SXG خود می‌برند توصیه کنم. این پست مجموعه ای از توصیه های من است. من مراحل زیر را طی می کنم:

• عملکرد SXG را با استفاده از WebPageTest تجزیه و تحلیل کنید .
• اگر مرحله تجزیه و تحلیل نشان داد که خط لوله SXG کار نمی کند، اشکال زدایی کنید .
• صفحات را برای واکشی اولیه SXG از جمله تنظیم max-age بهینه و از پیش بارگذاری منابع فرعی مسدودکننده رندر بهینه کنید.
• با انتخاب گروه‌های آزمایش و کنترل مناسب، بهبود SXG را با استفاده از Google Analytics اندازه‌گیری کنید .

مقدمه

یک SXG یک فایل حاوی یک URL، مجموعه‌ای از سرصفحه‌های پاسخ HTTP، و بدنه پاسخ است—همه به صورت رمزنگاری شده توسط یک گواهی وب PKI امضا شده‌اند. هنگامی که مرورگر یک SXG را بارگذاری می کند، همه این موارد را تأیید می کند:

• SXG منقضی نشده است.
• امضا با URL، سرصفحه ها، بدنه و گواهی مطابقت دارد.
• گواهی معتبر است و با URL مطابقت دارد.

اگر تأیید ناموفق باشد، مرورگر SXG را رها می‌کند و در عوض URL امضا شده را واکشی می‌کند. اگر راستی‌آزمایی با موفقیت انجام شود، مرورگر پاسخ امضا شده را بارگیری می‌کند و با آن برخورد می‌کند که گویی مستقیماً از URL امضا شده آمده است. این به SXG ها اجازه می دهد تا زمانی که از زمان امضای امضا منقضی یا تغییر نکرده اند، روی هر سروری دوباره میزبانی شوند.

در مورد جستجوی گوگل، SXG واکشی اولیه صفحات را در نتایج جستجوی خود فعال می کند . برای صفحاتی که از SXGها پشتیبانی می‌کنند، جستجوی Google می‌تواند نسخه ذخیره‌شده خود از صفحه را که در webpkgcache.com میزبانی می‌شود، از قبل واکشی کند. این نشانی‌های اینترنتی webpkgcache.com بر نمایش یا رفتار صفحه تأثیری نمی‌گذارند، زیرا مرورگر به URL اصلی و امضا شده احترام می‌گذارد. واکشی اولیه می تواند صفحه شما را قادر به بارگیری بسیار سریعتر کند.

توجه: SXG ها به طور بالقوه برای موارد استفاده دیگر که در این مقاله پوشش داده نشده اند مفید هستند. برای مثال، آنها می‌توانند انعطاف‌پذیری اتصال را فعال کنند: یک برنامه چت می‌تواند پیوندی را که برای کاربر ارسال می‌شود، در صورتی که صفحه از SXG پشتیبانی می‌کند، از قبل دانلود کند، بنابراین آنها می‌توانند بعداً در حالت آفلاین آن را مشاهده کنند. این لیست بزرگتر از موارد استفاده بالقوه را ببینید.

تجزیه و تحلیل کنید

برای مشاهده مزایای SXG، با استفاده از ابزار آزمایشگاهی برای تجزیه و تحلیل عملکرد SXG در شرایط تکرارپذیر شروع کنید. می‌توانید از WebPageTest برای مقایسه آبشارها و LCP با و بدون واکشی اولیه SXG استفاده کنید.

احتیاط: نتایج آزمایشگاه ممکن است با تجربیات واقعی کاربر متفاوت باشد ، اما آنها ابزار مفیدی برای تشخیص مکان بهینه سازی و تکرار سریع هستند. نحوه اندازه گیری معیارهای کاربر واقعی حاصل را در بخش اندازه گیری پوشش خواهیم داد.

یک تست بدون SXG به شرح زیر ایجاد کنید:

• به WebPageTest بروید و وارد شوید. ورود به سیستم، سابقه آزمایش شما را برای مقایسه آسان‌تر در آینده ذخیره می‌کند.
• URL مورد نظر برای آزمایش را وارد کنید.
• به تنظیمات پیشرفته بروید. (شما برای تست SXG به تنظیمات پیشرفته نیاز دارید، بنابراین استفاده از آن در اینجا کمک می کند تا مطمئن شوید که گزینه های تست یکسان هستند.)
• در برگه تنظیمات تست ، تنظیم اتصال روی 4G و افزایش «تعداد آزمایش‌ها برای اجرا» به 7 ممکن است مفید باشد.
• روی Start Test کلیک کنید.

با استفاده از مراحل مشابه بالا، یک آزمایش با SXG ایجاد کنید، اما قبل از کلیک بر روی Start Test ، به برگه Script بروید، اسکریپت 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 ظاهر نشده است، می توانید از این صفحه واکشی اولیه برای ایجاد یک صفحه نتایج جستجوی وانمودی برای این منظور استفاده کنید.

برای تعیین نشانی وب navigate دوم، از صفحه خود با استفاده از برنامه افزودنی SXG Validator Chrome دیدن کنید و روی نماد برنامه افزودنی کلیک کنید تا URL حافظه پنهان را ببینید:

پس از تکمیل این تست ها، به Test History بروید، دو تست را انتخاب کنید و روی مقایسه کلیک کنید:

&medianMetric=LCP به URL مقایسه اضافه کنید تا WebPageTest اجرای با LCP میانه را برای هر طرف مقایسه انتخاب کند. (میانگین با شاخص سرعت است.)

برای مقایسه آبشارها، قسمت Waterfall Opacity را باز کرده و نوار لغزنده را بکشید. برای مشاهده ویدیو، روی Adjust Filmstrip Settings کلیک کنید، داخل آن گفتگو به پایین بروید و روی View Video کلیک کنید.

اگر واکشی اولیه SXG با موفقیت انجام شود، خواهید دید که آبشار "با SXG" ردیفی برای HTML ندارد و واکشی برای منابع فرعی زودتر شروع می شود. به عنوان مثال، "قبل" و "بعد" را در اینجا مقایسه کنید:

اشکال زدایی

اگر WebPageTest نشان دهد که SXG در حال واکشی اولیه است، در تمام مراحل خط لوله موفق بوده است. برای یادگیری نحوه بهبود بیشتر LCP، می توانید به بخش Optimize بروید. در غیر این صورت، باید دریابید که در کجای خط لوله شکست خورده و چرا. ادامه مطلب را بخوانید تا یاد بگیرید چگونه

انتشار

مطمئن شوید که صفحات شما به صورت SXG تولید می شوند. برای انجام این کار، باید وانمود کنید که یک خزنده هستید. ساده ترین راه استفاده از افزونه SXG Validator Chrome است:

توجه: SXGها برای خزنده‌های دارای قابلیت SXG برای فعال کردن واکشی اولیه در نظر گرفته شده‌اند. هنگامی که کاربران مستقیماً از سایت شما بازدید می کنند، نباید SXGها را به آنها ارائه دهید، زیرا آنها از قبل واکشی نمی شوند - انجام این کار فقط هزینه های اضافی را اضافه می کند. Cloudflare ASX این مذاکره محتوا را به صورت خودکار انجام می دهد.

برنامه افزودنی URL فعلی را با یک سرصفحه Accept درخواست که می گوید نسخه SXG را ترجیح می دهد واکشی می کند. اگر علامت تیک (✅) را در کنار Origin مشاهده کردید، به این معنی است که یک SXG برگردانده شده است. می توانید به بخش Indexing بروید.

اگر علامت متقاطع (❌) را مشاهده کردید، به این معنی است که 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‌ها در حافظه پنهان ذخیره شوند و برای بازدیدهای متعدد و بازدیدکنندگان متعدد مورد استفاده مجدد قرار گیرند .

یکی دیگر از دلایل احتمالی علامت متقاطع (❌) وجود یکی از این هدرهای پاسخ حالت دار است، به جز Set-Cookie . ASX هدر Set-Cookie را حذف می کند تا با مشخصات SXG مطابقت داشته باشد.

نکته: این محدودیت ها با جزئیات بیشتر در کد ASX قابل مشاهده است. برای مثال، سرصفحه‌های کنترل حافظه پنهان توسط کدی بررسی می‌شوند که تعیین می‌کند چه زمانی امضا شود و چه مدت زمان امضا باید باشد . سایر هدرها قبل از امضا با این پیکربندی یا این کد حذف می شوند. سرصفحه های دیگر از امضا کردن جلوگیری می کنند، اگر به شکل دیگری حذف نشده باشند.

دلیل احتمالی دیگر وجود هدر پاسخ Vary: Cookie است. Googlebot SXG ها را بدون اعتبار کاربری واکشی می کند و ممکن است آنها را به چندین بازدیدکننده ارائه دهد. اگر HTML متفاوتی را بر اساس کوکی به کاربران مختلف ارائه دهید، آن‌ها می‌توانند تجربه نادرستی مانند نمای خروج از سیستم را ببینند.

توجه: در آینده، صفحاتی که از Vary: Cookie استفاده می‌کنند توسط SXG پشتیبانی می‌شوند و فقط به بازدیدکنندگان بدون کوکی برای سایت شما نشان داده می‌شوند. این در Chromium پیاده‌سازی می‌شود و پس از عرضه کامل‌تر در جستجوی Google فعال می‌شود.

به جای افزونه کروم، می‌توانید از ابزاری مانند curl استفاده کنید:

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

یا dump-signedexchange :

dump-signedexchange -verify -uri $URL

اگر SXG وجود داشته باشد و معتبر باشد، یک پرینت قابل خواندن توسط انسان از SXG خواهید دید. در غیر این صورت با پیغام خطا مواجه خواهید شد.

نمایه سازی

مطمئن شوید که SXG های شما با موفقیت توسط جستجوی گوگل ایندکس شده اند. Chrome DevTools را باز کنید، سپس یک جستجوی Google برای صفحه خود انجام دهید. اگر به عنوان SXG ایندکس شده باشد، پیوند Google به صفحه شما شامل یک data-sxg-url است که به نسخه webpkgcache.com اشاره می کند:

اگر جستجوی Google فکر می‌کند که کاربر احتمالاً روی نتیجه کلیک می‌کند، آن را نیز از قبل واکشی می‌کند:

عنصر <link> به مرورگر دستور می دهد که SXG را در کش اولیه خود دانلود کند. هنگامی که کاربر روی عنصر <a> کلیک می کند، مرورگر از آن SXG ذخیره شده برای نمایش صفحه استفاده می کند.

همچنین می توانید با رفتن به برگه Network در DevTools و جستجوی URL های حاوی webpkgcache ، شواهدی از واکشی اولیه را مشاهده کنید.

اگر <a> به webpkgcache.com اشاره کند، به این معنی است که نمایه سازی جستجوی Google برای تبادل امضا شده کار می کند. می توانید به بخش Ingestion بروید.

در غیر این صورت، ممکن است گوگل از زمانی که SXG را فعال کرده‌اید، صفحه شما را بازنموده باشد. ابزار بازرسی URL کنسول جستجوی گوگل را امتحان کنید:

وجود هدر خلاصه digest: mi-sha256-03=... نشان می دهد که Google با موفقیت نسخه SXG را خزیده است.

اگر سرصفحه digest وجود نداشته باشد، این می‌تواند نشانه‌ای از عدم ارائه یک SXG به Googlebot باشد یا از زمانی که SXGs را فعال کرده‌اید، فهرست به‌روزرسانی نشده است.

اگر یک SXG با موفقیت خزیده شود، اما هنوز به آن پیوند داده نشده است، ممکن است در برآورده کردن الزامات حافظه نهان SXG ناموفق باشد. در بخش بعدی به این موارد پرداخته شده است.

بلع

هنگامی که جستجوی Google یک SXG را نمایه می‌کند، کپی آن را به حافظه پنهان Google SXG می‌فرستد، که آن را در برابر الزامات حافظه پنهان تأیید می‌کند. افزونه کروم نتیجه را نشان می دهد:

اگر علامت تیک (✅) را مشاهده کردید، می‌توانید به بهینه‌سازی بروید.

اگر نتواند الزامات را برآورده کند، یک علامت متقاطع (❌) و یک پیام هشدار دهنده خواهید دید که دلیل آن را نشان می دهد:

در این رویداد، صفحه درست مانند قبل از فعال کردن SXG کار خواهد کرد. Google بدون واکشی اولیه SXG به صفحه در میزبان اصلی خود پیوند خواهد داد.

در صورتی که نسخه ذخیره شده در حافظه پنهان منقضی شده باشد و دوباره در پس‌زمینه واکشی شود، یک ساعت شنی (⌛) خواهید دید:

سند توسعه‌دهنده Google در SXG همچنین دستورالعمل‌هایی برای جستجوی دستی حافظه پنهان دارد.

بهینه سازی کنید

اگر افزونه SXG Validator Chrome همه علامت‌ها را نشان می‌دهد (✅)، شما یک SXG دارید که می‌تواند به کاربران ارائه شود! در ادامه بخوانید تا دریابید که چگونه صفحه وب خود را بهینه کنید تا بیشترین بهبود LCP را از SXG دریافت کنید.

حداکثر سن

وقتی SXG ها منقضی شوند، Google SXG Cache یک کپی جدید در پس زمینه دریافت می کند. در حالی که منتظر آن واکشی هستند، کاربران به صفحه میزبان اصلی آن هدایت می شوند که از قبل واکشی نشده است. هرچه Cache-Control: max-age را طولانی‌تر تنظیم کنید، این واکشی پس‌زمینه کمتر اتفاق می‌افتد و بنابراین، LCP را می‌توان با prefetch کاهش داد.

این یک معاوضه بین عملکرد و تازگی است، و حافظه پنهان به صاحبان سایت اجازه می دهد تا حداکثر سن SXG را بین 2 دقیقه تا 7 روز، متناسب با نیازهای خاص هر صفحه، ارائه دهند. به طور حکایتی متوجه می شویم که:

• max-age=86400 (1 روز) یا بیشتر برای عملکرد خوب عمل می کند
• max-age=120 (2 دقیقه) ندارد

ما امیدواریم که با مطالعه بیشتر داده ها، در مورد مقادیر بین این دو اطلاعات بیشتری کسب کنیم.

توجه: ما قصد داریم با افزودن یک API پاکسازی کش، مدیریت این مبادله را در آینده آسان‌تر کنیم. در webpackaging-announce اعلام خواهد شد.

عامل کاربر

یک بار، هنگام استفاده از SXG از پیش واکشی شده، شاهد افزایش LCP بودم. من WebPageTest را اجرا کردم و نتایج متوسط ​​را بدون و با واکشی اولیه SXG مقایسه کردم. با کلیک بر روی After در زیر:

دیدم که واکشی اولیه کار می کند. HTML از مسیر بحرانی حذف می شود و بنابراین، همه منابع فرعی می توانند زودتر بارگیری شوند. اما LCP - آن خط چین سبز - از 2 به 2.1 افزایش یافت .

برای تشخیص این موضوع به نوارهای فیلم نگاه کردم. من متوجه شدم که صفحه در SXG متفاوت ارائه می شود. در HTML ساده، کروم تشخیص داد که "بزرگترین عنصر" برای LCP عنوان عنوان است. با این حال، در نسخه SXG، صفحه یک بنر با بارگذاری تنبل اضافه کرد، که عنوان را به زیر صفحه می‌برد و باعث می‌شد بزرگترین عنصر جدید، گفتگوی رضایت کوکی با بارگذاری تنبل باشد. همه چیز سریعتر از قبل ارائه شد، اما تغییر در چیدمان باعث شد که متریک آن را کندتر گزارش کند.

من عمیق تر کاوش کردم و متوجه شدم دلیل تفاوت در چیدمان این است که صفحه براساس User-Agent متفاوت است و در منطق خطایی وجود داشت. با وجود اینکه سرصفحه خزیدن SXG نشان‌دهنده تلفن همراه بود، یک صفحه دسک‌تاپ را ارائه می‌کرد. پس از رفع این مشکل، مرورگر به درستی عنوان صفحه را به عنوان بزرگترین عنصر آن دوباره شناسایی کرد.

اکنون با کلیک بر روی "After"، دیدم که LCP از پیش واکشی شده به 1.3 ثانیه کاهش می یابد :

SXG ها برای همه عوامل شکل فعال هستند. برای آماده شدن برای آن، مطمئن شوید که یکی از این موارد درست است:

• صفحه شما بر اساس User-Agent Vary نمی کند (مثلاً از طراحی واکنشگرا یا URL های مجزای تلفن همراه/دسکتاپ استفاده می کند).
• اگر صفحه شما از سرویس پویا استفاده می‌کند، با استفاده از <meta name=supported-media content=...> خود را فقط برای موبایل یا دسک‌تاپ حاشیه‌نویسی می‌کند.

منابع فرعی

SXG ها را می توان برای واکشی اولیه منابع فرعی (از جمله تصاویر) همراه با HTML استفاده کرد. Cloudflare ASX HTML را برای عناصر <link rel=preload> یکسان (طرف اول) اسکن می کند و آنها را به هدرهای پیوند سازگار با SXG تبدیل می کند. جزئیات در کد منبع اینجا و اینجا .

اگر کار می‌کند، واکشی‌های اولیه اضافی را از جستجوی Google خواهید دید:

برای بهینه سازی LCP، به آبشار خود دقت کنید و بفهمید که کدام منابع در مسیر حیاتی رندر بزرگترین عنصر قرار دارند. اگر نمی توان آنها را از قبل واکشی کرد، در نظر بگیرید که آیا می توان آنها را از مسیر بحرانی خارج کرد . مواظب اسکریپت هایی باشید که صفحه را پنهان می کنند تا زمانی که بارگذاری آنها تمام شود.

Google SXG Cache تا 20 پیش‌منبع فرعی را اجازه می‌دهد و ASX تضمین می‌کند که از این محدودیت تجاوز نمی‌شود. با این حال، اضافه کردن بسیاری از پیش‌منبع‌های فرعی خطر وجود دارد. مرورگر تنها در صورتی از منابع فرعی از پیش بارگذاری شده استفاده می کند که واکشی همه آنها به پایان رسیده باشد تا از ردیابی بین سایتی جلوگیری کند . هرچه منابع فرعی بیشتر باشد، احتمال کمتری وجود دارد که همه آنها واکشی اولیه را قبل از کلیک کاربر به صفحه شما تمام کرده باشند.

توجه: ASX در حال حاضر فقط از واکشی اولیه برای منابع فرعی هم منبع (طرف اول) پشتیبانی می کند. اگر ارائه‌دهنده‌های منبع فرعی شخص ثالثی را می‌شناسید که از SXG پشتیبانی می‌کنند، در مورد این باگ به ما اطلاع دهید تا بتوانیم اضافه کردن پشتیبانی متقاطع را در اولویت قرار دهیم.

SXG Validator در حال حاضر منابع فرعی را بررسی نمی کند. برای اشکال زدایی، از curl یا dump-signedexchange در این فاصله استفاده کنید.

اندازه گیری کنید

پس از بهینه سازی بهبود LCP تحت WebPageTest، اندازه گیری تأثیر واکشی اولیه SXG بر عملکرد کلی سایت شما مفید است.

معیارهای سمت سرور

هنگام اندازه‌گیری معیارهای سمت سرور مانند زمان تا اولین بایت (TTFB) ، مهم است که توجه داشته باشید که سایت شما فقط SXG را به خزنده‌هایی ارائه می‌دهد که قالب را می‌پذیرند. اندازه گیری خود را از TTFB به درخواست های کاربران واقعی محدود کنید، نه ربات ها. ممکن است متوجه شوید که تولید SXG باعث افزایش TTFB برای درخواست‌های خزنده می‌شود، اما این تاثیری بر تجربه بازدیدکنندگان شما ندارد.

معیارهای سمت مشتری

SXG ها بیشترین مزیت سرعت را برای معیارهای سمت مشتری، به ویژه LCP ایجاد می کنند. هنگام اندازه‌گیری تأثیر آن‌ها، می‌توانید به سادگی Cloudflare ASX را فعال کنید، منتظر بمانید تا دوباره توسط Googlebot خزیده شود، ۲۸ روز دیگر برای جمع‌آوری Core Web Vitals (CWV) صبر کنید و سپس به اعداد CWV جدید خود نگاه کنید. با این حال، زمانی که در میان سایر تغییرات در این بازه زمانی ترکیب شود، ممکن است تشخیص این تغییر دشوار باشد.

درعوض، «بزرگنمایی» بر روی بارگذاری‌های احتمالی تحت تأثیر صفحه را مفید می‌دانم و آن را به‌صورت قاب‌بندی می‌کنم که «SXG ها بر X درصد بازدیدهای صفحه تأثیر می‌گذارند و LCP آن‌ها را با Y میلی‌ثانیه در صدک ۷۵ بهبود می‌بخشند».

در حال حاضر، واکشی اولیه SXG فقط تحت شرایط خاصی انجام می شود:

• مرورگر Chromium (به عنوان مثال Chrome یا Edge به جز در iOS )، نسخه M98 یا بالاتر
• Referer: google.com یا سایر دامنه های جستجوی Google . (توجه داشته باشید که در Google Analytics، یک تگ ارجاع برای همه بازدیدهای صفحه در جلسه اعمال می شود، در حالی که واکشی اولیه SXG فقط برای نمای صفحه اول که مستقیماً از جستجوی Google پیوند داده شده است اعمال می شود.)

توجه: جستجوی Google در حال برنامه‌ریزی برای گسترش زمینه‌هایی است که می‌تواند واکشی اولیه SXG، از جمله سیستم‌عامل‌های دسکتاپ و موارد دیگر را در آن‌ها انجام دهد. این ممکن است X% را در طول زمان افزایش دهد، و همچنین به این معنی است که ممکن است بخواهید معیارهای خود را برای تطبیق با تغییر به روز کنید. وقتی این اتفاق افتاد، باید در webpackaging-announce اعلام شود.

بخش مطالعه معاصر را برای نحوه اندازه‌گیری «X% بازدیدهای صفحه» و «بهبود LCP آنها با Y میلی‌ثانیه» بخوانید.

مطالعه معاصر

هنگامی که به داده های نظارت واقعی کاربر (RUM) نگاه می کنید، باید بارهای صفحه را به SXG و غیر SXG تقسیم کنید. هنگام انجام این کار، ضروری است که مجموعه بارگیری صفحه را که به آن نگاه می کنید محدود کنید، بنابراین طرف غیر SXG با شرایط واجد شرایط بودن برای SXG مطابقت داشته باشد تا از سوگیری انتخاب جلوگیری شود. در غیر این صورت، تمام موارد زیر فقط در مجموعه بارگیری‌های صفحه غیر SXG وجود دارد که ممکن است LCP ذاتاً متفاوت باشد:

• دستگاه های iOS: به دلیل تفاوت در سخت افزار یا سرعت شبکه در بین کاربرانی که این دستگاه ها را دارند.
• مرورگرهای قدیمی Chromium: به همین دلایل.
• دستگاه‌های رومیزی: به دلایل مشابه یا به این دلیل که طرح‌بندی صفحه باعث می‌شود «بزرگ‌ترین عنصر» متفاوتی انتخاب شود.
• پیمایش‌های همان سایت (بازدیدکنندگانی که پیوندهای داخل سایت را دنبال می‌کنند): زیرا می‌توانند از منابع فرعی ذخیره‌شده در بارگذاری صفحه قبلی دوباره استفاده کنند.

در Google Analytics (UA)، دو بعد سفارشی با دامنه "Hit" ایجاد کنید ، یکی با نام "isSXG" و دیگری با نام "ارجاع کننده". (بعد داخلی "منبع" دارای محدوده جلسه است، بنابراین پیمایش های همان سایت را مستثنی نمی کند.)

یک بخش سفارشی به نام "SXG counterfactual" با فیلترهای زیر و در کنار هم ایجاد کنید:

• referrer با https://www.google.
• Browser دقیقاً با Chrome مطابقت دارد
• نسخه Browser با regex مطابقت دارد ^(9[8-9]|[0-9]{3})
• isSXG دقیقاً با false مطابقت دارد

یک کپی از این بخش به نام "SXG" ایجاد کنید، به جز اینکه با isSXG دقیقا مطابق true باشد.

در قالب سایت خود، قطعه زیر را بالای قطعه Google Analytics اضافه کنید. این یک نحو خاص است که ASX هنگام تولید یک SXG، false را به true تغییر می‌دهد:

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

اسکریپت گزارش Google Analytics خود را همانطور که برای ضبط LCP توصیه می شود سفارشی کنید. اگر از gtag.js استفاده می‌کنید، دستور 'config' را برای تنظیم ابعاد سفارشی تغییر دهید (به جای 'dimension1' و 'dimension2' با نام‌هایی که Google Analytics می‌گوید استفاده کنید):

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

اگر از analytics.js استفاده می‌کنید، دستور 'create' را همانطور که در اینجا مستند شده است ، تغییر دهید.

پس از چند روز انتظار برای جمع‌آوری برخی داده‌ها، به گزارش رویدادهای Google Analytics بروید و برای بخش SXG یک برنامه آموزشی اضافه کنید. این باید X را برای "SXG ها بر X٪ از بازدیدهای صفحه تاثیر می گذارد" پر کند:

در نهایت، به گزارش Web Vitals بروید، «Choose segments» را انتخاب کنید و «SXG counterfactual» و «SXG» را انتخاب کنید.

روی "ارسال" کلیک کنید و باید توزیع های LCP را برای دو بخش مشاهده کنید. این باید Y را برای "بهبود LCP آنها با Y میلی ثانیه در صدک 75" پر کند:

هشدارها

هنگامی که تمام فیلترهای فوق را اعمال کردید، بارگیری صفحه خلاف واقع SXG باید شامل موارد زیر باشد:

• Cache misss: اگر Google SXG Cache نسخه جدیدی از SXG برای یک URL خاص نداشته باشد، به URL اصلی در سایت شما هدایت می شود.
• سایر انواع نتایج: در حال حاضر، جستجوی Google فقط از SXG برای نتایج وب استاندارد و چند نوع دیگر پشتیبانی می کند. سایرین، مانند قطعه‌های ویژه و چرخ فلک داستان‌های برتر، به URL اصلی در سایت شما پیوند می‌دهند.
• URL های واجد شرایط: اگر برخی از صفحات سایت شما برای SXG واجد شرایط نیستند (مثلاً به دلیل اینکه قابل ذخیره نیستند)، می توانند در این مجموعه ظاهر شوند.

ممکن است بین بارگذاری صفحه SXG و مجموعه بالا از بارگیری‌های صفحه غیر SXG باقی‌مانده وجود داشته باشد، اما اندازه آن باید کمتر از سوگیری‌های ذکر شده در بالای بخش مطالعه معاصر باشد. برای مثال، شاید صفحات غیرقابل کش شما کندتر یا سریعتر از صفحات قابل کش شما هستند. اگر مشکوک هستید که ممکن است مشکلی باشد، به داده‌های محدود به یک نشانی اینترنتی واجد شرایط SXG نگاه کنید تا ببینید آیا نتایج آن با مطالعه کلی مطابقت دارد یا خیر.

اگر سایت شما دارای برخی صفحات AMP است، احتمالاً بهبود عملکرد را از فعال کردن SXG مشاهده نخواهند کرد، زیرا می‌توانند از قبل از جستجوی Google واکشی شوند. افزودن فیلتری برای حذف چنین صفحاتی، برای "بزرگنمایی" بیشتر روی تغییرات مربوطه را در نظر بگیرید.

در نهایت، حتی با پرداختن به همه سوگیری‌های انتخاب، این خطر وجود دارد که سوگیری بقا، بهبودهای LCP را شبیه به تخریب در آمار RUM کند. این مقاله کار بسیار خوبی برای توضیح این خطر انجام می‌دهد و پیشنهاد می‌کند برای تشخیص اینکه آیا این اتفاق می‌افتد یا خیر، به نوعی معیار رهاسازی نگاه کنید.

قبل / بعد از مطالعه

برای تأیید نتایج حاصل از مطالعه معاصر، ممکن است مقایسه LCP قبل و بعد از فعال کردن SXG مفید باشد. برای از بین بردن تعصبات بالقوه ذکر شده در بالا، به بازدیدهای صفحه SXG محدود نکنید. در عوض، به نتایج واجد شرایط SXG نگاه کنید - تعاریف بخش فوق اما بدون محدودیت isSXG .

توجه داشته باشید که جستجوی Google ممکن است چندین هفته طول بکشد تا همه صفحات سایت شما را مجدداً بررسی کند تا مشخص شود که SXG برای آنها فعال شده است. در این چند هفته، سوگیری های بالقوه دیگری ممکن است رخ دهد:

• انتشار جدید مرورگر یا بهبود سخت افزار کاربران ممکن است بارگذاری صفحه را افزایش دهد.
• یک رویداد مهم مانند تعطیلات ممکن است ترافیک را از حالت عادی منحرف کند.

همچنین برای تأیید مطالعات بالا، نگاهی به LCP صدک 75 کلی قبل و بعد از آن مفید است. یادگیری در مورد زیرمجموعه ای از جمعیت لزوماً به ما درباره کل جمعیت نمی گوید. به عنوان مثال، فرض کنید SXG 10 درصد از بارگذاری صفحه را 800 میلی ثانیه بهبود می بخشد.

• اگر اینها قبلاً 10٪ سریعترین بارگذاری صفحه بودند، آنگاه به هیچ وجه صدک 75 را تحت تأثیر قرار نمی دهد.
• اگر آنها 10٪ کندترین بارگذاری صفحه را داشتند، اما در ابتدا بیش از 800 میلی ثانیه از LCP صدک 75 کندتر بودند، آنگاه به هیچ وجه بر صدک 75 تأثیر نمی گذارد.

این‌ها نمونه‌های افراطی هستند که احتمالاً بازتابی از واقعیت نیستند، اما امیدواریم موضوع را نشان دهند. در عمل، این احتمال وجود دارد که SXG بر صدک 75 برای اکثر سایت ها تأثیر بگذارد. پیمایش‌های بین سایتی معمولاً کندترین هستند و پیشرفت‌های حاصل از واکشی اولیه قابل توجه است.

برخی از URL ها را انصراف دهید

در نهایت، یکی از راه‌های مقایسه عملکرد SXG می‌تواند غیرفعال کردن SXG برای برخی از زیرمجموعه‌های URL در سایت شما باشد. برای مثال، می‌توانید یک هدر CDN-Cache-Control: no-store را تنظیم کنید تا از تولید SXG توسط Cloudflare ASX جلوگیری کنید. من در برابر این توصیه می کنم.

احتمالاً خطر سوگیری انتخابی بیشتری نسبت به سایر روش‌های مطالعه دارد. به عنوان مثال، ممکن است تفاوت زیادی ایجاد کند که صفحه اصلی سایت شما یا یک URL محبوب مشابه در گروه کنترل یا گروه آزمایش انتخاب شود.

مطالعه عقب مانده

راه ایده آل برای اندازه گیری تأثیر، انجام یک مطالعه بازدارنده است. متأسفانه، در حال حاضر نمی توانید این نوع آزمایش را انجام دهید. ما در حال برنامه ریزی برای اضافه کردن پشتیبانی برای چنین آزمایشی در آینده هستیم.

یک مطالعه بازدارنده دارای ویژگی های زیر است:

• در گروه آزمایش، برخی از کسری تصادفی از بازدیدهای صفحه که SXG هستند ، "بازداشت" می شوند و به جای آن به عنوان غیر SXG ارائه می شوند. این امکان مقایسه «سیب به سیب» را بین کاربران، دستگاه‌ها، سناریوها و صفحات معادل می‌دهد.
• آن بازدیدهای صفحه عقب مانده (معروف به خلاف واقع) در تجزیه و تحلیل چنین برچسب زده می شود. این اجازه می دهد تا یک نمای "بزرگنمایی" از داده ها، که در آن ما می توانیم بارگذاری صفحه SXG در کنترل را با ضد واقعیت های SXG در آزمایش مقایسه کنیم. این به نوبه خود نویز ناشی از بارگذاری های دیگر صفحه را که تحت تأثیر پیش واکشی SXG قرار نمی گیرند، کاهش می دهد.

این امر منابع احتمالی سوگیری انتخاب را حذف می کند، اگرچه خطر سوگیری بقای LCP را از بین نمی برد. هر دوی این ویژگی ها برای فعال کردن به مرورگر یا ارجاع دهنده نیاز دارند.

نتیجه گیری

اوه! این خیلی بود. امیدواریم تصویر کامل تری از نحوه آزمایش عملکرد SXG در یک آزمایش آزمایشگاهی، نحوه بهینه سازی عملکرد آن در یک حلقه بازخورد فشرده با آزمایش آزمایشگاهی، و در نهایت نحوه اندازه گیری عملکرد آن در دنیای واقعی ارائه دهد. کنار هم قرار دادن همه اینها باید به شما کمک کند تا از SXG ها نهایت استفاده را ببرید و مطمئن شوید که آنها به نفع سایت و کاربران شما هستند.

اگر راهنمایی بیشتری در مورد نحوه ضبط عملکرد SXG دارید، لطفاً به ما اطلاع دهید! با بهبودهای پیشنهادی خود، یک اشکال را علیه developer.chrome.com ثبت کنید .

برای اطلاعات بیشتر در مورد مبادلات امضا شده، نگاهی به اسناد web.dev و اسناد جستجوی Google بیندازید.

،

نحوه اندازه‌گیری و بهینه‌سازی صرافی‌های امضا شده برای بهره‌مندی بیشتر از آنها

Devin Mullins

صرافی‌های امضا شده (SXGs) وسیله‌ای برای بهبود سرعت صفحه شما هستند - عمدتاً بزرگترین رنگ محتوایی (LCP) . هنگامی که سایت‌ها (جستجوی فعلی گوگل) به یک صفحه پیوند داده می‌شوند، می‌توانند قبل از اینکه کاربر روی پیوند کلیک کند، آن را در حافظه پنهان مرورگر واکشی کنند .

این امکان وجود دارد که صفحات وبی بسازید که وقتی از قبل واکشی می شوند، نیازی به شبکه ای در مسیر حیاتی رندر صفحه ندارند! در اتصال 4G، این بارگذاری صفحه از 2.8 ثانیه به 0.9 ثانیه می رسد (0.9 ثانیه باقیمانده بیشتر بر اساس استفاده از CPU است):

توجه: قبلاً این پست از 6s به 0.9s بهبود یافته بود. این درست بود، اما سایت مورد آزمایش در آن زمان به طور غیر معمول کند بود. با این حال، ممکن است به عنوان نمونه ای از صفحات با منابع فرعی بیشتر ، سرورهای کندتر ، یا کاربرانی با انواع اتصال کندتر عمل کند.

اکثر افرادی که امروز SXG را منتشر می‌کنند از ویژگی تبادلات امضا شده خودکار (ASX) با استفاده آسان Cloudflare استفاده می‌کنند (اگرچه گزینه‌های منبع باز نیز وجود دارد):

در بسیاری از موارد، علامت زدن کادر برای فعال کردن این ویژگی برای دریافت نوع بهبود قابل توجهی که در بالا نشان داده شده است کافی است. گاهی اوقات، چند مرحله دیگر برای اطمینان از عملکرد این SXGها در هر مرحله از خط لوله، و بهینه سازی صفحات برای استفاده کامل از واکشی اولیه وجود دارد.

در چند ماه گذشته پس از راه‌اندازی Cloudflare، من در حال مطالعه و پاسخ به سؤالات در انجمن‌های مختلف بوده‌ام و یاد گرفته‌ام که چگونه به سایت‌ها در مورد چگونگی اطمینان از اینکه آنها بیشترین بهره را از استقرار SXG خود می‌برند توصیه کنم. این پست مجموعه ای از توصیه های من است. من مراحل زیر را طی می کنم:

• عملکرد SXG را با استفاده از WebPageTest تجزیه و تحلیل کنید .
• اگر مرحله تجزیه و تحلیل نشان داد که خط لوله SXG کار نمی کند، اشکال زدایی کنید .
• صفحات را برای واکشی اولیه SXG از جمله تنظیم max-age بهینه و از پیش بارگذاری منابع فرعی مسدودکننده رندر بهینه کنید.
• با انتخاب گروه‌های آزمایش و کنترل مناسب، بهبود SXG را با استفاده از Google Analytics اندازه‌گیری کنید .

مقدمه

یک SXG یک فایل حاوی یک URL، مجموعه‌ای از سرصفحه‌های پاسخ HTTP، و بدنه پاسخ است—همه به صورت رمزنگاری شده توسط یک گواهی وب PKI امضا شده‌اند. هنگامی که مرورگر یک SXG را بارگذاری می کند، همه این موارد را تأیید می کند:

• SXG منقضی نشده است.
• امضا با URL، سرصفحه ها، بدنه و گواهی مطابقت دارد.
• گواهی معتبر است و با URL مطابقت دارد.

اگر تأیید ناموفق باشد، مرورگر SXG را رها می‌کند و در عوض URL امضا شده را واکشی می‌کند. اگر راستی‌آزمایی با موفقیت انجام شود، مرورگر پاسخ امضا شده را بارگیری می‌کند و با آن برخورد می‌کند که گویی مستقیماً از URL امضا شده آمده است. این به SXG ها اجازه می دهد تا زمانی که از زمان امضای امضا منقضی یا تغییر نکرده اند، روی هر سروری دوباره میزبانی شوند.

در مورد جستجوی گوگل، SXG واکشی اولیه صفحات را در نتایج جستجوی خود فعال می کند . برای صفحاتی که از SXGها پشتیبانی می‌کنند، جستجوی Google می‌تواند نسخه ذخیره‌شده خود از صفحه را که در webpkgcache.com میزبانی می‌شود، از قبل واکشی کند. این نشانی‌های اینترنتی webpkgcache.com بر نمایش یا رفتار صفحه تأثیری نمی‌گذارند، زیرا مرورگر به URL اصلی و امضا شده احترام می‌گذارد. واکشی اولیه می تواند صفحه شما را قادر به بارگیری بسیار سریعتر کند.

توجه: SXG ها به طور بالقوه برای موارد استفاده دیگر که در این مقاله پوشش داده نشده اند مفید هستند. برای مثال، آنها می‌توانند انعطاف‌پذیری اتصال را فعال کنند: یک برنامه چت می‌تواند پیوندی را که برای کاربر ارسال می‌شود، در صورتی که صفحه از SXG پشتیبانی می‌کند، از قبل دانلود کند، بنابراین آنها می‌توانند بعداً در حالت آفلاین آن را مشاهده کنند. این لیست بزرگتر از موارد استفاده بالقوه را ببینید.

تجزیه و تحلیل کنید

برای مشاهده مزایای SXG، با استفاده از ابزار آزمایشگاهی برای تجزیه و تحلیل عملکرد SXG در شرایط تکرارپذیر شروع کنید. می‌توانید از WebPageTest برای مقایسه آبشارها و LCP با و بدون واکشی اولیه SXG استفاده کنید.

احتیاط: نتایج آزمایشگاه ممکن است با تجربیات واقعی کاربر متفاوت باشد ، اما آنها ابزار مفیدی برای تشخیص مکان بهینه سازی و تکرار سریع هستند. نحوه اندازه گیری معیارهای کاربر واقعی حاصل را در بخش اندازه گیری پوشش خواهیم داد.

یک تست بدون SXG به شرح زیر ایجاد کنید:

• به WebPageTest بروید و وارد شوید. ورود به سیستم، سابقه آزمایش شما را برای مقایسه آسان‌تر در آینده ذخیره می‌کند.
• URL مورد نظر برای آزمایش را وارد کنید.
• به تنظیمات پیشرفته بروید. (شما برای تست SXG به تنظیمات پیشرفته نیاز دارید، بنابراین استفاده از آن در اینجا کمک می کند تا مطمئن شوید که گزینه های تست یکسان هستند.)
• در برگه تنظیمات تست ، تنظیم اتصال روی 4G و افزایش «تعداد آزمایش‌ها برای اجرا» به 7 ممکن است مفید باشد.
• روی Start Test کلیک کنید.

با استفاده از مراحل مشابه بالا، یک آزمایش با SXG ایجاد کنید، اما قبل از کلیک بر روی Start Test ، به برگه Script بروید، اسکریپت 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 ظاهر نشده است، می توانید از این صفحه واکشی اولیه برای ایجاد یک صفحه نتایج جستجوی وانمودی برای این منظور استفاده کنید.

برای تعیین نشانی وب navigate دوم، از صفحه خود با استفاده از برنامه افزودنی SXG Validator Chrome دیدن کنید و روی نماد برنامه افزودنی کلیک کنید تا URL حافظه پنهان را ببینید:

پس از تکمیل این تست ها، به Test History بروید، دو تست را انتخاب کنید و روی مقایسه کلیک کنید:

&medianMetric=LCP به URL مقایسه اضافه کنید تا WebPageTest اجرای با LCP میانه را برای هر طرف مقایسه انتخاب کند. (میانگین با شاخص سرعت است.)

برای مقایسه آبشارها، قسمت Waterfall Opacity را باز کرده و نوار لغزنده را بکشید. برای مشاهده ویدیو، روی Adjust Filmstrip Settings کلیک کنید، داخل آن گفتگو به پایین بروید و روی View Video کلیک کنید.

اگر Prefetch SXG موفقیت آمیز باشد ، خواهید دید که آبشار "با SXG" یک ردیف برای HTML را شامل نمی شود ، و واکشی های مربوط به منابع فرعی زودتر شروع می شود. به عنوان مثال ، "قبل" و "بعد" را در اینجا مقایسه کنید:

اشکال زدایی

اگر WebPagetest نشان دهد که SXG در حال پیش بینی است ، در تمام مراحل خط لوله موفق شده است. برای یادگیری چگونگی بهبود بیشتر LCP ممکن است به بخش Optimize بپردازید. در غیر این صورت ، باید بدانید که در خط لوله در کجا شکست خورده و چرا ؛ در ادامه بخوانید تا یاد بگیرید که چگونه.

انتشار

اطمینان حاصل کنید که صفحات شما به عنوان SXG تولید می شوند. برای انجام این کار ، شما باید وانمود کنید که خزنده هستید. ساده ترین راه استفاده از پسوند Chrome اعتبار سنج SXG است:

توجه: SXG ها برای خزنده های قابل دسترسی SXG ، برای فعال کردن پیش بینی در نظر گرفته شده اند. هنگامی که کاربران مستقیماً از سایت شما بازدید می کنند ، نباید SXGS را به آنها ارائه دهید ، زیرا آنها از قبل استفاده نمی شوند - انجام می شود بنابراین فقط به سربار اضافه می شود. CloudFlare ASX این مذاکره محتوا را بطور خودکار انجام می دهد.

پسوند 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 کمتر s-maxage 120 ، مگر

ASX در این موارد SXG ایجاد نمی کند زیرا SXGS ممکن است برای بازدید چندگانه و بازدید کنندگان متعدد مورد استفاده قرار گیرد.

یکی دیگر از دلایل احتمالی یک مارک متقاطع (❌ ❌) حضور یکی از این هدر پاسخهای مطرح است ، به جز Set-Cookie . ASX هدر Set-Cookie را برای مطابقت با مشخصات SXG حذف می کند.

توجه: این محدودیت ها را می توان با جزئیات بیشتری در کد ASX مشاهده کرد. به عنوان مثال ، هدرهای کنترل حافظه نهان توسط کدی بازرسی می شوند که تعیین می کند چه موقع امضا کنید و مدت زمان امضای باید باشد . سرنورهای دیگر قبل از امضای این پیکربندی یا توسط این کد حذف می شوند. هدر دیگر در صورت عدم انسجام از امضای جلوگیری می کنند .

یکی دیگر از دلایل احتمالی وجود یک هدر پاسخ Vary: Cookie است. GoogleBot SXGS را بدون اعتبار کاربر واگذار می کند و ممکن است آنها را به چندین بازدید کننده خدمت کند. اگر بر اساس کوکی آنها HTML مختلف را برای کاربران مختلف ارائه می دهید ، آنها می توانند یک تجربه نادرست مانند نمای ورود به سیستم را مشاهده کنند.

توجه: در آینده ، صفحات با استفاده از Vary: Cookie توسط SXG پشتیبانی می شود ، با این که فقط به بازدید کنندگان بدون کوکی برای سایت شما نشان داده می شود. این در Chromium اجرا می شود و پس از آن که به طور کاملتر از بین رفته است ، در جستجوی Google فعال می شود.

از طرف دیگر برای پسوند کروم ، می توانید از ابزاری مانند curl استفاده کنید:

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

یا dump-signedexchange :

dump-signedexchange -verify -uri $URL

اگر SXG موجود و معتبر باشد ، یک چاپ قابل خواندن از SXG را مشاهده خواهید کرد. در غیر این صورت با پیغام خطا مواجه خواهید شد.

نمایه سازی

اطمینان حاصل کنید که SXG های شما با موفقیت توسط Google Search فهرست بندی شده اند. Chrome Devtools را باز کنید ، سپس یک جستجوی Google را برای صفحه خود انجام دهید. اگر به عنوان SXG نمایه شده باشد ، پیوند Google به صفحه شما شامل یک data-sxg-url است که به نسخه WebPKGCache.com اشاره دارد:

اگر Google Search فکر کند کاربر احتمالاً روی نتیجه کلیک می کند ، آن را نیز پیش بینی می کند:

عنصر <link> به مرورگر دستور می دهد SXG را در حافظه نهان Prefetch خود بارگیری کند. هنگامی که کاربر روی عنصر <a> کلیک می کند ، مرورگر از آن SXG ذخیره شده برای ارائه صفحه استفاده می کند.

همچنین می توانید با مراجعه به برگه شبکه در DevTools و جستجوی URL های حاوی webpkgcache ، شواهدی از پیش نمایش را مشاهده کنید.

اگر <a> به webpkgcache.com اشاره کند ، این بدان معنی است که نمایه سازی جستجوی گوگل از مبادله امضا شده کار می کند. می توانید به بخش مصرف بروید.

در غیر این صورت ، این ممکن است که Google از زمانی که SXG را فعال کرده اید ، صفحه شما را دوباره جذب نکرده است. ابزار بازرسی URL کنسول جستجوی Google را امتحان کنید:

حضور digest: mi-sha256-03=... عنوان نشان می دهد که Google با موفقیت نسخه SXG را خزید.

اگر یک هدر digest وجود نداشته باشد ، این می تواند نشانگر این باشد که SXG به Googlebot ارائه نشده است یا اینکه از زمان فعال کردن SXGS این شاخص به روز نشده است.

اگر یک SXG با موفقیت خزیده شود ، اما هنوز به آن مرتبط نیست ، ممکن است عدم موفقیت در مورد نیازهای حافظه پنهان SXG باشد. اینها در بخش بعدی پوشانده شده است.

بلع

هنگامی که Google Search یک SXG را فهرست می کند ، نسخه خود را به حافظه نهان Google SXG ارسال می کند ، که آن را در برابر نیازهای حافظه پنهان تأیید می کند. پسوند کروم نتیجه را نشان می دهد:

اگر یک علامت چک (✅) را مشاهده می کنید ، می توانید برای بهینه سازی پیش بروید.

اگر نتواند الزامات را برآورده کند ، یک علامت متقاطع (❌) و یک پیام هشدار دهنده را مشاهده خواهید کرد که نشان می دهد چرا:

در این رویداد ، این صفحه دقیقاً مانند قبل از فعال کردن SXG کار خواهد کرد. Google بدون پیش نویس SXG به میزبان اصلی خود به صفحه پیوند خواهد داد.

در صورتی که نسخه ذخیره شده منقضی شده و در پس زمینه دوباره به دست می آید ، یک ساعت شنی (⌛) خواهید دید:

سند Google Developer در SXG همچنین دستورالعمل هایی را برای پرس و جو در حافظه نهان به صورت دستی دارد.

بهینه سازی کنید

اگر پسوند SXG اعتبار سنجی Chrome تمام علائم چک (✅) را نشان می دهد ، شما یک SXG دارید که می تواند به کاربران ارائه شود! در ادامه بخوانید تا نحوه بهینه سازی صفحه وب خود را پیدا کنید تا بیشترین پیشرفت LCP را از SXG بدست آورید.

حداکثر سن

هنگامی که SXGS منقضی می شود ، حافظه نهان Google SXG یک نسخه جدید را در پس زمینه بدست می آورد. در حالی که منتظر آن واکشی هستید ، کاربران در میزبان اصلی خود به صفحه هدایت می شوند که از پیش تعیین نشده است. هرچه مدت زمان Cache-Control: max-age ، این کار پس زمینه کمتر اتفاق می افتد ، و بنابراین بیشتر اوقات که LCP را می توان با پیش تنظیم کاهش داد.

این یک تجارت بین عملکرد و طراوت است ، و حافظه نهان به صاحبان سایت اجازه می دهد تا SXG ها را در هر نقطه بین 2 دقیقه تا 7 روز به SXG ارائه دهند تا نیازهای خاص هر صفحه را متناسب کند. به طور غیرقانونی ، ما می دانیم که:

• max-age=86400 (1 روز) یا طولانی تر برای عملکرد خوب کار می کند
• max-age=120 (2 دقیقه) این کار را نمی کند

ما امیدواریم که اطلاعات بیشتری در مورد ارزش ها بین آن دو کسب کنیم ، زیرا داده ها را بیشتر مطالعه می کنیم.

توجه: ما قصد داریم با اضافه کردن یک API Cache Purge ، این تجارت را در آینده آسانتر کنیم. آن را در WebPackaging-Ennound اعلام می شود.

عامل کاربر

یک بار ، من دیدم که LCP هنگام استفاده از SXG از پیش تنظیم شده افزایش می یابد . من WebPagetest را اجرا کردم ، و نتایج متوسط ​​را بدون و با SXG Prefetch مقایسه کردم. با کلیک بر روی زیر:

من دیدم که پیش نویس کار می کند. HTML از مسیر بحرانی برداشته می شود و بنابراین ، تمام منابع فرعی قادر به بارگیری زودتر هستند. اما LCP - آن خط شکسته سبز - از 2s به 2.1s افزایش یافته است .

برای تشخیص این موضوع ، به نوارهای فیلم نگاه کردم. فهمیدم که این صفحه در SXG متفاوت است. در HTML ساده ، Chrome مشخص کرد که "بزرگترین عنصر" برای LCP تیتر است. با این حال ، در نسخه SXG ، این صفحه یک پرچم تنبل را اضافه کرده است که تیتر را در زیر برابر قرار داده و باعث شده بزرگترین عنصر جدید گفتگوی رضایت کوکی تنبل باشد. همه چیز سریعتر از گذشته ارائه می شود ، اما تغییر در طرح باعث شد تا متریک آن را کندتر گزارش دهد.

من عمیق تر حفر کردم و متوجه شدم که دلیل تفاوت در طرح این است که صفحه از نظر User-Agent متفاوت است و در منطق خطایی رخ داده است. این در حال خدمت به یک صفحه دسک تاپ بود حتی اگر عنوان SXG Crawl نشان دهنده موبایل باشد. پس از این امر برطرف شد ، مرورگر به طور صحیح عنوان صفحه را به عنوان بزرگترین عنصر خود معرفی کرد.

اکنون ، با کلیک بر روی "بعد" ، دیدم که LCP از پیش تنظیم شده به 1.3s کاهش می یابد :

SXG برای همه عوامل شکل فعال است. برای آماده سازی برای آن ، اطمینان حاصل کنید که یکی از این موارد صحیح است:

• صفحه شما با توجه به User-Agent Vary نیست (به عنوان مثال از طراحی پاسخگو یا URL های موبایل/دسک تاپ جداگانه استفاده می کند).
• اگر صفحه شما از سرویس پویا استفاده می کند ، خود را به عنوان موبایل یا دسک تاپ فقط با استفاده از <meta name=supported-media content=...> حاشیه نویسی می کند.

منابع فرعی

SXG ها را می توان برای پیش بینی منابع زیر (از جمله تصاویر) به همراه HTML استفاده کرد. CloudFlare ASX HTML را برای عناصر همان منبعی (شخص اول) <link rel=preload> اسکن می کند و آنها را به عنوان های پیوند سازگار با SXG تبدیل می کند. جزئیات موجود در کد منبع در اینجا و اینجا .

اگر در حال کار باشد ، پیش نمایش های اضافی را از Google Search مشاهده خواهید کرد:

برای بهینه سازی LCP ، از نزدیک به آبشار خود نگاه کنید و بفهمید که کدام منابع در مسیر بحرانی برای ارائه بزرگترین عنصر قرار دارند. اگر آنها نمی توانند از قبل استفاده شوند ، در نظر بگیرید که آیا می توان آنها را از مسیر بحرانی خارج کرد . در جستجوی اسکریپت هایی باشید که صفحه را پنهان می کنند تا اینکه بارگیری شود.

حافظه نهان Google SXG اجازه می دهد تا حداکثر 20 منبع زیر بار را از پیش بارگیری کند و ASX تضمین می کند که از این حد فراتر نرود. با این حال ، در افزودن بیش از حد بسیاری از پیشروهای زیر منبع خطر وجود دارد. مرورگر فقط در صورت تمام شدن تمام آنها به منظور جلوگیری از ردیابی سایت ، فقط از منابع از پیش بارگذاری شده استفاده می کند. هرچه منابع فرعی بیشتر وجود داشته باشد ، احتمالاً قبل از کلیک کاربر به صفحه شما ، همه آنها پیش نمایش را تمام می کنند.

توجه: ASX در حال حاضر فقط از پیش فرض برای منابع مشابه (شخص اول) پشتیبانی می کند. اگر از ارائه دهندگان Subresource شخص ثالث که از SXG پشتیبانی می کنند ، می دانید ، در مورد این اشکال به ما اطلاع دهید تا بتوانیم در اولویت اضافه کردن پشتیبانی از منشاء متقابل قرار بگیریم.

اعتبار سنج SXG در حال حاضر منابع زیر را بررسی نمی کند. برای اشکال زدایی ، در ضمن از curl یا dump-signedexchange استفاده کنید.

اندازه گیری کنید

پس از بهینه سازی بهبود LCP تحت WebPagetEst ، اندازه گیری تأثیر پیش بینی SXG بر عملکرد کلی سایت شما مفید است.

معیارهای سمت سرور

هنگام اندازه گیری معیارهای سمت سرور مانند Time to First Byte (TTFB) ، توجه به این نکته مهم است که سایت شما فقط به SXGS خدمت می کند تا خزنده هایی را بپذیرند که فرمت را می پذیرند. اندازه گیری TTFB خود را به درخواست های حاصل از کاربران واقعی محدود کنید و نه ربات ها. ممکن است متوجه شوید که تولید SXG TTFB را برای درخواست های خزنده افزایش می دهد ، اما این هیچ تاثیری در تجربه بازدید کنندگان شما ندارد.

معیارهای سمت مشتری

SXG ها بیشترین سود را برای معیارهای سمت مشتری ، به ویژه LCP تولید می کنند. هنگام اندازه گیری تأثیر آنها ، می توانید به سادگی CloudFlare ASX را فعال کنید ، منتظر بمانید که توسط GoogleBot دوباره ریخته شود ، 28 روز دیگر برای جمع آوری اصلی وب (CWV) صبر کنید و سپس به شماره های جدید CWV خود نگاه کنید. با این حال ، ممکن است تغییر در هنگام مخلوط شدن در بین سایر تغییرات دیگر در این بازه زمانی دشوار باشد.

درعوض ، من می دانم که "بزرگنمایی" در بارهای صفحه بالقوه آسیب دیده مفید است ، و آن را به عنوان "SXG ها تأثیر می گذارد ، روی X ٪ از نماهای صفحه تأثیر می گذارد و LCP خود را توسط y milliseconds در صدک 75 بهبود می بخشد."

در حال حاضر ، PREFETCH SXG فقط در شرایط خاصی اتفاق می افتد:

• مرورگر Chromium (به عنوان مثال کروم یا لبه به جز در iOS ) ، نسخه M98 یا بالاتر
• Referer: google.com یا سایر دامنه های جستجوی Google . (توجه داشته باشید که در Google Analytics ، یک برچسب ارجاع در مورد کلیه دیدگاه های صفحه در جلسه اعمال می شود ، در حالی که Prefetch SXG فقط در مورد صفحه اول ، که مستقیماً از جستجوی Google مرتبط است ، اعمال می شود.)

توجه: Google Search در حال برنامه ریزی برای گسترش زمینه هایی است که در آن می تواند پیش تنظیم SXG از جمله سیستم عامل های رومیزی و موارد دیگر رخ دهد. این ممکن است X ٪ را با گذشت زمان افزایش دهد ، و همچنین به این معنی است که شما ممکن است بخواهید معیارهای خود را به روز کنید تا این تغییر را در خود جای دهد. وقتی این اتفاق بیفتد ، باید در Web-Packaging-Ennound اعلام شود.

بخش مطالعه معاصر را برای چگونگی اندازه گیری "x ٪ از نماهای صفحه" و "بهبود LCP آنها توسط y milliseconds" بخوانید.

مطالعه معاصر

هنگام نگاه به داده های نظارت واقعی کاربر (RUM) ، باید بارهای صفحه را به SXG و غیر SXG تقسیم کنید. هنگام انجام این کار ، محدود کردن مجموعه بارهای صفحه ای که به آنها نگاه می کنید ، ضروری است ، بنابراین طرف غیر SXG با شرایط واجد شرایط بودن SXG مطابقت دارد تا از انتخاب تعصب جلوگیری شود. در غیر این صورت ، همه موارد زیر فقط در مجموعه بارهای صفحه غیر SXG وجود دارد ، که ممکن است LCP ذاتی متفاوت داشته باشد:

• دستگاه های iOS: به دلیل تفاوت در سخت افزار یا سرعت شبکه در بین کاربرانی که این دستگاه ها را دارند.
• مرورگرهای قدیمی کروم: به همین دلایل.
• دستگاه های دسک تاپ: به همین دلایل یا به دلیل اینکه طرح صفحه باعث می شود "بزرگترین عنصر" متفاوت انتخاب شود.
• ناوبری های همان سایت (بازدید کنندگان زیر پیوندها در سایت): زیرا آنها می توانند از منابع ذخیره شده ذخیره شده از بار صفحه قبلی استفاده مجدد کنند.

در Google Analytics (UA) ، دو بعد سفارشی با دامنه "ضربه" ، یکی به نام "ISSXG" و دیگری به نام "ارجاع" ایجاد کنید . (ابعاد داخلی "منبع" دارای دامنه جلسه است ، بنابراین ناوبری های همان سایت را حذف نمی کند.)

یک بخش سفارشی به نام "SXG Counterfactual" با فیلترهای زیر و با هم ایجاد کنید:

• referrer با https://www.google.
• Browser دقیقاً با Chrome مطابقت دارد
• نسخه Browser با regex ^(9[8-9]|[0-9]{3})
• isSXG دقیقاً false مطابقت دارد

یک کپی از این بخش با نام "SXG" ایجاد کنید ، مگر با isSXG دقیقاً true دارد.

در الگوی سایت خود ، قطعه زیر را در بالای قطعه Google Analytics اضافه کنید. این یک نحو خاص است که ASX هنگام تولید SXG false را به true تغییر می دهد:

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

اسکریپت گزارشگری Google Analytics خود را مطابق توصیه برای ضبط LCP سفارشی کنید. اگر از gtag.js استفاده می کنید ، دستور 'config' را برای تنظیم ابعاد سفارشی (جایگزینی 'dimension1' و 'dimension2' با نام هایی که Google Analytics می گوید از آن استفاده کنید) تغییر دهید:

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

اگر از Analytics.js استفاده می کنید ، دستور 'create' را همانطور که در اینجا مستند شده است تغییر دهید.

پس از چند روز انتظار برای جمع آوری برخی از داده ها ، به گزارش رویدادهای Google Analytics بروید و یک حفاری برای بخش SXG اضافه کنید. این باید X را برای "SXGS تأثیر X ٪ از صفحه نمایش" پر کند:

در آخر ، به گزارش وب ویتامز بروید ، "SELECT SECTIONS" را انتخاب کنید و "SXG Counterfactual" و "SXG" را انتخاب کنید.

روی "ارسال" کلیک کنید ، و باید توزیع LCP را برای دو بخش مشاهده کنید. این باید Y را برای "بهبود LCP آنها توسط y milliseconds در صدک 75" پر کند:

هشدارها

پس از استفاده از تمام فیلترهای فوق ، بارهای صفحه Counterfactual SXG باید شامل مواردی از این دست باشد:

• حافظه پنهان: اگر Google SXG Cache نسخه تازه ای از SXG را برای URL مشخص نداشته باشد ، به URL اصلی در سایت شما هدایت می شود.
• انواع دیگر نتیجه: در حال حاضر ، جستجوی Google فقط از SXG برای نتایج وب استاندارد و چند نوع دیگر پشتیبانی می کند. برخی دیگر ، مانند قطعه های برجسته و Carousel داستانهای برتر ، به URL اصلی در سایت شما پیوند می خورند.
• URL های غیر واجد شرایط: اگر برخی از صفحات در سایت شما واجد شرایط SXG نیستند (به عنوان مثال زیرا آنها قابل ذخیره نیستند) ، می توانند در این مجموعه ظاهر شوند.

ممکن است بین بارهای صفحه SXG و مجموعه فوق از بارهای غیر SXG تعصب باقی بماند ، اما باید از نظر بزرگی از تعصبات ذکر شده در بالای بخش مطالعه معاصر کوچکتر باشد. به عنوان مثال ، شاید صفحات غیر قابل استفاده شما کندتر یا سریعتر از صفحات ذخیره شما باشد. اگر گمان می کنید که این مسئله می تواند یک مسئله باشد ، به بررسی داده های محدود به یک URL خاص SXG واجد شرایط توجه کنید تا ببینید که آیا نتایج آن با مطالعه کلی مطابقت دارد یا خیر.

اگر سایت شما دارای برخی از صفحات AMP است ، احتمالاً آنها پیشرفت های عملکرد را از فعال کردن SXG نمی بینند ، زیرا می توان آنها را از جستجوی Google پیش بینی کرد. برای حذف چنین صفحات ، برای "بزرگنمایی" بیشتر در مورد تغییرات مربوطه ، یک فیلتر را اضافه کنید.

سرانجام ، حتی به پرداختن به همه تعصبات انتخاب ، این خطر وجود دارد که تعصب بقاء باعث می شود پیشرفت های LCP مانند تخریب در آمار رم به نظر برسد. در این مقاله کار بسیار خوبی برای توضیح این خطر انجام می شود و پیشنهاد می کند که به نوعی متریک متروکه نگاه کنید تا تشخیص دهد که آیا این اتفاق می افتد.

قبل/بعد از مطالعه

برای تأیید نتایج حاصل از مطالعه معاصر ، ممکن است انجام مقایسه LCP قبل و بعد از فعال کردن SXG مفید باشد. برای از بین بردن تعصبات احتمالی ذکر شده در بالا ، به نماهای صفحه SXG محدود نکنید. در عوض ، به نتایج واجد شرایط SXG نگاه کنید-تعاریف بخش فوق اما بدون محدودیت isSXG .

توجه داشته باشید که جستجوی Google ممکن است تا چند هفته طول بکشد تا تمام صفحات موجود در سایت شما را بازسازی کند تا مشخص شود که SXG برای آنها فعال شده است. در آن چند هفته ، تعصبات بالقوه دیگری نیز وجود دارد که ممکن است رخ دهد:

• انتشار یا پیشرفت های جدید در سخت افزار کاربران ممکن است بارهای صفحه را سرعت بخشد.
• یک رویداد مهم مانند تعطیلات ممکن است ترافیک از حالت عادی را کاهش دهد.

همچنین برای تأیید مطالعات فوق ، بررسی کل LCP صدک 75 درصد قبل و بعد از آن مفید است. یادگیری در مورد زیر مجموعه ای از جمعیت لزوماً در مورد جمعیت کلی به ما نمی گوید. به عنوان مثال ، بیایید بگوییم SXG 10 ٪ از بارهای صفحه را 800ms بهبود می بخشد.

• اگر این موارد در حال حاضر 10 ٪ سریعترین بارهای صفحه بودند ، به هیچ وجه روی صدک 75 تأثیر نمی گذارد.
• اگر آنها 10 ٪ کمترین بارهای صفحه بودند ، اما آنها بیش از 800 متر کندتر از LCP صدک 75 بودند که از ابتدا شروع می شوند ، به هیچ وجه روی صدک 75 تأثیر نمی گذارد.

اینها نمونه های شدید هستند ، احتمالاً منعکس کننده واقعیت نیستند ، اما امیدوارم موضوع را نشان دهد. در عمل ، این احتمال وجود دارد که SXG برای اکثر سایت ها روی صدک 75 تأثیر بگذارد. ناوبری های متقاطع تمایل به کمترین سرعت دارند و پیشرفت های پیش از پیش بینی قابل توجه است.

برخی از URL ها را امتناع کنید

سرانجام ، یکی از راه های مقایسه عملکرد SXG می تواند غیرفعال کردن SXG برای برخی از زیر مجموعه های URL در سایت شما باشد. به عنوان مثال ، شما می توانید یک CDN-Cache-Control: no-store برای جلوگیری از تولید SXG CloudFlare ASX. من در برابر این توصیه می کنم.

احتمالاً خطر بیشتری برای تعصب انتخاب نسبت به سایر روشهای مطالعه دارد. به عنوان مثال ، ممکن است تفاوت بزرگی ایجاد کند که آیا صفحه اصلی سایت شما یا یک URL مشابه محبوب در گروه کنترل یا گروه آزمایش انتخاب شده است.

مطالعه نگهدارنده

روش ایده آل برای اندازه گیری تأثیر ، انجام یک مطالعه نگهدارنده است. متأسفانه ، شما در حال حاضر نمی توانید این نوع تست را انجام دهید. ما قصد داریم در آینده از چنین آزمایشی پشتیبانی کنیم.

یک مطالعه نگهدارنده دارای خواص زیر است:

• در گروه آزمایش ، برخی از بخش های تصادفی از دیدگاه های صفحه که SXG "عقب نگه داشته می شود" است ، و به جای آن به عنوان غیر SXG خدمت می کنند. این امر امکان مقایسه "سیب به نمونه" بین کاربران معادل ، دستگاه ها ، سناریوها و صفحات را فراهم می کند.
• نمایش های صفحه نگهدارنده (با نام مستعار پیشخوان) در تجزیه و تحلیل ها به این ترتیب برچسب گذاری شده اند. این امکان را برای نمایش "بزرگنمایی" از داده ها فراهم می کند ، جایی که می توانیم بارهای صفحه SXG را در کنترل با Counterfactuals SXG در آزمایش مقایسه کنیم. این به نوبه خود ، نویز را از بارهای صفحه دیگر که تحت تأثیر Prefetch SXG قرار نمی گیرند ، کاهش می دهد.

این امر می تواند منابع احتمالی فوق الذکر تعصب انتخاب را از بین ببرد ، اگرچه خطر تعصب زنده ماندن LCP را از بین نمی برد. هر دوی این خصوصیات برای فعال کردن به مرورگر یا مراجعه کننده نیاز دارند.

نتیجه گیری

اوه! این خیلی بود. امیدوارم این تصویر کامل تر از نحوه تست عملکرد SXG در یک آزمایشگاه ، نحوه بهینه سازی عملکرد آن در یک حلقه بازخورد محکم با آزمایش آزمایشگاه و در آخر نحوه اندازه گیری عملکرد آن در دنیای واقعی باشد. کنار هم قرار دادن همه اینها باید به شما کمک کند تا از SXG ها بیشترین استفاده را کنید و اطمینان حاصل کنید که آنها از سایت و کاربران شما بهره مند می شوند.

اگر مشاوره دیگری در مورد نحوه ضبط عملکرد SXG دارید ، لطفاً به ما اطلاع دهید! با پیشرفتهای پیشنهادی خود ، اشکال علیه Developer.Chrome.com را ارائه دهید .

برای اطلاعات بیشتر در مورد مبادلات امضا شده ، به مستندات Web.dev و مستندات جستجوی Google نگاهی بیندازید.

،

نحوه اندازه گیری و بهینه سازی مبادلات امضا شده برای به دست آوردن بیشترین پیشرفت از آنها

Devin Mullins

مبادلات امضا شده (SXG) وسیله ای برای بهبود سرعت صفحه شما است - بسیار بزرگترین رنگ محتوا (LCP) . هنگام مراجعه به سایت ها (در حال حاضر جستجوی Google) به یک صفحه ، می توانند قبل از کلیک کاربر روی پیوند ، آن را در حافظه نهان مرورگر قرار دهند .

ساخت صفحات وب ممکن است که در صورت پیش بینی ، هیچ شبکه ای در مسیر بحرانی برای ارائه صفحه نیازی به شبکه ای نداشته باشد! در یک اتصال 4G ، این بار صفحه از 2.8s به 0.9s می رود (0.9s باقیمانده بیشتر توسط CPU است):

توجه: پیش از این ، این پست بهبودی از 6s به 0.9s را نشان می داد. این درست بود ، اما سایت تحت آزمایش در آن زمان به طور غیرعادی کند بود. با این وجود ، این ممکن است به عنوان نمونه نمونه از صفحات با منابع فرعی بیشتر ، سرورهای کندتر یا کاربران با انواع اتصال آهسته تر باشد.

امروزه اکثر افرادی که SXG ها را منتشر می کنند از ویژگی های Eash Automatic Exchange (ASX) با کاربرد آسان CloudFlare استفاده می کنند (اگرچه گزینه های منبع باز نیز وجود دارند):

در بسیاری از موارد ، بررسی جعبه برای فعال کردن این ویژگی برای به دست آوردن نوع پیشرفت قابل توجهی که در بالا نشان داده شده است ، کافی است. بعضی اوقات ، چند مرحله دیگر برای اطمینان از کار این SXG ها در هر مرحله از خط لوله و بهینه سازی صفحات برای استفاده کامل از Prefetch وجود دارد.

در دو ماه گذشته از زمان راه اندازی Cloudflare ، من در حال خواندن و پاسخ دادن به سؤالات مربوط به انجمن های مختلف و یادگیری نحوه مشاوره سایت ها در مورد چگونگی اطمینان از کسب بیشترین استفاده از استقرار SXG خود هستم. این پست مجموعه ای از توصیه های من است. من مراحل را طی می کنم:

• عملکرد SXG را با استفاده از WebPagetest تجزیه و تحلیل کنید .
• اگر مرحله تحلیل نشان می دهد که کار نمی کند ، خط لوله SXG را اشکال زد .
• بهینه سازی صفحات برای پیش فرض SXG از جمله تنظیم زیر مجموعه های max-age و پیش بارگذاری رندر مسدود کننده.
• با انتخاب گروه های آزمایش و کنترل مناسب ، بهبود SXG را با استفاده از Google Analytics اندازه گیری کنید .

مقدمه

SXG پرونده ای است که حاوی URL ، مجموعه ای از هدرهای پاسخ HTTP و یک بدنه پاسخ است - همه رمزنگاری شده توسط یک گواهی Web PKI امضا شده است. هنگامی که مرورگر SXG را بارگیری می کند ، همه اینها را تأیید می کند:

• SXG منقضی نشده است.
• امضا با URL ، هدرها ، بدنه و گواهی مطابقت دارد.
• گواهی معتبر است و با URL مطابقت دارد.

در صورت عدم موفقیت ، مرورگر SXG را رها می کند و در عوض URL امضا شده را واکشی می کند. اگر تأیید موفقیت آمیز باشد ، مرورگر پاسخ امضا شده را بارگیری می کند ، و آن را به گونه ای درمان می کند که گویی مستقیماً از URL امضا شده آمده است. این اجازه می دهد تا SXGS تا زمانی که از زمان امضاء منقضی یا اصلاح نشده باشد ، دوباره در هر سرور مجدداً مورد استفاده قرار گیرد.

در مورد جستجوی Google ، SXG پیش بینی صفحات را در نتایج جستجوی خود امکان پذیر می کند . برای صفحات پشتیبانی از SXG ها ، Google Search می تواند نسخه ذخیره شده خود را از صفحه ، میزبانی شده در WebPKGCache.com ، پیش بینی کند. این URL های webpkgcache.com بر صفحه نمایش یا رفتار صفحه تأثیر نمی گذارد ، زیرا مرورگر به URL اصلی و امضا شده احترام می گذارد. پیش بینی می تواند صفحه شما را قادر به بارگیری سریعتر کند.

توجه: SXG ها برای سایر موارد استفاده در این مقاله به طور بالقوه مفید هستند. به عنوان مثال ، آنها می توانند انعطاف پذیری اتصال را فعال کنند: یک برنامه گپ می تواند پیوندی را که در صورت پشتیبانی از SXG به کاربر ارسال می شود ، بارگیری کند ، بنابراین آنها می توانند بعداً در صورت آفلاین آن را مشاهده کنند. این لیست بزرگتر از موارد استفاده بالقوه را مشاهده کنید.

تجزیه و تحلیل کنید

برای دیدن فواید SXGS ، با استفاده از یک ابزار آزمایشگاهی برای تجزیه و تحلیل عملکرد SXG در شرایط قابل تکرار شروع کنید. شما می توانید از WebPagetest برای مقایسه آبشارها و LCP با و بدون پیش بینی SXG استفاده کنید.

احتیاط: نتایج آزمایشگاه ممکن است با تجربیات واقعی کاربر متفاوت باشد ، اما آنها ابزاری مفید برای تشخیص مکان بهینه سازی و تکرار سریع هستند. ما نحوه اندازه گیری معیارهای کاربر واقعی حاصل در بخش اندازه گیری را پوشش خواهیم داد.

آزمایش بدون SXG را به شرح زیر ایجاد کنید:

• به WebPagetest بروید و وارد سیستم شوید. ثبت نام در تاریخ آزمون خود را برای مقایسه آسانتر بعداً ذخیره می کند.
• URL مورد نظر خود را وارد کنید.
• به پیکربندی پیشرفته بروید. (برای تست SXG به پیکربندی پیشرفته نیاز خواهید داشت ، بنابراین استفاده از آن در اینجا به اطمینان از گزینه های آزمایش یکسان است.)
• در برگه تنظیمات تست ، ممکن است برای تنظیم اتصال به 4G و افزایش "تعداد تست ها برای اجرای" به 7 مفید باشد.
• روی تست شروع کلیک کنید.

با استفاده از همان مراحل فوق ، یک آزمایش با SXG ایجاد کنید ، اما قبل از کلیک بر روی تست Start ، به برگه اسکریپت بروید ، در اسکریپت 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 ظاهر نمی شود ، می توانید از این صفحه Prefetch برای تولید صفحه نتایج جستجوی وانمود برای این منظور استفاده کنید.

برای تعیین URL دوم navigate ، با استفاده از برنامه افزودنی SXG Validator Chrome به صفحه خود مراجعه کرده و برای دیدن URL حافظه پنهان روی نماد پسوند کلیک کنید:

پس از اتمام این تست ها ، به تاریخچه آزمون بروید ، دو تست را انتخاب کنید و روی مقایسه کلیک کنید:

Adpend &medianMetric=LCP به URL مقایسه ، بنابراین WebPagetest اجرای را با Median LCP برای هر طرف از مقایسه انتخاب می کند. (پیش فرض از نظر شاخص سرعت متوسط ​​است.)

برای مقایسه آبشارها ، بخش کدورت آبشار را گسترش داده و کشویی را بکشید. برای مشاهده ویدیو ، روی تنظیمات تنظیمات FilmStrip کلیک کنید ، در داخل آن گفتگو حرکت کنید و روی View Video کلیک کنید.

اگر Prefetch SXG موفقیت آمیز باشد ، خواهید دید که آبشار "با SXG" یک ردیف برای HTML را شامل نمی شود ، و واکشی های مربوط به منابع فرعی زودتر شروع می شود. به عنوان مثال ، "قبل" و "بعد" را در اینجا مقایسه کنید:

اشکال زدایی

اگر WebPagetest نشان دهد که SXG در حال پیش بینی است ، در تمام مراحل خط لوله موفق شده است. برای یادگیری چگونگی بهبود بیشتر LCP ممکن است به بخش Optimize بپردازید. در غیر این صورت ، باید بدانید که در خط لوله در کجا شکست خورده و چرا ؛ در ادامه بخوانید تا یاد بگیرید که چگونه.

انتشار

اطمینان حاصل کنید که صفحات شما به عنوان SXG تولید می شوند. برای انجام این کار ، شما باید وانمود کنید که خزنده هستید. ساده ترین راه استفاده از پسوند Chrome اعتبار سنج SXG است:

توجه: SXG ها برای خزنده های قابل دسترسی SXG ، برای فعال کردن پیش بینی در نظر گرفته شده اند. هنگامی که کاربران مستقیماً از سایت شما بازدید می کنند ، نباید SXGS را به آنها ارائه دهید ، زیرا آنها از قبل استفاده نمی شوند - انجام می شود بنابراین فقط به سربار اضافه می شود. CloudFlare ASX این مذاکره محتوا را بطور خودکار انجام می دهد.

پسوند 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 کمتر s-maxage 120 ، مگر

ASX در این موارد SXG ایجاد نمی کند زیرا SXGS ممکن است برای بازدید چندگانه و بازدید کنندگان متعدد مورد استفاده قرار گیرد.

یکی دیگر از دلایل احتمالی یک مارک متقاطع (❌ ❌) حضور یکی از این هدر پاسخهای مطرح است ، به جز Set-Cookie . ASX هدر Set-Cookie را برای مطابقت با مشخصات SXG حذف می کند.

توجه: این محدودیت ها را می توان با جزئیات بیشتری در کد ASX مشاهده کرد. به عنوان مثال ، هدرهای کنترل حافظه نهان توسط کدی بازرسی می شوند که تعیین می کند چه موقع امضا کنید و مدت زمان امضای باید باشد . سرنورهای دیگر قبل از امضای این پیکربندی یا توسط این کد حذف می شوند. هدر دیگر در صورت عدم انسجام از امضای جلوگیری می کنند .

یکی دیگر از دلایل احتمالی وجود یک هدر پاسخ Vary: Cookie است. GoogleBot SXGS را بدون اعتبار کاربر واگذار می کند و ممکن است آنها را به چندین بازدید کننده خدمت کند. اگر بر اساس کوکی آنها HTML مختلف را برای کاربران مختلف ارائه می دهید ، آنها می توانند یک تجربه نادرست مانند نمای ورود به سیستم را مشاهده کنند.

توجه: در آینده ، صفحات با استفاده از Vary: Cookie توسط SXG پشتیبانی می شود ، با این که فقط به بازدید کنندگان بدون کوکی برای سایت شما نشان داده می شود. این در Chromium اجرا می شود و پس از آن که به طور کاملتر از بین رفته است ، در جستجوی Google فعال می شود.

از طرف دیگر برای پسوند کروم ، می توانید از ابزاری مانند curl استفاده کنید:

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

یا dump-signedexchange :

dump-signedexchange -verify -uri $URL

اگر SXG موجود و معتبر باشد ، یک چاپ قابل خواندن از SXG را مشاهده خواهید کرد. در غیر این صورت با پیغام خطا مواجه خواهید شد.

نمایه سازی

اطمینان حاصل کنید که SXG های شما با موفقیت توسط Google Search فهرست بندی شده اند. Chrome Devtools را باز کنید ، سپس یک جستجوی Google را برای صفحه خود انجام دهید. اگر به عنوان SXG نمایه شده باشد ، پیوند Google به صفحه شما شامل یک data-sxg-url است که به نسخه WebPKGCache.com اشاره دارد:

اگر Google Search فکر کند کاربر احتمالاً روی نتیجه کلیک می کند ، آن را نیز پیش بینی می کند:

عنصر <link> به مرورگر دستور می دهد SXG را در حافظه نهان Prefetch خود بارگیری کند. هنگامی که کاربر روی عنصر <a> کلیک می کند ، مرورگر از آن SXG ذخیره شده برای ارائه صفحه استفاده می کند.

همچنین می توانید با مراجعه به برگه شبکه در DevTools و جستجوی URL های حاوی webpkgcache ، شواهدی از پیش نمایش را مشاهده کنید.

اگر <a> به webpkgcache.com اشاره کند ، این بدان معنی است که نمایه سازی جستجوی گوگل از مبادله امضا شده کار می کند. می توانید به بخش مصرف بروید.

در غیر این صورت ، این ممکن است که Google از زمانی که SXG را فعال کرده اید ، صفحه شما را دوباره جذب نکرده است. ابزار بازرسی URL کنسول جستجوی Google را امتحان کنید:

حضور digest: mi-sha256-03=... عنوان نشان می دهد که Google با موفقیت نسخه SXG را خزید.

اگر یک هدر digest وجود نداشته باشد ، این می تواند نشانگر این باشد که SXG به Googlebot ارائه نشده است یا اینکه از زمان فعال کردن SXGS این شاخص به روز نشده است.

اگر یک SXG با موفقیت خزیده شود ، اما هنوز به آن مرتبط نیست ، ممکن است عدم موفقیت در مورد نیازهای حافظه پنهان SXG باشد. اینها در بخش بعدی پوشانده شده است.

بلع

هنگامی که Google Search یک SXG را فهرست می کند ، نسخه خود را به حافظه نهان Google SXG ارسال می کند ، که آن را در برابر نیازهای حافظه پنهان تأیید می کند. پسوند کروم نتیجه را نشان می دهد:

اگر یک علامت چک (✅) را مشاهده می کنید ، می توانید برای بهینه سازی پیش بروید.

اگر نتواند الزامات را برآورده کند ، یک علامت متقاطع (❌) و یک پیام هشدار دهنده را مشاهده خواهید کرد که نشان می دهد چرا:

In this event, the page will work just as it did before enabling SXG. Google will link to the page on its original host without an SXG prefetch.

In the event that the cached copy has expired and is being re-fetched in the background, you will see an hourglass (⌛):

The Google developer document on SXG also has instructions for querying the cache manually .

بهینه سازی کنید

If the SXG Validator Chrome extension shows all check marks (✅), you have a SXG that can be served to users! Read on to find out how to optimize your web page so that you get the most LCP improvement from SXG.

حداکثر سن

When SXGs expire, the Google SXG Cache will fetch a new copy in the background. While waiting for that fetch, users are directed to the page on its original host, which is not prefetched. The longer you set Cache-Control: max-age , the less often this background fetch happens, and thus the more often that LCP can be reduced by prefetch.

This is a tradeoff between performance and freshness, and the cache allows site owners to provide SXGs with a max-age anywhere between 2 minutes and 7 days, to fit each page's particular needs. Anecdotally, we find that:

• max-age=86400 (1 day) or longer works well for performance
• max-age=120 (2 minutes) does not

We hope to learn more about values in between those two, as we study the data more.

Note: We plan to make this tradeoff easier to manage in the future, by adding a cache purge API. It will be announced on webpackaging-announce .

عامل کاربر

One time, I saw LCP increase when using a prefetched SXG. I ran WebPageTest , comparing median results without and with SXG prefetch. Clicking on After below:

I saw that prefetch was working. The HTML is removed from the critical path and, thus, all of the subresources are able to load earlier. But LCP—that green dashed line— increased from 2s to 2.1s .

To diagnose this, I looked at the film strips. I found that the page rendered differently in SXG. In plain HTML, Chrome determined that the "largest element" for LCP was the headline. However, in the SXG version, the page added a lazy-loaded banner, which pushed the headline below the fold and caused the new largest element to be the lazy-loaded cookie consent dialog. Everything rendered faster than before, but a change in layout caused the metric to report it as slower.

I dug deeper and discovered the reason for the difference in layout is that the page varies by User-Agent , and there was an error in the logic. It was serving a desktop page even though the SXG crawl header indicated mobile. After this was fixed, the browser correctly identified the page's headline as its largest element again.

Now, clicking on "After", I saw that the prefetched LCP drops to 1.3s :

SXGs are enabled for all form factors. To prepare for that, ensure that one of these is true:

• Your page doesn't Vary by User-Agent (eg it uses responsive design or separate mobile/desktop URLs ).
• If your page uses dynamic serving , it annotates itself as mobile- or desktop-only using <meta name=supported-media content=...> .

منابع فرعی

SXGs can be used to prefetch subresources (including images) along with the HTML. Cloudflare ASX will scan the HTML for same-origin (first-party) <link rel=preload> elements and convert them into SXG-compatible Link headers . Details in the source code here and here .

If it's working, you'll see additional prefetches from Google Search:

To optimize for LCP, look closely at your waterfall, and figure out which resources are on the critical path to rendering the largest element. If they can't be prefetched, consider if they can be taken off the critical path . Be on the lookout for scripts that hide the page until they are done loading.

The Google SXG Cache allows up to 20 subresource preloads and ASX ensures that this limit isn't exceeded. However, there is a risk in adding too many subresource preloads. The browser will only use preloaded subresources if all of them have finished fetching , in order to prevent cross-site tracking . The more subresources there are, the less likely all of them will have finished prefetching before the user clicks through to your page.

Note: ASX currently only supports prefetch for same-origin (first-party) subresources. If you know of third-party subresource providers who support SXG, let us know on this bug so we can prioritize adding cross-origin support.

SXG Validator does not currently check subresources; to debug, use curl or dump-signedexchange in the meantime.

اندازه گیری کنید

After optimizing the LCP improvement under WebPageTest, it's useful to measure the impact of SXG prefetching on the overall performance of your site.

Server-side metrics

When measuring server-side metrics such as Time to First Byte (TTFB) , it's important to note that your site only serves SXGs to crawlers that accept the format. Limit your measurement of TTFB to requests coming from real users, and not bots. You may find that generating SXGs increases the TTFB for crawler requests, but this has no impact on your visitors' experience.

Client-side metrics

SXGs produce the most speed benefit for client-side metrics, especially LCP. When measuring their impact, you could simply enable Cloudflare ASX, wait for it to be re-crawled by Googlebot, wait an additional 28 days for Core Web Vitals (CWV) aggregation, and then look at your new CWV numbers. However, the change might be hard to spot when mixed in among all the other changes during this time frame.

Instead, I find it helpful to "zoom in" on the potentially affected page loads, and frame it as, "SXGs affect X% of page views, improving their LCP by Y milliseconds at the 75th percentile."

Currently, SXG prefetch only happens under certain conditions:

• Chromium browser (eg Chrome or Edge except on iOS ), version M98 or higher
• Referer: google.com or other Google search domains . (Note that in Google Analytics, a referral tag applies to all page views in the session , whereas SXG prefetch only applies to the first page view, directly linked from Google Search.)

Note: Google Search is planning to expand the contexts where SXG prefetch can occur, including desktop OSes and more. This may increase the X% over time, and also means you may want to update your metrics to accommodate the change. When that happens, it should be announced on webpackaging-announce .

Read the Contemporary study section for how to measure "X% of page views" and "improving their LCP by Y milliseconds".

Contemporary study

When looking at real user monitoring (RUM) data, you should split page loads into SXG and non-SXG. When doing so, it is essential to limit the set of page loads you look at, so the non-SXG side matches the eligibility conditions for SXG, in order to avoid selection bias. Otherwise, all of the following would exist only in the set of non-SXG page loads, which may have innately different LCP:

• iOS devices: due to differences in hardware or network speed among the users who have these devices.
• Older Chromium browsers: for the same reasons.
• Desktop devices: for the same reasons or because the page layout causes a different "largest element" to be chosen.
• Same-site navigations (visitors following links within the site): because they can reuse cached subresources from the previous page load.

In Google Analytics (UA), create two custom dimensions with scope "Hit", one named "isSXG" and one named "referrer". (The built-in "Source" dimension has session scope , so it doesn't exclude same-site navigations.)

Create a custom segment named "SXG counterfactual" with the following filters ANDed together:

• referrer starts with https://www.google.
• Browser exactly matches Chrome
• Browser Version matches regex ^(9[8-9]|[0-9]{3})
• isSXG exactly matches false

Create a copy of this segment, named "SXG", except with isSXG exactly matches true .

In your site template, add the following snippet above the Google Analytics snippet. This is a special syntax that ASX will change false to true when generating a SXG:

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

Customize your Google Analytics reporting script as recommended to record LCP. If you're using gtag.js, modify the 'config' command to set the custom dimension (replacing 'dimension1' and 'dimension2' with the names that Google Analytics says to use):

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

If you're using analytics.js, modify the 'create' command as documented here .

After waiting a few days to collect some data, go to the Google Analytics Events report and add a drilldown for the SXG segment. This should fill in the X for "SXGs affect X% of page views":

Finally, go to the Web Vitals Report , select "Choose segments", and select "SXG counterfactual" and "SXG".

Click "Submit", and you should see LCP distributions for the two segments. This should fill in the Y for "improving their LCP by Y milliseconds at the 75th percentile":

هشدارها

Once you've applied all of the above filters, SXG counterfactual page loads should consist of things like these:

• Cache misses: If the Google SXG Cache doesn't have a fresh copy of the SXG for a given URL, it will redirect to the original URL at your site.
• Other result types: Currently, Google Search only supports SXG for standard web results and a few other types. Others, like Featured Snippets and Top Stories Carousel, will link to the original URL at your site.
• Ineligible URLs: If some pages on your site are not eligible for SXG (eg because they are not cacheable), they could appear in this set.

There may be remaining bias between the SXG page loads and the above set of non-SXG page loads, but it should be smaller in magnitude than the biases mentioned at the top of the Contemporary study section . For example, perhaps your non-cacheable pages are slower or faster than your cacheable pages. If you suspect this could be an issue, consider looking at the data limited to a specific SXG-eligible URL to see if its results match the overall study.

If your site has some AMP pages, they probably won't see performance improvements from enabling SXG, as they can already be prefetched from Google Search. Consider adding a filter to exclude such pages, to further "zoom in" on the relevant changes.

Lastly, even addressing all selection biases, there is risk that survivorship bias makes LCP improvements look like degradations in RUM statistics. This article does a great job of explaining that risk, and suggests looking at some form of abandonment metric to detect whether this is happening.

Before/after study

To corroborate results from the contemporary study, it may be useful to do a comparison of LCP before and after enabling SXG. Don't limit to SXG page views, to eliminate the potential biases noted above. Instead, look at SXG-eligible results—the above segment definitions but without the isSXG constraint.

Note that Google Search may take up to several weeks to recrawl all pages on your site, in order to identify that SXG has been enabled for them. In those several weeks, there are other potential biases that may occur:

• New browser releases or improvements in users' hardware may speed up page loads.
• A significant event like a holiday may skew traffic from normal.

It also is helpful to look at overall 75th percentile LCP before and after, to confirm the above studies. Learning about a subset of the population doesn't necessarily tell us about the overall population. For instance, let's say SXG improves 10% of page loads by 800ms.

• If these were already the 10% fastest page loads, then it won't affect the 75th percentile at all.
• If they were the 10% slowest page loads, but they were more than 800ms slower than the 75th percentile LCP to begin with, then it won't affect the 75th percentile at all.

These are extreme examples, likely not reflective of reality, but hopefully illustrate the issue. In practice, it's likely that SXG will affect the 75th percentile for most sites. Cross-site navigations tend to be some of the slowest, and improvements from prefetching tend to be significant.

Opt-out some URLs

Lastly, one way to compare SXG performance could be to disable SXG for some subset of URLs on your site. For instance, you could set a CDN-Cache-Control: no-store header to prevent Cloudflare ASX from generating an SXG. من در برابر این توصیه می کنم.

It likely has a bigger risk of selection bias than the other study methods. For instance, it may make a big difference whether your site's home page or a similarly popular URL is selected into the control group or the experiment group.

Holdback study

The ideal way to measure impact would be to conduct a holdback study. Unfortunately, you can't do this kind of test currently. We're planning to add support for such a test in the future.

A holdback study has the following properties:

• In the experiment group, some random fraction of page views that would be SXG are "held back", and served as non-SXG instead. This allows for an "apples-to-apples" comparison between equivalent users, devices, scenarios, and pages.
• Those held-back (aka counterfactual) page views are labeled as such in the analytics. This allows for a "zoomed-in" view of the data, where we can compare SXG page loads in the control to SXG counterfactuals in the experiment. This, in turn, reduces noise from the other page loads that would be unaffected by SXG prefetch.

This would eliminate the aforementioned possible sources of selection bias, although it wouldn't eliminate the risk of LCP survivorship bias. Both of these properties require either the browser or the referrer to enable.

نتیجه گیری

اوه! این خیلی بود. Hopefully it paints a more complete picture of how to test SXG performance in a lab test, how to optimize its performance in a tight feedback loop with the lab test, and finally how to measure its performance in the real world. Putting all of this together should help you make the most out of SXGs, and ensure that they are benefiting your site and your users.

If you have additional advice on how to capture SXG performance, please let us know! File a bug against developer.chrome.com with your suggested improvements.

For more information on signed exchanges, take a look at the web.dev documentation and the Google Search documentation .

،

How to measure and optimize signed exchanges to get the most improvement out of them

Devin Mullins

Signed exchanges (SXGs) are a means to improve your page speed—mainly Largest Contentful Paint (LCP) . When referring sites (currently Google Search) link to a page, they can prefetch it into the browser cache before the user clicks on the link.

It's possible to make web pages that, when prefetched, require no network on the critical path to rendering the page ! On a 4G connection, this page load goes from 2.8s to 0.9s (the remaining 0.9s being mostly by CPU usage):

Note: Previously, this post showed an improvement from 6s to 0.9s . That was true, but the site under test was atypically slow at the time. Still, it may serve as a example representative of pages with more subresources , slower servers , or users with slower connection types .

Most people publishing SXGs today are using Cloudflare's easy-to-use Automatic Signed Exchanges (ASX) feature (though open source options exist too):

In many cases, checking the box to enable this feature is enough to get the kind of substantial improvement shown above. Sometimes, there are a few more steps to ensure these SXGs are working as intended at each stage of the pipeline, and to optimize pages to take full advantage of prefetch.

In the past couple of months since Cloudflare's launch, I've been reading and responding to questions on various forums and learning how to advise sites on how to make sure they're getting the most out of their SXG deployments. This post is a collection of my advice. I'll walk through the steps to:

• Analyze SXG performance using WebPageTest.
• Debug the SXG pipeline if the Analyze step shows that it's not working.
• Optimize pages for SXG prefetch including setting an optimal max-age and preloading render-blocking subresources.
• Measure SXG improvement using Google Analytics by selecting appropriate experiment and control groups.

مقدمه

An SXG is a file containing a URL, a set of HTTP response headers, and a response body—all cryptographically signed by a Web PKI certificate. When the browser loads an SXG, it verifies all of these:

• The SXG hasn't expired.
• The signature matches the URL, headers, body, and certificate.
• The certificate is valid and matches the URL.

If verification fails, the browser abandons the SXG and instead fetches the signed URL. If verification succeeds, the browser loads the signed response, treating it as if it came directly from the signed URL. This allows SXGs to be rehosted on any server as long as it isn't expired or modified since being signed.

In the case of Google Search, SXG enables prefetching of pages in its search results. For pages supporting SXGs, Google Search can prefetch its cached copy of the page, hosted on webpkgcache.com. These webpkgcache.com URLs don't affect the display or behavior of the page, because the browser respects the original, signed URL. Prefetching can enable your page to load much faster.

Note: SXGs are potentially useful for other use cases not covered in this article. For instance, they could enable connection resilience: a chat app could pre-download a link sent to the user if the page supports SXG, so they could later view it while offline. See this larger list of potential use cases .

تجزیه و تحلیل کنید

To see the benefit of SXGs, start by using a lab tool to analyze SXG performance in repeatable conditions. You can use WebPageTest to compare waterfalls—and LCP—with and without SXG prefetch.

Caution: Lab results may differ from real user experiences, but they are a useful tool to diagnose where to optimize and to iterate quickly. We'll cover how to measure the resultant real user metrics in the Measure section .

Generate a test without SXG as follows:

• Go to WebPageTest and sign in. Signing in saves your test history for easier comparison later.
• Enter the URL you want to test.
• Go to Advanced Configuration . (You will need Advanced Configuration for the SXG test, so using it here helps ensure the test options are the same.)
• In the Test Settings tab, it may be helpful to set Connection to 4G and increase "Number of Tests to Run" to 7.
• Click Start Test .

Generate a test with SXG by using the same steps as above, but before clicking Start Test , go to the Script tab, paste in the following WebPageTest script , and modify the two navigate URLs as directed:

// 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

For the first navigate URL, if your page doesn't appear in any Google Search results yet, you can use this prefetch page to generate a pretend search results page for this purpose.

To determine the second navigate URL, visit your page using the SXG Validator Chrome extension , and click the extension icon to see the cache URL:

Once these tests are complete, go to Test History , select the two tests, and click Compare :

Append &medianMetric=LCP to the compare URL so WebPageTest selects the run with median LCP for each side of the comparison. (The default is median by Speed Index.)

To compare waterfalls, expand the Waterfall Opacity section and drag the slider. To view the video, click Adjust Filmstrip Settings , scroll down inside that dialog, and click View Video .

If the SXG prefetch is successful, you will see that the "with SXG" waterfall doesn't include a row for the HTML, and the fetches for subresources start sooner. For example, compare "Before" and "After" here:

اشکال زدایی

If the WebPageTest is showing that the SXG is being prefetched, then it has succeeded in all the steps of the pipeline; you may skip to the Optimize section to learn how to further improve LCP. Otherwise, you'll need to find out where in the pipeline it failed and why; read on to learn how.

انتشار

Make sure your pages are being generated as SXGs. To do so, you need to pretend to be a crawler. The easiest way is to use the SXG Validator Chrome extension :

Note: SXGs are meant for SXG-capable crawlers, to enable prefetching. When users visit your site directly, you should not serve SXGs to them, since they will not be prefetched—doing so only adds overhead. Cloudflare ASX performs this content negotiation automatically.

The extension fetches the current URL with an Accept request header that says it prefers the SXG version. If you see a check mark (✅) next to Origin, that means an SXG was returned; you can skip to the Indexing section.

If you see a cross mark (❌), that means an SXG wasn't returned:

If Cloudflare ASX is enabled, then the most likely reason for a cross mark (❌) is because a cache control response header prevents it. ASX looks at headers with the following names:

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

If any of these headers contains any of the following header values, it will prevent an SXG from being generated:

• private
• no-store
• no-cache
• max-age less than 120, unless overridden by s-maxage greater than or equal to 120

ASX doesn't create an SXG in these cases because SXGs may be cached and reused for multiple visits and multiple visitors.

Another possible reason for a cross mark (❌) is the presence of one of these stateful response headers , except for Set-Cookie . ASX removes the Set-Cookie header to comply with the SXG specification.

Note: These restrictions can be seen in more detail in the ASX code. For instance, cache control headers are inspected by the code that determines when to sign and what the signature duration should be . Other headers are removed before signing by this configuration or by this code . Other headers prevent signing if not otherwise stripped.

Another possible reason is the presence of a Vary: Cookie response header. Googlebot fetches SXGs without user credentials and may serve them to multiple visitors. If you serve different HTML to different users based on their cookie, then they could see an incorrect experience such as a logged out view.

Note: In the future, pages using Vary: Cookie will be supported by SXG, by being shown only to visitors without cookies for your site. This is implemented in Chromium , and will be enabled in Google Search once that has rolled out more fully.

Alternatively to the Chrome extension, you can use a tool like curl :

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

or dump-signedexchange :

dump-signedexchange -verify -uri $URL

If the SXG is present and valid, you will see a human readable printout of the SXG. در غیر این صورت با پیغام خطا مواجه خواهید شد.

نمایه سازی

Make sure your SXGs are successfully indexed by Google Search. Open Chrome DevTools, then perform a Google Search for your page. If it has been indexed as an SXG, Google's link to your page will include a data-sxg-url pointing to webpkgcache.com's copy:

If Google Search thinks the user is likely to click on the result, it will also prefetch it:

The <link> element instructs the browser to download the SXG into its prefetch cache. When the user clicks on the <a> element, the browser will use that cached SXG to render the page.

You can also see evidence of the prefetch by going to the Network tab in DevTools and searching for URLs containing webpkgcache .

If the <a> points to webpkgcache.com, this means Google Search indexing of the signed exchange is working. You can skip forward to the Ingestion section.

Otherwise, it could be that Google hasn't recrawled your page yet since you enabled SXG. Try the Google Search Console URL Inspection Tool :

The presence of a digest: mi-sha256-03=... header indicates that Google successfully crawled the SXG version.

If a digest header is not present, this could be an indication that an SXG was not served to Googlebot or that the index hasn't been updated since you enabled SXGs.

If an SXG is successfully crawled, but it still isn't being linked to, then it may be a failure to meet SXG cache requirements. These are covered in the next section.

بلع

When Google Search indexes an SXG, it sends its copy to the Google SXG Cache, which validates it against the cache requirements . The Chrome extension shows the result:

If you see a check mark (✅), then you can skip ahead to Optimize .

If it fails to meet the requirements, you will see a cross mark (❌) and a warning message indicating why:

In this event, the page will work just as it did before enabling SXG. Google will link to the page on its original host without an SXG prefetch.

In the event that the cached copy has expired and is being re-fetched in the background, you will see an hourglass (⌛):

The Google developer document on SXG also has instructions for querying the cache manually .

بهینه سازی کنید

If the SXG Validator Chrome extension shows all check marks (✅), you have a SXG that can be served to users! Read on to find out how to optimize your web page so that you get the most LCP improvement from SXG.

حداکثر سن

When SXGs expire, the Google SXG Cache will fetch a new copy in the background. While waiting for that fetch, users are directed to the page on its original host, which is not prefetched. The longer you set Cache-Control: max-age , the less often this background fetch happens, and thus the more often that LCP can be reduced by prefetch.

This is a tradeoff between performance and freshness, and the cache allows site owners to provide SXGs with a max-age anywhere between 2 minutes and 7 days, to fit each page's particular needs. Anecdotally, we find that:

• max-age=86400 (1 day) or longer works well for performance
• max-age=120 (2 minutes) does not

We hope to learn more about values in between those two, as we study the data more.

Note: We plan to make this tradeoff easier to manage in the future, by adding a cache purge API. It will be announced on webpackaging-announce .

عامل کاربر

One time, I saw LCP increase when using a prefetched SXG. I ran WebPageTest , comparing median results without and with SXG prefetch. Clicking on After below:

I saw that prefetch was working. The HTML is removed from the critical path and, thus, all of the subresources are able to load earlier. But LCP—that green dashed line— increased from 2s to 2.1s .

To diagnose this, I looked at the film strips. I found that the page rendered differently in SXG. In plain HTML, Chrome determined that the "largest element" for LCP was the headline. However, in the SXG version, the page added a lazy-loaded banner, which pushed the headline below the fold and caused the new largest element to be the lazy-loaded cookie consent dialog. Everything rendered faster than before, but a change in layout caused the metric to report it as slower.

I dug deeper and discovered the reason for the difference in layout is that the page varies by User-Agent , and there was an error in the logic. It was serving a desktop page even though the SXG crawl header indicated mobile. After this was fixed, the browser correctly identified the page's headline as its largest element again.

Now, clicking on "After", I saw that the prefetched LCP drops to 1.3s :

SXGs are enabled for all form factors. To prepare for that, ensure that one of these is true:

• Your page doesn't Vary by User-Agent (eg it uses responsive design or separate mobile/desktop URLs ).
• If your page uses dynamic serving , it annotates itself as mobile- or desktop-only using <meta name=supported-media content=...> .

منابع فرعی

SXGs can be used to prefetch subresources (including images) along with the HTML. Cloudflare ASX will scan the HTML for same-origin (first-party) <link rel=preload> elements and convert them into SXG-compatible Link headers . Details in the source code here and here .

If it's working, you'll see additional prefetches from Google Search:

To optimize for LCP, look closely at your waterfall, and figure out which resources are on the critical path to rendering the largest element. If they can't be prefetched, consider if they can be taken off the critical path . Be on the lookout for scripts that hide the page until they are done loading.

The Google SXG Cache allows up to 20 subresource preloads and ASX ensures that this limit isn't exceeded. However, there is a risk in adding too many subresource preloads. The browser will only use preloaded subresources if all of them have finished fetching , in order to prevent cross-site tracking . The more subresources there are, the less likely all of them will have finished prefetching before the user clicks through to your page.

Note: ASX currently only supports prefetch for same-origin (first-party) subresources. If you know of third-party subresource providers who support SXG, let us know on this bug so we can prioritize adding cross-origin support.

SXG Validator does not currently check subresources; to debug, use curl or dump-signedexchange in the meantime.

اندازه گیری کنید

After optimizing the LCP improvement under WebPageTest, it's useful to measure the impact of SXG prefetching on the overall performance of your site.

Server-side metrics

When measuring server-side metrics such as Time to First Byte (TTFB) , it's important to note that your site only serves SXGs to crawlers that accept the format. Limit your measurement of TTFB to requests coming from real users, and not bots. You may find that generating SXGs increases the TTFB for crawler requests, but this has no impact on your visitors' experience.

Client-side metrics

SXGs produce the most speed benefit for client-side metrics, especially LCP. When measuring their impact, you could simply enable Cloudflare ASX, wait for it to be re-crawled by Googlebot, wait an additional 28 days for Core Web Vitals (CWV) aggregation, and then look at your new CWV numbers. However, the change might be hard to spot when mixed in among all the other changes during this time frame.

Instead, I find it helpful to "zoom in" on the potentially affected page loads, and frame it as, "SXGs affect X% of page views, improving their LCP by Y milliseconds at the 75th percentile."

Currently, SXG prefetch only happens under certain conditions:

• Chromium browser (eg Chrome or Edge except on iOS ), version M98 or higher
• Referer: google.com or other Google search domains . (Note that in Google Analytics, a referral tag applies to all page views in the session , whereas SXG prefetch only applies to the first page view, directly linked from Google Search.)

Note: Google Search is planning to expand the contexts where SXG prefetch can occur, including desktop OSes and more. This may increase the X% over time, and also means you may want to update your metrics to accommodate the change. When that happens, it should be announced on webpackaging-announce .

Read the Contemporary study section for how to measure "X% of page views" and "improving their LCP by Y milliseconds".

Contemporary study

When looking at real user monitoring (RUM) data, you should split page loads into SXG and non-SXG. When doing so, it is essential to limit the set of page loads you look at, so the non-SXG side matches the eligibility conditions for SXG, in order to avoid selection bias. Otherwise, all of the following would exist only in the set of non-SXG page loads, which may have innately different LCP:

• iOS devices: due to differences in hardware or network speed among the users who have these devices.
• Older Chromium browsers: for the same reasons.
• Desktop devices: for the same reasons or because the page layout causes a different "largest element" to be chosen.
• Same-site navigations (visitors following links within the site): because they can reuse cached subresources from the previous page load.

In Google Analytics (UA), create two custom dimensions with scope "Hit", one named "isSXG" and one named "referrer". (The built-in "Source" dimension has session scope , so it doesn't exclude same-site navigations.)

Create a custom segment named "SXG counterfactual" with the following filters ANDed together:

• referrer starts with https://www.google.
• Browser exactly matches Chrome
• Browser Version matches regex ^(9[8-9]|[0-9]{3})
• isSXG exactly matches false

Create a copy of this segment, named "SXG", except with isSXG exactly matches true .

In your site template, add the following snippet above the Google Analytics snippet. This is a special syntax that ASX will change false to true when generating a SXG:

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

Customize your Google Analytics reporting script as recommended to record LCP. If you're using gtag.js, modify the 'config' command to set the custom dimension (replacing 'dimension1' and 'dimension2' with the names that Google Analytics says to use):

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

If you're using analytics.js, modify the 'create' command as documented here .

After waiting a few days to collect some data, go to the Google Analytics Events report and add a drilldown for the SXG segment. This should fill in the X for "SXGs affect X% of page views":

Finally, go to the Web Vitals Report , select "Choose segments", and select "SXG counterfactual" and "SXG".

Click "Submit", and you should see LCP distributions for the two segments. This should fill in the Y for "improving their LCP by Y milliseconds at the 75th percentile":

هشدارها

Once you've applied all of the above filters, SXG counterfactual page loads should consist of things like these:

• Cache misses: If the Google SXG Cache doesn't have a fresh copy of the SXG for a given URL, it will redirect to the original URL at your site.
• Other result types: Currently, Google Search only supports SXG for standard web results and a few other types. Others, like Featured Snippets and Top Stories Carousel, will link to the original URL at your site.
• Ineligible URLs: If some pages on your site are not eligible for SXG (eg because they are not cacheable), they could appear in this set.

There may be remaining bias between the SXG page loads and the above set of non-SXG page loads, but it should be smaller in magnitude than the biases mentioned at the top of the Contemporary study section . For example, perhaps your non-cacheable pages are slower or faster than your cacheable pages. If you suspect this could be an issue, consider looking at the data limited to a specific SXG-eligible URL to see if its results match the overall study.

If your site has some AMP pages, they probably won't see performance improvements from enabling SXG, as they can already be prefetched from Google Search. Consider adding a filter to exclude such pages, to further "zoom in" on the relevant changes.

Lastly, even addressing all selection biases, there is risk that survivorship bias makes LCP improvements look like degradations in RUM statistics. This article does a great job of explaining that risk, and suggests looking at some form of abandonment metric to detect whether this is happening.

Before/after study

To corroborate results from the contemporary study, it may be useful to do a comparison of LCP before and after enabling SXG. Don't limit to SXG page views, to eliminate the potential biases noted above. Instead, look at SXG-eligible results—the above segment definitions but without the isSXG constraint.

Note that Google Search may take up to several weeks to recrawl all pages on your site, in order to identify that SXG has been enabled for them. In those several weeks, there are other potential biases that may occur:

• New browser releases or improvements in users' hardware may speed up page loads.
• A significant event like a holiday may skew traffic from normal.

It also is helpful to look at overall 75th percentile LCP before and after, to confirm the above studies. Learning about a subset of the population doesn't necessarily tell us about the overall population. For instance, let's say SXG improves 10% of page loads by 800ms.

• If these were already the 10% fastest page loads, then it won't affect the 75th percentile at all.
• If they were the 10% slowest page loads, but they were more than 800ms slower than the 75th percentile LCP to begin with, then it won't affect the 75th percentile at all.

These are extreme examples, likely not reflective of reality, but hopefully illustrate the issue. In practice, it's likely that SXG will affect the 75th percentile for most sites. Cross-site navigations tend to be some of the slowest, and improvements from prefetching tend to be significant.

Opt-out some URLs

Lastly, one way to compare SXG performance could be to disable SXG for some subset of URLs on your site. For instance, you could set a CDN-Cache-Control: no-store header to prevent Cloudflare ASX from generating an SXG. من در برابر این توصیه می کنم.

It likely has a bigger risk of selection bias than the other study methods. For instance, it may make a big difference whether your site's home page or a similarly popular URL is selected into the control group or the experiment group.

Holdback study

The ideal way to measure impact would be to conduct a holdback study. Unfortunately, you can't do this kind of test currently. We're planning to add support for such a test in the future.

A holdback study has the following properties:

• In the experiment group, some random fraction of page views that would be SXG are "held back", and served as non-SXG instead. This allows for an "apples-to-apples" comparison between equivalent users, devices, scenarios, and pages.
• Those held-back (aka counterfactual) page views are labeled as such in the analytics. This allows for a "zoomed-in" view of the data, where we can compare SXG page loads in the control to SXG counterfactuals in the experiment. This, in turn, reduces noise from the other page loads that would be unaffected by SXG prefetch.

This would eliminate the aforementioned possible sources of selection bias, although it wouldn't eliminate the risk of LCP survivorship bias. Both of these properties require either the browser or the referrer to enable.

نتیجه گیری

اوه! این خیلی بود. Hopefully it paints a more complete picture of how to test SXG performance in a lab test, how to optimize its performance in a tight feedback loop with the lab test, and finally how to measure its performance in the real world. Putting all of this together should help you make the most out of SXGs, and ensure that they are benefiting your site and your users.

If you have additional advice on how to capture SXG performance, please let us know! File a bug against developer.chrome.com with your suggested improvements.

For more information on signed exchanges, take a look at the web.dev documentation and the Google Search documentation .