אופטימיזציה של LCP באמצעות Signed Exchange

איך למדוד את ההמרות החתומות ולבצע אופטימיזציה שלהן כדי להפיק מהן את השיפור הגדול ביותר

Devin Mullins

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

ניתן ליצור דפי אינטרנט שאינם מצריכים רשת בנתיב הקריטי לעיבוד הדף לאחר אחזור מראש. בחיבור 4G, טעינת הדף הזו עוברת מ-2.8 ל-0.9 שנ' (ה-0.9 הנותרות מחושבות בעיקר לפי שימוש במעבד):

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

רוב האנשים שמפרסמים היום SXG משתמשים בתכונה החלפה אוטומטית של חתימה אוטומטית (ASX) של Cloudflare (אבל יש גם אפשרויות של קוד פתוח):

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

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

• לנתח את ביצועי SXG באמצעות WebPageTest.
• מנפים באגים בצינור עיבוד הנתונים של SXG אם השלב 'ניתוח' מראה שהוא לא פועל.
• ביצוע אופטימיזציה של דפים לשליפה מראש (prefetch) של SXG, כולל הגדרה אופטימלית של max-age וטעינה מראש של משאבי משנה שחוסמים את העיבוד.
• מדידת השיפור ב-SXG באמצעות Google Analytics על ידי בחירת קבוצות ניסוי ובקרה מתאימות.

מבוא

SXG הוא קובץ שמכיל כתובת URL, קבוצה של כותרות תגובת HTTP וגוף תגובה – כולם חתומים באופן קריפטוגרפי על ידי אישור PKI באינטרנט. כשהדפדפן טוען SXG, הוא מאמת את כל התנאים הבאים:

• ה-SXG עדיין בתוקף.
• החתימה תואמת לכתובת ה-URL, לכותרות, לגוף ולאישור.
• האישור חוקי ותואם לכתובת ה-URL.

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

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

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

ניתוח

כדי לראות את היתרון של מודלים מסוג SXG, כדאי להתחיל בשימוש בכלי של שיעור ה-Lab כדי לנתח את ביצועי ה-SXG בתנאים שניתן לחזור עליהם. אפשר להשתמש ב-WebPageTest כדי להשוות היררכיות Waterfall – ו-LCP – עם או בלי שליפה מראש של SXG.

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

יוצרים בדיקה ללא SXG באופן הבא:

• עוברים אל WebPageTest ונכנסים לחשבון. כניסה לחשבון מאפשרת לשמור את היסטוריית הבדיקות כדי שתוכלו להשוות בקלות מאוחר יותר.
• מזינים את כתובת ה-URL שרוצים לבדוק.
• עוברים אל הגדרות מתקדמות. (נדרשת הגדרה מתקדמת עבור בדיקת ה-SXG, ולכן השימוש בה כאן עוזר לוודא שאפשרויות הבדיקה זהות).
• בכרטיסייה Test Settings (הגדרות בדיקה) ייתכן שכדאי להגדיר את החיבור ל-4G ולהגדיל את 'מספר הבדיקות להפעלה' ל-7.
• לוחצים על הפעלת הבדיקה.

מבצעים את אותם השלבים שלמעלה כדי ליצור בדיקה עם SXG, אבל לפני שלוחצים על הפעלת בדיקה, עוברים לכרטיסייה סקריפט, מדביקים את סקריפט WebPageTest הבא ומשנים את שתי כתובות ה-URL של navigate לפי ההוראות:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

עבור כתובת ה-URL הראשונה של navigate, אם הדף עדיין לא מופיע בתוצאות החיפוש ב-Google, אפשר להשתמש בדף הזה לשליפה מראש כדי ליצור דף תוצאות חיפוש חשוד למטרה הזו.

כדי לזהות את כתובת ה-URL השנייה של navigate, צריך להיכנס לדף באמצעות התוסף ל-Chrome SXG Validator, וללחוץ על סמל התוסף כדי לראות את כתובת ה-URL של המטמון:

לאחר השלמת הבדיקות האלה, עוברים אל היסטוריית בדיקות, בוחרים את שתי הבדיקות ולוחצים על השוואה:

צריך להוסיף את &medianMetric=LCP לכתובת ה-URL להשוואה כדי ש-WebPageTest תבחר את ההפעלה עם חציון LCP בכל צד של ההשוואה. (ברירת המחדל היא חציון לפי מדד המהירות).

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

אם השליפה מראש (prefetch) של SXG בוצעה בהצלחה, ה-Waterfall 'עם SXG' לא כולל שורה ל-HTML, והשליפה של משאבי המשנה מתחילה מוקדם יותר. לדוגמה, אפשר להשוות בין 'לפני' לבין 'אחרי' כאן:

ניפוי באגים

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

פרסום

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

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

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

אם מופיע סימן איקס (❌), לא הוחזר SXG:

אם מפעילים את ה-ASX של Cloudflare, סביר להניח שהסיבה לכך היא שכותרת תגובה של בקרת מטמון מונעת את הסמל הזה. 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 מאחזר SXGs ללא פרטי כניסה של משתמש, ועשוי להציג אותם למבקרים מרובים. אם שולחים HTML שונה למשתמשים שונים על סמך קובץ ה-cookie שלהם, הם עשויים לראות חוויה שגויה, כמו צפייה שהתנתקה.

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

לחלופין, בתוסף ל-Chrome, אתם יכולים להשתמש בכלים כמו curl:

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

או dump-signedexchange:

dump-signedexchange -verify -uri $URL

אם ה-SXG קיים ותקף, תוצג תדפיס של ה-SXG שקריא לבני-אדם. אחרת, תופיע הודעת שגיאה.

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

מוודאים שחיפוש Google נוסף לאינדקס בהצלחה פותחים את כלי הפיתוח ל-Chrome ומחפשים את הדף ב-Google. אם הוא נוסף לאינדקס כ-SXG, הקישור של Google לדף שלך יכלול data-sxg-url שמפנה לעותק של webpkgcache.com:

אם יש סיכוי גבוה שמשתמש ילחץ על התוצאה בחיפוש Google, תתבצע שליפה מראש (prefetch) של התוצאה:

הרכיב <link> מורה לדפדפן להוריד את ה-SXG למטמון השליפה מראש (prefetch). כשהמשתמש ילחץ על האלמנט <a>, הדפדפן ישתמש ב-SXG השמור במטמון כדי לעבד את הדף.

אפשר גם לראות הוכחה לשליפה מראש (prefetch) על ידי מעבר לכרטיסייה 'רשת' בכלי הפיתוח וחיפוש כתובות URL שמכילות את webpkgcache.

אם <a> מפנה אל webpkgcache.com, סימן שההוספה של ההחלפה החתומה לאינדקס בחיפוש Google פועלת. אפשר לדלג קדימה לקטע הטמעת נתונים.

אחרת, יכול להיות ש-Google עדיין לא סרקה מחדש את הדף מאז שהפעלתם את SXG. כדאי לנסות את הכלי לבדיקת כתובות URL של Google Search Console:

הנוכחות של הכותרת digest: mi-sha256-03=... מצביעה על כך ש-Google סרקה בהצלחה את גרסת SXG.

אם הכותרת digest לא קיימת, ייתכן ש-SXG לא הוצג ל-Googlebot או שהאינדקס לא עודכן מאז שהפעלת SXG.

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

הטמעת נתונים

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

אם מופיע סימן וי (✅), אפשר לדלג קדימה אל אופטימיזציה.

אם האתר לא יעמוד בדרישות, יוצג סימן איקס (❌) והודעת אזהרה עם הסיבה:

במקרה הזה, הדף יפעל בדיוק כמו לפני הפעלת SXG. Google תקשר לדף במארח המקורי שלה ללא שליפה מראש של SXG.

אם פג התוקף של העותק שנשמר במטמון והוא מאוחזר מחדש ברקע, יופיע שעון חול (⌛):

גם במסמך Google Developers בנושא SXG יש הוראות לשליחת שאילתות במטמון באופן ידני.

אופטימיזציה

אם בתוסף SXG Validator Chrome מוצגים כל סימני הווי (✅), יש לכם SXG שאפשר להציג למשתמשים! בהמשך תוכלו לקרוא איך לבצע אופטימיזציה של דף האינטרנט כדי ליהנות משיפור הכי גדול של LCP מ-SXG.

max-age

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

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

• max-age=86400 (יום אחד) או יותר מתאים לביצועים
• max-age=120 (2 דקות) לא

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

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

סוכן משתמש

פעם אחת הייתה עלייה במדד LCP כשהשתמשתי ב-SXG שנשלף מראש. הפעלתי WebPageTest תוך השוואה בין תוצאות חציון בלי שליפה מראש (prefetch) של SXG. לחיצה על אחרי למטה:

ראיתי שהשליפה מראש (prefetch) פועלת. ה-HTML מוסר מהנתיב הקריטי, ולכן ניתן לטעון את כל משאבי המשנה מוקדם יותר. אבל ה-LCP – הקו הירוק המקווקו הזה – גדל מ-2 ל-2.1.

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

בדקתי את הנושא וגיליתי שהסיבה להבדל בפריסה היא שהדף משתנה ב-User-Agent, והיה שגיאה בלוגיקה. הוא הוצג בדף של מחשב שולחני למרות שכותרת סריקת ה-SXG צוינה כנייד. לאחר תיקון הבעיה, הדפדפן זיהה שוב את כותרת הדף כרכיב הגדול ביותר שלו.

כשלוחצים על 'אחרי', ראיתי שמדד ה-LCP שנשלף מראש נופל ל-1.3 שניות:

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

• הדף לא Vary על ידי User-Agent (למשל, הוא משתמש בעיצוב רספונסיבי או בכתובות URL נפרדות לניידים/למחשבים).
• אם בדף נעשה שימוש בהצגה דינמית, הוא מציין את עצמו כמיועד לנייד או למחשב בלבד באמצעות <meta name=supported-media content=...>.

משאבי משנה

אפשר להשתמש באובייקטים מסוג SXG כדי לבצע שליפה מראש של משאבי משנה (כולל תמונות) יחד עם ה-HTML. שירות ASX של Cloudflare יסרוק את ה-HTML לאיתור רכיבי <link rel=preload> ממקור זהה (צד ראשון) וימיר אותם לכותרות קישורים תואמות ל-SXG. פרטים בקוד המקור מופיעים כאן וכאן.

אם היא פועלת, יוצגו לך הגדרות נוספות של אחזור מראש מחיפוש Google:

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

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

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

הכלי לאימות SXG לא בודק כרגע משאבי משנה. כדי לנפות באגים, צריך להשתמש בינתיים ב-curl או ב-dump-signedexchange.

מדידה

אחרי ביצוע אופטימיזציה של שיפור ה-LCP במסגרת WebPageTest, מומלץ למדוד את ההשפעה של שליפה מראש של SXG על הביצועים הכוללים של האתר.

מדדים בצד השרת

כשמודדים מדדים בצד השרת, כמו Time to First Byte (TTFB), חשוב לזכור שהאתר מציג SXG רק לסורקים שמקבלים את הפורמט הזה. הגבילו את המדידה של TTFB לבקשות שמגיעות ממשתמשים אמיתיים, ולא מבוטים. ייתכן שתגלו שיצירת SXG מגדילה את ערך ה-TTFB עבור בקשות סורק, אך אין לכך השפעה על חוויית המבקרים שלכם.

מדדים בצד הלקוח

מדדי SXG מניבים את היתרון של המהירות הגבוהה ביותר במדדים בצד הלקוח, במיוחד במדדי LCP. כשמודדים את ההשפעה, אפשר פשוט להפעיל ASX של Cloudflare, להמתין לסריקה מחדש של Googlebot, להמתין עוד 28 ימים עד לצבירת נתונים במדד הליבה לבדיקת חוויית המשתמש באתר (CWV) ולאחר מכן לבחון את נתוני ה-CWV החדשים. עם זאת, ייתכן שיהיה קשה לזהות את השינוי אם תשלבו אותו בין כל השינויים האחרים באותה מסגרת זמן.

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

בשלב זה, שליפה מראש (prefetch) של SXG מתבצעת רק בתנאים מסוימים:

• דפדפן Chromium (למשל, Chrome או Edge מלבד ב-iOS), מגרסה M98 ואילך
• Referer: google.com או דומיינים אחרים של חיפוש Google. (שים לב שב-Google Analytics, תג הפניה חל על כל הצפיות בדף בסשן, ואילו שליפה מראש של SXG חלה רק על הצפייה הראשונה בדף, המקושרת ישירות מחיפוש Google).

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

ניתן לקרוא את הקטע 'מחקר עכשווי' כדי ללמוד איך למדוד 'X% מהצפיות בדפים' ו'איך לשפר את מדד ה-LCP ב-Y אלפיות השנייה'.

מחקר עכשווי

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

• מכשירי iOS: עקב הבדלים במהירות הרשת או החומרה בין המשתמשים שהתקינו את המכשירים האלה.
• דפדפני Chromium ישנים יותר: מאותן סיבות.
• מחשבים: מאותן הסיבות או בגלל שפריסת הדף גורמת לבחירה ב'רכיב הגדול ביותר' אחר.
• ניווטים באותו אתר (מבקרים שנכנסים לקישורים בתוך האתר): מפני שהם יכולים לעשות שימוש חוזר במשאבי משנה שנשמרו במטמון מטעינת הדף הקודמת.

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

יוצרים פלח בהתאמה אישית בשם 'SXG countfability' עם המסננים הבאים ומשלבת ביניהם:

• referrer מתחיל ב-https://www.google.
• Browser תואם בדיוק ל-Chrome
• גרסת Browser תואמת לביטוי הרגולרי ^(9[8-9]|[0-9]{3})
• isSXG תואם בדיוק ל-false

יצירת עותק של הפלח הזה בשם 'SXG', אבל אם המשתנה isSXG תואם בדיוק לערך 'true'.

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

<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% מהצפיות בדף":

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

לוחצים על 'שליחה'. יופיעו התפלגות LCP בשני הפלחים. השדה הזה צריך למלא את ה-Y כדי "לשפר את ה-LCP ב-Y אלפיות השנייה באחוזון ה-75":

נקודות שצריך לשים לב אליהן:

לאחר שמחילים את כל המסננים שצוינו למעלה, טעינת הדף הנגדי של SXG אמורה לכלול:

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

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

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

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

לפני/אחרי המחקר

כדי לאמת את התוצאות מהמחקר העכשווי, מומלץ לבצע השוואה של LCP לפני ואחרי הפעלת SXG. אין להגביל את הצפיות בדפים ל-SXG כדי למנוע את ההטיות הפוטנציאליות שפורטו למעלה. במקום זאת, אפשר לבחון את התוצאות שעומדות בדרישות ל-SXG – הגדרות הפלחים שלמעלה, אבל בלי האילוץ isSXG.

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

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

מומלץ גם לבחון את מדד ה-LCP באחוזון ה-75 לפני ואחרי, כדי לאשר את המחקרים שצוינו. למידה על קבוצת משנה של אוכלוסייה לא בהכרח מספקת לנו מידע על האוכלוסייה הכללית. למשל, נניח שחברת SXG משפרת 10% מטעינות הדפים ב-800 אלפיות השנייה.

• אם אלה כבר היו 10% טעינות הדפים המהירות ביותר, אז לא תהיה לכך השפעה על האחוזון ה-75.
• אם טעינות הדף היו האיטיות ביותר ב-10%, אך הן היו איטיות ביותר מ-800 אלפיות השנייה ביחס ל-LCP באחוזון ה-75 מלכתחילה, לא תהיה לכך השפעה על האחוזון ה-75.

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

ביטול הצטרפות לחלק מכתובות ה-URL

לסיום, אחת הדרכים להשוואת ביצועים של SXG היא להשבית SXG עבור תת-קבוצה מסוימת של כתובות URL באתר. למשל, אפשר להגדיר את הכותרת CDN-Cache-Control: no-store כדי למנוע מ-Cloudflare ASX ליצור SXG. אני ממליץ לא להשתמש בהמלצה.

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

מחקר מסוג Holdback

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

למחקר בשיטת Holdback יש את המאפיינים הבאים:

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

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

סיכום

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

אם יש לך עצות נוספות לתיעוד ביצועים של SXG, נשמח לשמוע. דיווח על באג ב-developer.chrome.com עם השיפורים המוצעים.

מידע נוסף על החלפה חתומה זמין במסמכי התיעוד של web.dev ובתיעוד של חיפוש Google.