המרות חתומות (SXG)

SXG הוא מנגנון העברה שמאפשר לאמת את המקור של משאב ללא קשר לאופן שבו הוא הועבר.

Katie Hempenius
Katie Hempenius
Devin Mullins
Devin Mullins

חילופי נתונים חתומים (SXG) הם מנגנון העברה שמאפשר לאמת את המקור של משאב ללא קשר לאופן שבו הוא הועבר. הטמעה של SXG יכולה לשפר את Largest Contentful Paint (LCP) על ידי הפעלה של שליפה מראש (prefetch) ממקורות שונים תוך שמירה על הפרטיות. בנוסף, הפענוח הזה מקדם מגוון של תרחישים לדוגמה, כמו חוויית משתמש באינטרנט אופליין והצגה ממטמון של צדדים שלישיים.

במאמר הזה נספק סקירה כללית מקיפה על SXG: איך הוא עובד, תרחישי לדוגמה וכלים.

תאימות דפדפן

יש תמיכה ב-SXG בדפדפנים המבוססים על Chromium (החל מגרסאות: Chrome 73,‏ Edge 79 ו-Opera 64).

סקירה כללית

בתרחיש לדוגמה העיקרי, ה-SXG משתמש במטמון כדי לבצע אחסון מראש ולהציג תוכן שחתם עליו המקור באופן קריפטוגרפי. כך אפשר לזרז את הניווט בין מקורות מאתרים מפנים, תוך הבטחה שהדפים לא ישתנו ושיוכלו לשייך אותם למקור שלהם בצורה נכונה. כל מידע שעשוי לזהות את המשתמש מוסתר עד שהמשתמש מנווט לאתר, וכך מגינים על הפרטיות שלו. חיפוש Google הוא אחד מהמפתחים הראשונים שהשתמשו ביכולות של SXG לטעינה מראש. לאתרים שמקבלים חלק גדול מהתנועה שלהם מחיפוש Google, SXG יכול להיות כלי חשוב לטעינה מהירה יותר של דפים למשתמשים. עם הזמן, אנחנו מקווים שההשפעה הזו תתרחב למקורות הפניה נוספים.

איך זה עובד

אתר חותם על זוג בקשה/תגובה ('החלפת HTTP') באופן שמאפשר לדפדפן לאמת את המקור ואת השלמות של התוכן, ללא קשר לאופן שבו התוכן הופץ. כתוצאה מכך, הדפדפן יכול להציג בסרגל הכתובות את כתובת ה-URL של אתר המקור, במקום את כתובת ה-URL של השרת שהעביר את התוכן.

תרשים שמסביר איך פועלים חילופי מודעות חתומות. דפדפן שמתקשר עם המטמון שמתקשר עם אתר היעד

בעבר, הדרך היחידה שבה אתר יכול היה להשתמש בצד שלישי כדי להפיץ את התוכן שלו תוך שמירה על השיוך (Attribution) הייתה לשתף את אישורי ה-SSL שלו עם המפיץ. לכך יש חסרונות אבטחה, וגם זה רחוק מלהפוך את התוכן לנייד באמת.

פורמט SXG

קובץ SXG הוא בקופסה (encapsulated) בקובץ מקודד בינארי שכולל שני רכיבים עיקריים: החלפה של HTTP וחתימה שמכסה את ההחלפה. החלפת ה-HTTP מורכבת מכתובת URL של בקשה, מידע על ניהול משא ומתן על תוכן ותשובת HTTP.

דוגמה לקובץ SXG מפוענח:

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=&quot;https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE&quot;;
    date=1597680503;expires=1598285303;integrity=&quot;digest/mi-sha256-03&quot;;sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>;
    validity-url=&quot;https://example.org/webpkg/validity&quot;
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p>

<p>The exchange has a valid signature.
payload [1256 bytes]:</p>
<pre class="prettyprint"><code>&lt;title&gt;SXG example&lt;/title&gt;
&lt;meta charset=&#34;utf-8&#34;&gt;
&lt;meta http-equiv=&#34;Content-type&#34; content=&#34;text/html; charset=utf-8&#34;&gt;
&lt;style type=&#34;text/css&#34;&gt;
body {
    background-color: #f0f0f2;
    margin: 0;
    padding: 0;
}
&lt;/style&gt;
</code></pre>
<div>
    <h1>Hello</h1>
</div>

<p>

הפרמטר expires בחתימה מציין את תאריך התפוגה של ה-SXG. קוד SXG יכול להיות בתוקף למשך 7 ימים לכל היותר. מידע נוסף על כותרת החתימה זמין במפרט של Signed HTTP Exchanges.

תמיכה בהתאמה אישית בצד השרת

קובץ SXG שמכיל כותרת Vary: Cookie יוצג רק למשתמשים שאין להם קובצי cookie לכתובת ה-URL של הבקשה החתומה. אם האתר שלכם מציג HTML שונה למשתמשים שמחוברים לחשבון, תוכלו להשתמש בתכונה הזו כדי ליהנות מהיתרונות של SXG בלי לשנות את חוויית המשתמש. מידע נוסף על התאמה אישית בצד השרת באמצעות SXG דינמי

אריזת אתר

ה-SXG הוא חלק ממשפחת ההצעות הרחבה יותר של חבילת אתר. בנוסף ל-SXG, המרכיב העיקרי השני במפרט של אריזת האתרים הוא חבילות לאתרים ('חילופי HTTP מקובצים'). חבילות אינטרנט הן אוסף של משאבי HTTP והמטא-נתונים הנדרשים כדי לפרש את החבילה.

הקשר בין קובצי SXG לבין חבילות לאתרים הוא נושא שגורם לבלבול לעיתים קרובות. ‏SXG ו-Web Bundles הן שתי טכנולוגיות נפרדות שלא תלויות זו בזו. אפשר להשתמש ב-Web Bundles גם עם החלפות חתומות וגם עם החלפות לא חתומות. יעד נפוץ שמשיגים בעזרת SXG וחבילות Web Bundle הוא יצירת פורמט של "אריזה באינטרנט", שמאפשר לשתף אתרים בשלמותם לצריכה במצב אופליין.

האצת טעינות הדפים באמצעות Signed Exchanges

הפעלת Signed Exchanges יכולה לעזור לכם להאיץ את הביצועים של דפי האינטרנט, וכך להשפיע על מדדי הליבה לבדיקת חוויית המשתמש באתר, ובמיוחד על המהירות שבה נטען רכיב התוכן הכי גדול (LCP). אנחנו משתמשים ב-SXG בחיפוש Google כדי לספק למשתמשים חוויית טעינה מהירה יותר של דפים שנטענים מדף תוצאות החיפוש.

חיפוש Google סורק ומאחסן במטמון קובצי SXG כשהם זמינים, ומאחסן מראש קובצי SXG שהמשתמשים צפויים לבקר בהם – לדוגמה, הדף שתואם לתוצאת החיפוש הראשונה.

ה-SXG פועל בצורה הטובה ביותר בשילוב עם אופטימיזציות אחרות של ביצועים, כמו שימוש ב-CDN והפחתת משאבי משנה שמונעים עיבוד. לאחר ההטמעה, כדאי ליישם את ההמלצות האלה כדי למקסם את התועלת של ה-LCP משליפה מראש של SXG. במקרים רבים, אופטימיזציה כזו יכולה לגרום לטעינה כמעט מיידית של דפים שמגיעים מחיפוש Google:

ההשפעה של החלפות חתומות

בניסויים קודמים ראינו ירידה ממוצעת של 300 אלפיות השנייה עד 400 אלפיות שנייה ב-LCP כתוצאה משליפה מראש (prefetch) שתומכת ב-SXG. כך האתרים יכולים ליצור רושם ראשוני טוב יותר על המשתמשים, ולעיתים קרובות יש לכך השפעה חיובית על מדדי העסק.

כמה מותגים ואתרים גלובליים כבר נהנו מהיתרונות של Signed Exchanges. כמקרה לדוגמה, נבחן איך ההטמעה של 'החלפה חתומה' עזרה ל-RebelMouse, מערכת ניהול תוכן (CMS) בולטת, לשפר את הביצועים והמדדים העסקיים של הלקוחות שלה:

  • ב-Narcity שיפרו את ה-LCP ב-41%
  • ב-Paper Magazine זיהו עלייה של 27% במספר הסשנים לכל משתמש
  • זמן הטעינה של הדף הופחת ב-21% בבלוג MLT

Cloudflare גילתה ש-SXG שיפר את ה-TTDFB ב-98% מהאתרים שבדקתי, וגם שיפר את מדד ה-LCP ב-85% מהאתרים, עם שיפור חציוני של יותר מ-20% בטעינות הדפים שעומדים בדרישות ל-SXG.

הוספה לאינדקס

מערכת חיפוש Google לא מדרגת או מוסיפה לאינדקס באופן שונה את הייצוגים של דף בפורמט SXG ואת הייצוגים שלו בפורמטים אחרים. בסופו של דבר, SXG הוא מנגנון העברה – הוא לא משנה את התוכן הבסיסי.

AMP

אפשר להעביר תוכן AMP באמצעות SXG. SXG מאפשר שליפה מראש (prefetch) של תוכן AMP והצגתו באמצעות כתובת ה-URL הקנונית, במקום באמצעות כתובת ה-URL של ה-AMP.ל-AMP יש כלים נפרדים ליצירת SXG.ב-amp.dev מוסבר איך להציג דפי AMP באמצעות המרות חתומות.

ניפוי באגים בקובצי SXG באמצעות כלי פיתוח ל-Chrome

כדי לראות תמונה של SXG באופן אישי, צריך להשתמש בדפדפן Chromium, לפתוח את כלי הפיתוח, לפתוח את החלונית 'רשת' ולהיכנס לדף החיפוש לדוגמה. כדי לזהות המרות חתומות, מחפשים את signed-exchange בעמודה Type.

צילום מסך שבו מוצגת בקשת SXG בחלונית &#39;רשת&#39; בכלי הפיתוח
החלונית Network ב-DevTools

בכרטיסייה תצוגה מקדימה מוצג מידע נוסף על התוכן של קובץ SXG.

צילום מסך של הכרטיסייה &#39;תצוגה מקדימה&#39; של קובץ SXG
הכרטיסייה תצוגה מקדימה בכלי הפיתוח

כלים

הטמעת קובצי SXG כוללת יצירת קובץ SXG שתואם לכתובת URL מסוימת, ולאחר מכן הצגת קובץ ה-SXG הזה לבקשות (בדרך כלל סורקים).

אישורים

כדי ליצור קובץ SXG, צריך אישור שאפשר לחתום על קובצי SXG באמצעותו, אבל חלק מהכלים מקבלים את האישור הזה באופן אוטומטי. בדף הזה מפורטות רשויות האישורים שיכולות להנפיק אישורים מהסוג הזה. אפשר לקבל אישורים באופן אוטומטי מרשות האישורים של Google באמצעות כל לקוח ACME. לשרת Web Packager יש לקוח ACME מובנה, ול-sxg-rs יהיה בקרוב.

כלים ספציפיים לפלטפורמה ליצירת קובצי SXG

הכלים האלה תומכים בסטאקציות של טכנולוגיות ספציפיות. אם אתם כבר משתמשים בפלטפורמה שנתמכת על ידי אחד מהכלים האלה, אולי יהיה לכם קל יותר להגדיר כלי מאשר שימוש כללי.

כלים ל-SXG לשימוש כללי

שרת HTTP מסוג sxg-rs

sxg-rs http_server פועל בתור שרת proxy הפוך להצגת קובצי SXG. בבקשות מסורקים של SXG, http_server יחתום על התשובות מהקצה העורפי וישלח תשובה בפורמט SXG. הוראות ההתקנה מפורטות בקובץ README.

שרת Web Packager

שרת Web Packager,‏ webpkgserver, הוא חלופה ל-sxg-rs http_server, שנכתב ב-Go. להוראות להגדרת השרת של Web Packager, ראו איך מגדירים חילופי חתימה באמצעות Web Packager.

CLI של Web Packager

Web Packager CLI יוצר קובץ SXG שמתאים לכתובת URL נתונה.

webpackager \
    --private\_key=private.key \
    --cert\_url=https://example.com/certificate.cbor \
    --url=https://example.com

אחרי שיוצרים את קובץ ה-SXG, מעלים אותו לשרת ומציגים אותו עם סוג ה-MIME application/signed-exchange;v=b3. בנוסף, תצטרכו להציג את אישור ה-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 מינימלית שסופקת על ידי מפרט חבילת ה-web כהטמעת עזר ליצירת קובצי SXG. הוא משמש כבסיס לכלי ה-CLI לדוגמה, gen-signedexchange, ולכלים העשירים יותר של Web Packager.

משא ומתן על תוכן

שרתים צריכים להציג קובצי SXG כשכותרת ה-Accept מציינת שערך ה-q של application/signed-exchange גדול מערך ה-q של text/html או שווה לו. בפועל, המשמעות היא ששרת מקור יציג SXG לסורקים, אבל לא לדפדפנים. רבים מהכלים שלמעלה עושים זאת כברירת מחדל, אבל בכלים אחרים, אפשר להשתמש בביטוי הרגולרי הבא כדי להתאים לכותרת 'אישור' של בקשות שאמורות להיות מוצגות כ-SXG: http Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

ההמלצה הזו כוללת דוגמאות ל-Apache ול-nginx.

עדכון המטמון API

למטמון SXG של Google יש ממשק API שבעלי אתרים יכולים להשתמש בו כדי להסיר קובצי SXG מהמטמון לפני שתוקפם יפוג עקב Cache-Control: max-age. פרטים נוספים זמינים בהפניית API לעדכון מטמון.

קישור ל-SXG

כל אתר יכול לשמור במטמון, להציג ולבצע אחזור מראש של קובצי 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 היא אחת מהטכנולוגיות הרבות שאפשר להשתמש בהן כדי להפעיל אחסון מקדים (prefetching) ממקורות שונים. כשמחליטים באיזו טכנולוגיה להשתמש, יכול להיות שתצטרכו להחליט איזה היבט תרצו לשפר. בקטעים הבאים מפורטים כמה מהערכים הייחודיים ש-SXG מספק במרחב הפתרונות האפשריים. הגורמים האלה עשויים להשתנות עם הזמן, ככל שהמגוון של הפתרונות הזמינים יתפתח.

פחות בקשות להצגה

כשמשתמשים בטעינה מראש בכמה אתרים, יכול להיות שהשרת יצטרך להגיש בקשות נוספות. המצב הזה מתאים למקרים שבהם דף אוחזר מראש, אבל המשתמש לא ביקר בדף או שלא ניתן היה להציג למשתמש את הבייטים שאוחזרו מראש. עבור SXG, ניתן לצמצם באופן משמעותי את הבקשות הנוספות הבאות שלא נעשה בהן שימוש:

  • קובצי SXG נשמרים במטמון ויכול להיות שיישלחו למשתמשים עד שיפוג התוקף שלהם. לכן, שרת המטמון יכול לטפל בהרבה פעולות של אחזור מראש.
  • ניתן להציג SXG למשתמשים עם או בלי קובצי Cookie באתר שלכם. כך, יהיו פחות מקרים שבהם יהיה צורך לאחזר מחדש את הדף אחרי ניווט.

שיפור מהירות הדף

יכול להיות שתבחינו בשיפור נוסף במהירות הדף בגלל הפלטפורמות והיכולות של האחסון המקדים שנתמכות כרגע:

  • אפשר להציג מודעות SXG למשתמשים עם קובצי cookie של האתר שלכם.
  • ‏SXG מבצע גם אחזור מראש של משאבי משנה לדפים, כמו JavaScript,‏ CSS, גופנים ותמונות, כאשר הם מצוינים באמצעות כותרת Link.
  • בעתיד הקרוב, האחסון המקדים של SXG מחיפוש Google יהיה זמין בסוגי תוצאות חיפוש נוספים.

סיכום

Signed Exchanges הוא מנגנון העברה שמאפשר לאמת את המקור והתוקף של משאב, ללא קשר לאופן שבו המשאב הועבר. כתוצאה מכך, צדדים שלישיים יכולים להפיץ מודעות SXG תוך שמירה על שיוך מלא של בעלי התוכן הדיגיטלי.

קריאה נוספת