کاهش پینگ و تأخیر سایت معمولاً از جایی شروع میشود که کمتر کسی نگاهش میکند: نقشه. سایت را بهینه کردهاید، تصاویر را فشرده کردهاید، کش هم فعال است — اما صفحه هنوز با مکث بالا میآید؟ پیش از آنکه دوباره سراغ کد بروید بپرسید: سرور کجاست؟ اینجا میبینیم پینگ و TTFB چه هستند، هر بازدید چند رفتوبرگشت هزینه دارد، چطور اندازهشان بگیریم و چرا محل دیتاسنتر مهمترین اهرم شماست.
ping چیست و تأخیر سایت یعنی چه؟
اگر بپرسید ping چیست، سادهترین جواب این است: زمان یک رفتوبرگشت. کامپیوتر شما یک بستهی کوچک به سرور میفرستد، سرور جواب میدهد، و مدت این رفتوبرگشت بر حسب میلیثانیه ثبت میشود. به این عدد RTT یا «تأخیر» (Latency) هم میگویند؛ تعریف RTT در MDN همین است: زمان رسیدن بسته به مقصد بهعلاوهی زمان بازگشت تأییدیهاش.
تشبیهش پیک موتوری است: هرقدر هم رستوران سریع باشد، اگر پیک از آن سر شهر بیاید مسیرِ رفتوبرگشت کف زمان تحویل را تعیین میکند. باز شدن یک صفحهی وب هم یک رفتوبرگشت نیست، چند رفتوبرگشت پشتسرهم است:
- DNS — ترجمهی دامنه به آیپی (حداقل یک رفتوبرگشت اگر کش نباشد)؛
- TCP — دستدادن اولیه با سرور (یک رفتوبرگشت)؛
- TLS — برقراری اتصال امن HTTPS (معمولاً یک تا دو رفتوبرگشت)؛
- HTTP — ارسال درخواست و دریافت اولین بایت پاسخ.
مجموع اینها بهعلاوهی زمان پردازش سرور میشود TTFB (Time To First Byte): فاصلهی کلیک کاربر تا اولین بایت HTML. پس هر میلیثانیه پینگ تقریباً چهار برابر در TTFB ضرب میشود؛ یعنی تاخیر سایت سریعتر از تصور شما انباشته میشود.
کنار میانگین دو عدد دیگر را هم ببینید: نوسان (Jitter)، پراکندگی همین عدد بین بستههای پیاپی، و گمشدن بسته (Packet Loss). پینگ ثابتِ ۹۰ میلیثانیه تجربهی بهتری میسازد تا پینگی که بین ۴۰ و ۲۰۰ میپرد. ضمناً ping با ICMP کار میکند، نه HTTP؛ پس فقط «کف» تأخیر مسیر را نشان میدهد.
چرا فاصلهی فیزیکی و مسیریابی حرف آخر را میزنند؟
نور در فیبر نوری حدود ۲۰۰ هزار کیلومتر بر ثانیه حرکت میکند — دوسوم سرعت نور در خلأ، چون ضریب شکست شیشهی فیبر نزدیک ۱٫۵ است. یک قاعدهی سرانگشتی از همین عدد بیرون میآید: هر ۱۰۰ کیلومتر مسیر، حدود یک میلیثانیه به رفتوبرگشت اضافه میکند. مسیر فیبری تهران تا فرانکفورت (که هیچوقت خط مستقیم نیست) حدود ۴ تا ۵ هزار کیلومتر است؛ یعنی فقط فیزیکِ رفتوبرگشت ۴۰ تا ۵۰ میلیثانیه هزینه دارد، پیش از هر صف و هر ازدحامی. این کف تئوری است و هیچ بهینهسازی نرمافزاری آن را نمیشکند.
در عمل عدد واقعی بدتر است: ترافیک از دهها روتر (hop) عبور میکند، در گذرگاه بینالملل صف میکشد و در ساعات پیک با بقیهی ترافیک خروجی کشور رقابت میکند. نتیجه؟ پینگی که ظهر ۹۰ میلیثانیه است شب میشود ۱۵۰ با نوسان بالا. در مقابل، سرور داخل کشور یعنی مسیر کوتاه، هاپ کم و نوسان ناچیز.
نکتهی غافلگیرکننده اینکه اینترنت مسیر را بر اساس سیاستهای پیرینگ اپراتورها انتخاب میکند، نه کوتاهترین خط روی نقشه — برای همین تغییر اپراتور گاهی بدون جابهجایی جغرافیایی ۲۰ تا ۳۰ میلیثانیه تفاوت میسازد.
هر بازدید چند رفتوبرگشت هزینه دارد؟
بودجهی یک بازدید تازه و بدون کش:
| مرحله | رفتوبرگشت لازم | با پینگ ۱۵ms | با پینگ ۱۲۰ms |
|---|---|---|---|
| جستوجوی DNS (کشنشده) | ۱ یا بیشتر | ۱۵ms | ۱۲۰ms |
| دستدادن TCP | ۱ | ۱۵ms | ۱۲۰ms |
| دستدادن TLS 1.3 | ۱ | ۱۵ms | ۱۲۰ms |
| TLS 1.2 بهجای آن | ۲ | ۳۰ms | ۲۴۰ms |
| درخواست HTTP تا اولین بایت | ۱ + پردازش سرور | ۱۵ms + | ۱۲۰ms + |
| جمع تا اولین بایت با TLS 1.3 | ۴ | حدود ۶۰ms | حدود ۴۸۰ms |
ستون آخر تجربهی کاربر ایرانیِ یک سرور اروپایی است: نزدیک نیمثانیه سکوت پیش از رسیدن اولین بایت. راهنمای TTFB در web.dev توصیه میکند TTFB زیر ۰٫۸ ثانیه بماند؛ روی مسیر پرتأخیر، بخش عمدهی این بودجه پیش از اجرای یک خط کد سوخته است.
تأخیر را اندازه بگیرید: ping، mtr و curl
حدس نزنید؛ اندازه بگیرید. سادهترین ابزار ping است:
ping -c 5 example.com
PING example.com (203.0.113.10) 56(84) bytes of data.
64 bytes from 203.0.113.10: icmp_seq=1 ttl=54 time=118 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=54 time=121 ms
64 bytes from 203.0.113.10: icmp_seq=3 ttl=54 time=117 ms
64 bytes from 203.0.113.10: icmp_seq=4 ttl=54 time=131 ms
64 bytes from 203.0.113.10: icmp_seq=5 ttl=54 time=122 ms
--- example.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 117.412/121.905/131.044/5.104 msخط آخر را بخوانید: min نزدیکترین چیز به تأخیر خالص انتشار است، چون نویز صف از آن حذف شده؛ mdev همان نوسان است و اگر از ده درصد میانگین بیشتر شد مسیرتان شلوغ است. packet loss غیرصفر هم مهمتر از هر عدد دیگری در این خروجی است.
پیدا کردن هاپ مقصر با mtr
برای دیدن کل مسیر از mtr استفاده کنید — ترکیب ping و traceroute؛ در اوبونتو و دبیان با sudo apt install mtr-tiny و در راکی و آلما با sudo dnf install mtr نصب میشود:
mtr -rwzc 20 example.com
HOST: workstation Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.1.1 0.0% 20 0.9 1.0 0.7 2.1 0.3
2. AS58224 10.21.4.1 0.0% 20 6.4 7.1 5.9 14.2 1.8
3. AS58224 tehran-core-1.example-isp.ir 0.0% 20 9.8 10.4 9.1 19.7 2.2
4. AS49666 border-gw.example-transit.net 0.0% 20 11.2 12.0 10.6 21.3 2.4
5. AS49666 fra-ix.example-transit.net 0.0% 20 114.7 118.9 113.2 141.5 6.9
6. AS24940 core.example-dc.de 0.0% 20 116.1 119.4 114.0 138.8 5.7
7. AS24940 203.0.113.10 0.0% 20 117.4 121.9 117.1 131.0 5.1این خروجی یک داستان کامل است: تا هاپ چهارم داخل کشور هستیم و تأخیر زیر ۱۳ میلیثانیه است؛ بین هاپ چهارم و پنجم عدد از ۱۲ به ۱۱۹ میپرد — همانجا که ترافیک از گذرگاه بینالملل عبور میکند — و بعد از آن چیزی اضافه نمیشود. هیچ تنظیمی روی سرور مقصد آن جهش ۱۰۷ میلیثانیهای را برنمیگرداند.
اندازهگیری چیزی که کاربر حس میکند: curl
ping تأخیر شبکه را میدهد؛ TTFB واقعی را curl نشان میدهد:
curl -o /dev/null -s -w "DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
TTFB: %{time_starttransfer}s
Total: %{time_total}s
" https://example.com/
DNS: 0.0043s
TCP: 0.1261s
TLS: 0.2588s
TTFB: 0.4102s
Total: 0.9873sاین اعداد تجمعی هستند، نه مستقل؛ برای سهم هر مرحله باید تفریق کنید. اینجا DNS تقریباً رایگان بود (پاسخ کششده)، TCP حدود ۱۲۲ میلیثانیه گرفت — یعنی پینگ مسیر همین حدود است — TLS ۱۳۳ میلیثانیهی دیگر، و از پایان TLS تا اولین بایت ۱۵۱ میلیثانیه که جمع یک رفتوبرگشت با زمان پردازش برنامه است. پس سهچهارم TTFB این صفحه هزینهی فاصله بوده، نه کندی کد. برای جداکردن سهم شبکه، همین دستور را روی خود سرور علیه 127.0.0.1 بزنید.
برای دیدن وضع کلی سایت از بیرون هم آزمون رایگان سرعت سایت چند نمونه میگیرد و میانهی TTFB، زنجیرهی ریدایرکت، حجم صفحه و وضعیت SSL را گزارش میکند. یک نکتهی صادقانه: این ابزار درخواست را از سرور خودِ مهران هاست بیرون از ایران میفرستد؛ پس عددش را برای مقایسهی قبل و بعدِ خودتان بخوانید، نه بهعنوان تجربهی بازدیدکنندهی ایرانی.
| نشانه | علت محتمل | کار بعدی |
|---|---|---|
| پینگ بالا اما یکنواخت، mdev پایین | کف فیزیکی مسیر و فاصلهی جغرافیایی | سرور را به مخاطب نزدیک کنید؛ تنظیمات کمکی نمیکند |
| پینگ خوب ولی TTFB بالا | کندی برنامه یا دیتابیس، نه شبکه | همان curl را روی 127.0.0.1 بزنید و مقایسه کنید |
| پینگ نوسانی و mdev بالا، شبها | ازدحام و صف در گذرگاه بینالملل | با mtr هاپ جهش را پیدا کنید |
| گمشدن بسته از یک هاپ تا مقصد | لینک یا تجهیز معیوب در مسیر | خروجی mtr را برای اپراتور بفرستید |
| فاصلهی زیاد time_connect تا time_appconnect | TLS نسخهی قدیمی یا بدون ازسرگیری | TLS 1.3 و ازسرگیری نشست را فعال کنید |
کاهش پینگ سرور با انتخاب دیتاسنتر درست
اعداد واقعی برای کاربر داخل ایران تقریباً چنیناند:
| محل سرور | پینگ معمول از ایران | TTFB تقریبی (HTTPS) | نوسان |
|---|---|---|---|
| دیتاسنتر ایران | ۱ تا ۲۰ میلیثانیه | زیر ۱۰۰ میلیثانیه | بسیار کم |
| اروپا (آلمان، هلند) | ۸۰ تا ۱۵۰ میلیثانیه | ۴۰۰ تا ۷۰۰ میلیثانیه | متوسط تا زیاد |
| آمریکای شمالی | ۱۵۰ تا ۲۵۰ میلیثانیه | بالای ۷۰۰ میلیثانیه | زیاد |
یعنی برای مخاطب داخلی، جابهجایی سرور از اروپا به داخل کشور بهتنهایی میتواند TTFB را چهار تا هفت برابر بهتر کند — کاری که از هیچ افزونهی کش و فشردهسازی برنمیآید.
یک تبصره: ستون اول برای خط ثابت است. روی اینترنت همراه بخش زیادی از تأخیر در شبکهی رادیویی ساخته میشود و حتی برای سروری در همان شهر ۳۰ تا ۷۰ میلیثانیه طبیعی است؛ پیش از متهمکردن دیتاسنتر، از خط ثابت هم تست کنید.
این اعداد برای سئو و فروش یعنی چه؟
گوگل در Core Web Vitals مستقیماً سرعت پاسخ را میسنجد. مستندات LCP در web.dev صریح میگوید زمان اتصال، زمان ریدایرکت و تأخیرهای TTFB داخل عدد LCP شمرده میشوند و آستانهی «خوب» ۲٫۵ ثانیه است؛ یعنی نیمثانیهای که در بودجهی رفتوبرگشت سوزاندیم، پیش از رندر شدن چیزی، از همان سهم کم شده است. کاهش پینگ سرور اینجا مستقیم روی همان عدد اثر میگذارد.
وقتی عدد پینگ خوب است اما تجربه بد
گاهی میانگین پینگ آبرومند است و کاربر باز از کندی مینالد. مظنون اول صف در تجهیزات میانی است: وقتی لینکی اشباع میشود بستهها در بافرهای بزرگ روتر صف میکشند. تشخیصش ساده است: ping را حین یک دانلود سنگین اجرا کنید؛ اگر عدد از ۲۰ به ۳۰۰ پرید، مشکل ظرفیت لینک شماست، نه سرور. مظنون دوم گمشدن بسته است: یک درصد بیضرر به نظر میرسد، اما TCP هر بستهی گمشده را با یک رفتوبرگشت اضافه جبران میکند و پنجرهی ارسال را کوچک میکند.
و مظنون سوم به سرور شما ربطی ندارد: خودِ صفحه. اگر قالب به فونت و اسکریپت روی دامنههای خارجی اشاره کند، مرورگر برای هرکدام یک مسیر مستقل و پرتأخیر طی میکند — حتی اگر سرور شما داخل کشور باشد. روش حذف این وابستگیها در راهنمای کندی سایت روی نت ملی آمده است.
چه تنظیمهایی روی سرور واقعاً رفتوبرگشت کم میکنند؟
وقتی نمیتوانید فاصله را کم کنید، تنها راه کمکردن تعداد رفتوبرگشتهاست. فهرست بهترتیب اثر:
- ریدایرکتهای زنجیرهای را حذف کنید. پرهزینهترین و سادهترین برد؛ مقصد نهایی را مستقیم در لینکها بنویسید.
- TLS 1.3 را فعال و ازسرگیری نشست را روشن کنید. دستدادن TLS 1.3 یک رفتوبرگشت است و TLS 1.2 دو تا. برای کاربر بازگشتی، ازسرگیری با کلید از پیش اشتراکگذاشتهشده اجازه میدهد داده در همان اولین بسته برود — قابلیتی که RFC 8446 با نام 0-RTT تعریفش کرده و همانجا هشدار داده در برابر بازپخش محافظتشده نیست؛ پس فقط برای درخواستهای بیخطر مثل GET.
- اتصالها را زنده نگه دارید. keep-alive و مالتیپلکسِ HTTP/2 یعنی دهها فایل روی یک اتصال موجود میروند، بدون تکرار TCP و TLS برای هرکدام.
- OCSP stapling فقط وقتی ارزش دارد که گواهیتان OCSP داشته باشد. این تنظیم یک رفتوبرگشت مرورگر به سرور صادرکننده را حذف میکند، اما «لتسانکریپت» از مه ۲۰۲۵ آدرس OCSP را از گواهیهای تازه برداشت، در اوت ۲۰۲۵ پاسخدهندههایش را خاموش کرد و به CRL کوچید؛ روی چنین گواهیای stapling چیزی برای صرفهجویی ندارد.
- تعداد دامنههای صفحه را کم کنید. هر میزبان جدید در HTML یعنی یک جستوجوی DNS و یک اتصال تازه؛ میزبانی محلی فونت و کتابخانه چند رفتوبرگشت را حذف میکند.
پیکربندی عملی این موارد در راهنمای راهاندازی سایت با Nginx آمده است. و توجه کنید چه چیزی در فهرست نیست: هیچ تنظیم کرنل و هیچ «بهینهساز شبکه»ای تأخیر انتشار را کم نمیکند؛ آنها روی توان عبوری اثر دارند، نه کف رفتوبرگشت.
HTTP/3 و QUIC چقدر به کاهش تأخیر کمک میکنند؟
روی کاغذ، QUIC برای همین مسئله ساخته شده است: دستدادن انتقال و رمزنگاری را در یک مرحله ادغام میکند، پس اتصال تازه یک رفتوبرگشت کمتر میگیرد. RFC 9114 استاندارد رسمی HTTP/3 است و روی مسیرهای پرتلفات مزیت دیگری هم دارد: چون هر جریان مستقل است، گمشدن یک بسته بقیه را متوقف نمیکند.
اما یک واقعیت میدانی: در آزمایش ما از یک میزبان داخل ایران، دستدادن QUIC v1 به سرورهای خارج از کشور بیپاسخ ماند و در ۱۰ ثانیه تایماوت شد، در حالی که TCP به همان آیپی و پورت در کمتر از یک ثانیه پاسخ ۲۰۰ گرفت؛ همین رفتار برای چند سرویس بزرگ جهانی هم تکرار شد. انسداد پورت UDP نیست — بستهی QUIC با نسخهی ناشناخته بلافاصله پاسخ میگیرد — فقط دستدادنهای واقعی نسخهی ۱ ناپدید میشوند.
کی سرور خارجی هنوز انتخاب درستی است؟
محل دیتاسنتر باید تابع محل «مخاطب» باشد، نه سلیقه. سرور خارج وقتی منطقی است که:
- مخاطبتان خارج از ایران است — سایتی برای کاربران اروپا باید در اروپا میزبانی شود؛ همان منطق فاصله، اینبار به نفع سرور خارجی.
- به سرویسهای خارجی وابستهاید — اگر بکاند مدام با APIهایی کار میکند که از داخل کشور کند جواب میدهند، نزدیکی به آن سرویسها مهمتر میشود.
- کار غیروب انجام میدهید — بعضی بارهای پردازشی اصلاً کاربر نهایی داخل ایران ندارند.
راهحل حرفهای اغلب ترکیبی است: سایت اصلی روی سرور داخل کشور و یک سرور کوچک خارجی فقط برای همان کارهای خاص — مدلی که با پرداخت ساعتی قابل کنترل است و در مقالهی سرور ابری ساعتی چیست بازش کردهایم؛ مقایسهی هاست ایران و هاست خارج هم همین تصمیم را با جدول انتخاب جمعبندی کرده است. معیار را دقیق بگذارید: نه میانگین بازدیدها، بلکه مخاطب صفحههای پولساز.
CDN مکمل است، نه جایگزین
شاید بپرسید: «با CDN مشکل حل نمیشود؟» تا حدی. CDN فایلهای استاتیک — تصویر، CSS، جاوااسکریپت — را روی نودهای لبه نزدیک کاربر کش میکند و برای همین دسته عالی است، اما دو محدودیت مهم دارد:
- درخواستهای داینامیک همچنان به مبدأ میروند. صفحهی محصول، سبد خرید و هر چیزی که با دیتابیس کار دارد باید تا خودِ سرور اصلی برود و برگردد — با همان پینگ بالا.
- اولین بایت HTML معمولاً از مبدأ میآید. یعنی همان TTFB که گوگل و کاربر میسنجند، هنوز اسیر فاصلهی سرور اصلی است.
ظرافت کمتر گفتهشده: وقتی درخواست روی نود لبه MISS بخورد، کاربر «تا لبه» بهعلاوهی «لبه تا مبدأ» را میپردازد — پس برای اولین بازدیدکنندهی هر فایل، CDN میتواند کمی کندتر از اتصال مستقیم باشد و سود واقعی از HITهای بعدی میآید. سازوکار کش لبه در راهنمای کامل CDN چیست آمده است.
فرمول درست این است: مبدأ نزدیک به مخاطب + CDN برای استاتیکها + وبسرور بهینه. اگر مبدأ و نود لبه هر دو داخل ایران باشند، هیچکدام از دو مسیر HIT و MISS از مرز خارج نمیشود؛ پایدارترین ترکیب برای مخاطب داخلی.
مهاجرت سرور بدون قطعی: ترتیب کارها
- TTL رکورد A را به ۳۰۰ ثانیه کاهش دهید و بهاندازهی TTL قبلی صبر کنید.
- سایت را روی سرور جدید بالا بیاورید و پیش از تغییر DNS با سوییچ
--resolveهمانجا آزمایش کنید:curl -sI --resolve example.com:443:198.51.100.20 https://example.com/ | head -3 HTTP/2 200 server: nginx content-type: text/html; charset=UTF-8 - پینگ و TTFB سرور جدید را از چند شبکه — خط ثابت، اینترنت همراه و یک اپراتور دیگر — بگیرید و با اعداد قبلی مقایسه کنید.
- رکورد را عوض کنید، بعد سرور قدیمی را دستکم یک هفته روشن نگه دارید تا کشهای دیرپا هم منتقل شوند؛ در پایان TTL را به مقدار عادی برگردانید.
فهرست کامل کارهای پیش و پس از انتقال در راهنمای انتقال سایت به هاست جدید است.
کاهش پینگ با سرویسهای مهران هاست
تأخیر مالیاتی است که کاربران بابت فاصله میپردازند و با تغییر جغرافیا تقریباً صفر میشود. آنچه در مهران هاست برای همین کار در اختیار دارید:
- سرور ابری در دیتاسنتر ایران، ماشین KVM با دیسک NVMe و صورتحساب ساعتی — دقیقاً برای همین تصمیم: یک سرور بسازید، پینگ و TTFB بگیرید، با اعداد فعلی مقایسه کنید و اگر قانع نشدید حذفش کنید. و توجه کنید: خاموشکردن ماشین کنتور را متوقف نمیکند، چون دیسک و رم رزرو میمانند؛ فقط حذف کامل هزینه را صفر میکند.
- سرور و هاست خارج از کشور در دیتاسنترهای Hetzner — با فاکتور ریالی و بدون کارت ارزی. هاست اشتراکی روی cPanel و DirectAdmin ارائه میشود.
- CDN با نود لبه در ایران و اروپا، که کنار هر رکورد A در پنل DNS با یک کلید روشن میشود؛ روی دامنهای که DNS آن اینجا مدیریت شود هزینهی جداگانه ندارد و مبدأ میتواند هر جای دنیا بماند.
- DNS مدیریتشده با رکوردهای A، AAAA، CNAME، MX، TXT، NS، SRV و CAA و کمترین TTL شصت ثانیه — همان ابزار مرحلهی اول چکلیست مهاجرت.
قدم عملی همین امروز: با ping و curl از سرور فعلی اندازه بگیرید، یک سرور آزمایشی در دیتاسنتر ایران بسازید و همان دو دستور را تکرار کنید. برای شروع در مهران هاست ثبتنام کنید.
سؤالات پرتکرار
چطور پینگ و تأخیر سایتم را کم کنم؟
مؤثرترین کار، نزدیککردن سرور به مخاطب اصلی است؛ تأخیر انتشار تابع فاصلهی فیزیکی است و هیچ تنظیم نرمافزاری آن را نمیشکند. بعد از آن تعداد رفتوبرگشتها را کم کنید: زنجیرهی ریدایرکت را حذف کنید، TLS 1.3 و ازسرگیری نشست را فعال کنید، اتصالها را با keep-alive و HTTP/2 زنده نگه دارید و فونت و اسکریپت را از سرور خودتان سرو کنید.
پینگ خوب برای یک سایت با مخاطب ایرانی چقدر است؟
از خط ثابت داخل کشور به سروری در دیتاسنتر ایران، پینگ زیر ۲۰ میلیثانیه با نوسان اندک مطلوب است و تا حدود ۳۰ میلیثانیه هم قابل قبول. روی اینترنت همراه ۳۰ تا ۷۰ میلیثانیه طبیعی است، چون بخشی از تأخیر در شبکهی رادیویی ساخته میشود، و سروری در اروپا معمولاً ۸۰ تا ۱۵۰ میلیثانیه فاصله دارد. مهمتر از میانگین، پایداری عدد و صفر بودن گمشدن بسته است.
تفاوت پینگ و TTFB در چیست؟
پینگ زمان یک رفتوبرگشت بسته در لایهی شبکه است و با پروتکل ICMP سنجیده میشود؛ TTFB فاصلهی آغاز درخواست تا رسیدن اولین بایت پاسخ HTTP است و علاوه بر شبکه، جستوجوی DNS، دستدادن TCP و TLS، ریدایرکتها و زمان پردازش برنامه را هم در بر میگیرد. برای همین TTFB همیشه چند برابر پینگ است. اگر پینگ پایین ولی TTFB بالا باشد، مشکل در کد یا دیتابیس است، نه مسیر شبکه.
آیا CDN پینگ سایت را کم میکند؟
CDN تأخیر دریافت فایلهای ایستا مانند تصویر و CSS و جاوااسکریپت را کم میکند، چون آنها را از نود لبهی نزدیک کاربر تحویل میدهد. اما صفحههای داینامیک و اولین بایت HTML معمولاً از سرور مبدأ میآیند و تأخیرشان به فاصلهی همان سرور بستگی دارد. اولین درخواست هر فایل کشنشده هم هزینهی کاربر تا لبه بهعلاوهی لبه تا مبدأ را میپردازد. پس CDN مکمل انتخاب درست دیتاسنتر است، نه جایگزین آن.
چرا پینگ سایتم شبها بالا میرود؟
چون در ساعات پیک ترافیک بیشتری برای همان ظرفیت مسیر رقابت میکند و بستهها در بافر تجهیزات میانی صف میکشند؛ نتیجهاش بالا رفتن همزمان میانگین تأخیر و نوسان است. این پدیده در مسیرهای عبوری از گذرگاه بینالملل بسیار پررنگتر از مسیرهای داخلی است. برای تشخیص، mtr را یک بار در ساعت خلوت و یک بار در پیک اجرا کنید و ببینید جهش از کدام هاپ شروع میشود.