SXG یک مکانیسم تحویل است که تأیید اعتبار منبع یک منبع را مستقل از نحوه تحویل آن ممکن میسازد.
صرافی های امضا شده (SXG) یک مکانیسم تحویل است که احراز هویت مبدا یک منبع را مستقل از نحوه تحویل آن ممکن می سازد. پیادهسازی SXG میتواند بزرگترین رنگ محتوایی (LCP) را با فعال کردن واکشی اولیه متقاطع با حفظ حریم خصوصی بهبود بخشد. علاوه بر این، این جداسازی موارد استفاده مختلفی مانند تجربیات اینترنتی آفلاین و سرویس دهی از حافظه پنهان شخص ثالث را پیش می برد.
این مقاله یک نمای کلی از SXG ارائه می دهد: نحوه کار، موارد استفاده و ابزار.
سازگاری با مرورگر
SXG توسط مرورگرهای مبتنی بر Chromium پشتیبانی می شود (شروع با نسخه های: Chrome 73، Edge 79، و Opera 64).
نمای کلی
به عنوان مورد استفاده اصلی خود، SXG از یک کش برای واکشی و ارائه محتوایی که به صورت رمزنگاری شده توسط مبدا امضا شده است، استفاده می کند. این به سرعت پیمایشهای متقاطع از سایتهای ارجاعدهنده کمک میکند و همچنین تضمین میکند که صفحات بدون تغییر باقی میمانند و به درستی به مبدأ خود نسبت داده میشوند. هر گونه اطلاعات شناسایی بالقوه تا زمانی که کاربر به یک سایت پیمایش کند پنهان می شود و در نتیجه از حریم خصوصی کاربر محافظت می شود. جستجوی گوگل اولین پذیرنده قابلیتهای واکشی اولیه SXG است و برای سایتهایی که بخش زیادی از ترافیک خود را از جستجوی Google دریافت میکنند، SXG میتواند ابزار مهمی برای بارگذاری سریعتر صفحه به کاربران باشد. با گذشت زمان، امیدواریم این تأثیر به ارجاع دهندگان دیگر گسترش یابد.
چگونه کار می کند
یک سایت یک جفت درخواست/پاسخ (یک «مبادله HTTP») را امضا میکند به گونهای که مرورگر را قادر میسازد تا منشأ و یکپارچگی محتوا را مستقل از نحوه توزیع محتوا تأیید کند. در نتیجه، مرورگر میتواند نشانی وب سایت مبدا را به جای نشانی اینترنتی سروری که محتوا را تحویل داده است، در نوار آدرس نمایش دهد.
از لحاظ تاریخی، تنها راهی که یک سایت میتواند از یک شخص ثالث برای توزیع محتوای خود در حین حفظ اعتبار استفاده کند، این بوده است که سایت گواهیهای SSL خود را با توزیعکننده به اشتراک بگذارد. این دارای اشکالات امنیتی است. علاوه بر این، تا اینکه محتوا واقعا قابل حمل باشد فاصله زیادی دارد.
فرمت SXG
یک SXG در یک فایل کدگذاری شده باینری کپسوله شده است که دارای دو جزء اصلی است: یک تبادل HTTP و یک امضا که مبادله را پوشش می دهد. تبادل HTTP شامل یک URL درخواست، اطلاعات مذاکره محتوا و یک پاسخ HTTP است.
format version: 1b3 request: method: GET uri: https://example.org/ headers: response: status: 200 headers: Cache-Control: max-age=604800 Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY= Expires: Mon, 24 Aug 2020 16:08:24 GMT Content-Type: text/html; charset=UTF-8 Content-Encoding: mi-sha256-03 Date: Mon, 17 Aug 2020 16:08:24 GMT Vary: Accept-Encoding signature: label;cert-sha256=<em>ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=</em>; cert-url="https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE"; date=1597680503;expires=1598285303;integrity="digest/mi-sha256-03";sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>; validity-url="https://example.org/webpkg/validity" header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p> <p>The exchange has a valid signature. payload [1256 bytes]:</p> <pre class="prettyprint"><code><title>SXG example</title> <meta charset="utf-8"> <meta http-equiv="Content-type" content="text/html; charset=utf-8"> <style type="text/css"> body { background-color: #f0f0f2; margin: 0; padding: 0; } </style> </code></pre> <div> <h1>Hello</h1> </div> <p>
پارامتر expires
در امضا، تاریخ انقضای SXG را نشان می دهد. SXG ممکن است حداکثر 7 روز معتبر باشد. اطلاعات بیشتر در مورد هدر امضا در مشخصات Signed HTTP Exchanges بیابید.
پشتیبانی از شخصی سازی سمت سرور
یک SXG حاوی هدر Vary: Cookie
فقط برای کاربرانی که کوکیهایی برای URL درخواست امضا شده ندارند نشان داده میشود. اگر سایت شما HTML متفاوتی را به کاربران وارد شده خود ارائه می دهد، می توانید از این ویژگی برای استفاده از SXG ها بدون تغییر آن تجربه استفاده کنید. جزئیات شخصی سازی سمت سرور را با Dynamic SXG ببینید.
بسته بندی وب
SXG بخشی از خانواده پیشنهادی مشخصات بسته بندی وب است. علاوه بر SXGها، جزء اصلی دیگر مشخصات بسته بندی وب ، بسته های وب ("مبادلات HTTP همراه") است. بسته های وب مجموعه ای از منابع HTTP و ابرداده های لازم برای تفسیر بسته هستند.
رابطه بین SXG و Web Bundle یک نقطه سردرگمی رایج است. SXG و Web Bundles دو فناوری متمایز هستند که به یکدیگر وابسته نیستند—بستههای وب را میتوان هم با مبادلات امضا شده و هم بدون امضا استفاده کرد. هدف مشترکی که توسط SXG ها و Web Bundle ها پیش رفته است، ایجاد قالب «بسته بندی وب» است که به سایت ها اجازه می دهد به طور کامل برای مصرف آفلاین به اشتراک گذاشته شوند.
افزایش سرعت بارگذاری صفحات با صرافی های امضا شده
فعال کردن Signed Exchanges میتواند به سرعت بخشیدن به عملکرد صفحه وب کمک کند و در نتیجه بر هسته اصلی وب سایت شما، به ویژه بزرگترین رنگ محتوایی (LCP) تأثیر بگذارد. به عنوان اولین پذیرنده، جستجوی Google از SXG استفاده میکند تا تجربه بارگیری سریعتر صفحه را برای صفحات بارگیری شده از صفحه نتایج جستجو به کاربران ارائه دهد.
جستجوی Google SXGها را در صورت موجود بودن میخزد و ذخیره میکند و SXG را که کاربر احتمالاً از آن بازدید میکند، از پیش واکشی میکند - برای مثال، صفحه مربوط به اولین نتیجه جستجو.
SXG در کنار سایر بهینهسازیهای عملکرد مانند استفاده از CDN و کاهش منابع فرعی مسدودکننده رندر بهترین عملکرد را دارد. پس از پیاده سازی، این توصیه ها را دنبال کنید تا مزایای LCP را از واکشی اولیه SXG به حداکثر برسانید. در بسیاری از موارد، چنین بهینه سازی می تواند منجر به بارگیری تقریباً فوری صفحه از جستجوی Google شود:
تاثیر صرافی های امضا شده
از آزمایشهای گذشته، بهطور متوسط 300 میلیثانیه تا 400 میلیثانیه کاهش در LCP از واکشیهای پیشفرض با قابلیت SXG مشاهده کردهایم. این به سایتها کمک میکند تاثیر اول بهتری بر روی کاربران بگذارند و اغلب تأثیر مثبتی بر معیارهای تجاری دارد.
چندین برند و سایت جهانی قبلاً از Signed Exchanges بهره مند شده اند. به عنوان یک مطالعه موردی، اجازه میدهیم ببینیم که چگونه پیادهسازی Signed Exchanges به RebelMouse ، یک سیستم مدیریت محتوای برجسته (CMS)، کمک کرد تا عملکرد و معیارهای تجاری مشتریان خود را بهبود بخشد:
- Narcity LCP را 41٪ بهبود داد
- Paper Magazine متوجه افزایش 27 درصدی Sessions به ازای هر کاربر شد
- وبلاگ MLT زمان بارگذاری صفحه را 21٪ کاهش داد
Cloudflare دریافت که SXG TTFB را برای 98٪ از سایت هایی که آزمایش کرده بود، و LCP را برای 85٪ از سایت ها بهبود بخشید ، با بهبود متوسط بیش از 20٪ در بارگذاری صفحات واجد شرایط SXG.
نمایه سازی
نمایش SXG و غیر SXG یک صفحه توسط جستجوی Google رتبه بندی یا فهرست بندی متفاوتی ندارد. SXG در نهایت یک مکانیسم تحویل است - محتوای اصلی را تغییر نمی دهد.
AMP
محتوای AMP را می توان با استفاده از SXG تحویل داد. SXG به محتوای AMP اجازه می دهد تا از قبل واکشی شده و با استفاده از URL معمولی آن نمایش داده شود، به جای AMP URL.AMP ابزار جداگانه خود را برای تولید SXG دارد. نحوه ارائه AMP با استفاده از تبادلات امضا شده در amp.dev را بیاموزید.
اشکال زدایی SXG ها با ابزارهای توسعه دهنده کروم
برای مشاهده دست اول یک SXG، از مرورگر Chromium استفاده کنید، DevTools را باز کنید، پانل شبکه را باز کنید و از این صفحه جستجوی مثال دیدن کنید. صرافی های امضا شده را می توان با جستجوی signed-exchange
در ستون نوع شناسایی کرد.
![تصویری که درخواست SXG را در پانل «شبکه» در DevTools نشان میدهد](https://web.developers.google.cn/static/articles/signed-exchanges/image/screenshot-showing-sxg-r-9a4f9df2440b3.png?authuser=0&hl=fa)
تب Preview اطلاعات بیشتری در مورد محتویات یک SXG ارائه می دهد.
![اسکرین شات از برگه "پیش نمایش" برای یک SXG](https://web.developers.google.cn/static/articles/signed-exchanges/image/screenshot-the-preview-033e1253a3e1.png?authuser=0&hl=fa)
ابزار سازی
پیادهسازی SXG شامل تولید SXG مربوط به یک URL داده شده و سپس ارائه آن SXG به درخواستکنندگان (معمولاً خزندهها) است.
گواهینامه ها
برای تولید یک SXG به گواهینامه ای نیاز دارید که بتواند SXG ها را امضا کند، اگرچه برخی از ابزارها به طور خودکار آنها را دریافت می کنند. در این صفحه مقامات گواهی که می توانند این نوع گواهی را صادر کنند فهرست می شود. گواهی ها را می توان به طور خودکار از مرجع گواهی Google با استفاده از هر مشتری ACME دریافت کرد. سرور بسته بندی وب دارای یک کلاینت داخلی ACME است و sxg-rs به زودی خواهد داشت.
ابزار SXG مخصوص پلتفرم
این ابزارها پشته های فناوری خاصی را پشتیبانی می کنند. اگر قبلاً از پلتفرمی استفاده میکنید که توسط یکی از این ابزارها پشتیبانی میشود، ممکن است راهاندازی آن آسانتر از یک ابزار همهمنظوره باشد.
sxg-rs/cloudflare_worker
روی Cloudflare Workers اجرا می شود.sxg-rs/fastly_compute
روی Fastly Compute@Edge اجرا میشود.Automatic Signed Exchanges یک ویژگی Cloudflare است که به طور خودکار گواهی ها را دریافت کرده و Signed Exchanges را ایجاد می کند.
ماژول NGINX SXG SXGها را برای سایت هایی که از nginx استفاده می کنند تولید و ارائه می کند. دستورالعمل های راه اندازی را می توانید در اینجا پیدا کنید.
Envoy SXG Filter SXGها را برای سایتهایی که از Envoy استفاده میکنند تولید و ارائه میکند.
ابزار SXG همه منظوره
سرور HTTP sxg-rs
sxg-rs http_server به عنوان یک پروکسی معکوس برای سرویس دهی به SXG ها عمل می کند. برای درخواستهای خزندههای SXG، http_server
پاسخهای پشتیبان را امضا میکند و با SXG پاسخ میدهد. برای دستورالعملهای نصب، به README مراجعه کنید.
سرور بسته بندی وب
Web Packager Server ، webpkgserver
، جایگزینی برای sxg-rs http_server است که در Go نوشته شده است. برای دستورالعملهای مربوط به راهاندازی سرور Web Packager، به نحوه راهاندازی مبادلات امضا شده با استفاده از Web Packager مراجعه کنید.
Web Packager CLI
Web Packager CLI یک SXG مربوط به یک URL داده شده تولید می کند.
webpackager \
--private\_key=private.key \
--cert\_url=https://example.com/certificate.cbor \
--url=https://example.com
پس از تولید فایل SXG، آن را در سرور خود آپلود کرده و با نوع application/signed-exchange;v=b3
MIME آن را ارائه دهید. علاوه بر این، باید گواهینامه SXG را به عنوان application/cert-chain+cbor
ارائه دهید.
کتابخانه های SXG
از این کتابخانه ها می توان برای ساخت مولد SXG خود استفاده کرد:
sxg_rs
یک کتابخانه Rust برای تولید SXG است. این ویژگی برجسته ترین کتابخانه SXG است و به عنوان مبنایی برای ابزارهایcloudflare_worker
وfastly_compute
استفاده می شود.libsxg
یک کتابخانه C حداقل برای تولید SXG است. این به عنوان پایه ماژول NGINX SXG و فیلتر Envoy SXG استفاده می شود.go/signed-exchange
یک کتابخانه Go حداقل است که توسط مشخصات بسته وب به عنوان یک پیاده سازی مرجع برای تولید SXG ارائه شده است. این به عنوان مبنایی برای ابزار مرجع CLI،gen-signedexchange
و ابزارهای ویژهتر Web Packager استفاده میشود.
مذاکره محتوا
زمانی که هدر Accept نشان میدهد که مقدار q برای application/signed-exchange بزرگتر یا برابر با q-value برای text/html است، سرورها باید SXG را ارائه دهند. در عمل، این بدان معنی است که یک سرور مبدا SXG را به خزنده ها ارائه می دهد، اما نه مرورگرها. بسیاری از ابزارهای فوق به طور پیش فرض این کار را انجام می دهند، اما برای ابزارهای دیگر، عبارت منظم زیر را می توان برای مطابقت با هدر Accept درخواست هایی که باید به عنوان SXG ارائه شوند استفاده کرد: http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/
این توصیه شامل نمونه هایی برای آپاچی و nginx است.
API حافظه پنهان را به روز کنید
Google SXG Cache دارای یک API است که صاحبان سایت می توانند از آن برای حذف SXGها از حافظه پنهان قبل از انقضا به دلیل Cache-Control: max-age
استفاده کنند. برای جزئیات به مرجع API حافظه پنهان به روز رسانی مراجعه کنید.
پیوند دادن به SXG
هر سایتی می تواند با استفاده از و برچسبها: html <a href="https://example.com/article.html.sxg"> <link rel="prefetch" as="document" href="https://example.com/article.html.sxg">
این مقاله نحوه استفاده از nginx برای توزیع SXG را نشان میدهد.
مزایای منحصر به فرد
SXG یکی از بسیاری از فناوریهای ممکن برای فعال کردن واکشی اولیه متقاطع است. وقتی تصمیم می گیرید از کدام فناوری استفاده کنید، ممکن است لازم باشد بین بهینه سازی جنبه های مختلف معاوضه کنید. بخشهای زیر تعدادی از مقادیر منحصربهفردی را که SXG در فضای راهحلهای ممکن ارائه میکند، نشان میدهد. این عوامل ممکن است در طول زمان با تکامل فضای راه حل های موجود تغییر کنند.
درخواست کمتر برای خدمت
با واکشی اولیه متقاطع سایت، سرور شما ممکن است نیاز به ارائه درخواست های اضافی داشته باشد. این مربوط به مواردی است که یک صفحه از قبل واکشی شده است، اما یا کاربر از صفحه بازدید نکرده است، یا بایت های از پیش واکشی شده به کاربر نشان داده نمی شود. برای SXG، این درخواست های استفاده نشده اضافی را می توان به میزان قابل توجهی کاهش داد:
- SXG ها کش هستند و ممکن است تا زمان انقضا برای کاربران ارسال شوند. بنابراین، بسیاری از واکشیهای اولیه را میتوان تنها توسط سرور کش مدیریت کرد.
- SXG ها را می توان هم با و هم بدون کوکی در سایت شما به کاربران نشان داد. بنابراین، زمانهای کمتری وجود دارد که صفحه بعد از پیمایش مجدداً باید واکشی شود.
بهبود سرعت صفحه
ممکن است به دلیل سطوح واکشی اولیه و قابلیتهایی که در حال حاضر پشتیبانی میکند، بهبود سرعت صفحه بیشتری مشاهده کنید:
- SXG ها را می توان با کوکی های سایت شما به کاربران نشان داد.
- SXG همچنین منابع فرعی صفحات شما مانند جاوا اسکریپت، CSS، فونتها و تصاویر را زمانی که با استفاده از هدر
Link
مشخص میشود، واکشی میکند. - در آینده نزدیک، واکشی اولیه SXG از جستجوی Google در انواع بیشتری از نتایج جستجو در دسترس خواهد بود.
نتیجه گیری
مبادلات امضا شده یک مکانیسم تحویل است که تأیید منشأ و اعتبار یک منبع را مستقل از نحوه تحویل منبع ممکن میسازد. در نتیجه، SXGها را میتوان توسط اشخاص ثالث توزیع کرد و در عین حال اعتبار کامل ناشر را حفظ کرد.
در ادامه مطلب
- پیش نویس مشخصات برای صرافی های HTTP امضا شده
- توضیح دهنده بسته بندی وب
- با مبادلات امضا شده در جستجوی Google شروع کنید
- نحوه راه اندازی Signed Exchanges با استفاده از Web Packager
- نسخه ی نمایشی صرافی های امضا شده
SXG یک مکانیسم تحویل است که تأیید اعتبار منبع یک منبع را مستقل از نحوه تحویل آن ممکن میسازد.
صرافی های امضا شده (SXG) یک مکانیسم تحویل است که احراز هویت مبدا یک منبع را مستقل از نحوه تحویل آن ممکن می سازد. پیادهسازی SXG میتواند بزرگترین رنگ محتوایی (LCP) را با فعال کردن واکشی اولیه متقاطع با حفظ حریم خصوصی بهبود بخشد. علاوه بر این، این جداسازی موارد استفاده مختلفی مانند تجربیات اینترنتی آفلاین و سرویس دهی از حافظه پنهان شخص ثالث را پیش می برد.
این مقاله یک نمای کلی از SXG ارائه می دهد: نحوه کار، موارد استفاده و ابزار.
سازگاری با مرورگر
SXG توسط مرورگرهای مبتنی بر Chromium پشتیبانی می شود (شروع با نسخه های: Chrome 73، Edge 79، و Opera 64).
نمای کلی
به عنوان مورد استفاده اصلی خود، SXG از یک کش برای واکشی و ارائه محتوایی که به صورت رمزنگاری شده توسط مبدا امضا شده است، استفاده می کند. این به سرعت پیمایشهای متقاطع از سایتهای ارجاعدهنده کمک میکند و همچنین تضمین میکند که صفحات بدون تغییر باقی میمانند و به درستی به مبدأ خود نسبت داده میشوند. هر گونه اطلاعات شناسایی بالقوه تا زمانی که کاربر به یک سایت پیمایش کند پنهان می شود و در نتیجه از حریم خصوصی کاربر محافظت می شود. جستجوی گوگل اولین پذیرنده قابلیتهای واکشی اولیه SXG است و برای سایتهایی که بخش زیادی از ترافیک خود را از جستجوی Google دریافت میکنند، SXG میتواند ابزار مهمی برای بارگذاری سریعتر صفحه به کاربران باشد. با گذشت زمان، امیدواریم این تأثیر به ارجاع دهندگان دیگر گسترش یابد.
چگونه کار می کند
یک سایت یک جفت درخواست/پاسخ (یک «مبادله HTTP») را امضا میکند به گونهای که مرورگر را قادر میسازد تا منشأ و یکپارچگی محتوا را مستقل از نحوه توزیع محتوا تأیید کند. در نتیجه، مرورگر میتواند نشانی وب سایت مبدا را به جای نشانی اینترنتی سروری که محتوا را تحویل داده است، در نوار آدرس نمایش دهد.
از لحاظ تاریخی، تنها راهی که یک سایت میتواند از یک شخص ثالث برای توزیع محتوای خود در حین حفظ اعتبار استفاده کند، این بوده است که سایت گواهیهای SSL خود را با توزیعکننده به اشتراک بگذارد. این دارای اشکالات امنیتی است. علاوه بر این، تا اینکه محتوا واقعا قابل حمل باشد فاصله زیادی دارد.
فرمت SXG
یک SXG در یک فایل کدگذاری شده باینری کپسوله شده است که دارای دو جزء اصلی است: یک تبادل HTTP و یک امضا که مبادله را پوشش می دهد. تبادل HTTP شامل یک URL درخواست، اطلاعات مذاکره محتوا و یک پاسخ HTTP است.
format version: 1b3 request: method: GET uri: https://example.org/ headers: response: status: 200 headers: Cache-Control: max-age=604800 Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY= Expires: Mon, 24 Aug 2020 16:08:24 GMT Content-Type: text/html; charset=UTF-8 Content-Encoding: mi-sha256-03 Date: Mon, 17 Aug 2020 16:08:24 GMT Vary: Accept-Encoding signature: label;cert-sha256=<em>ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=</em>; cert-url="https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE"; date=1597680503;expires=1598285303;integrity="digest/mi-sha256-03";sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>; validity-url="https://example.org/webpkg/validity" header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p> <p>The exchange has a valid signature. payload [1256 bytes]:</p> <pre class="prettyprint"><code><title>SXG example</title> <meta charset="utf-8"> <meta http-equiv="Content-type" content="text/html; charset=utf-8"> <style type="text/css"> body { background-color: #f0f0f2; margin: 0; padding: 0; } </style> </code></pre> <div> <h1>Hello</h1> </div> <p>
پارامتر expires
در امضا، تاریخ انقضای SXG را نشان می دهد. SXG ممکن است حداکثر 7 روز معتبر باشد. اطلاعات بیشتر در مورد هدر امضا در مشخصات Signed HTTP Exchanges بیابید.
پشتیبانی از شخصی سازی سمت سرور
یک SXG حاوی هدر Vary: Cookie
فقط برای کاربرانی که کوکیهایی برای URL درخواست امضا شده ندارند نشان داده میشود. اگر سایت شما HTML متفاوتی را به کاربران وارد شده خود ارائه می دهد، می توانید از این ویژگی برای استفاده از SXG ها بدون تغییر آن تجربه استفاده کنید. جزئیات شخصی سازی سمت سرور را با Dynamic SXG ببینید.
بسته بندی وب
SXG بخشی از خانواده پیشنهادی مشخصات بسته بندی وب است. علاوه بر SXGها، جزء اصلی دیگر مشخصات بسته بندی وب، بسته های وب ("مبادلات HTTP همراه") است. بسته های وب مجموعه ای از منابع HTTP و ابرداده های لازم برای تفسیر بسته هستند.
رابطه بین SXG و Web Bundle یک نقطه سردرگمی رایج است. SXG و Web Bundles دو فناوری متمایز هستند که به یکدیگر وابسته نیستند—بستههای وب را میتوان هم با مبادلات امضا شده و هم بدون امضا استفاده کرد. هدف مشترکی که توسط SXG ها و Web Bundle ها پیش رفته است، ایجاد قالب «بسته بندی وب» است که به سایت ها اجازه می دهد به طور کامل برای مصرف آفلاین به اشتراک گذاشته شوند.
افزایش سرعت بارگذاری صفحات با صرافی های امضا شده
فعال کردن Signed Exchanges میتواند به سرعت بخشیدن به عملکرد صفحه وب کمک کند و در نتیجه بر هسته اصلی وب سایت شما، به ویژه بزرگترین رنگ محتوایی (LCP) تأثیر بگذارد. به عنوان اولین پذیرنده، جستجوی Google از SXG استفاده میکند تا تجربه بارگیری سریعتر صفحه را برای صفحات بارگیری شده از صفحه نتایج جستجو به کاربران ارائه دهد.
جستجوی Google SXGها را در صورت موجود بودن میخزد و ذخیره میکند و SXG را که کاربر احتمالاً از آن بازدید میکند، از پیش واکشی میکند - برای مثال، صفحه مربوط به اولین نتیجه جستجو.
SXG در کنار سایر بهینهسازیهای عملکرد مانند استفاده از CDN و کاهش منابع فرعی مسدودکننده رندر بهترین عملکرد را دارد. پس از پیاده سازی، این توصیه ها را دنبال کنید تا مزایای LCP را از واکشی اولیه SXG به حداکثر برسانید. در بسیاری از موارد، چنین بهینه سازی می تواند منجر به بارگیری تقریباً فوری صفحه از جستجوی Google شود:
تاثیر صرافی های امضا شده
از آزمایشهای گذشته، بهطور متوسط 300 میلیثانیه تا 400 میلیثانیه کاهش در LCP از واکشیهای پیشفرض با قابلیت SXG مشاهده کردهایم. این به سایتها کمک میکند تاثیر اول بهتری بر روی کاربران بگذارند و اغلب تأثیر مثبتی بر معیارهای تجاری دارد.
چندین برند و سایت جهانی قبلاً از Signed Exchanges بهره مند شده اند. به عنوان یک مطالعه موردی، اجازه میدهیم ببینیم که چگونه پیادهسازی Signed Exchanges به RebelMouse ، یک سیستم مدیریت محتوای برجسته (CMS)، کمک کرد تا عملکرد و معیارهای تجاری مشتریان خود را بهبود بخشد:
- Narcity LCP را 41٪ بهبود داد
- Paper Magazine متوجه افزایش 27 درصدی Sessions به ازای هر کاربر شد
- وبلاگ MLT زمان بارگذاری صفحه را 21٪ کاهش داد
Cloudflare دریافت که SXG TTFB را برای 98٪ از سایت هایی که آزمایش کرده بود، و LCP را برای 85٪ از سایت ها بهبود بخشید ، با بهبود متوسط بیش از 20٪ در بارگذاری صفحات واجد شرایط SXG.
نمایه سازی
نمایش SXG و غیر SXG یک صفحه توسط جستجوی Google رتبه بندی یا فهرست بندی متفاوتی ندارد. SXG در نهایت یک مکانیسم تحویل است - محتوای اصلی را تغییر نمی دهد.
AMP
محتوای AMP را می توان با استفاده از SXG تحویل داد. SXG به محتوای AMP اجازه می دهد تا از قبل واکشی شده و با استفاده از URL معمولی آن نمایش داده شود، به جای AMP URL.AMP ابزار جداگانه خود را برای تولید SXG دارد. نحوه ارائه AMP با استفاده از تبادلات امضا شده در amp.dev را بیاموزید.
اشکال زدایی SXG ها با ابزارهای توسعه دهنده کروم
برای مشاهده دست اول یک SXG، از مرورگر Chromium استفاده کنید، DevTools را باز کنید، پانل شبکه را باز کنید و از این صفحه جستجوی مثال دیدن کنید. صرافی های امضا شده را می توان با جستجوی signed-exchange
در ستون نوع شناسایی کرد.
![تصویری که درخواست SXG را در پانل «شبکه» در DevTools نشان میدهد](https://web.developers.google.cn/static/articles/signed-exchanges/image/screenshot-showing-sxg-r-9a4f9df2440b3.png?authuser=0&hl=fa)
تب Preview اطلاعات بیشتری در مورد محتویات یک SXG ارائه می دهد.
![اسکرین شات از برگه "پیش نمایش" برای یک SXG](https://web.developers.google.cn/static/articles/signed-exchanges/image/screenshot-the-preview-033e1253a3e1.png?authuser=0&hl=fa)
ابزار سازی
پیادهسازی SXG شامل تولید SXG مربوط به یک URL داده شده و سپس ارائه آن SXG به درخواستکنندگان (معمولاً خزندهها) است.
گواهینامه ها
برای تولید یک SXG به گواهینامه ای نیاز دارید که بتواند SXG ها را امضا کند، اگرچه برخی از ابزارها به طور خودکار آنها را دریافت می کنند. در این صفحه مقامات گواهی که می توانند این نوع گواهی را صادر کنند فهرست می شود. گواهی ها را می توان به طور خودکار از مرجع گواهی Google با استفاده از هر مشتری ACME دریافت کرد. سرور بسته بندی وب دارای یک کلاینت داخلی ACME است و sxg-rs به زودی خواهد داشت.
ابزار SXG مخصوص پلتفرم
این ابزارها پشته های فناوری خاصی را پشتیبانی می کنند. اگر قبلاً از پلتفرمی استفاده میکنید که توسط یکی از این ابزارها پشتیبانی میشود، ممکن است راهاندازی آن آسانتر از یک ابزار همهمنظوره باشد.
sxg-rs/cloudflare_worker
روی Cloudflare Workers اجرا می شود.sxg-rs/fastly_compute
روی Fastly Compute@Edge اجرا میشود.Automatic Signed Exchanges یک ویژگی Cloudflare است که به طور خودکار گواهی ها را دریافت کرده و Signed Exchanges را ایجاد می کند.
ماژول NGINX SXG SXGها را برای سایت هایی که از nginx استفاده می کنند تولید و ارائه می کند. دستورالعمل های راه اندازی را می توانید در اینجا پیدا کنید.
Envoy SXG Filter SXGها را برای سایتهایی که از Envoy استفاده میکنند تولید و ارائه میکند.
ابزار SXG همه منظوره
سرور HTTP sxg-rs
sxg-rs http_server به عنوان یک پروکسی معکوس برای سرویس دهی به SXG ها عمل می کند. برای درخواستهای خزندههای SXG، http_server
پاسخهای پشتیبان را امضا میکند و با SXG پاسخ میدهد. برای دستورالعملهای نصب، به README مراجعه کنید.
سرور بسته بندی وب
Web Packager Server ، webpkgserver
، جایگزینی برای sxg-rs http_server است که در Go نوشته شده است. برای دستورالعملهای مربوط به راهاندازی سرور Web Packager، به نحوه راهاندازی مبادلات امضا شده با استفاده از Web Packager مراجعه کنید.
Web Packager CLI
Web Packager CLI یک SXG مربوط به یک URL داده شده تولید می کند.
webpackager \
--private\_key=private.key \
--cert\_url=https://example.com/certificate.cbor \
--url=https://example.com
پس از تولید فایل SXG، آن را در سرور خود آپلود کرده و با نوع application/signed-exchange;v=b3
MIME آن را ارائه دهید. علاوه بر این، باید گواهینامه SXG را به عنوان application/cert-chain+cbor
ارائه دهید.
کتابخانه های SXG
از این کتابخانه ها می توان برای ساخت مولد SXG خود استفاده کرد:
sxg_rs
یک کتابخانه Rust برای تولید SXG است. این ویژگی برجسته ترین کتابخانه SXG است و به عنوان مبنایی برای ابزارهایcloudflare_worker
وfastly_compute
استفاده می شود.libsxg
یک کتابخانه C حداقل برای تولید SXG است. این به عنوان پایه ماژول NGINX SXG و فیلتر Envoy SXG استفاده می شود.go/signed-exchange
یک کتابخانه Go حداقل است که توسط مشخصات بسته وب به عنوان یک پیاده سازی مرجع برای تولید SXG ارائه شده است. این به عنوان مبنایی برای ابزار مرجع CLI،gen-signedexchange
و ابزارهای ویژهتر Web Packager استفاده میشود.
مذاکره محتوا
زمانی که هدر Accept نشان میدهد که مقدار q برای application/signed-exchange بزرگتر یا برابر با q-value برای text/html است، سرورها باید SXG را ارائه دهند. در عمل، این بدان معنی است که یک سرور مبدا SXG را به خزنده ها ارائه می دهد، اما نه مرورگرها. بسیاری از ابزارهای فوق به طور پیش فرض این کار را انجام می دهند، اما برای ابزارهای دیگر، عبارت منظم زیر را می توان برای مطابقت با هدر Accept درخواست هایی که باید به عنوان SXG ارائه شوند استفاده کرد: http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/
این توصیه شامل نمونه هایی برای آپاچی و nginx است.
API حافظه پنهان را به روز کنید
Google SXG Cache دارای یک API است که صاحبان سایت می توانند از آن برای حذف SXGها از حافظه پنهان قبل از انقضا به دلیل Cache-Control: max-age
استفاده کنند. برای جزئیات به مرجع API حافظه پنهان به روز رسانی مراجعه کنید.
پیوند دادن به SXG
هر سایتی می تواند با استفاده از و برچسبها: html <a href="https://example.com/article.html.sxg"> <link rel="prefetch" as="document" href="https://example.com/article.html.sxg">
این مقاله نحوه استفاده از nginx برای توزیع SXG را نشان میدهد.
مزایای منحصر به فرد
SXG یکی از بسیاری از فناوریهای ممکن برای فعال کردن واکشی اولیه متقاطع است. وقتی تصمیم می گیرید از کدام فناوری استفاده کنید، ممکن است لازم باشد بین بهینه سازی جنبه های مختلف معاوضه کنید. بخشهای زیر تعدادی از مقادیر منحصربهفردی را که SXG در فضای راهحلهای ممکن ارائه میکند، نشان میدهد. این عوامل ممکن است در طول زمان با تکامل فضای راه حل های موجود تغییر کنند.
درخواست کمتر برای خدمت
با واکشی اولیه متقاطع سایت، سرور شما ممکن است نیاز به ارائه درخواست های اضافی داشته باشد. این مربوط به مواردی است که یک صفحه از قبل واکشی شده است، اما یا کاربر از صفحه بازدید نکرده است، یا بایت های از پیش واکشی شده به کاربر نشان داده نمی شود. برای SXG، این درخواست های استفاده نشده اضافی را می توان به میزان قابل توجهی کاهش داد:
- SXG ها کش هستند و ممکن است تا زمان انقضا برای کاربران ارسال شوند. بنابراین، بسیاری از واکشیهای اولیه را میتوان تنها توسط سرور کش مدیریت کرد.
- SXG ها را می توان هم با و هم بدون کوکی در سایت شما به کاربران نشان داد. بنابراین، زمانهای کمتری وجود دارد که صفحه بعد از پیمایش مجدداً باید واکشی شود.
بهبود سرعت صفحه
ممکن است به دلیل سطوح واکشی اولیه و قابلیتهایی که در حال حاضر پشتیبانی میکند، بهبود سرعت صفحه بیشتری مشاهده کنید:
- SXG ها را می توان با کوکی های سایت شما به کاربران نشان داد.
- SXG همچنین منابع فرعی صفحات شما مانند جاوا اسکریپت، CSS، فونتها و تصاویر را زمانی که با استفاده از هدر
Link
مشخص میشود، واکشی میکند. - در آینده نزدیک، واکشی اولیه SXG از جستجوی Google در انواع بیشتری از نتایج جستجو در دسترس خواهد بود.
نتیجه گیری
مبادلات امضا شده یک مکانیسم تحویل است که تأیید منشأ و اعتبار یک منبع را مستقل از نحوه تحویل منبع ممکن میسازد. در نتیجه، SXGها را میتوان توسط اشخاص ثالث توزیع کرد و در عین حال اعتبار کامل ناشر را حفظ کرد.
در ادامه مطلب
- پیش نویس مشخصات برای صرافی های HTTP امضا شده
- توضیح دهنده بسته بندی وب
- با مبادلات امضا شده در جستجوی Google شروع کنید
- نحوه راه اندازی Signed Exchanges با استفاده از Web Packager
- نسخه ی نمایشی صرافی های امضا شده
SXG یک مکانیسم تحویل است که تأیید اعتبار منبع یک منبع را مستقل از نحوه تحویل آن ممکن میسازد.
صرافی های امضا شده (SXG) یک مکانیسم تحویل است که احراز هویت مبدا یک منبع را مستقل از نحوه تحویل آن ممکن می سازد. پیادهسازی SXG میتواند بزرگترین رنگ محتوایی (LCP) را با فعال کردن واکشی اولیه متقاطع با حفظ حریم خصوصی بهبود بخشد. علاوه بر این، این جداسازی موارد استفاده مختلفی مانند تجربیات اینترنتی آفلاین و سرویس دهی از حافظه پنهان شخص ثالث را پیش می برد.
این مقاله یک نمای کلی از SXG ارائه می دهد: نحوه کار، موارد استفاده و ابزار.
سازگاری با مرورگر
SXG توسط مرورگرهای مبتنی بر Chromium پشتیبانی می شود (شروع با نسخه های: Chrome 73، Edge 79، و Opera 64).
نمای کلی
به عنوان مورد استفاده اصلی خود، SXG از یک کش برای واکشی و ارائه محتوایی که به صورت رمزنگاری شده توسط مبدا امضا شده است، استفاده می کند. این به سرعت پیمایشهای متقاطع از سایتهای ارجاعدهنده کمک میکند و همچنین تضمین میکند که صفحات بدون تغییر باقی میمانند و به درستی به مبدأ خود نسبت داده میشوند. هر گونه اطلاعات شناسایی بالقوه تا زمانی که کاربر به یک سایت پیمایش کند پنهان می شود و در نتیجه از حریم خصوصی کاربر محافظت می شود. جستجوی گوگل اولین پذیرنده قابلیتهای واکشی اولیه SXG است و برای سایتهایی که بخش زیادی از ترافیک خود را از جستجوی Google دریافت میکنند، SXG میتواند ابزار مهمی برای بارگذاری سریعتر صفحه به کاربران باشد. با گذشت زمان، امیدواریم این تأثیر به ارجاع دهندگان دیگر گسترش یابد.
چگونه کار می کند
یک سایت یک جفت درخواست/پاسخ (یک «مبادله HTTP») را امضا میکند به گونهای که مرورگر را قادر میسازد تا منشأ و یکپارچگی محتوا را مستقل از نحوه توزیع محتوا تأیید کند. در نتیجه، مرورگر میتواند نشانی وب سایت مبدا را به جای نشانی اینترنتی سروری که محتوا را تحویل داده است، در نوار آدرس نمایش دهد.
از لحاظ تاریخی، تنها راهی که یک سایت میتواند از یک شخص ثالث برای توزیع محتوای خود در حین حفظ اعتبار استفاده کند، این بوده است که سایت گواهیهای SSL خود را با توزیعکننده به اشتراک بگذارد. این دارای اشکالات امنیتی است. علاوه بر این، تا اینکه محتوا واقعا قابل حمل باشد فاصله زیادی دارد.
فرمت SXG
یک SXG در یک فایل کدگذاری شده باینری کپسوله شده است که دارای دو جزء اصلی است: یک تبادل HTTP و یک امضا که مبادله را پوشش می دهد. تبادل HTTP شامل یک URL درخواست، اطلاعات مذاکره محتوا و یک پاسخ HTTP است.
format version: 1b3 request: method: GET uri: https://example.org/ headers: response: status: 200 headers: Cache-Control: max-age=604800 Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY= Expires: Mon, 24 Aug 2020 16:08:24 GMT Content-Type: text/html; charset=UTF-8 Content-Encoding: mi-sha256-03 Date: Mon, 17 Aug 2020 16:08:24 GMT Vary: Accept-Encoding signature: label;cert-sha256=<em>ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=</em>; cert-url="https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE"; date=1597680503;expires=1598285303;integrity="digest/mi-sha256-03";sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>; validity-url="https://example.org/webpkg/validity" header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p> <p>The exchange has a valid signature. payload [1256 bytes]:</p> <pre class="prettyprint"><code><title>SXG example</title> <meta charset="utf-8"> <meta http-equiv="Content-type" content="text/html; charset=utf-8"> <style type="text/css"> body { background-color: #f0f0f2; margin: 0; padding: 0; } </style> </code></pre> <div> <h1>Hello</h1> </div> <p>
پارامتر expires
در امضا، تاریخ انقضای SXG را نشان می دهد. SXG ممکن است حداکثر 7 روز معتبر باشد. اطلاعات بیشتر در مورد هدر امضا در مشخصات Signed HTTP Exchanges بیابید.
پشتیبانی از شخصی سازی سمت سرور
یک SXG حاوی هدر Vary: Cookie
فقط برای کاربرانی که کوکیهایی برای URL درخواست امضا شده ندارند نشان داده میشود. اگر سایت شما HTML متفاوتی را به کاربران وارد شده خود ارائه می دهد، می توانید از این ویژگی برای استفاده از SXG ها بدون تغییر آن تجربه استفاده کنید. جزئیات شخصی سازی سمت سرور را با Dynamic SXG ببینید.
بسته بندی وب
SXG بخشی از خانواده پیشنهادی مشخصات بسته بندی وب است. علاوه بر SXGها، جزء اصلی دیگر مشخصات بسته بندی وب ، بسته های وب ("مبادلات HTTP همراه") است. بسته های وب مجموعه ای از منابع HTTP و ابرداده های لازم برای تفسیر بسته هستند.
رابطه بین SXG و Web Bundle یک نقطه سردرگمی رایج است. SXG و Web Bundles دو فناوری متمایز هستند که به یکدیگر وابسته نیستند—بستههای وب را میتوان هم با مبادلات امضا شده و هم بدون امضا استفاده کرد. هدف مشترکی که توسط SXG ها و Web Bundle ها پیش رفته است، ایجاد قالب «بسته بندی وب» است که به سایت ها اجازه می دهد به طور کامل برای مصرف آفلاین به اشتراک گذاشته شوند.
افزایش سرعت بارگذاری صفحات با صرافی های امضا شده
فعال کردن Signed Exchanges میتواند به سرعت بخشیدن به عملکرد صفحه وب کمک کند و در نتیجه بر هسته اصلی وب سایت شما، به ویژه بزرگترین رنگ محتوایی (LCP) تأثیر بگذارد. به عنوان اولین پذیرنده، جستجوی Google از SXG استفاده میکند تا تجربه بارگیری سریعتر صفحه را برای صفحات بارگیری شده از صفحه نتایج جستجو به کاربران ارائه دهد.
جستجوی Google SXGها را در صورت موجود بودن میخزد و ذخیره میکند و SXG را که کاربر احتمالاً از آن بازدید میکند، از پیش واکشی میکند - برای مثال، صفحه مربوط به اولین نتیجه جستجو.
SXG در کنار سایر بهینهسازیهای عملکرد مانند استفاده از CDN و کاهش منابع فرعی مسدودکننده رندر بهترین عملکرد را دارد. پس از پیاده سازی، این توصیه ها را دنبال کنید تا مزایای LCP را از واکشی اولیه SXG به حداکثر برسانید. در بسیاری از موارد، چنین بهینه سازی می تواند منجر به بارگیری تقریباً فوری صفحه از جستجوی Google شود:
تاثیر صرافی های امضا شده
از آزمایشهای گذشته، بهطور متوسط 300 میلیثانیه تا 400 میلیثانیه کاهش در LCP از واکشیهای پیشفرض با قابلیت SXG مشاهده کردهایم. این به سایتها کمک میکند تاثیر اول بهتری بر روی کاربران بگذارند و اغلب تأثیر مثبتی بر معیارهای تجاری دارد.
چندین برند و سایت جهانی قبلاً از Signed Exchanges بهره مند شده اند. به عنوان یک مطالعه موردی، اجازه میدهیم ببینیم که چگونه پیادهسازی Signed Exchanges به RebelMouse ، یک سیستم مدیریت محتوای برجسته (CMS)، کمک کرد تا عملکرد و معیارهای تجاری مشتریان خود را بهبود بخشد:
- Narcity LCP را 41٪ بهبود داد
- Paper Magazine متوجه افزایش 27 درصدی Sessions به ازای هر کاربر شد
- وبلاگ MLT زمان بارگذاری صفحه را 21٪ کاهش داد
Cloudflare دریافت که SXG TTFB را برای 98 ٪ از سایت هایی که آزمایش کرده است بهبود می بخشد و LCP را برای 85 ٪ از سایت ها بهبود می بخشد ، با بهبود متوسط بیش از 20 ٪ در بارهای صفحه واجد شرایط SXG.
نمایه سازی
نمایش های SXG و غیر SXG از یک صفحه با جستجوی Google رتبه بندی یا ایندکس نمی شوند. SXG در نهایت یک مکانیسم تحویل است - محتوای اساسی را تغییر نمی دهد.
AMP
محتوای AMP را می توان با استفاده از SXG تحویل داد. SXG اجازه می دهد تا محتوای AMP با استفاده از URL متعارف خود از قبل استفاده و نمایش داده شود ، به جای AMP URL.AMP از ابزار جداگانه ای برای تولید SXGS.Learn نحوه ارائه خدمات AMP با استفاده از مبادلات امضا شده در amp.dev استفاده می کند.
اشکال زدایی SXG ها با Devtools Chrome
برای دیدن یک دست اول SXG ، از یک مرورگر Chromium استفاده کنید ، Devtools را باز کنید ، پنل شبکه را باز کنید و به این صفحه جستجوی مثال مراجعه کنید. مبادلات امضا شده را می توان با جستجوی signed-exchange
در ستون نوع شناسایی کرد.
![تصویر نشان دهنده درخواست SXG در پانل "شبکه" در DevTools](https://web.developers.google.cn/static/articles/signed-exchanges/image/screenshot-showing-sxg-r-9a4f9df2440b3.png?authuser=0&hl=fa)
برگه Preview اطلاعات بیشتری در مورد محتوای SXG ارائه می دهد.
![تصویر برگه "پیش نمایش" برای SXG](https://web.developers.google.cn/static/articles/signed-exchanges/image/screenshot-the-preview-033e1253a3e1.png?authuser=0&hl=fa)
ابزار سازی
اجرای SXGS شامل تولید SXG مربوط به یک URL معین و سپس خدمت به SXG برای درخواست کنندگان (معمولاً خزنده ها) است.
گواهینامه ها
برای تولید SXG به یک گواهی نیاز دارید که بتواند SXGS را امضا کند ، اگرچه برخی از ابزارها به طور خودکار اینها را به دست می آورند. در این صفحه مقامات گواهینامه ای که می توانند این نوع گواهی را صادر کنند ، ذکر شده است. گواهینامه ها را می توان به طور خودکار از مرجع گواهی Google با استفاده از هر مشتری ACME دریافت کرد. Web Packager Server دارای یک مشتری داخلی ACME است و SXG-RS به زودی خواهد بود.
ابزار SXG خاص سیستم عامل
این ابزارها از پشته های فناوری خاص پشتیبانی می کنند. اگر در حال حاضر از یک بستر پشتیبانی شده توسط یکی از این ابزارها استفاده می کنید ، ممکن است تنظیم آن را از یک ابزار با هدف کلی آسان تر کنید.
sxg-rs/cloudflare_worker
روی کارگران CloudFlare اجرا می شود.sxg-rs/fastly_compute
در Edge@Edge به سرعت محاسبه می شود.مبادلات امضا شده اتوماتیک یک ویژگی CloudFlare است که به طور خودکار گواهینامه ها را به دست می آورد و مبادلات امضا شده را تولید می کند.
ماژول NGINX SXG SXGS را برای سایتهایی که از NGINX استفاده می کنند ، تولید و خدمت می کند. دستورالعمل های راه اندازی را می توان در اینجا یافت.
فیلتر Envoy SXG برای سایتهایی که از فرستاده استفاده می کنند ، SXGS تولید و خدمت می کند.
ابزار SXG با هدف عمومی
سرور HTTP SXG-RS
SXG-RS HTTP_SERVER به عنوان یک پروکسی معکوس برای خدمت به SXGS عمل می کند. برای درخواست از خزنده های SXG ، http_server
پاسخ ها را از پس زمینه امضا کرده و با SXG پاسخ می دهد. برای دستورالعمل های نصب ، به Readme مراجعه کنید.
سرور بسته بندی وب
سرور Web Packager ، webpkgserver
، جایگزینی برای SXG-RS HTTP_SERVER است که در Go نوشته شده است. برای راهنمایی در مورد تنظیم سرور Web Packager ، به نحوه تنظیم مبادلات امضا شده با استفاده از Web Packager مراجعه کنید.
Web Packager CLI
Packager Web CLI یک SXG مربوط به یک URL خاص تولید می کند.
webpackager \
--private\_key=private.key \
--cert\_url=https://example.com/certificate.cbor \
--url=https://example.com
پس از تولید پرونده SXG ، آن را در سرور خود بارگذاری کرده و آن را با application/signed-exchange;v=b3
MIME سرو کنید. علاوه بر این ، شما نیاز به گواهی SXG به عنوان application/cert-chain+cbor
دارید.
کتابخانه های SXG
از این کتابخانه ها می توان برای ساخت ژنراتور SXG خود استفاده کرد:
sxg_rs
یک کتابخانه زنگ زدگی برای تولید SXG است. این ویژگی برجسته ترین کتابخانه SXG است و به عنوان پایه ای برای ابزارهایcloudflare_worker
وfastly_compute
استفاده می شود.libsxg
یک کتابخانه حداقل C برای تولید SXG است. از آن به عنوان پایه ای برای ماژول NGINX SXG و فیلتر SXG Envoy استفاده می شود.go/signed-exchange
یک کتابخانه حداقل GO است که توسط مشخصات وب سایت به عنوان اجرای مرجع تولید SXG ارائه شده است. از آن به عنوان پایه ای برای ابزار مرجع CLI ،gen-signedexchange
و ابزارهای برجسته تر Packager استفاده می شود.
مذاکره محتوا
سرورها باید SXG را خدمت کنند وقتی که هدر پذیرش نشان می دهد که مقدار Q برای کاربرد/تبادل امضا شده بیشتر از یا برابر با ارزش Q برای متن/HTML است. در عمل ، این بدان معنی است که یک سرور Origin به SXG برای خزنده ها خدمت می کند ، اما نه مرورگرها. Many of the above tools do this by default, but for other tools, the following regular expression can be used to match the Accept header of requests that should be served as SXG: http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/
این توصیه شامل نمونه هایی برای Apache و Nginx است.
API Cache را به روز کنید
حافظه نهان Google SXG دارای API است که صاحبان سایت می توانند قبل از انقضا به دلیل Cache-Control: max-age
. برای جزئیات بیشتر به مرجع API Update Cache مراجعه کنید.
پیوند به SXG
هر سایتی می تواند SXG های صفحاتی را که به آن پیوند می دهد ، در صورت وجود ، با استفاده از و برچسب ها: html <a href="https://example.com/article.html.sxg"> <link rel="prefetch" as="document" href="https://example.com/article.html.sxg">
این مقاله نشان می دهد که چگونه از nginx برای توزیع sxgs استفاده می کند.
مزایای منحصر به فرد
SXG یکی از بسیاری از فناوری های ممکن برای فعال کردن پیش بینی های متقاطع است. هنگام تصمیم گیری در مورد استفاده از کدام فناوری ، ممکن است نیاز به تجارت بین بهینه سازی جنبه های مختلف داشته باشید. بخش های زیر تعدادی از مقادیر منحصر به فرد را که SXG در فضای راه حل های ممکن ارائه می دهد ، نشان می دهد. این عوامل ممکن است به مرور زمان تغییر کند زیرا فضای راه حل های موجود تکامل می یابد.
درخواست کمتری برای خدمت
با استفاده از پیش نویس سایت ، سرور شما ممکن است نیاز به درخواست درخواست های اضافی داشته باشد. این مربوط به مواردی است که یک صفحه از آن استفاده می شود ، اما یا کاربر از صفحه بازدید نکرد ، یا بایت های پیش ساخته را نمی توان به کاربر نشان داد. برای SXG ، این درخواست های استفاده نشده اضافی می تواند به طور قابل توجهی کاهش یابد:
- SXG ها ذخیره می شوند و ممکن است تا زمان انقضا برای کاربران ارسال شوند. بنابراین ، بسیاری از پیش نویس ها فقط توسط سرور حافظه نهان قابل استفاده هستند.
- SXG ها را می توان با و بدون کوکی در سایت شما به کاربران نشان داد. بنابراین ، زمان کمتری وجود دارد که صفحه بعد از ناوبری دوباره به آن واگذار شود.
بهبود سرعت صفحه
به دلیل سطوح پیش فرض و قابلیت هایی که در حال حاضر از آن پشتیبانی می کند ، ممکن است بهبود سرعت صفحه را مشاهده کنید:
- SXGS را می توان به کاربران با کوکی برای سایت شما نشان داد.
- SXG همچنین برای صفحات شما ، مانند JavaScript ، CSS ، Fonts و Images ، در صورت مشخص شدن با استفاده از هدر
Link
، منابع فرعی را برای صفحات شما فراهم می کند. - در آینده نزدیک ، پیش بینی SXG از Google Search در انواع نتایج جستجوی بیشتر در دسترس خواهد بود.
نتیجه گیری
مبادلات امضا شده یک مکانیسم تحویل است که امکان تأیید منشأ و اعتبار یک منبع را به طور مستقل از نحوه تحویل این منبع امکان پذیر می کند. در نتیجه ، SXG ها ضمن حفظ انتساب کامل ناشر می توانند توسط شخص ثالث توزیع شوند.