האם דפדפנים יכולים לבצע אופטימיזציה לטעינה של משאבים של צד שלישי?

Addy Osmani
Addy Osmani

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

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

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

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

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

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

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

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

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

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

קטגוריה הגדרה
פרסום סקריפטים שמשמשים להצגת מודעות או למדידת ביצועים של מודעות.
וידאו סקריפטים שמאפשרים פונקציונליות של סטרימינג ונגן וידאו.
ספריות מתארחות שילוב של ספריות קוד פתוח שמתארחות באירוח ציבורי.
Content סקריפטים מספקי תוכן או ממעקב ספציפי של שותפים עצמאיים
הצלחת לקוחות סקריפטים מתמיכת לקוחות או מספקי שיווק שמציעים פתרונות לצ'אט וליצירת קשר.
אירוח סקריפטים מפלטפורמות לאירוח באינטרנט.
שיווק סקריפטים מכלי שיווק שמוסיפים חלונות קופצים, ניוזלטרים ועוד.
רשתות חברתיות סקריפטים שמאפשרים תכונות חברתיות.
Tag Manager סקריפטים שטוענים סקריפטים רבים אחרים ויוזמים משימות רבות.
ניתוח נתונים סקריפטים שמודדים או עוקבים אחר משתמשים והפעולות שלהם.
פלטפורמה לקבלת הסכמה לקובצי cookie סקריפטים שמאפשרים לאתרים לקבל את הסכמת המשתמש (GDPR, ePR, CCPA) בצורה מושכלת ושקופה.
כלי עזר סקריפטים שהם כלים למפתחים (לקוחות API, מעקב אחר אתרים, זיהוי הונאות ועוד.
אחר סקריפטים שונים שהועברו דרך מקור משותף, ללא קטגוריה או שיוך מדויקים.

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

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

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

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

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

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

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

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

תצוגה חזותית של נתוני אתר של צד שלישי

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

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

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

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

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

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

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

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

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

הצעה לגישה

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

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

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

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

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

    בדומה לכך, נשמח לטפל בבעיות כאלה ב-frameworks ובמערכות ניהול תוכן (CMS) של JavaScript, במקרים הרלוונטיים יותר. פרויקטים כמו Aurora וצוות הביצועים של WordPress לימדו אותנו למה חשוב להשתמש בברירות מחדל מוטמעות כדי לפתור בעיות ידועות בטעינה. ברירות המחדל המשולבות ב-frameworks וב-CMS מנחים את העסקים בנתיב מואר היטב. הם יכולים גם להיות שימושיים לסוכן המשתמש (לדוגמה, Chrome) כרמזים שמאפשרים לו להחיל היוריסטיקה כדי לבצע אופטימיזציה של טעינת הדף ושל 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> עבור משתמשי מצב Lite שלנו. אפשר להרחיב את התכונה הזו לכל המשתמשים כדי לדחות את הטעינה של רכיבי <iframe>, שנקבע שהם הטמעות של צד שלישי עד שהמשתמש גולל בקרבתם. הפעולה הזו יכולה להאיץ את הטעינה של חלקים אחרים בדף, לשפר את מדדי הליבה לבדיקת חוויית המשתמש באתר, לצמצם את השימוש בזיכרון ולחסוך בנתונים.

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

לפני אחרי
נתונים 15.4 MB 6.1 MB
זמן החסימה הכולל 3.2 שניות 1.6 שניות

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

ויסות נתונים ממוקד של צד שלישי

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

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

ממשקי API של RUM משפרים

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

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

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

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

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

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

עם תודות מיוחדות ללינה סוהוני, קסטור, Jeremy Wagner, Gilberto Cocchi, Kenji Baheux, Kouhei Ueno, Kentaro Hara, Alex N. חוזה, מליסה מיטשל, יואב וייס, שוניה שישידו ומינורו צ'יקמונה על המשוב והתרומה שלהם.