کاهش TTFB وردپرس با پیدا کردن زمان ازدست‌رفته پیش از رسیدن اولین بایت پاسخ شروع می‌شود. ابتدا درخواست اصلی صفحه را اندازه بگیرید، زمان اتصال و تغییر مسیر را از انتظار پاسخ جدا کنید و رفتار صفحه کش‌شده را با صفحه پویا مقایسه کنید. سپس روی همان بخش کند کار کنید: مسیر شبکه، کش HTML، اجرای PHP، دیتابیس یا سرویس بیرونی.
اگر کاربر چند ثانیه صفحه سفید می‌بیند، نصب هم‌زمان چند افزونه سرعت تشخیص را دشوارتر می‌کند. این راهنما برای مدیر سایتی است که می‌خواهد بداند مشکل را در وردپرس پیگیری کند یا با گزارش مشخص به میزبان ارجاع بدهد. هدف، بهترشدن تجربه واقعی بازدیدکننده است؛ یک امتیاز آزمایشگاهی به‌تنهایی سلامت همه صفحات فروشگاه را نشان نمی‌دهد.
TTFB چیست و چه چیزی را اندازه نمی‌گیرد؟
TTFB یا Time to First Byte فاصله شروع درخواست تا رسیدن نخستین بایت پاسخ است. در اندازه‌گیری ناوبری مرورگر، تغییر مسیر، پیداکردن دامنه و برقراری اتصال هم می‌توانند سهم داشته باشند. پس عدد بالا الزاماً ثابت نمی‌کند پردازنده هاست ضعیف است. همچنین TTFB با زمان دانلود کامل صفحه یا زمان دیده‌شدن تصویر اصلی یکسان نیست.
ممکن است HTML زود برسد ولی تصویر بزرگ یا کد جاوااسکریپت، نمایش محتوای اصلی را عقب بیندازد. برعکس، بهینه‌سازی تصویر جای انتظار طولانی برای تولید HTML را نمی‌گیرد. TTFB خودش یکی از سه شاخص اصلی Core Web Vitals نیست، اما تأخیر ابتدای پاسخ می‌تواند نمایش محتوا را عقب بیندازد. تشخیص هر دو مرحله برای تصمیم درست لازم است.
پیش از تغییر، یک خط پایه قابل مقایسه بسازید
سه نشانی انتخاب کنید: یک مقاله عمومی، یک صفحه محصول یا دسته و یک عملیات پویا که برای کسب‌وکار مهم است. زمان آزمون، موقعیت شبکه، ورود یا خروج از حساب و وضعیت کش را بنویسید. هر نشانی را چند بار با فاصله کوتاه بررسی کنید و همه نتایج را نگه دارید؛ بهترین اجرای اتفاقی را نتیجه نهایی ننامید.
برای نمونه آموزشی، فرض کنید مقاله در بازدید دوم سریع می‌شود ولی جست‌وجوی فروشگاه همچنان کند است. این اختلاف، بررسی مسیر بدون کش و اجرای برنامه را منطقی‌تر می‌کند؛ هنوز ثابت نمی‌کند دیتابیس مقصر است. اگر تمام درخواست‌ها فقط از یک شبکه کندند، مسیر اتصال هم باید بررسی شود. این مثال، گزارش آزمون انجام‌شده روی آفاق هاست یا سایت شما نیست.
| الگوی مشاهده‌شده | آزمون بعدی | مسیر احتمالی رسیدگی |
|---|---|---|
| چند تغییر مسیر پیش از صفحه نهایی | بررسی زنجیره نشانی‌ها | هماهنگ‌کردن نشانی اصلی و لینک‌ها |
| بازدید اول کند و بعدی سریع | مقایسه وضعیت کش پاسخ‌ها | رفتار کش و تولید صفحه تازه |
| مقاله سریع، جست‌وجو کند | ثبت زمان اجرای همان جست‌وجو | PHP، پرس‌وجوها و منابع |
| کندی فقط در یک مسیر اینترنت | مقایسه از شبکه مستقل | DNS، اتصال و مسیر شبکه |
| TTFB مناسب، نمایش محتوا دیر | بررسی مرحله رندر و منابع اصلی | تصاویر، CSS و جاوااسکریپت |
۱. درخواست HTML را در مرورگر پیدا کنید
در Chrome ابزار توسعه را باز کنید، به Network بروید و صفحه را تازه‌سازی کنید. درخواست سند اصلی را انتخاب کنید؛ زمان یک تصویر یا فایل CSS پاسخ سؤال ما نیست. در Timing، بخش‌های DNS، اتصال، TLS و انتظار پاسخ را ببینید. حالت کاهش سرعت آزمایشی مرورگر را هم یادداشت کنید تا آن را با شبکه واقعی اشتباه نگیرید.
اگر گزینه Disable cache را فعال می‌کنید، توجه کنید این گزینه کش مرورگر را تحت تأثیر قرار می‌دهد و الزاماً کش CDN یا کش صفحه سرور را دور نمی‌زند. از هدرها و گزارش راهکار کش نصب‌شده برای فهمیدن وضعیت استفاده کنید؛ نام هدر میان سرویس‌ها متفاوت است. نتیجه HIT یا MISS را هم همراه عدد زمان ثبت کنید.
۲. با curl نتیجه را از یک نقطه مشخص مقایسه کنید
اگر به خط فرمان دسترسی دارید، فرمان زیر یک درخواست عادی GET می‌فرستد و بدنه را نمایش نمی‌دهد. نشانی نمونه را با صفحه عمومی سایت خودتان جایگزین کنید. در PowerShell ویندوز از curl.exe استفاده کنید تا با نام مستعار ابزار دیگری اشتباه نشود. برای یک بررسی اولیه، اجرای محدود کافی است و نیازی به تولید بار سنگین نیست.
curl -sS -o /dev/null -w "code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/page/در ویندوز، به‌جای /dev/null مقصد NUL را بنویسید. زمان‌ها بر حسب ثانیه و عمدتاً از آغاز انتقال محاسبه می‌شوند؛ برای به‌دست‌آوردن هر مرحله، نباید آن‌ها را دوباره با هم جمع کنید. time_starttransfer زمان تا اولین بایت را نشان می‌دهد و کل زمان پردازش داخلی PHP را به‌تنهایی جدا نمی‌کند. این فرمان بدون گزینه دنبال‌کردن ریدایرکت است؛ اگر پاسخ انتقال 3xx مانند 301، 302، 307 یا 308 دیدید، ابتدا مقصد تغییر مسیر را بررسی کنید.
۳. نشانی اصلی و کش صفحات عمومی را اصلاح کنید
درخواست از نشانی HTTP، سپس انتقال به HTTPS و بعد انتقال دوباره به نسخه دارای www، می‌تواند مسیر رسیدن به صفحه را طولانی کند. لینک‌های داخلی را به نشانی نهایی و درست همان سایت بدهید و قواعد تغییر مسیر را در لایه مسئول هماهنگ کنید. آدرس همه صفحات را صرفاً برای کوتاه‌کردن زنجیره عوض نکنید؛ ساختار فعلی و مسیرهای ورودی را در نظر بگیرید.
برای مقاله و صفحه عمومی، کش HTML می‌تواند اجرای تکراری برنامه را کاهش دهد. یک سازوکار مشخص و سازگار با میزبان انتخاب کنید و تأیید کنید واقعاً پاسخ کش‌شده تحویل می‌شود. سبد خرید، پرداخت، حساب کاربری و محتوای شخصی باید مطابق قواعد فروشگاه از کش عمومی مستثنا باشند. پس از تنظیم، ورود کاربر و تغییر محتوای یک صفحه را هم بررسی کنید.
۴. مسیر بدون کش را جداگانه بررسی کنید
وقتی صفحه پویا کند است، یک عملیات مشخص را در محیط آزمایشی بازتولید کنید. زمان درخواست‌های بیرونی، پرس‌وجوهای دیتابیس و افزونه‌های درگیر را با ابزار پایش مناسب ببینید. تعداد زیاد افزونه به‌تنهایی میزان تأخیر را ثابت نمی‌کند؛ ممکن است یک ارتباط بیرونی منتظر پاسخ باشد یا یک پرس‌وجوی مشخص، بخش اصلی زمان را مصرف کند.
تغییر قالب یا غیرفعال‌کردن مرحله‌ای افزونه‌ها را روی نسخه آزمایشی انجام دهید و پس از هر تغییر همان عملیات را تکرار کنید. حذف مستقیم جدول‌های دیتابیس یا پاک‌سازی گسترده بدون شناخت وابستگی‌ها، قدم تشخیصی مناسبی نیست. اگر تأخیر یک سرویس خارجی پیدا شد، زمان‌پایان، تعداد فراخوانی و نیاز واقعی به اجرای هم‌زمان آن را با توسعه‌دهنده بررسی کنید.
۵. چه زمانی مشکل را به هاست ارجاع بدهیم؟
در هاست اشتراکی، نمودار محدودیت منابع و گزارش خطا را با ساعت کندی تطبیق دهید. روی VPS هم مصرف CPU، حافظه، دیسک و صف پردازش باید در همان بازه دیده شود. یک عدد متوسط روزانه ممکن است اوج کوتاه اختلال را پنهان کند. افزایش منابع زمانی تصمیم روشن‌تری است که محدودیت مشخص یا نیاز ظرفیت مستند شده باشد.
گزارش مفید برای میزبان شامل نشانی، ساعت و منطقه زمانی، وضعیت ورود، چند نتیجه اندازه‌گیری و وضعیت کش است. مشخص کنید کدام صفحه سالم و کدام عملیات کند است. برای شروع بررسی عمومی از ابزار بررسی سلامت سایت آفاق هاست و برای بررسی فنی‌تر از خدمات مدیریت سایت و سرور استفاده کنید. مقایسه هاست لینوکس هم باید با نیاز همین برنامه انجام شود.
آزمون نهایی کاهش TTFB وردپرس
بعد از یک تغییر، همان نشانی‌ها را با شرایط ثبت‌شده دوباره بسنجید. مقاله عمومی، صفحه پویا و ورود کاربر را جدا بررسی کنید. اگر فقط کش گرم بهتر شده ولی درخواست تازه همچنان کند است، نتیجه را به همان محدوده نسبت بدهید. سپس نمایش محتوای اصلی و عملیات فروشگاه را کنترل کنید؛ پاسخ سریع همراه محتوای قدیمی یا سبد خرید اشتباه، بهینه‌سازی موفقی نیست.
پرسش‌های رایج
آیا کاهش TTFB به‌تنهایی رتبه گوگل را تضمین می‌کند؟
خیر. این کار به رفع تأخیر پاسخ کمک می‌کند، اما کیفیت و ارتباط محتوا، امکان خزش و تجربه کامل صفحه نیز باید بررسی شوند. نتیجه سرعت را با نتیجه رتبه یکی نگیرید.
آیا نصب Redis برای همه سایت‌ها لازم است؟
خیر. کش اشیای پایدار با کش کامل صفحه متفاوت است. نیاز آن را بر اساس بار دیتابیس، معماری میزبان و اندازه‌گیری عملیات بدون کش مشخص کنید.
چرا ابزارهای مختلف اعداد متفاوت می‌دهند؟
موقعیت آزمون، اتصال تازه یا تکراری، وضعیت کش، ورود کاربر و تعریف دقیق اندازه‌گیری می‌تواند متفاوت باشد. ابتدا شرایط و مرحله اندازه‌گیری را یکسان کنید.
منابع رسمی برای مطالعه بیشتر
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.