دليل تحسين السكربتات الخارجية 2026

آخر تحديث: 4 سبتمبر 2026

تحسين السكربتات الخارجية (Third-Party Scripts) في 2026 يعني تأجيلها إلى ما بعد التفاعل، أو عزلها في Web Worker باستخدام Partytown، أو استبدالها بواجهات (Facades) خفيفة عند التضمينات الثقيلة، مع فرض ميزانية أداء صارمة لعدد الوسوم المسموح بها. بصراحة، في متجرنا الإلكتروني اكتشفت أن أكثر من 60% من زمن الحجب على الخيط الرئيسي (Main Thread Blocking) كان بسبب أدوات التتبع ومدير الوسوم وودجات الدردشة، وأن معالجتها منحتنا قفزة فورية في مقياس INP من 320ms إلى 180ms دون تغيير سطر واحد من كود المنتج. لم أكن أتوقع هذا الفرق قبل القياس فعلياً.

السكربتات الخارجية هي السبب الرئيسي لضعف مقياس INP في 40% من المواقع على الأجهزة المحمولة وفق تقرير Chrome UX لعام 2026.
مكتبة Partytown تنقل تنفيذ سكربتات مثل Google Tag Manager وGoogle Analytics إلى Web Worker، مما يحرر الخيط الرئيسي بشكل شبه كامل.
نمط الواجهة (Facade Pattern) يستبدل التضمينات الثقيلة (يوتيوب، خرائط، دردشة) بصورة خفيفة تُحمّل الخدمة الفعلية فقط عند التفاعل، وقد يوفر 1–2 ثانية من LCP.
يجب ألا يتجاوز موقعك المتوسط 10 سكربتات خارجية؛ فوق 15–20 سكربت يكاد يكون الأداء متضرراً حتماً.
البدائل من جانب الخادم مثل Cloudflare Zaraz تنقل تنفيذ الوسوم إلى الحافة (Edge)، فتصبح تكلفتها على المتصفح صفراً تقريباً.
ميزانية الأداء الصارمة (Performance Budget) على حجم JavaScript الطرف الثالث هي الوسيلة الوحيدة لمنع التراجع مع الوقت.

ما هي السكربتات الخارجية ولماذا تُبطئ موقعك؟

السكربتات الخارجية هي أي ملف JavaScript يُحمّل من نطاق (Domain) لا تتحكم به: Google Analytics، وGoogle Tag Manager، وMeta Pixel، وودجات الدردشة مثل Intercom وZendesk، وشبكات الإعلانات، ومقاطع يوتيوب المضمّنة، وخرائط Google Maps، ومكتبات اختبار A/B مثل Optimizely أو VWO. في تجربتي مع موقع تجارة إلكترونية يستقبل ملايين الزيارات شهرياً، وجدت أن الصفحة الواحدة تحمّل بين 22 و38 سكربتاً خارجياً افتراضياً. وهذا رقم كارثي بكل المقاييس.

المشكلة الجوهرية أن هذه السكربتات:

تُنفَّذ على الخيط الرئيسي (Main Thread) نفسه الذي يستخدمه المتصفح للاستجابة لنقرات المستخدم.
لا يمكنك تحسين شفرتها: أنت تعتمد على جودة كود المزوّد، وبعضهم (لن أسمّي أسماء) يشحن حزماً بحجم 200KB+ مضغوطة.
تُحقن ديناميكياً عبر document.write أو appendChild، مما يجعل التنبؤ بحجمها النهائي شبه مستحيل.
تتضاعف مع الوقت: كل حملة تسويقية جديدة تعني وسماً جديداً، ولا أحد يُزيلها لاحقاً. أبداً.

وفق مجموعة بيانات Third Party Web، فإن Google Tag Manager وحده يضيف في المتوسط 130ms من زمن الحجب على الخيط الرئيسي على أجهزة الميدرانج، بينما تصل بعض ودجات الدردشة إلى 400ms، وهذا وحده كافٍ لإفشال مقياس INP لديك.

كيف تُدمّر السكربتات الخارجية Core Web Vitals؟

كل مقياس من مقاييس Core Web Vitals يتأثر بشكل مختلف. فهم آلية الضرر هو الخطوة الأولى في العلاج.

التأثير على INP (Interaction to Next Paint)

هذا هو أخطر التأثيرات وأكثرها شيوعاً في 2026. عندما ينقر المستخدم على زر "أضف إلى السلة"، يجب على المتصفح تنفيذ معالج النقر ثم رسم الإطار التالي. لكن إذا كان Google Tag Manager يُنفّذ مهمة طويلة (Long Task) في تلك اللحظة، يُؤجَّل معالج النقر حتى تنتهي المهمة. تجربتي: إضافة ودجت دردشة واحدة رفعت INP لدينا من 190ms إلى 340ms في نفس اليوم. للتعمق في هذا المقياس، اطّلع على دليل تحسين مقياس INP.

التأثير على LCP (Largest Contentful Paint)

السكربتات الخارجية التي تُحمّل بشكل تزامني (Synchronous) تحجب المُحلل (Parser) وتؤخر اكتشاف الصور والخطوط الحرجة. حتى السكربتات غير المتزامنة تتنافس على عرض النطاق الترددي (Bandwidth) مع صورة LCP. الحل غالباً هو تأخير كل شيء غير حرج، واستخدام سمة fetchpriority="high" لصورة LCP.

التأثير على CLS (Cumulative Layout Shift)

ودجات الدردشة التي تظهر فجأة في الزاوية، وبانرات الإعلانات التي تُحقن في منتصف المحتوى، وبانرات الكوكيز التي لا تحجز مساحتها مسبقاً؛ كلها مصادر شائعة لانزياح التخطيط. الحل هو حجز مساحة (Reserved Space) لكل عنصر خارجي متوقع. راجع دليل تحسين مقياس CLS للتفاصيل الكاملة.

كيف أفحص وأحدد السكربتات الأكثر ضرراً؟

لا تحسّن ما لا تقيسه. قبل حذف أي سكربت أو نقله إلى Partytown، احصل على أرقام حقيقية. أستخدم أربع أدوات بالتوازي:

1. تدقيق Lighthouse "Reduce the impact of third-party code"

افتح DevTools، وشغّل تدقيق Lighthouse في وضع Mobile. سيُظهر تقرير يسرد كل نطاق طرف ثالث، مع حجمه بالكيلوبايت وزمن حجبه للخيط الرئيسي (Main Thread Blocking Time). رتّب حسب Blocking Time تنازلياً، والقمة هي أهدافك الأولى.

2. تبويب Performance في Chrome DevTools

سجّل جلسة تفاعل حقيقية (فتح الصفحة، نقر على زر، تمرير). في قسم Main، ابحث عن المهام الطويلة الحمراء (Long Tasks > 50ms) وحدد أي نطاق مصدرها. غالباً ستجد أن 3–5 نطاقات مسؤولة عن 80% من المشكلة (قانون باريتو).

3. مجموعة بيانات Third Party Web

موقع thirdpartyweb.today يُصنّف آلاف النطاقات الخارجية حسب متوسط تأثيرها. مفيد جداً لتقدير التكلفة قبل إضافة سكربت جديد إلى موقعك.

4. بيانات RUM من مستخدميك الحقيقيين

مكتبة web-vitals من Google تسمح بربط كل قيمة INP سيئة بالسكربت الذي كان يُنفَّذ في تلك اللحظة (Attribution API). هذا يفوق أي اختبار مخبري لأنه يعكس شبكات وأجهزة مستخدميك الفعلية.

استراتيجيات التحميل: async وdefer والتأخير حتى التفاعل

القرار الأول لكل سكربت خارجي هو: متى يجب أن يبدأ التحميل والتنفيذ؟ هناك أربع استراتيجيات مرتبة من الأسوأ إلى الأفضل:

التحميل التزامني (تجنّبه دائماً)

<!-- سيء: يحجب المُحلل حتى ينتهي التحميل والتنفيذ -->
<script src="https://third-party.com/tag.js"></script>

async: للسكربتات المستقلة (تحليلات)

<!-- يُحمّل بالتوازي، ويُنفَّذ فور جاهزيته -->
<script async src="https://www.google-analytics.com/analytics.js"></script>

مناسب فقط للسكربتات التي لا تعتمد على DOM ولا على سكربتات أخرى.

defer: الافتراضي الأكثر أماناً

<!-- يُحمّل بالتوازي، ويُنفَّذ بعد اكتمال DOM قبل DOMContentLoaded -->
<script defer src="/js/app.js"></script>

التأخير حتى التفاعل (الأفضل للسكربتات غير الحرجة)

لا يحتاج ودجت الدردشة أو chatbot أن يُحمَّل قبل أن يُبدي المستخدم أي نية للاستخدام. أُطلق التحميل عند أول تفاعل حقيقي:

// تحميل ودجت الدردشة بعد أول تفاعل من المستخدم
function loadChatWidget() {
  const script = document.createElement('script');
  script.src = 'https://widget.intercom.io/widget/APP_ID';
  script.async = true;
  document.head.appendChild(script);
}

// المحفزات: أول نقرة، أول تمرير، أو مرور 10 ثوانٍ
const triggers = ['click', 'scroll', 'keydown', 'touchstart'];
const loadOnce = () => {
  loadChatWidget();
  triggers.forEach(evt =>
    window.removeEventListener(evt, loadOnce, { passive: true })
  );
};
triggers.forEach(evt =>
  window.addEventListener(evt, loadOnce, { once: true, passive: true })
);

// خطة احتياطية: حمّل بعد 10 ثوانٍ إذا لم يتفاعل المستخدم
setTimeout(loadOnce, 10000);

في Next.js، استخدم استراتيجية lazyOnload عبر مكوّن next/script:

import Script from 'next/script';

export default function Layout({ children }) {
  return (
    <>
      {children}
      <Script
        src="https://widget.intercom.io/widget/APP_ID"
        strategy="lazyOnload"
      />
    </>
  );
}

نمط الواجهة (Facade Pattern) للتضمينات الثقيلة

نمط الواجهة يعني عرض صورة أو مكوّن HTML خفيف يُشبه العنصر الحقيقي، وتحميل الكود الفعلي فقط عند نقر المستخدم. مقاطع يوتيوب المضمّنة هي المثال الأشهر: تضمين واحد يُحمّل حوالي 550KB من JavaScript قبل أن يشاهد المستخدم أي شيء. الواجهة تُقلّل هذا إلى صورة مصغّرة بحجم 15KB.

مثال يوتيوب: مكتبة lite-youtube-embed

<!-- بدلاً من iframe يوتيوب الرسمي -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/lite-youtube-embed/src/lite-yt-embed.css" />
<script src="https://cdn.jsdelivr.net/npm/lite-youtube-embed/src/lite-yt-embed.js"></script>

<lite-youtube videoid="dQw4w9WgXcQ" playlabel="اضغط للتشغيل"></lite-youtube>

النتيجة: تحميل أولي أقل بـ 500KB، ولا يتم استدعاء نطاقات youtube.com إلا عند التفاعل.

مثال دردشة: react-live-chat-loader

import { LiveChatLoaderProvider, Intercom } from 'react-live-chat-loader';

export default function App() {
  return (
    <LiveChatLoaderProvider provider="intercom" providerKey="APP_ID">
      {/* واجهة خفيفة تشبه أيقونة الدردشة */}
      <Intercom />
    </LiveChatLoaderProvider>
  );
}

لا يتم تحميل حزمة Intercom الأصلية (200KB+) إلا بعد أن ينقر المستخدم على الأيقونة. في تجربتنا، هذا التغيير وحده أنقص LCP بمقدار 1.4 ثانية على الصفحات التي تحتوي على الدردشة.

خرائط: Static Maps بدلاً من JavaScript API

لعرض موقع فيزيائي فقط (بدون تفاعل)، استخدم Google Static Maps API كصورة، ووفّر تحميل مكتبة Maps JavaScript كاملة (350KB+). راجع توثيق Chrome عن أنماط الواجهة للطرف الثالث.

Partytown: تشغيل السكربتات في Web Worker

Partytown هي مكتبة مفتوحة المصدر من Builder.io تنقل السكربتات الخارجية إلى Web Worker منفصل بدلاً من الخيط الرئيسي. هذا يعني أن Google Tag Manager يمكنه استهلاك 300ms من زمن CPU دون أن يُلاحظ المستخدم شيئاً، لأن الخيط الرئيسي حرّ للاستجابة لنقراته. راجع توثيق Partytown الرسمي.

التثبيت والاستخدام الأساسي

npm install @builder.io/partytown

في Next.js 15، استخدم استراتيجية worker المدمجة:

// app/layout.tsx
import Script from 'next/script';

export default function RootLayout({ children }) {
  return (
    <html lang="ar" dir="rtl">
      <body>
        {children}

        {/* Google Tag Manager عبر Web Worker */}
        <Script id="gtm" strategy="worker">
          {`
            (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({
              'gtm.start': new Date().getTime(),event:'gtm.js'
            });var f=d.getElementsByTagName(s)[0],
            j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';
            j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;
            f.parentNode.insertBefore(j,f);
            })(window,document,'script','dataLayer','GTM-XXXXXX');
          `}
        </Script>
      </body>
    </html>
  );
}

الأداء الفعلي

في اختباراتنا على موقع كتالوج منتجات:

قبل Partytown: Lighthouse 68 / TBT 640ms / INP 310ms
بعد Partytown: Lighthouse 96 / TBT 90ms / INP 165ms

القيود التي يجب معرفتها

Partytown ليست حلاً سحرياً لكل شيء:

السكربتات التي تعتمد بشكل كبير على قراءة DOM بشكل متزامن قد تصبح أبطأ (كل عملية Read تمر عبر messaging synchronous).
بعض السكربتات (مثل Hotjar Recording) لا تعمل معها لأنها تحتاج وصولاً لحظياً لأحداث المتصفح.
تحتاج إلى تشغيل proxy عكسي (Reverse Proxy) على نطاقك لتجاوز قيود CORS.

القاعدة العملية: Partytown ممتازة لـ GTM، وGA4، وMeta Pixel، وHubSpot، وMixpanel. اختبرها في staging قبل الإنتاج.

إدارة الوسوم من جانب الخادم (Server-Side Tagging)

الحل الأنظف للسكربتات الخارجية هو ألا تُشغّلها في المتصفح أصلاً. إدارة الوسوم من جانب الخادم تنقل تنفيذ الوسوم إلى خادم أو حافة شبكة (Edge)، فيُرسل المتصفح حدثاً واحداً فقط بدلاً من تحميل عشرات SDKs.

الخيارات المتاحة في 2026

Cloudflare Zaraz: مجاني حتى مليون حدث/شهر، ويعمل على شبكة Cloudflare العالمية. يدعم أكثر من 100 أداة (GA4، Meta، TikTok، LinkedIn، إلخ) دون تحميل أي SDK في المتصفح.
Google Tag Manager Server-Side: يتطلب استضافة على Google Cloud (حوالي 120$ شهرياً كحد أدنى)، لكنه يوفّر أعلى قدر من التخصيص.
Segment/RudderStack: منصات CDP تدعم إرسال الأحداث من جانب الخادم إلى عشرات الوجهات.

مثال: Meta Conversions API بدلاً من Pixel

بدلاً من تحميل Meta Pixel في كل صفحة (60KB+، ويتصل بـ facebook.net)، أرسل الأحداث من خادمك مباشرة:

// server: إرسال حدث Purchase إلى Meta بدون Pixel في المتصفح
async function sendPurchaseEvent(order, hashedEmail) {
  await fetch(`https://graph.facebook.com/v18.0/${PIXEL_ID}/events`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      access_token: META_ACCESS_TOKEN,
      data: [{
        event_name: 'Purchase',
        event_time: Math.floor(Date.now() / 1000),
        action_source: 'website',
        user_data: { em: [hashedEmail] },
        custom_data: {
          currency: 'SAR',
          value: order.total,
        },
      }],
    }),
  });
}

النتيجة: صفر تكلفة على المتصفح، ودقة تتبع أعلى (لا يوقفها مانع الإعلانات)، وتوافق أفضل مع GDPR.

ميزانية أداء صارمة للسكربتات الخارجية

بدون سقف مكتوب، سيتراكم عدد السكربتات مع كل حملة تسويقية جديدة حتى تعود إلى نقطة الصفر بعد ستة أشهر. ميزانية الأداء (Performance Budget) هي عقد بين فريق الهندسة والتسويق.

الأرقام التي أستخدمها في متجرنا الإلكتروني

المقياس	حد صارم	حد التحذير	الإجراء عند التجاوز
حجم JS الطرف الثالث (مضغوط)	170KB	130KB	حظر merge في CI
عدد النطاقات الخارجية	10	7	مراجعة إلزامية
Total Blocking Time	200ms	150ms	حظر النشر
INP (p75)	200ms	170ms	مراجعة الحوادث
LCP (p75)	2.5s	2.1s	مراجعة أسبوعية

فرض الميزانية في CI

استخدم Lighthouse CI مع ملف budgets.json:

{
  "path": "/*",
  "resourceSizes": [
    { "resourceType": "third-party", "budget": 170 },
    { "resourceType": "script", "budget": 350 }
  ],
  "resourceCounts": [
    { "resourceType": "third-party", "budget": 10 }
  ],
  "timings": [
    { "metric": "total-blocking-time", "budget": 200 },
    { "metric": "largest-contentful-paint", "budget": 2500 }
  ]
}

أي PR يتجاوز هذه الحدود يفشل في CI، ويحتاج موافقة صريحة من قائد الأداء. هذه هي الطريقة الوحيدة التي وجدتها لمنع الانحدار البطيء (Slow Regression) الذي يقتل المواقع بمرور الوقت.

المراقبة المستمرة ومنع التراجع

الأداء ليس مشروعاً بل ممارسة مستمرة. أرقام اليوم لا تعني شيئاً إن لم تُراقبها غداً وبعده. إليك ما أُشغّله في كل منتج أعمل عليه:

1. RUM (Real User Monitoring) مع Attribution

استخدم مكتبة web-vitals من Google لتجميع INP وLCP وCLS من المستخدمين الحقيقيين، مع API الإسناد الجديد الذي يخبرك أي عنصر أو نطاق سبّب المشكلة. لمقاربة أعمق للموضوع، راجع قياس Core Web Vitals من بيانات الحقل:

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const attribution = metric.attribution;
  // إرسال إلى نقطة تحليلاتك مع تفاصيل المصدر
  fetch('/api/rum', {
    method: 'POST',
    body: JSON.stringify({
      metric: 'INP',
      value: metric.value,
      target: attribution.interactionTarget,
      loadState: attribution.loadState,
      inputDelay: attribution.inputDelay,
      processingDuration: attribution.processingDuration,
    }),
  });
});

2. تنبيهات على تراجع الأداء

اربط لوحة معلومات (Grafana أو Datadog) بمقاييس p75 لـ INP وLCP، وأنشئ تنبيهاً عندما يتجاوز أي مقياس عتبته لمدة 3 ساعات متواصلة. في تجربتي، هذا يكتشف تراجعات نشرها فريق التسويق دون علم فريق الهندسة.

3. مراجعة ربع سنوية للوسوم

كل ثلاثة أشهر، اجتمع مع فريق التسويق واستعرض قائمة الوسوم النشطة. اسأل ثلاثة أسئلة عن كل وسم: هل استُخدمت بياناته في آخر 90 يوماً؟ هل هناك بديل من جانب الخادم؟ ما هو تأثيره الحالي على Lighthouse؟ أي وسم يفشل في الأسئلة الثلاثة يُحذف.

الأسئلة الشائعة

كم عدد السكربتات الخارجية المسموح به قبل تضرر الأداء؟

لا يوجد رقم سحري، لكن القاعدة العملية أن الموقع المتوسط يجب أن يبقى تحت 10 سكربتات خارجية. بعد 15 سكربتاً، من شبه المؤكد أن الأداء يتضرر بغض النظر عن مدى تحسين كل سكربت على حدة. ما يهم فعلاً هو مجموع Blocking Time وحجم JS الطرف الثالث، وليس العدد.

هل استخدام async أفضل من defer للسكربتات الخارجية؟

defer أفضل في معظم الحالات لأنه يضمن ترتيب التنفيذ ولا يُنفَّذ قبل اكتمال DOM. استخدم async فقط للسكربتات المستقلة تماماً مثل تحليلات لا تعتمد على DOM. للسكربتات غير الحرجة كودجات الدردشة، الأفضل تأخيرها حتى تفاعل المستخدم بدلاً من async أو defer.

هل Partytown تعمل مع جميع السكربتات الخارجية؟

لا. Partytown ممتازة لسكربتات القياس والتتبع مثل Google Tag Manager وGA4 وMeta Pixel وHubSpot. لكنها لا تعمل مع السكربتات التي تحتاج وصولاً متزامناً كبيراً لـ DOM أو تسجيلاً حياً للأحداث مثل Hotjar Recording. اختبر دائماً في بيئة staging قبل الإنتاج.

ما الفرق بين نمط الواجهة (Facade) والتحميل الكسول (Lazy Loading)؟

التحميل الكسول يؤجّل تحميل الكود حتى يقترب العنصر من العرض، بينما نمط الواجهة يستبدل العنصر بالكامل بواجهة خفيفة (صورة أو HTML بسيط) ولا يُحمّل الكود الأصلي إلا عند التفاعل. الواجهة أقوى بكثير لأنها تُوفّر الكود تماماً للمستخدمين الذين لا يتفاعلون مع العنصر.

هل تؤثر السكربتات الخارجية على SEO مباشرة؟

نعم. Google يستخدم Core Web Vitals كإشارة ترتيب، والسكربتات الخارجية هي السبب الأول لضعف INP وLCP. تحسينها يُحسّن مقاييسك الميدانية في CrUX، مما يرفع فرصك في الترتيب. بالإضافة إلى التأثير غير المباشر: صفحة أبطأ = معدل ارتداد أعلى = إشارة سلبية للترتيب.

كيف أقنع فريق التسويق بإزالة الوسوم القديمة؟

الأرقام تتحدث. اربط كل 100ms من تحسين LCP بـ ~1% زيادة في التحويل، وأظهر لهم تكلفة كل وسم بالريالات المفقودة شهرياً. اعرض بديلاً من جانب الخادم يحافظ على البيانات دون التكلفة. أخيراً، ضع ميزانية أداء في CI تمنع إضافة وسوم جديدة دون إزالة أخرى.