مشکلات عملکرد کلیدی

درحال‌حاضر، تصاویر بزرگ‌ترین دارایی‌های وب ازنظر اندازه کل انتقال و تعداد درخواست‌ها در هر صفحه هستند. میانه اندازه کل انتقال صفحه وب تقریباً ۲ مگابایت، از ژوئن ۲۰۲۲ است که تصاویر به‌تنهایی تقریباً نیمی از آن را تشکیل می‌دهند. اغراق نیست اگر بگوییم بهینه‌سازی درخواست‌های تصویر ممکن است بزرگ‌ترین بهینه‌سازی عملکردی باشد که می‌توانید انجام دهید.

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

به‌تعویق انداختن درخواست‌های تصویر

درحالی‌که می‌خواهید با روش‌های مختلفی آشنا شوید تا مطمئن شوید درخواست‌های تصویر شما تا حد امکان کوچک و کارآمد هستند، سریع‌ترین درخواست تصویر همیشه درخواستی خواهد بود که هرگز ساخته نمی‌شود. بنابراین، همین ابتدا می‌خواهم تأثیرگذارترین تغییری را که می‌توانید در نحوه ارائه دارایی‌های تصویری به کاربرانتان ایجاد کنید با شما درمیان بگذارم: مشخصه loading="lazy".

<img src="image.jpg" loading=&quo>t;lazy" alt="…"

این مشخصه تضمین می‌کند که درخواست‌های تصاویر تا زمانی که به ناحیه نمایش کاربر نزدیک نشوند، ارسال نمی‌شوند. این کار باعث می‌شود که درخواست‌ها از بارگذاری اولیه صفحه (زمانی که مرورگر در شلوغ‌ترین حالت خود است) به تعویق بیفتند و از مسیر پرداز زدن بحرانی حذف شوند.

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

اما مشکلی وجود دارد: به‌تعویق انداختن این درخواست‌ها به‌معنای عدم استفاده از فرایندهای بسیار بهینه‌شده مرورگرها برای درخواست تصاویر در اولین فرصت ممکن است. اگر loading="lazy" در عناصر img نزدیک به بالای چیدمان استفاده شود (و بنابراین احتمال بیشتری دارد که هنگام بار شدن اولیه صفحه در نمای کاربر باشد)، این تصاویر ممکن است برای کاربر نهایی به‌طور قابل‌توجهی کندتر به‌نظر برسند.

اولویت واکشی

مشخصه loading نمونه‌ای از تلاش‌های گسترده‌تر برای استانداردسازی وب است تا توسعه‌دهندگان بتوانند کنترل بیشتری بر نحوه اولویت‌بندی درخواست‌ها توسط مرورگرهای وب داشته باشند.

احتمالاً با رویکردهای اصلی مرورگرها برای واکشی اولویت آشنا هستید: برای مثال، درخواست برای فایل CSS خارجی در <head> سند به‌اندازه کافی ضروری درنظر گرفته می‌شود که رندر را مسدود کند، درحالی‌که درخواست برای فایل JavaScript خارجی درست بالای </body> تا زمانی که رندر کامل شود به‌تعویق می‌افتد. اگر مقدار مشخصه loading در <img> «lazy» باشد، درخواست تصویر مرتبط تا زمانی که مرورگر تشخیص دهد که به کاربر نشان داده خواهد شد به‌تعویق می‌افتد. درغیراین‌صورت، آن تصویر همان اولویت را خواهد داشت که هر تصویر دیگری در صفحه دارد.

مشخصه fetchpriority برای این است که به توسعه‌دهندگان کنترل دقیق‌تری بر اولویت دارایی‌ها داده شود و به شما امکان می‌دهد منابع را نسبت‌به منابع هم‌نوع به‌عنوان اولویت «بالا» و «پایین» پرچم‌گذاری کنید. موارد استفاده برای fetchpriority مشابه مشخصه loading است، اما بسیار گسترده‌تر است. برای مثال، ممکن است از fetchpriority="low" در تصویری استفاده کنید که فقط پس‌از تعامل کاربر آشکار می‌شود (چه آن تصویر در نمای کاربر قرار داشته باشد یا نه) تا تصاویر نمایان در جاهای دیگر صفحه را اولویت‌بندی کنید، یا fetchpriority="high" تا تصویری را اولویت‌بندی کنید که می‌دانید به‌محض پردازش صفحه در نما نمایان خواهد شد.

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

سنجش تأثیر تصاویر

هنگام بهینه‌سازی دارایی‌های تصویری، عملکرد درک‌شده اغلب مهم‌تر و اندازه‌گیری آن دشوارتر از اندازه کل انتقال به‌تنهایی است.

Web Vitals سنجه‌ها و راهنمایی‌های قابل‌اندازه‌گیری و کاربردی برای بهبود تجربه کاربران از وب ارائه می‌دهد و مشکلاتی مانند زمان پاسخ آهسته از سرور وب، مشکلات پرداز زدن، و تأخیرهای تعاملی را برجسته می‌کند. «هسته‌های حیاتی وب» زیرمجموعه‌ای از این اهداف هستند که به‌طور دقیق بر تجربه مستقیم کاربر از یک صفحه خاص تمرکز دارند—مجموعه‌ای از اندازه‌گیری‌های فنی که باهم تعیین می‌کنند تجربه کاربر چقدر سریع احساس می‌شود.

تغییر چیدمان تجمعی

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

با زمان بارگیری بالا و مقدار فضایی که می‌توانند در چیدمان اشغال کنند، منطقی است که تصاویر علت رایج امتیازهای CLS بالا باشند.

به‌لطف تغییرات نسبتاً جدید در مرورگرهای مدرن، اجتناب از امتیازهای CLS بالا به‌دلیل تصاویر آسان‌تر از آن چیزی است که فکر می‌کنید.

اگر چند سالی است که روی فرانت‌اند کار می‌کنید، با مشخصه‌های width و height در <img> آشنا خواهید بود: پیش‌از پذیرش گسترده CSS، این‌ها تنها راه کنترل اندازه تصویر بودند.

<img src="image.jpg" height="200"> width="400" alt="…"

این مشخصه‌ها در تلاش برای جدا نگه داشتن نگرانی‌های مربوط به سبک‌بندی از نشانه‌گذاری ما از استفاده خارج شدند، به‌ویژه ازآنجایی‌که طراحی وب واکنش‌گرا مشخص کردن اندازه‌گذاری مبتنی بر درصد را ازطریق CSS ضروری کرد. در روزهای اولیه طراحی وب واکنش‌گرا، «برداشتن ویژگی‌های width و height استفاده‌نشده» توصیه‌ای رایج بود، زیرا مقادیری که در CSS خود مشخص کرده بودیم—max-width: 100% و height: auto—آن‌ها را لغو می‌کردند.

<img src="image.jpg&quo>t; alt="…"

img {
  max-width: 100%;
  height: auto;
}

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

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

به‌عنوان یک قانون، همیشه باید از مشخصه‌های height و width در <img> استفاده کنید، با مقادیری که با اندازه ذاتی منبع تصویر شما مطابقت دارند—تا زمانی که مطمئن شوید height: auto را در کنار max-width: 100% مشخص کرده‌اید تا ارتفاع را از مشخصه HTML لغو کنید.

<img src="image.jpg" height="200"> width="400" alt="…"

img {
  max-width: 100%;
  height: auto;
}

بااستفاده از مشخصه‌های width و height در عناصر <img>، از امتیاز CLS بالا به‌دلیل تصاویر جلوگیری خواهید کرد.

توجه به این نکته مهم است که این رویکرد هیچ جنبه منفی‌ای ندارد، زیرا بر رفتار مرورگر که از دیرباز تثبیت شده است تکیه دارد—هر مرورگری که از CSS پایه پشتیبانی کند، به همان روشی که همیشه کار می‌کرده است کار خواهد کرد، و ویژگی‌های height و width در نشانه‌گذاری شما توسط سبک‌هایتان لغو می‌شود.

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

بزرگ‌ترین رندر محتوایی اولیه

«بزرگ‌ترین نقاشی دارای محتوا» (LCP) مدت‌زمانی را که طول می‌کشد تا بزرگ‌ترین عنصر «دارای محتوا» نمایان در ناحیه نمایش کاربر پرداز زده شود اندازه‌گیری می‌کند—عنصر محتوایی که بیشترین درصد صفحه نمایان را اشغال می‌کند. ممکن است در ظاهر سنجه‌ای بیش‌ازحد خاص به‌نظر برسد، اما این عنصر به‌عنوان پراکسی کاربردی برای نقطه‌ای عمل می‌کند که اکثر صفحه از دیدگاه کاربر رندر شده است. LCP معیار مهمی برای عملکرد (درک‌شده) است.

سنجه‌هایی مانند DOMContentLoaded یا رویداد window.onload می‌توانند برای تعیین زمان تکمیل فنی فرایند بارگیری صفحه فعلی مفید باشند، اما لزوماً با تجربه کاربر از صفحه مطابقت ندارند. تأخیر جزئی در پردازش عنصری خارج از نمای کاربر در هریک از این سنجه‌ها لحاظ می‌شود، اما احتمالاً کاربر واقعی اصلاً متوجه آن نخواهد شد. «بزرگ‌ترین نقاشی دارای محتوا» (LCP) طولانی یعنی اولین برداشت کاربر از صفحه (مهم‌ترین محتوای داخل ناحیه نمایش فعلی) این است که صفحه کند است، یا کاملاً خراب است.

درک کاربر که توسط LCP ثبت می‌شود، تأثیر مستقیمی بر تجربه کاربری دارد. آزمایشی که Vodafone همین سال گذشته انجام داد نشان داد که بهبود ۳۱ درصدی در LCP نه‌تنها منجر به ۸٪ فروش بیشتر شد (که به‌خودی‌خود نتیجه‌ای عالی است)، بلکه از کل تعداد کاربران آن‌ها، ۱۵٪ بهبود در تعداد بازدیدکنندگانی که به مشتریان بالقوه تبدیل شدند («نرخ تبدیل بازدیدکننده به مشتری بالقوه») و ۱۱٪ بهبود در تعداد کاربرانی که از سبد خریدشان بازدید کردند («نرخ تبدیل بازدید به سبد خرید») مشاهده شد.

در بیش‌از ۷۰٪ صفحه‌های وب، بزرگ‌ترین عنصر در ناحیه نمایش اولیه شامل یک تصویر است، چه به‌عنوان یک عنصر مستقل <img> یا عنصری با تصویر پس‌زمینه. به‌عبارت دیگر، ۷۰٪ از امتیازهای LCP صفحه‌ها براساس عملکرد تصویر است. تصور دلیل آن چندان دشوار نیست: تصاویر و نشان‌واره‌های بزرگ و جلب‌توجه‌کننده به احتمال زیاد در «نیمه بالایی صفحه» قرار دارند.

برای جلوگیری از تأخیر LCP می‌توانید چند اقدام انجام دهید: اول، هرگز loading="lazy" را در تصویر «بالای خط تا» مشخص نکنید، زیرا به‌تأخیر انداختن درخواست تا پس‌از پرداز صفحه احتمالاً تأثیر منفی زیادی بر امتیاز LCP شما خواهد داشت. دوم، استفاده از fetchpriority="high" می‌تواند به مرورگر اطلاع دهد که انتقال این تصویر باید نسبت‌به تصاویر جاهای دیگر صفحه اولویت داشته باشد.

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

نتیجه‌گیری

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

هرچند ممکن است این کار دلهره‌آور باشد، اما اگرچه «وب با تصاویر کمتر بهتر خواهد بود» مطمئناً ازنظر عملکرد به‌تنهایی درست است، اما این کار به کاربرانش نیز آسیب بزرگی می‌رساند. تصاویر بخش حیاتی وب هستند و نباید کیفیت محتوای معنادار را صرفاً به‌خاطر عملکرد فدا کنید.

در ادامه این دوره، با فناوری‌هایی که دارایی‌های تصویری ما را تقویت می‌کنند و تکنیک‌هایی برای کاهش تأثیرات عملکردی آن‌ها بدون به‌خطر انداختن کیفیت آشنا خواهید شد.