بهینهسازی عملکرد از فشردهسازی ساده کد به زمانبندی پیشرفته منابع تغییر یافته است. یکی از تأثیرگذارترین حوزهها برای بهبود Core Web Vitals، بهویژه Largest Contentful Paint (LCP)، کنترل نحوه دریافت داراییهای حیاتی توسط مرورگر است. اگرچه توسعهدهندگان مدتهاست به دستورالعمل <link rel="preload"> تکیه کردهاند، اما مرورگرهای مدرن اکنون رویکردی انعطافپذیرتر را از طریق ویژگی fetchpriority ارائه میدهند. در این مقاله، بررسی میکنیم که چگونه میتوان این استراتژیها را ترکیب کرد تا اطمینان حاصل شود که مهمترین عناصر بصری شما ابتدا بارگذاری میشوند.
درک گلوگاه: LCP و اولویتبندی شبکه
LCP مدتزمانی را اندازهگیری میکند که طول میکشد تا بزرگترین عنصر محتوایی (معمولاً یک تصویر یا بنر اصلی) قابل مشاهده شود. اگر این عنصر توسط منابع دیگر مانند اسکریپتها یا فایلهای CSS مسدود شود، کاربران صفحهای با بارگذاری کند را تجربه میکنند که منجر به نرخ پرش بالاتر میشود. علت ریشهای اغلب اولویت شبکه ناکافی است. بهطور پیشفرض، مرورگرها ممکن است دریافت تصاویر بزرگ را به تأخیر بیندازند اگر منابع دیگر را فوریتر تشخیص دهند. برای رفع این مشکل، باید بهصورت صریح به مرورگر سیگنال دهیم که منابع خاصی دارای اولویت بالایی هستند.
رویکرد مدرن: استفاده از fetchpriority
ویژگی fetchpriority افزودنی نسبتاً جدیدی به HTML5 است که به شما امکان میدهد به مرورگر در مورد فوریت یک منبع راهنمایی دهید. این ویژگی مقادیری مانند high، low و auto را میپذیرد. این موضوع بهویژه زمانی مفید است که نتوانید از preload استفاده کنید یا با محتوای بهصورت پویا رندر شده سروکار دارید. برخلاف preload که اغلب نیاز به نوع MIME صریح و تنظیمات منبع مشترک (cross-origin) دارد، fetchpriority اعلانی (declarative) است و نگهداری آن آسانتر است.
یک سناریوی معمول تصویر اصلی (hero image) را در نظر بگیرید. برای اولویتدهی به آن، کافی است ویژگی را به تگ <img> اضافه کنید:
<img
src="/images/hero-banner.jpg"
alt="Welcome to our platform"
fetchpriority="high"
width="1200"
height="630"
>این یک خط کد به مرورگر میگوید تا این درخواست را بالاتر از اولویتهای استاندارد ارتقا دهد و ممکن است آن را جلوتر از اسکریپتهای شخص ثالث یا CSSهای غیرحیاتی قرار دهد.
استفاده از Preload برای منابع حیاتی
در حالی که fetchpriority قدرتمند است، <link rel="preload"> همچنان استاندارد طلایی برای درخواست صریح دریافت زودهنگام داراییهای حیاتی باقی مانده است، بهویژه اگر بخشی از HTML اولیه نباشند اما برای اولین رندر مورد نیاز باشند. با این حال، سوءاستفاده از preload میتواند منجر به رقابت برای منابع شود. بسیار مهم است که فقط منابعی را preload کنید که بلافاصله مورد نیاز هستند.
برای فونتها و CSSهای حیاتی، preload اغلب ضروری است. برای تصاویر، این یک انتخاب استراتژیک است. در اینجا نحوه preload تصویر اصلی همراه با تگ img استاندارد آورده شده است:
<link
rel="preload"
as="image"
href="/images/hero-banner.jpg"
fetchpriority="high"
>
<img
src="/images/hero-banner.jpg"
fetchpriority="high"
alt="Hero Image"
>توجه داشته باشید که میتوانیم هر دو دستورالعمل را ترکیب کنیم. لینک preload تضمین میکند که اگر منبع هنوز در DOM وجود ندارد، زودتر دریافت شود، در حالی که تگ img با fetchpriority="high" تضمین میکند که پس از کشف، اولویت بالایی خود را حفظ کند.
استراتژی عملی: تعادل بین اولویت و پهنای باند
یک اشتباه رایج این است که همه تصاویر را با اولویت بالا علامتگذاری کنید. این کار میتواند منابع ضروری دیگر مانند تماسهای API یا اسکریپتهای تعاملی را از منابع محروم کند و باعث کندی آنها شود. یک رویکرد استراتژیک شامل شناسایی عنصر واقعی LCP و اولویتدهی فقط به آن تصویر خاص است. سایر تصاویر پایینتر از خط چین (below the fold) باید اولویت پیشفرض یا پایین خود را حفظ کنند.
برای تصاویری که قطعاً بخشی از LCP نیستند، میتوانید بهصورت صریح اولویت آنها را کاهش دهید تا از گرفتگی صف شبکه جلوگیری کنید:
<img
src="/images/galaxy-thumb.jpg"
fetchpriority="low"
alt="Gallery Item"
>نتیجهگیری
بهینهسازی LCP تنها مربوط به فشردهسازی تصاویر نیست؛ بلکه درباره زمانبندی شبکه است. با استفاده از fetchpriority="high" برای داراییهای بصری اصلی و استفاده قضاوتشده از preload برای فونتها و سبکهای حیاتی، میتوانید زمان تعامل (time-to-interactive) را بهطور قابل توجهی کاهش داده و تجربه کاربری را بهبود بخشید. به یاد داشته باشید که معیارهای عملکرد خود را در شرایط دنیای واقعی پایش کنید، زیرا عملکرد دستگاه و شرایط شبکه در میان کاربران شما بهطور گستردهای متفاوت است.