learn

آموزش GTmetrix؛ خواندن گزارش سرعت و Core Web Vitals

راهنمای خواندن گزارش فعلی GTmetrix و تبدیل امتیازها به اصلاحات قابل‌اندازه‌گیری در سایت.

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

شروع آموزش GTmetrix با تنظیم آزمون

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

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

Grade، Performance و Structure چه تفاوتی دارند؟

طبق راهنمای فعلی گزارش GTmetrix، در نسخهٔ به‌روزشدهٔ ۱۵ سپتامبر ۲۰۲۶، Grade از ۶۰ درصد Performance و ۴۰ درصد Structure تشکیل می‌شود. Performance نتیجهٔ معیارهای عملکرد آزمایشگاهی است؛ Structure ارزیابی توصیه‌های ساختاری ابزار را نشان می‌دهد. وزن‌های قدیمی ۷۰ و ۳۰ درصد را برای گزارش فعلی مبنا نگیرید.

وزن معیارهای Performance در همان راهنما عبارت است از FCP برابر ۱۰ درصد، Speed Index برابر ۱۰ درصد، LCP برابر ۲۵ درصد، TBT برابر ۳۰ درصد و CLS برابر ۲۵ درصد. TTI در این فهرست وزنی نیست. ابزارها تغییر می‌کنند؛ هنگام تفسیر یک گزارش تاریخی، نسخه و توضیح همان گزارش را نیز بررسی کنید.

تفاوت آزمایش سرعت با Core Web Vitals

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

TBT شاخص آزمایشگاهی مسدودشدن رشتهٔ اصلی است و جای اندازه‌گیری INP کاربران واقعی را نمی‌گیرد. بنابراین سبزبودن TBT به‌تنهایی به معنای قبولی تمام Core Web Vitals نیست. برچسب یا آستانهٔ یک پنل آزمایشگاهی را نیز با آستانهٔ رسمی دادهٔ میدانی یکسان فرض نکنید.

کدام بخش گزارش را بخوانیم؟

  • Summary نقطهٔ شروع مشاهدهٔ وضعیت کلی و مسائل مهم صفحه است.
  • Performance زمان‌ها و معیارهای آزمون را برای تشخیص مشکل نمایش، تعامل یا جابه‌جایی چیدمان ارائه می‌کند.
  • Structure پیشنهادها را نشان می‌دهد؛ هر پیشنهاد را با اثر واقعی و شرایط سایت بسنجید.
  • Waterfall ترتیب درخواست‌ها، زمان انتظار و فایل‌های سنگین را روشن می‌کند.
  • CrUX در صورت وجود دادهٔ کافی، تجربهٔ واقعی را در بازهٔ گردشی ۲۸ روزه نشان می‌دهد؛ نبود داده مساوی خوب یا بد بودن صفحه نیست.

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

تبدیل گزارش به برنامهٔ اصلاح

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

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

مطالعهٔ مرتبط

بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.

مطالب مرتبط

ارسال نظر

فهرست مطالب