معیارهای gtmetrix

معیارهای جی تی متریکس نسخه جدید

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

  • معیار اول: شاخص سرعت (Speed Index)
  • معیار دوم: نمایش اولین محتوی (First Contentful Paint)
  • معیار سوم: Largest Contentful Paint
  • معیار چهارم: Time to Interactive
  • معیار پنجم: Total Blocking Time
  • معیار ششم: Cumulative Layout Shift

جی تی متریکس در آبدیت 2020 خود تغییرات زیادی را انجام داده. چنانچه با این تغییرات آشنا نیستید ، ابتدا مقاله “آبدیت جدید جی تی متریکس” را مطالعه کنید و در ادامه به مطالعه همین مقاله بازگردید.

معیار اول: شاخص سرعت (Speed Index)

شاخص سرعت یا همان Speed Index (SI) ، معیاری برای عملکرد مناسب یک سایت است که سرعت لود شدن و سرعت کامل شدن صفحه وب سایت را اندازه گیری میکند. این معیار به سایز پورت مرورگر شما نیز بستگی دارد و بر خلاف معیارهایی نظیرFirst Contentful Paint (FCP) یا Largest Contentful Paint (LCP) در timeline لود صفحه شما نمایش داده نمی شود.

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

شاخص سرعت چگونه اندازه گیری می شود؟

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

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

شاخص سرعت را می توان به عنوان یکی از بهترین شاخص هایی در نظر گرفت که تعداد زیادی از سایر شاخص ها را در دل خود جای داده است و تنها به بیان یک عدد نهایی بیان می کند. در واقع این معیار اطلاع دقیق و عملی خاصی در اختیار شما قرار نمی دهد اما می تواند مشخص کند که بهینه سازی برای وب سایت شما انجام شده است و یا خیر.

چنانچه مایل هستید بیشتر در این رابطه اطلاعات کسب کنید پیشنهاد میکنیم مقاله ” محاسبه شاخص سرعت ” را مطالعه کنید.

محاسبه شاخص سرعت

تأثیر شاخص سرعت بر روی امتیاز عملکرد شما (performance)

شاخص سرعت 15٪ از امتیاز عملکرد را به خود اختصاص می دهد که نشان دهنده اهمیت نسبتاً بالای آن است. به ازای عدد SI پایین تر می توان گفت که محتوی بیشتری در زمان کوتاه تری به کاربران سایت شما نمایش داده شده و باعث ایجاد تجربه کاربری خیلی خوبی برای بازدید کنندگان وب سایت شما خواهد داشت.

حد و حدود شاخص سرعت

GTmetrix شاخص سرعت محاسبه شده را در چند ثانیه نمایش می دهد. زمان کمتر نشان دهنده بارگیری سریعتر صفحه وب است. حدود SI به شرح زیر است:

  • SI=1311 میلی ثانیه و یا کمتر >->-> خیلی خوبه – کاری برای انجام دادن نیست !!!
  • SI بین 1311 الی 1711 میلی ثانیه >->-> خوبه – باید کمی بر روی بهبود وب سایت خودتون کار کنید.
  • SI بین 1711 الی 2300 میلی ثانیه >->-> بیش از حد توصیه شد و بد – باید حتما روی بهبود وب سایت خودتون کار کنید.
  • SI بیشتر از2300 میلی ثانیه >->-> خیلی بد – باید خیلی خیلی روی بهبود وب سایت خودتون کار کنید.

چگونه شاخص سرعت را بهبود ببخشیم؟

توجه داشته باشید که نکات خاص ذکر شده در زیر، بیشترین تأثیر را در SI شما دارند. با این حال ، شاخص سرعت صفحه شما ممکن است تحت تأثیر نکات و بهینه سازی های دیگری باشد که در اینجا ذکر نشده است.

به طور کلی ، اکثر بهینه سازی های عملکردی (performance optimizations) که منجر به سریع تر شدن FCP (First Contentful Paint) و LCP (Largest Contentful Paint) می شوند، احتمالاً منجر به سرعت سریعتر لود صفحه نیز می شوند.

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

  1. Reducing JavaScript execution time
  2. Minimizing main-thread work
  3. Removing unused JavaScript
  4. Reducing the impact of third-party code
  5. Replacing large JavaScript libraries with smaller alternatives

منبع : Lighthouse: Speed Index

 

معیار دوم: نمایش اولین محتوی (First Contentful Paint)

نمایش اولین محتوی یا همان First Contentful Paint (FCP) معیاری عملکردی است و اندازه گیری می کند که چقدر سریع بازدیدکنندگان می توانند محتوی اصلی صفحه را ببینند. محتوایی همچون متن ، تصاویر ، ویدئو و …

این مورد در ورژن قبلی جی تی متریکس نیز وجود داشت و اندازه گیری میشد که می توانید اطلاعات آن را در این صفحه مشاهده کنید.

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

First Contentful Paint چه چیزی را اندازه گیری می کند؟

به گفته گوگل:

بعد از اینکه کاربر به صفحه شما وارد شد، برای ارائه اولین قطعه محتوای DOMبه مرورگر زمانی صرف خواهد شد. تصاویر، آیکون ها وفایل های SVG موجود در صفحه به عنوان محتوای DOM در نظر گرفته می شوند. البته به شرط آنکه داخل iframe گنجانده نشده باشد.

FCP یک معیار مهم و کاربر محور برای اندازه گیری عملکردی است که قابل درک باشد. به این معنی که اولین محتوایی که به کاربر نمایش داده شده و وی می تواند از آن استفاده نماید. برای درک بیشتر این موضوع در مقابل FCP، زمان نمایش اولین تغییر (First Paint Timing) نقطه ای را نشان می دهد که هر چیزی روی صفحه نمایش داده می شود. به عنوان مثال، یک رنگ زمینه، یک حاشیه و غیره که این موارد کمتر مفید بوده و چندان مورد استفاده کاربر قرار نمی گیرد.

سنجش FCP

تأثیر FCP در امتیاز عملکرد شما

این معیار 15٪ از کل امتیاز عملکرد را به خود اختصاص می دهد ، که اهمیت نسبتاً بالای آن را نشان می دهد. بهینه سازی صفحه برای بهبود FCP معمولاً دستاوردهای قابل توجهی در زمان بارگذاری صفحه و درک کاربر از عملکرد سایت شما به همراه دارد.

حد و حدود FCP

حدود FCP به شرح زیر است:

  • FCP در حدود 934 میلی ثانیه و کمتر = حالت خوب و ایده آل است و نیاز به انجام کاری نیست.
  • FCP بین 934 و 1205 میلی ثانیه = خوب است اما کمی نیاز به بهینه سازی دارد
  • FCP بین 1205 تا 1600 میلی ثانیه = بیشتر از مقدار قابل قبول است و نیاز است که اصلاحات اندکی انجام شود.
  • FCP بیشتر از 1600 میلی ثانیه = اصلاح وضعیت خوبی نیست و باید تغییرات بیشتر انجام شود.

چطور FCP را بهبود ببخشیم؟

توجه داشته باشید که موارد ذکر شده در زیر بیشترین کمک را به بهینه سازی FCP شما می کنند. با این حال ، ممکن است FCP صفحه شما تحت تأثیر موارد دیگری باشد که در اینجا ذکر نشده است.

مورد اول : کاهش زمان پاسخ سرور

بدون شک کاهش زمان پاسخ سرور کمک می کند تا یک زمان FCP سریع در صفحه وب سایت شما ارائه شود. برای این منظور می توانید از شبکه CDN استفاده کنید ، مقدار ریدایرکت های موجود را کاهش دهید و یا از راه حل هایی که در مقالات زیر ارائه شده است استفاده نمایید.

مورد دوم : حذف منابع مسدود شده

منابع مسدود شده (render-blocking resources) در واقع فایل هایی هستند که شما تصمیم می گیرید تا بعد از لود اولیه وارد پروسه لود شوند. در واقع می توان گفت شما فایل های غیر ضروری را دیرتر لود میکنید تا صفحه وب سایت شما به سرعت برای کاربر نمایش داده شده و به مرور تکمیل گردد.

به منظور مطالعه بیشتر در اینباره حتما مقاله زیر را مطالعه کنید

مورد سوم : به حداقل رساندن تعداد درخواست (request) و سایز آنها

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

همچنین برای حل این مشکل در وب سایت های وردپرسی می توانید از افزونه های بهینه ساز همچون راکت استفاده کنید.


منبع : Lighthouse: First Contentful Paint

معیار سوم: Largest Contentful Paint

Largest Contentful Paint یا همان LCP معیار عملکردی است که در سال 2020 توسط Lighthouse برای سنجش بهتر تجربه بارگیری قابل درک برای کاربران ارائه شده است.

درواقع ، LCP اندازه گیری می کند که چه مدت طول می کشد تا بزرگترین “عنصر محتوا” (به عنوان مثال ، تصویر قهرمان ، متن عنوان و غیره) در صفحه شما در صفحه نمایش بازدید کننده شما قابل مشاهده باشد.

LCP یکی از معیارهایی است که Google’s Web Vitals را تشکیل می دهد.

Largest Contentful Paint چه چیزی را اندازه گیری می کند؟

با توجه به گفته گوگل:
” LCP یک معیار کاربرپسند برای اندازه گیری بهتر سرعت بارگیری وب سایت است؛ زیرا هنگامی که محتوای اصلی صفحه بارگیری می شود ، نقطه ای را در جدول زمانی بارگیری صفحه نشان می دهد – یک LCP سریع ، حس اعتماد را در کاربران افزایش می دهد.”

LCP میزان مصرف محتوای قابل توجه در صفحه وب شما توسط بازدید کنندگان را اندازه گیری می کند. فرض کنید که بزرگترین عنصر محتوای صفحه خود را بارگذاری کنید، LCP اندازه گیری می کند که بزرگترین عنصر محتوای صفحه با چه سرعتی بارگیری می شود. هر “عنصر محتوا” از عنصر HTML است ، مانند:
• یک عنصر تصویر
• یک عنصر ویدیویی
• عنصری که تصویر پس زمینه از طریق تابع URL بارگیری می شود (به جای اعلام آن در CSS)
• عناصر سطح بلوک مانند < h1> ، <h2> ، <div> ، <ul> ، <table> و غیره

largest contentful paint example

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

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

تأثیر Largest Contentful Paint’s در امتیاز عملکرد

جی تی متریکس بیان می کند که LCP ، مقدار 25٪ از امتیاز بهینه سازی Web Vital را به خود اختصاص داده و یکی از مهمترین معیارهای بهینه سازی است. در حالی که معیارهای دیگر مانند First Contentful Paint (FCP) یا (Time-to-First-Byte (TTFB همچنان وابسته به سرعت متن صفحه هستند ، LCP نمایانگر انتظار بازدید کنندگان شما در دنیای واقعی به هنگام بررسی وب سایت شماست.

fast vs slow lcp

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

حدود Largest Contentful Paint

  • خوب ، کاری برای انجام دادن نیست = LCP برابر 1200 میلی ثانیه یا کمتر
  • بد نیست ، اما میشه بهترش کرد = LCP بین 1200 تا 1666 میلی ثانیه
  • جالب نیست و بیشتر از حد توصیه شده = LCP بین 1666 تا 2400 میلی ثانیه
  • اصلا وضعیت خوبی نیست و باید درست بشه = LCP بالاتر از 2400 میلی ثانیه

Largest Contentful Paint Element در تب Structure

آنچه را GTmetrix به عنوان بزرگترین عنصر محتوای صفحه شناسایی کرده است ، می توانید در تب Structure مشاهده کنید. در فهرست بررسی عبارت “Largest Contentful Paint Element” ذکر شده است.

چگونه Largest Contentful Paint را بهبود ببخشیم؟

توجه داشته باشید که بررسی های خاصی که در زیر ذکر شده بیشترین کمک را به LCP شما می کنند. با این حال ، ممکن است زمان بندی LCP صفحه شما تحت تأثیر بهینه سازی های دیگری باشد که در اینجا ذکر نشده است. در اینجا برای نمونه چند نمونه مثال می زنیم :
1. کاهش زمان پاسخ سرور: کاهش زمان پاسخ سرور به بارگیری سریعتر منابع و تحویل سریع LCP در صفحه کمک می کند. می توانید با کاهش زمان پاسخ اولیه سرور و یا استفاده از شبکه تحویل محتوا (CDN) می توانید این بهینه سازی را انجام دهید.

2. از بین بردن رفتار render-blocking: از بین بردن رفتار render-blocking در صفحه شما بارگذاری منابع را در سریعترین زمان ممکن تضمین می کند.

3. بهینه سازی عکس ها و ویدئو ها: تصاویر و فیلم ها را در صفحه خود بهینه کنید تا زمان بارگیری کاهش یابد. برخی از کارهایی که می توانید انجام دهید شامل موارد زیر است:

  • اندازه مناسب تصاویر
  • فرمت مناسب تصاویر
  • ترکیب تصاویر کوچک با استفاده از Sprites CSS
  • استفاده از قالب های ویدئویی برای محتوای متحرک

توجه: برخی از بررسی ها با هم دارای اشتراکاتی هستند که بهبود یک عنصر از اجزای سایت باعث بهبود سایر گزینه ها نیز خواهد شد.


منبع :  Largest Contentful Paint

معیار چهارم: Time to Interactive

Time to Interactive یا همان TTI اندازه گیری می کند که چه مدت طول می کشد تا یک صفحه کاملاً قابلیت تعامل با کاربران را پیدا کند. یعنی مدت زمان بین اولین Contentful Paint (FCP) و آخرین long-task در main-thread را اندازه گیری می کند و نقطه ای را نشان می دهد که مرورگر قادر به پاسخگویی مطمئن به کاربر است. به زبان ساده ، TTI سریع به شما اطمینان می دهد که صفحه قابل استفاده برای کاربران است.

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

کاهش TTI برای عملکرد وب شما بسیار مهم است ، به ویژه در دستگاه های تلفن همراه که این موضوع از اهمیت بالاتری برخوردار است.

اثر Time to Interactive بر روی امتیاز Performance

معیار TTI مقدار 15٪ از کل امتیاز عملکرد (Performance Score) را به خود اختصاص می دهد ، که اهمیت نسبتاً بالای آن را نشان می دهد. توجه داشته باشید که TTI معیاری است که با زمان مسدود کردن کل (TBT) در کنار هم هستند، و این دو معیار اطلاعات بیشتری در مورد پاسخگویی صفحه شما به کاربر ارائه می دهند.

حدود قابل قبول برای Time to Interactive

  • TTI برابر 2468 میلی ثانیه یا کمتر = خوب است و نیاز به بهبودی ندارد
  • TTI را بین 2468 تا 3280 میلی ثانیه = خوب ، اما نیاز بهبودی دارد
  • TTI بین 3280 تا 4500 میلی ثانیه = بیشتر از حد توصیه شده و کمی بهینه سازی لازم دارد
  • TTI بالاتر از 4500 میلی ثانیه = خیلی بیشتر از حد توصیه شده و حتما باید فکری به حال سایت خودتون کنید

چگونه زمان تعامل را بهبود ببخشیم؟

توجه داشته باشید که بررسی های خاصی که در زیر ذکر شده اند بیشترین کمک را به TTI شما می کنند. با این حال ، TTI صفحه شما ممکن است تحت تأثیر بهینه سازی های دیگری باشد که در اینجا ذکر نشده است.

1. بهینه سازی اجرای جاوا اسکریپت: برای کاهش main-thread blocking time، اجرای JavaScript خود را بهینه کنید و اطمینان حاصل کنید که صفحه شما سریع به ورودی های کاربر پاسخ می دهد.

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

2. ارائه درخواست های کوچک: اطمینان حاصل کنید که تعداد درخواست ها در کمترین حالت خودش باشد. به همین ترتیب ، از chaining critical requests برای تسریع در بارگذاری منابع اصلی ، خودداری کنید.

3. استفاده از Preconnect to required origins ، این مورد یک مورد تخصصی است.


منبع: Time to Interactive

معیار پنجم: Total Blocking Time

Total Blocking Time یا همان (TBT) ، یکی از معیارهای عملکردی lighthouse است که در سال 2020 معرفی شد. این معیار میزان پاسخگویی صفحه شما را نسبت به ورودی کاربر مشخص می کند. به عبارت ساده ترTBT کل زمان مسدود بودن صفحه وب شما را اندازه گیری می کند. منظور از مسدود بودن در این عبارت زمانی است که کاربر نمی تواند با صفحه شما تعامل داشته باشد.

این معیار جایگزینی برای معیار field-only First Input Delay (FID) است که در PageSpeed Insights مشاهده می شود.

Total Blocking Time چه چیزی را اندازه گیری می کند؟

بر اساس بیانات گوگل :

TBT زمان کل بین First Contentful Paint (FCP) و Time to Interactive را اندازه گیری می کند. یعنی دقیقا زمانی که main-thread به حالت مسدود قرار گرفته و از پاسخگویی نسبت به کاربران جلوگیری می کند.

main-thread، جایی است که مرورگر اکثر موارد مرتبط با بارگذاری صفحه را مانند رندر یا چاپ محتوا (rendering/painting) و مدیریت تعاملات کاربران ، پردازش می کند. اساساً ، مرورگر از main-thread ، برای تجزیه HTML ، ساخت DOM ، اجرای CSS و JavaScript ، پردازش رویدادهای کاربر و انجام سایر کارهای مهم استفاده می کند.

وقتی انجام هر یک از این کارها بیش از 50 میلی ثانیه زمان ببرد، main-thread “مسدود” در نظر گرفته می شود زیرا مرورگر نمی تواند یک کار در حال انجام را قطع کند. و اگر main-thread مسدود یا بلاک شده باشد ، صفحه شما نمی تواند به اطلاعات ورودی کاربر مانند ضربه زدن روی صفحه ، فشار صفحه کلید یا کلیک ماوس پاسخی دهد.

زمان بیش از 50 میلی ثانیه ، زمانindividual blocking آن درخواست در نظر گرفته می شود و مجموع تمام این زمانهای مسدود شده ، کل زمان مسدود کردن صفحه شما یا Total Blocking Time است.

main thread timeline tbt

به عنوان مثال ، در تصویر بالا ، 5 وظیفه یا مورد در main-thread وجود دارد که 3 مورد از آنها Long Tasks هستند ، زیرا مدت زمان لازم برای انجام هریک از آن ها بیش از 50 میلی ثانیه است. زمان مسدودی هر یک از این long taskها به شرح زیر است:

  • Task A – 220 ms
  • Task B – 70 ms
  • Task E – 145 ms

TBT در این سناریو برابر با 435 میلی ثانیه است. اما بهرحال اگر main-thread فقط یک مورد داشت که 500 میلی به طول می انجامید، TBT نیز برابر 500 میلی ثانیه میشد.

مقایسه Total Blocking Time و Time to Interactive

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

TTI مدت زمانی را بیان می کند که طول می کشد تا صفحه شما کاملاً تعاملی شود. TBT به طور خاص به شما می گوید که کدام یک از موارد جاوا اسکریپت طولانی ترین زمان را برای اجرا شدن صرف کرده است.

درصورتی که main-thread ، حداقل به مدت 5 ثانیه آزاد باشد، TTI صفحه را کاملا تعاملی فرض می کند.

سناریوهای زیر را در نظر بگیرید:

tbt example

الف) سه کار 60 میلی ثانیه ای در یک دوره 5 ثانیه ای انجام شده

ب) یک Long Task به مدت 5 ثانیه

هر دو سناریوی فوق TTI را به یک اندازه افزایش می دهند. سناریوی A در طول بارگذاری صفحه تا حد زیادی تعاملی است ، چرا که هیچ long task یا کار طولانی ای در آن اتفاق نیفتاده و وقت مرورگر را نمی گیرد.

اما این دو سناریو از نظر کاربر بسیار متفاوت هستند زیرا TBT در سناریوی اول فقط 30 میلی ثانیه و در سناریوی دوم 4950 میلی ثانیه است.

سناریوی A در طول بارگذاری صفحه تا حد زیادی تعاملی است ، چرا که هیچ long task یا کار طولانی ای در آن اتفاق نیفتاده و وقت مرورگر را نمی گیرد.در حالی که در سناریو B هنگامی که مرورگر مشغول انجام Long Task است ، به هیچ وجه به کاربر اجازه تعامل با صفحه را نمی دهد. همین ویژگی باعث میشود TBT ، هم بعنوان یک معیار مستقل و هم با بکارگیری آن همراه TTI، مفید باشد.

مقایسه Total Blocking Time و First Input Delay

همانطور که قبلاً اشاره کردیم، TBT جایگزینی برای First Input Delay (FID) است که یکی از معیارهای Vital Web است. این داده های واقعی کاربر از طریق گزارش های تجربه کاربری Chrome (CrUX) – پایگاه داده رفتاری مرورگر Chrome که از کاربران سرتاسر دنیا جمع آوری شده است، به دست می آید. اما GTmetrix از این معیار در سنجش ها استفاده نمی کند. GTmetrix، به جای First Input Delay ، Total Blocking Time را گزارش می دهد. بنابراین جی تی متریکس، TBT را به جای FID گزارش می کند چراکه همان بهینه سازی ها را به شما توصیه می کند.

tbt web vitals

تاثیر Total Blocking Time بر نمره عملکرد یا performance

TBT به عنوان یک معیار Web Vital ، 25٪ از امتیاز performance را به خود اختصاص داده و همین مسئله این معیار را به یک معیار مهم برای بهینه سازی تبدیل کرده است. به عبارت دیگر، بهینه سازیTBT می تواند موثرترین پیشرفت را در پاسخگویی وبسایت شما ایجاد کند.

حدود Total Blocking

  • TBT=150 میلی ثانیه یا کمتر ، عالی ، این حالت ایده آل است و TBT شما نیازی به بهینه سازی ندارد
  • TBT بین 150 تا 224 میلی ثانیه = این حالت خوب است اما بهینه سازیTBT را انجام دهید
  • TBT بین 224 تا 350 میلی ثانیه = کمی بیشتر از حد توصیه شده که نیاز به بهینه سازی دارد
  • TBT بالاتر از 350 میلی ثانیه = خیلی بیشتر از حد توصیه شده است و نیاز حتمی به بهینه سازی دارد

چگونه Total Blocking Time را بهبود ببخشیم؟

Total Blocking Time با عملکرد جاوا اسکریپت ارتباط زیادی دارد و هرگونه پیشرفت در اجرای جاوا اسکریپت ( بهینه سازی هایی که باعث بهبود TTI می شوند) TBT شما را کاهش می دهد.
برخی از این بهینه سازی ها عبارتند از:


منبع مقاله: Total Blocking Time

معیار ششم: Cumulative Layout Shift

Cumulative Layout Shift (CLS) معیار عملکردی است که در سال 2020 توسط Lighthouse معرفی شده است تا میزان ثبات بصری یا ظاهری صفحه را اندازه گیری کند. به عبارت ساده تر CLS ، تغییر مکان غیرمنتظره عناصر صفحه را هنگام بارگذاری اندازه گیری می کند. در واقع نمره CLS، مجموع همه امتیاز های layout shift در صفحه است.

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

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

کاهش صفحه CLS امری بسیار مهم است زیرا صفحاتی که عناصر آن درحین بارگیری جابجا می شوند میتوانند منجر به تجربه منفی کاربری شوند (به ویژه در دستگاه های تلفن همراه).

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

تفاوت Layout Shift غیر منتظره و مورد انتظار

توجه به تفاوت بین شیفت های مورد انتظار و غیر منتظره امری مهم است که در ادامه بصورت کامل بیان شده است:

یک Layout Shift، زمانی موردانتظار محسوب می شود که در پاسخ به ورودی کاربر اتفاق افتاده باشد. به عنوان مثال وقتی با کلیک بر روی نماد جستجو ، یک قسمت برای گرفتن واژه جستجو از کاربر، باز می شود، یک Layout Shift مورد انتظار اتفاق افتاده است.

از طرف دیگر ، Layout Shift یا تغییر طرح غیر منتظره معمولاً توسط تصاویری که طول و عرض آن ها مشخص نشده یا سایر محتوای پویا ایجاد می شود.

به عنوان مثال ، هنگامی که یک تبلیغ به طور ناگهانی ظاهر می شود و یک تصویر یا عنصری دیگر را به پایین صفحه هل می دهد، Layout Shift غیرمنتظره اتفاق افتاده است.

GTmetrix با استثنا درنظر گرفتن Layout Shift هایی که در عرض 0.5 ثانیه از ورود کاربر رخ می دهد ، بین Layout Shift های موردانتظار و غیر منتظره تفاوت قائل می شود.

تأثیر Cumulative Layout Shift در امتیاز عملکردی شما

حتی اگر تأثیر مستقیم CLS در امتیاز عملکرد نسبتاً کم باشد (5٪)، نباید فراموش کنیم که این مورد یک کمک بزرگ به حاصل شدن یک تجربه کاربری مطلوب است تا بتوانید تجربه ای روان و بدون تأخیر را به بازدیدکنندگان خود ارائه دهید. در حالی که برخی دیگر از معیارهای نمره عملکرد صفحه مستقیماً با سرعت بارگیری صفحه ارتباط دارند ، CLS بر بررسی کیفیت تجربه کاربری صفحه شما متمرکز است.

حد آستانه Cumulative Layout Shift

توجه کنید که CLS یک امتیاز است و نه مقداری بر پایه زمان. و مقدار آن عددی بین 0 تا 1 است.

  • CLS برابر 0.1 یا کمتر = خوب ، نیازی به بهینه سازی وجود ندارد
  • CLS بین 0.1 تا 0.15 = خوب ، اما میتوانید آن را بهبود بخشید
  • CLS بین 0.15 تا 0.25 = بیشتر از حد توصیه شده اما بهتر است بهینه سازی انجام شود
  • CLS برابر 0.25 یا بالاتر = خیلی بیشتر از حد توصیه شده و نیاز به بهینه سازی دارد

چگونه Cumulative Layout Shift را بهبود ببخشیم؟

توجه داشته باشید که اقدامات خاص ذکر شده در زیر، بیشترین تأثیر را در میزان CLS شما دارند. اما ممکن است نمره CLS صفحه شما تحت تأثیر بهینه سازی های دیگری باشد که در اینجا ذکر نشده است.
1) تعیین ابعاد تصویر: همیشه ، عرض و ارتفاع را برای عناصر تصویر و فیلم وبسایت خود مشخص کنید تا از فاصله ای مناسب برای تصاویر و فیلم ها استفاده شود. همچنین میتوانید این کار را با مشخص کردن نسبت ابعاد باکس ها در CSS انجام دهید.

2) برای کاهش تغییرات چیدمان ناشی از تبلیغات ، embed و iframesها ، اقدامات زیر را را انجام دهید:

  • قبل از بارگذاری کتابخانه تبلیغات ، اندازه شیار تبلیغات (ترجیحاً بزرگترین) را رزرو کنید.
  • تبلیغات را به پایین صفحه یا خارج از ویوپورت انتقال دهید.
  • وقتی هیچ تبلیغی برای نمایش در دسترس نیست ، از نگه دارنده فضا یا placeholder استفاده کنید.

3) از درج مطالب جدید با محتوی پویا بالاتر از مطالب موجود خودداری کنید


منبع مقاله: Cumulative Layout Shift

تصویر شاخص حل مشکلات جی تی متریکس

بررسی اشکالات جی تی متریکس

حل مشکلات GTmetrix با بررسی مورد به مورد در این مقاله بیان شده است.

  • حل مشکل Reduce initial server response time
  • حل مشکل Avoid an excessive DOM size
  • حل مشکل Enable Keep-Alive
  • حل مشکل critical request chain
  • حل مشکل Avoid long main-thread tasks
  • حل مشکل Use a Content Delivery Network (CDN)
  • حل مشکل Avoid large layout shifts
  • حل مشکل Minimize main-thread work

حل مشکل کاهش زمان پاسخ اولیه سایت

مشکل کاهش زمان پاسخ اولیه سایت – Reduce initial server response time

زمان اول بایت ارسالی یا همانTime to First Byte (TTFB) ، در واقع به عنوان زمان پاسخ سرور شناخته می شود. در واقع این زمان، زمانی است که مرورگر درخواست خود را برای سرور ارسال کرده و اولین بایت ارسالی از طرف سرور را دریافت می کند.

کاهش TTFB برای تجربه کاربری صفحه بازدید کنندگان شما بسیار مهم است چرا که بر روی دریافت هر درخواست (request) ارسالی از طرف وب سایت شما اثر گذاشته و مستقیما بر مدت زمان بارگیری صفحه اثرگذار خواهد بود.

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

به عنوان یک بهینه سازی پر اهمیت ، کاهش TTFB می تواند عملکرد وب سایت شما را به طور قابل توجهی بهبود بخشد.

تاثیر زمان پاسخگویی (server response time) سرور بر عملکرد صفحه (page performance)

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

نمودار پاسخ سمت سرور برای سرعت سایت

TTFB به عوامل مختلفی بستگی دارد ، اما عمدتا عملکرد نشان داده شده در مرحله 2 مد نظر است.

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

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

توجه داشته باشید که تعاریف زیادی برای TTFB وجود دارد. جی تی متریکس (GTmetrix) ، TTFB را مجموع مدت زمان ارسال درخواست ، مدت اتصال و مدت زمان بازگشت می داند.

محاسبه زمان gtmetrix-ttfb

در شکل فوق زمان محاسبه شده برای TTFB نمایش داده شده است.

مقدار قابل قبول GTmetrix برای این پارامتر چقدر است؟

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

چگونه زمان پاسخ سرور را کاهش دهیم؟

حال زمان پاسخگویی به این سوال مهم رسیده است. برای این کار 3 راه حال وجود دارد.

راه حل اول: بهینه سازی کدهای داخلی وب سایت به ویژه درخواست های پایگاه داده (Database)

البته این مورد نیازمند دانش تخصصی زیادی بوده و ما اکیداً توصیه می کنیم که از متخصصین درخواست کمک کنید چراکه در صورت انجام اشتباه ممکن است ضربه سختی به وب سایت خود وارد کنید. برای این منظور می توانید کدهای داخلی دیتابیس را تا حد امکان ساده سازی کرده و آنها را دسته بندی کنید تا در بلوک های خاصی اجرا شوند. همچنین می توانید کد های غیر ضروری را پاک کنید.

در صورتی که از سیستم مدیریت وردپرسی برای مدیریت وب سایت خود استفاده می کنید می توانید با استفاده از افزونه های بهینه ساز این کار را انجام دهید البته تغییرات خاص و پیچیده ای را نمی توانید اعمال کنید که ما هم پیشنهاد میکنیم چنین کاری را انجام ندهید.

راه حل دوم : اجرای حافظه پنهان سرور یا همان سیستم کش (server-side caching)

حافظه پنهان (حافظه کش) روشی است که به جای پردازش در سرور و تولید صفحه در صورت درخواست کاربر، از نسخه پیش ساخته صفحه ، در هنگام درخواست استفاده می شود. برای حل این موضوع می توانید از پلاگین های وردپرسی زیادی استفاده کنید. (پلاگین های بهینه سازی کش) پیشنهاد ما برای انجام این کار استفاده از یکی از 3 پلاگین زیر است.

البته توجه داشته باشید که میزبان و هاستینگ شما ممکن است از قبل در حافظه کش سمت سرور این مورد را در نظر گرفته باشد. بنابراین برای روشن شدن موضوع حتماً با آنها تماس بگیرید.

راه حل سوم: به روزرسانی سخت افزار سمت سرورCPU یا RAM قوی تر

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

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


منبع: سایت جی تی متریکس

حل مشکل Avoid an excessive DOM size

قبل از هر چیزی لازم است تا تعریفی در رابطه با المان های DOM ارائه کنیم.

المان Dom چیست؟

DOM یا همان Document Object Model در واقع یک مدل و ساختار درختی از تمام عناصر HTML درون یک صفحه وب است. که در آن عناصر HTML (همان تگ‌های HTML) به عنوان اشیاء در نظر گرفته می‌شوند. DOM در واقع یک API یا همان رابط برنامه نویسی برای جاوا اسکریپت است که به برنامه نویس اجازه کارهای زیر را می دهد:

  • حذف ، اضافه یا تغییر تگ‌های (عناصر) HTML
  • حذف ، اضافه یا تغییر خصیصه‌های attribute) HTML)
  • حذف ، اضافه یا تغییر استایل‌های CSS
  • واکنش به رویداد‌های Event) HTML)
  • حذف ، اضافه یا تغییر رویداد‌های HTML

صفحه html دارای کد هایی است که هر کدام از این کد ها در یک بلوک قرار گرفته و این درخت که معروف به درخت DOM است را می سازد.

المان Dom

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

یک درخت DOM بزرگ چگونه بر عملکرد صفحه تأثیر می گذارد؟

هر زمان که یک صفحه بارگیری می شود ، مرورگر قبل از اینکه شروع به ساخت درخت Document Object Model (DOM) کند، HTML آن صفحه را دانلود و تجزیه می کند. این درخت DOM تمام عناصر HTML را، که شامل ساختار و محتوای صفحه وب میشود، دربرمیگرد.

حال یک درخت بزرگ DOM می تواند به روش های زیر بر عملکرد صفحه شما تأثیر منفی بگذارد:

مورد اول: افزایش غیرضروری تعداد بایت های منتقل شده

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

مورد دوم: کاهش بیش اندازه سرعت رندر صفحه

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

مورد سوم: تخریب قدرت Ram سیستم کاربران

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

GTmetrix چگونه این گزارش را آماده کرده است؟

GTmetrix مجموع عناصر DOM را برای یک صفحه ، حداکثر عمق DOM صفحه و حداکثر عناصر فرزند (Child elements) را گزارش می دهد. بسته به تعداد عناصر DOM، نمره گزارش GTMetrix صفحه شما تغییر می کند.

اگر اندازه DOM صفحه شما بیش از 818 عدد باشد ، این عامل بعنوان یک مشکل به شما گزارش داده می شود.

چگونه از اندازه بیش از حد DOM جلوگیری کنیم؟

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

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

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

به یاد داشته باشید که هرچه صفحه شما پیچیده تر باشد ، احتمالاً اندازه DOM صفحه شما بزرگتر است.

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


منبع: GTmetrix – Lighthouse: Avoid an excessive DOM size

حل مشکل Enable Keep-Alive

تذکر: این ملاک توسط خود جی تی متریکس ارائه شده است.

برای درخواست های HTTP/1.1 ، فعال کردن Keep-Alive تاخیر را کاهش داده و عملکرد صفحه شما را بهبود می بخشد.

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

فعال کردن Keep-Alive این امکان را فراهم می کند تا از یک اتصال TCP برای انتقال چندین فایل استفاده شده و در نتیجه بارگیری صفحه سریعتر انجام می شود.

فعال کردن Keep-Alive چه تاثیری بر عملکرد صفحه دارد؟

فعال کردن Keep-Alive تضمین می کند که از یک اتصال TCP برای انتقال چند فایل، از سرور به مرورگر استفاده شود و از آنجایی که با این اتصال دیگر مرورگر برای بازیابی تمام منابع صفحه شما نیازی به برقراری اتصال دیگری ندارد، به صفحه شما کمک می کند تا سریعتر بارگیری شود.

به طور کلی ، مرورگر یک اتصال TCP را با یک سرور برقرار می کند تا بتواند منابع صفحه شما را بازیابی کرده و محتوای صفحه را نمایش دهد.

با درخواست های HTTP/1.1 ، مرورگر می تواند اتصالات TCP را پس از دریافت فایل خاصی از سرور، ببندد. اگر چندین اتصال برای بازیابی فایل های صفحه شما برقرار شود، تأخیر غیرضروری شبکه را افزایش داده ، در نتیجه بارگیری صفحه کند انجام می شود.

فعال کردن Keep-Alive به صراحت به مرورگر اعلام می کند که با دریافت فایل از سرور ، نباید اتصال را قطع کند. توجه داشته باشید که این اقدام فقط برای درخواست های HTTP/1.1 قابل اجرا است. وب سایت هایی که بر پایه درخواست های HTTP/1.1 عمل می کنند، می توانند چندین اتصال TCP با یک سرور برقرار کنند تا منابع صفحه را دریافت کنند. در حالی که بسیاری از وب سایت ها به HTTP/2 منتقل شده اند و یا برخی از سرورهای وب به طور خودکار پرونده ها را از طریق یک اتصال TCP منتقل می کنند. البته ممکن است این موارد برای برخی از کاربران صدق نکند.

GTmetrix چگونه این گزارش را آماده می کند؟

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

این در حالی است که Lighthouse بررسی می کند آیا صفحه وب شما از HTTP/2 استفاده می کند یا خیر و فعال بودن Keep-Alive را در سرور وب شما را بررسی نمی کند.

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

چگونه Keep-Alive را فعال کنیم؟

بسته به وب سرور مورد استفاده خود ، دستورالعمل های زیر را دنبال کنید:

1) سرورهای Apache :Apache به صورت پیش فرض اتصالات Keep-Alive را فعال می کند. با این حال ، می توانید با افزودن خط زیر به فایل ” httpd.conf ” آن را فعال کنید. اما توجه داشته باشید اگر وبسایت شما روی یک هاست اشتراکی قرار دارد، احتمالاً به httpd.conf دسترسی نخواهید داشت و بنابراین مجبورید تنظیمات پیشفرض ارائه دهنده فضای میزبانی خود کنار بیایید.

 KeepAlive On

هشدار مهم درباره htaccess: ممکن است منابع دیگر به شما پیشنهاد کنند تا با افزودن کد زیر به فایل htaccess ، اقدام به فعال کردن keep alive کنید. اما بر خلاف آنچه این وب سایت ها پیشنهاد می دهند ، افزودن کد فوق به فایل htaccess در واقع اتصالات Keep-Alive را فعال نخواهد کرد بلکه باعث می شود اطلاعات نادرستی درباره قابلیت های سرور به مرورگرها ارسال شوند.

 Header set Connection keep-alive

2) سرورهای Microsoft IIS : کد زیر را کپی و در خط فرمان جایگذاری کنید:

 appcmd set config /section:httpProtocol /allowKeepAlive:true

3) سرورهای NGINX :حالت Keep-Alive به صورت پیش فرض در سرورهای NGINX فعال است.


منبع : Lighthouse: Enable Keep-Alive

حل مشکل critical request chain

critical request chain، درواقع یک سری درخواست های دنباله دار وابسته به یکدیگر هستند که برای ارائه صفحه ضروری هستند. این کار توسط یک روند مشخص ارائه می شود که ترتیب درخواست های تجزیه و اجراکردن را تعیین می کند.

درخواست های ضروری زنجیره ای طولانی (به خصوص آنهایی که منابع زیادی دارند) می توانند زمان بارگذاری صفحه شما را که به render-blocking شناخته می شوند، افزایش دهند. با کاهش تعداد critical request chains می توانید سرعت لود صفحه خود را بالا ببرید.

render-blocking در واقع این موضوع را بیان می کند که ابتدا باید فایل خاصی لود شود تا فایل بعدی که در صف قرار دارد وارد پروسه بارگزاری شود.

critical request chain چه تاثیری روی سرعت لود صفحه دارند؟

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

در صورتیکه مشخص نشوند، کدهای HTML معمولا دارای الویت اول هستند. بعد از آن CSS ها ، عکس ها و JavaScript ها به ترتیب الویت بندی می شوند. البته توجه داشته باشید این در صورتی است که خود شما اولویت بندی خاصی را تعریف نکرده باشید. چراکه در اینصورت اولویت با تنظیمات و توالی هایی است که شما انجام داده اید.

تشکیل critical request chain طولانی ، باعث به وجود آمدن تاخیر در لود صفحات سایت شده و زمان بارگذاری صفحه شما را افزایش می دهند.

حداکثر تاخیر critical path ، مجموع کل زمان صرف شده برای بارگیری همه منابع در طولانی ترین critical request chain است.

با به حداقل رساندن تعداد منابع بوسیله به تعویق انداختن لودینگ ، حذف کامل آنها ، یا کوتاه کردن طول critical path می توان باعث افزایش عملکرد وب سایت و بهبود تجربه کاربری بازدید کنندگان شد.

GTmetrix بر چه اساسی این گزارش را آماده می کند؟

یک critical request به عنوان یکی از درخواست های زیر تعریف می شود:

  • Render-blocking
  • Not preloaded (بارگیری نشده)
  • Declared with a medium, high, or very high priority (اعلام با الویت متوسط ، بالا ، یا خیلی زیاد)

بررسی این مبحث در صورتی آغاز می شود که حداقل یک critical request chain وجود داشته باشد.

برای شروع کردن بررسی ، GTmetrix طولانی ترین critical request chain را با جزئیات نمایش می دهد و به شما اجازه می دهد هر درخواست را مشاهده کنید.

همچنین حداکثر critical path latency نمایش داده می شود.

چگونه این بررسی را انجام دهیم؟

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

  1. بارگیری درخواست های کلیدی: برای سرعت بخشیدن به اجرای منابع مهم ، درخواست های کلیدی (مانند: اسکریپت ها ، صفحات وب ، صفحه های سبک و غیره) را از قبل بارگیری کنید ، این کار باعث صرفه جویی وقت در زمان بارگیری صفحه می شود.
  1. کاهش تعداد critical resources: برای کاهش تعداد critical resources مورد نیاز (یعنی منابع مورد نیاز برای نمایش محتوای با ارزش) بوسیله به تأخیر انداختن بارگیری non-critical resources یا در صورت امکان از حذف کامل آن ها استفاده کنید. این کار تضمین میکند که مرورگر زمان کمتری را برای بارگیری منابع غیرضروری صرف کند. به عنوان مثال: تصاویر کم ارزش ، کدهای جاوا اسکریپت ، استایل های CSS برای محتوای غیر مهم.
  1. استفاده از ویژگی font-display: از ویژگی font-display برای بهینه سازی بارگیری فونت وب سایت و تجربه صفحه بازدید کنندگان خود استفاده کنید.

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


منبع: GTmetrix-Lighthouse: Avoid chaining critical requests

حل مشکل Avoid long main-thread tasks

رویدادهایی مانند تجزیه HTML/CSS ، تجزیه/اجرای جاوا اسکریپت و سایر موارد “task” هایی هستند که بر روی رشته اصلی اجرا می شوند (به طور پیش فرض).

زمانیکه هر یک از این task ها در طول زمان بیش از 50 میلی ثانیه اجرا شود (به عنوان “task های طولانی ” نیز شناخته می شود) ، می تواند هم برای First Paint و هم زمانی که برای تعامل کامل صفحه شما لازم است تأخیر ایجاد کند.

حتما از main-thread tasks طولانی تا آنجایی که ممکن است، جلوگیری کنید، تا بازدیدکنندگان سایت شما یک تجربه کاربری خوب داشته باشند.

main-thread tasks طولانی چه تاثیری بر عملکرد صفحه دارند؟

هر بار که صفحه شما بارگیری می شود ، مرورگر از main-thread برای مدیریت بیشتر کارهای مربوط به ارائه محتوای صفحه استفاده می کند.

Avoid long main-thread tasks

فایل جاوا اسکریپت که مدت طولانی در حال اجرا است (A ، B ، E در بالا) ممکن است main-thread را برای مدت طولانی مسدود کند و از اجرای سایر فایل ها توسط مرورگر جلوگیری کند و در نتیجه در بارگزاری کلی صفحه شما تأثیر بگذارد. main-thread task های طولانی مانع از این می شوند که مرورگر با سایر فرآیندهای ضروری در بارگیری صفحه شما روبرو شود.

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

کاهش تعداد main-thread task طولانی با به حداقل رساندن کارmain-thread ، عملکرد کلی صفحه شما را بهبود می بخشد. این برای بازدیدکنندگان سایت شما به این معنی است ، ممکن است محتوا را سریعتر در صفحه شما ببینند و زودتر با آن ارتباط برقرار کنند.

GTmetrix چگونه این عملکرد را بررسی می کند؟

این بررسی با معیار زمان شما برای تعامل (TTI:Time to Interaction) ارتباط زیادی دارد. با کلیک بر روی این گزارش مشخص می شود که کدام یک از فعالیت های اجرا شده اصلی بیش از 50 میلی ثانیه بوده است.

چگونه از انجام main-thread task جلوگیری کنیم؟

این بررسی تمام وظایف طولانی را که در بخش اصلی انجام می شوند، لیست می کند.

برای برطرف کردن این مشکل شما باید توالی موجود بین فایل های اجرا شده را تغییر داده و لود شدن فایل ها و کدهایی که اهمیت کمتری دارند را به تعویق بیاندازید.

توجه: این یک بهینه سازی تخصصی است. فقط به متخصصین با تجربه توصیه می شود که این بررسی را بهبود ببخشند.


منبع: Lighthouse: Avoid long main-thread tasks

حل مشکل Use a Content Delivery Network (CDN)

استفاده از “Content Delivery Network(CDN)” می تواند عملکرد سایت شما را در مناطق مختلف جهان بهبود بخشد. CDN اساساً شبکه ای از سرورها است که در سراسر جهان پخش شده است. هر CDN “گره” ایست که در منطقه دیگری قرار دارد و محتوای ثابت صفحه شما مانند تصاویر ، پرونده های CSS / JavaScript و غیره را ذخیره می کند.

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

استفاده از Content Delivery Network (CDN) چه تاثیری بر عملکرد صفحه دارد؟

Content Delivery Network با ذخیره کردن منابع ثابت صفحه شما در سرورهای مختلف جهان ، تأخیر در زمان لود شدن فایل های سایت شما را کاهش می دهد.

بسته به محلی که بازدید کنندگان شما در آن قرار دارند ، محتوای صفحه شما از نزدیکترین سرور / گره CDN ارائه می شود.

GTmetrix چگونه عملکرد آن را بررسی می کند؟

GTmetrix پاسخ درخواست های لود صفحه شما بررسی می کند و مواردی که از CDN شناخته شده ارائه نمی شوند را شناسایی می کند.

اگر صفحه شما دارای منابع ثابتی است که روی CDN شناخته نشده است ، GTmetrix عملکرد آن را بررسی می کند. رتبه این بررسی به این بستگی دارد که چه تعداد منابع از CDN شناخته شده تأمین نمی شود. توجه داشته باشید که این موضوع تأثیر کمتری در رتبه ساختار سایت شما دارد و به احتمال زیاد روی عملکرد شما تأثیر می گذارد.

استفاده از Content Delivery Network (CDN) در اصل در لیست بررسی پیش فرض Lighthouse موجود نیست.

به هر حال ، با توجه به تأثیر بالقوه آن بر عملکرد سایت به اندازه کافی مهم است که در GTmetrix در نظر گرفته شده است.

CDN ها به طور کلی عملکرد قابل توجهی را برای بازدیدکنندگان فراهم می کنند. مهم نیست که بازدید کنندگان شما از کجا هستند ، CDN می تواند با ارائه منابع ثابت از نزدیکترین گره سرور ، عملکرد ثابت را تضمین کند.

البته می توان گفت که تمامی وب سایت ها به CDN احتیاجی ندارند. و در نتیجه استفاده از Content Delivery Network (CDN) به عنوان یک عامل منفی برای وب سایت شما مانند گذشته به حساب نمی آید ؛ اگرچه هنوز هم تا حدی بر رتبه آن تاثیر می گذارد.

چگونه این بررسی را انجام دهیم ؟

اولاً ، CDN ها برای عملکرد وب سایت شما ضروری نیستند. اگرچه آن ها می توانند عملکرد وب سایت شما را در مکان های مختلف جغرافیایی به طور قابل توجهی بهبود ببخشند ، اما این سوال که آیا شما باید از یکی از آن ها استفاده کنید به مخاطبان هدف و اهداف عملکرد شما بستگی دارد.

حالات زیر در نظر بگیرید:

  • CDN های شناخته شده: اگر از CDNهای محبوب (به عنوان مثال Cloudflare ، Netflify ، Amazon CloudFront ) برای ارائه منابع صفحه خود انتخاب کنید ، ممکن است GTmetrix از قبل این CDN را تشخیص دهد. در این صورت ، با شروع استفاده از CDN ، بررسی این پارامتر باید درست شود.
  • CDN های شناخته نشده: اگر از CDNهایی استفاده می کنید که نادر هستند می توانید با جی تی متریکس تماس بگیرید تا برای شما بررسی کنند.
  • من به CDN نیازی ندارم: اگر احساس می کنید که نیازی به استفاده از CDN ندارید (به عنوان مثال مخاطبان محلی ، وب سایت کوچک و غیره) ، می توانید این بررسی را با افزودن دامنه خود به قسمت نام های میزبان CDN در قسمت Analysis Options در حساب خود دور بزنید!!!

می توانید دامنه / نام هاست ، خود را به قسمت Hostnames CDN در تنظیمات کاربر اضافه کنید.

پس از انجام این کار ، GTmetrix وب سایت شما را به دلیل عدم استفاده از CDN امتیازی از شما کسر نخواهد شد. با این حال ، توجه داشته باشید که امتیاز عملکرد شما تغییری نخواهد کرد.


منبع: Lighthouse: Use a Content Delivery Network (CDN)

حل مشکل Avoid large layout shifts

مشکل Large layout shifts می تواند تجربه بسیار بد و نا امیدکننده ای را برای بازدیدکنندگان شما ایجاد کرده و باعث شود صفحه شما از نظر بصری نامناسب به نظر برسد. چرا که عناصر صفحه به طور ناگهانی ظاهر شده ، حرکت می کنند و بر نحوه تعامل بازدید کنندگان شما با صفحه تأثیر می گذارند. اجتناب از Large layout shifts در ایجاد یک تجربه کاربری مناسب برای بازدیدکنندگان ضروری است.

Layout Shift چگونه بر عملکرد صفحه تأثیر می گذارد؟

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

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

و یا این فیلم را مشاهده کنید:

این “تغییر طرح” بر نحوه تعامل کاربران با وب سایت شما ، به ویژه در دستگاه های تلفن همراه تأثیر می گذارد. نمره پایین CLS نشان می دهد که صفحه شما از نظر بصری ناپایدار است. با اینکه CLS روی نمره عملکرد تأثیر زیادی ندارد (فقط 5٪)، درج آن در Web Vital نشان دهنده اهمیت آن به عنوان یک معیار مفید است که تجربه صفحه شما را منعکس می کند.

چگونه می توان از Large layout shifts جلوگیری کرد؟

شما می توانید با استفاده از روش های زیر ، از Large layout shifts جلوگیری کنید:

راهکار اول: تعیین ابعاد تصویر: همیشه ، عرض و ارتفاع را برای عناصر تصویر و فیلم سایت خود مشخص کنید تا از فاصله ای مناسب برای تصاویر و فیلم ها استفاده شود. همچنین میتوانید این کار را با مشخص کردن نسبت ابعاد باکس ها در CSS انجام دهید.

راهکار دوم: کاهش layout shift ناشی از تبلیغات ، embed ها و iframe ها:

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

راهکار سوم: جلوگیری از Flash of Invisible Text (FOIT) : مسئله Flash of Invisible Text (FOIT) می تواند CLS صفحه شما را تحت تأثیر قرار دهد. با preload کردن فونت ها و یا استفاده از ویژگی font-display، اطمینان حاصل کنید که متن شما هنگام بارگیری فونت وب نیز قابل مشاهده است.

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


منبع مقاله : GT metrix – Lighthouse: Avoid large layout shifts

حل مشکل Minimize main-thread work

main-thread محلی است که مرورگر قسمت اعظمی از دستورات مربوط به بارگذاری صفحه شما را پردازش می کند. مانند ارائه / چاپ محتوا یا مدیریت تعامل کاربر. در واقع main-thread فرایندهای بارگیری صفحه شما را کنترل می کند. سرعت بارگیری صفحه شما به میزان کارهایی که main-thread باید انجام دهد بستگی دارد. شما باید که اطمینان حاصل کنید main-thread برای مدت طولانی مشغول نباشد.

برخی از کارهای مرورگر که در main-thread اجرا می کند شامل موارد زیر است:

  • دست زدن به طرح بندی ها
  • تجزیه CSS و HTML
  • ساخت Document Object Model (DOM)
  • اجرای تمام JavaScript ها

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

با به حداقل رساندن کار main-thread ، مرورگر شما صفحه را برای انجام کار های ضروری آزاد می کند.

main-thread به چه مواردی بستگی دارد؟

بسته به طولانی بودن مدت main-thread در هنگام بارگیری صفحه ، GTmetrix این بررسی را آغاز می کند و زمان صرف شده را در دسته های مختلف طبقه بندی می کند ، از جمله:

  • ارزیابی اسکریپت
  • سبک و چیدمان
  • رندر گیری
  • تجزیه HTML و CSS
  • تجزیه و تدوین اسکریپت
  • مجموعه Garbage

در هنگام مشاهده گزارش جی تی متریکس با کلیک بر روی هر کدام از اشکالات مطرح شده در گزارش جی تی متریکس ، زمان صرف شده برای رویدادهای مختلف در main-thread مشخص می شود.

Minimize main-thread work

main-thread رویدادهایی مانند تجزیه HTML / CSS ، اجرای جاوا اسکریپت و غیره … را برای انجام مدیریت تعامل کاربر یا انجام کارهای دیگر مسدود می کند.

اجرای جاوا اسکریپت معمولاً قسمت عمده ای از main-thread را تشکیل می دهد. به همین دلیل سایت هایی که از جاوا اسکریپت های زیادی استفاده می کنند کمی با کند شدن اجرا همراه هستند. به طور کلی ، هرچه JavaScript صفحه شما بیشتر باشد ، فرایند تجزیه / جمع آوری طولانی تر است.

جاوا اسکریپت با اجراهای طولانی (A ، B ، E در بالا) ممکن است main-thread را برای مدت طولانی مسدود کند و از اجرای سایر کارهای لازم برای چاپ اولین صفحه شما جلوگیری کند. دوباره به مثال پبشخدمت برمی گردیم ، کاهش کارهایی که پیشخدمت باید انجام دهد ، به سرعت بخشیدن خدمات و بهبود تجربه کلی رستوران کمک می کند. 
Minimize main-thread work

چگونه main-thread را به حداقل برسانیم؟

به حداقل رساندن کار main-thread حتما باید توسط یک فرد متخصص انجام شود. برای برطرف کردن این مشکل باید فعالیت های زیر را انجام داد:

  • کاهش زمان صرف شده در ارزیابی اسکریپت ها
  • به حداقل رساندن محاسبه مجدد استایل ها و طراحی ها
  • کاهش زمان صرف شده در تجزیه CSS / HTML / JavaScript
  • جلوگیری از تأخیر در ارائه پیکسل های صفحه

برخی از استراتژی های مورد استفاده برای دستیابی به موارد فوق عبارتند از:

  1. بهینه سازی third-party JavaScript :کد third-party وب سایت خود را بررسی کنید و مواردی را که هیچ ارزشی برای وب سایت شما ندارند را حذف کنید. با به تعویق انداختن اسکریپت های غیر مهم اسکریپت های دیگر را بهینه کنید، ایجاد ارتباطات اولیه با دامنه های مهم third-party ، بارگذاری آهسته عکس ها (lazy-loading) محتوای جاسازی شده در third-party ، و بهینه سازی هاست.
  2. استفاده از web workers :برای دور نگ داشتن جاوا اسکریپت از main-thread و بهبود عملکرد صفحه خود ، از web workers استفاده کنید. (مطالعه برای کسب اطلاعات بیشتر)
  3. کاهش زمان اجرای جاوا اسکریپت:با تقسیم کد ، کوچک کردن و فشرده سازی کد جاوا اسکریپت ، حذف کد استفاده نشده و پیروی از الگوی PRPL ، از میزان حجم JavaScript خود کم کنید. (مطالعه برای کسب اطلاعات بیشتر)
  4. کاهش زمان تجزیه CSS :با کم کردن یا به تعویق انداختن CSS غیر ضروری یا حذف CSS بدون استفاده ، زمان تجزیه CSS را کاهش دهید.

منبع مقاله : Minimize main-thread work

Mobile Usability در سرچ کنسول وبمستر

  • قابلیت استفاده موبایل Mobile Usability در کنسول وب مستر چیست و به چه میزان اهمیت دارد؟
  • خطای Mobile Usability در وب مستر تولز شامل چه مواردی می شود؟
  • چگونه بایستی خطای Mobile Usability در کنسول وب مستر را برطرف نمود؟

در این مقاله به صورت کامل خطای Mobile Usability در کنسول وب مستر رو مورد تحلیل قرار میدیم و راه حل برطرف کردن این مشکل رو بررسی میکنیم.

قابلیت استفاده موبایل – Mobile Usability

استفاده روز افزون از تلفن همراه بدون شک بر کسی پوشیده نیست. برای دونستن اهمیت این موضوع کافیست بدونید که گوگل اولویت نتایج جست و جو رو بر اساس دستگاه های موبایلی قرار داده و در ادامه نتایج سیستم های کامپوتری برای گوگل دارای اهمیت هستش. یکی از مهم ترین آموزش هایی که در رابطه با آموزش کنسول وب مستر تولز باید بهش اشاره کنیم آموزش برطرف کردن خطاهای Mobile Usability هستش.

وب سایت شما حتما باید به صورت mobile friendly یا همون رسپانسیو باشه و برای کاربران نمایش خوب و مناسبی داشته باشه. دکمه های وب سایت شما باید به صورت تنظیم شده باشن تا به راحتی بشه از اونها در دستگاه های تلفن همراه استفاده کرد.

mobile useability in webmaster

برای تست این موضوع که آیا وب سایت شما از دید گوگل موبایل فرندلی هست و یا نه کافیه وارد لینک ” بررسی وضعیت mobile friendly از دید گوگل ” بشید و لینک صفحه مورد نظر خودتون رو وارد کرده و بررسی کنید. اگه صفحه شما مشکلی نداشته باشه پیغام سبز رنگی به شما میده و صفحه شمارو تایید میکنه در غیر این صورت با اخطار قرمز رنگ به شما میگه که باید اشکالات وب سایت خودتون رو برطرف کنید.

  • Status (وضعیت) : که با Error برای خطا و یا Valid برای صفحات سالم به شما نشون میده این سری از مشکلات رو دارید و یا نه.
  • Type(نوع) : در این قسمت گوگل به شما میگه که نوع مشکل صفحات شما از چه نوعی است.
  • Pages (صفحات): و در نهایت در این قسمت تعداد صفحاتی که قابلیت استفاده با موبایل رو ندارن و یا استفاده از اونها با مشکل مواجه میشه.

خطاهای موجود در Mobile Usability

شما در این قسمت با چند دسته خطا مواجه خواهید شد.

  • text too small to read : زمانی که متن ها و نوشته های سفحات وب سایت شما اندازه خیلی کوچیکی داشته باشه به صورتی که نشه اونهارو خوند و از دید گوگل به خصوص کوچک تر از حد استاندارد باشن این ارور برای شما نمایش پیدا میکنه.
  • Clickable elements too close together : با داشتن این ارور یعنی المان های استفاده شده در وب سایت شما خیلی به هم نزدیک هستن و در موبایل این امکان وجود نداره که به راحتی بر روی اونها بشه کلیک کرد.
  • mobile friendly pages : در این قسمت صفحات وب سایت شما که به صورت موبایل فرندلی هستن و تایید شدن رو به شما نمایش میده
  •  Uses incompatible Plugins : شما از پلاگین هایی برای سایت خودتون استفاده کردید که سازگار با موبایل نیستن.
  • Content wider than screen : این خطا به این معناست که محتوی وب سایت شما بزرگتر و بیشتر از صفحه نمایش دستگاه هاست.
  •  Viewport not set : در واقع view port کادری در نمایشگر هست که سایت ها در اون نمایش پیدا میکنن.
  •  Viewport not set to device-width: این ارور هم بدان معناست که دستگاه ها و موبایل های مختلف که دارای اندازه های مختلفی هستند نمیتونن تا سایت شمارو در ابعاد مناسبی نمایش بدن.

برای حل هردوتا مشکل بالا کافیه که در قسمت Head سایت قبل از فراخوانی کدهای CSS کد زیر رو وارد کنید تا این مشکل برطرف بشه:

<meta name=”viewport” content=”width=device-width, initial-scale=1″>

موبایل وبمستر تولز

اعتبارسنجی با Validation بعد از رفع مشکل

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

در صورتی که شما همه اشکالات رو برطرف کرده باشید با پیام fixed مواجه میشید. یعنی اینکه اشکالات وب سایت شما برطرف شده. البته این نکته رو در نظر داشته باشید که گوگل تا 90 روز اون صفحه رو بررسی مجدد میکنه و بی خیالش نمیشه تا مطمئن بشه که اون خطا حتما از بین رفته. به طور کلی پروسه بررسی گوگل برای بررسی اشکالات صفحات وب سایت شما مدت زمانی طول میکشه که شما باید صبور باشید.

مشکل coverage در وبمستر

خطای Coverage در وب مستر

  • انواع خطای Coverage در وب مستر چه خطاهایی هستند؟
  • چه زمانی خطای Coverage در کنسول وب مستر ایجاد می شود؟
  • راه حل برطرف کردن خطاهای Coverage در وب مستر تولز چیست؟
  • بازبینی مجدد صفحات از طرف گوگل به چه صورت بیان می گردد؟

خطای Coverage در وب مستر

در این قسمت از مجموعه آموزش کنسول گوگل وب مستر تولز ، به اشکالات coverage میرسیم. یكی از زبانه‌های فنی تر اما بسیار ارزشمندتر در كنسول جستجوی گوگل، زبانه‌ی Index>Coverage است. این بخش نشان می‌دهد كه چه تعداد صفحه از زمان آخرین به روزرسانی در شاخص گوگل قرار دارند و چه تعداد صفحه این طور نیستند. همچنین نشان می دهد که چه خطاها و هشدارهایی موجب دشواری شاخص‌گذاری گوگل می‌شوند.

ایمیل های خطایی که از طرف وب مستر برای شما ارسال می شود و غالبا با عنون ” New Index coverage issue detected for site site.com ” هستند. این ایمیل ها بیان می کنند که در نتیجه خزش ربات گوگل در وب سایت شما ، مشکلاتی رخ داده که گوگل به شما پیشنهاد داده است که این مشکلات را برطرف کنید. با ورود به وب مستر خود باید مشخص کنید که کدام بک از صفحات وب سایت شما دچار مشکل شده است. برای این موضوع وارد قسمت Index >>> Coverage بشوید.

Index Coverage

در این بخش 4 مورد بسیار مهم نمایش داده شده است.

  • Error: لیست صفحاتی که دارای خطا هستند و ممکن است از نتایج گوگل حذف شوند.
  • Valid with warnings: صفحاتی که در نتایج گوگل نمایش داده می شوند ، مشکل حادی ندارند اما دارای مشکلاتی هستند که بهتر از هرچه سریعتر برطرف شود.
  • Valid: صفحاتی که بدون مشکل از طرف گوگل بررسی شده اند.
  • Excluded: صفحاتی که ریدایرکت شده و یا متاتگ نوایندکس دارند که بدین معناست که شما خزش گوگل را در این صفحات مجاز نمی دانید.

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

باكلیك بر روی پیوند، می‌توانید خطا را با جزئیات بیشتر تحلیل كنید تا متوجه شوید كه كدام URLهای خاص، تحت تأثیر قرار گرفته‌اند. وقتی خطا را رفع كردید می‌توانید را به عنوان ترمیم شده علامت بزنید تا مطمئن شوید كه گوگل بار دیگر URL را بررسی می‌كند:

Index-Coverage-2

ارورهای متداول در Coverage

در این قسمت شما با چندین ارور مختلف ممکن است که مواجه شوید. این خطاها عبارتند از:

خطاهای کد 5 – Server error (5xx)

وب سایت شما دارای خطاهایی با کد پنج از سمت سرور است.

  • ارور 500 Internal Server : بدترین نوع ارور که در آن مشخص نیست دقیقا خطا به چه علتی رخ داده. ممکن است مشکل از کد نویسی وب سایت شما ، سیستم کش و یا افزونه های وب سایت شما باشد. برای رفع این خطا باید تمام ارور های کد 5xx را برطرف کنید.
  • ارور 502 Bad Gateway: ارور سرورهای اینترنتی که خارج از کنترل شماست.
  • ارور 503 Service Unavailable: سرویس دهنده سیستم هاستینگ شما دچار مشکل شده ، شلوغ است و یا به علت تعمیرات یا به روزرسانی از دسترس خارج شده است.
  • ارور 504 Gateway Timeout: پاسخ از سمت سرور در زمان مناسبی ارسال نشده است که این مورد نیز از کنترل شما خارج است.

اگر چنانچه با اینگونه ارورها به تعداد دفعات زیادی مواجه شدید پیشنهاد میکنیم حتما شرکت هاستینگ خود را تغییر دهید.

خطاهای ریدایرکتی – Redirect error

زمانیکه این ارور را مشاهده کردید ممکن است که ریدایرکت شما طولانی بوده و لود نهایی زمان زیادی را طول کشیده باشد. یا اینکه ریدایرکت شما در یک loop یا چرخه بی انتها قرار گرفته باشد. البته در نظر داشته باشید که این مورد ممکن است به دلیل اختلال در سیستم هاستینگ شما نیز رخ داده باشد. که به صورت موقت است.

با استفاده از ابزار GTMetrix هم می توانید این ارورها را در صفحات وب سایت خود مشخص کنید.

بلاک شدن صفحات وب سایت شما – Submitted URL blocked by robots.txt

این خطا بدان معناست که شما در فایل robots.txt اجازه خزش به ربات گوگل را برای برخی صفحات بسته اید که این موضوع از دید گوگل خوشایند نخواهد بود. با کلیک بر روی test robots می توانید فایل روبوتس خود را بررسی کنید و از صحیح بودن آن اطمینان کسب کنید. البته گاها هم مشاهده شده که این خطا نامربوط بوده و پس از گذشت مدتی از کنسول گوگل شما حذف خواهد شد. چنانچه در این مسیر با مشکلی مواجه شدید حتما با کارشناسان مجموعه تاپ ادرت تماس بگیرید و از مشاوره رایگان تیم ما استفاده کنید.

ایندکس نکردن صفحات در نتایج جست و جو – Submitted URL marked noindex

این ارور زمانی رخ می دهد که شما در فایل robots.txt به گوگل بیان کرده اید که برخس صفحات را در صفحه نتایج گوگل نمایش ندهد. این مورد باید به دقت و با وسواس خاصی از طرف شما انتخاب گردد. حتما از مشاوره با یک کارشناس حرفه ای برای تنظیم فایل روبوتس (robots) خود استفاده کنید.

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

حتما توجه داشته باشید که صفحات Noindex را از قسمت نقشه سایت یا همان sitemap خود حذف کنید چراکه در غیر این صورت با ارور New Index coverage issue detected مواجه خواهید شد.

در صورت استفاده از افزونه ووکامرس (woocommerce) مربوط به فروشگاه وردپرس است، برخی صفحات مانند صفحه cart و صفحه checkout آن باید که noindex باشند. اگر چنانچه با ارور برای این صفحات مواجه شدید آن را نادیده بگیرید.

ارور 404 نرم – Submitted URL seems to be a Soft 404

بدان معناست که صفحه ی مذکور دارای محتوی بسیار ضعیفی است یا اصلا محتوی داخل آنها وجود ندارد و یا ممکن است مشکلات دیگری داشته باشید. توجه داشته باشید که این ارور با ارور 404 not found کاملا متفاوت است.

Submitted URL returns unauthorized request (401)

در صورت مشاهده این ارور که به ندرت اتفاق می افتد گوگل به شما می گوید که صفحه قابل بارگذاری نیست و مگر اینکه در ابتدا با یک شناسه کاربری و رمز عبور معتبر ، وارد سایت شوید (Login).

Submitted URL not found (404)

معروف ترین خطای سری خطاهای با کد 4 ، بدین معناست که آدرس url ذکر شده وجود ندارد که یعنی صفحه شما یا پیش نویس است و یا از لیست صفحات شما حذف شده است. همچنین ممکن است که آدرس ذکر شده دارای اشتباه تایپی در کاراکترهای url خود باشد.

Submitted URL has crawl issue

در صورت بروز این خطا یعنی ربات گوگل در نتیجه خزش در وب سایت شما با مشکلی مواجه شده که دلیل آن را نمی داند. پیشنهاد میکنیم با استفاده از ابزار url inspection این مشکل رو بررسی کنید.

بیان رفع اشکال به گوگل

بعد از برطرف کردن ارورهای ذکر شده باید مراحل زیر را برای اطلاع رسانی به گوگل به منظور رفع اشکال انجام دهید.

در ابتدا به این مسیر بروید :قسمت Index سرچ کنسول >> coverage

sitemap coverage issue

در ادامه به قسمت ارورهای رخ داده بروید و بر روی آنها کلیک کنید. در ادامه بر روی گزینه validate fix کلیک کنید. در ادامه گوگل ایمیلی با این محتوی برای شما ارسال میکنه We’re validating your fixes for Index coverage issues و بیان میکنه که بیان رفع اشکال از طرف شمارو گوگل دریافت کرده. البته با کلیک بر روی INSPECT URL می توانید یک بررسی LIVE از صفحه خود انجام دهید که پیشنهاد میکنیم حتما این کار را انجام دهید.

sitemap coverage issuesitemap coverage issue

سخن آخر

خطای Coverage در وب مستر نکته بسیار مهمی است که نباید از کنار آن بدون توجه عبور کرد. چند نكته وجود دارد كه باید در زمان بررسی گزارش‌های پوشش همواره مدنظر داشته باشید:

  • اگر محتوای جدیدی می‌نویسید، صفحات شاخص شده‌ی شما باید یك عدد افزایشی ثابت باشند. این دو مورد را به شما می‌گوید: گوگل می‌تواند سایت شما را شاخص‌ كند و سایتتان را با افزودن محتوا، زنده نگه داشته‌اید.
  • مراقب افت‌های ناگهانی باشید! این یعنی گوگل در دسترسی به (تمام) سایت شما دچار مشكل شده است. چیزی ممكن است گوگل را مسدود كرده باشد، آیا txt تغییر یافته یا سرور از كار افتاده: باید به دنبال آن باشید!
  • افت‌ و خیزهای ناگهانی (و غیرمنتظره) در نمودار می‌توانند به این معنی باشند كه مشكلی در مورد محتوای مضاعف (مثل www و غیر www، معیارهای اشتباه و…)، به طور خودكار صفحاتی را ایجاد كرده یا حتی هك كرده است.

پیشنهاد ما این است كه این شرایط را از نزدیك بررسی كرده و خطاها را به سرعت رفع كنید چرا كه تعداد زیاد خطاها می‌توانند به معنی كیفیت پایین (نگهداری ضعیف) برای گوگل باشند.