فهرست عناوین
بررسی اشکالات جی تی متریکس
حل مشکلات 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 را مجموع مدت زمان ارسال درخواست، مدت اتصال و مدت زمان بازگشت میداند.
در شکل فوق زمان محاسبه شده برای 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 بزرگ چگونه بر عملکرد صفحه تأثیر میگذارد؟
هر زمان که یک صفحه بارگیری میشود، مرورگر قبل از اینکه شروع به ساخت درخت 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 استفاده کنید، چند نمونه برای شما معرفی کرده ایم:
- بارگیری درخواستهای کلیدی: برای سرعت بخشیدن به اجرای منابع مهم، درخواستهای کلیدی (مانند: اسکریپتها، صفحات وب، صفحههای سبک و غیره) را از قبل بارگیری کنید، این کار باعث صرفه جویی وقت در زمان بارگیری صفحه میشود.
- کاهش تعداد critical resources: برای کاهش تعداد critical resources مورد نیاز (یعنی منابع مورد نیاز برای نمایش محتوای با ارزش) بوسیله به تأخیر انداختن بارگیری non-critical resources یا در صورت امکان از حذف کامل آنها استفاده کنید. این کار تضمین میکند که مرورگر زمان کمتری را برای بارگیری منابع غیرضروری صرف کند. به عنوان مثال: تصاویر کم ارزش، کدهای جاوا اسکریپت، استایلهای CSS برای محتوای غیر مهم.
- استفاده از ویژگی 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 برای مدیریت بیشتر کارهای مربوط به ارائه محتوای صفحه استفاده میکند.
فایل جاوا اسکریپت که مدت طولانی در حال اجرا است (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 مشخص میشود.
main-thread رویدادهایی مانند تجزیه HTML / CSS، اجرای جاوا اسکریپت و غیره … را برای انجام مدیریت تعامل کاربر یا انجام کارهای دیگر مسدود میکند.
اجرای جاوا اسکریپت معمولاً قسمت عمده ای از main-thread را تشکیل میدهد. به همین دلیل سایت هایی که از جاوا اسکریپتهای زیادی استفاده میکنند کمی با کند شدن اجرا همراه هستند. به طور کلی، هرچه JavaScript صفحه شما بیشتر باشد، فرایند تجزیه / جمع آوری طولانی تر است.
جاوا اسکریپت با اجراهای طولانی (A، B، E در بالا) ممکن است main-thread را برای مدت طولانی مسدود کند و از اجرای سایر کارهای لازم برای چاپ اولین صفحه شما جلوگیری کند. دوباره به مثال پبشخدمت برمی گردیم، کاهش کارهایی که پیشخدمت باید انجام دهد، به سرعت بخشیدن خدمات و بهبود تجربه کلی رستوران کمک میکند.
چگونه main-thread را به حداقل برسانیم؟
به حداقل رساندن کار main-thread حتما باید توسط یک فرد متخصص انجام شود. برای برطرف کردن این مشکل باید فعالیتهای زیر را انجام داد:
- کاهش زمان صرف شده در ارزیابی اسکریپت ها
- به حداقل رساندن محاسبه مجدد استایلها و طراحی ها
- کاهش زمان صرف شده در تجزیه CSS / HTML / JavaScript
- جلوگیری از تأخیر در ارائه پیکسلهای صفحه
برخی از استراتژیهای مورد استفاده برای دستیابی به موارد فوق عبارتند از:
- بهینه سازی third-party JavaScript :کد third-party وب سایت خود را بررسی کنید و مواردی را که هیچ ارزشی برای وب سایت شما ندارند را حذف کنید. با به تعویق انداختن اسکریپتهای غیر مهم اسکریپتهای دیگر را بهینه کنید، ایجاد ارتباطات اولیه با دامنههای مهم third-party، بارگذاری آهسته عکسها (lazy-loading) محتوای جاسازی شده در third-party، و بهینه سازی هاست.
- استفاده از web workers :برای دور نگ داشتن جاوا اسکریپت از main-thread و بهبود عملکرد صفحه خود، از web workers استفاده کنید. (مطالعه برای کسب اطلاعات بیشتر)
- کاهش زمان اجرای جاوا اسکریپت:با تقسیم کد، کوچک کردن و فشرده سازی کد جاوا اسکریپت، حذف کد استفاده نشده و پیروی از الگوی PRPL، از میزان حجم JavaScript خود کم کنید. (مطالعه برای کسب اطلاعات بیشتر)
- کاهش زمان تجزیه CSS :با کم کردن یا به تعویق انداختن CSS غیر ضروری یا حذف CSS بدون استفاده، زمان تجزیه CSS را کاهش دهید.
منبع مقاله : Minimize main-thread work
ممنون از مقاله خوبتون.
من مشکلم TTFB در حالت موبایل وبسایتم هست . میفرمایید رفع خطای reduce initial server response time درموبایل چجوری انجام میشه؟؟؟؟
ببینید این موضوع به ساختار کد بندی سایت شما و همچنین قدرت سروری هست که هاستینگ بر روی اون قرار داره ، حتما یک هاستینگ خوب و با کیفیت انتخاب کنید و وب سایت خودتون رو داخل اون بالا بیارید و همچنین داخل سایت خودتون از افزونه های اضافی تا حد امکان استفاده نکنید.