سرعت سایت؛ از چند ثانیه انتظار تا از دست رفتن مشتری
کاربر زمانی که وارد یک وب سایت می شود، منتظر نمی ماند تا تمام بخش های فنی سایت به پایان برسند. او انتظار دارد صفحه اصلی، محصول، مقاله یا اطلاعات مورد نظرش در زمان مناسبی در اختیارش قرار بگیرد.
به همین دلیل عملکرد سایت فقط یک موضوع فنی برای برنامه نویسان نیست؛ مستقیما با تجربه کاربر و عملکرد تجاری وب سایت ارتباط دارد.
یک سایت سریع لزوما سایتی نیست که فقط یک عدد خوب در یک ابزار تست نمایش دهد. سرعت واقعی باید از دید کاربر، دستگاه، شبکه و نوع تعامل با صفحه بررسی شود.
چرا سرعت سایت یک موضوع جدی است؟
فرض کنید کاربری از طریق گوگل وارد یک صفحه خدمات می شود. اگر صفحه دیر نمایش داده شود، تصاویر به تدریج ظاهر شوند، دکمه ها با تاخیر واکنش نشان دهند یا محتوای صفحه هنگام بارگذاری جابه جا شود، تجربه کاربر آسیب می بیند.
این مشکل در سایت های فروشگاهی، سامانه های رزرو، سایت های خدماتی و وب اپلیکیشن ها اهمیت بیشتری دارد؛ زیرا کاربر فقط قرار نیست یک صفحه را بخواند، بلکه باید با سایت تعامل داشته باشد.
Google و پروژه Web.dev سه معیار Core Web Vitals را برای جنبه های مهم تجربه کاربر معرفی می کنند: LCP برای بارگذاری، INP برای پاسخگویی و CLS برای ثبات بصری.
LCP؛ محتوای اصلی چه زمانی دیده می شود؟
LCP یا Largest Contentful Paint یکی از معیارهای مهم عملکرد است و بررسی می کند که بزرگ ترین عنصر محتوایی قابل مشاهده چه زمانی نمایش داده می شود.
برای بسیاری از صفحات، این عنصر می تواند تصویر اصلی، تیتر بزرگ یا بخش اصلی محتوای صفحه باشد.
طبق راهنمای Web Vitals، مقدار LCP در صدک ۷۵ بهتر است حداکثر حدود ۲.۵ ثانیه باشد.
البته رسیدن به این عدد به تنهایی به معنی سریع بودن کامل سایت نیست. ممکن است محتوای اصلی سریع نمایش داده شود اما بعد از آن، اجرای اسکریپت های سنگین باعث شود صفحه برای مدتی پاسخگو نباشد.
INP؛ سایت بعد از کلیک چه واکنشی دارد؟
یکی از مشکلاتی که در سایت های سنگین دیده می شود این است که صفحه ظاهرا بارگذاری شده، اما هنگام کلیک روی منو، دکمه، فیلتر یا فرم، کاربر باید منتظر بماند.
INP برای بررسی همین بخش از تجربه کاربر اهمیت دارد.
این معیار پاسخگویی صفحه به تعاملات کاربر مانند کلیک، لمس و ورود اطلاعات با صفحه کلید را بررسی می کند. مقدار INP برابر یا کمتر از ۲۰۰ میلی ثانیه در صدک ۷۵ به عنوان وضعیت خوب در راهنمای Web Vitals معرفی شده است.
در نتیجه، توسعه دهنده نباید فقط زمان بارگذاری اولیه سایت را بررسی کند؛ عملکرد سایت پس از بارگذاری نیز اهمیت دارد.
CLS؛ چرا صفحه هنگام بارگذاری جابه جا می شود؟
حتما برای شما هم پیش آمده است که هنگام باز شدن یک صفحه، قصد کلیک روی یک دکمه را داشته باشید اما ناگهان تصویر یا تبلیغی بالای آن ظاهر شود و محل دکمه تغییر کند.
این اتفاق نمونه ای از تغییر ناگهانی Layout است.
CLS برای اندازه گیری همین نوع بی ثباتی بصری استفاده می شود. یکی از دلایل رایج CLS نامشخص بودن ابعاد تصاویر، تبلیغات، iframeها و محتوایی است که به صورت پویا به صفحه اضافه می شود.
در طراحی و توسعه صحیح می توان بسیاری از این مشکلات را از ابتدا کنترل کرد.
چه چیزهایی معمولا سایت را کند می کنند؟
کندی سایت معمولا یک دلیل واحد ندارد.
تصاویر بسیار بزرگ، کدهای JavaScript غیرضروری، فایل های CSS سنگین، درخواست های زیاد به سرور، افزونه های متعدد، کوئری های ضعیف دیتابیس، هاست نامناسب، Cache ناقص، فونت های سنگین و سرویس های شخص ثالث می توانند روی عملکرد تاثیر بگذارند.
به همین دلیل، افزایش سرعت سایت با نصب یک افزونه یا فعال کردن یک گزینه همیشه راه حل مناسبی نیست.
ابتدا باید مشخص شود گلوگاه واقعی کجاست.
بهینه سازی تصویر فقط کم کردن حجم فایل نیست
یکی از اولین اقداماتی که معمولا در بهینه سازی سایت بررسی می شود تصاویر هستند.
اما بهینه سازی حرفه ای تصویر شامل چند مرحله است:
انتخاب ابعاد مناسب تصویر
استفاده از فرمت مناسب
فشرده سازی
بارگذاری تنبل تصاویر غیرضروری
مشخص کردن ابعاد تصویر برای جلوگیری از تغییر Layout
و تحویل تصویر متناسب با دستگاه کاربر
هدف این نیست که همه تصاویر را به شدیدترین شکل فشرده کنیم؛ هدف ایجاد تعادل میان کیفیت بصری و عملکرد است.
سرور و کدنویسی نیز اهمیت دارند
گاهی اوقات توسعه دهنده تمام تمرکز خود را روی Front-end می گذارد، در حالی که مشکل اصلی در Backend یا دیتابیس قرار دارد.
یک درخواست ساده ممکن است به چندین کوئری دیتابیس منجر شود. یک API ممکن است اطلاعات غیرضروری را برگرداند. یا یک فرآیند سمت سرور ممکن است برای هر درخواست دوباره محاسبات سنگینی انجام دهد.
در چنین شرایطی، افزایش منابع سرور همیشه بهترین پاسخ نیست.
گاهی یک Query بهینه، Cache مناسب یا اصلاح معماری API می تواند تاثیر بیشتری از افزایش سخت افزار داشته باشد.
تست عملکرد باید بخشی از فرآیند توسعه باشد
بهینه سازی نباید فقط در آخر پروژه انجام شود.
در یک فرآیند حرفه ای بهتر است عملکرد صفحات مهم از مراحل مختلف توسعه بررسی شود. ابزارهایی مانند Chrome DevTools، Lighthouse و WebPageTest می توانند برای بررسی بخش های مختلف عملکرد مورد استفاده قرار گیرند.
همچنین باید تفاوت میان تست آزمایشگاهی و داده های واقعی کاربران را در نظر گرفت. عملکرد یک سایت می تواند با توجه به دستگاه، شبکه و نحوه تعامل کاربران تغییر کند و به همین دلیل داده های واقعی کاربران ارزش زیادی دارند.
سرعت، یک ویژگی تجملی نیست
سرعت مناسب بخشی از کیفیت فنی یک وب سایت است.
یک سایت خوب باید در کنار ظاهر حرفه ای، ساختار مناسب و امکانات کاربردی، پاسخگویی مناسبی نیز داشته باشد.
نگاه ما به Performance این نیست که فقط یک امتیاز بالاتر در ابزارهای تست بگیریم. هدف اصلی این است که کاربر هنگام استفاده از سایت، احساس کند سیستم سریع، پایدار و قابل اعتماد است.
در نهایت، بهترین بهینه سازی آن است که کاربر متوجه وجود آن نشود؛ فقط احساس کند سایت به موقع پاسخ می دهد.