افقطراحی، توسعه، رشد
سرعت و تجربه کاربری

افزایش سرعت سایت؛ راهنمای LCP، INP و CLS برای مدیران کسب‌وکار

حدود ۴ دقیقه مطالعه
تصویرسازی لپ‌تاپ و ابزارهای توسعه وب برای بررسی عملکرد سایت
بهینه‌سازی عملکرد به بررسی تصاویر، کد و مسیر تعامل کاربر نیاز دارد.

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

نکتهٔ اصلی

سه مشکل را جدا کنید: دیر دیده‌شدن محتوا، دیر پاسخ‌دادن صفحه و جابه‌جایی ناگهانی اجزا. هرکدام راه بررسی متفاوتی دارند.

سه شاخص اصلی چه چیزی را نشان می‌دهند؟

طبق راهنمای web.dev، LCP زمان نمایش بزرگ‌ترین محتوای قابل مشاهده، INP پاسخ‌گویی به تعامل و CLS ناپایداری بصری را می‌سنجد. محدوده خوب به‌ترتیب حداکثر ۲٫۵ ثانیه، ۲۰۰ میلی‌ثانیه و ۰٫۱ است. ارزیابی بر پایه صدک ۷۵ بازدیدها و با تفکیک موبایل و دسکتاپ انجام می‌شود؛ یک بار باز کردن سایت روی لپ‌تاپ معیار کافی نیست.

منبع: تعریف و آستانه‌های Core Web Vitals در web.dev

گزارش واقعی با آزمایش شبیه‌سازی‌شده فرق دارد

داده میدانی از تجربه کاربران واقعی می‌آید؛ آزمایش آزمایشگاهی در شرایط کنترل‌شده اجرا می‌شود. Lighthouse برای تشخیص مسائل فنی مفید است، اما اجرای عادی آن INP واقعی کاربران را اندازه نمی‌گیرد. در سایت کم‌ترافیک ممکن است داده میدانی کافی وجود نداشته باشد؛ نبود گزارش به معنی خوب یا بد بودن عملکرد نیست.

منبع: تفاوت سنجش میدانی و آزمایشگاهی

یک بررسی کاربردی را از کجا شروع کنیم؟

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

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

  • سه تا پنج صفحه مهم را با یک روش ثابت بررسی کنید
  • زمان و شرایط آزمایش را در گزارش بنویسید
  • رفتار منو، فیلتر و فرم را روی گوشی هم امتحان کنید
  • پس از اصلاح، همان صفحه‌ها و همان مسیرها را دوباره بررسی کنید

اولویت‌های اصلاح را از شواهد انتخاب کنید

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

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

در قرارداد بهینه‌سازی چه خروجی بخواهیم؟

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

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

این موضوع برای سایت شما هم مطرح است؟

نیازها و آدرس سایتتان را با تیم افق در میان بگذارید تا مسیر مناسب پروژه را بررسی کنیم.

همه مقاله‌ها
شروع گفت‌وگو