آموزش گام‌به‌گام TTFB و سرعت سرور؛ از هاست تا لایهٔ کش

کمتر چیزی این‌قدر بی‌صدا ترافیک را می‌بلعد مثل سرور کند: کاربر صفحه را می‌بیند ولی دیر، موتور جستجو هم بودجهٔ خزشش را روی صفحات پُر تأخیر کم می‌کند و هیچ گزارشی به اسم «سرور کند» فاکتور نمی‌دهد. در ممیزی‌هایمان صاحبان سایت معمولاً دو سر خط‌اند: یا همه‌چیز را به قالب ربط می‌دهند و سرور را دست‌نخورده نگه می‌دارند، یا اولین کارشان خرید هاست گران‌تر است، بدون اینکه بدانند گلوگاه کجاست.

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

TTFB و سرعت سرور چیست و کجا اتفاق می‌افتد؟

TTFB یا Time To First Byte، فاصلهٔ زمانی بین ارسال درخواست کاربر و رسیدن اولین بایت پاسخ است. در این فاصله چند ایستگاه پشت هم کار می‌کنند: شبکه و DNS، وب‌سرور، اجرای کد سمت سرور مثل PHP، کوئری‌های دیتابیس و در نهایت آماده‌شدن اولین بایت. هر ایستگاه می‌تواند گلوگاه باشد؛ برای همین TTFB فقط یک عدد نیست، گزارشی است از سلامت کل زنجیرهٔ سرور. وقتی TTFB خوب شود، بقیهٔ مسیر رندر هم دیرتر شروع نمی‌شود و همهٔ تلاش‌های سمت مرورگر معنا پیدا می‌کند.

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

آموزش گام‌به‌گام سنجش و خواندن TTFB

قدم اول، تست از چند نقطه است: با آموزش گام‌به‌گام تست سرعت سایت شروع کنید و از حداقل دو نقطهٔ جغرافیایی متفاوت تست بگیرید؛ عدد تک‌نقطه‌ای قضاوت‌پذیر نیست، مخصوصاً اگر مخاطب و سرور شهرهای مختلفی باشند. قدم دوم، تکرار است: هر تست چند بار اجرا کنید و سنجش صفحهٔ کش‌شده را جدا از اولین بارِ بدون کش؛ اغلب قضاوت‌های غلط از مقایسهٔ این دو با هم می‌آید. قدم سوم، خواندن تفکیک مراحل است: در گزارش waterfall ببینید سهم «صبر تا اولین بایت» کجاست و کدام ایستگاه — شبکه، سرور یا دیتابیس — وزن اصلی را برداشته.

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

کلاس هاست؛ اولین اهرم لایهٔ سروری

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

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

لایه‌های کش؛ از حافظهٔ سرور تا سقف پشتیبانی

کش، ارزان‌ترین بهبود لایهٔ سروری است و چند طبقه دارد. کش صفحه، خروجی HTML آماده را نگه می‌دارد و برای بازدیدکنندهٔ مهمان، کل چرخهٔ PHP و دیتابیس را دور می‌زند؛ اثرش معمولاً بزرگ‌ترین است. کش شیء و کوئری، نتایج پرتکرار دیتابیس را در حافظه نگه می‌دارد و صفحات پویا را سبک می‌کند. کش opcode هم کد PHP کامپایل‌شده را نزدیک اجرا نگه می‌دارد. در وردپرس این لایه‌ها با افزونهٔ کش فعال می‌شوند و چگونه‌گی انتخاب و تنظیم آن، با نگهداری و پاک‌سازی درست، در راهنمای کش وردپرس جداگانه آمده است؛ این‌جا فقط نقشهٔ لایه‌ها را لازم دارید.

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

نگهداری سمت سرور؛ PHP، دیتابیس و بارهای پنهان

بعد از هاست و کش، نگهداری روزمره تعیین می‌کند سرعت سرور سرِ جای خودش بماند یا دوباره پُر شود. نسخهٔ PHP یکی از همین اهرم‌هاست: به تجربهٔ ما ارتقای منظم به نسخه‌های جدیدتر، معمولاً همان کارها را با پردازش و حافظهٔ کمتری انجام می‌دهد؛ البته قبل از ارتقا، سازگاری قالب و افزونه‌ها را در محیط آزمایشی چک کنید، چون یک افزونهٔ قدیمی می‌تواند کل سایت را درگیر کند. افزونه‌های سنگین و کم‌استفاده هم بار پردازشی دائمی می‌سازند؛ ممیزی فصلی افزونه‌ها با همان منطق حذف اسکریپت‌ها انجام می‌شود، فقط این‌بار روی سرور.

دیتابیس خواب‌آلود را جدی بگیرید: گزینه‌های انباشتهٔ خودبارگذاری‌شونده و جداول بزرگ‌شده، هر درخواست پویا را سنگین‌تر می‌کنند و اثرشان مستقیم روی TTFB می‌افتد؛ پاک‌سازی دوره‌ای و منظم‌کردن گزینه‌ها را در بهینه‌سازی دیتابیس وردپرس دنبال کنید. بارهای پنهان را هم خاموش کنید: کارهای زمان‌بندی‌شدهٔ هم‌زمان در ساعات اوج، بکاپ‌گیری سنگین روی سرور تولیدی در وسط روز و لاگ‌های پرشده. پایش لاگ خطاها هفته‌ای یک‌بار، مشکلات را قبل از اینکه کاربر ببیند نشان می‌دهد؛ به تجربهٔ ما بیشتر «کند شدن تدریجی»، مجموع همین بارهای پنهان است، نه یک اتفاق ناگهانی.

CDN برای مخاطب ایرانی؛ نقش، مرز و پیکربندی

شبکهٔ توزیع محتوا فایل‌های ثابت — عکس‌ها، CSS و JS — را روی نقطه‌هایی نزدیک‌تر به کاربر نگه می‌دارد؛ نتیجه این است که درخواست‌های ثابت به سرور شما نمی‌رسند، بار سرور کم می‌شود و منابع برای پردازش صفحات پویا آزاد می‌شود. اما مرزها را صادقانه بگویید: CDN به‌خودی‌خود پردازش پویای صفحه را سریع نمی‌کند؛ اگر TTFB شما به‌خاطر اجرای PHP و کوئری‌ها بالاست، توزیع استاتیک‌ها کمک جانبی است، نه درمان اصلی. CDN با کش درست مکمل است، نه جایگزین.

برای مخاطب ایرانی یک لایهٔ اضافه هم هست: دسترس‌پذیری شبکه‌های توزیع محتوا یکسان نیست و برای سایت‌های ایرانی برخی سرویس‌ها به‌سادگی در دسترس نیستند یا پیکربندی خاص دامنه و گواهی می‌خواهند. برای همین انتخاب را با تست واقعی از داخل کشور و چند نقطه انجام دهید، نه با وعدهٔ صفحهٔ فروش؛ معیارها و سناریوهای انتخاب در مقایسهٔ کامل CDN برای سایت‌های ایرانی باز شده است. به تجربهٔ ما برای سایت‌هایی که مخاطب شهری و بین‌المللی دارند، ترکیب میزبانی نزدیک به مخاطب اصلی با توزیع استاتیک‌ها معمولاً منطقی‌ترین نقطهٔ شروع است — و همان قاعدهٔ همیشگی: بعد از هر تغییر، با پایهٔ ثبت‌شده دوباره بسنجید.

جمع‌بندی؛ سرعت سرور لایه‌به‌لایه ساخته می‌شود

جمع ببندیم: TTFB و سرعت سرور پنج لایه دارد — سنجش قابل اتکا با پایهٔ ثبت‌شده، کلاس هاست متناسب با رشد، لایه‌های کش با انقضای درست، نگهداری منظم PHP و دیتابیس و در صورت نیاز، سنجش دقیق نقش CDN. ترتیب هم مهم است: اول سنجش، بعد ارزان‌ترین اهرم‌ها؛ کش قبل از تعویض هاست، و نگهداری قبل از هر دو. اهرم سمت مرورگر را هم قربانی نکنید — اسکریپت‌های اضافه‌ای که بعد از اولین بایت صفحه را نگه می‌دارند، در راهنمای حذف اسکریپت‌های غیرضروری درمان شده‌اند و دو مقاله مکمل یکدیگرند. فهرست کامل موضوعات این حوزه را هم در هاب سئو فنی کنار هم گذاشته‌ایم.

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

رصد ما، رشد شما.