טעינת JavaScript של צד שלישי

Addy Osmani

Arthur Evans

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

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

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

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

מהם סקריפטים של צד שלישי?

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

• לחצני שיתוף ברשתות חברתיות (Facebook, X, LinkedIn, Mastodon)

• הטמעות של נגני וידאו (YouTube, Vimeo)

• מסגרות iframe לפרסום

• סקריפטים של Analytics ומדדים

• סקריפטים של בדיקת A/B לניסויים

• ספריות מסייעות, כמו עיצוב תאריך, אנימציה או ספריות פונקציונליות

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

<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

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

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

• שליחה של יותר מדי JavaScript תעסיק את ה-thread הראשי. יותר מדי JavaScript עלול לחסום את בניית ה-DOM, ולכן השהיה של עיבוד הדפים. ניתוח וביצוע של סקריפטים שצורכים הרבה משאבי מעבד (CPU) עלולים לעכב את האינטראקציה של המשתמש ולגרום להתרוקנות הסוללה.

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

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

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

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

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

• שימוש בממשקי API מדור קודם שידוע שהם פוגעים בחוויית המשתמש, למשל document.write().

• יותר מדי רכיבי DOM או סלקטורים ב-CSS יקרים.

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

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

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

איך מזהים סקריפט של צד שלישי בדף?

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

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

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

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

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

איך אפשר למדוד את ההשפעה של סקריפט של צד שלישי על הדף שלי?

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

ביקורת בזמן ההפעלה של Lighthouse

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

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

ביקורת על מטענים ייעודיים (payloads) ברשת של Lighthouse

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

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

חסימת בקשות ברשת כלי הפיתוח ל-Chrome

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

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

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

.

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

החלונית 'ביצועים' בכלי הפיתוח ל-Chrome עוזרת לזהות בעיות בביצועי הדף באינטרנט.

1. לוחצים על הקלטה.
2. לטעון את הדף. בכלי הפיתוח מוצג תרשים מפל מים שמייצג את זמן הטעינה של האתר שלכם.
3. עוברים אל הקטע למטה למעלה בתחתית החלונית 'ביצועים'.
4. לוחצים על קיבוץ לפי מוצר וממיינים את הסקריפטים של צד שלישי בדף לפי זמן טעינה.

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

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

אלה תהליך העבודה המומלץ שלנו למדידת ההשפעה של סקריפטים של צד שלישי:

1. אפשר להשתמש בחלונית 'רשת' כדי למדוד כמה זמן לוקח לטעון את הדף.
   • כדי לחקות תנאים בעולם האמיתי, מומלץ להפעיל את האפשרויות ויסות רשת וויסות נתונים של מעבד (CPU). סביר להניח שהמשתמשים שלכם לא יצטרכו את החיבורים המהירים לרשת והחומרה למחשב שמפחיתה את ההשפעה של סקריפטים יקרים בתנאי שיעור Lab.
2. חוסמים את כתובות ה-URL או את הדומיינים שאחראים לסקריפטים של צד שלישי שלדעתכם הם בעייתיים (עיינו בחלונית הביצועים של כלי הפיתוח ל-Chrome לקבלת הנחיות לגבי זיהוי סקריפטים יקרים).
3. טוענים מחדש את הדף ומודדים שוב את זמן הטעינה.
   • כדי לקבל נתונים מדויקים יותר, מומלץ למדוד את זמן הטעינה לפחות שלוש פעמים. כך נוצרים סקריפטים של צד שלישי שמאחזרים משאבים שונים בכל טעינת דף. כדי לעזור לכם בכך, חלונית הביצועים של כלי הפיתוח תומכת בהקלטות מרובות.

מדידת ההשפעה של סקריפטים של צד שלישי באמצעות WebPageTest

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

בחלונית הזו מציינים את הדומיינים שרוצים לחסום.

מומלץ לפעול לפי תהליך העבודה הבא כדי להשתמש בתכונה הזו:

1. בדיקת דף בלי לחסום צדדים שלישיים.
2. חוזרים על הבדיקה עם כמה צדדים שלישיים חסומים.
3. בוחרים את שתי התוצאות מהיסטוריית הבדיקות.
4. לוחצים על השוואה.

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

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

ההשפעה של חסימת משאבים של צד שלישי החל מ שימוש ב-WebPageTest למדידת ההשפעה של תגים של צד שלישי מאת אנדי דייוויס.

WebPageTest תומך גם בשתי פקודות שפועלות ברמת ה-DNS לחסימת דומיינים:

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

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

אפשר להשתמש בתכונת הבדיקה SPOF כדי לדמות את הכשל בדומיינים שצוינו.

זיהוי מסגרות iframe יקרות באמצעות משימות ארוכות

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

כדי לזהות משימות ארוכות ב-Real User Monitoring (RUM), אפשר להשתמש ב-API של PerformanceObserver ב-JavaScript כדי לעיין ברשומות longtask. הערכים האלה מכילים מאפיין שיוך שאפשר להשתמש בו כדי לקבוע איזה הקשר מסגרת גרם למשימה הארוכה.

הקוד הבא מתעד את רשומות longtask במסוף, כולל אחת ל-iframe "יקר":

<script>
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Attribution entry including "containerSrc":"https://example.com"
      console.log(JSON.stringify(entry.attribution));
    }
  });

  observer.observe({entryTypes: ['longtask']});
</script>

<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>

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

איך אתם טוענים סקריפט של צד שלישי ביעילות?

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

• כדי למנוע חסימה של ניתוח המסמך, צריך לטעון את הסקריפט באמצעות המאפיין async או defer.
• אם השרת של הצד השלישי איטי, אפשר לארח את הסקריפט באירוח עצמי.
• אם הסקריפט לא מוסיף ערך ברור לאתר, צריך להסיר אותו.
• משתמשים ב-Resource Hints כמו <link rel=preconnect> או <link rel=dns-prefetch> כדי לבצע חיפוש DNS לדומיינים שמארחים סקריפטים של צד שלישי.

שימוש ב-async או ב-defer

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

המאפיינים async ו-defer משנים את ההתנהגות הזו באופן הבא:

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

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

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

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

הערה: ב-Chrome ובדפדפנים אחרים המבוססים על Blink, async ו-defer הפחיתו את העדיפות של בקשת הרשת למשאבים, כך שבקשת הרשת תיטען באופן משמעותי מאוחר יותר מאשר כסקריפט חסימה. זהו מידע שימושי במיוחד עבור סקריפטים של Analytics.

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

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

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

שימוש ב'רמזים למשאבים' כדי לקצר את זמן ההגדרה של החיבור

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

<link rel="dns-prefetch" href="http://example.com" />

אם הדומיין של הצד השלישי שאליו מתחברים משתמש ב-HTTPS, אפשר להשתמש גם ב-, שמבצע חיפושי DNS וגם פותר בעיות של העברת נתונים מ-TCP וטיפול במשא ומתן ב-TLS (אבטחת שכבת התעבורה). השלבים האחרים האלה עלולים להיות איטיים מאוד כי הם כרוכים באימות של אישורי SSL, ולכן חיבור מראש יכול לקצר משמעותית את זמן הטעינה.

<link rel="preconnect" href="https://cdn.example.com" />

סקריפטים "Sandbox" עם iframe

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

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

סקריפטים של צד שלישי באירוח עצמי

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

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

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

בדיקת A/B על דגימות קטנות יותר של משתמשים

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

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

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

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

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

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

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

הערה: LazySizes היא ספריית JavaScript פופולרית לטעינה מדורגת של תמונות ומסגרות iframe. הוא תומך בהטמעות וווידג'טים של YouTube.

במסמכי התיעוד הרשמיים של DoubleClick יש הנחיות לטעינה מדורגת של מודעות.

טעינה עצלה יעילה עם Intersection Viewer

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

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

ניתוח של טעינה מדורגת

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

הפוסט בבלוג של פיל וולטון The Google Analytics Setup I Use on Every Site I Build (הגדרת Google Analytics שבו אני משתמש בכל אתר I Build) עוסק באסטרטגיה אחת כזו ב-Google Analytics.

טעינה בטוחה של סקריפטים של צד שלישי

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

הימנעות מ-document.write()

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

פתרון הבעיות עבור document.write() הוא לא להשתמש בו. בגרסה 53 ואילך של Chrome, כלי הפיתוח ל-Chrome רושמים אזהרות למסוף לגבי שימוש בעייתי ב-document.write():

כלי הפיתוח ל-Chrome מסמן שימוש ב-document.write().

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

דוח Lighthouse שבו רואים אילו סקריפטים משתמשים ב-document.write().

שימוש זהיר ב-Tag Manager

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

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

הסיכונים בשימוש במנהלי תגים

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

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

נמנעים מסקריפטים שמזהמים את ההיקף הגלובלי

סקריפטים של צד שלישי יכולים להתנהג בכל מיני דרכים שיגרמו לשיבושים בדף באופן בלתי צפוי:

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

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

אסטרטגיות מיטיגציה

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

• HTTPS: אתרים שמשתמשים ב-HTTPS לא יכולים להיות תלויים בצדדים שלישיים שמשתמשים ב-HTTP. למידע נוסף, קראו את המאמר תוכן מעורב.

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

• Content Security Policy (CSP): אפשר להשתמש בכותרות HTTP בתגובה של השרת כדי להגדיר התנהגות מהימנה של סקריפטים באתר, וכדי לזהות ולצמצם את ההשפעות של התקפות מסוימות, כמו יצירת סקריפטים חוצי אתרים (XSS).

הדוגמה הבאה ממחישה איך להשתמש בהנחיה script-src של CSP כדי לציין את מקורות ה-JavaScript המורשים בדף:

// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed

<script src="https://not-example.com/js/library.js"></script>

קריאה נוספת

למידע נוסף על אופטימיזציה של JavaScript של צד שלישי, מומלץ לקרוא:

• ביצועים ועמידות: צדדים שלישיים לבדיקת מתח
• הוספת אינטראקטיביות עם JavaScript
• סכנות פוטנציאליות באמצעות סקריפטים של צד שלישי
• איך סקריפטים של צד שלישי יכולים להיות אזרחים בעלי ביצועים טובים באינטרנט
• למה המהירות חשובה – קסמים של שירותי CSS
• הפרדוקס של שרשרת האספקה של JavaScript: SRI, CSP ואמון בספריות של צד שלישי
• שירות CSS של צד שלישי לא בטוח

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