TTFB بالا دارید و نمیدانید مقصر کیست
سایت را باز میکنید. مرورگر چند ثانیه صفحه سفید نشان میدهد و بعد همهچیز یکجا بالا میآید. گزارش PageSpeed میگوید TTFB شما ۱.۸ ثانیه است. توسعهدهنده میگوید «سرور ما سریع است»، مدیر هاستینگ میگوید «کد شما مشکل دارد» و شما ماندهاید که پول را کجا خرج کنید.
واقعیت این است که هر دو ممکن است درست بگویند. TTFB (Time To First Byte) فقط زمان رسیدن اولین بایت به مرورگر نیست؛ مجموع سه بخش مجزاست: زمان شبکه، زمان صف و پردازش در سرور، و زمان ساخت پاسخ. اگر این سه را از هم جدا نکنید، هر بهینهسازیای کورکورانه است.
این مقاله دقیقاً برای همین لحظه نوشته شده است. نه برای تعریف TTFB، بلکه برای اینکه با چند دستور و یک روش اندازهگیری مشخص، بفهمید گلوگاه کجاست و کدام بهینهسازی واقعاً در مرورگر کاربر دیده میشود.
تفکیک زمان شبکه از زمان سرور با یک دستور
اولین ابزاری که نیاز دارید curl است. نه PageSpeed Insights، نه GTmetrix. چون آنها نتیجه نهایی را نشان میدهند، اما اینجا ما به جزئیات نیاز داریم. دستور زیر را از سروری خارج از ایران (مثلاً یک VPS در آلمان یا هلند) روی سایت خودتان اجرا کنید:
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.comخروجی چیزی شبیه این خواهد بود:
DNS: 0.042s
Connect: 0.187s
TLS: 0.351s
TTFB: 0.890s
Total: 1.240sحالا اعداد را تفسیر کنید. فاصله بین Connect و TLS زمان دستدادن امنیتی است. فاصله بین TLS و TTFB همان چیزی است که میخواهید: زمانی که سرور صرف کرد تا اولین بایت را بفرستد. اگر این عدد بالای ۰.۵ ثانیه باشد، مشکل از سرور یا کد شماست. اگر Connect و TLS بالا باشند اما TTFB پایین باشد، مشکل از مسیر شبکه است.
یک نکته مهم: این تست را از داخل ایران هم اجرا کنید. تفاوت فاحش بین نتیجه تست خارجی و داخلی، نشاندهنده مشکل تحریم، فیلترینگ یا کیفیت مسیر بینالمللی است. این را در نظر داشته باشید که نتیجه این تست از داخل ایران، به دلیل مسیرهای اینترنت بینالمللی، معمولاً بالاتر است.
اینجا اشتباه میکنند: تست از روی سیستم خودشان
رایجترین خطایی که دیدهام این است که مدیر سایت از لپتاپ خودش که به شبکه داخلی شرکت وصل است، تست میگیرد. نتیجه عالی است، اما کاربر در مشهد با اینترنت همراه، تجربهای کاملاً متفاوت دارد. تست باید از جایی گرفته شود که کاربر واقعی در آن است. ابزارهای ابزارهای سئو و وبمستر معمولاً از چند نقطه دنیا تست میگیرند، اما برای تشخیص اولیه، همین curl کافی است.
زمان سرور: جایی که بیشترین بهینهسازی ممکن است
فرض کنید TTFB شما ۰.۹ ثانیه است و از این مقدار، ۰.۶ ثانیه صرف پردازش در سرور شده است. این عدد یعنی سرور شما برای هر درخواست، ۶۰۰ میلیثانیه کار میکند. این مقدار برای یک صفحه ساده وردپرسی بدون کش، غیرعادی نیست. اما قابل قبول هم نیست.
اولین اقدام، فعالسازی کش صفحات است. در وردپرس، افزونهای مثل WP Rocket یا LiteSpeed Cache را نصب کنید و کش صفحه را روشن کنید. بعد از آن، TTFB را دوباره اندازه بگیرید. اگر عدد به زیر ۰.۲ ثانیه رسید، یعنی مشکل از پردازش PHP و کوئریهای دیتابیس بوده است. اگر نه، مقصر جای دیگری است.
دومین اقدام، بررسی کوئریهای دیتابیس است. اگر از MySQL استفاده میکنید، این دستور را در ترمینال سرور اجرا کنید:
mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"اگر عدد Slow_queries بالا باشد (بیش از چند صد در ساعت)، باید کوئریهای سنگین را پیدا کنید. افزونه Query Monitor در وردپرس میتواند دقیقاً نشان دهد کدام کوئری کند است و کدام افزونه مقصر است.
کش object cache را فراموش نکنید
کش صفحه فقط برای کاربران مهمان کار میکند. کاربر لاگینشده یا سبد خرید فعال، از کش صفحه بیبهره است. برای این موارد به Redis یا Memcached نیاز دارید. نصب Redis روی سرور و اتصال آن به وردپرس با افزونهای مثل Redis Object Cache، میتواند زمان پاسخ را برای درخواستهای داینامیک تا ۷۰٪ کاهش دهد. این عدد را من از روی تجربه میگویم، نه از روی کاتالوگ فروش.
زمان شبکه: وقتی مشکل از سرور نیست
حالا حالت دوم را در نظر بگیرید. TTFB از تست خارجی ۰.۳ ثانیه است، اما از داخل ایران ۱.۲ ثانیه. این یعنی سرور شما سریع است، اما مسیر شبکه بین کاربر ایرانی و سرور شما مشکل دارد. اینجا هیچ بهینهسازی کدی کمکی نمیکند.
راهحلها دو دستهاند. اول، استفاده از CDN با حضور در ایران یا منطقه نزدیک (ترکیه، امارات). دوم، انتقال سایت به سروری داخل ایران. انتخاب بین این دو به بودجه و نیاز شما بستگی دارد. اگر کاربران شما عمدتاً در ایران هستند و سایت شما تحریمپذیر نیست، سرور داخلی گزینه بهتری است. اگر مخاطب بینالمللی دارید، CDN با دیتاسنتر در خاورمیانه انتخاب منطقیتری است.
برای بررسی دقیقتر وضعیت DNS و زیرساخت دامنه خودتان، میتوانید از بررسی فنی دامنه و DNS استفاده کنید. گاهی مشکل از TTL بالای DNS است که باعث میشود کاربر به IP قدیمی متصل شود.
زمان مرورگر: بخشی که TTFB نشان نمیدهد
TTFB فقط تا اولین بایت را اندازه میگیرد. اما کاربر با اولین بایت که کاری ندارد. او منتظر است تا صفحه کامل رندر شود. بین این دو، مرورگر باید HTML را پردازش کند، CSS و جاوااسکریپت را دانلود و اجرا کند و تصاویر را بارگذاری کند. این بخش در TTFB دیده نمیشود اما در LCP (Largest Contentful Paint) دیده میشود.
سایتهایی هستند که TTFB عالی ۰.۱ ثانیهای دارند اما LCP بالای ۴ ثانیه. مشکل از جاوااسکریپت سنگین یا تصاویر بهینهنشده است. برای این موارد، TTFB را دست نزنید. به سراغ بهینهسازی تصاویر با فرمتهای جدید مثل WebP و AVIF بروید یا مشکل LCP را ریشهیابی کنید.
یک معیار ساده برای تشخیص اینکه مشکل از کجاست: اگر TTFB پایین است اما صفحه دیر بالا میآید، مشکل مرورگر است. اگر TTFB بالاست، مشکل از شبکه یا سرور است. این تفکیک ساده، ۸۰٪ از مسیر اشتباه بهینهسازی را حذف میکند.
کدام را اول کم کنیم؟
اگر TTFB شما بالای ۰.۸ ثانیه است، اول آن را کم کنید. چون هر بهینهسازی دیگری در مرورگر، روی یک پایه کند سوار میشود. اگر TTFB زیر ۰.۴ ثانیه است، به سراغ LCP و CLS بروید. این ترتیب را من در دهها سایت اجرا کردهام و جواب گرفته است.
استثنا هم وجود دارد. اگر سایت شما یک وباپلیکیشن با تعامل سنگین است و کاربر بعد از بارگذاری اولیه، زمان زیادی در صفحه میماند، شاید بهینهسازی INP (Interaction to Next Paint) مهمتر از TTFB باشد. اما برای ۹۰٪ سایتهای محتوایی و فروشگاهی، قانون بالا درست است.
برای یک بررسی کامل از تمام معیارهای سرعت، راهنمای عملی Core Web Vitals را بخوانید. همچنین اگر تازه شروع کردهاید، راهنمای کامل افزایش سرعت سایت مسیر گامبهگام را نشان میدهد.
یک سناریوی واقعی از خطای رایج
چند ماه پیش سایتی را بررسی میکردم که TTFB آن ۲.۲ ثانیه بود. مدیر سایت یک هفته روی بهینهسازی کد وقت گذاشته بود و نتیجهای نگرفته بود. تست curl نشان داد که زمان TLS حدود ۱.۴ ثانیه است. یعنی مشکل از دستدادن امنیتی بود، نه از کد. بررسیها نشان داد که سرور از TLS 1.0 با سیپرفرهای قدیمی استفاده میکند و برخی مسیرهای شبکه، این نوع اتصال را با تأخیر بالا پاسخ میدهند. با ارتقای پیکربندی SSL به TLS 1.3 و فعالسازی OCSP Stapling، TTFB به ۰.۴ ثانیه رسید. بدون تغییر حتی یک خط کد.
این خطا را خیلیها تکرار میکنند: فرض میکنند TTFB بالا یعنی کد بد است. در حالی که گاهی فقط یک پیکربندی اشتباه در وبسرور یا SSL است.
پرسشهای پرتکرار
TTFB مناسب برای سئو چقدر است؟
گوگل عدد دقیقی اعلام نکرده، اما تجربه نشان میدهد TTFB زیر ۰.۲ ثانیه عالی، زیر ۰.۵ ثانیه خوب و بالای ۰.۸ ثانیه نیازمند بررسی است. این اعداد برای کاربران ایرانی با در نظر گرفتن شرایط شبکه، باید حدود ۳۰٪ بالاتر در نظر گرفته شوند.
تفاوت TTFB و زمان بارگذاری کامل صفحه چیست؟
TTFB فقط زمان تا رسیدن اولین بایت است. زمان بارگذاری کامل، شامل دانلود همه منابع (CSS، جاوااسکریپت، تصاویر) و رندر نهایی صفحه است. یک سایت میتواند TTFB پایین و زمان بارگذاری بالا داشته باشد، یا برعکس.
آیا CDN باعث کاهش TTFB میشود؟
بله، اگر مشکل از مسیر شبکه باشد. CDN با قرار دادن محتوا در نزدیکی کاربر، زمان رفتوبرگشت شبکه را کاهش میدهد. اما اگر مشکل از پردازش کند سرور اصلی باشد، CDN فقط مشکل را پنهان میکند و TTFB از مبدأ همچنان بالاست.
چرا TTFB از داخل ایران با خارج از ایران متفاوت است؟
به دلیل مسیرهای اینترنت بینالمللی و نبود ارتباط مستقیم با بسیاری از دیتاسنترهای خارجی. این تفاوت گاهی تا ۵ برابر میشود. اگر کاربران شما در ایران هستند، تست را از داخل ایران انجام دهید و بر اساس آن تصمیم بگیرید.
دیدگاهها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!