نگاهی به سئو: server response time چیست؟

با سلام و احترام خدمت شما خوانندگان گرامی روکسو، به آخرین قسمت از دوره ی نگاهی به سئو خوش آمدید. بحث امروز ما Server response time و انواع آن خواهد بود. همچنین به مباحث پیرامون آن مانند TTFB نیز خواهیم پرداخت.

Server response time چیست؟

Server response time در لغت به معنی «زمان پاسخ سرور» است و آقای Patrick Sexton (از محققین سئو) آن را اینطور تعریف می کند:

Server response time is the amount of time it takes for a web server to respond to a request from a browser.

ترجمه: Server response time، مقدار زمانی است که که یک وب سرور برای پاسخ به یک درخواست مرورگر نیاز دارد.

اگر خودمانی تر بخواهم برایتان توضیح دهم اینطور می گویم:

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

• درخواست توسط شما به مرورگر تحویل داده می شود.
• درخواست توسط مرورگر به وب سرور ارسال می شود.
• درخواست ارسال شده توسط وب سرور تحلیل و پردازش می شود تا ببیند شما چه چیزی می خواهید.
• پاسخ درخواست به سمت مرورگر شما ارسال می شود.

مرحله ی 2 در تصویر (پردازش درخواست)، محلی است که Server response time در آن تعریف می شود. سرور شما باید فکر کند و ببیند چه فایل هایی را به کاربر تحویل دهد. هر چقدر این زمان فکر کردن بیشتر باشد می گوییم Server response time بیشتر است و مشخصا سرعت بارگذاری صفحات نیز کند تر!

نکته: سرعت بارگذاری صفحات را با Server response time اشتباه نگیرید. سرعت بارگذاری صفحات به عواملی مانند قدرت پردازش سیستم و مرورگر شما، سرعت ارسال اطلاعات توسط سرور به مرورگر شما و ... بستگی دارد اما Server response time به انتخاب فایل های ارسالی، پردازش یک فرم و اعلام نتیجه آن، انجام محاسبات خاص و برگشت دادن پاسخ و دیگر پردازش های اینچنینی مربوط است بنابراین حتی اگر صفحاتتان را بی نهایت بهینه سازی کرده باشید تا زمانی که Server response time زیادی داشته باشید، کاربران سایت شما را کُند می بینند.

مثالی که گوگل از Server response time می زند هنگامی است که کاربر می خواهد تاریخچه ی خرید های خود را ببیند. در این حالت سرور باید با پایگاه داده اتصال برقرار کند و این تاریخچه را از آن گرفته و سپس نمایش دهد. این ها همه جزو Server response time محاسبه می شوند.

سوال: Server response time ایده آل چه مقدار است؟

پاسخ: طبق گفته ی قدیمی گوگل بهتر است Server response time شما همیشه زیر 200 میلی ثانیه باشد که همان حالت ایده آل محسوب می شود. این مقدار معمولا پیشنهاد اکثر متخصصان سئو می باشد (در آخر این مقاله بیشتر توضیح خواهیم داد).

فکر نمی کنم لازم باشد توضیح بدهم که چرا Server response time با سئو ارتباط تنگاتنگی دارد! سرعت بارگذاری صفحات وب یکی از معیارهای بسیار مهم در رتبه بندی گوگل است و از طرفی کاربران نیز به آن اهمیت می دهند. شاید بتوان گفت سرعت یک وب سایت مهم ترین ویژگی آن برای کاربران امروزی دنیای وب است.

TTFB چیست؟

TTFB مخفف Time To First Byte و به معنی «زمان اولین بایت» می باشد. به گفته ی آقای Patrick Sexton (از محققان سئو) TTFB اینچنین تعریف می شود:

It is the amount of time a browser waits to receive the first piece of information from a web server after requesting it.

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

آیا متوجه نکته ی مشکوکی نشده اید؟ تفاوت TTFB و Server response time چیست؟ مسئله همین است! این دو هیچ تفاوتی با هم ندارند و حتی گوگل نیز در صفحه ی مربوط به Server response time خود میگوید این دو اصطلاح به جای هم به کار می روند.

چه فاکتورهایی باعث بالا رفتن TTFB می شوند؟

حالا که می دانیم TTFB و Server response time یکی هستند باید به دنبال دلایل کند شدن و بالا رفتن این دو بگردیم. عوامل بسیار زیادی می توانند باعث بالا رفتن TTFB بشوند اما شایع ترین این عوامل را می توانید در تصویر زیر مشاهده کنید:

بیایید تک تک آن ها را بررسی کنیم!

تولید محتوای پویا

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

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

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

مشخص است که تک تک این موارد زمان خواهند برد و به همین دلیل TTFB یا همان Server response time بالاتری دارند.

- چه راه حلی برای این مورد وجود دارد؟

• می توانید از پلاگین هایی مانند  W3 Total Cache و  WP Super Cache استفاده کنید تا محتوای سایت وردپرسی خود را کش کنید
• از سایت های ارائه دهنده ی میزبانی و hosting مخصوص وردپرس استفاده کنید. با کمی خرج بیشتر می توانید سرعت وب سایت خود را به شدت افزایش دهید.

پیکربندی سرور

پیکربندی وب سرور در زمان TTFB تاثیر زیادی دارد. وقتی می گوییم پیکربندی وب سرور منظورمان همان تنظیمات Apache و NGINX و IIS و Litespeed و ... است. این تنظیمات بسیار زیاد هستند و واضح است که نمی توان تمام آن ها را توضیح داد اما مهم ترین قسمت پیکربندی یک سرور که می تواند به TTFB صدمه بزند را بررسی خواهیم کرد: فایل htaccess.

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

طبق گفته ی سایت توسعه دهندگان گوگل و سایت رسمی Apache (ر.ک به این لینک):

However, in general, use of .htaccess files should be avoided when possible. Any configuration that you would consider putting in a .htaccess file, can just as effectively be made in a <Directory> section in your main server configuration file.

در واقع خلاصه ی متن بالا این است که سعی کنید از وارد کردن دستورات به صورت مستقیم در فایل htaccess. اجتناب کنید و به جای آن، دستورات را مستقیما در <Directory> تنظیمات سرور وارد کنید.

سوال: پس چرا چنین فایلی وجود دارد و به ما داده می شود؟

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

سپس سایت مذکور در مورد مشکلات احتمالی استفاده از htaccess. ادامه می دهد و می گوید:

- "httpd will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested.

- "In the case of RewriteRule directives, in .htaccess context these regular expressions must be re-compiled with every request to the directory, whereas in main server configuration context they are compiled once and cached. Additionally, the rules themselves are more complicated, as one must work around the restrictions that come with per-directory context and mod_rewrite."

ترجمه:

- httpd در هر مسیر و دیرکتوری به دنبال فایل htaccess. خواهد گشت. بنابراین مجاز گردن استفاده از htaccess. باعث کاهش عملکرد و سرعت می شود، چه از آن استفاده کنید و چه نکنید! همچنین هر زمانی که درخواستی برای یک سند به سرور ارسال شود، فایل htaccess. بارگذاری می شود!

- در رابطه با دستورات RewriteRule باید گفت: اگر این عبارات با قاعده در فایل htaccess. باشند باید، با هر درخواستی که به دیرکتوری ارسال می شود، دوباره کامپایل شوند اما اگر در تنظیمات اصلی وب سرور باشند تنها یک بار کامپایل شده و سپس کش می شوند. همچنین خود دستورات پیچیده تر هستند چرا که افراد باید با محدودیت های ایجاد شده توسط mod_rewrite و per-directory کنار بیایند.

بنابراین مشخص است که بارگذاری هر بار فایل htaccess. باعث بالا رفتن TTFB می شود اما مسئله اینجاست که در بسیاری از مواقع نمی توان فایل htaccess. را کنار گذاشت چرا که تقریبا تمام وب مستران از آن استفاده می کنند.

- چه راه حلی برای این مورد وجود دارد؟

بهترین راه بروزرسانی مرتب سرور از نظر نرم افزاری است. به طور مثال بروزرسانی نسخه ی زبان PHP می تواند به شدت روی سرعت سایت شما تاثیر گذاری باشد (ر.ک به مقاله ی مقایسه PHP 7 و PHP 5 (بروزرسانی ۲۰۱۹)). متاسفانه بسیاری از برنامه نویسان ایرانی هنوز از ورژن های عهد عتیق PHP استفاده می کنند.

ترافیک زیاد وب سایت و مشکلات شبکه

از دیگر دلایل بالا رفتن TTFB ترافیک زیاد و ایجاد مشکلات در شبکه است. زمانی که افراد زیادی وارد وب سایت شما بشوند، تعداد درخواست ها بالا می رود و زمانی که تعداد درخواست ها بالا برود CPU بیشتر اشغال می شود و زمانی که CPU بیشتر اشغال شود زمان مورد نیاز برای پردازش هر درخواست بیشتر می شود که در آخر باعث بالا رفتن TTFB می شود. مشکلات شبکه نیز ممکن است هر روز رخ بدهند (مانند کندی شبکه، اختلال در شبکه و زیرساخت ها و...). این دو مورد داستان متفاوتی دارند به این دلیل که ما روی آن ها کنترل واقعی نداریم. بنابراین راه حل چیست؟

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

اختلال در شبکه را چه کار کنیم؟ برخی اوقات اختلال در شبکه سراسری و در سطح یک کشور و شرکت زیرساخت است؛ در این موارد نمی توان کاری کرد. اما برخی از اوقات اختلالات در سطح میزبان و شرکت Hosting شما است. بنابراین برای دوری از مشکلات شبکه و همچنین مدیریت بهتر ترافیک، خدمات میزبانی را از شرکت های معتبر و مطرح دریافت کنید.

مقدار پیشنهادی TTFB

ارائه دادن یک عدد ثابت کار سختی است اما اگر فرض کنیم شما از یک منطقه ی جغرافیایی خاص (ترجیحا نزدیک به سرورتان) TTFB را اندازه گیری کنید و وب سایت مدرن و به روزی داشته باشید می توان گفت:

• کمتر از 100 میلی ثانیه بسیار عالی و بهترین حالت است.
• 200 میلی ثانیه ایده آل است.
• 500 میلی ثانیه غیر ایده آل و دلسرد کننده است.
• 1 ثانیه واقعا بد است.
• 2 ثانیه و بیشتر بسیار بد است و می تواند به کسب و کار شما صدمه ی جدی بزند.

برای مثال می توان گفت گوگل TTFB حدود 100 میلی ثانیه دارد.

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