آموزش گامبهگام تحلیل سرعت با GTmetrix
GTmetrix به دو دلیل هنوز در جعبهابزار بیشتر تیمهای فارسیزبان است: گزارش آبشارِ خوانا و امکان تکرار دقیق همان تست با همان پروفایل. ولی همان ابزار خوب، بدون پروتکل، عدد گیجکننده میسازد؛ تستهای پراکنده با تنظیمات متفاوت چیزی جز نویز تولید نمیکنند. این راهنما همان پروتکل را میسازد و بعد سراغ خواندن گزارش و ترتیب اصلاح میرود.
لایهبندی خانوادهٔ سرعت را روشن کنیم: روش کلی تست — انتخاب صفحهٔ نمونه، پروفایل ثابت و مقایسهٔ قبل و بعد — در آموزش گامبهگام تست سرعت سایت آمده و اینجا همان روش را روی GTmetrix پیاده میکنیم. نمای کل خانواده هم در هاب سرعت و کارایی وردپرس است و لایهٔ زیرینِ سرور را در بخش ترتیب اصلاح جدا میبینیم.
تحلیل سرعت با GTmetrix از کجا شروع میشود؟

هر تحلیل معتبر از یک تنظیم درست شروع میشود. آدرس صفحهٔ نمونه را واقعی بگیرید؛ صفحهٔ محصول یا مقالهای که ترافیک واقعی دارد، نه صفحهٔ خانگی تمیزِ تازهساخته. بعد پروفایل تست را بچینید: موقعیت سرور تست، مرورگر و دستگاه را انتخاب کنید و همین ترکیب را برای همهٔ تستهای بعدی قفل کنید؛ تغییر پروفایل یعنی مقایسهٔ سیب با پرتقال و هدر دادن کل زحمت سنجش.
پس از تنظیم، اولین تست را تنها نفرمایید؛ دو سه بار پشت هم تست بگیرید تا نوسان طبیعی شبکه را ببینید و عدد میانه را مبنای کار بگذارید. ساعت تست را هم ثابت نگه دارید؛ بار شبکه در ساعات شلوغ و خلوت فرق میکند و بخشی از پراکندگی نتایج از همینجا میآید. از این به بعد، هر تغییری که روی سایت میدهید با همین پروفایل و همین ساعت سنجیده میشود و هیچ عددی بیرون از این قاب، قابل مقایسه نیست. پروفایل را در یک برگهٔ کوچک ثبت کنید تا هر همتیمی همان را اجرا کند؛ تنظیماتی که فقط در ذهن یک نفر است، پروفایل نیست و دو هفته بعد گم میشود.
خواندن نمرهها و سنجههای حیاتی صفحه
نمرهٔ کلی، خلاصهٔ وضعیت است و برای پیگیری روند خوب؛ ولی تصمیم اصلاح از آن درنمیآید. سه سنجهٔ حیاتی را جدا بخوانید: LCP میگوید اصلیترین عنصر صفحه چه زمانی دیده میشود، TBT میگوید صفحه چقدر تا پاسخگویی به کاربر آزاد است و CLS میگوید چیدمان حین بارگذاری چقدر جابهجا میشود. جدول زیر هر سنجه و مقصرهای رایجش را کنار هم میگذارد:
| سنجه | چه میگوید | مقصرهای رایج |
|---|---|---|
| LCP | کی اصلیترین عنصر دیده میشود | تصویر سنگین، فونت دیررس، پاسخ کند سرور |
| TBT | چقدر صفحه تا پاسخگویی آزاد است | اسکریپتهای سنگین و کدهای مسدودکنندهٔ رندر |
| CLS | چقدر چیدمان حین بارگذاری جابهجا میشود | تصویر بدون ابعاد، بنر تزریقی، فونت دیررس |
سه سنجه، سه سرنخ متفاوت میدهند؛ نمرهٔ کلی را جای آنها نگذارید. برای هر دور اصلاح فقط یکی را هدف بگیرید.
دو سنجه را با هم بخوانید تا تلهٔ رایج را نبینید: صفحهای با LCP خوب و TBT بد، اولش تند باز میشود ولی بعدش سفت است و کاربر نمیتواند کلیک کند؛ تجربهٔ کاربر بد است با نمرهٔ خوشظاهر. برای همین در هر گزارش، سه سنجه را کنار نمره بگذارید و اصلاح را از بدترین سنجه شروع کنید، نه از نمرهٔ کلی. این تله در گزارشهای تیمی بیشتر تکرار میشود؛ کسی نمره را اعلام میکند و جلسه به برسرآوردن نمره میگذرد، در حالی که هیچکس نگفته کدام سنجه مشکل دارد و مقصرش کدام فایل است.
خواندن آبشار؛ یافتن گلوگاه واقعی

آبشار، قلب GTmetrix است: هر ردیف یک درخواست و طول هر ردیف، زمان آن. سه الگو را جستجو کنید؛ ردیفهای بلندِ ابتدای صفحه که مسیر رندر را نگه میدارند، زنجیرههای متوالی که هر فایل منتظر قبلی میماند و فایلهای بزرگ شخصاول — معمولاً تصویر اصلی و فونت. کنار هر ردیف، اندازه و نوع فایل هم هست و دقیقاً همانجاست که اسم مقصر بیرون میآید.
یک قاعدهٔ خواندن آبشار را همیشه رعایت کنید: به جمع زمانها نگاه نکنید، به زمانهای موازیِ مسیر رندر نگاه کنید. فایل سنگینی که بعد از رندر اصلی میرسد، کاربر را نگه نمیدارد؛ فایل متوسطی که جلوی رندر ایستاده، کل صفحه را نگه میدارد. اولویتبندی اصلاح از همین تفکیک میآید و بدون آن، وقت تیم خرج فایلهای بیاثر میشود و گلوگاه دستنخورده میماند.
برای سایتهای وردپرسی، دو مقصر تکرارشوندهٔ آبشار را از امروز بشناسید: تصویر اصلی بدون فشردهسازی و فونت چندوزنِ تمامحروف. وقتی این دو در بالای فهرست سنگینها مینشینند، اصلاحشان معمولاً بیشترین افت زمان را با کمترین ریسک میدهد و همینجا بهترین نقطهٔ شروع برای اولین دور اصلاح است.
ترتیب اصلاح؛ اول چه چیزی را ببندیم؟
ترتیب اصلاح را از پایین زنجیره شروع کنید. اگر اولین بایت دیر میرسد، هیچ بهینهسازی جلویی جبرانش نمیکند؛ پاسخدهی سرور و کش، لایهٔ زیرین است و روش کاملش در آموزش گامبهگام TTFB و سرعت سرور آمده است. بعد از آن، وزن مسیر رندر میآید: فشردهسازی و اندازهٔ درست تصاویر، حذف فونتهای بیاستفاده و زیرمجموعهسازی فونت فارسی که روشش در آموزش گامبهگام فونت فارسی و سرعت سایت باز شده است. ترتیب را از روی همان آبشار بخوانید؛ گلوگاه زنجیره، مقدم بر تزئینات است.
لایهٔ سوم، اجرای اسکریپتهاست: به تعویق انداختن آنچه رندر را نگه میدارد و سبککردن کدهای شخصاول. لایهٔ آخر، پایداری چیدمان است؛ ابعاد صریح برای تصاویر و فضای رزروشده برای بنرها و فونتها تا صفحه نلرزد. قاعدهٔ اجرا هم یکی است: در هر دور فقط یک تغییر بدهید و با همان پروفایل تست بگیرید؛ تغییرهای موازی، اعتبار مقایسه را میبرند و نمیدانید کدام کار اثر کرد. بعد از هر دور هم یک سطر در برگهٔ نتایج بنویسید: چه تغییر دادید، کدام سنجه جابهجا شد و چقدر؛ این سطرها بعداً سند دفاع شما در جلسهها هستند.
واقعیت تست از ایران؛ چطور نتایج را بخوانیم؟
واقعیت بازار ایران را صریح بگوییم: سرورهای تست GTmetrix بیرون از ایراناند و نتیجه، مسیر شبکهای خارج از کشور را میبیند، نه مسیر کاربر داخل. به تجربهٔ ما فاصلهٔ شبکه و دسترسپذیری برخی سرویسهای خارجی از شبکههای داخلی، تصویر را برای کاربر ایرانی متفاوت میکند؛ پس عدد مطلق گزارش را بهجای تجربهٔ واقعی کاربر نگذارید و با آن نتیجهگیری نهایی نکنید و مقایسهٔ مطلق با سایتهای دیگر هم بیمعناست، چون رقیب شما شاید روی زیرساخت دیگری تست شده باشد.
کاربرد درست دو جاست. اول، مقایسهٔ نسبی قبل و بعد با پروفایل ثابت، که برای تصمیم اصلاح کاملاً معتبر است؛ اگر بعد از بستن تصاویر، آبشار سبک شد، این یافته برای هر مخاطبی درست است. دوم، صحهگذاری روی دادهٔ میدانی — اعدادی که از کاربران واقعی به دست میآید — برای دیدن فاصلهٔ آزمایشگاه با تجربهٔ واقعی. اگر این دو با هم ناخوانا شدند، دادهٔ میدانی را مبنا بگیرید و با آبشار دنبال دلیلش بگردید. این تفکیک را در گزارشهای داخلی هم نگه دارید؛ عدد آزمایشگاهی را با برچسب تستِ خارج و عدد میدانی را با برچسب کاربر واقعی ثبت کنید تا هیچوقت یکی جای دیگری ننشیند.
جمعبندی؛ ریتم تست و ثبت نتایج
ریتم تست را دو سطح ببندید: بعد از هر تغییر معنادار، یک دور کامل با پروفایل ثابت؛ و ماهانه یک تست روتین برای کشف پسرفتها، چون افزونههای تازه و آپدیتها بیصدا سنگین میکنند. نتایج را در یک برگه ثبت کنید: تاریخ، پروفایل، سه سنجه و نمره. این برگه در بازنگریهای فصلی، سند حرکت سایت است و نشان میدهد اصلاحها اثر ماندگار داشتهاند یا موقتی بودهاند.
اگر میخواهید رصد و بهینهسازی در یک ریتم واحد بیفتد، قابلیتهای پلتفرم مسیر انتشار امن و پایش را نشان میدهد و ممیزی رایگان دامنه نقطهٔ شروع سنجیدهای میدهد. سرعت قابلیتی است که با یک اصلاح تمام نمیشود؛ با ریتم تست و ترتیب درست، ماهبهماه ساخته میشود و پسرفتهایش زود لو میرود.
سه سؤال را در بازنگری ماهانه تکرار کنید: پروفایل تست همان قبلی است؟ بدترین سنجهٔ صفحهٔ نمونه کدام است و با ماه قبل چه فرقی دارد؟ و کدام فایل تازه به بالای فهرست سنگینهای آبشار رسیده است؟ جواب همین سه سؤال، پسرفتها را قبل از کاربران نشان میدهد.
رصد ما، رشد شما.
سؤالات پرتکرار
نمرهٔ GTmetrix چقدر مهم است؟
نمره خلاصهٔ وضعیت است و برای پیگیری روند به کار میآید؛ تصمیم اصلاح را نه از نمره، از سه سنجهٔ LCP و TBT و CLS و آبشار بگیرید. دو صفحه با نمرهٔ برابر میتوانند گلوگاههای متفاوت داشته باشند.
چرا عدد تست من با آزمون همکارم فرق دارد؟
چون موقعیت سرور تست، مرورگر، دستگاه و حتی ساعت تست در نتیجه اثر میگذارد. پروفایل تست را ثابت نگه دارید تا مقایسهها معتبر بمانند.
نتایج GTmetrix برای کاربر ایرانی معتبر است؟
بهعنوان مقایسهٔ نسبی قبل و بعد بله؛ بهعنوان عدد مطلق تجربهٔ کاربر ایرانی خیر، چون سرورهای تست بیرون از ایراناند. عدد مطلق را با دادهٔ میدانی کاربران واقعی صحه بگذارید.
بعد از هر اصلاح کی دوباره تست کنیم؟
بعد از هر تغییر معنادار، یک دور کامل با همان پروفایل قبلی؛ و ماهانه یک تست روتین برای کشف پسرفتها. بدون پروفایل ثابت، مقایسه بیمعناست.