סקריפטים חיצוניים - Google Analytics, Facebook Pixel, Tag Manager, Hotjar, Intercom, Crisp, Tidio, Zendesk - כל אחד מהם נטען מדומיין שונה. בכל דומיין הדפדפן צריך לבצע: DNS lookup (20-200ms), TCP handshake (50-100ms), TLS handshake (100-200ms), וdownload (תלוי בגודל). בסה"כ 200-500ms לכל דומיין חדש. 10 סקריפטים מדומיינים שונים = 2-5 שניות מצטברים.
למה זה משנה
סקריפטים חיצוניים פוגעים בכל מדדי Core Web Vitals: LCP נדחה כי הסקריפטים תופסים bandwidth של תמונת ה-hero. FCP נדחה כי סקריפטים render-blocking עוצרים את ה-parser של HTML. INP מתארך כי סקריפטים שרצים אחרי הטעינה (analytics, chat) חוטפים את ה-main thread של JavaScript ועוצרים תגובות לקליקים. TBT (Total Blocking Time) הופך לקטסטרופה - אתרים עם 5+ סקריפטים חיצוניים מציגים TBT של 2000-5000ms.
בנוסף, חלק מהסקריפטים יש להם cascading dependencies - Google Tag Manager טוען עוד סקריפטים שטוענים עוד סקריפטים. בלי GTM, אתה רואה את הכל פעם אחת בקוד שלך. עם GTM - יכול להיות שאתה לא רואה כלל מה הוא טוען.
נטו: כל סקריפט חיצוני זה decision tradeoff. השאל "מה אני מקבל ממנו?" מול "כמה אני משלם בביצועים?". אם chat widget שלך משמש 1% מהמבקרים אבל מאריך LCP ל-2 שניות לכולם - זו עסקה גרועה.
איך לזהות
F12 > Network > רענן עמוד > הסתכל על העמודה "Domain". כל דומיין שאינו האתר שלך הוא script חיצוני. ספור אותם. אם יותר מ-5 - יש כאן עבודה.
בדיקה מקצועית: WebPageTest. הוא מציג "3rd Party Domains" עם משקל לכל אחד. PageSpeed Insights בקטגוריית "Reduce the impact of third-party code" יציג רשימה של הצרכנים הגדולים.
בדיקה ב-Lighthouse: F12 > Lighthouse > Performance. תחת "Avoid enormous network payloads" ו-"Reduce JavaScript execution time" - יראו את הסקריפטים החיצוניים בולטים.
איך לתקן
אסטרטגיה 1: סקור והסר. עבור על כל סקריפט שאל "האם אני באמת משתמש בנתונים?". Hotjar שלא בדקת ב-3 חודשים - הסר. Pixel של קמפיין שהסתיים - הסר. לכל סקריפט שמתווסף, הסר אחד.
אסטרטגיה 2: איחוד דרך GTM. עבור ל-Google Tag Manager. במקום 10 סקריפטים שונים על האתר, יש קונטיינר GTM יחיד שטוען את כולם בצורה מנוהלת. גם מאפשר tag firing rules - לטעון Pixel רק בעמודי checkout, לא בכל האתר.
אסטרטגיה 3: defer/async. סקריפטים שלא צריכים לרוץ מיד יכולים להיטען לאחר טעינת הדף. הוסף ל-functions.php:
add_filter('script_loader_tag', function ($tag, $handle, $src) {
$defer_handles = ['google-analytics', 'facebook-pixel'];
if (in_array($handle, $defer_handles, true)) {
return str_replace(' src', ' defer src', $tag);
}
return $tag;
}, 10, 3);או השתמש ב-WP Rocket / FlyingPress שיש להם הגדרת "Delay JavaScript Execution" - הם דוחים את כל הסקריפטים עד אינטראקציה ראשונה (קליק, גלילה).
אסטרטגיה 4: self-hosting. עבור Google Analytics, אפשר לטעון את analytics.js מ-CDN שלך במקום מ-googletagmanager.com. תוסף "Complete Analytics Optimization Suite (CAOS)" עושה את זה אוטומטית - חוסך DNS lookup ו-handshake.
אסטרטגיה 5: lazy chat widgets. במקום שה-chat ייטען בכל עמוד, הוסף JS שטוען אותו רק כשהמשתמש לוחץ על אייקון או גולל. צ'אט עם delay של 5 שניות נראה זהה למשתמש אבל חוסך 500KB בטעינה ראשונית.
טעויות נפוצות
הטעות הראשונה: להוסיף 5 plugins לאנלטיקס במקום אחד. כל אחד טוען אותו GA פעם נוספת. הטעות השנייה: לשכוח לבדוק GTM לעומק - לפעמים יש שם 20 tags ש-marketing הוסיף לפני שנים ושכח. בדוק GTM מדי רבעון. הטעות השלישית: לשים את GA בראש ה-head בלי async - זה render-blocking ופוגע ב-FCP. הטעות הרביעית: לסמוך על Cloudflare Rocket Loader - הוא לפעמים שובר סקריפטים מודרניים.
בדיקה לאחר תיקון
הרץ Lighthouse לפני ואחרי. "Reduce the impact of third-party code" צריך לרדת. TBT צריך לרדת ב-500-2000ms. LCP במקרים שבהם סקריפט חיצוני בלע bandwidth - יורד ב-200-500ms. בדוק שכל הסקריפטים שעדיין רצים פועלים: בדוק GA real-time, נסה לפתוח chat widget, וודא ש-Pixel רושם events.