Addy Osmani

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

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

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

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

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

מבט מעמיק יותר על צדדים שלישיים

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

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

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

מקור: צדדים שלישיים לפי קטגוריה.

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

איך צדדים שלישיים משפיעים על הביצועים?

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

1. הגודל והעלויות של ביצוע הסקריפט: צדדים שלישיים שואפים לרוב לספק פונקציונליות משמעותית 'רק' על ידי הטמעת רכיב <script> או <iframe> בדף. לאחר מכן, הרכיבים האלה מושכים סקריפטים ומשאבים גדולים, וההורדה וההפעלה שלהם נמשכים זמן רב יותר. כמות גדולה מדי של JavaScript גורמת לכך שהשרשור הראשי יהיה עסוק יותר זמן, חוסמת את העיבוד וגורמת לעיכוב באינטראקציות של המשתמשים. חלק מהצדדים השלישיים המובילים ידועים כגורמים לחסימה של ה-thread הראשי למשך 42 אלפיות השנייה עד 1.6 שניות ביותר מ-50% מהאתרים שנבדקו. אם ה-thread הראשי חסום, משך החסימה הכולל (TBT) גבוה. זהו אחד המדדים שמשפיעים על דירוג הביצועים של האתר. בנוסף, הוא גורם לעיכוב בתגובה לאינטראקציות של משתמשים ולפגיעה במדד מהירות התגובה לאינטראקציה באתר (INP) שמשמש למדידת הרספונסיביות של אתרים. לכן, לעלויות של הפעלת הסקריפט יש השפעה משמעותית על הביצועים.

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

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

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

כתוצאה מכך, צדדים שלישיים יכולים להשפיע על כל אחד מהרכיבים של Core Web Vitals או על כולם. רוב צדדים שלישיים משפיעים לרעה על הזמן שבו נטען רכיב התוכן הכי גדול (LCP) ועל הזמן שחלף מהקלט הראשון להצגת התוכן (FID). הטמעות של YouTube חוסמות את השרשור הראשי למשך 4.5 שניות ב-10% מהאתרים בנייד, ולמשך 1.6 שניות לפחות ב-50% מהאתרים שנבדקו. דמיינו את תסכולו של משתמש שיגיע לדף עם 20 סקריפטים כאלה בחיבור איטי. התצוגה החזותית הבאה מ-thirdpartyweb.today מציגה את צדדים שלישיים שיש להם את ההשפעה הגדולה ביותר על הביצועים כרגע.

"ב-4 מיליון האתרים המובילים, כ-2,700 מקורות אחראים לכ-57% מכל זמן הביצוע של הסקריפטים, ו-50 הישויות המובילות כבר אחראיות לכ-47%". - third-party-web

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

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

איך Chrome יכול לעזור?

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

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

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

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

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

הגישה המוצעת

אנחנו מציעים גישה בת שלוש רמות כדי להשיג את התוצאות האלה...

1. **למפתחים יש אפשרות לקבל שיוך מעמיק יותר של ההשפעה של כל צד שלישי באמצעות RUM ובכלים למפתחים של Chrome.**

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

2. **מספקים לעסקים נתיב מואר היטב לטעינה יעילה של משאבים של צד שלישי.**

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

   אנחנו רוצים לטפל בבעיות כאלה גם במסגרות JavaScript ובמערכות ניהול תוכן (CMS) במקרים המתאימים. פרויקטים כמו Aurora וצוות הביצועים של WordPress לימדו אותנו את החשיבות של הגדרות ברירת מחדל מובנות שמאפשרות לפתור בעיות טעינה ידועות. ברירת המחדל שמוטמעת במסגרות ובמערכות ניהול תוכן מנחה את העסקים בדרך מוארת. הן יכולות גם לעזור לסוכנות המשתמשים (לדוגמה, Chrome) בתור רמזים שמאפשרים לה להחיל שיטות ניתוח נתונים (heuristics) כדי לבצע אופטימיזציה של טעינת הדף ושל מדד CWV. רמזים כאלה יכולים לעזור לסוכנות המשתמשים להחליט מתי ואיך יש לטעון צדדים שלישיים ספציפיים במחזור החיים של הדף. (לדוגמה, רכיב הסקריפט של Next.js כולל ברירת מחדל מובנית לטעינה של סקריפטים של צד שלישי אחרי שהדף הופך לאינטראקטיבי).

3. **מומלץ לתת לצדדים שלישיים תמריצים לצמצם את ההשפעה שלהם על הביצועים באמצעות מאמצי שקיפות משופרים.**

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

אתגרים

מאמץ בהיקף כזה לא נטול אתגרים. אלה כמה מהאתגרים העיקריים שאנחנו צריכים לקחת בחשבון:

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

אנחנו מקווים שנוכל לשתף פעולה עם קטגוריות שונות של צדדים שלישיים, להבין את הניואנסים, לפתור את הפשרות ולפתח תמריצים שיתאימו לכולם. אנחנו מבינים שאנחנו צריכים לעבוד בנפרד עם ישויות בכל תחום כדי שהאסטרטגיה שלנו תהיה יעילה. הוא כולל את השותפים הפנימיים שלנו, כמו Google Tag Manager, ‏ Google Ads ו-YouTube.

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

2. אנחנו מציעים לשפר את Chrome כדי שיוכל להחיל אופטימיזציות שיעזרו למצוא את האיזון הנכון לקביעת סדר העדיפויות של הטעינה של משאבים מצד ראשון לעומת משאבים של צד שלישי. שינוי חשוב הופך לזמין כסטנדרט בכל הדפדפנים, אבל זה לוקח זמן. לדוגמה, המאפיין loading של הרכיבים <img> ו-<iframe> זמין ב-Chrome/Edge מאז 2019, אבל הפך לזמין ב-Safari רק ב-2022. עד שהתכונה תהיה סטנדרטית, משתמשים במשאבים של צד שלישי יצטרכו לוודא שהם ביצעו אופטימיזציה גם לדפדפנים אחרים. אנחנו נעזור לכם בכך ונדגיש את הנושא הזה בהנחיות שלנו במקרים הרלוונטיים.

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

הצעות ראשוניות לתקנים

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

LazyEmbeds

בעבר, Chrome טען באיטרציות רכיבי <img> ו-<iframe> מחוץ למסך למשתמשים במצב טעינה מהירה. אפשר להרחיב את התכונה הזו לכל המשתמשים כדי לדחות את טעינת הרכיבים של <iframe> שנקבעו כרכיבים מוטמעים של צד שלישי, עד שהמשתמש גולל לידיהם. הפעולה הזו עשויה לזרז את הטעינה של חלקים אחרים בדף, לשפר את המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals), לצמצם את השימוש בזיכרון ולחסוך נתונים.

הנה הדגמה לשימוש ב-LazyEmbeds כדי לטעון סרטוני YouTube בדף באופן איטי. הטמעה של סרטון YouTube אחד בדרך כלל מוסיפה לדף 500-600KB של JavaScript. ניסינו לבצע אופטימיזציה של פוסט בבלוג עם 14 הטמעות כאלה של סרטונים באמצעות LazyEmbeds. התוצאות היו מבטיחות מבחינת זמן טעינת הדף וחיסכון בנתונים.

מידע נוסף על העבודה הזו זמין במאמר ההסבר שלנו, בשרשור בנושא כוונה לערוך ניסוי ובתוסף הניסוי ב-blink-dev.

הגבלת קצב שליחת הבקשות (Throttling) ממקורות צד שלישי באופן מותאם אישית

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

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

שיפור ממשקי ה-API של RUM

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

1. דיווח על <iframe>: אנחנו עובדים על פתרונות שיכולים להשתמש ב-API של Performance Timeline לדיווח על פריימים שונים. כך יהיה אפשר לאפשר לכותבים של הדף ברמה העליונה לבדוק את נתוני הביצועים של iframe של צד שלישי שתומך בכך, שמוטמע בדף.

2. שיוך של משימות ארוכות: Long Tasks API ב-RUM יעזור לבעלי אתרים לזהות משימות ארוכות שגורמות לעיכוב של האינטראקציה על ידי ייצור עומס על ה-thread הראשי למשך זמן רב.

עדכונים נוספים

אנחנו עדיין בודקים רעיונות רבים כאלה, ומקווים לפרסם הסברים ב-GitHub וטיוטות של מפרטים לשינויים במהלך הדרך. צדדים שלישיים ובעלי אתרים שרוצים לשתף איתנו פעולה או לשלוח משוב יכולים להשתתף בדיונים דרך הפורומים האלה. צדדים שלישיים יכולים גם להתחיל להתמקד באופטימיזציה של מדדי Core Web Vitals ו-INP כדי להבטיח שלא ישויכו אליהם נתונים נמוכים של Core Web Vitals או INP. בינתיים, מי שמחפש עדכונים באופן פעיל יכול לעיין בפוסטים בקבוצה blink-dev.

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

תודה מיוחדת ל-Leena Sohoni-Kasture, ‏ Jeremy Wagner, ‏ Gilberto Cocchi, ‏ Kenji Baheux, ‏ Kouhei Ueno, ‏ Kentaro Hara, ‏ Alex N. Jose,‏ Melissa Mitchell,‏ Yoav Weiss,‏ Shunya Shishido ו-Minoru Chikamune על המשוב והתרומות שלהם.