TTFB Optimization در وردپرس چرا از سرور شروع می‌شود؟

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

TTFB (Time To First Byte) پیش‌نیاز همه معیارهای Core Web Vitals است، چون LCP و INP نمی‌توانند سریع‌تر از لحظه‌ای باشند که اولین بایت پاسخ به مرورگر می‌رسد.

سه منبع اصلی تأخیر در TTFB وجود دارد: زمان شبکه، زمان پردازش سرور و زمان تولید پاسخ در لایه اپلیکیشن.

بدون تفکیک این سه منبع، هر تلاش برای بهبود TTFB می‌تواند هزینه‌ای بدون بازدهی ایجاد کند.

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

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

TTFB دقیقاً چه چیزی را اندازه می‌گیرد

TTFB (Time To First Byte) معیاری است که فاصله زمانی میان ارسال درخواست HTTP از سمت مرورگر و دریافت اولین بایت از پاسخ را اندازه می‌گیرد. این معیار، در واقع مجموع چند مرحله است که هر یک می‌تواند منبع تأخیر باشد.

مرحله اول، حل نام دامنه است. مرورگر باید نام دامنه را به آدرس IP تبدیل کند. این مرحله، با پرس‌وجو از سرور DNS انجام می‌شود و زمان آن بستگی به فاصله کاربر از سرور DNS و کارایی آن دارد.

مرحله دوم، برقراری اتصال TCP است. مرورگر با آدرس IP مقصد، یک اتصال سه‌مرحله‌ای برقرار می‌کند. زمان این مرحله به فاصله جغرافیایی بین کاربر و سرور بستگی دارد و با هر رفت و برگشت شبکه افزایش می‌یابد.

مرحله سوم، انجام مذاکره TLS است. اگر سایت با HTTPS سرو می‌شود، یک مرحله اضافه برای توافق بر کلید رمزنگاری انجام می‌گیرد. این مرحله، در نسخه‌های قدیمی TLS چند رفت و برگشت نیاز دارد و در نسخه‌های جدید، این تعداد کاهش یافته است.

مرحله چهارم، پردازش درخواست در سرور است. سرور درخواست را دریافت می‌کند، در لایه وب‌سرور پردازش می‌کند، در صورت نیاز به PHP-FPM می‌سپارد، کد وردپرس و افزونه‌ها اجرا می‌شوند و در نهایت پاسخ ساخته می‌شود.

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

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

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

چرا TTFB از سرور شروع می‌شود

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

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

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

مرحله برقراری اتصال TCP و مذاکره TLS نیز اگرچه در سمت مرورگر آغاز می‌شود، اما زمان آن تحت تأثیر موقعیت سرور و پیکربندی آن است. سرور نزدیک‌تر به کاربر، زمان کمتری برای این مراحل نیاز دارد.

مرحله حل نام دامنه، تنها مرحله‌ای است که عمدتاً مستقل از سرور عمل می‌کند. اما حتی این مرحله نیز با انتخاب سرور DNS سریع و استفاده از رکوردهای CNAME مناسب، قابل بهبود است.

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

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

تفکیک سه منبع تأخیر در TTFB

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

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

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

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

منبع تأخیر	بازه معمول در سایت‌های وردپرسی	راه‌حل اصلی
شبکه (DNS + TCP + TLS)	۵۰-۲۰۰ میلی‌ثانیه	CDN و سرور نزدیک‌تر
وب‌سرور و PHP	۱۰۰-۸۰۰ میلی‌ثانیه	OPcache و PHP-FPM Tuning
پایگاه داده	۵۰-۵۰۰ میلی‌ثانیه	ایندکس‌گذاری و بهینه‌سازی کوئری
تولید پاسخ	۵۰-۳۰۰ میلی‌ثانیه	کش و بهینه‌سازی قالب
ارسال اولین بایت	۵-۵۰ میلی‌ثانیه	پیکربندی وب‌سرور

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

ابزار Chrome DevTools در تب Network، تفکیک دقیق مراحل را نمایش می‌دهد. ستون‌های DNS Lookup، Initial Connection و SSL زمان هر مرحله را نشان می‌دهند و Waiting (TTFB) زمان پردازش سرور را مشخص می‌کند.

با تحلیل این ستون‌ها در ابزار توسعه‌دهنده مرورگر، می‌توان منبع غالب تأخیر را مشخص کرد. اگر زمان Waiting غالب باشد، مشکل در سرور است. اگر زمان SSL یا Initial Connection غالب باشد، مشکل در لایه شبکه است.

زمان DNS، اتصال و TLS

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

حل نام دامنه، اولین مرحله است. زمان این مرحله بستگی به سرور DNS مورد استفاده و کارایی آن دارد. استفاده از سرورهای DNS سریع مانند Cloudflare یا Google DNS می‌تواند این زمان را کاهش دهد.

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

# Check DNS resolution time
dig example.com +stats
nslookup -debug example.com

این دستورات، زمان حل نام دامنه را نشان می‌دهند. اگر این زمان بالای ۵۰ میلی‌ثانیه باشد، انتخاب سرور DNS سریع‌تر می‌تواند کمک کند.

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

مرحله سوم، مذاکره TLS است. در TLS نسخه ۱.۲، دو رفت و برگشت اضافه نیاز است. در TLS نسخه ۱.۳، این تعداد به یک رفت و برگشت کاهش یافته است. فعال‌سازی TLS 1.3 در سرور، کاهش محسوسی در این مرحله ایجاد می‌کند.

# Nginx TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

پارامتر ssl_session_cache اجازه می‌دهد اتصال‌های بازگشتی از کاربران، از کش نشست استفاده کنند و نیاز به مذاکره کامل TLS را حذف کنند. این پارامتر، به‌ویژه در سایت‌هایی که کاربران بازدیدهای مکرر دارند، اثر محسوسی دارد.

افزون بر این، استفاده از HTTP/2 و HTTP/3 می‌تواند تعداد اتصال‌های TCP را برای یک صفحه کاهش دهد و زمان کل را بهبود بخشد. HTTP/2 چندگانه‌سازی درخواست‌ها روی یک اتصال را ممکن می‌کند و HTTP/3 روی پروتکل QUIC سوار می‌شود که مذاکره اتصال را سریع‌تر انجام می‌دهد.

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

لایه PHP و اثر آن بر TTFB

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

سه عامل اصلی بر سرعت این لایه اثر می‌گذارند. عامل اول، نسخه PHP است. نسخه‌های جدیدتر PHP سرعت اجرای کد را بهبود می‌دهند. مهاجرت از PHP 7 به PHP 8 می‌تواند سرعت اجرا را ۲۰ تا ۳۰ درصد افزایش دهد. مقایسه تفصیلی این نسخه‌ها در تفاوت PHP ۷ و PHP ۸ آمده است.

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

عامل سوم، پیکربندی PHP-FPM است. این لایه، مدیریت فرآیندهای PHP را بر عهده دارد و پیکربندی درست آن، به کاهش زمان انتظار برای اجرای کد کمک می‌کند. اصول تفصیلی در تنظیم PHP-FPM برای وردپرس آمده است.

; OPcache configuration
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 16229
opcache.validate_timestamps = 0
opcache.interned_strings_buffer = 16

; PHP-FPM configuration
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500

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

مسئله مهم دیگر، تعداد افزونه‌های فعال است. هر افزونه، فایل‌های PHP اضافه‌ای بارگذاری می‌کند که زمان راه‌اندازی را افزایش می‌دهد. کاهش افزونه‌های غیرضروری، یکی از مؤثرترین راه‌ها برای کاهش زمان پردازش است. اصول شناسایی افزونه‌های اضافی در شناسایی افزونه‌های اضافی وردپرس آمده است.

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

لایه پایگاه داده و کوئری‌های کند

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

سه دسته کوئری کند در وردپرس وجود دارد. دسته اول، کوئری‌های بدون ایندکس است که موتور پایگاه داده را مجبور به اسکن کامل جدول می‌کند. دسته دوم، کوئری‌های با JOIN های متعدد روی جدول wp_postmeta است. دسته سوم، کوئری‌های تحلیلی روی داده‌های حجیم است.

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

سطح دوم، بازنویسی کوئری‌ها است. تبدیل زیرکوئری‌های همبسته به JOIN، حذف توابع روی ستون‌های ایندکس‌شده و محدودسازی نتایج با LIMIT، همه می‌توانند زمان اجرا را به‌طور محسوس کاهش دهند. اصول تفصیلی در بهینه‌سازی کوئری در وردپرس آمده است.

سطح سوم، انتقال بخشی از داده به جدول اختصاصی است. اگر حجم جدول wp_postmeta بسیار بالا باشد و کوئری‌ها به چند JOIN نیاز داشته باشند، انتقال ویژگی‌های پرتکرار به جدول اختصاصی می‌تواند زمان پاسخ را چند مرتبه کاهش دهد. اصول این تصمیم در جداول اختصاصی در وردپرس آمده است.

-- Analysis query for slow query log
SELECT
    DIGEST_TEXT,
    COUNT_STAR,
    SUM_TIMER_WAIT,
    AVG_TIMER_WAIT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 20;

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

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

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

لایه کش و رفتار آن با TTFB

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

چند نوع کش بر TTFB اثر می‌گذارند. کش صفحه (Page Cache) که کل خروجی HTML را ذخیره می‌کند و در درخواست‌های بعدی، بدون اجرای وردپرس پاسخ می‌دهد. کش لایه وب‌سرور (FastCGI Cache یا Varnish) که پیش از رسیدن درخواست به PHP پاسخ می‌دهد. کش شیء (Object Cache) که نتایج کوئری‌های تکراری را در حافظه نگه می‌دارد. کش مرورگر که بر پایه هدرهای Cache-Control عمل می‌کند.

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

در لایه وب‌سرور، FastCGI Cache و Varnish دو گزینه اصلی هستند. FastCGI Cache بخشی از Nginx است و پاسخ‌ها را روی دیسک ذخیره می‌کند. اصول پیکربندی آن در پیکربندی Nginx FastCGI Cache برای وردپرس آمده است.

Varnish یک سرویس مستقل است که پاسخ‌ها را در حافظه نگه می‌دارد و سطح کنترل بالاتری ارائه می‌دهد. اصول تفصیلی در Varnish Cache برای وردپرس آمده است.

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

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

لایه وب‌سرور و پیکربندی آن

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

در Nginx، پارامترهای کلیدی شامل تعداد Worker Process، تعداد Worker Connections و پارامترهای Keep-Alive است. اصول تفصیلی در بهینه‌سازی Nginx برای وردپرس آمده است.

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}

http {
    keepalive_timeout 30;
    keepalive_requests 100;
    client_max_body_size 64m;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
}

پارامتر sendfile اجازه می‌دهد فایل‌های استاتیک بدون عبور از حافظه کاربر منتقل شوند. پارامتر tcp_nopush و tcp_nodelay رفتار ارسال بسته‌های شبکه را بهینه می‌کنند.

در Apache، انتخاب MPM مناسب و تنظیم پارامترهای مربوطه اهمیت دارد. اصول تفصیلی در بهینه‌سازی Apache برای وردپرس آمده است.

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

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

شبکه توزیع محتوا و لایه لبه

شبکه توزیع محتوا (Content Delivery Network یا CDN) یکی از مؤثرترین ابزارها برای کاهش تأخیر شبکه است. با نزدیک‌کردن محتوا به کاربر، زمان DNS، اتصال و TLS کاهش می‌یابد.

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

# Example Cloudflare configuration concept
# - Static assets cached at edge
# - HTML cached with short TTL
# - Dynamic content bypasses cache but still benefits from edge network

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

مسائل مرتبط با پیکربندی CDN و هماهنگی آن با سرور مبدأ در نقش CDN در بهبود سرعت سایت و راه‌اندازی CDN برای وردپرس آمده است.

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

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

OPcache و کاهش زمان راه‌اندازی PHP

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

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

سه پارامتر کلیدی در پیکربندی OPcache وجود دارد. پارامتر opcache.memory_consumption حافظه اختصاص‌یافته به کش را تعیین می‌کند. پارامتر opcache.max_accelerated_files سقف تعداد فایل‌های کش‌شده را مشخص می‌کند. پارامتر opcache.validate_timestamps رفتار به‌روزرسانی کش را کنترل می‌کند.

opcache.memory_consumption = 256
opcache.max_accelerated_files = 16229
opcache.validate_timestamps = 0
opcache.revalidate_freq = 0
opcache.interned_strings_buffer = 16

پارامتر validate_timestamps روی مقدار صفر، بهترین عملکرد را در محیط تولید می‌دهد. اما این تنظیم یک پیامد دارد: تغییرات کد بدون پاک‌سازی صریح OPcache اعمال نمی‌شوند. این ویژگی باید در جریان استقرار لحاظ شود.

مسائل تفصیلی این لایه، از جمله هماهنگی با PHP-FPM و رفتار در محیط‌های چندسایتی، در تنظیم بهینه OPcache در وردپرس آمده است.

نکته تکمیلی، تفکیک OPcache وب و CLI است. این دو محیط پیکربندی جدا دارند و اختلاط آن‌ها می‌تواند به سردرگمی منجر شود.

اندازه‌گیری دقیق TTFB

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

ابزار اول، Chrome DevTools است. تب Network این ابزار، تفکیک دقیق مراحل را نشان می‌دهد.

// Open Chrome DevTools, go to Network tab
// Reload the page, click on the main document request
// In the Timing tab, observe:
// - DNS Lookup
// - Initial Connection
// - SSL
// - Waiting (TTFB)
// - Content Download

این تفکیک، تصویر روشنی از منبع غالب تأخیر ارائه می‌دهد.

ابزار دوم، خط فرمان curl است. با این ابزار می‌توان TTFB را در بازه‌های مختلف اندازه گرفت.

curl -w "DNS: %{time_namelookup}s
Connect: %{time_connect}s
TLS: %{time_appconnect}s
TTFB: %{time_starttransfer}s
Total: %{time_total}s
" -o /dev/null -s https://example.com/

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

ابزار سوم، PageSpeed Insights است که بر پایه داده‌های واقعی کاربران (Field Data) تحلیل ارائه می‌دهد. داده‌های میدانی می‌توانند تصویر متفاوتی از داده‌های آزمایشگاهی ارائه دهند، چون شرایط شبکه و دستگاه کاربران را نیز لحاظ می‌کنند.

ابزار چهارم، WebPageTest است که امکان آزمایش از مناطق جغرافیایی مختلف را فراهم می‌کند. این ابزار برای سایت‌هایی که کاربرانشان در مناطق مختلف پراکنده‌اند، مفید است.

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

TTFB در فروشگاه ووکامرس

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

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

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

لایه دوم، کش جزئی با استفاده از Edge Side Includes است. در این رویکرد، صفحه اصلی از کش سرو می‌شود اما بخش‌های پویا مانند سبد خرید کوچک، از یک درخواست جداگانه ساخته می‌شوند. اصول تفصیلی این رویکرد در Varnish Cache برای وردپرس آمده است.

لایه سوم، بهینه‌سازی کوئری‌های ووکامرس است. جداول ووکامرس مانند wp_wc_order_stats و wp_wc_order_product_lookup در حجم بالا نیازمند ایندکس دقیق هستند. اصول تفصیلی در بهینه‌سازی دیتابیس ووکامرس آمده است.

لایه چهارم، انتقال گزارش‌گیری به جریان پس‌زمینه است. اگر گزارش‌های فروش در پنل مدیریت کند باشند، اجرای آن‌ها در زمان درخواست کاربر، TTFB را افزایش می‌دهد. انتقال این گزارش‌ها به Action Scheduler، این بار را از مسیر کاربر حذف می‌کند. اصول تفصیلی در Action Scheduler در وردپرس آمده است.

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

جدول تصمیم‌گیری بهینه‌سازی

منبع تأخیر	ابزار تشخیص	راه‌حل اصلی	اثر تخمینی
DNS و اتصال	Chrome DevTools	CDN و DNS سریع	۵۰-۱۵۰ میلی‌ثانیه
پردازش PHP	profiling	OPcache و PHP-FPM	۱۰۰-۳۰۰ میلی‌ثانیه
پایگاه داده	Slow Query Log	ایندکس و کش شیء	۱۰۰-۵۰۰ میلی‌ثانیه
تولید پاسخ	query monitor	کش صفحه	۱۰۰-۴۰۰ میلی‌ثانیه
لایه وب‌سرور	server logs	پیکربندی وب‌سرور	۲۰-۱۰۰ میلی‌ثانیه

اشتباهات رایج

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

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

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

چهارمین اشتباه، اعتماد به تنظیمات پیش‌فرض PHP-FPM است. این تنظیمات برای پروژه‌های کوچک طراحی شده‌اند و در سایت‌های متوسط و بزرگ نیازمند بازبینی هستند.

پنجمین اشتباه، بی‌توجهی به کوئری‌های کند است. هر کوئری کند، به‌طور مستقیم TTFB را افزایش می‌دهد. تحلیل دوره‌ای با Slow Query Log، بخش ضروری هر پروژه بهینه‌سازی است.

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

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

هشتمین اشتباه، فراموش کردن پاک‌سازی OPcache در جریان استقرار است. اگر OPcache پاک نشود، تغییرات کد اعمال نمی‌شوند. اصول تفصیلی در پیاده‌سازی CI/CD برای پروژه‌های وردپرسی آمده است.

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

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

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

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

پرسش‌های پرتکرار درباره TTFB در وردپرس

TTFB چیست و چه تفاوتی با زمان بارگذاری صفحه دارد؟

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

مقدار مطلوب TTFB چقدر است؟

مقدار کمتر از ۲۰۰ میلی‌ثانیه عالی است. مقدار ۲۰۰ تا ۵۰۰ میلی‌ثانیه قابل قبول است. مقدار بیش از ۵۰۰ میلی‌ثانیه نیازمند بررسی است. این اعداد به نوع سایت و شرایط شبکه کاربران بستگی دارند.

چرا TTFB از سرور شروع می‌شود؟

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

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

با ابزارهایی مانند Chrome DevTools، دستور curl با پارامتر -w و ابزارهای آنلاین مانند WebPageTest. اندازه‌گیری در بازه‌های مختلف، تصویر واقع‌بینانه‌تری ارائه می‌دهد.

تفاوت TTFB در دسکتاپ و موبایل چیست؟

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

آیا TTFB روی سئو اثر دارد؟

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

چگونه OPcache بر TTFB اثر می‌گذارد؟

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

آیا کش TTFB را کاهش می‌دهد؟

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

آیا CDN بر TTFB اثر دارد؟

بله، به‌طور محسوس. CDN با نزدیک‌کردن محتوا به کاربر، زمان DNS، اتصال، TLS و انتقال داده را کاهش می‌دهد. این کاهش، مستقیماً به بهبود TTFB منجر می‌شود.

چگونه TTFB را در فروشگاه ووکامرس بهبود دهم؟

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

آیا بهینه‌سازی TTFB نیازمند تغییر کد است؟

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

آیا TTFB در محیط لوکال هم قابل اندازه‌گیری است؟

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

چند وقت یک‌بار باید TTFB را بررسی کنم؟

در سایت‌های پربازدید، بررسی هفتگی یا ماهانه توصیه می‌شود. در سایت‌های با تغییرات مکرر، بررسی پس از هر تغییر عمده در پیکربندی یا افزونه‌ها ضروری است.

آیا TTFB بین صفحات مختلف متفاوت است؟

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

آیا HTTP/3 بر TTFB اثر دارد؟

بله، HTTP/3 با کاهش تعداد رفت و برگشت‌های شبکه، زمان اتصال را کاهش می‌دهد و این کاهش به بهبود TTFB منجر می‌شود. این تأثیر در شبکه‌های با کیفیت پایین محسوس‌تر است.

آیا TTFB برای همه کاربران یکسان است؟

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

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

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

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