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

Addy Osmani
Arthur Evans
X GitHub

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

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

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

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

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

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

  • כפתורי שיתוף במדיה חברתית (פייסבוק, X, לינקדאין, Mastodon)

  • נגני וידאו מוטמעים (YouTube, ‏Vimeo)

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

  • סקריפטים של ניתוח ומדדים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדיקת זמן האתחול של Lighthouse

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

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

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

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

‫Lighthouse מציג תמיכה במטענים ייעודיים (payloads) גדולים ברשת
בביקורת Network Payloads מוצג אילו בקשות לאחזור מהרשת נמשכות הכי הרבה זמן ומאחזרות הכי הרבה נתונים.

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

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

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

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

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

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

  1. לוחצים על הקלטה.
  2. טוענים את הדף. בכלי הפיתוח מוצג תרשים מפל שמייצג את משך הזמן שלוקח לאתר להיטען.
  3. עוברים אל Bottom-up (מלמטה למעלה) בתחתית החלונית Performance (ביצועים).
  4. לוחצים על Group by product (קיבוץ לפי מוצר) וממיינים את הסקריפטים של צד שלישי בדף לפי זמן הטעינה.
חלונית הביצועים של כלי הפיתוח, שבה מוצגת התצוגה מלמטה למעלה, מקובצת לפי מוצרים (של צד שלישי)
סקריפטים של צד שלישי ממוינים לפי מוצר, החל מזמן הטעינה הארוך ביותר.

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

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

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

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

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

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

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

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

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

רצועת תמונות של WebPageTest שמציגה את ההשפעה של טעינת אתר עם ובלי השבתה של צדדים שלישיים
ההשפעה של חסימת משאבים של צד שלישי, מתוך Using WebPageTest To Measure The Impact Of Third-Party Tags מאת אנדי דייוויס.

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

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

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

הגדרות מתקדמות של WebPageTest‏ > SPOF‏ > מארחים שייכשלו
משתמשים בתכונה לבדיקת נקודת כשל יחידה כדי לדמות כשל בדומיינים שצוינו.

זיהוי רכיבי iframe שצורכים הרבה משאבים באמצעות משימות שנמשכות הרבה זמן

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

כדי לזהות משימות שנמשכות הרבה זמן לצורך מעקב אחר משתמשים אמיתיים (RUM), משתמשים ב-API של PerformanceObserver ב-JavaScript כדי לבחון רשומות של longtask. הרשומות האלה מכילות מאפיין שיוך (Attribution) שבעזרתו אפשר לקבוע איזה הקשר של פריים גרם למשימה שנמשכת הרבה זמן.

הקוד הבא מתעד 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.
  • אם השרת של הצד השלישי איטי, כדאי לארח את הסקריפט בעצמכם.
  • אם הסקריפט לא מוסיף ערך ברור לאתר, הסירו אותו.
  • משתמשים בהצעות למשאבים כמו <link rel=preconnect> או <link rel=dns-prefetch> כדי לבצע חיפוש DNS לדומיינים שמארחים סקריפטים של צד שלישי.

אפשר להשתמש ב-async או ב-defer.

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

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

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

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

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

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

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

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

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

שימוש ב-Resource Hints כדי לקצר את זמן ההגדרה של החיבור

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

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

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

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

סקריפטים של "ארגז חול" עם iframe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

טעינה מדורגת יעילה באמצעות Intersection Observer

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

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

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

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

בפוסט בבלוג של פיל וולטון, The Google Analytics Setup I Use on Every Site I Build, מתוארת אסטרטגיה כזו ל-Google Analytics.

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

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

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

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

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

אזהרות במסוף כלי הפיתוח שמדגישות הפרות של הטמעה של צד שלישי באמצעות document.write()‎
שימוש בדגלים של כלי הפיתוח ל-Chrome document.write().

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

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

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

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

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

סיכונים בשימוש ב-Tag Manager

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

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

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

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

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

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

אסטרטגיות לצמצום הפגיעה

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

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

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

  • מדיניות אבטחת תוכן (CSP): אתם יכולים להשתמש בכותרות HTTP בתגובה של השרת כדי להגדיר התנהגויות של סקריפטים מהימנים באתר, ולזהות ולצמצם את ההשפעות של התקפות מסוימות, כמו פרצת אבטחה XSS‏ (cross-site scripting).

בדוגמה הבאה אפשר לראות איך משתמשים בהוראה 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 של צד שלישי, מומלץ לקרוא את המאמרים הבאים:

תודה ל-Kenji Baheux, ‏ Jeremy Wagner, ‏ Pat Meenan, ‏ Philip Walton, ‏ Jeff Posnick ו-Cheney Tsai על הביקורות שלהם.