بهینهسازی اسکریپتهای شخص ثالث در ۲۰۲۶: راهنمای عملی Partytown، Facade و کاهش تأثیر بر Core Web Vitals
اسکریپتهای شخص ثالث اصلیترین قاتل Core Web Vitals هستند. با ترکیب Partytown، الگوی facade و GTM سمت سرور، بار آنها را از رشته اصلی مرورگر خارج کنید و LCP و INP را نجات دهید.
بهینهسازی اسکریپتهای شخص ثالث در ۲۰۲۶ یعنی هر اسکریپت خارجی (از Google Tag Manager تا ویجت چت Intercom و پیکسل Meta) را از مسیر بحرانی رندر خارج کنید، آنها را با الگوی facade تا نخستین تعامل کاربر به تأخیر بیندازید، و در صورت امکان اجرایشان را به Web Worker (با Partytown) یا به یک کانتینر GTM سمت سرور منتقل کنید. طبق Web Almanac ۲۰۲۵، ۹۲٪ صفحات دستکم یک منبع شخص ثالث بارگذاری میکنند و اسکریپتها ۲۴.۸٪ کل درخواستهای خارجی را میسازند. همینها بزرگترین قاتل Core Web Vitals در سایتهای بهظاهر بهینه هستند. من در یک فروشگاه تجارت الکترونیک روزم را با همین اسکریپتها میگذرانم و در این راهنما، نتایج واقعی جنگ با آنها را میآورم.
اسکریپتهای شخص ثالث اصلیترین علت شکست Core Web Vitals در سایتهای تجارت الکترونیک هستند و بهطور مستقیم LCP، INP و TBT را تخریب میکنند.
الگوی Facade میتواند ۲۰۰ تا ۴۰۰ کیلوبایت جاوااسکریپت از ویجتهای چت و ویدیوهای YouTube را از بارگذاری اولیه حذف کند.
Partytown در ۲۰۲۶ همچنان در وضعیت Beta است، اما تیم Chrome Aurora با انتقال GTM به Web Worker کاهش ۹۲٪ در TBT گزارش کرده است.
Google Tag Manager سمت سرور فقط زمانی سود واقعی برای INP دارد که تگهای مرورگری را بهطور کامل حذف کنید، نه اینکه به موازات نگه دارید.
یک سایت متوسط باید کمتر از ۱۰ اسکریپت شخص ثالث داشته باشد؛ بالای ۱۵ عدد تقریباً همیشه بهروشنی مضر است.
هر اسکریپت را با استراتژی صریح بارگذاری (afterInteractive، lazyOnload یا onDemand) همراه کنید و با Lighthouse و RUM بهطور مداوم پایش کنید.
اسکریپتهای شخص ثالث چه هستند و چرا مشکلسازند؟
اسکریپت شخص ثالث هر کدی است که در صفحه شما اجرا میشود ولی روی دامنه یا سرور شما میزبانی نمیشود و شما مستقیماً کنترلی روی محتوای آن ندارید. نمونههای آشنا شامل Google Analytics، Google Tag Manager، پیکسل Meta، ویجتهای چت مانند Intercom و Drift، ابزارهای A/B تست مثل Optimizely یا VWO، اسکریپتهای تبلیغاتی، ویدیوهای YouTube و Vimeo، و نقشههای Google Maps میشوند. در تجربهی خودم با یک فروشگاه بزرگ، یک صفحه محصول ساده بهراحتی میتواند بین ۲۰ تا ۳۰ فراخوانی شخص ثالث داشته باشد. هر کدام یک اتصال TCP جدید، یک درخواست DNS، و در بدترین حالت اجرای مسدودکننده روی رشته اصلی.
مشکل اصلی این است که هر بایت جاوااسکریپتی که مرورگر پارس، کامپایل و اجرا میکند، هزینهی چندبرابری نسبت به بایتهای تصویر یا CSS دارد. جاوااسکریپت وظیفههای طولانی (Long Tasks) روی رشتهی اصلی میسازد، همان رشتهای که مرورگر برای پاسخ به کلیک، اسکرول و انیمیشن از آن استفاده میکند. وقتی Intercom مثلاً ۴۰۰ کیلوبایت جاوااسکریپت اجرا میکند، مرورگر برای ۲۰۰ میلیثانیه یا بیشتر «کر» میشود و هر تلاش کاربر برای زدن دکمهی «افزودن به سبد خرید» در آن پنجره در صف میماند. این دقیقاً تعریف تجربهی بد INP است.
موضوع دیگر این است که اسکریپتهای شخص ثالث معمولاً بهصورت مسدودکننده و از منشأ نامعلوم میآیند. سرور آنها ممکن است در قارهای دیگر باشد، ممکن است تحت بار سنگین کند شود، و ممکن است بدون هشدار قبلی نسخهی جدیدی با حجم دوبرابر منتشر کند. اگر شما این اسکریپت را با <script src="..."> ساده در <head> بگذارید، مرورگر تا وقتی آن اسکریپت دانلود و اجرا نشود، رندر بقیهی صفحه را متوقف میکند.
تأثیر واقعی روی LCP، INP و CLS
اسکریپتهای شخص ثالث هر سه معیار Core Web Vitals را تخریب میکنند، اما به روشهای متفاوت. برای LCP (Largest Contentful Paint)، اسکریپتها بر سر پهنای باند و پردازنده رقابت میکنند؛ اگر مرورگر مشغول دانلود و اجرای کد تحلیلی باشد، تصویر hero شما دیرتر بارگذاری میشود. در یک صفحهی محصول واقعی که اخیراً روی آن کار کردم، حذف صرف دو تگ بازاریابی، LCP را از ۴.۲ ثانیه به ۲.۸ ثانیه رساند، بدون هیچ تغییری در تصویر یا HTML.
خب، برای INP (Interaction to Next Paint) داستان بدتر است. هر اسکریپتی که روی رشته اصلی اجرا میشود، تعاملهای کاربر را عقب میاندازد. کلیک روی دکمهی «افزودن به سبد خرید» زمانی که پیکسل Facebook در حال اجرا است، تا پایان اجرای پیکسل در صف میماند. برای درک عمیقتر این پدیده، راهنمای ما در بهینهسازی INP و بهبود تعاملپذیری وب را ببینید که مکانیزم Long Tasks را قدمبهقدم توضیح دادهام.
برای CLS (Cumulative Layout Shift)، اسکریپتهای شخص ثالث معمولاً از طریق بنر تبلیغاتی یا ویجت چتی که پس از بارگذاری صفحه چیدمان را جابهجا میکند، ضربه میزنند. ویجت Intercom که ۲ ثانیه بعد از رندر ظاهر میشود و محتوای زیرش را ۶۰ پیکسل به بالا هل میدهد، یک نمونهی کلاسیک است. راهحل: فضای ثابت رزرو کنید یا از facade استفاده کنید که در ادامه توضیح میدهم. اگر بهبود LCP هدف اصلی شماست، مقالهی بهینهسازی LCP و بهبود سرعت بارگذاری محتوای اصلی یک مسیر تکمیلی خوب است.
جدول مقایسه: چهار استراتژی اصلی برای مهار اسکریپتهای شخص ثالث
راستش را بخواهید، چهار الگوی اصلی در جعبهابزار ما هست. هر کدام مبادلات خودش را دارد و انتخاب درست به نوع اسکریپت، تعامل کاربر و نیازهای تجاری بستگی دارد. جدول زیر انتخاب سریع را ساده میکند:
معیار
defer/async
Facade
Partytown (Web Worker)
Server-side GTM
پیچیدگی پیادهسازی
بسیار کم
کم تا متوسط
متوسط تا زیاد
زیاد (نیاز به Cloud Run)
کاهش TBT/INP
محدود (۱۰-۲۰٪)
زیاد برای اسکریپت هدف
تا ۹۲٪ (طبق Chrome Aurora)
زیاد (اگر تگهای کلاینت حذف شوند)
هزینه ماهانه
صفر
صفر
صفر (لایبرری متنباز)
~$50-$500 (بسته به ترافیک)
سازگاری با اسکریپتها
تقریباً همه
فقط ویجتهای تعاملی
محدود (نیاز تست دقیق)
وابسته به vendor
وضعیت production
پایدار
پایدار
Beta در ۲۰۲۶
پایدار
بهترین کاربرد
اسکریپتهای سبک تحلیلی
چت، ویدیو، نقشه
GTM، پیکسلها، A/B testing
تگهای سنگین بازاریابی
در عمل، این چهار استراتژی مکمل هم هستند. ما در فروشگاه از هر چهار بهطور همزمان استفاده میکنیم: ویجت چت با facade، GTM با کانتینر سمت سرور، پیکسلهای تبلیغاتی با Partytown آزمایشی، و اسکریپتهای سبک با defer ساده. رویکرد «همهیاهیچ» شکست میخورد. هر اسکریپت را جداگانه بررسی کنید.
Partytown در ۲۰۲۶: آماده production است؟
Partytown یک لایبرری متنباز است که اسکریپتهای سنگین شخص ثالث را به یک Web Worker منتقل میکند تا رشتهی اصلی برای کد شما و تعاملهای کاربر آزاد بماند. مکانیزم آن هوشمندانه است: با تعویض type="text/javascript" به type="text/partytown"، اجرای اسکریپت در رشتهی اصلی متوقف میشود، سپس Partytown محتوای اسکریپت را در یک Blob میآورد و در Web Worker اجرا میکند. برای فراخوانیهای DOM (که در Worker مستقیم دسترسپذیر نیستند)، از Proxy و درخواستهای HTTP همزمان و Service Worker برای برقراری ارتباط سنکرون استفاده میکند.
وضعیت رسمی در آگوست ۲۰۲۶: پروژه توسط تیم QwikDev نگهداری میشود و همچنان در Beta است. issueهای فعال در GitHub تا می ۲۰۲۶ گزارش میشوند و تیم به رفع باگها ادامه میدهد. مستندات رسمی صراحتاً میگویند «تضمین نمیشود در هر سناریو کار کند». برای جزئیات بیشتر مستندات Partytown را ببینید و مخزن گیتهاب Partytown را برای وضعیت issueها بررسی کنید.
پیادهسازی پایه در HTML خالص:
<!-- 1. اسکریپت خود Partytown را در head قرار دهید -->
<script>
partytown = {
forward: ['dataLayer.push', 'gtag'],
debug: false,
resolveUrl: function(url) {
// reverse proxy برای دور زدن CORS
if (url.hostname === 'www.googletagmanager.com') {
const proxy = new URL('/api/partytown-proxy', location.origin);
proxy.searchParams.append('url', url.href);
return proxy;
}
return url;
}
};
</script>
<script src="/~partytown/partytown.js"></script>
<!-- 2. تگ GTM را با type مخصوص Partytown قرار دهید -->
<script type="text/partytown">
(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);
j.async=true;
j.src='https://www.googletagmanager.com/gtm.js?id='+i;
f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');
</script>
در Next.js با Pages Router میتوانید از استراتژی worker در next/script استفاده کنید که Partytown را زیر کاپوت اجرا میکند. توجه مهم: تا زمان نگارش این مقاله، این استراتژی در App Router کار نمیکند و توصیهی رسمی تیم Next.js این است که فعلاً از آن دوری کنید. اگر روی App Router هستید، Partytown را دستی از خارج فریمورک اضافه کنید یا صبر کنید.
الگوی Facade: چگونه Intercom، YouTube و ویجتهای چت را lazy load کنیم؟
Facade یک عنصر ایستا و سبک است که شبیه ویجت واقعی به نظر میرسد ولی هیچ کاری نمیکند تا کاربر با آن تعامل کند. در آن لحظه، ویجت واقعی جایگزین میشود. تیم Google در راهنمای facadeهای شخص ثالث web.dev این الگو را رسماً توصیه میکند و Lighthouse چک مخصوص برای شناسایی فرصتهای آن دارد.
موارد کاربرد رایج: ویجتهای چت (Intercom، Drift، Crisp، Zendesk)، ویدیوها (YouTube، Vimeo)، نقشهها (Google Maps)، و ابزارهای اشتراکگذاری اجتماعی. یک ویجت Intercom در حالت عادی میتواند ۴۰۰ کیلوبایت جاوااسکریپت اضافه کند. با facade، این بار به صفر میرسد تا وقتی کاربر واقعاً روی دکمه چت کلیک کند.
پیادهسازی facade ساده برای Intercom:
<!-- دکمه ایستای facade -->
<button
id="intercom-facade"
aria-label="باز کردن چت پشتیبانی"
style="position:fixed;bottom:20px;right:20px;width:60px;height:60px;
border-radius:50%;background:#0084ff;color:#fff;border:none;
box-shadow:0 4px 12px rgba(0,0,0,.15);cursor:pointer;z-index:9999;">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" aria-hidden="true">
<path d="M20 2H4a2 2 0 0 0-2 2v18l4-4h14a2 2 0 0 0 2-2V4a2 2 0 0 0-2-2z"
stroke="currentColor" stroke-width="2"/>
</svg>
</button>
<script>
const facade = document.getElementById('intercom-facade');
let intercomLoaded = false;
function loadIntercom() {
if (intercomLoaded) return;
intercomLoaded = true;
window.intercomSettings = { app_id: 'YOUR_APP_ID' };
// بارگذاری اسکریپت واقعی Intercom
(function(){
var w=window,ic=w.Intercom;
var d=document,i=function(){i.c(arguments)};
i.q=[];i.c=function(args){i.q.push(args)};
w.Intercom=i;
var s=d.createElement('script');
s.async=true;
s.src='https://widget.intercom.io/widget/YOUR_APP_ID';
d.head.appendChild(s);
s.onload=function(){
window.Intercom('show');
facade.style.display='none';
};
})();
}
// بارگذاری در اولین تعامل
facade.addEventListener('click', loadIntercom, { once: true });
// یا در حالت idle بعد از ۱۵ ثانیه
if ('requestIdleCallback' in window) {
setTimeout(() => requestIdleCallback(loadIntercom), 15000);
}
</script>
برای YouTube، کامپوننتهای آمادهای مثل lite-youtube و lite-vimeo-embed وجود دارد که با یک تگ HTML سفارشی iframe کامل را با یک تصویر و دکمه پخش جایگزین میکنند. حجم اولیه از حدود ۸۰۰ کیلوبایت به کمتر از ۳ کیلوبایت کاهش مییابد. برای یک صفحه لندینگ که ۵ ویدیو دارد، این تفاوت بین LCP ۶ ثانیه و LCP ۲.۵ ثانیه است.
GTM سمت سرور در برابر سمت کلاینت: کدام برای INP بهتر است؟
Google Tag Manager سمت سرور (sGTM) اجرای تگ را از مرورگر کاربر به یک کانتینر Cloud Run منتقل میکند. به جای اینکه مرورگر ده درخواست جداگانه به Google Analytics، Google Ads، Meta و LinkedIn بفرستد، فقط یک درخواست HTTPS به سرور شما میفرستد و آن سرور داده را پردازش و به هر vendor توزیع میکند. برای معماری فنی مستقیم مستندات رسمی GTM سمت سرور بهترین مرجع است.
سود عملکردی sGTM برای INP و LCP از دو مسیر میآید: کاهش کد اجراشده در مرورگر و کاهش تعداد درخواستهای HTTP خارجی. یک بنچمارک از یک فروشگاه با ۸ تگ بازاریابی نشان داد که مهاجرت کامل به sGTM، INP را از ۴۲۰ میلیثانیه به ۱۸۰ میلیثانیه رساند — از ناحیه «ضعیف» به «خوب».
اما یک نکتهی کلیدی که خیلی از تیمها اشتباه میکنند: اگر تگ سمت مرورگر را نگه دارید و به موازات کانتینر سمت سرور بیندازید، هیچ سود عملکردی نخواهید دید. برای مثال، اگر پیکسل Facebook همچنان در مرورگر بارگذاری شود در حالی که Conversions API را هم پشت sGTM دارید، پیکسل هنوز رشتهی اصلی را قفل میکند. سود واقعی فقط با حذف کامل اسکریپتهای مرورگری برای آن vendor میآید.
هزینهی واقعی: کانتینر Cloud Run معمولاً بین $۵۰ تا $۵۰۰ در ماه بسته به ترافیک هزینه دارد. برای سایت کوچک با یک GA4 و یکی دو تگ سبک، صرفهی اقتصادی ندارد. اما برای سایتهای با ۵+ تگ سنگین بازاریابی، هم عملکرد و هم کیفیت داده بهتر میشود. طبق بنچمارکهای صنعتی، sGTM بهطور میانگین ۲۰٪ رویدادهای تبدیل معتبر بیشتر ثبت میکند چون توسط ITP و ad blockerها فیلتر نمیشود.
تفاوت async، defer و lazyOnload برای اسکریپتهای خارجی چیست؟
سه اتریبیوت اصلی برای کنترل زمان بارگذاری اسکریپتهای خارجی وجود دارد. انتخاب صحیح میتواند بین ثانیهها تفاوت ایجاد کند:
async: اسکریپت بهصورت موازی دانلود میشود و بهمحض دانلود شدن، رندر HTML را متوقف میکند تا اجرا شود. مناسب برای اسکریپتهای مستقل مانند تحلیلی که ترتیب اجرا برایشان مهم نیست، ولی میتوانند INP اولیه را تخریب کنند.
defer: بهصورت موازی دانلود میشود اما اجرای آن تا پایان پارس HTML به تأخیر میافتد. ترتیب اجرا حفظ میشود. بهترین پیشفرض برای اکثر اسکریپتهای شخص ثالث.
lazyOnload (در Next.js و کتابخانههای مشابه): اسکریپت فقط پس از رویداد load و در زمان idle مرورگر بارگذاری میشود. بهترین برای چت، ویجتهای اجتماعی، و هر چیزی که در بارگذاری اولیه دیده نمیشود.
نمونه استفاده در Next.js با کامپوننت Script:
import Script from 'next/script';
export default function Layout({ children }) {
return (
<>
{children}
{/* GA4: بعد از تعاملی شدن، غیرمسدودکننده */}
<Script
src="https://www.googletagmanager.com/gtag/js?id=G-XXXX"
strategy="afterInteractive"
/>
<Script id="ga4-config" strategy="afterInteractive">
{`
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXX', { send_page_view: true });
`}
</Script>
{/* Intercom: فقط بعد از load و idle */}
<Script
src="https://widget.intercom.io/widget/YOUR_APP_ID"
strategy="lazyOnload"
/>
{/* اسکریپت حیاتی احراز هویت: قبل از تعامل کاربر */}
<Script
src="https://auth.example.com/sdk.js"
strategy="beforeInteractive"
/>
</>
);
}
در استراتژی afterInteractive در Next.js، اسکریپت بعد از هیدراسیون صفحه اجرا میشود که برای اکثر تگهای تحلیلی و بازاریابی گزینهی پیشفرض درست است. اگر با بهینهسازی باندل جاوااسکریپت با Tree Shaking و Code Splitting ترکیب کنید، بار اولیهی رشتهی اصلی حداقل میشود.
بودجه اسکریپت شخص ثالث و تعریف SLO
در تیم من، هر اسکریپت شخص ثالث باید در برابر یک بودجه توجیه شود. بدون بودجه، تیم بازاریابی هر ماه یک تگ جدید اضافه میکند تا صفحه بهطور آرام از ۲ اسکریپت به ۲۵ عدد برسد (بله، این را از نزدیک دیدهام). بودجهی پیشنهادی ما برای یک صفحهی محصول فروشگاهی:
حداکثر ۸ اسکریپت شخص ثالث در بارگذاری اولیه (قبل از تعامل کاربر)
مجموع حجم JS شخص ثالث زیر ۱۵۰ کیلوبایت gzip در راه اصلی
هیچ اسکریپت شخص ثالث با strategy="beforeInteractive" مگر برای احراز هویت یا SDKهای پرداخت
کل Total Blocking Time زیر ۲۰۰ میلیثانیه در ۹۵ درصد دستگاههای واقعی
INP زیر ۲۰۰ میلیثانیه در p75
این اعداد را در CI جا بدهید. برای مثال با lighthouse-ci در GitHub Actions میتوانید هر PR را در برابر بودجه بسنجید و اگر تخطی شد، merge را مسدود کنید. تیم بازاریابی که ببیند PR اضافهشدن پیکسل جدید در CI شکست خورد، خودش شروع میکند سؤالات درست بپرسد.
یک ابزار مفید تکمیلی، Speculation Rules API و prerender/prefetch است که میتواند بار اسکریپتهای شخص ثالث را برای صفحات بعدی به پسزمینه منتقل کند و INP در ناوبریها را عملاً به صفر برساند.
حسابرسی و پایش مداوم با Lighthouse و WebPageTest
بدون پایش، هر پیشرفتی در چند هفته از بین میرود. مسیر کاری ما شامل سه لایه است:
حسابرسی هفتگی با Lighthouse CI: هر شنبه شب یک اجرای برنامهریزیشده روی صفحههای کلیدی. بخش «Third-party code» گزارش میکند کدام اسکریپتها بیشترین زمان رشتهی اصلی را میخورند. اگر یک تگ جدید یا رشد ناگهانی یک تگ قدیمی ظاهر شود، ticket ساخته میشود.
پایش RUM با CrUX یا Sentry Performance: دادههای میدانی از کاربران واقعی. Lab data کافی نیست چون Long Tasks در دستگاههای میانرده اثر متفاوتی دارند. CrUX Dashboard در Data Studio راهاندازی سریع دارد و رایگان است.
WebPageTest برای comparison: قبل و بعد از هر تغییر مهم، یک تست از سه لوکیشن (US، EU، APAC) روی دستگاه Moto G4 بگیرید. Waterfall واضح نشان میدهد کدام اسکریپت چقدر بلوک میکند و کجا در صف ماند.
یک تکنیک عملی که کم استفاده میشود: در Chrome DevTools، تب «Performance» را باز کنید، ضبط کنید، سپس بخش «Bottom-Up» را روی Group by Domain تنظیم کنید. این نما دقیقاً میگوید هر دامنه شخص ثالث چقدر از CPU مرورگر را در آن جلسه بلعیده است. من از این نما هر هفته برای پرسیدن سؤال «چرا این عدد بزرگ شد؟» استفاده میکنم و معمولاً پاسخ یک تگ جدیدی است که تیم مارکتینگ در سایلنت اضافه کرده.
در نهایت، اسکریپتهای شخص ثالث از بین نمیروند. اما با ترکیب facade برای ویجتهای سنگین، Partytown برای تگهای سازگار، sGTM برای تگهای بازاریابی، و بودجهی سختگیرانهی CI، میتوانید فروشگاهی داشته باشید که هم Analytics تیم را راضی نگه دارد و هم LCP زیر ۲.۵ ثانیه و INP زیر ۲۰۰ میلیثانیه باشد. جنگ ادامه دارد، اما با این ابزارها، سمت شما پیروز میشود.
پرسشهای متداول
اسکریپتهای شخص ثالث دقیقاً چه هستند؟
هر اسکریپتی که در سایت شما اجرا میشود اما روی دامنه یا سرور شما میزبانی نمیشود، اسکریپت شخص ثالث محسوب میشود. نمونهها شامل Google Analytics، GTM، پیکسل Meta، ویجتهای چت مانند Intercom و Drift، ابزارهای A/B تست، ویدیوهای YouTube و نقشههای Google هستند. طبق Web Almanac ۲۰۲۵، ۹۲٪ صفحات وب حداقل یک منبع شخص ثالث بارگذاری میکنند.
آیا Partytown با Next.js App Router کار میکند؟
خیر. تا آگوست ۲۰۲۶، استراتژی worker در next/script فقط با Pages Router کار میکند و در App Router پشتیبانی نمیشود. توصیهی رسمی این است که تا زمانی که این پروژه بالغ شود یا DOM در Web Workerها در دسترس قرار گیرد، از این استراتژی در App Router دوری کنید و بهجایش از پیادهسازی دستی Partytown یا استراتژی facade استفاده کنید.
بهترین استراتژی برای بارگذاری Google Tag Manager چیست؟
ابتدا از strategy="afterInteractive" استفاده کنید تا GTM بعد از تعاملی شدن صفحه اجرا شود. اگر تعداد تگها بالای ۵ عدد رفت و INP همچنان بد است، به کانتینر سمت سرور (sGTM) مهاجرت کنید و تگهای مرورگری را کامل حذف کنید. برای مواردی که sGTM ممکن نیست، Partytown را روی GTM آزمایش کنید. تیم Chrome Aurora با این ترکیب کاهش ۹۲٪ TBT گزارش کرده است.
Facade چیست و چه زمانی از آن استفاده کنم؟
Facade یک عنصر HTML ایستا و سبک است که ظاهراً شبیه یک ویجت شخص ثالث (چت، ویدیو، نقشه) به نظر میرسد ولی فقط با کلیک یا تعامل کاربر، اسکریپت واقعی را بارگذاری میکند. از آن برای هر ویجتی که در بارگذاری اولیه دیده نمیشود یا کاربر معمولاً بلافاصله با آن تعامل نمیکند استفاده کنید. ویدیوهای YouTube، ویجتهای چت مانند Intercom، و نقشههای Google Maps کاندیداهای کلاسیک هستند.
آیا Google Tag Manager سمت سرور واقعاً INP را بهبود میدهد؟
بله، اما فقط اگر تگهای سمت مرورگر را کاملاً حذف کنید. اگر پیکسل Facebook در مرورگر بارگذاری شود و Conversions API را هم به موازات پشت sGTM بگذارید، سود عملکردی نخواهید دید. برای سایتهای با ۵+ تگ سنگین بازاریابی که کامل مهاجرت میکنند، بهبود قابل توجه در INP و LCP انتظار میرود؛ برای سایت با فقط GA4 و یکی دو تگ سبک، تفاوت ناچیز خواهد بود.
راهنمای عملی Speculation Rules API در سال ۲۰۲۶: prerender و prefetch با eagerness، پیادهسازی در Next.js، fallback سافاری و اثر واقعی بر LCP و آنالیتیکس.
راهنمای عملی بهینهسازی تصاویر مدرن وب با AVIF، WebP و srcset. تنظیم fetchpriority برای LCP، جلوگیری از CLS با width/height صریح، و کاهش ۵۰٪ حجم فایل با نمونه کد sharp و الگوی picture.
