סקריפטים חיצוניים (סקריפטים של צד שלישי) הם קוד שהאתר טוען משרתים של חברות אחרות: אנליטיקה, פיקסלים של פרסום, צ'אט, סרטוני יוטיוב, מפות, כפתורי שיתוף ווידג'טים של ביקורות. כל אחד מהם נוסף "רק עם שורה אחת", אבל ביחד הם לרוב הסיבה העיקרית לכך שאתר שנבנה מהר נהיה איטי. החלק הבעייתי: האתר לא שולט בקוד הזה — לא בגודל שלו, לא בזמן התגובה של השרת שלו ולא בשינויים שהספק עושה בו.
כמה זה נפוץ
לפי פרק צד שלישי ב-Web Almanac 2024, ב-92% מהעמודים שנבדקו יש לפחות שירות צד שלישי אחד. החציון הוא 27 שירותי צד שלישי לעמוד באתרי המיליון המובילים, ו-66 באלף האתרים המובילים. רוב עשרת הדומיינים הנפוצים שייכים לגוגל — בהם googletagmanager.com, google-analytics.com ו-youtube.com.
דוגמה מהאתר הזה
כשמדדתי את דף הבית של האתר הזה לפני ואחרי שהוספתי את Google Analytics 4, משקל העמוד עלה מכ-88KB לכ-273KB — כמעט פי שלושה, בגלל תג אחד. זה לא אומר שאסור למדוד; זה אומר שכל תג צריך להצדיק את המחיר שלו. את המדידה המלאה פירטתי במאמר בדיקת מהירות אתר.
מה בדיוק סקריפט חיצוני עולה
- משקל והורדה: עוד קבצי JavaScript, ולעיתים עוד סקריפטים שהסקריפט הראשון טוען בעצמו.
- חיבורים חדשים: כל דומיין חיצוני דורש חיפוש DNS, חיבור והצפנה לפני שהקובץ בכלל מתחיל לרדת.
- זמן מעבד: אחרי ההורדה הדפדפן צריך להריץ את הקוד. זמן ריצה ארוך פוגע בתגובה ללחיצות — מדד INP — במיוחד בטלפונים חלשים.
- תלות: אם השרת של הספק איטי או נופל, סקריפט שנטען בצורה חוסמת יכול לעכב את כל העמוד.
- פרטיות ואבטחה: קוד חיצוני רץ עם אותן הרשאות כמו הקוד של האתר, ורבים מהשירותים האלה מציבים עוגיות.
איך עושים מיפוי
- פותחים את כלי המפתחים, לשונית הרשת, ומסננים לפי דומיין — כל מה שלא מגיע מהדומיין של האתר הוא צד שלישי.
- לכל שירות כותבים: מי הוסיף אותו, למה, ומי משתמש בנתונים שלו בפועל.
- מחפשים כפילויות: שני כלי אנליטיקה, פיקסל שנשאר מקמפיין שהסתיים, תוסף שהותקן ונשכח.
- בודקים בכלי מדידה, כמו Lighthouse, כמה זמן מעבד כל שירות צורך.
ברוב האתרים שעוברים מיפוי כזה מתגלה לפחות שירות אחד שאפשר פשוט להסיר. זה השיפור הזול והיעיל ביותר שיש.
איך טוענים את מה שנשאר
| שיטה | מה היא עושה | מתאים ל |
|---|---|---|
| async | הורדה במקביל, הרצה מיד כשהקובץ מגיע | אנליטיקה עצמאית שלא תלויה בסקריפטים אחרים |
| defer | הורדה במקביל, הרצה אחרי שהעמוד נקרא, לפי הסדר | סקריפטים שתלויים במבנה העמוד |
| חזית סטטית (Facade) | תמונה במקום הווידג'ט, טעינה אמיתית רק בלחיצה | יוטיוב, מפות, צ'אט |
| טעינה אחרי הסכמה | הסקריפט נטען רק אחרי שהגולש אישר | פיקסלים ושירותי פרסום |
| ריכוז במנהל תגים | ניהול כל התגים ממקום אחד | אתרים עם הרבה תגי שיווק |
לפי התיעוד של MDN, סקריפט עם async רץ ברגע שההורדה מסתיימת, בלי סדר מובטח, וסקריפט עם defer רץ רק אחרי שהעמוד נקרא ובסדר שבו הוא מופיע. סקריפט בלי אף אחד מהם עוצר את קריאת העמוד עד שהוא יורד ורץ.
חזית סטטית: הטריק לווידג'טים כבדים
התיעוד של Lighthouse מגדיר חזית (Facade) כאלמנט סטטי שנראה כמו הווידג'ט אבל לא פועל: בטעינה מוצגת תמונה, במעבר עכבר מתחילים להתחבר לספק, ובלחיצה החזית מתחלפת בווידג'ט האמיתי. לסרטוני יוטיוב יש ספריות מוכנות כמו lite-youtube-embed. המחיר: הפעלה אוטומטית של סרטון לא תמיד עובדת כשהוא נטען כך.
מנהל תגים לא מקטין את המשקל
Google Tag Manager נוח לניהול, אבל הוא עצמו עוד סקריפט, וכל תג שמוסיפים דרכו עדיין נטען. הוא פותר בעיית סדר ובקרה — לא בעיית משקל.
כלל שאני עובד לפיו
כל סקריפט חיצוני נכנס לאתר עם בעלים ועם מטרה. אם אף אחד לא יכול להגיד מה הנתונים שלו משמשים, הוא יוצא. ובתוך הקוד של התבנית, אני מעדיף לטעון סקריפטים עם defer ולשמור את מה שבאמת דחוף לראש העמוד.
שאלות נפוצות
האם להעביר את הסקריפטים לשרת שלי?
לפעמים זה עוזר — למשל בגופנים, שאפשר לארח באתר עצמו. בסקריפטים של אנליטיקה ופרסום זה לרוב לא מומלץ, כי הספק מעדכן אותם, ועותק מקומי מתיישן.
איך יודעים איזה סקריפט הכי מאט?
ב-Lighthouse ובכלי המפתחים אפשר לראות זמן ריצה לפי דומיין. התחילו מהשירות שצורך הכי הרבה זמן מעבד, לא מזה שהקובץ שלו הכי גדול.
מיפוי וניקוי של סקריפטים חיצוניים הוא אחד הצעדים הראשונים שלי בכל עבודת שיפור מהירות אתר ובמסגרת תחזוקת אתרים. רוצים לדעת מה רץ באתר שלכם? שלחו לי את הכתובת.
אהבתם את המאמר?
