TTFB چیست؟ چطور زمان TTFB را کاهش دهیم

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

در چنین شرایطی ممکنه مشکل از TTFB باشه؛ یعنی سرور هنوز اولین بخش از پاسخ رو به مرورگر نرسونده.

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

البته TTFB قرار نیست جواب همه سؤال‌های مربوط به سرعت باشه. ممکنه TTFB سایت شما عالی باشه، اما تصاویر چندمگابایتی و جاوااسکریپت‌های سنگین همچنان صفحه رو کُند کنن. برعکس، ممکنه طراحی فرانت‌اند خیلی سبک باشه ولی سرور اون‌قدر دیر جواب بده که مرورگر اصلاً فرصت شروع بارگذاری رو پیدا نکنه.

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

TTFB چیست؟

TTFB مخفف Time to First Byte و به معنی «زمان رسیدن اولین بایت» است.

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

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

فاصله بین پرسیدن سؤال و شنیدن اولین کلمه، تقریباً همون نقشی رو داره که TTFB در سایت بازی می‌کنه.

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

داخل زمان TTFB دقیقاً چه اتفاقی می‌افته؟

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

• مرورگر باید آدرس دامنه رو از طریق DNS به IP تبدیل کنه.
• ارتباط شبکه با سرور برقرار می‌شه.
• اگر سایت HTTPS باشه، مذاکره TLS انجام می‌شه.
• اگر ریدایرکتی وجود داشته باشه، مرورگر باید مسیر جدید رو دنبال کنه.
• درخواست به سرور می‌رسه.
• سرور، وردپرس، PHP و دیتابیس درخواست رو پردازش می‌کنن.
• اولین بایت پاسخ از سرور به مرورگر برمی‌گرده.

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

یه نکته ظریف هم وجود داره: ابزارهای مختلف همیشه دقیقاً یه بخش یکسان رو اندازه نمی‌گیرن. برای مثال، گزارش Server Response Time در Lighthouse همه اجزای TTFB مثل DNS و ریدایرکت رو شامل نمی‌شه. به همین دلیل ممکنه عدد Lighthouse با عددی که کاربر واقعی تجربه کرده متفاوت باشه.

TTFB چه فرقی با سرعت لود کامل سایت دارد؟

این دو تا زیاد با هم اشتباه گرفته می‌شن، اما یکی نیستن.

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

برای اینکه تفاوتشون روشن‌تر بشه، بارگذاری صفحه رو مثل ورود به یه رستوران ببینید:

• TTFB: چقدر طول می‌کشه پیشخدمت بعد از سفارش، اولین چیزی رو روی میز شما بذاره.
• FCP: اولین بخش قابل‌دیدن سفارش چه زمانی روی میز قرار می‌گیره.
• LCP: غذای اصلی چه زمانی می‌رسه.
• لود کامل صفحه: چه زمانی تمام سفارش شما آماده شده.

ممکنه پیشخدمت سریع یه لیوان آب بیاره و TTFB عالی باشه، اما غذای اصلی خیلی دیر آماده بشه. در سایت هم ممکنه پاسخ سرور سریع شروع بشه ولی فایل‌های سنگین باعث بشن صفحه دیر قابل‌استفاده بشه.

از اون طرف، TTFB بالا همه مراحل بعدی رو عقب می‌ندازه. مرورگر تا وقتی پاسخ HTML رو نگیره، معمولاً نمی‌تونه منابع اصلی صفحه رو پیدا کنه. به همین دلیل TTFB روی FCP و LCP یه اثر پایه‌ای داره.

TTFB خوب چقدر است؟

طبق راهنمای فعلی web.dev، این محدوده‌ها رو می‌تونیم به‌عنوان یه راهنمای تقریبی در نظر بگیریم:

این ارزیابی بهتره براساس صدک ۷۵ تجربه کاربران واقعی انجام بشه؛ یعنی حداقل ۷۵ درصد بازدیدها باید داخل محدوده مناسب قرار بگیرن. اطلاعات کامل در راهنمای TTFB در web.dev منتشر شده.

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

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

چرا بعضی منابع هنوز عدد ۲۰۰ میلی‌ثانیه را پیشنهاد می‌کنند؟

چون داشتن پاسخ زیر ۲۰۰ میلی‌ثانیه برای خیلی از سایت‌ها عالیه و به‌عنوان یه هدف فنی بلندپروازانه مطرح می‌شه. اما این عدد، مرز رسمی فعلی بین TTFB خوب و بد نیست.

در راهنمای فعلی web.dev، ۸۰۰ میلی‌ثانیه یا کمتر به‌عنوان محدوده خوب معرفی شده. پس اگر TTFB شما ۴۰۰ میلی‌ثانیه‌ست، قرار نیست صرفاً چون زیر ۲۰۰ نیست، کل هاست رو عوض کنید.

اول ببینید تجربه واقعی کاربران و بقیه شاخص‌های سرعت چه وضعیتی دارن.

چطور TTFB سایت را اندازه‌گیری کنیم؟

برای اندازه‌گیری درست، بهتره هم داده آزمایشگاهی یا Lab Data رو ببینید، هم داده کاربران واقعی یا Field Data رو.

بررسی TTFB با PageSpeed Insights

آدرس صفحه رو داخل PageSpeed Insights وارد کنید.

اگر سایت داده کافی در Chrome User Experience Report داشته باشه، بالای گزارش بخشی مربوط به تجربه کاربران واقعی می‌بینید. TTFB در همین بخش می‌تونه نشون بده بازدیدکننده‌های واقعی از موقعیت‌ها، دستگاه‌ها و اینترنت‌های مختلف چه تجربه‌ای داشتن.

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

اندازه‌گیری با Chrome DevTools

برای بررسی یه درخواست مشخص:

1. صفحه موردنظر رو در Chrome باز کنید.
2. کلید F12 رو بزنید یا Inspect رو انتخاب کنید.
3. وارد تب Network بشید.
4. صفحه رو دوباره بارگذاری کنید.
5. روی درخواست اصلی Document کلیک کنید.
6. در بخش Timing، مقدار Waiting for server response یا TTFB رو ببینید.

این روش کمک می‌کنه مراحل DNS، اتصال، SSL و انتظار برای پاسخ سرور رو جدا ببینید.

بررسی با GTmetrix و WebPageTest

GTmetrix برای یه نگاه سریع و مقایسه چند تست مناسبه. WebPageTest هم امکان انتخاب موقعیت جغرافیایی، مرورگر، سرعت شبکه و اجرای چندباره تست رو می‌ده.

برای نتیجه قابل‌اعتماد:

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

چرا عدد TTFB در هر تست فرق می‌کند؟

اگر الان تست بگیرید و TTFB بشه ۳۰۰ میلی‌ثانیه، ممکنه پنج دقیقه بعد عدد ۶۰۰ یا حتی ۹۰۰ ببینید. این تفاوت همیشه به معنی خراب‌شدن سایت نیست.

TTFB به شرایط مختلفی وابسته‌ست:

• موقعیت کاربر یا سرور تست؛
• کیفیت و شلوغی شبکه؛
• گرم یا سردبودن کش؛
• میزان فشار لحظه‌ای روی سرور؛
• اجرای Cron یا پردازش‌های پس‌زمینه؛
• صفحه عمومی یا شخصی‌سازی‌شده؛
• وجود ریدایرکت در مسیر ورود؛
• تفاوت ابزار در تعریف و محاسبه TTFB.

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

چه چیزهایی باعث افزایش TTFB می‌شن؟

حالا که می‌دونیم TTFB چطور اندازه‌گیری می‌شه، بریم سراغ مقصرهای اصلی.

هاست ضعیف یا کمبود منابع

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

نشونه‌های احتمالی مشکل هاست:

• TTFB بیشتر صفحات بالاست؛
• پیشخوان وردپرس هم کُنده؛
• در ساعت‌های شلوغی وضعیت بدتر می‌شه؛
• خطای کمبود منابع یا ۵۰۳ می‌بینید؛
• با اجرای یه کار معمولی، مصرف CPU به سقف می‌رسه.

البته هاست اشتراکی لزوماً بد نیست. یه هاست اشتراکی مدیریت‌شده و باکیفیت برای خیلی از سایت‌ها کافیه. قبل از رفتن سراغ VPS یا سرور اختصاصی، مصرف واقعی سایت و کیفیت پلن فعلی رو بررسی کنید.

فاصله جغرافیایی و تأخیر شبکه

هرچقدر کاربر از سرور دورتر باشه، رفت‌وبرگشت داده زمان بیشتری می‌گیره. این تأخیر در مراحل DNS، اتصال TCP، TLS و ارسال درخواست خودش رو نشون می‌ده.

اگر مخاطب‌های شما فقط در یه منطقه هستن، انتخاب سرور نزدیک‌تر می‌تونه مفید باشه. اگر کاربرها در کشورهای مختلف پراکنده‌ان، CDN و Edge Cache معمولاً راه منطقی‌تریه.

DNS کند

مرورگر قبل از اتصال باید IP دامنه رو پیدا کنه. DNS کند می‌تونه شروع ارتباط رو عقب بندازه، مخصوصاً در اولین بازدید یا وقتی اطلاعات داخل کش نیست.

استفاده از DNS معتبر، حذف رکوردهای اشتباه و جلوگیری از زنجیره‌های پیچیده CNAME می‌تونه کمک‌کننده باشه.

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

ریدایرکت‌های اضافی

فرض کنید کاربر آدرس http://example.com رو باز می‌کنه، بعد به https://example.com می‌ره و از اونجا دوباره به https://www.example.com منتقل می‌شه.

هر ریدایرکت یه رفت‌وبرگشت اضافه به شبکه تحمیل می‌کنه. ریدایرکت‌های ضروری مشکلی ندارن، اما زنجیره‌های بی‌دلیل باید کوتاه بشن.

لینک‌های داخلی، منوها، Sitemap و کمپین‌های تبلیغاتی رو مستقیم به آدرس نهایی وصل کنید.

پردازش سنگین PHP و وردپرس

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

علت‌های رایج:

• نسخه قدیمی PHP؛
• افزونه یا قالب با کدنویسی ضعیف؛
• درخواست به API خارجی؛
• کارهای سنگین داخل Hookهای عمومی؛
• تولید گزارش یا محاسبات پیچیده در هر بازدید؛
• فعال‌نبودن OPcache.

کوئری‌های سنگین دیتابیس

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

مشکلاتی مثل Autoload حجیم در جدول wp_options، افزونه‌های گزارش‌گیری، جست‌وجوهای پیچیده و جدول‌های خیلی بزرگ می‌تونن TTFB رو بالا ببرن.

فقط پاک‌سازی رونوشت‌ها کافی نیست. باید بفهمید دقیقاً کدوم کوئری و کدوم افزونه زمان می‌گیره.

قالب یا افزونه سنگین

تعداد افزونه‌ها به‌تنهایی معیار خوبی نیست. ممکنه سی افزونه سبک داشته باشید و سایت سریع باشه، اما یه افزونه بد نوشته‌شده چندصد میلی‌ثانیه به پردازش هر درخواست اضافه کنه.

قالب هم می‌تونه قبل از تولید HTML کوئری‌ها و پردازش‌های زیادی اجرا کنه. بنابراین فقط حجم فایل CSS قالب رو نبینید؛ عملکرد سمت سرور اون هم مهمه.

نقش قالب اهورا در کنترل فایل‌های اضافی

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

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

فعال‌نبودن کش صفحه

بدون Page Cache، سرور ممکنه برای هر بازدید دوباره PHP و وردپرس رو اجرا کنه و همون خروجی قبلی رو بسازه.

با Full Page Cache، نسخه آماده HTML ذخیره و در بازدید بعدی مستقیم تحویل داده می‌شه. این کار معمولاً یکی از مؤثرترین روش‌های کاهش TTFB صفحه‌های عمومی وردپرس محسوب می‌شه.

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

نبودن Object Cache و OPcache

این سه نوع کش رو با هم اشتباه نگیرید:

• Page Cache: خروجی کامل HTML رو ذخیره می‌کنه.
• Object Cache: نتایج پرتکرار و داده‌های موردنیاز وردپرس رو در حافظه نگه می‌داره تا مراجعه به دیتابیس کمتر بشه.
• OPcache: کد کامپایل‌شده PHP رو نگه می‌داره تا فایل‌های PHP هر بار از صفر کامپایل نشن.

برای صفحه‌های عمومی، Page Cache معمولاً بیشترین اثر مستقیم رو داره. برای فروشگاه‌ها، سایت‌های عضویتی و پیشخوان که محتوای پویا دارن، Object Cache پایدار مثل Redis می‌تونه مهم‌تر بشه.

درخواست‌های خارجی کُند

گاهی PHP قبل از ساخت صفحه منتظر جواب یه سرویس دیگه می‌مونه: درگاه پرداخت، لایسنس افزونه، API نرخ ارز، سرویس پیامک یا یه درخواست آماری.

اگر اون سرویس دیر جواب بده یا در دسترس نباشه، TTFB سایت شما هم بالا می‌ره.

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

WP-Cron و پردازش‌های پس‌زمینه

وردپرس برای کارهای زمان‌بندی‌شده از WP-Cron استفاده می‌کنه. بعضی افزونه‌ها وظایف سنگینی مثل ارسال ایمیل، ساخت گزارش، همگام‌سازی محصول یا پاک‌سازی رو روی اون قرار می‌دن.

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

ترافیک بالا، ربات‌ها یا حمله

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

اگر افزایش TTFB ناگهانیه، لاگ سرور، نمودار مصرف منابع و تعداد درخواست‌ها رو بررسی کنید. CDN، Rate Limiting و فایروال برنامه وب می‌تونن کمک کنن.

چطور زمان TTFB را کاهش دهیم؟

بهینه‌سازی TTFB باید براساس علت انجام بشه. اگر مشکل از دیتابیسه، CDN به‌تنهایی درمانش نمی‌کنه. اگر مشکل از فاصله جغرافیاییه، پاک‌سازی چند رونوشت هم اثر زیادی نداره.

این مسیر رو مرحله‌به‌مرحله جلو برید.

اول TTFB کش‌شده و کش‌نشده را مقایسه کنید

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

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

داشتن کش خوبه، اما بهتره مسیر بدون کش هم اون‌قدر بد نباشه که با هر پاک‌سازی، سایت از نفس بیفته.

Full Page Cache را فعال کنید

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

کش می‌تونه در سطح افزونه، وب‌سرور، Reverse Proxy یا CDN Edge انجام بشه. هرچه تحویل صفحه زودتر و نزدیک‌تر به کاربر انجام بشه، معمولاً TTFB بهتر می‌شه.

از افزونه رخش برای کش مستقیم وب‌سرور استفاده کنید

ما در تیم میهن وردپرس افزونه رخش رو ساختیم تا کش و بخش‌های مختلف بهینه‌سازی سرعت رو با تنظیمات ساده‌تری مدیریت کنه.

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

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

رخش فقط Page Cache نیست. تبدیل تصاویر به WebP و AVIF، کنترل CSS و JavaScript، Delay اسکریپت‌ها و تحلیل کوئری‌های کند دیتابیس هم داخلش قرار گرفته. بعضی از این قابلیت‌ها TTFB رو هدف می‌گیرن و بعضی‌ها سرعت مراحل بعدی لود رو بهتر می‌کنن.

خود سایت میهن وردپرس هم قبلاً از WP Rocket استفاده می‌کرد و حالا روی رخش اجرا می‌شه. برای دیدن امکانات و نتیجه تست‌ها می‌تونید صفحه افزونه افزایش سرعت رخش رو بررسی کنید.

۴. هاست و نسخه PHP را بررسی کنید

اگر TTFB حتی با کش مناسب همچنان بالاست، منابع هاست، نوع وب‌سرور، نسخه PHP، OPcache و فشار سرور رو بررسی کنید.

قبل از ارتقا از پشتیبانی هاست بخواید مصرف CPU، RAM، I/O، تعداد Workerها و خطاهای محدودیت منابع رو نشونتون بده. گاهی مشکل با تغییر تنظیمات یا پلن حل می‌شه و نیازی به سرور اختصاصی نیست.

نسخه PHP رو هم فقط وقتی ارتقا بدید که قالب و افزونه‌ها باهاش سازگار باشن. اول روی Staging تست کنید.

۵. کوئری‌های دیتابیس را پیدا و اصلاح کنید

برای سایت وردپرسی، ابزارهایی مثل Query Monitor یا سیستم‌های APM می‌تونن نشون بدن کدوم کوئری، Hook یا درخواست خارجی بیشترین زمان رو گرفته.

مواردی که باید بررسی بشن:

• کوئری‌های تکراری؛
• کوئری‌های بدون ایندکس؛
• Autoload حجیم؛
• جدول‌های خیلی بزرگ؛
• داده‌های باقی‌مانده از افزونه‌های حذف‌شده؛
• جست‌وجو و فیلتر پیچیده محصولات.

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

۶. افزونه و قالب سنگین را شناسایی کنید

همه افزونه‌ها رو یه‌باره روی سایت اصلی غیرفعال نکنید. یه نسخه Staging بسازید و افزونه‌ها رو گروه‌به‌گروه آزمایش کنید.

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

ممکنه امکان حذف افزونه وجود نداشته باشه. در این حالت باید تنظیماتش سبک‌تر، پردازش‌ها زمان‌بندی یا بخشی از درخواست‌ها کش بشن.

۷. Object Cache پایدار را برای سایت‌های پویا بررسی کنید

Object Cache مثل Redis می‌تونه نتیجه کوئری‌ها و داده‌های پرتکرار رو در حافظه نگه داره. این موضوع برای ووکامرس، سایت‌های عضویتی و پیشخوان‌های سنگین مفیده؛ جاهایی که Full Page Cache همیشه قابل‌استفاده نیست.

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

۸. از CDN و Edge Cache درست استفاده کنید

CDN فایل‌های ثابت رو از سرور نزدیک‌تر به کاربر تحویل می‌ده. اما اگر فقط عکس، CSS و JavaScript روی CDN باشن، لزوماً TTFB سند اصلی HTML به‌شکل چشمگیری کم نمی‌شه.

برای اثر مستقیم‌تر روی TTFB صفحه، CDN باید Full Page Cache یا Edge Cache داشته باشه تا خود HTML از نقطه نزدیک به کاربر تحویل داده بشه.

صفحات شخصی‌سازی‌شده، حساب کاربری و سبد خرید به قوانین دقیق کش نیاز دارن. فعال‌کردن کورکورانه Edge Cache روی ووکامرس می‌تونه محتوای اشتباه به کاربر نشون بده.

۹. ریدایرکت‌ها را کوتاه کنید

نسخه نهایی دامنه رو مشخص کنید: HTTPS، با www یا بدون www. بعد مطمئن بشید لینک‌های داخلی، Sitemap، Canonical و تبلیغات مستقیماً به همین نسخه اشاره می‌کنن.

زنجیره http → https → www → آدرس نهایی رو به یه ریدایرکت مستقیم تبدیل کنید.

۱۰. DNS و TLS را بهینه کنید

از DNS معتبر و سریع استفاده کنید، رکوردهای اشتباه رو حذف کنید و زنجیره‌های غیرضروری رو کوتاه نگه دارید.

برای TLS، تنظیمات مدرن، Session Resumption و HTTP/2 یا HTTP/3 می‌تونن هزینه برقراری ارتباط رو کمتر کنن. این بخش معمولاً در کنترل مدیر سرور یا شرکت هاسته.

قبل از دستکاری تنظیمات امنیتی با متخصص سرور هماهنگ کنید؛ پایین‌آوردن TTFB نباید به قیمت ضعیف‌کردن امنیت تموم بشه.

۱۱. درخواست‌های خارجی و Cronها را مدیریت کنید

با Query Monitor، APM یا لاگ برنامه بررسی کنید آیا پردازش صفحه منتظر API خارجی می‌مونه یا نه.

درخواست‌های غیرضروری رو حذف، جواب‌های قابل‌کش رو ذخیره و Timeout منطقی تعریف کنید. کارهای سنگین رو از درخواست کاربر جدا و در صف یا Cron اجرا کنید.

برای سایت پرترافیک، WP-Cron رو به Cron واقعی سرور منتقل کنید تا اجرای وظایف زمان‌بندی‌شده قابل‌کنترل‌تر بشه.

۱۲. از Server-Timing برای پیدا کردن گلوگاه استفاده کنید

اگر سایت یا کدنویسی اختصاصی دارید، هدر Server-Timing می‌تونه زمان بخش‌های مختلف پردازش بک‌اند رو داخل DevTools نشون بده؛ مثلاً زمان دیتابیس، رندر سمت سرور یا Cache Hit و Miss.

این کار کمک می‌کنه به‌جای حدس‌زدن، دقیقاً ببینید ۷۰۰ میلی‌ثانیه انتظار کجا مصرف شده.

راهنمای رسمی بهینه‌سازی TTFB در web.dev استفاده از Server-Timing یا ابزارهای APM رو برای عیب‌یابی بک‌اند پیشنهاد می‌کنه.

TTFB در ووکامرس چرا پیچیده‌تره؟

در یه وبلاگ، خیلی از صفحه‌ها برای همه کاربران یکسانن و به‌راحتی Full Page Cache می‌شن. اما ووکامرس صفحه‌های پویای بیشتری داره:

• سبد خرید؛
• تسویه‌حساب؛
• حساب کاربری؛
• تاریخچه سفارش؛
• قیمت و موجودی شخصی‌سازی‌شده؛
• فیلترها و جست‌وجوی محصولات.

این صفحه‌ها معمولاً نمی‌تونن مثل یه مقاله عمومی از کش کامل استفاده کنن. برای بهبود TTFB فروشگاه باید سراغ Object Cache، دیتابیس، کوئری محصولات، Sessionها، Cronها و منابع واقعی سرور هم برید.

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

آیا TTFB روی سئو اثر می‌گذاره؟

اینجا باید دقیق جواب بدیم: TTFB خودش جزو Core Web Vitals نیست و گوگل اون رو به‌عنوان یه «فاکتور مستقیم و مستقل رتبه‌بندی» معرفی نکرده.

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

در سایت‌های خیلی بزرگ، پاسخ‌گویی ضعیف سرور می‌تونه کار خزنده‌ها رو هم سخت‌تر کنه، اما بهتره هر TTFB بالا رو فوراً به «هدررفتن Crawl Budget» ربط ندیم. Crawl Budget بیشتر برای سایت‌های بزرگ و پرتغییر اهمیت جدی پیدا می‌کنه.

همچنین Bounce Rate بالا به‌تنهایی یه جریمه مستقیم سئو نیست. ولی اگر کاربرها به‌خاطر کندی سایت نتونن به محتوا یا محصول برسن، تجربه بد، تبدیل کمتر و نارضایتی واقعی نتیجه طبیعی ماجراست.

پس TTFB رو به خاطر کاربر و عملکرد بهتر اصلاح کنید؛ نه با وعده اینکه کم‌شدن چند میلی‌ثانیه حتماً رتبه گوگل رو جابه‌جا می‌کنه.

چه زمانی باید هاست را عوض کنیم؟

با دیدن یه تست بد فوراً هاست رو عوض نکنید. اول این موارد رو بررسی کنید:

• آیا TTFB در ساعت‌ها و روزهای مختلف بالاست؟
• آیا صفحه کش‌شده هم کُنده؟
• آیا پیشخوان وردپرس و صفحات پویا هم مشکل دارن؟
• آیا مصرف منابع دائماً به سقف می‌رسه؟
• آیا پشتیبانی هاست می‌تونه دلیل رو با لاگ و نمودار نشون بده؟
• آیا همین نسخه سایت روی محیط بهتر، سریع‌تر جواب می‌ده؟

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

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

چک‌لیست کاهش TTFB

اگر می‌خواید مرحله‌به‌مرحله جلو برید، این فهرست رو دنبال کنید:

1. از سایت بکاپ کامل بگیرید.
2. TTFB رو با چند تست و از چند موقعیت بسنجید.
3. داده کاربران واقعی رو با آزمایش Lighthouse مقایسه کنید.
4. کش سرد و گرم رو جدا بررسی کنید.
5. ریدایرکت‌های قبل از آدرس نهایی رو پیدا کنید.
6. مصرف CPU، RAM و I/O هاست رو ببینید.
7. نسخه PHP و فعال‌بودن OPcache رو بررسی کنید.
8. Full Page Cache رو برای صفحات عمومی فعال کنید.
9. قوانین استثنای کش فروشگاه و حساب کاربری رو کنترل کنید.
10. افزونه‌ها و قالب رو روی Staging آزمایش کنید.
11. کوئری‌های کند و Autoload حجیم رو پیدا کنید.
12. درخواست‌های API و Cronهای سنگین رو بررسی کنید.
13. برای سایت پویا، Object Cache رو ارزیابی کنید.
14. در صورت نیاز از CDN دارای Edge Cache استفاده کنید.
15. بعد از هر تغییر، دوباره با شرایط مشابه تست بگیرید.

چند باور اشتباه درباره TTFB

«TTFB زیر ۲۰۰ میلی‌ثانیه واجبه»

نه. زیر ۲۰۰ میلی‌ثانیه عالیه، اما مرز تقریبی فعلی web.dev برای محدوده خوب ۸۰۰ میلی‌ثانیه یا کمتره.

«TTFB خوب یعنی سایت کاملاً سریعه»

نه. تصاویر، CSS، JavaScript، فونت‌ها و ساختار صفحه بعد از اولین بایت همچنان می‌تونن سایت رو کند کنن.

«CDN حتماً TTFB صفحه رو کم می‌کنه»

نه همیشه. CDN فایل‌های ثابت لزوماً HTML اصلی رو کش نمی‌کنه. برای کاهش مستقیم TTFB سند باید Edge Cache یا Full Page Cache مناسب داشته باشید.

«کش مرورگر TTFB کاربر جدید رو حل می‌کنه»

کش مرورگر بیشتر برای فایل‌های ثابت و بازدیدهای بعدی مفیده. Page Cache و Server Cache اثر مستقیم‌تری روی زمان ساخت پاسخ HTML دارن.

«هر TTFB بالایی یعنی هاست بده»

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

«کم‌شدن TTFB حتماً رتبه گوگل رو بالا می‌بره»

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

سؤالات پرتکرار درباره TTFB

آموزش کامل‌تر افزایش سرعت سایت

TTFB فقط یکی از بخش‌های سرعت سایته. اگر می‌خواید موضوعاتی مثل کش، دیتابیس، Core Web Vitals، بهینه‌سازی قالب و عیب‌یابی سایت رو عمیق‌تر یاد بگیرید، در دوره جامع سایت برتر یه فصل کامل به افزایش سرعت سایت اختصاص داده شده.

جمع‌بندی

TTFB مدت‌زمانیه که از شروع درخواست تا رسیدن اولین بایت پاسخ به مرورگر طول می‌کشه. این زمان می‌تونه شامل DNS، اتصال، TLS، ریدایرکت، فاصله شبکه و پردازش خود سرور باشه.

اگر TTFB بالاست، مستقیم سراغ تعویض هاست یا نصب چند افزونه نرید. اول مشخص کنید تأخیر دقیقاً کجا ایجاد شده. کش سرد و گرم رو مقایسه کنید، منابع هاست رو ببینید، کوئری‌های دیتابیس و درخواست‌های خارجی رو بررسی کنید و ریدایرکت‌ها رو کوتاه کنید.

برای صفحات عمومی وردپرس، Full Page Cache معمولاً یکی از مؤثرترین راه‌هاست. برای صفحات پویا و پیشخوان، باید Object Cache، دیتابیس، PHP و افزونه‌ها رو جدی‌تر بررسی کنید.

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

هدف نهایی این نیست که فقط یه عدد کوچک‌تر تحویل بگیریم. هدف اینه که کاربر بعد از کلیک، معطل نمونه و سایت واقعاً سریع‌تر و روان‌تر کار کنه.

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

ما در تیم تولید محتوای میهن وردپرس در تلاش هستیم تا بهترین مقالات آموزشی در زمینه وردپرس و کسب‌و‌کارهای اینترنتی را تهیه کنیم. صحت محتوای این صفحه توسط رضا راد بررسی خواهد شد.