تأثیرات عملکردی بار کردن کُند بیش‌ازحد

توصیه داده‌محور برای بارگیری کُند تصویرها با درنظر گرفتن «معیارهای کلیدی اصلی وب».

بار کردن کُند تکنیکی است که بارگیری منبع را تا زمانی که به آن نیاز باشد به‌تعویق می‌اندازد تا داده‌ها را حفظ کند و رقابت شبکه را برای دارایی‌های حیاتی کاهش دهد. در سال ۲۰۱۹ به استاندارد وب تبدیل شد و امروزه اکثر مرورگرهای اصلی از loading="lazy" برای تصاویر پشتیبانی می‌کنند.

این راهنما خلاصه می‌کند که چگونه داده‌های شفافیت وب دردسترس عموم و آزمایش آ/ب موردی برای درک ویژگی‌های پذیرش و عملکرد بار کردن کُند تصویر در سطح مرورگر تجزیه‌وتحلیل شده است. یافته‌ها نشان داد که بار کردن کُند می‌تواند ابزاری بسیار مؤثر برای کاهش بایت‌های غیرضروری تصویر باشد، اما استفاده بیش‌ازحد می‌تواند بر عملکرد تأثیر منفی بگذارد. به‌طور مشخص، این تحلیل نشان می‌دهد که بار کردن مشتاقانه‌تر تصاویر در نمای اولیه (درحالی‌که بقیه تصاویر به‌صورت آزادانه بار کردن کُند می‌شوند) می‌تواند بهترین نتیجه را از هر دو روش به ما بدهد: بار شدن بایت‌های کمتر و بهبود Core Web Vitals.

به فرزندی پذیرفتن

طبق جدیدترین داده‌های بایگانی HTTP، بار کردن کُند تصویر داخلی توسط ٪۲۹ وب‌سایت‌ها استفاده می‌شود و پذیرش آن به‌سرعت درحال رشد است.

نمودار دایره‌ای که نشان می‌دهد WordPress‏ ۸۴٫۱٪ از پذیرش بارکردن کُند را تشکیل می‌دهد، سایر سیستم‌های مدیریت محتوا ۲٫۳٪، و غیرسیستم‌های مدیریت محتوا ۱۳٫۵٪.
تفکیک انواع وب‌سایت‌هایی که از بار کردن کُند تصویر در سطح مرورگر استفاده می‌کنند. (منبع).

پرس‌وجو از داده‌های خام در پروژه «بایگانی HTTP» درک واضح‌تری از انواع وب‌سایت‌هایی که پذیرش را هدایت می‌کنند به ما می‌دهد: ۸۴٪ از سایت‌هایی که از بارکردن کُند تصویر در سطح مرورگر استفاده می‌کنند از WordPress استفاده می‌کنند، ۲٪ از «سیستم مدیریت محتوا» دیگری استفاده می‌کنند، و ۱۴٪ باقی‌مانده از «سیستم مدیریت محتوا» شناخته‌شده‌ای استفاده نمی‌کنند. این نتایج به‌وضوح نشان می‌دهد که چگونه WordPress در پذیرش پیشتاز است.

نمودار سری زمانی پذیرش بار کردن کُند که در آن WordPress در مقایسه با سایر سیستم‌های مدیریت محتوا و غیرسیستم‌های مدیریت محتوا، با نسبت‌های مشابه با نمودار قبلی، بازیگر غالب است. پذیرش کلی از ژوئیه ۲۰۲۰ تا ژوئن ۲۰۲۱ به‌سرعت از ۱٪ به ۱۷٪ افزایش یافته است.
تفکیک انواع وب‌سایت‌هایی که از بار کردن کُند تصویر در سطح مرورگر استفاده می‌کنند. (منبع).

نرخ پذیرش نیز قابل‌توجه است. یک سال پیش در ژوئیه ۲۰۲۰، سایت‌های WordPress که از بارکردن کُند استفاده می‌کنند ده‌ها هزار وب‌سایت را در مجموعه حدود ۶ میلیون وب‌سایت (۱٪ از کل) تشکیل می‌دادند. از آن زمان، پذیرش بار کردن کُند فقط در WordPress به بیش‌از ۱ میلیون وب‌سایت (۱۴٪ از کل) افزایش یافته است.

عملکرد همبستگی

با کاوش عمیق‌تر در «بایگانی HTTP»، می‌توان عملکرد صفحه‌های دارای بار کردن کُند تصویر در سطح مرورگر را با صفحه‌های فاقد آن ازطریق سنجه «بزرگ‌ترین نقاشی دارای محتوا» (LCP) مقایسه کرد. داده‌های LCP از تجربه‌های کاربران واقعی در گزارش تجربه کاربری Chrome (CrUX) به‌دست می‌آید و نه از آزمایش‌های مصنوعی در آزمایشگاه. نمودار زیر از نمودار جعبه‌ای برای دیداری‌سازی توزیع‌های صدک ۷۵ «بزرگ‌ترین رنگ‌آمیزی محتوایی» هر صفحه استفاده می‌کند: خطوط نشان‌دهنده صدک‌های ۱۰ و ۹۰ و جعبه‌ها نشان‌دهنده صدک‌های ۲۵ و ۷۵ هستند.

نمودار جعبه‌ای و خطی که صدک‌های ۱۰، ۲۵، ۷۵، و ۹۰ را برای صفحه‌هایی که از بار کردن کُند تصویر در سطح مرورگر استفاده می‌کنند و صفحه‌هایی که استفاده نمی‌کنند نشان می‌دهد. درمقایسه، توزیع LCP صفحه‌هایی که از آن استفاده نمی‌کنند سریع‌تر از صفحه‌هایی است که از آن استفاده می‌کنند.
توزیع تجربه «بزرگ‌ترین نقاشی دارای محتوا» در صدک ۷۵ همه صفحه‌ها، تفکیک‌شده براساس اینکه آیا از بار کردن کُند تصویر در سطح مرورگر استفاده می‌کنند یا نه. (منبع).

صفحه میانه بدون بار کردن کُند دارای صدک ۷۵ام LCP با ۲۹۲۲ میلی‌ثانیه است، درمقایسه با ۳۵۴۶ میلی‌ثانیه برای صفحه میانه با بار کردن کُند. به‌طور کلی، وب‌سایت‌هایی که از بار کردن کُند استفاده می‌کنند معمولاً عملکرد LCP بدتری دارند.

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

نمودار جعبه‌ای و خطی که صدک‌های ۱۰، ۲۵، ۷۵، و ۹۰ را برای صفحه‌های WordPress که از بار کردن کُند تصویر در سطح مرورگر استفاده می‌کنند و نمی‌کنند نشان می‌دهد. درمقایسه، توزیع LCP صفحه‌هایی که از آن استفاده نمی‌کنند سریع‌تر از صفحه‌هایی است که از آن استفاده می‌کنند، مشابه نمودار قبلی.
توزیع تجربه «بزرگ‌ترین نقاشی دارای محتوا» در صدک ۷۵ صفحات WordPress، تفکیک‌شده براساس اینکه آیا از بار کردن کُند تصویر در سطح مرورگر استفاده می‌کنند یا نه. (منبع).

متأسفانه، همین الگو هنگام بررسی دقیق‌تر صفحات WordPress نیز ظاهر می‌شود؛ صفحاتی که از بار کردن کُند استفاده می‌کنند معمولاً عملکرد LCP کندتری دارند. صفحه WordPress میانه بدون بار کردن کُند دارای صدک ۷۵ام LCP به‌مدت ۳٬۴۹۵ میلی‌ثانیه است، درمقایسه با ۳٬۷۶۸ میلی‌ثانیه برای صفحه میانه با بار کردن کُند.

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

عملکرد علّی

هدف از آزمون آ/ب اثبات یا رد این فرضیه بود که بار کردن کُند تصویر توکار، همان‌طور که در هسته WordPress پیاده‌سازی شده است، منجر به عملکرد کُندتر «بزرگ‌ترین رنگ محتوایی» و بایت‌های تصویر کمتر می‌شود. روش استفاده‌شده آزمایش یک وب‌سایت نمایشی WordPress با زمینه twentytwentyone بود. هر دو نوع صفحه تکی و بایگانی، که شبیه صفحه‌های مقاله و صفحه اصلی هستند، در رایانه و دستگاه‌های همراه شبیه‌سازی‌شده بااستفاده از WebPageTest آزمایش شدند. هر ترکیبی از صفحه‌ها با و بدون فعال بودن بارکردن کُند آزمایش شد و هر آزمایش نُه بار اجرا شد تا مقدار LCP میانه و تعداد بایت‌های تصویر به‌دست آید.

مجموعه‌ها پیش‌فرض غیرفعال تفاوت با پیش‌فرض
twentytwentyone-archive-desktop ۲٬۰۲۹ ۱٬۷۵۹ ‫-۱۳٪
twentytwentyone-archive-mobile ۱۶۵۷ ۱۴۰۳ ‫-٪۱۵
twentytwentyone-single-desktop ۱٬۶۵۵ ۱٬۷۲۶ ٪۴
twentytwentyone-single-mobile ۱٬۳۵۲ ۱٬۳۸۴ ٪۲
تغییر در LCP (میلی‌ثانیه) با غیرفعال کردن بارگیری کُند تصویر در سطح مرورگر در صفحه‌های نمونه WordPress.

این نتایج میانه «بزرگ‌ترین رنگ محتوایی» را برحسب میلی‌ثانیه برای آزمایش‌های انجام‌شده روی صفحه‌های بایگانی و تکی در رایانه و تلفن همراه مقایسه می‌کند. وقتی بار کردن کُند در صفحه‌های بایگانی غیرفعال شد، «بزرگ‌ترین نقاشی دارای محتوا» با حاشیه قابل‌توجهی بهبود یافت. اما در صفحه‌های تکی، تفاوت چندانی ایجاد نکرد.

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

مجموعه‌ها پیش‌فرض غیرفعال تفاوت با پیش‌فرض
twentytwentyone-archive-desktop 577 1173 ‫‎٪۱۰۳
twentytwentyone-archive-mobile 172 378 ‫‎٪۱۲۰
twentytwentyone-single-desktop 301 850 ‫‎٪۱۸۳
twentytwentyone-single-mobile 114 378 ‫‎٪۲۳۳
تغییر در تعداد بایت‌های تصویر (کیلوبایت) با غیرفعال کردن بار کردن کُند تصویر در سطح مرورگر در صفحه‌های نمونه WordPress.

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

برای خلاصه کردن نتایج آزمایش A/B، تکنیک بار کردن کُند که توسط WordPress استفاده می‌شود به‌وضوح به کاهش بایت‌های تصویر به قیمت تأخیر در LCP کمک می‌کند.

درحال آزمایش اصلاح

مهم‌ترین جنبه پیاده‌سازی بارکردن کُند فعلی WordPress برای این آزمایش این است که تصاویر را در نمای هدف (بالای خط تا) به‌صورت کُند بار می‌کند. پست وبلاگ CMS این را به‌عنوان الگویی برای اجتناب تصدیق می‌کند، اما داده‌های آزمایشی در آن زمان نشان داد که تأثیر بر LCP حداقل بود و ارزش ساده‌سازی پیاده‌سازی در هسته WordPress را داشت.

با توجه به این داده‌های جدید، یک اصلاح آزمایشی ایجاد شد که از بارگذاری تنبل تصاویر بالای خط تا جلوگیری می‌کند و این اصلاح تحت همان شرایط آزمایش A/B اول آزمایش شد.

مجموعه‌ها پیش‌فرض غیرفعال اصلاح تفاوت با پیش‌فرض تفاوت با غیرفعال‌شده
twentytwentyone-archive-desktop ۲٬۰۲۹ ۱٬۷۵۹ ۱۷۴۹ ‫-۱۴٪ ‫٪۱-
twentytwentyone-archive-mobile ۱۶۵۷ ۱۴۰۳ ۱٬۳۵۲ ‫-۱۸٪ ‫-۴٪
twentytwentyone-single-desktop ۱٬۶۵۵ ۱٬۷۲۶ ۱۶۷۶ ٪۱ ‫-۳٪
twentytwentyone-single-mobile ۱٬۳۵۲ ۱٬۳۸۴ ۱٬۳۴۲ ‫٪۱- ‫-۳٪
تغییر در LCP (میلی‌ثانیه) با اصلاح پیشنهادی برای بارگیری کُند تصویر در سطح مرورگر در صفحه‌های نمونه WordPress.

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

مجموعه‌ها پیش‌فرض غیرفعال اصلاح تفاوت با پیش‌فرض تفاوت با غیرفعال‌شده
twentytwentyone-archive-desktop 577 1173 577 ٪۰ ‫-۵۱٪
twentytwentyone-archive-mobile 172 378 172 ٪۰ ‫-۵۴٪
twentytwentyone-single-desktop 301 850 301 ٪۰ ‫-۶۵٪
twentytwentyone-single-mobile 114 378 114 ٪۰ ‫-۷۰٪
تغییر در تعداد بایت‌های تصویر (کیلوبایت) با اصلاح پیشنهادی برای بار کردن کُند تصویر در سطح مرورگر در صفحه‌های نمونه WordPress.

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

این اصلاحیه با چند هشدار همراه است. ‫WordPress تعیین می‌کند کدام تصاویر در سمت سرور بارگذاری کُند شوند، یعنی چیزی درباره اندازه نمای هدف کاربر یا اینکه تصاویر در ابتدا در آن بارگذاری می‌شوند یا نه نمی‌داند. بنابراین، این اصلاح از روش‌های اکتشافی درباره مکان نسبی تصاویر در نشان‌گذاری استفاده می‌کند تا حدس بزند که آیا در نمای هدف بار می‌شود یا نه. به‌طور خاص، اگر تصویر اولین تصویر ویژه در صفحه یا اولین تصویر در محتوای اصلی باشد، فرض می‌شود که بالای خط تا یا نزدیک به آن است و بار کردن کُند نخواهد شد.

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

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

پیاده‌سازی

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

ازآنجایی‌که این روال‌های مطلوب برای همه توسعه‌دهندگان وب قابل‌اجرا است، ممکن است پرچم‌گذاری الگوهای ضد بارکردن کُند در ابزارهایی مانند Lighthouse نیز ارزشمند باشد. اگر مایلید پیشرفت این ممیزی را دنبال کنید، به درخواست ویژگی در GitHub مراجعه کنید. تا آن زمان، یکی از کارهایی که توسعه‌دهندگان می‌توانند برای پیدا کردن نمونه‌های عناصر LCP که به‌صورت بارکردن کُند بار می‌شوند انجام دهند، اضافه کردن گزارش‌گیری دقیق‌تر به داده‌های فیلدشان است.

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

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

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

نتیجه‌گیری

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

امتحان کردن میاناهای برنامه‌سازی کاربردی پلاتفرم وب نسبتاً جدید می‌تواند هم ریسک و هم پاداش داشته باشد—به همین دلیل به آن‌ها ویژگی‌های پیشرفته می‌گویند. درحالی‌که داریم به درکی از دشواری بارکردن کُند تصویر در سطح مرورگر می‌رسیم، جنبه‌های مثبت نحوه استفاده از آن برای دستیابی به عملکرد بهتر را نیز می‌بینیم.