آزمایش سرعت سایت: مقایسه هاست‌های مختلف

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

چرا این آزمایش و چه چیزی را اندازه گرفتیم؟

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

هدف آزمایش، پاسخ دادن به سه سؤال مشخص بود. اول، تفاوت TTFB (Time To First Byte) بین انواع هاست چقدر است؟ دوم، این تفاوت روی LCP (Largest Contentful Paint) — همان شاخصی که در Core Web Vitals چیست توضیح داده شده — چقدر اثر می‌گذارد؟ سوم، در ساعات شلوغی، کدام هاست پایدارتر می‌ماند؟

هر ادعایی در مورد سرعت هاست، یا با عدد ثابت می‌شود یا با تبلیغ؛ در این آزمایش، دنبال عدد بودم نه تبلیغ.

روش‌شناسی: همان سایت، چهار محیط

اصل آزمایش، تک‌متغیره بودن بود. یک سایت وردپرسی استاندارد ساختم با این مشخصات ثابت:

• قالب: یک قالب سبک شناخته‌شده با ساختار تمیز (بدون صفحه‌ساز سنگین).
• افزونه‌ها: فقط چهار افزونه پایه — سئو، فرم تماس، کش و بکاپ.
• محتوا: پنج نوشته با متن و تصویر یکسان، یک برگه، و یک منوی ساده.
• تصاویر: همه با ابعاد یکسان و به فرمت WebP، بدون اختلاف بین محیط‌ها.
• PHP: در همه محیط‌ها نسخه ۸.۲ با تنظیمات پیش‌فرض.

چهار محیط آزمایشی که انتخاب کردم:

1. هاست اشتراکی ارزان ایرانی: پلن پایه یک ارائه‌دهنده شناخته‌شده بازار، با منابع محدود ولی معمولی.
2. هاست وردپرس‌محور (WordPress-managed): پلن میانی یک ارائه‌دهنده با کش سرور و پیکربندی بهینه وردپرس.
3. VPS (Virtual Private Server) میانی: پلن ۲ هسته، ۴ گیگابایت RAM، با Nginx، PHP-FPM و Redis.
4. سرور ابری اشتراکی: پلن ابری با منابع پویا و شبکه بهینه، بدون تنظیمات دستی اضافه.

روش اندازه‌گیری از سه منبع مستقل انجام شد: PageSpeed Insights در حالت موبایل (به‌عنوان نمای آزمایشگاهی)، curl برای TTFBِ خالص در سه ساعت مختلف روز، و ابزار سنجش سرعت سایت (مطابق روش بهترین ابزارهای تست سرعت سایت). هر تست سه بار تکرار شد و میانگین ثبت شد تا اثر نوسان لحظه‌ای کم شود.

نتیجه اول: TTFB روی چهار نوع هاست

TTFB مهم‌ترین عدد در این آزمایش است، چون پایه تمام محاسبات بعدی LCP را می‌سازد. اگر می‌خواهید مکانیزم آن را عمیق ببینید، تأثیر TTFB بر سرعت بارگذاری را بخوانید. نتیجه میانگین سه اندازه‌گیری در سه ساعت مختلف روز (صبح، عصر، شب):

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

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

نتیجه دوم: LCP و آنچه فراتر از سرور است

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

دو نتیجه از این بخش. اول، بین هاست وردپرس‌محور و VPS تنظیم‌شده، تفاوت LCP فقط ۰.۲ ثانیه است — این تفاوت معنادار است اما انقلابی نیست. دوم، حتی روی بهترین سرور، حدود ۷۵ تا ۸۰ درصد LCP از کنترل هاست خارج است: تصویر شاخص، CSS، فونت و بارگذاری جاوااسکریپت. به‌عبارت‌دیگر، هاست خوب شرط لازم LCP مطلوب است، اما شرط کافی نیست. جزئیات مظنون‌های LCP را در LCP چیست و چگونه آن را بهینه کنیم آورده‌ام.

هاست، سقف سرعت شما را تعیین می‌کند؛ اما تصویر و کد شما تعیین می‌کند که چقدر به آن سقف نزدیک می‌شوید.

نتیجه سوم: پایداری در ساعات شلوغی

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

• هاست اشتراکی ارزان: در ساعات شب، TTFB تا حدود دو برابر جهش داشت. علت محتمل، ترافیک همسایه‌ها روی سرور مشترک است — همان مسئله‌ای که در تفاوت هاست اشتراکی و اختصاصی توضیح داده شده.
• هاست وردپرس‌محور: نوسان بسیار کم، حتی در ساعات شب. معماری کشِ سرور، بار را از PHP برمی‌دارد.
• VPS و سرور ابری: پایداری بالا؛ چون منابع بین همسایه‌ها به‌طور پویا مدیریت می‌شود (ابری) یا اختصاصی است (VPS).

تجربه‌ام نشان می‌دهد پایداری، در بلندمدت مهم‌تر از عدد میانگین است. سایت با TTFB ۳۰۰ms پایدار، تجربه کاربری بهتری دارد از سایت با TTFB ۲۰۰ms میانگین ولی با جهش‌های ۱۵۰۰ms در ساعات اوج. همین پایداری است که تصمیم می‌گیرد کاربر در شبِ خرید، سایت شما را سالم ببیند یا برعکس.

اقتصاد آزمایش: هزینه در برابر تفاوت واقعی

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

نکته‌ای که در آزمایش خودم بیشترین تأثیر را داشت: «وقت فنی ماهانه». یک VPS میانی، هزینه ماهانه معقولی دارد، اما اگر وقت فنی شما گران باشد، هزینه واقعی‌اش چند برابر هاست وردپرس‌محور می‌شود. اگر تیم فنی ندارید، هزینه ساعت‌های نگهداری VPS (که در مدیریت و نگهداری سرور توضیح داده شده) به‌سرعت از تفاوت هزینه ماهانه عبور می‌کند.

چطور نتیجه خودتان را بخوانید

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

1. یک متغیر در هر زمان: اگر همزمان هاست و قالب را عوض کنید، نتیجه هرگز قابل‌استناد نیست. اول هاست را جابه‌جا کنید، سه روز بمانید، سپس سراغ قالب بروید.
2. سه ساعت مختلف روز: اندازه‌گیری فقط در ظهر روز کاری، نیمی از حقیقت را نشان نمی‌دهد. صبح، عصر و شب را جدا اندازه بگیرید.
3. داده میدانی، نه فقط آزمایشگاهی: اگر سایت شما ترافیک دارد، CrUX (Chrome User Experience Report) در Search Console از هر ابزار آزمایشگاهی معتبرتر است؛ چون تجربه واقعی کاربران را می‌سنجد.

در تجربه من، تفاوت‌های زیر ۵۰ میلی‌ثانیه در TTFB، در سطح نوسان شبکه قرار می‌گیرند و معنادار نیستند. تفاوت‌های بالای ۲۰۰ میلی‌ثانیه، محسوس‌اند. تفاوت‌های بالای ۵۰۰ میلی‌ثانیه، مشکل‌سازند — و در آزمایش من، فقط هاست اشتراکی ارزان در ساعات شلوغی به این محدوده رسید.

اشتباهات رایج در خواندن نتایج مقایسه هاست

پنج اشتباه که در پروژه‌های واقعی دیده‌ام:

1. مقایسه با متغیرهای متفاوت: سایت‌های مختلف روی هاست‌های مختلف را مقایسه کردن، هیچ چیزی را ثابت نمی‌کند. متغیرها باید ثابت باشند.
2. تک‌اندازه‌گیری: یک بار اجرا کردن PageSpeed و نتیجه‌گیری. نوسان طبیعی شبکه، عدد تک را بی‌اعتبار می‌کند.
3. باور به تبلیغات «سریع‌ترین هاست»: هیچ هاستی همیشه سریع‌ترین نیست؛ منطقه سرور، شبکه و بار لحظه‌ای هم اثرگذارند.
4. نادیده‌گرفتن هزینه مهاجرت: جابه‌جایی هاست، هزینه دارد. تصمیم گرفتن بر اساس تفاوت ۲۰۰ میلی‌ثانیه، اگر نگهداری ماهانه دو روز وقت ببرد، به‌صرفه نیست.
5. مقایسه فقط بر اساس قیمت: ارزان‌ترین پلن، گران‌ترین تصمیم ممکن است؛ چنان‌که در آزمایش، هاست ارزان در شب به محدوده‌ای رسید که در آن، حتی کاربر معمولی هم تفاوت را حس می‌کند.

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

جدول مرجع

پرسش‌های کوتاه

آیا نتیجه این آزمایش روی همه سایت‌ها صادق است؟ روندها بله، اما اعداد نه. تفاوت مطلق بین هاست‌ها بسته به قالب، محتوا و محل کاربر تغییر می‌کند. الگوی کلی («هاست ارزان ناپایدارتر است، VPS تنظیم‌شده سریع‌ترین است») قابل تعمیم است.

آیا باید از هاست اشتراکی به VPS مهاجرت کنم؟ اگر سایت شما شرکتیِ کوچک یا شخصی است، هاست وردپرس‌محور انتخاب بهتری است؛ چون هم پایداری خوبی دارد و هم نگهداری‌اش دست شما نیست. مهاجرت به VPS فقط اگر تیم فنی دارید یا پروژه، درآمد جدی دارد منطقی است. راهنمای مهاجرت در مهاجرت از هاست اشتراکی به VPS آمده.

چرا هاست ابری در آزمایش، بهترین نبود؟ چون سرور ابری به‌طور پیش‌فرض بهینه نشده بود. با تنظیم کش و بهینه‌سازی PHP-FPM، می‌توانست رتبه بالاتری بگیرد. این خودش درسی از آزمایش است: معماری به‌تنهایی کافی نیست، تنظیمات دقیق لازم است.

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

چقدر طول می‌کشد تا نتیجه مهاجرت در Google Search Console دیده شود؟ داده میدانی CrUX، ۷۵امین صدک ۲۸ روز گذشته است؛ پس دو تا چهار هفته زمان لازم است تا تغییرات در گزارش گوگل ظاهر شود. صبر کنید و بر اساس داده قضاوت کنید، نه بر اساس حس روز اول.

از نگاه معماری زیرساخت

برای تیم‌های فنی، این آزمایش یک درس مهم‌تر از عددهایش دارد: در معماری زیرساخت، تصمیم‌ها را باید روی «بودجه کارایی» بنا کرد، نه روی «بهترین مقدار مطلق». اگر بودجه LCP شما زیر ۲.۵ ثانیه است و ۷۵٪ آن خارج از کنترل هاست است، خرید هاستی که TTFB را از ۲۲۰ به ۱۵۰ میلی‌ثانیه کاهش می‌دهد، تنها حدود ۳٪ به LCP نهایی اضافه می‌کند. در مقابل، همان مقدار بودجه اگر صرف بهینه‌سازی تصویر شاخص و حذف CSS بلااستفاده شود، می‌تواند ۱۵ تا ۲۵٪ بهبود LCP بسازد. این مقایسه، تصمیم‌گیری در مورد هزینه را از دوقطبی «هاست ارزان یا گران» آزاد می‌کند و به یک انتخاب مهندسی تبدیل می‌کند: در کدام لایه، هر واحد هزینه بیشترین بازده را می‌دهد. سه اصل عملی که در پروژه‌های سازمانی روی آن توافق داریم: اول، جدا کردن نقش‌ها (سرور، کش، CDN، بهینه‌سازی محتوا) و سنجش جداگانه هر کدام؛ دوم، تفکیک «بودجه پایه» از «بودجه اوج» — یعنی مشخص کردن اینکه در ساعات پیک، چه سطحی از کارایی قابل قبول است؛ سوم، تصمیم‌گیری بر اساس «بازه سه‌ساله» نه ماه اول، چون هزینه‌های پنهان (مهاجرت، نگهداری، آموزش تیم) معمولاً در سه سال اول خودشان را نشان می‌دهند. در تجربه من، تیم‌هایی که این چارچوب را اجرا می‌کنند، در تصمیم‌های زیرساختی، هم کمتر هزینه می‌کنند و هم کیفیت پایدارتری می‌سازند. در مقابل، تصمیم‌های مبتنی بر مقایسه‌های تک‌متغیر یا توصیه‌های عمومی، در ماه سوم همیشه یک جایی می‌شکنند — و آن شکست، هزینه‌اش بیشتر از صرفه‌جویی اولیه است.

برداشت شخصی از این آزمایش

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