جلسه ۴ – تحلیل گزارش Performance در GTmetrix جدید

سلام به همراهان عزیز میزفا؛ با مقاله چهارم از سری آموزش GTmetrix جدید در خدمتتون هستیم و قراره منوی Performance (اجرا) و مفاهیم بسیار مهم و کلیدی این سربرگ رو بررسی کنیم. در باب اهمیت Performance همین بس که ۷۰٪ از نمره نهایی جی تی متریکس یا همون GTmetrix Grade رو تشکیل میده. پس بریم ببینیم چه مواردی روی عملکرد یا Performance صفحه ما تاثیرگذار هستن و چطور میشه به افزایش امتیاز Performance در GTmetrix جدید پرداخت؟ یادمون نره که GTmetrix در نسخه جدید شدیدا روی تجربه کاربری و بهینه سازی UX تاکید داره و معیارهای Performance هم مستثنی از این قاعده نیستن.

با کلیک روی سربرگ Performance چنین صفحه‌ای رو مشاهده می‌کنید. اگه صفحه شما هم مثل عکس بالا امتیاز خوبی از قسمت Performance نگرفته، خیلی نگران نباشید. با اعمال معیارهای سرسخت Lighthouse در GTmetrix جدید، در حال حاضر بیشتر سایت‌های فارسی زبانی که این مدت تو میزفا بررسی کردیم چنین وضعیتی دارن. این معیارها و امتیازهایی که تو عکس می‌بینید، از Lighthouse گوگل گرفته شدن.
هنوز GTmetrix میانگین نمره سایت‌هایی که بررسی می‌کنه رو اعلام نکرده. برای همین خودم دست به کار شدم و از سایت‌هایی که تو این ۱ ماه به میزفا درخواست بهبود سرعت داده بودن رو بررسی کردم، آمار گرفتم. میانگین امتیاز Performance این سایت‌ها ۳۲.۸ بود. امتیازی که از نظر GTmetrix خیلی بد محسوب میشه. هرچند که جامعه آماری من خیلی بزرگ نبود و این عدد خیلی دقیق نیست. اما میگن مشت نمونه خرواره.
پس حتی اگه نمره Performance شما بین ۴۰ تا ۵۰ هست، می‌تونید فعلا کلاهتون رو با افتخار بندازید هوا و خوشحال باشید. هرچند که از طرفی باید به فکر استخدام یه برنامه نویس حرفه‌ای برای بهبود این وضعیت هم باشید.

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

First Contentful Paint چیست و چطور بهینه سازی میشه؟

اگه از بالا و سمت چپ این گزارش شروع کنیم، اولین معیار First Contentful Paint هست. برای اینکه مفهوم First Contentful Paint یا FCP رو بهتر درک کنید، باید اول تعریفی از First Paint بهتون بگم. معیار First Paint که از سال‌ها پیش در GTmetrix و بعضی دیگه از ابزارهای تست سرعت سایت موجود بوده،‌ بیان کننده زمان اولین رندر (Render) در صفحه توسط مرورگره. به‌عبارت ساده‌تر، First Paint زمانی هست که اولین تغییر در صفحه ایجاد میشه و ممکنه کاربر بتونه اون رو ببینه. بله، ممکنه. چرا که شاید First Paint یه صفحه فقط شامل ایجاد رنگ پس‌زمینه اون صفحه باشه و این رنگ برای کاربر قابل تشخیص نباشه. پس توسعه دهندگان وب به این نتیجه رسیدن که First Paint معیار خیلی خوبی برای بررسی سرعت و البته میزان رضایت کاربران نیست و معیار جدیدی به نام First Contentful Paint رو در نظر گرفتن.

تفاوت First Paint و First Contentful Paint (همونطور که از اسمشون هم پیداست) تو نمایش محتوا (Content) هست. در واقع FCP (مخفف First Contentful Paint) زمانیه که اولین محتوا در صفحه نمایش داده میشه. محتوا می‌تونه از جنس متن، عکس، ویدئو و… باشه. پس در این لحظه، کاربر حتما محتوایی رو در صفحه می‌بینه و خیالش راحت میشه که صفحه در حال لود شدنه. پس معیار FCP تمرکز بیشتری بر UX یا تجربه کاربری داره. البته این معیار هم از سال ۲۰۱۷ در ابزار GTmetrix وجود داشته و جدید نیست.
سایت GTmetrix تو این عکس تفاوت First Paint و FCP رو به خوبی نشون داده.

یادمون نره هدف ابزارهای بررسی سرعت سایت مثل GTmetrix اینه که به ما کمک کنن تا تجربه کاربری بهتری رو ایجاد کنیم. بنابراین معیار FCP مستقیما روی نمره Performance در GTmetrix جدید تاثیر داره و ۱۵٪ از امتیاز Performance مربوط به FCP هست. به‌عنوان جمع بندی، زمان FCP از اولین لحظه لود صفحه شروع میشه و تا نمایش اولین محتوا ادامه پیدا می‌کنه.

روش بهینه سازی FCP : درباره اینکه مقدار مناسب FCP باید چقدر باشه، سایت GTmetrix تقسیم بندی زیر رو ارائه کرده:

• کمتر از ۰.۹ ثانیه : خوب
• بین ۰.۹ تا ۱.۲ ثانیه: قابل قبول، اما نیازمند بهینه سازی
• بین ۱.۳ تا ۱.۶ ثانیه: کمی طولانی‌تر از حد استاندارد
• بیشتر از ۱.۶ ثانیه: خیلی طولانی‌تر از حد استاندارد

زمان FCP تا حد زیادی به کیفیت فنی سرور شما و کدنویسی‌های انجام شده در سایتتون بستگی داره. برای کاهش زمان First Contentful Paint صفحه، میشه از روش‌های زیر استفاده کرد:

• کاهش زمان پاسخ اولیه سرور
• استفاده از CDN
• استفاده صحیح از کش (Cache)
• جلوگیری از ریدایرکت های چندگانه و پیاپی
• حذف منابعی که از باعث ایجاد وقفه یا توقف در Render میشن
• کاهش تعداد درخواست ارسال شده به سرور
• کاهش حجم صفحه

جمع بندی: معیار FCP زمانی رو مشخص می‌کنه که اولین محتوای صفحه به کاربر نمایش داده میشه. این معیار ۱۵٪ از امتیاز Performance رو تشکیل میده.

اگر تمایل داری اطلاعات بیشتری بدونی حتما مقاله First Contentful Paint چیست بخون و اونجا جزئیات بیشتری رو گفتیم.

Largest Contentful Paint چیست و چطور بهینه سازی میشه؟

از اینجا، ترتیب معیارهای سربرگ Performance رو کمی تغییر میدیم و حالا سراغ Largest Contentful Paint یا به اختصار LCP می‌ریم که مفهوم نزدیکی با FCP داره. همونطور که با هم بررسی کردیم، معیار FCP بهتر از First Paint بود و بیان می‌کرد اولین محتوا چه زمانی در صفحه نمایش داده میشه. اما FCP یه ایراد داشت، مشخص نبود که اولین محتوا چیه و چقدر برای کاربر مفید و کاربردیه. به‌عبارتی اولین محتوا می‌تونه عکس لوگو یا فقط یه متن یا تیتر معمولی باشه و دردی رو از کاربر دوا نکنه.

بنابراین معیار Largest Contentful Paint مطرح شد تا زمان نمایش بزرگترین محتوای صفحه رو اندازه گیری کنه. LCP تو نسخه قبلی GTmetrix جایگاهی نداشت و حالا به لطف Google Lighthouse وارد GTmetrix جدید شده. ابزارهای اندازه گیری سرعت هر کدوم به شکل خاصی LCP رو محاسبه می‌کنن. اما GTmetrix جدید بزرگترین محتوایی که در نیمه بالایی صفحه (Above the Fold) باشه رو به‌عنوان LCP در نظر می‌گیره. باید سعی کنیم تفاوت زمان FCP و LCP تقریبا ناچیز باشه.

در عکس بالا مشاهده می‌کنیم زمانی که به‌عنوان FCP تعیین میشه، کاربر چیزی رو در صفحه نمی‌بینه. اما در لحظه‌ای که LCP تعیین میشه، محتوای مناسبی در صفحه لود شده.

روش بهینه سازی LCP : مفهوم معیار LCP به‌سادگی قابل درکه. پس برای کاهش زمان Largest Contentful Paint کافیه بزرگترین محتوای موجود در نیمه بالایی صفحه‌مون روشناسایی کنیم و سعی کنیم اون رو بهینه سازی کنیم. بزرگترین محتوای صفحه رو می‌تونیم از طریق سربرگ Structure و تو قسمت Largest Contentful Paint Element ببینیم. تو این قسمت GTmetrix به ما میگه کدوم محتوای صفحه رو به‌عنوان LCP درنظر گرفته. مثلا اگه این محتوا عکس باشه، باید حجمش رو بهینه کنیم. این کار باعث میشه کاربر متوجه بشه صفحه در حال بارگذاریه و احساس رضایت داشته باشه. موارد زیر می‌تونند به عنوان بزرگترین محتوا محسوب بشن:

• تگ‌های <img>
• تگ‌های <img> داخل <svg>
• ‌تگ‌های <video> (عکسِ پوستر ویدئو استفاده میشه)
• block-level های شامل متن (مثل <h1> و <h2> و <div> و <ul> و <table> و…)

معیار LCP به تنهایی ۲۵٪ از امتیاز Performance رو تشکیل میده و بیشترین تاثیر رو در این امتیاز داره. پس کاهش زمان LCP خیلی مهمه.

امتیاز دهی به LCP از منظر GTmetrix به این شکله:

• کمتر از ۱.۲ ثانیه : خوب
• بین ۱.۲ تا ۱.۶ ثانیه: قابل قبول، اما نیازمند بهینه سازی
• بین ۱.۷ تا ۲.۴ ثانیه: کمی طولانی‌تر از حد استاندارد
• بیشتر از ۲.۴ ثانیه: خیلی طولانی‌تر از حد استاندارد

پس میشه گفت فاصله استاندارد بین FCP و LCP باید تقریبا بین ۰.۵ تا ۱.۵ ثانیه باشه. بعضی از روش‌های کاهش زمان Largest Contentful Paint شامل این موارد هست:

• کاهش زمان پاسخ اولیه سرور
• فعال سازی CDN
• استفاده از کش (Cache) مناسب
• حذف منابعی که از باعث ایجاد وقفه یا توقف در Render میشن یا اصطلاحا منابع Render-Blocking
• بهینه سازی عکس های سایت (از نظر حجم و اندازه)
• ترکیب عکس ها با متد CSS Sprites
• استفاده از فرمت‌های نسل جدید برای تصاویر (مانند WebP, JPEG 200, JEPG XR)
• استفاده از فرمت‌های ویدئویی برای محتواهای متحرک (به‌جای استفاده از فرمت GIF)

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

جمع بندی: معیار LCP بهتر از FCP تجربه کاربری رو مد نظر قرار میده و همچنین بیشترین تاثیر رو در امتیاز Performance صفحه داره. این معیار زمان نمایش بزرگترین محتوای صفحه رو مشخص می‌کنه.

اگر تمایل داری اطلاعات بیشتری بدونی حتما مقاله Largest Contentful Paint چیست بخون و اونجا جزئیات بیشتری رو گفتیم.

Speed Index چیست و چطور بهینه سازی میشه؟

معیار بعدی که بهش می‌پردازیم، Speed Index هست که ما برای راحتی بهش SI هم می‌گیم. این معیار در سال ۲۰۱۲ توسط سایت WebPageTest معرفی شد. با این حال در سال ۲۰۲۰ به نسخه آپدیت GTmetrix اضافه شده. معیار Speed Index بیان‌گر اینه که نیمه بالایی صفحه ما یا همون Above the Fold چقدر سریع از نظر بصری کامل میشه.

اگه با مفهوم Above the Fold آشنا نیستید، به قسمتی از صفحه گفته میشه که پس از لود شدن سایت و بدون اسکرول کردن، مقابل چشمان کاربر قرار می‌گیره.

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

روش بهینه سازی SI : نمره Speed Index به اندازه ۱۵٪ از امتیاز Performance رو تشکیل میده. روش نمره‌دهی GTmetrix به SI ، به این صورته:

• کمتر از ۱.۳ ثانیه : خوب
• بین ۱.۳ تا ۱.۷ ثانیه: قابل قبول، اما نیازمند بهینه سازی
• بین ۱.۸ تا ۲.۳ ثانیه: کمی طولانی‌تر از حد استاندارد
• بیشتر از ۲.۳ ثانیه: خیلی طولانی‌تر از حد استاندارد

بیشتر بهینه سازی‌هایی که روی FCP و یا LCP اثر بذاره، باعث بهبود Speed Index هم میشه. همچنین بعضی از روش‌های کاهش زمان Speed Index شامل موارد زیره:

• کاهش زمان اجرای فایل‌های JavaScript
• حذف فایل‌های JavaScript بدون استفاده
• جایگزین کردن کتابخانه‌های سنگین JavaScript با موارد کوچکتر

جمع بندی: معیار Speed Index بیان‌گر اینه که محتوای صفحه چقدر سریع از نظر بصری قابل رویت میشه؛ خصوصا محتوای موجود در Above the Fold . زمان این معیار بستگی به نوع مرورگر ما داره. همچنین این معیار یه نقطه عطف نیست که در یک لحظه خاص اندازه گیری بشه. بلکه توسط فرمول‌های ریاضی محاسبه میشه. پس میشه گفت SI بیشتر یه معیار آزمایشگاهیه، تا معیار میدانی. اما مثل سایر معیارهای قسمت Performance بحث تجربه کاربری رو هدف قرار میده و برای همین، بهینه سازی Speed Index مهمه. همچنین میشه از زمان Speed Index متوجه بشیم که بهینه سازی‌هایی که روی سایر معیارها و خطاهای GTmetrix انجام دادیم، اثر بخش بوده یا نه. چرا که Speed Index یه معیار جامع هست که از سایر معیارها و خطاها تاثیر می‌گیره.

اگر تمایل داری اطلاعات بیشتری بدونی حتما مقاله Speed Index چیست بخون و اونجا جزئیات بیشتری رو گفتیم.

Time to Interactive چیست و چطور بهینه سازی میشه؟

تو جمع بندی بالا، تاکید کردم که معیار Speed Index نمایش محتوا از نظر بصری رو مد نظر قرار میده. شاید براتون سوال پیش بیاد که پس قراره از چه نظر لود شدن محتوا رو بررسی کنه؟ در جواب شما باید عرض کنم، علاوه بر دیده شدن محتوا یا همون بحث بصری، تعامل داشتن با صفحه هم اهمیت زیادی داره. مثلا اینکه کاربر بتونه روی دکمه‌های مختلف کلیک کنه و با صفحه تعامل داشته باشه.
معیار بعدی در گزارش Performance ، معیار Time to Interactive یا به اختصار TTI هست که ما اسمش رو زمان تعامل می‌ذاریم. این معیار مهم و کلیدی، واکنش‌گرایی (Responsiveness) صفحه رو در حین لود شدن بررسی می‌کنه. هرجا که صحبت از واکنش‌گرا بودن صفحه میشه، یاد موبایل و تبلت می‌افتیم. معیار TTI هم برای گوشی‌های موبایل و تبلت‌ها اهمیت بیشتری داره؛ اما به این معنی نیست که برای بررسی وضعیت دسکتاپ بی اثر باشه.

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

به همین دلیل معیار Time to Interactive ایجاد شد. TTI زمانیه که منابع صفحه لود شدن و کاربر می‌تونه به‌طور کامل با صفحه ما تعامل داشته باشه. بنابراین میشه گفت TTI یه معیار کلیدی و کاربر محور محسوب میشه. درصورتی که زمان Time to Interactive صفحه ما بالا باشه، کاربران فقط می‌تونن محتواها رو تماشا کنن و امکان کلیک روی دکمه‌ها، ارسال درخواست و… رو ندارن. کم بودن زمان TTI نشون دهنده اینه که صفحه ما واکنشگرایی لازم رو داره و باعث اطمینان کاربران میشه.

نمونه‌ای از Time To Interactive خوب رو تو عکس زیر می‌بینیم که فاصله‌اش با FCP حدود ۰.۵ ثانیه ست.

تعریف ساده‌تر Time to Interactive اینه که از لحظه لود صفحه شروع میشه و تا زمانی که منابع اصلی صفحه لود بشن و صفحه ما قابلیت این رو داشته باشه که به درخواست‌های کاربر سریعا پاسخ بده، طول می‌کشه. معیار TTI هم مثل FCP ، مقدار ۱۵٪ از امتیاز Performance رو تشکیل میده.

روش بهینه سازی TTI : معیاری که PageSpeed Insight برای TTI مشخص کرده کمتر از ۵ ثانیه ست. با این حال، می‌بینیم که معیارهای GTmetrix برای امتیازدهی به این معیار مهم، متفاوت و به شکل زیره:

• کمتر از ۲.۵ ثانیه : خوب
• بین ۲.۵ تا ۳.۲ ثانیه: قابل قبول، اما نیازمند بهینه سازی
• بین ۳.۳ تا ۴.۵ ثانیه: کمی طولانی‌تر از حد استاندارد
• بیشتر از ۴.۵ ثانیه: خیلی طولانی‌تر از حد استاندارد

میشه گفت بهینه سازی معیار TTI بیش از کیفیت فنی سرور، به نوع کدنویسی سایت ما بستگی داره (البته سرور هم موثره). توجه به موارد زیر باعث کاهش زمان Time to Interactive یا زمان تعامل و در نتیجه بهبود UX صفحات ما میشه.

• کاهش حجم فایل های JavaScript
• پیش بارگذاری (preload) درخواست‌های اصلی و مهم
• کاهش زمان اجرای JavaScript
• حذف فایل‌های JavaScript بدون استفاده
• کاهش تعداد درخواست‌ها

در آینده و در مقالات تخصصی، روش برطرف کردن این خطاها و سایر خطاهای قسمت Structure رو در میزفا بررسی خواهیم کرد.

جمع بندی: معیار Time to Interactive کمک می‌کنه متوجه بشیم چقدر طول می‌کشه تا منابع صفحه ما لود بشن و کاربر بتونه به‌طور کامل با صفحه تعامل برقرار کنه. البته باید بدونیم لود شدن تمام منابع، به‌معنای لود کامل صفحه نیست. بهینه سازی TTI باعث بهبود امتیاز Performance و افزایش سرعت و تجربه کاربری بهتر میشه.

اگر تمایل داری اطلاعات بیشتری بدونی حتما مقاله First Contentful Paint چیست بخون و اونجا جزئیات بیشتری رو گفتیم.

Total Blocking Time چیست و چطور بهینه سازی میشه؟

معیار بعدی که بهش می‌پردازیم، Total Blocking Time یا به اختصار، TBT هست. این معیار هم مربوط به امکان تعامل کاربر با صفحه میشه. کمی قبل‌تر با ۲ معیار FCP و TTI آشنا شدیم. به مجموع زمان‌های بین FCP و TTI که main thread شلوغ بوده و به‌عبارت بهتر بلاک شده، Total Blocking Time یا مجموع زمان بلاک شدن گفته میشه. می‌دونم کمی سخت شد. پس بیایید اول مفهوم main thread رو با هم بررسی کنید.

Main Thread چیست؟

هنگامی که صفحه وبسایت در حال لود شدنه، لازمه منابع زیادی فراخوانی بشن و وظایف و عملیات گوناگونی پشت صفحه رخ میده. کارهایی مثل تجزیه فایل‌های HTML و CSS ، ساختن DOM ، اجرای فایل‌های JavaScript و… به زبون خیلی ساده، مرورگر از main thread برای اجرای این کارها یا درخواست‌های کاربر (مثل کلیک کردن) استفاده می‌کنه.

یه مثال خیلی خوب برای درک بهتر main thread اینه که main thread رو مثل گارسون رستوران در نظر بگیریم. این گارسون وظایف مختلفی مثل گرفتن سفارش‌ها، تحویل سفارش به آشپزخانه، بردن غذا سر میز، تمیز کردن میزها و… داره. حالا اگه یکی از کارهای این گارسون بیش از حد طول بکشه، چه اتفاقی می‌افته؟ درسته، به کارهای مهم دیگه نمی‌رسه. پس باید طوری وظایف گارسون (main thread) رو طراحی کنیم که رسیدگی به یک کار خاص، وقتش رو بیش از حد نگیره.

حالا منظور از بلاک شدن main thread چیه؟ هروقت یکی از وظایفی که main thread برعهده داره بیش از ۵۰ میلی ثانیه طول بکشه، می‌گیم main thread بلاک شده. حالا بین زمان‌های FCP و TTI ، تمام زمان‌هایی که main thread بلاک شده رو محاسبه می‌کنیم و با هم جمع می‌کنیم تا TBT یا Total Blocking Time رو به‌دست بیاریم.

معیار TBT هم یکی از معیارهای کاربر محور GTmetrix جدید محسوب میشه. چرا که تو این مدت زمان (یعنی وقتی main thread بلاک شده باشه) درخواست‌ها و ورودی‌های کاربر انجام نمیشه. مثلا اگه کاربر روی دکمه‌ای کلیک کنه، اتفاقی نمی‌افته. بنابراین کاربر گمان می‌کنه سایت ما مشکلی داره و از صفحه خارج میشه و تجربه کاربری بدی شکل می‌گیره.

عکس بالا از سایت web.dev به خوبی بحث main thread و محاسبه معیار Total Blocking Time رو نشون میده. مستطیل‌هایی که مشاهده می‌کنید، نشون دهنده وظایف main thread هستن و اعدادی بالای هر کدوم از اونها، مدت زمانی که main thread درگیر اون کار هست رو مشخص می‌کنه.
از سمت چپ موارد ۳ و ۴ جزء کارهای طولانی (Long Task) محسوب نیمشن. چرا که به ترتیب ۳۵ و ۳۰ میلی ثانیه وقت main thread عزیز رو گرفتن. اما زمان انجام سایر موارد بیش از ۵۰ میلی ثانیه هست و  Long Task هستن. حالا اگه از هر کدوم از این ۳ مورد، ۵۰ میلی ثانیه (زمان استاندارد) کم کنیم، مجموع زمان باقی مانده اونها میشه TBT . پس تو این مثال، از مجموع ۵۶۰ میلی ثانیه‌ای که main thread درگیره، Total Blocking Time میشه ۳۴۵ میلی ثانیه.

معیار TBT مقدار ۲۵٪ از امتیاز Performance رو تشکیل میده و این نشون دهنده اهمیت بسیار زیاد این معیار کلیدی هست. این معیار شبیه به معیار First Input Delay در Web Vitals هست. معیار TBT در سال ۲۰۲۰ توسط Google Lighthouse به GTmetrix اضافه شد.

روش بهینه سازی TBT : روش نمره‌دهی GTmetrix به Total Blocking Time به این شکله:

• ۱۵۰ میلی ثانیه یا کمتر : خوب
• بین ۱۵۰ تا ۲۲۴ میلی ثانیه: قابل قبول، اما نیازمند بهینه سازی
• بین ۲۲۴ تا ۳۵۰ میلی ثانیه: کمی طولانی‌تر از حد استاندارد
• بیشتر از ۳۵۰ میلی ثانیه: خیلی طولانی‌تر از حد استاندارد

کاهش Total Blocking Time تا حد زیادی به اجرای JavaScript بستگی داره. بنابراین بهینه سازی اجرای فایل‌های JavaScript باعث بهبود TBT خواهد شد. همچنین بهینه سازی‌های مربوط به TTI که بالاتر بهشون اشاره کردیم، در بهبود TBT اثر گذاره. توجه به موارد زیر هم باعث کاهش Total Blocking Time در صفحه ما میشه:

• کاهش زمان اجرای JavaScripts
• بهینه سازی main thread
• حذف فایل‌های JavaScript بدون استفاده
• جایگزین کردن کتابخانه‌های سنگین JavaScript با موارد کوچکتر

جمع بندی: معیار Total Blocking Time یکی از مهم‌ترین معیارهای GTmetrix جدید هست که تاثیر زیادی روی افزایش امتیاز Performance داره. TBT به بررسی زمانی می‌پردازه که main thread به دلیل کارهای طولانی (Long Tasks) بلاک شده بوده و درنتیجه مرورگر نمی‌تونسته به درخواست‌های کاربر پاسخ بده. هر زمان که main thread بیش از ۵۰ میلی ثانیه درگیر یک کار (Task) بشه، بقیه این زمان جزء TBT محسوب میشه. معیار Total Blocking Time شبیه معیار First Input Delay در Web Vitals هست.

اگر تمایل داری اطلاعات بیشتری بدونی حتما مقاله Total Blocking Time چیست بخون و اونجا جزئیات بیشتری رو گفتیم.

Cumulative Layout Shift چیست و چطور بهینه سازی میشه؟

آخرین معیار از معیارهای شش گانه‌ای که روی امتیاز Performance تاثیر می‌ذارن، Cumulative Layout Shift یا CLS هست. البته به صورت تخصصی درباره این معیار در مقاله cumulative ayout shift چیست صحبت کردیم. این معیار هم در سال ۲۰۲۰ و به لطف Lighthouse به GTmetrix جدید اضافه شد. همونطور که تا اینجا با هم بررسی کردیم، معیارهای GTmetrix علاوه بر سرعت، کاملا به تجربه کاربری (UX) هم توجه دارن. اما معیار Cumulative Layout Shift یا مجموع جابجایی چیدمان صفحه، فقط به بحث تجربه کاربری می‌پردازه و ربطی به سرعت صفحه نداره. شاید برای همینه که تاثیر CLS در امتیاز Performance کمتر از سایر موارد و فقط ۵٪ هست. اما این به‌معنای کم اهمیت بودن این معیار نیست. در واقع CLS میزان پایداری و ثبات صفحه رو در حین لود شدن اندازه گیری می‌کنه.

بیایید با هم یه سناریوی عملی رو بررسی کنیم. تا حالا شده بعد از ورود به صفحه و در حالی که صفحه هنوز در حال لود شدنه، ناگهان ببینید که یکی از محتواهای صفحه (مثلا یه عکس، پاراگراف، دکمه و…) به شکل غیرمنتظره‌ای جابجا بشه؟ به این اتفاق، جابجایی چیدمان یا Layout Shift گفته میشه. اگه این تجربه بد رو داشته باشید، کاملا درک می‌کنید که چرا معیار CLS توسط توسعه دهندگان وب به‌وجود اومده و الآن جزء معیارهای GTmetrix هست.

مجموع جابجایی‌های عناصر صفحه، میزان Cumulative Layout Shift رو مشخص می‌کنه که هرچقدر کمتر باشه، صفحه ما پایدارتر و UX بهتر خواهد بود. جابجایی محتواها گاهی اوقات به دلیل تبلیغات موجود در صفحه هست که ناگهان بالای صفحه ظاهر میشه و باعث جابجایی سایر محتواهای صفحه به سمت پایین میشه.
بعضی وقت‌ها این جابجایی فقط باعث میشه ما غافلگیر بشیم و متنی که در حال خوندنش بودیم رو گم کنیم. اما گاهی اوقات هم به محض اینکه می‌خوایم رو دکمه خاصی کلیک کنیم، جابجایی اتفاق می‌افته و باعث میشه روی دکمه یا لینک دیگه‌ای کلیک کنیم و وارد صفحه دیگه‌ای بشیم؛ و این یعنی یه تجربه کاربری افتضاح!!
عکس دیگه‌ای از web.dev که اهمیت معیار Cumulative Layout Shift رو به خوبی نمایش میده.

روش بهینه سازی CLS : مثل موارد قبلی، اول نمره‌دهی GTmetrix به CLS رو بررسی کنیم:

• ۰.۱ یا کمتر : خوب
• بین ۰.۱ تا ۰.۱۵ : قابل قبول، اما نیازمند بهینه سازی
• بین ۰.۱۵ تا ۰.۲۵ : کمی طولانی‌تر از حد استاندارد
• بیشتر از ۰.۲۵: خیلی طولانی‌تر از حد استاندارد

برای کاهش Cumulative Layout Shift پیشنهاد میشه موارد زیر رو رعایت کنید:

• مشخص کردن ابعاد عکس و ویدئوها
• کاهش جابجایی حاصل از تبلیغات، embeds و iframes
• عدم ایجاد محتوای پویا بالای محتوای موجود در صفحه (مگر در پاسخ به درخواست کاربر)

جمع بندی: CLS معیاریه برای بررسی پایداری عناصر، در حین لود شدن صفحه و کاملا روی ایجاد تجربه کاربری تمرکز داره. این معیار در Core Web Vitals هم وجود داره. محتواها و عناصر صفحه نباید به‌صورت غیرمنتظره‌ای جابجا بشن و باعث سردرگمی کاربر بشن.

اگر تمایل داری اطلاعات بیشتری بدونی حتما مقاله Cumulative Layout Shift چیست بخون و اونجا جزئیات بیشتری رو گفتیم.

بررسی Browser Timings در گزارش Performance

خب، بالاخره بررسی ۶ معیار مهم و کلیدی که در افزایش امتیاز Performance در GTmetrix تموم شد. تو بخش پایانی این مقاله، نگاه سریعی می‌اندازیم به قسمت Browser Timings و گزارشش رو خیلی سریع تحلیل می‌کنیم. لازمه بدونید هیچ کدوم از زمان‌های این قسمت مربوط به آپدیت GTmetrix نیستن و تو نسخه قبلی این ابزار در سربرگ Timings همه این موارد قابل مشاهده بودن.

Redirect Duration : اگه قبل از ورود به این صفحه ریدایرکت انجام شده باشه، زمانش در این قسمت مشخص میشه. در غیر این صورت، عدد صفر رو می‌بینیم (مثل عکس بالا).

Connection Duration : بعد از انجام ریدایرکت (در صورت وجود)، مدت زمانی که صرف اتصال به سرور برای ایجاد درخواست میشه، Connection Duration نامیده میشه. تو این مدت، هنوز صفحه خالیه و چیزی نمایش داده نشده.

Backend Duration : بعد از اینکه درخواست به سرور ارسال شد، سرور باید به این درخواست پاسخ بده. به مدت زمان لازم برای ایجاد این پاسخ، Backend Duration گفته میشه.

TTFB : مدت زمان لازم برای دریافت اولین Byte از پاسخی که سرور ارسال کرده بود. TTFB یکی از معیارهای کلیدی در بحث سرعت سایت هست که در مقاله TTFB چیست به‌طور مفصل درباره‌اش صحبت کردیم.

First Paint : درباره First Paint تو همین مقاله و هنگام بررسی First Contentful Paint صحبت کردیم و گفتیم زمانیه که مرورگر اولین Render رو در صفحه انجام میده. در این لحظه ممکنه کاربر بتونه تغییری رو در صفحه مشاهده کنه.

DOM Interactive Time : این لحظه، زمانیه که مرورگر لود کردن (Loading) و تجزیه کردن (Parsing) سند HTML رو تموم کرده باشه.

DOM Content Loaded Time : این لحظه، زمانیه که DOM آماده ست و هیچ فایل CSS یا Stylesheet اجرای JavaScript رو متوقف نمی‌کنه.

Onload Time : زمانی که پردازش صفحه کامل شده و تمام منابع صفحه (مثل عکس و فایل‌های CSS) دانلود شده‌اند، Onload Time نامیده میشه.

Fully Loaded Time : بعد از زمان Onload امکان داره درخواست‌هایی برای دریافت منابع بیشتر ارسال بشه. مثلا ممکنه فایل‌های JavaScript شروع کنن به ارسال درخواست‌های بعدی و این مسئله باعث میشه نیاز به اندازه گیری زمان دیگه‌ای با عنوان Fully Loaded Time داشته باشیم.

جمع بندی درباره سربرگ Performance و اینکه چطور امتیاز Performance رو بهتر کنیم؟

در این مقاله با ۶ معیار زیر آشنا شدیم که هر کدوم به مقداری در بهبود Performance تاثیر داشتن:

• FCP (تاثیر ۱۵ درصدی)
• LCP (تاثیر ۲۵ درصدی)
• Speed Index (تاثیر ۱۵ درصدی)
• TTI (تاثیر ۱۵ درصدی)
• TBT (تاثیر ۲۵ درصدی)
• CLS (تاثیر ۵ درصدی)

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