سریع‌ترین و بهینه‌ترین منبع، منبعی است که ارسال نشده است. باید منابع غیرضروری را از برنامه‌تان حذف کنید. بهتر است فرضیات ضمنی و صریح را با تیمتان زیر سؤال ببرید و به‌طور دوره‌ای آن‌ها را بازبینی کنید. در اینجا چند مثال آورده شده است:
- شما همیشه منبع X را در صفحه‌هایتان گنجانده‌اید، اما آیا هزینه بارگیری و نمایش آن ارزش ارائه‌شده به کاربر را جبران می‌کند؟ آیا می‌توانید ارزش آن را بسنجید و اثبات کنید؟
- آیا منبع (به‌ویژه اگر منبع طرف سوم باشد) عملکرد ثابتی ارائه می‌دهد؟ آیا این منبع در مسیر بحرانی قرار دارد یا باید قرار داشته باشد؟ اگر منبع در مسیر بحرانی باشد، آیا می‌تواند نقطه تکی شکست برای سایت باشد؟ یعنی اگر منبع دردسترس نباشد، آیا بر عملکرد و تجربه کاربری صفحه‌هایتان تأثیر می‌گذارد؟
- آیا این منبع به SLA نیاز دارد یا SLA دارد؟ آیا این منبع از روال‌های مطلوب عملکرد پیروی می‌کند: فشرده‌سازی، ذخیره‌سازی، و غیره؟
اغلب اوقات، صفحه‌ها حاوی منابعی هستند که غیرضروری‌اند یا بدتر از آن، عملکرد صفحه را مختل می‌کنند بدون اینکه ارزش زیادی برای بازدیدکننده یا سایتی که در آن میزبانی می‌شوند داشته باشند. این امر به‌طور یکسان برای منابع و ابزاره‌های شخص اول و شخص ثالث اعمال می‌شود:
- سایت الف تصمیم گرفته است گردونه عکسی را در صفحه اصلی خود نمایش دهد تا بازدیدکننده بتواند با یک کلیک سریع، چندین عکس را پیش‌دید کند. همه عکس‌ها هنگام بار شدن صفحه بار می‌شوند و کاربر عکس‌ها را یکی‌یکی جلو می‌برد.
- سؤال: آیا تعداد کاربرانی را که چندین عکس را در گردونه مشاهده می‌کنند اندازه‌گیری کرده‌اید؟ ممکن است با بارگیری منابعی که اکثر بازدیدکنندگان هرگز مشاهده نمی‌کنند، هزینه سربار بالایی را متحمل شوید.
- سایت B تصمیم گرفته است ابزاره طرف سومی را برای نمایش محتوای مرتبط، بهبود تعامل اجتماعی، یا ارائه سرویس دیگری نصب کند.
- سؤال: آیا تعداد بازدیدکنندگانی را که از ابزاره استفاده می‌کنند یا روی محتوای ارائه‌شده توسط ابزاره کلیک می‌کنند ردیابی کرده‌اید؟ آیا تعاملی که این ابزاره ایجاد می‌کند برای توجیه سربار آن کافی است؟ علاوه‌براین، آیا برایتان امکان‌پذیر است که از استراتژی بارگیری استفاده کنید تا مطمئن شوید دستورگان تا زمانی که نیاز نباشد بارگیری نمی‌شود؟
تصمیم‌گیری درباره اینکه آیا بارگیری‌های غیرضروری حذف شوند یا نه اغلب به تفکر و سنجش دقیق نیاز دارد. برای کسب بهترین نتایج، به‌طور دوره‌ای این سؤالات را برای هر دارایی در صفحه‌هایتان فهرست‌بندی و بازبینی کنید.
تأثیرات بر معیارهای کلیدی اصلی وب
ابتکار Core Web Vitals توسط Google معرفی شد تا مجموعه‌ای از سنجه‌ها را ارائه دهد که نشان‌دهنده تجربه کاربران هنگام استفاده از وب است. درحالی‌که استراتژی‌های بهینه‌سازی زیادی برای Core Web Vitals وجود دارد، پرسش درباره اینکه آیا منبع خاصی در صفحه بار شود یا نه ممکن است راهی برای بهبود این سنجه‌ها در وب‌سایتتان به شما نشان دهد. در زیر چند نمونه (گروه‌بندی‌شده براساس هریک از «معیارهای کلیدی اصلی وب») آورده شده است که بهتر است آن‌ها را درنظر بگیرید. اگرچه این فهرست کاملی از مثال‌ها نیست (و مثال‌های بسیار دیگری وجود دارد)، خواندن آن‌ها ممکن است شما را به فکر فرو ببرد.
بزرگ‌ترین رندر محتوایی (LCP)
بزرگ‌ترین نقاشی دارای محتوا (LCP) زمان بار شدن بزرگ‌ترین محتوا (برای مثال، نگاره اصلی یا عنوان) را اندازه‌گیری می‌کند. این سنجه به‌عنوان یک سنجه ادراکی مهم درنظر گرفته می‌شود که به کاربر این احساس را می‌دهد که سایت به‌سرعت درحال بار شدن است.
به‌طور کلی، بارگیری منابع کمتر به این معنی است که پهنای باندی که کاربر دارد به منابع کمتری اختصاص داده می‌شود و ممکن است به بهبود «بزرگ‌ترین نقاشی دارای محتوا» منجر شود. یک مثال کلاسیک بار کردن کُند است که در آن تصاویر خارج از نمای هدف درطول بار کردن صفحه بارگیری نمی‌شوند تا زمانی که مرورگر تشخیص دهد کاربر احتمالاً آن‌ها را خواهد دید. اگر گالری ریزعکس بزرگی داشته باشید، مثلاً ۵۰ تصویر، بارکردن کُند همه تصاویر به‌جز ده تصویر اول به این معنی است که مرورگر می‌تواند از پهنای باند دردسترس خود به‌طور کارآمدتری استفاده کند و اولین تصاویری که کاربر می‌بیند سریع‌تر بار می‌شوند.
بااین‌حال، این موضوع لزوماً فقط درباره بار کردن تصاویر کمتر نیست. مرورگر طرح اولویت‌بندی داخلی دارد که تعیین می‌کند هر منبع چقدر پهنای باند باید دریافت کند. بااین‌حال، حتی با این همه منابع—به‌ویژه آن‌هایی که با اولویت بالا بارگیری شده‌اند—این پتانسیل را دارند که منبع وابسته عنصر LCP بالقوه را محروم کنند. این امر به‌ویژه در اتصالات شبکه کُند صادق است. این منبع وابسته ممکن است فایل تصویری باشد که عنصر LCP صفحه را نشان می‌دهد، اما همچنین می‌تواند منبع قلم وب باشد که مرورگر برای پرداز گره نوشتاری که ممکن است به‌عنوان عنصر LCP صفحه تعیین شود به آن نیاز دارد.
اگر وب‌سایت شما نوشتار زیادی دارد، ممکن است عنصر LCP صفحه یک گره نوشتاری باشد. درحالی‌که استراتژی‌های بهینه‌سازی و بارگیری قلم خوب زیادی وجود دارد، شاید ارزش داشته باشد که بررسی کنید آیا قلم سیستم برای نیازهای وب‌سایت شما کافی است یا نه، تا عناصر «بزرگ‌ترین نقاشی دارای محتوا» که گره‌های نوشتاری هستند بتوانند بدون وابستگی به منبع قلم وب بارگیری شوند و تقریباً بلافاصله پس‌از رسیدن CSS و HTML از سرور، رنگ‌آمیزی شوند.
تغییر چیدمان تجمعی
هر منبعی که بار می‌کنید می‌تواند در تغییر چیدمان تجمعی (CLS) صفحه نقش داشته باشد، به‌ویژه اگر بارگیری آن تا زمان رنگ‌آمیزی اولیه تمام نشده باشد. برای تصاویر، اجتناب از «تغییر چیدمان تجمعی» (CLS) شامل اقداماتی مانند تنظیم ابعاد صریح است. برای قلم‌ها، مدیریت بارگیری قلم و احتمالاً تطبیق قلم جایگزین می‌تواند جابه‌جایی‌ها را درطول دوره تعویض قلم وب به‌حداقل برساند. برای جاوا اسکریپت، این کار می‌تواند مدیریت نحوه دستکاری DOM توسط آن اسکریپت باشد تا تغییرات چیدمان به مقدار قابل‌قبولی کاهش یابد.
هر منبعی که در CLS صفحه مشارکت دارد، برای اطمینان از پایداری کافی چیدمان صفحه، به مقداری کار نیاز دارد. با پرسیدن اینکه آیا به منبع خاصی نیاز دارید یا نه، نه‌تنها بارگیری صفحه را تسریع می‌کنید، بلکه تلاش شناختی لازم برای حفظ پایداری چیدمان را نیز کاهش می‌دهید. این کار نه‌تنها به تجربه کاربری بسیار کمتر ناامیدکننده منجر می‌شود، بلکه تجربه توسعه‌دهنده را نیز کمتر ناامیدکننده می‌کند، زیرا زمان بیشتری برای دنبال کردن اهداف دیگر در پروژه‌هایتان خواهید داشت.
تعامل تا ترسیم بعدی (INP)
تعامل تا ترسیم بعدی (INP) پاسخ‌گویی به ورودی‌های کاربر را درطول عمر صفحه اندازه‌گیری می‌کند. INP صفحه می‌تواند به‌شدت تحت‌تأثیر جاوا اسکریپتی باشد که بار می‌کند، زیرا جاوا اسکریپت چیزی است که بیشتر تعاملاتی را که فرد در سراسر وب تجربه می‌کند هدایت می‌کند. به‌ویژه، مقدار منابع اسکریپت بارگیری‌شده درطول بار شدن صفحه می‌تواند کار احتمالاً پرهزینه‌ای را که در ارزیابی و کامپایل اسکریپت دخیل است آغاز کند. هرچه جاوا اسکریپت کمتری درطول راه‌اندازی بار کنید، مرورگر در آن نقطه بحرانی از تجربه صفحه که کاربران ممکن است درحال تلاش برای تعامل با آن باشند، کار کمتری باید انجام دهد.
درحالی‌که راهبردهایی برای کاهش اندازه منابع JavaScript بارگیری‌شده درطول راه‌اندازی وجود دارد (مانند تقسیم کد و تکان دادن درخت)، ارزش دارد که بسته‌هایی را که در پروژه‌هایتان استفاده می‌کنید ممیزی کنید تا ببینید آیا اصلاً ضروری هستند یا نه. برای مثال، lodash روش‌های زیادی دارد که هنوز هم مفید هستند، اما با روش‌هایی ارائه می‌شود که مرورگر به‌طور پیش‌فرض ارائه می‌دهد، مانند توابع خاص Array برای نگاشت، کاهش، و فیلتر کردن، و بسیاری موارد دیگر.
ارتقای پیش‌رو همچنین رویکرد مفیدی برای جاوا اسکریپت است، زیرا به شما امکان می‌دهد تجربه پایه‌ای (اما همچنان کاربردی) را برای کاربران ارائه دهید که می‌توانید آن را برای کاربران دارای دستگاه‌های قدرتمندتر و اتصال‌های شبکه سریع‌تر ارتقا دهید. چه به اصل ارتقای پیش‌رو پایبند باشید یا نه، نکته همچنان باقی است: هر منبع جاوا اسکریپتی که بتوانید از بارگیری آن اجتناب کنید، می‌تواند منجر به تجربه‌ای شود که سریع‌تر به تعاملات کاربر پاسخ می‌دهد، که جنبه‌ای حیاتی از عملکرد وب است.
نتیجه‌گیری
حسابرسی وب‌سایتتان برای بارگیری‌های غیرضروری ممکن است فقط یکی از جنبه‌های ارائه تجربه‌های کاربری سریع باشد، اما جنبه‌ای است که پتانسیل تأثیرگذاری بالایی دارد. برای خلاصه کردن:
- دارایی‌های خودتان و دارایی‌های شخص ثالث را در صفحه‌هایتان فهرست کنید.
- عملکرد هر دارایی را بسنجید: ارزش آن و عملکرد فنی آن.
- تعیین کنید که آیا منابع ارزش کافی را ارائه می‌دهند یا نه.
- تأثیر بارگیری‌های غیرضروری بر معیارهای کلیدی اصلی وب و سنجه‌های پشتیبانی را درک کنید.
با بهینه‌سازی کارایی محتوا به این روش، نه‌تنها عملکرد کلی را بهبود می‌بخشید، بلکه مراقب هستید که پهنای باند کاربران هدر نرود و همچنین سنجه‌های کاربرمحور را بهبود می‌بخشید و تجربه کاربری بهتری ارائه می‌دهید.