به عنوان مدیر یک وب سایت شما همیشه به دنبال افزایش سرعت وب سایت خودتان برای بالا بردن رضایت کاربرانتان یا همان تجربه کاربری هستید. یکی از جدیدترین و مدرنترین مدلهای افزایش سرعت سایت در حال حاضر استفاده یک سرویس CDN میباشد. (CDN به معنای شبکه تحویل محتوا یا شبکه توزیع محتوا یاد میشود).
این سرویسها بار اضافه را از سرور اصلی سایت شما کاهش داده و باعث میشود سرعت تحویل محتوا به کاربران بالاتر رود، تجربه کاربری بهتری در مدیریت وب سایت به شما و کاربرانتان هدیه میدهند.
امروز ما میخواهیم شما را با نحوه کار CDN ها و همچنین دلیل استفاده از آنها و معرفی برخی مزایای اضافی CDN ها آشنا کنیم. همچنین با نمایش چندین آزمایش سرعت قبل و بعد از فعال سازی سرویس CDN شما را به چالش میکشیم که خود تفاوت استفاده کردن و استفاده نکردن CDN را قضاوت کنید.
۴۰ درصد کاربران اگر وب سایتی بیشتر از ۳ ثانیه لود شود آن رها میکنند. (این یک شاخص جهانی است ولی در ایران با توجه به سرعت بسیار پایین اینترنت و حجم بالای وب سایت ها این شاخص تا ۷ ثانیه پیشبینی میشود).
کلمه CDN مخفف کلمه content delivery network به معنای شبکه تحویل محتوا (شبکه توزیع محتوا) میباشد. این سرویس یک شبکه از سرورها در سراسر جهان میباشد که برای میزبانی اطلاعات استاتیک (و گاهی داینامیک) وب سایت شما نظیر تصاویر، ویدیوها، فایلهای CSS و فایلهای جاوااسکریپت طراحی شده است. توجه داشته باشید که وقتی از میزبانی صحبت میکنیم منظور میزبانی وب سایت شبیه هاستهای اشتراکی یا اختصاصی سایت شما نیست. CDN به طور کامل یک سرویس جداگانه میزبانی میباشد. سرویسهای CDN جایگزین هاستهای میزبانی شما نیست ولی راهی اضافه برای بهبود سرعت سئو سایت میباشد.
سرویس CDN دقیقا چگونه کار میکند؟ خب، به عنوان مثال ، وقتی شما قصد خرید یک هاست میزبانی وب را دارید ، میبایست مکان یک دیتاسنتر فیزیکی مثل آلمان، فرانسه، امریکا، ایران و غیره را انتخاب کنید. به عنوان نمونه فرانسه را برای میزبانی انتخاب کردیم. این به معنی آن است که مثلا وب سایت شما توسط سرورهایی واقع در پاریس میزبانی میشود. حال در نظر بگیرید فردی در ایران بخواهد وارد وب سایت ما شود و فردی نیز از فرانسه وارد وب سایت ما شوید، به علت مکان قرارگیری سرور و همچنین انتقال دادهها از مبدا به کشور مقصد، زمان لود وب سایت در ایران بیشتر از فرانسه خواهد بود. این چیزی است که به آن لِیتنسی یا تاخیر گفته میشود (latency). لیتنسی به زمان یا تاخیری گفته میشود که برای انتقال اطلاعات در شبکهها لازم است. بنابراین هرچه فاصله کاربر از مکان قرارگیری سرور وب سایت دورتر باشد لیتنسی نیز بیشتر میشود.
همچنین لیتنسی را در تبادل دادهها فراموش نکنید، هنگامی که شما به عنوان کاربر دادهها را دریافت میکنید و با پر کردن فرم یا کلیک روی کلیدی درخواستی را برای سرور ارسال میکنید، باز هم فاصله شما با سرور باعث تاخیر در دریافت پاسخ میشود. حال جایی است که CDN وارد بازی میشود و ما در این زمان برای کاهش لیتنسی سرویسی به نام CDN را وب سایت خود اضافه میکنیم. سرویس CDN اطلاعات را از نزدیکترین سرور برای کاربر نمایش میدهد و این کار باعث کاهش لیتنسی لود وب سایت میشود. سرورهای CDN را گاهی نقطه حضور (POPs) مینامند.
کاربران وردپرسی در ابتدا برای استفاده از CDN بیمیلی نشان میدهند. در اینجا ما در ۳ مرحله خیلی ساده نحوه عملکرد CDNو همچنین نحوه فعالسازی آن در وب سایتتان را آموزش میدهیم.
یک ارائه دهنده سرویس CDN را انتخاب کنید و در وب سایتش ثبت نام کنید. سرویس دهی آنها بیشتر به صورت ماهیانه یا حجم پهنایباند میباشد و اکثر ارائه دهندگان برای محاسبه قیمت، به صورت هوشمند عمل میکنند و نیازی به ارسال تیکت یا تماس با ارائه دهنده نیست.
برای ادغام CDN خود با وردپرس از یک افزونه رایگان مانند CDN Enabler استفاده کنید. این افزونهها به صورت خودکار دادههای شما را با CDN ادغام میکنند. با این افزونهها نیازی نیست که شما به هیچ چیزی دست بزنید و همه کارها به صورت خودکار انجام میشود، صرفا برخی اطلاعات اولیه برای وصل شدن به CDN لازم دارند. در حال حاضر استفاده ازCDN نسبت به چند سال پیش خیلی راحتتر شده است.
حال هنگامی که کاربران شما وارد وبسایتتان میشوند، اکنون محتوای وب سایت وردپرسی شما در CDN هایی در سراسر دنیا لود میشود و نسبت به مکان کاربر نزدیک ترین سرور CDN انتخاب میشود و اطلاعات برایش لود میشود. پس اگر حال کاربر از ایران وارد وب سایت ما شود دیگر لیتنسی قبلی را برای انتقال از فرانسه به ایران را احساس نمیکند زیرا اطلاعات از سروری در آسیا برایش ارسال میشود. حال به این بخش میرسیم که CDN چگونه مکان کاربر را تشخیص میدهد. این سرور برای تشخیص مکان فعلی کاربر از تشخیص IP و همچنین مسیریابی جغرافیایی استفاده میکند تا دقیقترین مکان را تشخیص و نزدیکترین سرور را به درستی انتخاب کند.
با این حال، هنوز هم انتخاب یک سرور قدرتمند در یک مکان مرکزی بسیار اهمیت دارد، چون اگر از یک CDN قدرتمند برای لود اطلاعات وب سایت خود استفاده کنید نیز مرورگر باید چند درخواست برای دریافت فایلهای استاتیکی مثل HTML وPHP ارسال کند، مگر اینکه از تکنیک ذخیره سازی در سرور پروکسی استفاده کنیم که آن بخشی جداست که بعدا به آن میپردازیم. در حال حاضر وب سایتهای میزبانی بسیاری هستند که از نظر ارائه سرور قدرتمند در ایران فعالیت میکنند و از مکانهای مختلفی از جهان از جمله خود کشورمان ایران سرویس دهی میکنند.
در زیر تعداد اندکی از مزایای بسیار زیاد CDN ها را بیان میکنیم.
بهبود عملکرد یکی از مهمترین دلایل استفاده از این سرویس میباشد. با این سرویس هربار که وب سایت را لود میکنید سرویس از نزدیک ترین سرور با حداکثر سرعت دادهها را دریافت کند و نرخ فرار کاربران یا bounce rate را کاهش دهد (اطلاعات بیشتر درباره bouce rate را میتوانید در مقاله bounce rate چیست بخوانید) و برای شما بازدیدکنندگانی وفادار پیدا کند. و این به معنای تغییر سادهای در تجربه کاربری نیست. آخرین باری که وارد وب سایتتان شدید و وب سایت دیر لود شد چه زمانی بود؟ این چیزی است که دوست دارید براتون خاطره شود و همیشه سرعتی عالی برای لود شدن صفحه داشته باشید. این سرعت به همین راحتیها هم به دست نمیآید. در زیر آماری معتبر از بزرگان این صنعت براتون آماده کردیم که بهتر است به آن توجه کنید :
تمامی این مشکلات و نکات توسط CDN امکان پذیر است.
ما قبلا در بالا ذکر کردیم که اتصال یک CDN به وب سایت وردپرسی شما باعث میشود که لیتنسی وب سایت شما با کم شدن مسافت فیزیکی کاربران نسبت به سرور کاهش یابد. همچنین میتواند باعث کاهش زمان دستیابی شما به اولین بایت وب سایت شود.(TTFB یا time to first byte)
در تعریف ساده TTFB باید بگویم که برای دریافت اولین بایت دادههای وب سایت، مرورگر موظف است زمانی منتظر بماند. هرچقدر که این زمان بیشتر باشد، لود وب سایت نیز دیرتر انجام میشود. ولی پیشنهاد مهمی برای شما داریم و آن این است که حتما مقاله TTFB چیست را مطالعه نمایید تا باعث بهینه سازی زمان بارگذاری سایت خود شوید.
یک تصور غلط در رابطه با محاسبه TTFB این است که بیشتریها تصویر میکنند که زمان دستیابی مرورگر به اولین بایت وب سایت بعد از بررسی DNS میباشد که این تصوری کاملا اشتباه است. زمان تاخیر TTFB به لیتنسی وب سایت شما بستگی دارد و هرچه پایینتر باشد TTFB شما نیز پایینتر است.
به طور کلی لود شدن اولین بایت در وب سایت باید ۳ مرحله پردازش، تاخیر و لیتنسی را بگذراند. TTFB بالا در وبسایت شما ممکن است به علت کدنویسی اشتباه ویا استفاده اشتباه از سیستم کش باشد.ولی مکان کاربران نیز یکی از دلایل موجود میباشد. ما با انجام آزمایشی تفاوت فعال بودن و نبودن CDN را در TTFB وب سایتمان بررسی کردیم که نتیجه آن به صورت زیر میباشد.
ما در ابتدا یک تست را بدون فعالسازی CDN انجام دادیم که در نتیجه تست زمان لود وب سایت ۱.۴۵ ثانیه نمایش داده شد که از این زمان ۱۳۶ میلی ثانیه اش به TTFB وب سایت مربوط بود.
پس از فعالسازی CDN و تست دوباره وب سایت، همانطور که مشاهده میکنید زمان لود وب سایت ۷۸۸ ثانیه و TTFB وب سایت نیز 37 میلیثانیه شده است. حال وقت آن است که بگویید، واو CDN چه تغییری ایجاد کرد
سرفصلهای پست
امروز قصد داریم تا با نگاهی عمیق به یکی از پرطرفدارترین ابزار آنلاین تست سرعت سایت یعنی ابزار Pingdom و چگونگی استفاده بهتر از این ابزار بپردازیم. البته بارها در پستهای مختلف آموزش سئو به سایت Pingdom اشاره کردیم و حتی در مقاله برترین ابزارهای آنلاین جهت تست سرعت سایت نیز به شکل خلاصه این ابزار قدرتمند را تشریح کردیم. شما با ابزار Pingdom میتوانید تحلیلی آبشاری از وب سایت خود داشته باشید. این تحلیلها به شما کمک میکند تا مشکلات عملکرد وب سایتتان را تشخیص دهید و با حل آنها طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی،قیمت طراحی سایت) های بدون مشکل سرعت سایت داشته باشید. مشاهده میشود که بعضی از کاربران وردپرسی ما که به اطلاعات نمایش داده شده در Pingdom آشناییت ندارند، با دستکاری وب سایت سرعت لود وب سایت را از قبل هم بدتر میکنند.
Pingdom یک شرکت ارائه خدمات مانیتورینگ آپتایم و خدمات مدیریت عملکرد وب سایت مستقر در سوئد میباشد. همواره یکی از چیزهایی که هر وب مستری با آن آشناست، ابزار بررسی سرعت لود وب سایت Pingdom میباشد و در بین کاربران وردپرسی نیز میتوان یکی از پرطرفدارترین ابزارها آن را معرفی کرد. چرا؟ اولین دلیل آن استفاده بسیار ساده آن است ، برای استفاده از آن نیازی نیست که کاربر خیلی حرفه ای باشد و برای کاربران عادی وردپرس کاربردی ساده دارد که در ابزارهای جایگزین کمتر دیده میشود. گاهی اوقات امکانات بعضی از ابزارها انقدر پایین است که اصلا جای صحبتی باقی نمیگذارد.
ابزار Pingdom امکان تست وب سایتتان را از ۵ مکان مختلف میدهد، که لیست آنها در زیر آورده شده است:
مکان فیزیکی که انتخاب میکنید خیلی مهم است، زیرا درواقع مربوط به جایی میشود که وب سایت شما میزبانی میشود. با این حال، به ادامه مقاله توجه فرمایید، در ادامه به جزئیات بیشتری اشاره خواهیم کرد.
یک صفحه وب به طور کلی از چندین ساختار مانند HTML،CSS،JS، تصاویر و ویدیوها تشکیل میشود. هرکدام از اینها یک درخواست را هنگامی که شما میخواهید یک صفحه وب را مشاهده کنید ارسال میکنند. به طور کلی، هرچه تعداد درخواستهای وب سایت شما بالاتر باشد، وب سایت شما کندتر میشود ولی همیشه هم درست نیست، در بعضی اوقات برای مثال در Lazy Load با بالا رفتن درخواستها شاهد افزایش سرعت نیز میشوید. در زیر ما قصد داریم که تمامی بخشهای ابزار Pingdom را بررسی کنیم، هر قسمت مربوط به عملکرد کلی وب سایت را به طور کامل برایتان توضیح دهیم و به نحوه تحلیل آبشاری نتایج بپردازیم.
هنگامی که شما وب سایت وردپرس خود را در Pingdom وارد میکنید، Pingdom به شما یک درجه عملکرد، زمان لود، حجم کلی وب سایت و تعداد درخواستها را نشان میدهد میتوان گفت ساختاری شبیه به سایت GTmetrix دارد و اگر مقاله آنالیز Gtmetrix را مطالعه کرده باشید به چنین ویژگیهایی نیز اشاره کردیم. به عنوان مثال، در زیر ما وب سایت perfmatters.io را مورد بررسی قرار دادیم . همانطور که میبینید در اولین تست وب سایت درجه ۱۰۰ را از ۱۰۰ نمره به دست آورد و در زیر ۹۰۰ میلیثانیه لود میشود. همانطور که مشاهده میکنید این وب سایت از ۹۶ درصد وب سایتهای تست شده در این ابزار سریعتر است.
ما یک آزمایش دیگر بر روی این وب سایت انجام دادیم که نتیجه آن لود ۴۹۱ ثانیهای شد. چه اتفاقی برای وب سایت افتاد؟ این اتفاق هنگامی که چندین بار یک وب سایت را در Pingdom آزمایش میکنید اتفاق میافتد که دلیل آن وجود کش در مرورگر کاربر، سرور و DNS میباشد. برای درک بهتر این امر به بخش تحلیل آبشاری مراجعه فرمایید.
آیا میخواهید که نتیجه بهتری در آزمایشات Pingdom داشته باشید؟ با توجه به نوع وب سایت شما و نوع پیکربندی آن هیچ تضمینی در اینکه شما درجه عملکرد ۱۰۰ را از ۱۰۰ نمره بگیرید نیست ولی با صرف چندین ساعت وقت برای بهینه سازی وب سایتتان میتوانید بهبود رتبه را از امروز شروع کنید. در بعضی از مواقع تجربه کاربری ممکن است جای چیزهایی که خواندید را پرکند و شما در بخش هایی نیازی به بهینه سازی محتوا نداشته باشید. هیچ وقت تجربه کاربری (UX) را فراموش نکنید. اما مطمئن باشید که با آموزشی که ما در زیر به شما میدهیم میتوانید کلیه مراحل رساندن وب سایت به نتیجهای مانند نتیجه بالا را یاد بگیرید.
بخش بینش عملکرد (همان Insights) ابزار Pingdom، یکی از بخشهای بسیار مهم و کمک کننده در این ابزار میباشد. تمامی اطلاعات گنجانده شده در این بخش با توجه به قوانین بینش عملکرد گوگل (Insights) میباشد. به طور کلی، اگر شما بتوانید این بخش را در وب سایت خود بهبود دهید، باید شاهد کاهش زمان لود وب سایت خود باشید.
یکی از رایجترین مشکلات افراد در هنگام آزمایش وب سایت در ابزارهای تست سرعت رویارویی با خطای Leverage Browser caching میباشد. این خطا به علت وجود مشکل HTTP Cache header در سرور شما میباشد. برای حل این مشکل به آموزش حل مشکل Leverage Browser Caching وب سایت سئوراز مراجعه کنید.
یکی دیگر از مسائل رایج موجود در آزمایشات مورد Riove Query Strings میباشد. فایلهای CSS و JS در هنگام لود شدن در فایل HTML وب سایت ورژن های خود را نیز لینکها قرار میدهند. مانند :domain.com/file.min.css?ver=4.5.3 .بعضی از سرورها و پروکسیها امکان کش کردن این فایلها وقتی اینگونه لینک میشوند ندارند. پس با حذف ورژن از لینکها شما میتوانید سیستم کش وب سایت خود را بهبود بخشید. برای حل این مشکل میتوانید از افزونه رایگان Query Strings Riover در وردپرس استفاده کنید تا به صورت خودکار عملیات حذف ورژنها انجام شود. در غیر اینصورت برای حل این مشکل میتوانید به آموزشحل مشکل Riove Query Strings وب سایت سئوراز مراجعه فرمایید.
در بیشتر مواقع وب مسترها به علت وجود پروتکلهای جدیدی مثل HTTP/2 این خطا را نادیده میگیرند. اضافه کردن یک اتصال جدید همیشه نسبت به زمانی که همه ساختار را در یک اتصال بارگیری میکنید، هزینه کمتری برایتان خواهد داشت. با این حال، ما دو راه برای حل این مشکل داریم که یک استفاده از یک ارائه دهنده CDNو دیگری اضافه کردن یک دامنه یا زیردامنه (SubDomain) به وب سایت است.
این مشکل به علت وجود محدودیت در HTTP/1.1 و اتصال همزمان مرورگر به وب سایت میباشد ، که در بیشتر سرورها ۶ اتصال است. این هشدار بیشتر در وب سایت هر پربازدید و پردرخواست نمایان میشود. در گذشته تنها کاری که میتوانستیم انجام دهیم عمل Call Domain Sharding بود. با این حال، اگر از سرویس CDN استفاده میکنید و سرویس CDN شما ازHTTP/2 پشتیبانی میکند، میتوانید این هشدار را نادیده بگیرید زیرا در حال حاضر دانلودهای شما در چندین سرور تقسیم بندی میشود.
این خطا به HTTP header وب سایت شما مربوط میشود و باید در سروراصلی وب سایت شما رعایت شود، که سرور درخواستی را برای مرورگر کاربر بفرستد تا متوجه شود که آن مرورگر امکان مشاهده محتوا بهینه سازی شده را دارد یا خیر!!!
این هشدار به کش HTTP header وب سایت مربوط میشود که باید در سرور اصلی وب سایت بر روی اعتبار و زمان کش اعمال شود. اگر header ها لود نشوند، مرورگر درخواست دیگری را ارسال میکند و تا دریافت نهایی header وب سایت لود نمیشود و این باعث افزایش زمان لود وب سایت میشود. این header ها شاملlast-modified ،ETag، Cache-Control وانقضای کش میشود. برای حل این مشکل مقاله Specify a cache validator وب سایت سئوراز را بررسی کنید.
قسمت بعدی ابزار تست سرعت Pingdom مربوط به کدهای پاسخ میباشد. کدهای پاسخ یا کدهای وضعیت HTTP مانند یک نکته کوتاه وضعیت صفحه وب را به شما نمایش میدهند. هر کد نشانگر وضعیتی است که هنگام ارسال درخواست توسط مرورگر، سرور پاسخ میدهد.در زیر به بعضی از کدهای رایج میپردازیم :
بخشهای بعدی که قصد داریم به آن بپردازیم حجم محتوا بر اساس نوع آنها و همچنین درخواستها بر اساس نوع محتوا میباشد. با استفاده از هر قسمت این بخش میتوانید متوجه شوید که هریک از ساختار وب سایت شما چه مقدار حجم دارند و چه مقدار از درخواستها مربوط به یک ساختار میشود.
با مراجعه به آخرین HTTP Archive متوجه میشویم که ۶۴ درصد صفحات وب را تصاویر تشکیل دادهاند. این موضوع را معمولا در بیشتر جاها مشاهده میکنیم. ولی در مورد زیر متوجه میشوید که همیشه هم اینطور نیست. در نمونه زیر نزدیک به ۴۶ درصد از ساختار به دسته Other یا دیگر اختصاصی داده شده است که بیشتر این ساختار مربوط به فونتهای گوگل و font awesome میباشد. فونتهای وب در بخش دیگر تست Pingdom قرار میگیرند.
راه دیگری که میتوانید به جای استفاده از تصاویر استفاده کنید، استفاده از فونت آیکونها مانند فونت Awesome به جای تصاویر می باشد. این استفاده میتواند به مقدار قابل ملاحظهای در حجم وب سایت شما موثر باشد.
بخش حجم محتوا (Content size by domain) و درخواست نسبت به دامنه (Requests by domain) یکی از بهترین راهها برای یافتن ساختارهاییست که خارج از وب سایت شما لود میشوند.
در مثال زیر شما مشاهده میکنید که ما همه ساختار وب سایتمان را از CDN لود میکنیم. سپس یک فایل HTML وب سایت میماند که از خود وب سایت لود میشود و یک لینک خارجی نیز به وب سایت Google Analytics متصل شده است. بسته به نوع وب سایت، شما ممکن سرویسهای خارجی مختلفی اعمم از فیسبوک، اینستاگرام، توییتر، تلگرام، تبلیغات و غیره را به وب سایت خود متصل کنید.
به طور کلی، هرچه درخواستهای خارجی وب سایت شما کمتر باشد، بهتر است. زیرا، هر درخواست خارجی در لیتنسی (latency) شما تاثیر میگذارد، مرورگر باید DNS اش را بررسی کند، TLS را به تاخیر میاندازد وغیره. پس بهتر است که درخواستها را تاجای ممکن کوتاه کنیم و ساختارها را از یک سرور فیزیکی یا CDN لود کنیم. یکی از بهترین مثالها فونت Awesome میباشد. بهجای اینکه بیاییم و از لینک خارجی آن را لود کنیم بهتر است که مستقیم آن را دانلود کنیم و از سرور خودمان لود کنیم، ما در مقاله رفع ارور Reduce DNS lookups به شکل بسیار کاملی درباره این موضوع پرداختیم.
و بالاخره، چارتهای آبشاری ساخته شده از هر درخواست میباشد که در زیر مشاهده میکنید. شما توسط این چارت میتوانید تمامی درخواستهایی که باعث کاهش سرعت و ایجاد مشکل در عملکرد وب سایت شما شده اند را مشاهده کنید. این دقیقا همان تحلیل آبشاری است که قبلا در رابطه با آن صحبت میکردیم. در زیر به توضیح جامعی در رابطه با هر یک از رنگهای موجود در چارت آبشاری میپردازیم.
DNS چیست؟ خب، فکر کنم شبیه یک دفتر تلفن بتوانیم آن را بیان کنیم. در شبکه به آن نام سرور دامنه (Domain Name Server) میگویند که در خود تمامی اطلاعات مربوط به سرور وب سایت و آی پی سرور را در خود نگهداری میکند. هنگامی که شما در Pingdom وب سایت خود را بررسی میکنید، این وب سایت در ابتدا به سرعت شروع به بررسی DNS وب سایت شما میکند و کوئریهای مربوط به دریافت اطلاعات IP شما را ایجاد میکند. این بررسی در بعضی اوقات طولانی مدت طول میکشد و این به فرآیند DNS lookups گویند.
هنگامی که وب سایت خود را چند بار توسط Pingdom بررسی میکنید، این ابزار DNS شما را در خود کش کرده و به علت اینکه IP شما ثابت است دیگر نیازی ندارد که دوباره DNS شما را بررسی کند. به همین دلیل است که هنگامی که شما چندین بار وب سایت خود را بررسی میکنید افزایش سرعت را مشاهده میکنید. همانطور که در تصویر زیر مشاهده میکنید ما بعد از انجام آزمایش دوم از وب سایت دیگر لود شدن DNS را مشاهده نمیکنیم و زمان لود DNS به 0 میلیثانیه تغییر کرده است که قبلا ۳۳ میلیثانیه بود. این یکی از موردهاییست که بعضی از افراد اشتباه تفسیر میکنند و احساس میکنند که اصلا DNSلود نشده است درحالی که اینطور نیست و DNS به صورت کش شده لود شده است.
دلایل دیگری نیز وجود دارد که ممکن است وب سایت شما پس از چند بار آزمایش سریعتر لود شود و یکی از آنها استفاده ازCDN میباشد. برای آن دسته از کاربرانی که با CDN آشنا نیستند پیشنهاد میشود که مقاله ما در رابطه با CDN را مطالعه کنند. هنگامی که برای بار اول توسط Pingdom وب سایت را بررسی میکنید اطلاعات توسط CDN بررسی میشوند و سپسCDN دقیقا همانند DNS اطلاعات را کش میکند و در بار دوم دیگر سرعت به خاطر لود اطلاعات درون CDN پایین نمیآید.
همچنین راه دیگری نیز برای لود سریع وب سایت از طریق DNS میباشد که از متد DNS prefetching استفاده کنید. با اینکارDNS های وب سایت شما در پسزمینه لود میشوند. شما میتوانید با اضافه کردن چند خط به بخش Header پوسته وردپرس خود این متد را فعال کنید. به کدهای زیر توجه فرمایید :
یا اگر از نسخه وردپرس بالای ۴.۶ استفاده میکنید، میتوانید از ترفندهای منابع منتشر شده کمک بگیرید. توسعه دهندگان با استفاده از متد wp_resource_hints میتوانند با اضافه کردن دامنهها و لینکهای جدید، dns-prefetch، preconnect، prefetch و یا prerender را در پسزمینه وردپرس لود کنند.
رنگ وضعیت بنفش زمانی ظاهر میشود که شما در وب سایت خود از SSL/TLS handshake استفاده کرده باشید. وقتی شما وب سایتی را با پروتکل HTTPS لود میکنید متوجه میشوید که آن وب سایت گواهینامه SSL دارد و برای کدگذاری اطلاعات شما و حفظ امنیت شخصی شما زمانی را صرف میکند. در تست زیر ما هم در سرور خود و هم در CDN از گواهینامه SSLاستفاده میکنیم. بنابراین زمانی را در ابتدا برای کدگذاری اطلاعات شما بر روی سرور برای جلوگیری از دزدی اطلاعات، به زمان لود صفحه اضافه میشود.
در گذشته اگر وب سایتی از گواهینامه SSL استفاده میکرد و باید برای ورود از پروتکل HTTPS استفاده میکردیم، لود آن وب سایت عذاب آور میشد ولی حالا خوشبختانه با وارد شدن نسل جدیدی از پروتکل به نام پروتکل HTTP/2 زمان لود صفحاتHTTPS ناچیز شده است. در حال حاضر بیشتر مرورگرها از پروتکل HTTP/2 پشتیبانی میکنند و از نظر من با توجه به پیشرفت روز به روز اطلاعات تعداد کاربرانی که از آخرین نسخه مرورگرها استفاده نمیکنند ناچیز است پس این پروتکل HTTP/2 کمک موثری به لود وب سایت شما میکند. همچنین باید توجه داشته باشید که همه ارائه دهندگان میزبانی و CDNاز پروتکل HTTP/2 پشتیبانی نمیکنند و شما باید توجه فرمایید، در صورتی که به HTTPS نیازمندید باید به دنبال ارائه دهندگانی باشید که از پروتکل HTTP/2 پشتیبانی میکنند. خوشبختانه سئوراز در طراحی سایت برای شما از سرورهای معتبری استفاده میکند که همه از پروتکل HTTP/2 پشتیبانی کامل میکنند.
توجه داشته باشید که پروتکل HTTP/2 از نسخه ۴۹ به بعد کروم فعالسازی شده است و نسخه کرومی که Pingdom برای تست استفاده میکند ۳۹ میباشد، بنابر این درصورتی که از این ابزار برای بررسی سرعت لود وب سایت خود استفاده میکنید ممکن است نتایج نمایشی تمامی تاثیرات پروتکل HTTP/2 را به شما نمایش ندهد ولی مطمئن باشی، در صورتی که کاربران از نسخه بروز کروم استفاده کنند، سرعت قابل ملاحظهای را احساس خواهند کرد.
زمان اتصال در Pingdom به اتصال TCP یا کل زمان لازم برای ایجاد اتصال TCP مربوط میشود.شما نیازی نیست که خیلی در این رابطه اطلاعات داشته باشید ولی به صورت خیلی ساده این بخش مربوط به سرعت اتصال کاربر به سرور شما میباشد.
زمان انتظار به مدت زمان لازم برای دسترسی مرورگر کاربر به اولین بایت از صفحه شما گفته میشود و در اصطلاح به آن TTFB نیز میگویند. TTFB نوعی اندازهگیری از واکنشپذیری سرور ویا دیگر شبکهها میباشد.به طور کلی، هر زمانی زیر 200 میلیثانیه برای TTFB عالی است. اگر به بالای 800 میلیثانیه رسیدید، باید در کانفیگ سرور خود مراجعه کنید و آن را بروزرسانی کنید و ومشکلات را حل کنید زیرا صد در صد مشکل در پیکربندی سرور میباشد و این چنین نتیجهای غیرعادی میباشد.
بهترین راه برای کاهش زمان TTFB چیست؟ یکی از بهترین راههای کاهش زمان TTFB استفاده از CDN میباشد. در زیر سرعت ساخت سایت را با فعالسازی و غیرفعالسازی CDN بررسی کردیم تا نتیجه مطلوبی بدست آید.
در ابتدا بدون اتصال CDN به وبسایت، وب سایت را تست کردیم و همانطور که مشاهده میکنید TTFB وب سایت 136 میلیثانیه طول میکشد و وب سایت نیز در 1.45 ثانیه لود میشود.
سپس ما CDN را متصل کردیم و دوباره آزمایش را انجام دادیم. مشاهده میکنید که زمان لود وب سایت به 788 ثانیه و زمان TTFB نیز 37 میلیثانیه شده است.
البته علاوه بر CDN، داشتن یک هاست میزبانی خوب نیز در کاهش این زمان موثر است و پیشنهاد میشود علاوهبر تهیهCDN، یک هاست میزبانی خوب نیز تهیه کنید که این مشکل را نداشته باشید.
با توجه به اطلاعات بالای شما عزیزان فکر نکنم توضیحات زیادی برای توجیح دو وضعیت دریافت و ارسال نیاز باشد. به طور کلی وضعیت ارسال(Send) به معنای زمان لازم برای ارسال درخواست از مرورگر به سرور میباشد. همچنین دریافت(receive) نیز زمان لازم برای دریافت اطلاعات توسط مرورگر از سرور میباشد. هردوی اینها زمان خیلی کمی لازم دارند و تاثیر زیادی بر روی آزمایش شما نمیگذارد.
هنگامی که در حال بررسی چارت آبشاری هستید، میتوانید هر یک از دادههای جدول را نسبت به پاسخهای سربرگ HTTP(یا همان درخواست HTTP Headers) بررسی کنید.
در این بخش اطلاعات ارزشمندی قرار دارد. در نمونه زیر شما متوجه میشوید که محتوا توسط متد فشردهسازی gzip بهینه سازی شدهاند، کش در وب سایت فعال است (HIT به معنای فعال و Miss به معنای غیر فعال) ، نوع محتوا از نوع html و یونیکد از نوع UTF-8 میباشد و غیره…
حالا اگر مقاله تحلیل آبشاری توسط Pingdom من را به صورت کامل بررسی کردید، حالا وقت آن است که دست به کار شوید و مشکلات وب سایت خود را حل کنید. در بیشتر وقتها دیدن آموزشها بدون در نظرگیری اطلاعات کامل در رابطه با محصول مورد مطالعه آزار دهنده است و در بیشتر سایت ها رعایت نمیشود. بنابراین در زیر اطلاعات پیکربندی وب سایت مورد مطالعه این مقاله را قرار میدهیم و شما با در نظرگیری آنها میتوانید یک وب سایت پرسرعت را داشته باشید.
در زیر تمامی افزونههای استفاده شده در این وب سایت را مشاهده میکنید که بیشتر آنها به صورت رایگان از مخزن وردپرس قابل دریافت میباشند.
نکته : بعضی از افزونههایی که در وب سایت استفاده شده است خیلی کوچک بوده و با چند کد جاوااسکریپت هم میشود که آنها را فعال کرد ولی با توجه به سادگی و حجم کم از این افزونه استفاده شده است.
در حال حاضر، شما با Pingdom بیشتر آشنا شدید و میدانید که در تحلیل آبشاری Pingdom هر قسمت چه معنایی دارد و برای حل مشکلات چهکار باید کرد. در تحلیلهای آبشاری خیلی مهم است که شما دلیل اتفاق افتادن هر قسمت را بدانید و با نحوه حل مشکل آشنا باشید.
اگر با نکته جدیدی در Pingdom مواجه شدید و یا پیشنهادی در رابطه با ارائه مقالهای جامع در رابطه با بخشهای مختلف سئو و بهینه سازی داشتید با ما از طریق بخش دیدگاه درمیان بگذارید. همینطور میتوانید به جای استفاده از این سایت از ابزار GTmetrix استفاده نمایید.
تحلیل عملکرد وب سایت، یکی از کارهای اساسی است که ما در پروژه های افزایش سرعت سایت انجام میدهیم. یکی از راههای ارزیابی و کشف کندی وب سایت، بررسی تک تک درخواست ها است که به اصطلاح به آن تجزیه و تحلیل آبشاری یا به انگلیسی Waterfall Analysis گفته میشود. ابزارهای فراوانی برای این امر وجود دارند که از جمله آنها میتوان به Chrome DevTools ، WebPage Tools ، Pingdom و GTmetrix اشاره کرد که استفاده از این ابزارهای سئو در درک و نحوه کارکرد طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی، ساخت سایت) در دقیق مشخص کردن مشکلات میتواند بسیار کارگشا باشد چرا که این نمودار آگاهی ارزشمندی درباره چگونگی تاثیر گذاری فایلهای پیوست شده (asset) روی سرعت صفحات و تجربه کاربری به شما میدهند. درواقع تجزیه و تحلیل آبشاری همان تجزیه و تحلیل سرعت سایت میباشد.
البته ما در سایت سئوراز بارها از تجزیه و تحلیل آبشاری در ابزارهای آنلاین مختلف استفاده کردهایم، در پست بررسی سرعت با ابزار Pingdom درباره تجربه و تحلیل آبشاری (چارت آبشاری) این ابزار به خوبی اشاره شد، در دوره جامع بهینه سازی سرعت سایت به شکل بسیار جامع درباره تجربه و تحلیل آبشاری سایت Gtmetrix کار شد و همچنین در این پست قصد داریم به تجزیه و تحلیل آبشاری موجود در Chrome DevTools بپردازیم.
سرفصلهای پست
نمودار آبشاری که به عنوان گراف آبشاری و هم چارت آبشاری نیز شناخته میشود، ارائه بصری از نحوه بارگذاری عناصر در وب سایتتان ارائه میدهد. این عناصر شامل CSS، JavaScript، HTML، تصاویر، پلاگین ها، فونتها و … میشوند. نکته مهم دیگر این است که نمودارهای آبشاری به شما اجازه مشاهده ترتیب رندر شدن عناصر در مرورگر را میدهند. از آن جا که این عناصر میتوانند شامل موارد مختلفی باشند از جمله بلاک های CSS تا مشکلات FOIT ، ترتیب بارگذاری از اهمیت زیادی برخوردار است که در ادامه به آن اشاره خواهیم کرد.
ابزارهای تست آنلاین سرعت سایت بسیاری وجود دارند که میتوانید برای ایجاد نمودار آبشاری از آن ها استفاده کنید. در زیر یک نمودار آبشاری معمولی را مشاهده میکنید که با ابزار خوده گوگل کروم یعنی Chrome DevTools ایجاد شده است.
گاهی تمامی رنگ ها، خطوط و ستونها به صورت یک جا میتوانند گیج کننده باشند. در ادامه به بعضی از مهمترین قسمت های نمودار آبشاری میپردازیم. علاوه بر زمان کلی بار گذاری موارد بیشتری در نمودار آبشاری وجود دارند. همچنین به یاد داشته باشید بسته به نوع مرورگر یا ابزاری که استفاده می کنید، نام ویژگی های زیر ممکن است متفاوت باشند که ما در پستهای قبلی برخی از آنها را اشاره کردهایم.
هنگام دسترسی به یک صفحه وب، مرورگر تمام منابعی که نیازمند DNS Lookup هستند و باید تا زمان تکمیل lookup منتظر بمانند را شناسایی میکند. DNS lookup مبتنی بر hostname ها می باشد. به عنوان مثال، اگر Google Analytics را در وب سایتتان اضافه کنید، نه تنها برای دامنه شما DNS lookup انجام می دهد بلکه برای google-analytics.com نیز این کار را انجام میدهد.
پست ما درباره چگونگی کاهش DNS lookup را حتما مشاهده کنید چرا که در این قسمت به شکل کامل به DNS Lookup پ نحوه کاهش آن بحث کردیم.
کاهش DNS Lookup کمک بزرگی به بهبود سرعت سایت میکند، به همین دلیل است که همواره توصیه میشود عناصر واسطه بیشتری را روی CDN قرار دهید زیرا این کار درخواست های DNS lookup را کاهش میدهد. همچنین باید توجه داشته باشید که در ابزارهای زیاد، اگر تست های سرعت را چندین بار اجرا کنید، آنها DNS را cache می کنند، به این معنی که این اطلاعات را در تست های بعدی مشاهده نخواهید کرد. اما lookup همچنان برای بازدیدکنندگان جدید که وارد سایت شما می شوند انجام میشود. سایت WebPageTest که از نگاه بنده بهترین ابزار برای آنالیز درخواست های http و همینطور تجزیه و تحلیل آبشاری سایت هست، برای رفع این مشکل راه حل مناسبی به نام First View و Repeat View دارد. از این طریق می توانید تصویر کلی بهتری را مشاهده کنید.
همچنین می توانید از resource hint هایی مانند DNS prefetching استفاده کنید که به مرورگر امکان انجام DNS lookup در یک صفحه در پس زمینه در حالی که کاربر در حال استفاده از مرورگر است را میدهد. این امر باعث کاهش latency یا همان تاخیر در DNS lookup در زمان کلیک کاربر روی یک لینک انجام میشود. مثال زیر را مشاهده کنید:
ارتباط اولیه که با عنوان ارتباط TCP و ارتباط در بعضی ابزارها شناخته میشود، مجموع زمان مورد نیاز برای ایجاد یک ارتباط TCP است. این مورد برای ایجاد یک ارتباط بین یک کاربر یا هاست محلی و سرور استفاده میشود و روشی سه مرحله ای میباشد که نیازمند کاربر و سرور به منظور تبادل بسته ها قبل از شروع تبادل اطلاعات است.
کاهش زمان TCP کمی دشوارتر است. بهترین نقطه برای شروع این است که مطمئن شوید روی یک هاست وب سریع با تاخیر پایین سایت شما پیاده شده است. این handshake با ارسال داده از طرف کاربر در حین SYN اتفاق میافتد، بنابراین به ارتباط ها امکان جایگزینی در حین handshake را میدهد.
همچنین preconnect را فراموش نکنید که به مرورگر اجازه میدهد ارتباطهای ابتدایی را قبل از ارسال واقعی درخواستHTTP به سرور ایجاد کنید.
SSL، که در بعضی ابزار ها به عنوان SSL negotiation نیز معرفی میشود، زمان کلی مرورگر برای اجرای SSL/TLS handshake میباشد. مشخصاً این را زمانی مشاهده میکنید که CDN و یا هاست شما روی HTTPS فعال باشد.
در زیر تعدادی روش برای افزایش سرعت سایت هایی که روی HTTPS اجرا می شوند آورده شده است.
TTFB که خلاصه time to first byte است، مقدار زمانی است که طول میکشد تا یک کاربر یک درخواست HTTP ایجاد کرده و اولین بایت داده را از وب سرور دریافت کند. در Pingdom این مورد به عنوان زمان انتظار یا wait time شناخته می شود. TTFB یک جنبه مهم از بهینه سازی سئو سایت است زیرا هرچه TTFB سریعتر باشد، منبع درخواستی سریعتر به مرورگر ارسال میشود. به طور میانگین هر چیزی با TTFB کمتر از 100 میلی ثانیه فوق العاده است. هرچیزی با میانگین TTFB 200 تا 500 میلی ثانیه استاندارد است و بین 500 میلی ثانیه تا 1 ثانیه کمتر از ایده آل و هرچیزی با TTFB بزرگتر از 1 ثانیه احتمالاً باید مورد بررسی قرار گیرد. نکات تکمیلی و جالب درباره TTFB را حتما در مقاله TTFB چیست بخوانید.
یکی از راه های ساده بهبود TTFB پیاده سازی caching روی سرور است. به عنوان مثال، اگر از وردپرس استفاده می کنید، پلاگین WordPress Cache Enabler می تواند یک فایل Cache استاتیک در قالب HTML روی سرور شما ایجاد کند. این مورد به کاربران اجازه میدهد تا از فرایند فشرده سازی منابع جلوگیری کنند، بنابراین صفحه با TTFB سریعتری تحویل داده میشود.
و البته استفاده از CDN نیز به شدت می تواند TTFB شما را بهبود دهد.
در اینجا مثالی از آزمایش TTFB بدون استفاده از CDN را مشاهده میکنید.
در ادامه مثال قبل را با استفاده از CDN تکرار کردیم.
همانطور که مشاهده می کنید، با استفاده از CDN مقدار TTFB به نصف کاهش پیدا کرد. البته بسته به موقعیت سرور و POPها این موارد متفاوت خواهند بود. از جمله راه های دیگر برای افزایش سرعت TTFB می توان به روز بودن Nginx و Apache و همچنین مدیریت منابع سرور از جمله CPU و IO و همینطور اسکریپت و پلاگینهای نصب شده اشاره کرد.
دانلود محتوا دقیقاً به همان صورتی است که از اسمش به نظر میآید، این مورد مدت زمانی است که طول میکشد تا محتوای مورد نظرتان را دانلود کنید. هرچه asset ها و اندازه فایل ها بزرگتر باشند، زمان بیشتری طول خواهد کشید.
هنگامی که درباره زمان دانلود محتوا صحبت میکنیم فشرده سازی تصویر نقش بزرگی در این مورد ایفا می کند. طبق HTTP Archive، از ژوئن 2017 تصاویر به طور متوسط 61% از حجم وب سایت ها را به خود اختصاص می دهند. مقالات جامع ما درباره بهینه سازی عکس میتواند بسیار به شما کمک کند
و البته استفاده از CDN می تواند یکی از آسان ترین راه ها به منظور کاهش زمان دانلود محتوا باشد، زیرا از این طریق محتوا را از POP های نزدیک به کاربران به آن ها عرضه می کنید. استفاده از CDN باعث کاهش TTFB نیز می شود.
از راه های دیگر به منظور کاهش زمان دانلود می توان به استفاده از javascript و css تنها در موارد مورد نیاز و فشرده سازی با Gzip اشاره کرد.
DOM مخفف Document Object Model می باشد. هنگامی که از inspector کروم یا فایرفاکس استفاده میکنید تبی دارد به نام elients در واقع این تب در حال مشاهده نمایه بصری از DOM هست، Chrome DevTools پس از دستکاری در صفحهDOM را با HTML یا javascript نمایش میدهد. همچنین می توانید به آن به عنوان HTML تجزیه شده نیز نگاه کنید.
هنگامی که به بررسی سرعت صفحات وب سایت می پردازیم، همواره باید مواردی که ممکن است DOM را مسدود کنند و باعث ایجاد تاخیر در زمان بارگذاری میشوند را در نظر داشته باشید. این موارد به عنوان render blocking resources در نظر گرفته میشوند، مانند HTML، CSS و جاوا اسکریپت. بیشتر ابزارهای تست سرعت سایت مجموع محتوای DOM را نمایش می دهند در حالیکه این زمان با زمان کلی بارگذاری متفاوت است.
Load Time که با عنوان Fully Loaded نیز در بعضی ابزار ها شناخته میشود، زمان کلی پایان دانلود، رندر و نمایش به کاربر است. این مورد از معیارهای بسیار مهم است که باید مورد توجه قرار گیرد چرا که این زمان در Devtools واقعی تر از ابزارهای تست آنلاین است، به این علت که ابزارهای تست سرعت سایت لوکیشن ایران را ندارند و شما میتوانید با مرورگر خود یک ابزار تست سرعت سایت در ایران باشید.موارد متعددی وجود دارند که می توانید با انجام آن ها سرعت بارگذاری را افزایش دهید.
Data Transferred در Devtools کروم (دیتا انتقال داده شده)، که در WebPageTest به عنوان Bytes In شناخته میشود، و در Pingdom به عنوان Page Size، اندازه کلی تمامی asset ها (تمام فایلهای پیوست شده در سند html) در صفحه وب می باشد. هرچه این مقدار کوچکتر باشد، بهتر است. توصیه های ما درباره کاهش زمان بارگذاری محتوا که در بالا آورده شد را دنبال کنید و در عوض Data Transfered وب سایت شما کاهش پیدا میکند.
تا سال 2016 متوسط اندازه صفحه، کمی بیشتر از 2 مگابایت بود که بسیار بزرگ است. اندازه صفحه وب از سال 2010 تا 2016 317% افزایش یافته و به مقدار 1530 کیلو بایت رسیده است. پیشنهاد می کنیم حداقل 1 مگابایت یا کمتر برای اندازه صفحه وب سایت خود در نظر بگیرید. اگرچه این امر در تمام محیط ها امکان پذیر نیست.
درخواستها مجموع کلی درخواست های HTTP تولید شده در وب سایت شما را نشان می دهند. هر فایل پیوست شده (CSS، JavaScript، Image) درخواست مربوط به خود را تولید میکند. در مجموع هرچه درخواست های HTTP صفحه شما بیشتر باشد، زمان بارگذاری هم طبیعتا بیشتر میشود.
روش های زیادی برای کاهش تعداد درخواست ها وجود دارند که می توان به موارد زیر اشاره کرد:
ولی اگر قصد دارید اطلاعات بیشتر و کامل تری درباره درخواست های http و نحوه کاهش این درخواست ها کسب کنید مقاله رفع خطای Make fewer HTTP requests ما را حتما مطالعه نمایید.
کدهای وضعیت یا همان Status Codes ، که با عنوان کدهای خطا (Error) و کدهای پاسخ سرور (Server Response Codes) نیز شناخته میشوند، پیام هایی هستند که شامل اطلاعات کامل وضعیت ها درخواست بین کاربر و سرور می باشند. کاربر درخواست خود را به یک سرور HTTP ارسال می کند که میزبان یک وب سایت است، سپس سرور پیام پاسخ را در قالب یک کد بازمی گرداند.
اگر مشکلی در یک درخواست HTTP باشد، لیستی از کدهای وضعیت وجود دارد که مرورگر شما را با استفاده از آن مطلع می سازد تا بتوانید منبع مشکل را پیدا کنید. روشی که مرورگر پاسخ را مدیریت میکند بسته به کد و فیلد header پاسخ دارد. به عنوان مثال، خطای Not Found 404 بدان معناست که محتوا دیگر وجود ندارد یا حذف شده است.
همانطور که مشاهده می کنید، ابزارهایی مانند Chrome DevTools، WebPageTest ، Pingdom و GTmetrix انواع مختلفی از اطلاعات ارزشمند درباره چگونگی بارگذاری صفحات و دلایل تاخیرها فراهم میکنند. درک معنای هر قسمت از داده ها می تواند در عیب یابی و تشخیص مشکلات اجرایی سایت کمک کند. توجه داشته باشید که بهینه سازی سرعت سایت تاثیری مستقیم بر روی افزایش رتبه سایت در گوگل و سایر موتورهای جستجو دارد و جدا از این مورد اثری حیاطی بر روی تجربه کاربری و رضایت بازدیدکنندگان نیز دارد.
امیدواریم این مقاله برای شما مفید بوده باشه و دفعات دیگری که تجزیه و تحلیل آبشاری (Waterfall Analysis) انجام میدهید، خوشبختانه بعضی از نکته های ذکر شده در بالا می توانند به شما کمک کنند.
راههای مختلفی برای بهینه سازی وب سایت وردپرسی شما موجود است که ممکن است برخی از آنها مهمتر از دیگر راهها باشند. یکی از فاکتورهای مهمی که اغلب نادیده گرفته میشود، کاهش زمان لود DNS Lookups (جستجوهای DNS) میباشد. همانند TTFB و لیتنسی (latency) که قبلا درباره آنها صحبت بسیار کرده بودیم، زمان لود DNS Lookups نیز در دستیابی به اولین اطلاعات وب سایت بسیار موثر است. بنابراین امروز تصمیم گرفتیم که به نحوه کاهش زمان لود DNSLookups و افزایش سرعت آنها بپردازیم و با هم به دلیل اهمیت بالای این فاکتور در سرعت وب سایت پیببریم. توضیحات بیشتر درباره TTFB در مقاله بهبود زمان TTFB بخوانید.
سرفصلهای پست
برای فهمیدن اینکه منظور ما از DNS Lookups یا جستجوهای DNS چیست، ابتدا باید با روش کار اصلی DNS آشنا شوید. به طور کلی DNS مخفف کلمه Domain Name Systi و به معنای سامانه نام دامنه میباشد که اساسا به ستون فقرات اینترنت معروف است.دفترچه یادداشتی برای تمام جهان. تمامی طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی، سئو سایت) ها و دامنههایی که شما در اینترنت مشاهده میکنید به طور مشخصی به یک IP Address مرتبط میشوند.
برای مثال هنگامی که آدرس Google.com را در اینترنت وارد میکنید، کوئریهای DNS توسط ISP شما برای دریافت اطلاعات مشخص مرتبط به نیم سرورها درخواست میشوند. سپس جمعآوری اطلاعات دامنه توسط IP در پشت صحنه سرور انجام میشود که شما با توجه به اختصاصی بودن IP آدرس وب سایت گوگل شما میتوانید با آی پی 216.58.217.206 نیز وارد این وب سایت شوید. ورود با ای پی آنقدری که به نظر میرسد هم سرگرم کننده نیست.
هنگامی که شما درخواست ورود به یک وب سایت را وارد میکنید اولین چیزی که ISP شما از سرور مقصد درخواست میکند درخواست ارائه اطلاعات DNS وب سایت میباشد. اما در نظر داشته باشید که نیازی نیست برای هر منبعی دوباره DNSجستجو شود. برای مثال به درخواستهای HTTP زیر توجه کنید:
با توجه به اینکه ۸ درخواست HTTP در بالا وجود دارد، با این حال، با توجه به اینکه ۳ دامنه در درخواستها وجود دارد، ۳ جستجو برای اطلاعات DNS لازم است.
اگر نیاز به توضیحات بیشتر و سادهتر درباره نحوه کار DNS Lookups دارید مقاله رفع خطای Reduce DNS lookups را مطالعه فرمایید.
در زیر به نحوه نمایش درخواستهای بالا در ابزار تست سرعت در ساخت سایت Pingdom میپردازیم. DNS در تحلیل آبشاری به رنگ صورتی میباشد و تحلیل سرعت آن به صورت میلی ثانیه است. وقتی برای اولین بار وب سایتتان را در Pingdom مورد ارزیابی قرار میدهید، این وب سایت به صورت کامل اطلاعات IP آدرس و دیگر کوئریهای DNS شما را دریافت و بررسی میکند. توجه کنید که لازم نیست برای هر ارزیابی برای مثال دامنه cdn.wpdev.ink شروع به ارزیابی DNSها کنید. این دقیقا کاری است که DNS میکند، برای هر دامنه کافیست که تنها یک بار آن را لود کنید. در بالا ۸ درخواستHTTP موجود است که از بین اینها تنها ۳ درخواست DNS لازم است.
برای هر بار بررسی DNS ها توسط مرورگر و سرور زمان اضافه ای به لود وب سایت اضافه میشود و هیچ اطلاعاتی قبل از بررسی کامل DNS لود نمیشوند.
برای مثال در بررسی ۳ DNS بالا ، یکی از ۳ DNS برای بررسی ۳۰۰ میلی ثانیه زمان گرفته است که این زمان بدون در نظر گیری زمان لازم برای بررسی DNS دیگر دامین هاست. بنابر این تاثیر بررسی DNS را بر روی سرعت میتوانید کاملا واضح مشاهده کنید.
هنگامی دوباره وب سایت خود را با Pingdom مورد ارزیابی قرار میدهید، متوجه میشوید که اطلاعات DNS در Pingdom کش شدهاند و دیگر نیازی به لود دوباره آنها نیست. این یکی از دلایلی است که پیشنهاد میشود وب سایت خود را چندین بار در Pingdom مورد ارزیابی دقیق قرار دهید. همانطور که در زیر مشاهده میکنید زمان لود DNS در تصویر زیر 0 ثانیه شده است. این بخش، بخشی است که بیشتر مردم آن را اشتباه در نظر میگیرند اما نگران نباشید، ما در رابطه با کش شدن DNSبیشتر صحبت خواهیم کرد.
به طور کلی هر وب سایت بررسی سرعت نوع بررسی خاص خود را دارد ولی بیشتر آنها سرعت بررسی DNS ها را به شما میگویند. در زیر نحوه نمایش زمان بارگیری اطلاعات DNS را در GTMetrix مشاهده میکنید. DNS ها به رنگ سبز و بر اساس میلی ثانیه مشخص شده اند.
ابزار بررسی سرعت وب سایت WebPageTest نیز یک ابزار بسیار دقیق و کارآمد در حوزه بررسی DNSها و تجزیه و تحلیل نمودار آبشاری برای سایت میباشد که در صورت علاقه میتوانید از این وب سایت نیز استفاده کنید و به علت تعداد سرورها در سراسر جهان و همچنین آنالیز کلی تمامی اطلاعات وب سایت کاربر بسیار معروف شده است. اطلاعات مربوط به زمان لود DNS در این ابزار در ستون DNS Lookup و با واحد اندازه گیری میلیثانیه قرار میگیرد. برای مثال ما یک وب سایت خبری را به صورت تصادفی انتخاب کردیم و پس از انجام عملیات بررسی توسط این ابزار زمان لود DNS به ۶.۵ ثانیه رسید!
متاسفانه در بیشتر وب سایتهای خبری، بهینه سازی صورت نمیگیرد و درخواستهای خارجی وب سایتها بسیار زیاد است. با این حال، همانطور که مشاهده میکنید وب سایت خبری مورد مطالعه ما خیلی بیشتر از مقدار قابل قبول لود DNS از نظر کاربران برای لود این فاکتور زمان نیاز دارد. برای همین است که میگوییم DNS ها خیلی اهمیت دارند، زیرا ممکن است باعث کندی بیش از حد و حتی قطعی وب سایت شما شوند.
در رابطه با نحوه کار DNS ها اطلاعات کاملی به دست آوردید. حال وقت آن است که به نحوه کاهش زمان لود و افزایش سرعت DNS Lookups بپردازیم، افزایش سرعت لود DNS Lookups اسم های مختلفی دارد همانند:
یکی از نکات مهم در DNS ها این است که DNS ها نیز مانند هاستهای میزبانی ارائه دهندگانی سریع و کند دارند. این اولین چیزی است که باید در وب سایتتان رعایت کنید.
به طور معمول DNS های ثبت شده توسط GoDaddy و NameCheap بسیار ضعیف عمل میکنند. ارائه دهندگان DNS نیز مانند CDN دارای POPs های مختلفی در جای جای جهان هستند. از بهترین و پر سرعتترین ارائه دهندگان DNS میتوانیم به amazon ، Cloudflare ، Dyn و DNS Made Easy اشاره کنیم. همه این ارائه دهندگان دارای زیرساختهایی وسیع برای سریعترین بازده میباشند.
ما با توجه به این موضوع شروع به بررسی تک تک ارائه دهندگان DNS کردیم که پس از بررسیهایمان متوجه شدیم که در ارائه دهندگان تجاری DNS سرعت تفاوت خاصی نمیکند ولی در ارائه دهندگان DNS رایگان به جز CloudFlare بقیه سرعت ضعیفی دارند. بنابراین اگر کسب و کار خیلی پر اهمیتی دارید پیشنهاد میشود که از یک ارائه دهنده DNS تجاری استفاده کنید.
بعضی از ارائه دهندگان بالا در مناطقی سریع تر از دیگری هستند و این خیلی مهم است که شما چگونه به بارگیری DNS نگاه میکنید، جهانی یا محلی؟
وب سایت DNSPerf ابزاری خوب برای مقایسه انواع ارائه دهندگان DNS میباشد و به شما کمک میکند که بهترین ارائه دهنده را انتخاب کنید. آیا میدانستید که شما میتوانید بدون استفاده از امکانات دیگر Cloudflare از بخش DNS آن استفاده کنید؟
خوشبختانه، با توجه به توضیحاتی که در بالا دادیم، پس از کش شدن DNS در مرورگر شما، دیگر نگرانی برای لود دوباره بررسیهای DNS در دیگر صفحات شما نیست و تنها کافیست که وب سایت شما برای اولین بار لود شود. کش شدن DNSدقیقا مانند کش شدن کامل وب سایت میباشد و تا زمانی که به تاریخ انقضای خود برسد در مرورگر باقی میماند. طول کش DNS از طریق چیزی با نام Time to live (زمان برای زندگی) که مخفف TTL هست، مشخص میشود. اگر TTL وب سایتی بالا باشد، مرورگر شروع به بررسی دوباره DNS میکند.
شما میتوانید ورودیهای TTL وب سایت خود را برای بهبود کش DNS تغییر دهید. قابل توجه است که ISP ها به صورت خودکار DNS شما را کش میکنند ولی با تغییر ورودیهای TTL میتوانید به این کش کمک کنید.
۳۰ دقیقه در هر ساعت برای TTL بیشتر از همه استفاده میشود. با این حال، بعضی از کاربران به علت بروزرسانی پی در پی وب سایتشان TTL کمتری استفاده میکنند. برای مثال Cloudflare به صورت پیشفرض TTL را بر روی ۵ دقیقه ذخیره کرده است. این خیلی خوب است که شما به رکوردهای دیگر خود نیز توجه کنید و نسبت به استفاده وب سایت آنها را تنظیم کنید. برای مثال :
به طور کلی وقتی در رابطه با TTL صحبت میکنیم جواب درست یا غلطی وجود ندارد. اما شما با کمی تغییر در ورودیهای TTL و آزمایش آن میتوانید به کش DNS کمک کنید.
یکی از بهترین راهها برای کم کردن زمان بررسی DNS ها کاهش تعداد درخواستها به دامنههای مختلف است یعنی به طور کلی کاهش تعداد دامنههای متصل به وب سایت است. زمان بررسی DNS ها به تعداد درخواستها آنقدری هم مهم نیست، مهم تعداد دامنهها است که هرچقدر کمتر باشد زمان بررسی DNS ها نیز کاهش مییابد. وب سایت خود را با یک ابزار مانند Pingdom بررسی کنید و درخواستهای مهم را مشخص کنید. با توجه به اینکه DNS ها بر اساس IP ها طراحی میشوند، شاید برای شما سوال شود که چرا مردم از دامنهها در DNS خود استفاده میکنند؟! حتما توجه داشته باشید که DNS های شما بر روی یک دامنه ست شده باشند زیرا آی پیها قابل تغییر هستند (مثلا با تغییر هاست) ولی دامنهها تغییر نمیکنند و همیشه خواهند ماند و برای کش کردن فایلها مناسبتر هستند.
درحالی که کم کردن تعداد دامنهها (hostnames) نسبت به این ترفند راحتتر است، با این حال، ما پیشنهاد میکنیم که ابتداDNS هایی که سرعت بررسی آنها بیشتر از بقیه طول میکشد را بیابید. برای مثال در وب سایت زیر یکی از فایلهای جاوااسکریپت لود شده از Crazy Egg برای لود DNS ۲۵۵ میلی ثانیه زمان لازم دارد که از بقیه DNS ها بیشتر است. این به علت این است که این وب سایت از یک ارائه دهنده DNS خوب استفاده نمیکند.
در این وضعیت شما میتوانید از سرویسهای جایگزین این سرویس مانند Hotjar که دقیقا همان کار را انجام میدهند استفاده کنید که هم از نظر سرعت لود DNS و هم از نظر کارایی بهتر از این سرویس عمل میکنند. این خیلی مهم است که وقتی شما افزونهای را به وردپرستان اضافه میکنید توجه داشته باشید که به عملکرد وب سایت شما آسیبی نمیزند.
یکی از راحتترین راههای موجود برای افزایش سرعت وب سایت خود این است که تا جای ممکن منابع خود را به ارائه دهندهCDN خود انتقال دهید. هنگامی که شما در Pingdom وب سایت خود را آزمایش میکنید میزان درخواستهای وب سایت خود را بر اساس هر دامنه را مشاهده میکنید. همانطور که مشاهده میکنید در زیر ۹۳.۸ درصد درخواستهای ما از CDN لود میشوند. یک درخواست از هاست خودمان و یک درخواست نیز از گوگل آنالیز میباشد. با انتقال منابع به CDN زمان بررسیDNS ها را به تنها یک DNS ارائه دهنده CDN محدود میکنید و سرعت آن را افزایش میدهید. در مقاله دلایل استفاده از CDN ما به شکل کامل توضیحات لازم را ارائه دادهایم.
به هر حال، وب سایت بالا یک وب سایت خاص بوده است ولی به طور کلی همیشه امکان انتقال اطلاعات به طور کامل به CDN وجود ندارد.
شما در بیشتر مواقع منابعی که نیاز است در سرورهای خارجی لود شوند را در CDN لود خواهید کرد. با این حال، ما پیشنهاد میکنیم که تاجایی که به وب سایتتان آسیب نرساند منابع را از CDN لود کنید. در بیشتر اوقات ما مشاهده میکنیم که کاربران وردپرسی بیشتر منابع خود را در هاست خود لود میکنند و CDN را نادیده گرفتهاند. با انجام این کار شما میتوانید از امکاناتHTTP/2 و parallelization نیز استفاده کنید.
در زیر به نکتههایی اشاره کردهایم که میتواند به شما در این مورد کمک کند.
ما در بیشتر وب سایتهای امروزی مشاهده میکنیم که از فونت Awesome به عنوان فونت آیکون در وب سایت خود استفاده میکنند. ولی مشکلی در استفاده از این فونتها وجود دارد این است که در بیشتر وب سایتهای وردپرسی به صورت کاملا مستقیم از هاست کاربر لود میشوند و کاربران بلد نیستند که آنها را از طریق CDN لود کنند ، در این مواقع پیشنهاد میکنیم که از افزونهای مانند CDN Enabler استفاده کنید.
یک راه دیگر استفاده از cdnjs ویا bootstrapcdn می باشد تا فایلهای فونت را از طریق CDN عمومی لود کنید
با توجه به اینکه با اضافه کردن لینک از طریق CDN های بالا یک رکورد به DNS های شما اضافه میشود پیشنهاد میشود کهCDN مخصوص خود را استفاده کنید. (cdnjs از سرورهای Cloudflare و Bootstrap CDN از سرورهای MAXCDN استفاده میکند)
اگر از وردپرس استفاده میکنید حتما با تصاویر کاربری پیشفرض آن یعنی Gravatars آشنا هستید. یکی از بهترین راهها برای خلاص شدن از زمان لود DNS های Gravatars استفاده از لود تنبل نظرات میباشد که در سئوراز آموزش فعالسازی آن را نیز منتشر کردهایم و میتوانید با مراجعه به پست لود تنبل تصاویر از آموزشهای عالی ما بهره ببرید. با این حال اینکار زمان لودDNS شما را کاهش نمیدهد و تنها لود آن را تا وقتی که کاربر تا بخش نظرات اسکرول کند به تاخیر میاندازد. بنابراین شما با اینکار در لود بخش اولیه وب سایت خود زمان لود DNS را کاهش دادهاید. پیشنهاد میکنم که حتما مقاله ما در رابطه با افزایش سرعت دیدگاههای وردپرس را مشاهده کنید.
با فونتهای گوگل شما یک درخواست اضافه برای لود استایلهای مخصوص فونتهای گوگل به وب سایت خود اضافه میکنید. سپس شما باید از طریق gstatic اقدام به دانلود فونتها کنید. سعی کنید که این نوع فونتها را در وب هاست یاCDN خود به صورت محلی لود کنید و از لود از طریق وب سایتهای واسطهای دیگر جلوگیری کنید. این کار مزایا و معایبی به همراه دارد ولی در کل به سرعت وب سایت شما بسیار کمک میکند.
فونت Awesome ، فونتهای گوگل و gravatars تنها نمونههایی از روشهای کاهش زمان لود DNS ها بودند. آیا شما سعی کردید که بیشتر منابع خود را از طریق CDN ها لود کنید؟
یکی دیگر از راههای کاهش زمان لود DNS، استفاده از DNS Prefetching میباشد. این امکان به شما کمک میکند تا DNS ها را در پسزمینه وب سایت خود لود کنید. این کار با اضافه کردن چند خط کد به وب سایتتان امکان پذیر است.به کدهای زیر توجه کنید :
فقط توجه کنید که DNS prefetch در بعضی از مرورگرها مانند Opera Mini پشتیبانی نمیشود ولی نگران نباشید، این پشتیبانی نشدن در عملکرد وب سایت شما تاثیری نمیگذارد ولی برای کاربرانی که از آن مرورگر استفاده میکنند DNS ها دیرتر لود میشوند.
یا اگر از نسخه وردپرس بالای ۴.۶ استفاده میکنید، میتوانید از ترفندهای منابع منتشر شده کمک بگیرید. توسعه دهندگان با استفاده از متد wp_resource_hints میتوانند با اضافه کردن دامنهها و لینکهای جدید، dns-prefetch، preconnect، prefetch و یا prerender را در پسزمینه وردپرس لود کنند.
اگر شما خواندن فایلهای جاوااسکریپت را به تاخیر بیاندازید آنها تا پایان لود کامل دیگر منابع سایت لود نخواهند شد. اینکار سرعت لود DNS Lookup را افزایش نمیدهد ولی باعث میشود که از بروزرسانی پی در پی آن جلوگیری شود. افزونه Varvy یکی از بهترین پیشنهادها برای بررسی تاثیر تاخیر انداختن لود جاوااسکریپت میباشد. نمونه فایل جاوااسکریپتی که بیشتر وب سایتها از آن استفاده میکنند فایل جاوااسکریپت گوگل آنالیز میباشد که نیازی نیست در هنگام لود شدن وب سایت، لود شود و کافیست که پس از لود وب سایت در پس زمینه لود شود.
در وردپرس افزونههایی مانند Async JavaScript وجود دارند که باعث به تاخیر انداختن لود جاوااسکریپت میشوند. با اینحال بعضی از اسکریپتها در لود وب سایت اهمیت دارند و باید شما قبل از فعالسازی تاخیر در لود آنها را پیدا کرده و در لیست پرش یا استثنا قرار دهید.
افزونه Async Javascript با افزونه Autoptimize نیز به صورت کامل همخوانی دارد و قابل ادغام است و یکی از بهترین پیشنهادها برای به تاخیر انداختن لود جاوااسکریپت میباشد.
البته این بحث به تاخیر انداختن لود جاوا اسکریپت به خطای asynchronous resources در GTmetrix هم برمیگردد که میتواند در آنجا به شکل کامل مطالعه نمایید.
در بعضی از ارائه دهندگان DNS رکوردهای اضافهای وجود دارد که میتواند سرعت لود DNS را افزایش دهد.
رکوردهای ANAME به شما عملکرد کلی رکوردهای CNAME را در سطح ROOT نمایش میدهند. برای مثال در نظر بگیرید که شما CNAME دامنه خود را به صورت www.domain.com پیکربندی کردهاید. ابتدا www. باید نام هاست نیم را پیدا کند و سپس به IP متصل شود. پس اینکار ۲ مرحله ایست. در ANAME مرحله اولیه CNAME حذف شده است و مستقیم به IPمتصل میشود که این باعث افزایش سرعت میشود. دقیقا مانند نمونه زیر :
به طور مشابه Cloudflare هم نوعی سرویس به نام CNAME مسطح دارد که دقیقا همان کار ANAME را انجام میدهد و دادهها را در سطح zone apex نمایش میدهد.
به طور کلی، DNS Lookups یکی از فاکتورهایی است که در بیشتر وب سایتها نادیده گرفته میشود ولی با اندکی توجه مدیر وب سایت میتواند به لود وب سایت خود کمک کند. فقط کافیست که بدانید DNS چطور کار میکند، ارائه دهندگان کند و سریعی برای DNS وجود دارد و یاد بگیرید که چگونه مشکلات بررسی DNS را حل کنید.
به طور کلی هنگامی که درباره سرعت سایت وردپرسی صحبت می کنیم، اکثر مواقع بر عملکرد front-end و بهینه سازی سرعت بارگذاری صفحه متمرکز می شویم. با این حال، گاهی بهتر است از سمت سرور که وبسایت شما در اصل از آنجا بارگذاری می شود، به این موضوع نگاه کنیم. امروز به تاثیر TTFB بر وطراحی سایت (طراحی سایت فروشگاهی، طراحی سایت شرکتی) شما و بحث درباره راه های راحتی به منظور کاهش آن می پردازیم. TTFB معمولا به عنوان یک از عوامل بهینه سازی نادیده گرفته می شود، اما در هنگام آزمایش سرعت سایت باید در نظر گرفته شود.
سرفصلهای پست
TTFB مخفف time to first byte است. به بیان ساده، اندازه گیری مدت زمانی است که مرورگر باید قبل از دریافت اولین بایت داده از سرور منتظر بماند. هرچه این مدت زمان دریافت داده بیشتر باشد، مدت زمان بیشتری طول میکشد تا صفحه برای بازدیدکننده نمایش داده شود. یکی از تصورات رایج غلط این است که TTFB پس از جستجوی DNS محاسبه میشود، با این حال، محاسبه TTFB در شبکه همیشه شامل network latency میباشد. 3 مرحله Process و Delay و Latency ممکن است در هرجایی در این بین رخ دهند و به مجموع کلی TTFB شما اضافه کنند.
هنگامی که کسی از وبسایت شما بازدید میکند، اولین چیزی که اتفاق میافتد، ارسال درخواست HTTP از کاربر به سرور است. در این مرحله، عوامل گوناگونی وجود دارند که در delay تاثیر دارند. زمان کند DNS lookup میتواند باعث افزایش زمان درخواست شود. اگر سرور از نظر جغرافیایی دور باشد، فاصله ای که داده باید بپیماید در latency موثر است. همچنین، اگر قوانین firewall پیچیده ای دارید، ممکن است زمان routing را افزایش دهد. و علاوه بر این موارد، سرعت اینترنت کاربر را فراموش نکنید.
پس از اینکه درخواست ارسال شد، سرور باید آن را پردازش کند و پاسخی تولید کند. این امر میتواند تعداد گوناگونی delay مانند فراخوانی آهسته پایگاه داده، اسکریپت های واسطه بیش از حد، ذخیره(cache) نشدن اولین پاسخ، کد یا قالبی که به طور مناسبی بهینه سازی نشده و منابع ناکافی سرور مانند disk I/O یا حافظه ایجاد کند.
بعد از اینکه درخواست توسط سرور پردازش شد، باید آن را به کاربر ارسال کند. این مرحله هم از سرعت شبکه سرور و هم از سرعت اینترنت کاربر تاثیر میگیرد. اگر سرعت اینترنت کاربر پایین باشد، بر TTFB تاثیر میگذارد.
بسیار مهم است که بدانید TTFB و سرعت وبسایت یکسان نیستند. بحثهای زیادی در حوزه وب وجود دارند که آیا TTFB مهم است یا نه. بعضی میگویند TTFB بی معنی است و بعضی دیگر میگویند اهمیت دارد. هر دو گروه دلایلی برای گفته خود میآورند و سوالاتی درباره نحوه محاسبه آن میپرسند.
حتی وبسایت Moz مطالعه گسترده ای درباره ارتباط بین رتبه بندی جستجو و TTFB انجام داد. با این حال، دانستن علت این موضوع یا اینکه ساخت سایت های با TTFB پایین تر سریعتر هستند، می تواند به نوبه خود توسط عوامل رتبه بندی صفحات گوگل تحت تاثیر قرار گیرد.
اما به جای صرف زمان روی اهمیت داشتن یا نداشتن آن در سئو، میتوانید برای بهبود این معیار مهم تمرکز کنید. هرکاری که انجام میدهید میتواند بر سرعت کلی سایت شما از هر نوع CMS که باشید (وردپرس، جوملا و …) شما تاثیر داشته باشد و این موضوع بر TTFB شما هم شاید تاثیر بگذارد. در آزمایش های انجام شده با TTFB زیاد، سرعت بارگذاری بسیار آهسته بود.
در کل، اگر سرعت بارگذاری زیر 100 میلی ثانیه باشد TTFB مناسب است. Google PageSpeed Insights برای هر پاسخی زمان کمتر از 200 میلی ثانیه را توصیه میکند. اگر در بازه 300 تا 500 میلی ثانیه هستید، تقریبا استاندارد است. و اگر بیش از 600 میلی ثانیه باشید، ممکن است در پیکر بندی سرور مشکلی وجود داشته باشد یا زمان آن فرا رسیده که به نرم افزار وب بهتری ارتقا پیدا کنید. یا اینکه میتوانید دستور العمل های گفته شده در ادامه را دنبال کنید تا TTFB را کاهش دهید و به یاد داشته باشید که SSL/TLS نیز میتواند یکی از عوامل کندی هم باشد.
روشهای گوناگون زیادی وجود دارند که میتوانید از طریق آنها TTFB را امتحان کنید. در ادامه با تعدادی از آن ها آشنا خواهیم شد. اما به یاد داشته باشید، هر ابزاری نتایجی کمی متفاوت از دیگری میدهد، پس بسیار مهم است که تنها از یکی از آنها استفاده کنید و از آن به عنوان اساس سایر فعالیتها بهره ببرید.
می توان TTFB را در گوگل کروم با استفاده از DevTools اندازه گیری کرد. به یاد داشته باشید، اگر در اندازه گیری TTFB از کامپیوتر خود استفاده میکنید، TTFB تحت تاثیر latency شبکه و ارتباط اینترنت قرار میگیرد. پس بهتر است از ابزارهای واسطه استفاده کنید تا آزمایش را از data center انجام دهد.
می توانید پنجره network را انتخاب کنید و عملکرد سئو سایت خود را ببینید.
همچنین می توانید TTFB را با WebPageTest بسنجید. Great time زمان مورد نیاز برای DNS، socket و SSLnegotiations + 100 میلی ثانیه می باشد. به ازای هر 100 میلی ثانیه یک حرف A کسر می شود. همانطور که در آزمایش زیر می توانید ببینید، TTFB این سایت در 0.256 ثانیه یا 256 میلی ثانیه محاسبه شده است.
کروم و WebPageTest به عنوان TTFB به Pingdom رجوع می کنند. با این حال، اگر شما از Pingdom استفاده می کنید، در واقع به عنوان زمان Wait به TTFB مراجعه می کند. می توانید از راهنما استفاده از Pingdom برای آشنایی بیشتر استفاده کنید.
یکی از ابزارهای معروف برای مدیران ایرانی که بیشترین استفاده را از آن میکنند، سایت Gtmetrix هم میتواند ابزاری بسیار مناسب جهت محاسبه TTFB سایت شما باشد، شما میتوانید با استفاده از لوکیشن های مختلف سایت خود را بررسی نمایید.
تفاوت اصلی ابزار performance.sucuri با سایر ابزارها این است به یک تست میتواند از ۱۰ ها مکان مختلف در سراسر دنیا سایت شما را تست نمایید و زمان TTFB هر مکان با میانگین کلی را ارائه دهد، یکی از ضعفهای این ابزار کش کردن و یا بهتر است بگیم توان مدیریت برای تست دوباره وجود نداره و اگر همان سایت رو تست دوباره بگیریم نتایج قبلی رو نشون میده.
همچنین ابزار های مختلف دیگری نیز برای اندازه گیری TTFB وجود دارند، مانند tools.keycdn.com و ByteCheck. حتی Google Analytics نیز بخشی برای مشاهده میانگین response time دارد.
حال به ارائه راهکارهایی برای کاهش TTFB در وبسایت میپردازیم.
اولین راه برای بهبود زمان TTFB استفاده از یک هاست مناسب با تنظیمات بهینه است، چرا که جدا تاثیر آن بر روی افزایش سرعت سایت روی تجربه کاربری نیز بسیار تاثیری مستقیم و حیاطی دارد. اصولا کمتر هاست اشتراکی دارای TTFB مناسب است و اکثرا به شکل بهینه کانفیگ نشدهاند، البته مخاطب حرفهای بنده هاستینگهای ایرانی است چرا که ما از اکثر هاستینگها سرور تهیه کردهایم و اکثرا در هاست های اشتراکی TTFB بالایی را داشتند، مگر سرور مجازی یا اختصاصی تهیه کرده باشید.
راه دیگری برای کاهش TTFB استفاده از Content Delivery Network یا همان CDN است. CDN را میتوان به شبکه توزیع محتوا ترجمه کرد و ما بارها درباره اهمیت و تاثیرات مثبت و منفی CDN ها صحبت کردهایم. اگر وبسایتی دارید که میزبان کاربرانی از نقاط مختلف کشور یا جهان است، استفاده از CDN می تواند به شدت TTFB شما را کاهش دهد، البته در برخی مکانها این موضوع صدق نمیکند مثلا ایران
راه سوم و شاید راحت ترین راه کاهش TTFB استفاده از caching در وبسایت وردپرسی است. افراد زیادی فکر می کنند که تنها استفاده از caching می تواند باعث کاهش زمان بارگذاری صفحه شود، اما در حقیقت در کاهش TTFB نیز موثر است و همچنین زمان پردازش سرور را نیز کاهش می دهد. برای اطلاعات بیشتر به مقاله نحوه کش کردن سایتمراجعه نمایید.
DNS نیز در TTFB موثر است. محاسبه دقیق مقدار این تاثیر بسیار سخت است، اما همچنان میتوانید زمان کلی DNSlookup را مشاهده کنید. Provider های سریع و آهسته ای وجود دارند. با استفاده از ابزار SolveDNS speed testمیتوانید از مکانهای مختلف آزمایش لازم را انجام دهید. برای کاهش زمان لود DNS میتوانید پست ۸ راه کاهش DNS Lookups و رفع خطای Reduce DNS lookups در GTmetrix مطالعه نمایید.
در پایان
موارد متعددی وجود دارند که می توانید بهینه سازی یا تعمیر کنید تا TTFB را کاهش دهید، مانند database caching، Disk IO، Swap usage، RAM، تنظیمات PHP، تنظیمات MySQL، تنظیمات شبکه، TLS overhead و غیره. اما پیاده سازی و اجرای موارد گفته شده در بالا آسانتر هستند و عملکردتان را سرعت می بخشند. پس دفعه بعدی که شخصی از شما پرسید که چطور TTFB را کاهش دهیم، به یاد داشته باشید که هاست سریع وردپرس، CDN، Caching و DNS مواردی هستند که در این زمینه از اهمیت زیادی برخوردارند. رفع و بهبود این موارد راه حل مشکل TTFB است.