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

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

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

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

כל תג script שהדפדפן שלכם נתקל בו בדרך כלל מפעיל שרשרת תגובות:

• חיפוש DNS לדומיין שאתם לא שולטים בו
• חיבור TCP חדש וסבב לחיצות ידיים (handshake) של TLS
• הורדה של הסקריפט עצמו
• ניתוח והרצה על ה-thread הראשי
• לעיתים קרובות, בקשות נוספות שמופעלות על ידי אותו סקריפט (פיקסלים, משאבי משנה, סקריפטים נוספים)

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

הבעיה של ה-thread הראשי

רוב הסקריפטים של צד שלישי רצים על ה-thread הראשי של הדפדפן, אותו thread שאחראי על עיצוב הדף שלכם ומענה לפעולות המשתמש. כשסקריפט כבד חוסם את ה-thread הזה, הדף שלכם יכול להיראות טעון בזמן שהוא בעצם קפוא. משתמשים לוחצים על כפתור ולא קורה כלום. זו לא בעיה של רינדור, זו בעיה של הרצת JavaScript, וזה בדיוק מה שהמדד Total Blocking Time של Google נועד לתפוס.

איך למדוד את הנזק בפועל

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

לתמונה ברורה יותר, הריצו את האתר שלכם דרך כלי ניתוח מהירות דף ובדקו את הקטע "Third-Party Usage" בדוח Lighthouse. הוא מפרק:

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

WebPageTest היא אפשרות נוספת מצוינת. תצוגת ה-waterfall שלה מראה בדיוק מתי כל בקשה של צד שלישי נורית וכמה זמן הדפדפן ממתין לה לפני שהוא ממשיך.

דוגמה מהירה מהעולם האמיתי

ווידג'ט צ'אט חי פופולרי בודד יכול להוסיף:

• כ-150KB של JavaScript
• 3-5 בקשות רשת נוספות
• 200-400 מילישניות של חסימת thread ראשי במכשיר נייד ברמה בינונית

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

תיקונים מעשיים שבאמת עושים הבדל

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

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

2. טענו סקריפטים באופן אסינכרוני או דחו אותם

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

<script src="https://example.com/widget.js" defer></script>

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

3. השתמשו בתבנית "פאסאד" עבור הטמעות כבדות

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

4. אחסנו בעצמכם מה שאפשר

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

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

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

איך אחסון האתר משתלב בכל זה

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

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

לסיכום

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

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