تاثیر هاست بر سرعت سایت چقدر است؟

سوالی که در مشاوره‌ها زیاد تکرار می‌شود این است: «هاستم چقدر مقصر است؟» و جواب صادقانه یک عدد ثابت نیست؛ بین صفر تا هشتاد درصد، به‌این بستگی دارد که سایت شما گلوگاهش کجاست. آن‌چه اما همیشه صادق است، مکانیزم اثر است: هاست فقط «فضای دیسک» نیست؛ کارخانه‌ای‌ست که وردپرس در آن اجرا می‌شود — پردازنده، حافظه، سرعت خواندن/نوشتن دیسک، نسخه PHP، و مسیر شبکه تا کاربر، همه در همین کارخانه تولید می‌شوند. در مقالۀ «هاست چیست و چطور انتخابش کنیم؟» جنسِ خودِ خدمت را باز کرده‌ام؛ این مقاله دقیقاً ادامه‌ی همان بحث است: چطور و چقدر هاست روی سرعت اثر می‌گذارد، از هفت کانال مجزا. یاد می‌گیرید نشانه‌های هاستِ ضعیف را مثل یک تعمیرکار بشناسید، با عدد (نه حس) مقصر بودنش را ثابت کنید، و بدانید کی ارتقای هاست عاقلانه است و کی فقط جابه‌جاشدنِ مشکل است — چون هر دردی درمانش جراحی نیست.

هفت کانال اثر هاست بر سرعت

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

1. زمان پاسخ سرور (TTFB): سرعتِ خودِ کارخانه در تحویل اولین بایت
2. CPU و صفِ اجرا: سهمِ شما از پردازنده در اشتراک با همسایه‌ها
3. دیسک و I/O: سرعتِ خواندن و نوشتن فایل و دیتابیس
4. نسخه و تنظیم PHP: موتورِ اجرای وردپرس (PHP 8.2 در برابر 7.4 تفاوتِ محسوس است)
5. زیرساخت کشِ سرور: LiteSpeed/Nginx یا Apacheِ خام؛ کشِ OPcache
6. لوکیشن سرور: فاصله‌ی فیزیکی تا کاربر (ping پایه)
7. کیفیت شبکه و پورت: مسیر ترافیک، پیکربندیِ روتینگ، افت شبانه

این هفت را در سه دسته جمع می‌کنم: دسته‌ی «اجرا» (یک تا پنج) روی TTFB اثر می‌گذارد، دسته‌ی «فاصله» (شش و هفت) روی latencyِ شبکه؛ و هر دو سرجمع در همان سه‌عددِ آشنای Core Web Vitals و در تجربۀ کاربری نهایی ظاهر می‌شوند. در نقشۀ شش‌لایۀ «افزایش سرعت وردپرس»، هاست لایۀ اول بود — نه به‌خاطر این‌که همیشه مقصر است، به‌خاطر این‌که اگر مقصر باشد، هیچ لایۀ بعدی نمی‌تواند نقصانش را جبران کند.

قالبِ بد در هاستِ خوب، سایتِ بد است؛ قالبِ خوب در هاستِ بد هم همان‌طور. ولی هاستِ بد، حتی از قالبِ بد هم تن‌تر به نفس می‌زند — چون سقف را خودش تعیین می‌کند.

کانال اول و دوم: TTFB و صفِ CPU

وقتی بازدیدکننده آدرس را می‌زند، مرورگر اول باید «پاسخ» سرور را بگیرد: اجرای PHP، کوئری‌های دیتابیس، رندر HTML. مجموعِ همین‌ها همان TTFB است که در «تأثیر TTFB بر سرعت بارگذاری» عددبهعدد باز کرده‌ام و در واقعیت، اولین جایی‌ست که کیفیتِ هاست از آبِ بیرون می‌زند. حالا کانال دوم که زیرمجموعۀ اول است: در هاست اشتراکی، پردازندهٔ سرور بین ده‌ها مشتری تقسیم می‌شود و اگر یکی‌شان (همان سایتمحلی که بکاپِ ساعتیِ ۲ گیگی می‌گیرد) CPU را بخورد، درخواستِ شما در صف می‌نشیند — بدون‌این‌که شما کاری کرده باشید. نشانه‌اش مشخص است: TTFBِ نوسانی؛ صبح ۲۰۰ میلی‌ثانیه، ساعت ۲۱ هزار. هاست‌هایِ ایرانیِ پُرمشتری که فروشِ «نامحدودِ» واقعاً-نامحدود دارند، قهرمانِ این صف‌ها هستند. معادلِ پنجرۀ مشاهده: در cPanelِ خودتان (راهنمایش در «cPanel چیست؟») نمودارهای CPU/RAM/Entry Processes را نگاه کنید؛ اگر سقفِ ۲۵٪ را معمولیِ روزانه‌تان است، جای کار می‌لنگد — راهکارهای عددیِ کاهشِ مصرف را جدا در «کاهش مصرف منابع هاست» نوشته‌ام.

کانال سوم: دیسک و I/O — قاتل خاموش

کمتر کسی اسمش را می‌شنود و بیشترِ «معماهایِ کندی» همین‌جا حل می‌شوند: وردپرس موجودِ زنده است — نوشتنِ لاگ، کش‌کردن، آپلودِ تصویر، به‌روز‌رسانیِ گزینه‌ها؛ اگر هاست روی دیسکِ HDD قدیمی یا SANِ شلوغ باشد، سرعتِ خواندن/نوشتن به‌شدت افت می‌کند و نتیجه‌اش کندیِ پیشخوان است بیشتر از front-end: ذخیرهٔ یک نوشته طول می‌کشد، ویرایشگرِ قالب گیر می‌کند، افزونه‌های اسکن‌کننده ساعت‌ها می‌کشند. تشخیصِ خانگی: یک فایلِ ۱۰ مگابایتی را در File Manager آپلود کنید و زمانش را با تخمینی بسنجید؛ یا در پیشخوان، سرعتِ «افزودن نوشته» را با سه ماه پیش مقایسه کنید. درمانِ ریشه‌ای: هاستِ NVMe/SSD — تفاوتِ IOPSِ دیسکِ نو با HDD قدیمی چندبرابر است و هیچ افزونه‌ای جبرانش نمی‌کند؛ کشِ صفحه هم همان‌جا کمک می‌کند چون خواندنِ HTML آماده را از نوشتنِ مجدد نجات می‌دهد (نقشۀ انتخابش در «افزونه‌های کش»).

کانال چهارم: نسخه PHP و حافظه

پی‌اچ‌پی موتورِ وردپرس است و نسخه‌هایِ ۸.x نسبت به ۷.۴ تا دو برابر راندمانِ اجرایِ کدِ وردپرسی دارند — فقط با تغییرِ عددی در پنلِ هاست، بدونِ یک خط دست‌کاری. تجربه‌ام: در چند پروژه، «افزایش محسوسِ TTFB» بدونِ هیچ بهینه‌سازیِ دیگری از همین یک تغییر آمده. دوم، memory_limit است: اگر کم باشد، وردپرس وسطِ کارِ سنگین (اکسپورت، اسکن، ووکامرس) به دیوار می‌خورد و دوباره نفس می‌کشد — کُندی با طعمِ خطا. قبل از هر دستکاری‌ای در نسخه PHP، بکاپ بگیرید و افزونه‌ها/قالبِ خودتان را برای سازگاری چک کنید؛ اگر جایی شکست، در محیطِ لوکال تستش کنید (روش تستِ امن را در «بهترین روش تست قالب» توضیح داده‌ام). نکته‌ی صادقانه: بعضی هاست‌هایِ ارزان هیچ نسخه‌ی جدیدی در پنلشان ندارند — و این خودش یک نشانه‌ی «هاستِ بی‌نگهداری» است که در چک‌لیستِ بخشِ نشانه‌ها می‌آید.

کانال پنجم: کشِ سمتِ سرور

روی همۀ کانال‌هایِ قبلی، سرورِ درست یک ضربه‌ی چکش می‌زند: LiteSpeed با افزونۀ رایگانش، کشِ صفحه را قبلِ PHP سرو می‌کند؛ یعنی TTFBِ چندمیلی‌ثانیه‌ای روی هاستِ اشتراکیِ معمولی. Nginx به‌تنهایی هم در تحویلِ فایل‌هایِ استاتیک از Apacheِ کلاسیک جلو می‌زند؛ OPcache در هر دو، کامپایلِ PHP را یک‌بار انجام می‌دهد نه هر ریکوئست. همین را در «تأثیر افزونه‌ها بر سرعت» هم گفتم: کشِ سروری، مالیاتِ افزونه‌ها را هم ارزان‌تر می‌کند. در انتخابِ پلن، این‌قدر ساده نگاهش کنید: روی همۀ کاغذاتِ تبلیغاتیِ هاست‌ها «SSD و LiteSpeed» نوشته شده؛ امتحانِ عملی‌اش همان تستِ عددیِ بخشِ نهم این مقاله است، نه متنِ صفحهٔ فروش. مقایسه‌ی فنیِ پلن‌ها را در «بهترین هاست وردپرس» و برای فروشگاه در «انتخاب هاست برای فروشگاه» انجام داده‌ام.

کانال ششم و هفتم: لوکیشن و شبکه

سرعتِ نور بی‌رحم است: هررفت‌وبرگشتِ تهران–فرانکفورت ~= ۴۰ میلی‌ثانیه فقط در مسیر؛ حالا یک صفحه که ۶۰ درخواستِ استاتیک به سرورِ بیرون می‌زند را تصور کنید — latencyِ پایه، روی هر درخواست جریمه می‌دهد. برای مخاطبِ ایرانی، هاستِ داخل با pingِ دو رقمی، تجربه‌ای می‌سازد که هاستِ اروپاییِ سریع‌تر هم گاهی نمی‌رساند — و برعکس، اگر مخاطبتان اروپاست، داخل نگه‌داشتنِ سایت اشتباهِ آینه‌ای است. کانال هفتم، کیفیتِ مسیر است: پورتِ ۱G یا اشتراکیِ شلوغ، روتینگِ بد، و افتِ شبانهِ ترافیکِ بین‌المللی؛ نشانه‌اش را کاربرِ شما حینِ تماسِ تصویریِ همزمان با دانلودِ سایتتان حس می‌کند. جبرانِ هر دو کانال از دستِ هاست هم در‌می‌آید: CDN فایل‌ها را به نزدیکِ کاربر می‌آورد و «راه‌اندازی CDN» روشش است — ولی TTFBِ داینامیکِ بی‌کش را هیچ CDN نجات نمی‌دهد؛ آن همان‌جا می‌ماند.

نشانه‌های هاست ضعیف (چک‌لیست تشخیص)

تعمیرکار، اول گوش می‌دهد؛ صداهایِ هاستِ مریض این هفت‌تاست:

• TTFBِ نوسانیِ بی‌دلیل در طول روز (صفِ CPU — کانال ۲)
• کندیِ نامتقارن: front معمولی، پیشخوانِ لگ‌دار (دیسک/I/O — کانال ۳)
• خطاهایِ تصادفی: «اتصال برقرار نیست» ۵۰۳ لحظه‌ای، white screenِ گاه‌به‌گاه، cronِ دیر‌اجراشده
• سقفِ Entry Processesِ ۲۰–۳۰ تایی با سایتی که ترافیکِ سرسام‌آور ندارد
• پنلِ قدیمی با PHP 7.4 به‌عنوان «جدیدترین» و نبودِ OPcache/Redis
• پشتیبانیِ پاسخ‌نمی‌دهنده — اگر نتوانید بپرسید سرورتان LiteSpeed است یا نه، با همان بی‌سروصدا نبودنِ پاسخِ تیکت، معلوم است
• «نامحدود» با ستاره‌ی ریز: حجمِ گره‌ای‌ست که روزِ ترافیکِ بالا به شکلِ تعلیقِ حساب بازنمایی می‌شود

سه اثرِ غیرسرعتیِ هاست که در همین محاسبه می‌آیند

پیش از آن‌که به تستِ عددی برویم، سه هزینه‌ی دیگرِ هاستِ بی‌کیفیت را هم به ترازو اضافه کنید، چون در تصمیمِ ارتقا اثرگذارند:

• سئو و خزش: Uptimeِ پایین و خطاهایِ ۵xxِ مکرر، بودجه‌ی خزش را می‌سوزاند و رباتِ گوگل را دل‌زده می‌کند؛ همان حلقه‌ای که در «سئو تکنیکال از خزش تا ایندکس» توضیح داده‌ام. سایتی که روزی یک ساعت از دسترس خارج است، در ایندکسِ منظم شکست می‌خورد حتی اگر محتوایش عالی باشد.
• امنیت: هاستی که سرورش پچ‌نشده بماند یا TLS را درست سرو نکند، شما را لایه‌لایه در برابر حملات باز می‌گذارد؛ فهرستِ کارهایی که هیچ هاستی به‌جای شما انجام نمی‌دهد در «راهنمای امنیت وردپرس» و لایه‌بندیِ افزونه‌ها در «بهترین افزونه‌های امنیتی وردپرس» آمده.
• پشتیبانی و نگهداری: ارزشِ واقعیِ خیلی پلن‌ها نه در CPU که در «سرعتِ جواب» است — نیمه‌شبِ کمپین که خطای دیتابیس می‌گیرید، تیکتِ ده‌ساعته یعنی فروشِ از‌دست‌رفته. در چک‌لیستِ خریدِ هر خدمتی، «پاسخ‌گوییِ واقعی» را با یک سؤالِ فنیِ رندوم پیش از خرید محک بزنید؛ نشانه‌هایِ قالبِ استاندارد را هم که در «پیش از خرید قالب چه بررسی کنیم؟» آورده‌ام.

این سه با سرعت جمع نمی‌شوند بلکه ضرب می‌شوند: هاستِ بد، تجربه‌ی کاربر را کند، ایندکس را ناقص، و اعتماد را شکننده می‌کند — همان چیزی که «سئو چیست و چه کمکی به کسب‌وکار می‌کند؟» در زنجیره‌ی ارزش توضیح داده.

هاستِ خوب، نامرئی است؛ هیچ‌وقت اسمش را در جلسات نمی‌آورید. اگر «باید» درباره‌اش حرف بزنید — یعنی دارید برای ضعفِ بسترِ اجراییِ کسب‌وکارتان مالیات می‌دهید.

هاست‌سنجی عددی: قبل از سرزنش، اثبات کنید

«هاستم بده» را هیچ‌وقت از حس نمی‌گویم؛ سه آزمونِ سریع با عدد دارم که روششان را در «بهترین ابزارهای تست سرعت» هم باز کرده‌ام:

1. تستِ خالصِ TTFB روی چند IP: با curl پنج صفحه را سه‌بار بزنید (بدونِ CDN): اگر در ساعاتِ مختلف، عدد از ۳۰۰ به ۳۰۰۰ میلی‌ثانیه می‌رود و بقیه‌ی تست‌ها (دیسک در آپلود، PHP ورژن) سرِ جایش است، صفِ CPU متهمِ اول است.
2. تستِ فاصله: ping/traceroute تا IPِ سرور + mtr در ساعتِ اوج؛ ۱۵۰+ میلی‌ثانیه برای مخاطبِ ایرانی یعنی لوکیشنِ غلط، نه کیفیتِ بد.
3. تستِ مقایسه‌ی استجینگ: سایت را روی هاستِ دیگرِ موقت (حتی پلنِ ارزانِ LiteSpeed) بالا بیاورید و اعدادِ گام صفر را مقایسه کنید؛ همین «جراحیِ کنترل‌شده»، قاطع‌ترین جواب را می‌دهد — مهاجرتِ بین دو هاست را سرخود و بی‌برنامه انجام ندهید؛ اما پروتکلِ کلیِ تغییرِ امن (بکاپِ کامل، محیطِ مقصدِ آماده، چک‌لیستِ بعدِ تغییر، پایشِ هفتۀ اول) همان چیزی است که در «تغییر قالب بدون آسیب» نوشته‌ام و اینجا هم کپی‌بردار است.

و یادآوری: در ردیفِ ابزارهای تست، «عیب‌یابیِ مرحله‌به‌مرحلۀ سرعت» ترتیبِ درستِ شک‌کردن را می‌دهد — اولِ همه، از خودِ سایت و افزونه‌ها شک کنید، بعد از هاست؛ چون عوض‌کردنِ هاستِ سالم، فقط هزینه است نه درمان.

کی ارتقا بدهیم؟ کی ندهیم؟

تصمیم‌نامۀ تجربیِ من، شفاف:

• ارتقا بدهید اگر: نشانه‌هایِ چک‌لیست بالا چندتایی‌اند؛ TTFBِ شما روی همه‌ی صفحات بد است و افزونه‌ها خاموش‌هم اثری ندارند؛ در صفِ CPU/دیسک هستید و بک‌آپ‌ها به اوایل صبح منتقل شده‌اند و باز هم گیر دارید؛ سایتتان در ساعتِ اوج خطا می‌دهد؛ یا ووکامرس دارید و پرداختِ ۵هزارتومانی‌تان به «سرعتِ تراکنش» وابسته است (نقشۀ فروشگاه در «هاستِ فروشگاه»).
• ارتقا ندهید اگر: TTFBِ شما خوب است ولی LCP بد (تصویر و JS شماست، نه هاست — نقشۀ «کندی قالب»)؛ ترافیکتان ناچیز است و فقط در PageSpeed دنبالِ نمره‌ی ۱۰۰ می‌گردید؛ یا مشکل از یک افزونه‌ی بدکد است که با حذفش، هاستِ فعلی مثلِ روز اول نفس می‌کشد (تستِ حذفِ دسته‌ای در «تأثیر افزونه‌ها»).

قاعده‌ی سرانگشتیِ اقتصادی: ارتقای هاست، هزینه‌اش ماهانه و کوچک است و سودش روی همه‌ی صفحات؛ مهاجرتِ قالب، هزینه‌اش یک‌باره و بزرگ. به همین ترتیب هم اولویت‌بندی می‌شود — همان چیزی که در «افزایش سرعت وردپرس» در بودجۀ چهارهفتگی چیده‌ام. و یک تذکرِ چرخشی که کمتر دیده می‌شود: هاستِ ارتقایافته، لایه‌های پایینِ نقشه (کد قالب و افزونه‌های پُر CPU) را نمایش می‌دهد؛ یعنی بودجه‌ی آزادشده را بی‌درنگ خرجِ همان‌ها کنید، وگرنه هاستِ قوی‌تر فقط «سریع‌تر نفس‌نفس می‌زند». مفاهیمِ پایه‌ی بهینگیِ سرتاسری هم در «بهینۀ سرعت چیست؟» آمده.

جمع‌بندی

تأثیر هاست بر سرعت سایت از هفت کانال می‌آید — TTFB، صفِ CPU، دیسک، PHP، کشِ سرور، فاصله، شبکه — و اندازه‌اش از صفر تا هشتاد درصدِ گلوگاه نوسان دارد؛ تشخیص، حس نیست عدد است: سه تستِ سریع (TTFBِ چندساعته، ping، مقایسۀ استجینگ) ثابت می‌کنند مقصر کیست. به‌یاد داشته باشید که هاستِ خوب سقفِ سرعت را بالا می‌برد ولی کفِ آن را قالب و افزونه‌های شما تعیین می‌کنند؛ اول عدد بگیرید، بعد سرزنش. قدمِ امشب: پنج بار از صفحاتِ کلیدی با curl TTFB بگیرید (صبح و شب)، و نمودارِ CPU پنلتان را باز کنید؛ اگر نوسانِ چندبرابری دیدید، همان فردا سراغِ چک‌لیستِ هفت‌بندِ نشانه‌ها بروید. تجربه‌تان از «مقصری که هاست بود ولی نشانه‌اش جای دیگری بود» یا بالعکس را در دیدگاه بنویسید — فهرستِ نشانه‌ها را از پرونده‌های واقعیِ شما کامل می‌کنم. 🖥️