بار کردن جاوا اسکریپت شخص ثالث

Addy Osmani
Arthur Evans
X GitHub

اگر کدتان را بهینه‌سازی کرده‌اید، اما سایتتان همچنان خیلی کند بار می‌شود، احتمالاً مشکل از اسکریپت‌های شخص ثالث است.

دستورات طرف سوم انواع مختلفی از ویژگی‌های مفید را ارائه می‌دهند که وب را پویاتر، تعاملی‌تر، و مرتبط‌تر می‌کند. برخی‌از آن‌ها حتی ممکن است برای عملکرد وب‌سایت یا جریان درآمد شما حیاتی باشند. اما استفاده از آن‌ها پرخطر است:

  • این افزونه‌ها می‌توانند عملکرد سایتتان را کند کنند.
  • این برنامه‌ها می‌توانند مشکلات حریم خصوصی یا امنیت ایجاد کنند.
  • این مدل‌ها می‌توانند غیرقابل‌پیش‌بینی باشند و رفتار آن‌ها می‌تواند پیامدهای ناخواسته‌ای داشته باشد.

در حالت ایده‌آل، باید مطمئن شوید که دستورگان‌های طرف سوم بر مسیر پرداز زدن بحرانی سایت شما تأثیر نمی‌گذارند. در این راهنما، نحوه پیدا کردن و رفع مشکلات مربوط به بار کردن جاوا اسکریپت شخص ثالث را بررسی می‌کنیم و خطرات را برای کاربران شما به حداقل می‌رسانیم.

متن‌های شخص ثالث چیست؟

جاوا اسکریپت طرف سوم اغلب به اسکریپت‌هایی اشاره دارد که می‌توانند مستقیماً از یک فروشنده طرف سوم در هر سایتی جاسازی شوند. چند نمونه:

  • دکمه‌های هم‌رسانی اجتماعی (فیس‌بوک، X،‏ LinkedIn،‏ Mastodon)

  • جاسازی‌های پخش‌کننده ویدیو (YouTube، ‏Vimeo)

  • ‫iframes تبلیغاتی

  • دستورات Analytics و سنجه‌ها

  • اسکریپت‌های آزمایش A/B برای آزمایش‌ها

  • کتابخانه‌های کمکی، مانند قالب‌بندی تاریخ، پویانمایی، یا کتابخانه‌های کاربردی

نمونه‌ای از جاسازی ویدیو YouTube
نمونه‌ای از جاسازی ویدیو YouTube که می‌توان بااستفاده از کد زیر به صفحه اضافه کرد.
<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

متأسفانه، جاسازی اسکریپت‌های شخص ثالث به این معنی است که ما اغلب برای اجرای سریع و کند نشدن صفحاتمان به آن‌ها متکی هستیم. اسکریپت‌های شخص ثالث یکی از دلایل رایج کاهش عملکرد ناشی از منابع خارج از کنترل مالک سایت هستند، ازجمله مشکلات زیر:

  • ارسال درخواست‌های شبکه بسیار زیاد به چندین سرور. هرچه سایت درخواست‌های بیشتری داشته باشد، بار شدن آن بیشتر طول می‌کشد.

  • ارسال جاوا اسکریپت بیش‌ازحد که رشته اصلی را مشغول نگه می‌دارد. جاوا اسکریپت بیش‌ازحد می‌تواند ساخت DOM را مسدود کند که این امر پرداز صفحه را به‌تأخیر می‌اندازد. تجزیه و اجرای اسکریپت با مصرف بالای CPU می‌تواند تعامل کاربر را به‌تأخیر بیندازد و باعث تخلیه باتری شود.

  • ارسال فایل‌های تصویری یا ویدیوهای بزرگ و بهینه‌نشده می‌تواند داده مصرف کند و برای کاربران هزینه داشته باشد.

  • مشکلات امنیتی که اگر صفحه‌تان اسکریپتی را بدون احتیاط بار کند، می‌توانند به‌عنوان نقطه تکی شکست (SPOF) عمل کنند.

  • ذخیره‌سازی HTTP ناکافی، که مرورگر را مجبور می‌کند درخواست‌های شبکه بیشتری برای واکشی منابع ارسال کند.

  • نبود فشرده‌سازی سرور کافی باعث می‌شود منابع به‌کندی بار شوند.

  • مسدود کردن نمایش محتوا تا زمانی که پردازش آن‌ها تکمیل شود. این موضوع می‌تواند برای اسکریپت‌های آزمایش A/B ناهمگام نیز صادق باشد.

  • استفاده از میاناهای برنامه‌سازی کاربردی قدیمی که برای تجربه کاربری مضر شناخته شده‌اند، مانند document.write().

  • عناصر DOM بیش‌ازحد یا گزینشگرهای CSS گران.

  • گنجاندن چندین جاسازی شخص ثالث می‌تواند منجر به کشیده شدن چندین چارچوب و کتابخانه در چندین بار شود، منابع را هدر دهد و مشکلات عملکرد موجود را بدتر کند.

  • اسکریپت‌های طرف سوم اغلب از تکنیک‌های جاسازی استفاده می‌کنند که می‌تواند window.onload را مسدود کند، حتی اگر جاسازی از async یا defer استفاده کند.

توانایی شما برای برطرف کردن مشکلات مربوط به اسکریپت‌های طرف سوم می‌تواند به سایت شما و توانایی‌تان برای پیکربندی نحوه بار کردن کد طرف سوم بستگی داشته باشد. خوشبختانه، تعدادی راه‌حل و ابزار برای پیدا کردن و برطرف کردن مشکلات مربوط به منابع طرف سوم وجود دارد.

چگونه اسکریپت طرف سوم را در صفحه شناسایی می‌کنید؟

شناسایی اسکریپت‌های طرف سوم در سایت و تعیین تأثیر عملکرد آن‌ها اولین گام برای بهینه‌سازی آن‌ها است. توصیه می‌کنیم برای شناسایی اسکریپت‌های پرهزینه، از ابزارهای رایگان سنجش سرعت وب، ازجمله Chrome DevTools، PageSpeed Insights، و WebPageTest استفاده کنید. این ابزارها اطلاعات تشخیصی غنی‌ای را نمایش می‌دهند که می‌تواند به شما بگوید سایتتان از چند اسکریپت شخص ثالث استفاده می‌کند و کدام‌یک بیشترین زمان را برای اجرا می‌گیرد.

نمای آبشاری WebPageTest می‌تواند تأثیر استفاده سنگین از اسکریپت طرف سوم را برجسته کند. تصویر زیر از Tags Gone Wild نمودار نمونه‌ای از درخواست‌های شبکه موردنیاز برای بار کردن محتوای اصلی یک سایت را درمقابل اسکریپت‌های ردیابی و بازاریابی نشان می‌دهد.

نمای آبشاری از webpagetest که یک وب‌سایت واقعی را درمقابل مدت زمان صرف‌شده برای بار کردن اسکریپت‌های ردیابی نشان می‌دهد
بار کردن متن‌های این صفحه بیشتر از خود صفحه طول می‌کشد.

تفکیک دامنه WebPageTest نیز می‌تواند برای تجسم اینکه چه مقدار محتوا از منابع طرف سوم می‌آید مفید باشد. این گزارش براساس کل بایت‌ها و تعداد درخواست‌ها تفکیک می‌شود:

تفکیک محتوا براساس دامنه (نمای اول). درصد درخواست‌ها و بایت‌ها را برای هر شخص ثالث نشان می‌دهد
نمودارهای تفکیک دامنه نشان می‌دهد که چه مقدار از محتوای صفحه از طرف‌های سوم می‌آید.

چگونه تأثیر اسکریپت طرف سوم را بر صفحه‌ام اندازه‌گیری کنم؟

وقتی می‌بینید که اسکریپتی باعث ایجاد مشکل می‌شود، ببینید آن اسکریپت چه کاری انجام می‌دهد و تعیین کنید که آیا سایت شما برای عملکرد خود به آن نیاز دارد یا نه. درصورت لزوم، آزمون آ/ب اجرا کنید تا ارزش درک‌شده آن را درمقابل تأثیرش بر سنجه‌های عملکرد یا تعامل کاربر کلیدی متعادل کنید.

ممیزی زمان راه‌اندازی Lighthouse

بازبینی زمان راه‌اندازی جاوا اسکریپت Lighthouse اسکریپت‌هایی را برجسته می‌کند که زمان تجزیه، کامپایل، یا ارزیابی اسکریپت پرهزینه‌ای دارند. این کار می‌تواند به شما کمک کند تا اسکریپت‌های شخص ثالثی را که به‌شدت از CPU استفاده می‌کنند شناسایی کنید.

Lighthouse پشتیبانی از ارزیابی و تجزیه کردن اسکریپت را نشان می‌دهد
ممیزی زمان راه‌اندازی نشان می‌دهد که بار کردن کدام دستورگان‌ها بیشترین زمان را می‌برد.

ممیزی محموله‌های شبکه Lighthouse

ممیزی بار خالص شبکه Lighthouse درخواست‌های شبکه را شناسایی می‌کند، ازجمله درخواست‌های شبکه شخص ثالث که زمان بار کردن صفحه را کند می‌کند و باعث می‌شود کاربران بیشتر از آنچه انتظار دارند برای داده تلفن همراه هزینه کنند.

Lighthouse showing support for large network payloads
«ممیزی محموله‌های شبکه» نشان می‌دهد کدام درخواست‌های شبکه بیشترین زمان را می‌برند و بیشترین داده را واکشی می‌کنند.

مسدودسازی درخواست شبکه Chrome DevTools

Chrome DevTools به شما امکان می‌دهد ببینید وقتی یک اسکریپت، برگه سبک، یا منبع دیگر دردسترس نیست، صفحه‌تان چگونه رفتار می‌کند. این کار با مسدود کردن درخواست شبکه انجام می‌شود، ویژگی‌ای که می‌تواند به اندازه‌گیری تأثیر برداشتن منابع طرف سوم از صفحه‌تان کمک کند.

برای فعال کردن مسدودسازی درخواست، روی هر درخواستی در پانل «شبکه» کلیک راست کنید و مسدود کردن نشانی وب درخواست را انتخاب کنید. سپس برگه مسدود کردن درخواست در کشوی DevTools نمایش داده می‌شود و به شما امکان می‌دهد درخواست‌های مسدودشده را مدیریت کنید.

مسدود کردن نشانی‌های وب درخواست از پانل شبکه DevTools
درخواست‌های شبکه را به‌صورت جداگانه مسدود کنید تا ببینید صفحه‌تان بدون آن‌ها چگونه رفتار می‌کند.

پانل عملکرد Chrome DevTools

پانل «عملکرد» در Chrome DevTools به شناسایی مشکلات عملکرد وب صفحه‌تان کمک می‌کند.

  1. روی ضبط کلیک کنید.
  2. صفحه‌تان را بار کنید. DevTools نمودار آبشاری‌ای نشان می‌دهد که نشان‌دهنده نحوه صرف زمان بارگیری سایت شما است.
  3. به پایین به بالا در پایین پانل «عملکرد» بروید.
  4. روی گروه‌بندی براساس محصول کلیک کنید و اسکریپت‌های شخص ثالث صفحه‌تان را براساس زمان بارگیری مرتب کنید.
پانل «عملکرد» DevTools که نمای پایین به بالا را نشان می‌دهد که براساس محصولات (طرف سوم) گروه‌بندی شده است
اسکریپت‌های شخص ثالث براساس محصول مرتب شده‌اند، و از طولانی‌ترین زمان بار کردن شروع می‌شوند.

برای کسب اطلاعات بیشتر درباره استفاده از Chrome DevTools برای تجزیه‌وتحلیل عملکرد بارگیری صفحه، به شروع به کار با تجزیه‌وتحلیل عملکرد زمان اجرا مراجعه کنید.

در زیر گردش کار توصیه‌شده ما برای اندازه‌گیری تأثیر اسکریپت‌های شخص ثالث آمده است:

  1. از پانل «شبکه» برای اندازه‌گیری مدت زمان بار شدن صفحه‌تان استفاده کنید.
    • برای شبیه‌سازی شرایط دنیای واقعی، توصیه می‌کنیم محدود کردن شبکه و محدود کردن CPU را روشن کنید. بعید است کاربران شما اتصال شبکه سریع و سخت‌افزار رایانه داشته باشند که تأثیر اسکریپت‌های گران‌قیمت را در شرایط آزمایشگاهی کاهش دهد.
  2. نشانی‌های وب یا دامنه‌های مسئول اسکریپت‌های طرف سومی را که فکر می‌کنید مشکل‌ساز هستند مسدود کنید (برای راهنمایی درباره شناسایی اسکریپت‌های پرهزینه، به پانل عملکرد Chrome DevTools مراجعه کنید).
  3. صفحه را مجدداً بار کنید و زمان بار شدن را دوباره اندازه‌گیری کنید.
    • برای داده‌های دقیق‌تر، شاید بخواهید زمان بارگیری را حداقل سه بار اندازه‌گیری کنید. این امر به‌دلیل برخی‌از اسکریپت‌های طرف سوم است که در هر بارگذاری صفحه، منابع متفاوتی را واکشی می‌کنند. برای کمک به این موضوع، «پانل عملکرد DevTools» از چند ضبط پشتیبانی می‌کند.

سنجش تأثیر دستورگان‌های طرف سوم با WebPageTest

WebPageTest از مسدود کردن بار شدن درخواست‌های تکی برای اندازه‌گیری تأثیر آن‌ها در تنظیمات پیشرفته > مسدود کردن پشتیبانی می‌کند. از این ویژگی برای مشخص کردن فهرستی از دامنه‌ها برای مسدود کردن، مانند دامنه‌های تبلیغاتی، استفاده کنید.

تنظیمات پیشرفته WebPageTest < مسدود کردن. کادر نوشتاری را برای مشخص کردن دامنه‌هایی که باید مسدود شوند نمایش می‌دهد.
دامنه‌هایی را که می‌خواهید مسدود کنید در این پانل فهرست کنید.

توصیه می‌کنیم برای استفاده از این ویژگی، گردش کار زیر را دنبال کنید:

  1. صفحه‌ای را بدون مسدود کردن طرف‌های سوم آزمایش کنید.
  2. آزمایش را با مسدود کردن برخی‌از اشخاص ثالث تکرار کنید.
  3. دو نتیجه را از سابقه آزمایش خود انتخاب کنید.
  4. روی مقایسه کلیک کنید.
WebPageTest گزینه مقایسه را نمایش می‌دهد که به شما امکان می‌دهد دو گزارش را مقایسه کنید
نتایج آزمایش بار را برای مقایسه انتخاب کنید.

تصویر زیر ویژگی نوار فیلم WebPageTest را نشان می‌دهد که توالی‌های بارگیری را برای صفحه‌هایی با و بدون منابع طرف سوم فعال مقایسه می‌کند. توصیه می‌کنیم این مورد را برای آزمایش مبدأهای شخص ثالث جداگانه بررسی کنید تا مشخص شود کدام دامنه‌ها بیشترین تأثیر را بر عملکرد صفحه‌تان دارند.

فیلم‌نگار WebPageTest که تأثیر بار کردن سایت را با و بدون غیرفعال کردن طرف‌های سوم نشان می‌دهد
تأثیر مسدود کردن منابع طرف سوم، از استفاده از WebPageTest برای اندازه‌گیری تأثیر برچسب‌های طرف سوم توسط اندی دیویس.

WebPageTest همچنین از دو فرمان که در سطح ساناد برای مسدود کردن دامنه‌ها عمل می‌کنند پشتیبانی می‌کند:

  • blockDomains فهرستی از دامنه‌ها را برای مسدود کردن می‌گیرد.
  • blockDomainsExcept فهرستی از دامنه‌ها را می‌گیرد و هر چیزی را که در فهرست نباشد مسدود می‌کند.

WebPageTest همچنین دارای برگه نقطه تکی شکست (SPOF) است که به شما امکان می‌دهد یک وقفه زمانی یا شکست کامل در بارگیری یک منبع را شبیه‌سازی کنید. برخلاف مسدود کردن دامنه، SPOF به‌آرامی منقضی می‌شود، که می‌تواند برای آزمایش رفتار صفحه‌های شما زمانی که سرویس‌های شخص ثالث تحت بار سنگین هستند یا به‌طور موقت دردسترس نیستند، مفید باشد.

تنظیمات پیشرفته WebPageTest > SPOF > میزبان‌هایی که باید ناموفق شوند
از ویژگی آزمایش SPOF برای شبیه‌سازی خرابی دامنه‌های مشخص‌شده استفاده کنید.

شناسایی iframeهای گران بااستفاده از Long Tasks

وقتی اجرای دستورگان‌ها در iframeهای طرف سوم طول می‌کشد، می‌توانند رشته اصلی را مسدود کنند و کارهای دیگر را به‌تأخیر بیندازند. این کارهای طولانی می‌توانند باعث شوند که گرداننده‌های رویداد به‌کندی کار کنند یا قاب‌ها حذف شوند، که این امر تجربه کاربری را بدتر می‌کند.

برای شناسایی تکالیف طولانی برای پایش کاربر واقعی (RUM)، از میانای برنامه‌سازی کاربردی PerformanceObserver جاوا اسکریپت برای مشاهده ورودی‌های longtask استفاده کنید. این ورودی‌ها حاوی ویژگی ارجاعی هستند که می‌توانید از آن برای تعیین اینکه کدام بافت قاب باعث ایجاد تکلیف طولانی شده است استفاده کنید.

کد زیر 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

اجرای جاوا اسکریپت مسدودکننده تجزیه‌کننده است. وقتی مرورگر با دستورگانی مواجه می‌شود، باید ساخت DOM را موقتاً متوقف کند، دستورگان را به موتور جاوااسکریپت ارسال کند، و اجازه دهد دستورگان اجرا شود و سپس ساخت DOM را ادامه دهد.

مشخصه‌های async و defer این رفتار را به‌صورت زیر تغییر می‌دهند:

  • async باعث می‌شود مرورگر اسکریپت را به‌صورت ناهمگام بارگیری کند، درحالی‌که به تجزیه سند HTML ادامه می‌دهد. وقتی بارگیری اسکریپت تمام می‌شود، تجزیه درحین اجرای اسکریپت مسدود می‌شود.

  • defer باعث می‌شود مرورگر اسکریپت را به‌صورت ناهمگام بارگیری کند درحالی‌که به تجزیه سند HTML ادامه می‌دهد، سپس منتظر می‌ماند تا تجزیه سند کامل شود و بعد اسکریپت را اجرا می‌کند.

همیشه از async یا defer برای دستورگان‌های طرف سوم استفاده کنید، مگراینکه دستورگان برای مسیر پردازشی حیاتی ضروری باشد. اگر مهم است که اسکریپت در اوایل فرایند بارگیری اجرا شود، مثلاً برای برخی اسکریپت‌های تجزیه‌وتحلیل، از async استفاده کنید. از defer برای منابعی که اهمیت کمتری دارند استفاده کنید، مثلاً ویدیوهایی که در قسمت پایین‌تر صفحه رندر می‌شوند و کاربر در ابتدا آن‌ها را نمی‌بیند.

اگر عملکرد نگرانی اصلی شما است، توصیه می‌کنیم برای افزودن اسکریپت‌های ناهمگام تا بعداز بار شدن محتوای مهم صفحه‌تان صبر کنید. توصیه نمی‌کنیم از async برای کتابخانه‌های ضروری مثل jQuery استفاده کنید.

برخی‌از اسکریپت‌ها باید بدون async یا defer بار شوند، به‌ویژه آن‌هایی که بخش‌های مهمی از سایت شما هستند. این موارد شامل کتابخانه‌های UI یا چارچوب‌های شبکه توزیع محتوا (CDN) می‌شود که سایت شما بدون آن‌ها نمی‌تواند کار کند.

برخی‌از دستورات دیگر اگر به‌صورت ناهمگام بار شوند، کار نمی‌کنند. اسناد مربوط به هر اسکریپتی را که استفاده می‌کنید بررسی کنید و هر اسکریپتی را که نمی‌تواند به‌صورت ناهمگام بار شود با جایگزین‌هایی که می‌توانند بار شوند جایگزین کنید. توجه داشته باشید که برخی‌از اشخاص ثالث توصیه می‌کنند که اسکریپت‌هایشان به‌صورت همگام اجرا شود، حتی اگر به‌صورت ناهمگام نیز به‌خوبی کار کنند.

به‌یاد داشته باشید که async همه مشکلات را برطرف نمی‌کند. اگر صفحه‌تان شامل تعداد زیادی متن باشد، مثل متن‌های ردیابی برای اهداف تبلیغاتی، بار کردن آن‌ها به‌صورت ناهمگام مانع از کند شدن بار کردن صفحه نمی‌شود.

استفاده از «نکات منبع» برای کاهش زمان راه‌اندازی اتصال

برقراری اتصال به مبدأهای شخص ثالث می‌تواند زمان زیادی ببرد، به‌ویژه در شبکه‌های کند، زیرا درخواست‌های شبکه چندین مؤلفه پیچیده دارند، ازجمله جستجوهای ساناد و تغییرمسیرها. می‌توانید از نکات منبع مانند برای انجام جستجوهای DNS برای دامنه‌های میزبان اسکریپت‌های شخص ثالث در اوایل صفحه استفاده کنید روند بارگیری، به‌طوری‌که بقیه درخواست شبکه بتواند سریع‌تر ادامه یابد بعداً:

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

اگر دامنه شخص ثالثی که به آن متصل می‌شوید از HTTPS استفاده می‌کند، می‌توانید از نیز استفاده کنید، که هم جستجوهای ساناد را انجام می‌دهد و هم رفت‌وبرگشت‌های TCP را حل‌وفصل می‌کند و مذاکرات امنیت لایه انتقال را مدیریت می‌کند. این مراحل دیگر می‌تواند بسیار کند باشد زیرا شامل تأیید گواهینامه‌های SSL است، بنابراین پیش‌اتصال می‌تواند زمان بارگیری را به‌شدت کاهش دهد.

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

اسکریپت‌های «جعبه امن» با iframe

اگر اسکریپت شخص ثالث را مستقیماً در iframe بار کنید، اجرای صفحه اصلی را مسدود نمی‌کند. AMP از این رویکرد برای دور نگه داشتن جاوا اسکریپت از مسیر بحرانی استفاده می‌کند. توجه داشته باشید که این رویکرد همچنان رویداد onload را مسدود می‌کند، بنابراین سعی کنید ویژگی‌های مهم را به onload متصل نکنید.

‫Chrome همچنین از خط‌مشی اجازه‌ها (که قبلاً «خط‌مشی ویژگی» نام داشت) پشتیبانی می‌کند. این خط‌مشی مجموعه‌ای از خط‌مشی‌ها است که به توسعه‌دهنده اجازه می‌دهد دسترسی به برخی‌از ویژگی‌های مرورگر را به‌صورت انتخابی غیرفعال کند. می‌توانید از این مورد برای جلوگیری از معرفی رفتارهای ناخواسته به سایت توسط محتوای طرف سوم استفاده کنید.

متن‌های اشخاص ثالث را خودتان میزبانی کنید

اگر می‌خواهید کنترل بیشتری بر نحوه بار شدن اسکریپت‌های مهم داشته باشید، مثلاً برای کاهش زمان DNS یا بهبود سرصفحه‌های ذخیره‌سازی HTTP، شاید بتوانید خودتان آن را میزبانی کنید.

بااین‌حال، میزبانی شخصی مشکلات خاص خود را دارد، به‌ویژه وقتی نوبت به به‌روزرسانی اسکریپت‌ها می‌رسد. دستورگان‌های خودمیزبان به‌روزرسانی‌های خودکار برای تغییرات میانای برنامه‌سازی کاربردی یا اصلاحات امنیتی دریافت نمی‌کنند، که این امر می‌تواند منجر به ازدست رفتن درآمد یا مشکلات امنیتی شود تا زمانی که بتوانید دستورگان خود را به‌صورت دستی به‌روز کنید.

به‌عنوان جایگزین، می‌توانید بااستفاده از کارگران سرویس اسکریپت‌های طرف سوم را ذخیره کنید تا کنترل بیشتری بر تعداد دفعات واکشی اسکریپت‌ها از شبکه داشته باشید. همچنین می‌توانید از عامل خدماتی برای ایجاد استراتژی‌های بارگیری استفاده کنید که درخواست‌های غیرضروری طرف سوم را تا زمانی که صفحه‌تان به لحظه کلیدی کاربر برسد، محدود می‌کند.

آزمایش A/B نمونه‌های کوچک‌تر کاربران

آزمایش A/B (یا آزمایش تقسیم) روشی برای آزمایش دو نسخه از یک صفحه برای تحلیل تجربه و رفتار کاربر است. این ابزار نسخه‌های صفحه را برای نمونه‌های مختلف ترافیک وب‌سایت شما دردسترس قرار می‌دهد و ازطریق تجزیه‌وتحلیل تعیین می‌کند کدام نسخه نرخ تبدیل بهتری ارائه می‌دهد.

بااین‌حال، طبق طراحی، آزمایش A/B پردازش را به‌تأخیر می‌اندازد تا تصمیم بگیرد کدام آزمایش باید فعال باشد. اغلب از جاوا اسکریپت برای بررسی اینکه آیا هیچ‌یک از کاربران شما به آزمایش آزمون A/B تعلق دارند یا نه و سپس فعال کردن گونه صحیح استفاده می‌شود. این فرایند می‌تواند تجربه را حتی برای کاربرانی که بخشی از آزمایش نیستند بدتر کند.

برای سرعت بخشیدن به پردازش صفحه، توصیه می‌کنیم اسکریپت‌های آزمایش A/B را به نمونه کوچک‌تری از پایگاه کاربرانتان ارسال کنید و کدی را اجرا کنید که تصمیم می‌گیرد کدام نسخه از صفحه در سمت سرور نمایش داده شود.

بارگیری کُند منابع طرف سوم

منابع طرف سوم جاسازی‌شده، مانند آگهی‌ها و ویدیوها، درصورت ساخت ضعیف می‌توانند عامل اصلی سرعت پایین صفحه باشند. از بار کردن کُند می‌توان برای بار کردن منابع جاسازی‌شده فقط درصورت لزوم استفاده کرد، برای مثال، منتظر ماندن برای ارائه آگهی‌ها در پانویس صفحه تا زمانی که کاربر به‌اندازه کافی پیمایش کند تا آن‌ها را ببیند. همچنین می‌توانید محتوای طرف سوم را پس‌از بار شدن محتوای اصلی صفحه اما قبل‌از اینکه کاربر با صفحه تعامل داشته باشد، به‌صورت کُند بار کنید.

تصویری که دارایی‌های مهم برای تجربه بالای خط تا و دارایی‌های کم‌اهمیت‌تر را که می‌توانند به‌صورت بارگیری کُند بار شوند نشان می‌دهد.
می‌توانید دارایی‌هایی را که کاربر بلافاصله پس‌از بار شدن صفحه نمی‌بیند، به‌صورت کُند بار کنید.

هنگام بار کردن کُند منابع مراقب باشید، زیرا اغلب شامل کد جاوا اسکریپت است که می‌تواند تحت تأثیر اتصالات شبکه ناپایدار قرار گیرد.

DoubleClick در اسناد رسمی خود راهنمایی‌هایی درباره نحوه بار کردن کُند آگهی‌ها ارائه می‌دهد.

بار کردن کُند کارآمد با Intersection Observer

در گذشته، روش‌های تشخیص اینکه آیا عنصری در نمای دید برای اهداف بار کردن کُند قابل‌مشاهده است یا نه، مستعد خطا بودند و اغلب مرورگر را کُند می‌کردند. این روش‌های ناکارآمد اغلب به رویدادهای scroll یا resize گوش می‌دهند، سپس از DOM APIهایی مانند getBoundingClientRect() برای محاسبه مکان عناصر نسبت به نمای هدف استفاده می‌کنند.

IntersectionObserver یک میانای برنامه‌سازی کاربردی مرورگر است که به مالکان صفحه امکان می‌دهد به‌طور مؤثر تشخیص دهند که چه زمانی یک عنصر مشاهده‌شده وارد نمای مرورگر می‌شود یا از آن خارج می‌شود. LazySizes همچنین دارای پشتیبانی اختیاری برای IntersectionObserver است.

تجزیه‌وتحلیل بارگذاری کُند

اگر بار کردن اسکریپت‌های تجزیه‌وتحلیل را بیش‌ازحد به‌تعویق بیندازید، ممکن است داده‌های تجزیه‌وتحلیل ارزشمندی را ازدست بدهید. خوشبختانه، راهبردهایی برای مقداردهی اولیه تنبل تجزیه‌وتحلیل‌ها و درعین‌حال حفظ داده‌های بارگیری اولیه صفحه وجود دارد.

پست وبلاگ فیل والتون راه‌اندازی Google Analytics که در هر سایتی که می‌سازم استفاده می‌کنم یکی از این استراتژی‌ها را برای Google Analytics پوشش می‌دهد.

بار کردن ایمن متن‌های اشخاص ثالث

این بخش راهنمایی‌هایی برای بار کردن اسکریپت‌های طرف سوم به‌صورت هرچه ایمن‌تر ارائه می‌دهد.

از document.write() اجتناب کنید

دستورات طرف سوم، به‌ویژه برای سرویس‌های قدیمی‌تر، گاهی‌اوقات از document.write() برای تزریق و بار کردن دستورات استفاده می‌کنند. این مشکل‌ساز است چون document.write() رفتار ناسازگاری دارد و اشکال‌زدایی خرابی‌های آن دشوار است.

راه حل مشکلات document.write() این است که از آن استفاده نکنید. در Chrome نسخه ۵۳ و بالاتر، Chrome DevTools هشدارهایی را برای استفاده مشکل‌ساز از document.write() در کنسول ثبت می‌کند:

هشدارهای کنسول DevTools که نقض‌های مربوط به جاسازی شخص ثالث بااستفاده از()document.write را برجسته می‌کند
استفاده از پرچم‌های Chrome DevToolsdocument.write().

اگر این خطا را دریافت کردید، می‌توانید سایتتان را برای استفاده از document.write() با جستجوی سرایندهای HTTP ارسال‌شده به مرورگرتان بررسی کنید. Lighthouse همچنین می‌تواند هرگونه اسکریپت طرف سومی را که هنوز از document.write() استفاده می‌کند برجسته کند.

ارزیابی روال‌های مطلوب Lighthouse استفاده از document.write()‎ را پرچم‌گذاری می‌کند
گزارش Lighthouse که نشان می‌دهد کدام دستورگان‌ها از document.write() استفاده می‌کنند.

از مدیران برچسب بااحتیاط استفاده کنید

برچسب تکه‌کدی است که به تیم‌های بازاریابی دیجیتال امکان می‌دهد داده‌ها را جمع‌آوری کنند، کوکی‌ها را تنظیم کنند، یا محتوای طرف سوم مانند ابزاره‌های رسانه‌های اجتماعی را در سایت ادغام کنند. این برچسب‌ها درخواست‌های شبکه، وابستگی‌های جاوا اسکریپت، و منابع دیگری را به صفحه‌تان اضافه می‌کنند که می‌تواند بر عملکرد آن تأثیر بگذارد، و با اضافه شدن برچسب‌های بیشتر، به‌حداقل رساندن این تأثیر برای کاربران دشوارتر می‌شود.

برای اینکه صفحه سریع بار شود، توصیه می‌کنیم از مدیر برچسبی مثل Google Tag Manager (GTM) استفاده کنید. ‫GTM به شما امکان می‌دهد برچسب‌ها را به‌صورت ناهمگام مستقر کنید تا مانع بار شدن یکدیگر نشوند، تعداد تماس‌های شبکه‌ای را که مرورگر برای اجرای برچسب‌ها نیاز دارد کاهش می‌دهد، و داده‌های برچسب را در واسط کاربر لایه داده خود جمع‌آوری می‌کند.

خطرات استفاده از مدیران برچسب

اگرچه مدیران برچسب برای ساده‌سازی بارگیری صفحه طراحی شده‌اند، استفاده بی‌دقت از آن‌ها می‌تواند به‌جای آن، سرعت بارگیری را به روش‌های زیر کاهش دهد:

  • تعداد بیش‌ازحد برچسب‌ها و شنوندگان رویداد خودکار در مدیر برچسب شما باعث می‌شود مرورگر درخواست‌های شبکه بیشتری نسبت‌به آنچه درغیراین‌صورت نیاز دارد ایجاد کند و توانایی کد شما را برای پاسخ سریع به رویدادها کاهش می‌دهد.
  • هرکسی که اطلاعات کاربری و دسترسی داشته باشد می‌تواند جاوا اسکریپت را به مدیر برچسب شما اضافه کند. این کار نه‌تنها می‌تواند تعداد درخواست‌های شبکه پرهزینه موردنیاز برای بار کردن صفحه‌تان را افزایش دهد، بلکه می‌تواند خطرات امنیتی و مشکلات عملکردی دیگری را ازسوی دستورگان‌های غیرضروری ایجاد کند. برای کاهش این خطرات، توصیه می‌کنیم دسترسی به مدیر برچسبتان را محدود کنید.

از دستورگان‌هایی که دامنه جهانی را آلوده می‌کنند اجتناب کنید

متون شخص ثالث می‌توانند به انواع روش‌هایی رفتار کنند که صفحه شما را به‌طور غیرمنتظره‌ای خراب می‌کند:

  • اسکریپت‌هایی که وابستگی‌های جاوا اسکریپت را بار می‌کنند می‌توانند با کدی که تعامل بدی با کد شما دارد، محدوده سراسری را آلوده کنند.
  • به‌روزرسانی‌های غیرمنتظره می‌تواند باعث تغییرات مخرب شود.
  • کد شخص ثالث را می‌توان درحین انتقال اصلاح کرد تا بین آزمایش و استقرار صفحه‌تان رفتار متفاوتی داشته باشد.

توصیه می‌کنیم به‌طور منظم بازرسی‌هایی از اسکریپت‌های شخص ثالثی که بار می‌کنید انجام دهید تا عوامل بدخواه را بررسی کنید. همچنین می‌توانید خودآزمایی، یکپارچگی زیرمنبع، و انتقال امن کد شخص ثالث را برای ایمن نگه داشتن صفحه‌تان پیاده‌سازی کنید.

راهبردهای کاهش آسیب

در اینجا چند راهبرد در مقیاس بزرگ برای به‌حداقل رساندن تأثیر اسکریپت‌های طرف سوم بر عملکرد و امنیت سایت شما آورده شده است:

  • HTTPS: سایت‌هایی که از HTTPS استفاده می‌کنند نباید به اشخاص ثالثی که از HTTP استفاده می‌کنند وابسته باشند. برای اطلاعات بیشتر، به محتوای مختلط مراجعه کنید.

  • جعبه امن: اجرای اسکریپت‌های طرف سوم را در iframe با ویژگی sandbox درنظر بگیرید تا کنش‌های دردسترس برای اسکریپت‌ها را محدود کنید.

  • خط‌مشی امنیت محتوا (CSP): می‌توانید از سرایندهای HTTP در پاسخ سرور برای تعریف رفتارهای دستورگان مورداعتماد برای سایتتان استفاده کنید و تأثیرات برخی حملات، مانند دستورگان‌نویسی بین‌سایتی (XSS) را شناسایی و کاهش دهید.

در زیر مثالی از نحوه استفاده از دستورالعمل script-src در CSP برای مشخص کردن منابع جاوا اسکریپت مجاز صفحه آورده شده است:

// 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>

مطالعه بیشتر

برای کسب اطلاعات بیشتر درباره بهینه‌سازی جاوا اسکریپت طرف سوم، توصیه می‌کنیم موارد زیر را بخوانید:

با تشکر از کنجی باهو، جرمی واگنر، پت مینان، فیلیپ والتون، جف پوسنیک و چنی تسای برای بررسی‌هایشان.