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

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

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

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

רוב האנשים שמפרסמים כיום 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 בכל שרת, כל עוד הוא לא פג תוקף ולא השתנה מאז שנחתמו.

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

ניתוח

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

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

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

יוצרים בדיקה באמצעות SXGnavigate

// 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, צריך להיכנס לדף באמצעות התוסף SXG Validator ל-Chrome וללחוץ על סמל התוסף כדי לראות את כתובת ה-URL של המטמון:

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

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

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

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

ניפוי באגים

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

פרסום

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

התוסף מאחזר את כתובת ה-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.

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

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

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

או dump-signedexchange:

dump-signedexchange -verify -uri $URL

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

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

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

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

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

כדי לראות ראיות לשליפה מראש, אפשר לעבור לכרטיסייה 'רשת' בכלי הפיתוח ולחפש כתובות URL שמכילות את webpkgcache.

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

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

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

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

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

הטמעת נתונים

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

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

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

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

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

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

אופטימיזציה

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

גיל מקסימלי

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

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

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

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

סוכן משתמש

פעם אחת, ראיתי עלייה ב-LCP בזמן השימוש ב-SXG שנשלף מראש. הפעלתי את WebPageTest והשוואת תוצאות חציון בלי שליפה מראש של SXG ועם שליפה מראש של 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. שירות Cloudflare ASX יסרוק את ה-HTML של רכיבי <link rel=preload> מאותו מקור (צד ראשון) וימיר אותם לכותרות קישור תואמות SXG. הפרטים בקוד המקור מופיעים כאן וכאן.

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

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

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

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

מדידה

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

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

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

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

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

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

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

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

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

מחקר עכשווי

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

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

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

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

• 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 אמורות לכלול:

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

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

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

מחקר שמירת נתונים

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

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

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

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

סיכום

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

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

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