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

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

Katie Hempenius
Katie Hempenius
X
Devin Mullins
Devin Mullins
X GitHub

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

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

תאימות דפדפן

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

סקירה כללית

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

איך זה עובד

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

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

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

פורמט SXG

SXG מוקף בקובץ בקידוד בינארי שכולל שני רכיבים עיקריים: חילופי 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 Exchange.

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

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

אריזת אינטרנט

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

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

האצה של טעינת דפים באמצעות החלפה חתומה

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

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

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

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

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

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

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

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

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

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

AMP

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

ניפוי באגים של SXGs באמצעות כלי הפיתוח ל-Chrome

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

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

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

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

כלים

הטמעה של 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, הוא חלופה ל-http_server sxg-rs, שכתוב ב-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 מינימלית שמסופקת על ידי מפרט חבילת האינטרנט כהטמעה של הפניה של יצירת מודלים של SXG. הוא משמש כבסיס לכלי ה-CLI להתייחסות שלו, gen-signedexchange ולכלים המתקדמים יותר ל-Web Packager.

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

שרתים צריכים להציג SXG כאשר הכותרת Accept מציינת ש-q-value עבור application/signed-exchange גדול מהערך או שווה ל-q-value של 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 היא אחת מהטכנולוגיות הרבות האפשריות שמאפשרת שליפה מראש (prefetch) ממקורות שונים. כשאתם מחליטים באיזו טכנולוגיה להשתמש, ייתכן שתצטרכו להחליף בין אופטימיזציה של היבטים שונים. הקטעים הבאים ממחישים כמה מהערכים הייחודיים ש-SXG מספק בתחום הפתרונות האפשריים. הגורמים האלה עשויים להשתנות עם הזמן, ככל שמרחב הפתרונות הזמינים מתפתח.

פחות בקשות להצגת מודעות

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

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

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

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

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

סיכום

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

קריאה נוספת