سؤال همیشه به همین شکل مطرح می‌شود: «هاست من Apache است، مهاجرت به LiteSpeed کنم سرعت بالا می‌رود؟» و جواب تبلیغاتی همیشه یک عدد است. اما سرعت یک سایت وردپرسی حاصل‌ضرب چهار لایه است و وب‌سرور فقط یکی از آن‌هاست. اگرگلوگاه در دیتابیس یا در یک افزونهٔ سنگین باشد، هیچ وب‌سروری نجاتت نمی‌دهد.
در این مقاله سه وب‌سرور را از نظر معماری مقایسه می‌کنم، می‌گویم روی هاست اشتراکی سی‌پنل کدام انتخاب واقع‌بینانه است، و روش اندازه‌گیری‌ای را توضیح می‌دهم که به‌جای عددِ تبلیغاتی، رفتار واقعی سایت خودت را نشان بدهد. این صفحهٔ ستونِ خوشهٔ «سرور و عملیات» است؛ بقیهٔ مقاله‌های این خوشه هر کدام یک لایه را باز می‌کنند.
سه وب‌سرور را از کجا بشناسیم
Apache قدیمی‌ترین و سازگارترین است. مدلی که سال‌ها استاندارد بوده، per-process یا با mpm_event به‌صورت per-thread است: برای هر اتصال همزمان یک پروسه یا ترد درگیر می‌شود. انعطاف‌پذیری آن بی‌نظیر است؛ .htaccess، هزاران ماژول، و سازگاری با هر تنظیمی که در بیست سال نوشته شده. بهای آن هم روشن است: اتصال‌های همزمانِ بی‌کار (keep-alive روی موبایل ضعیف، کاربری که تب را باز گذاشته) منابع را بلوکه نگه می‌دارند.
Nginx مدل event-driven و غیرهمزمان دارد. تعداد کمی worker process و هر کدام هزاران اتصال را با یک ترد مدیریت می‌کند. برای سرو کردن فایل استاتیک و عمل‌کردن به‌عنوان proxy جلوی یک backend مثل PHP-FPM، بسیار کارآمد است. اما PHP-FPM خودش یک استخر جدا و هم‌پیکربندی‌شدنی است؛ یعنی عملاً دو سیستم را باید همزمان مدیریت کنی.
LiteSpeed event-driven است ولی فلسفهٔ متفاوتی دارد: سازگاری باینری با Apache را هدف گرفته. ماژول‌های Apache مثل mod_rewrite روی آن کار می‌کنند، فایل .htaccess خوانده می‌شود، و روی سی‌پنل معمولاً به‌جای Apache جایگزین می‌شود بدون اینکه ساختار اکانت‌ها عوض شود. نسخهٔ اصلی‌اش Enterprise پولی است؛ آنچه هاست‌های سی‌پنل استفاده می‌کنند نسخهٔ رایگان OpenLiteSpeed یا بیلد ادغامی با cPanel است. افزونهٔ LSCache هم همان‌جا می‌نشیند و کش را در همان لایهٔ وب‌سرور انجام می‌دهد.
معماری اجرا: پروسه، ترد، یا رویداد
تفاوت عدد اصلی در همین‌جاست. فرض کن ۵۰۰ اتصال همزمان داری و ۴۸۰ تایشان در حالت keep-alive بی‌کار نشسته‌اند.
در مدل پروسه‌محور، آن ۴۸۰ اتصال همچنان یک واحد اجرایی با حافظهٔ مخصوص خودشان درگیر نگه می‌دارند. اگر MaxRequestWorkers پر شود، اتصال‌های تازه در صف می‌مانند و زمان پاسخ بالا می‌رود؛ ولی این اتفاق نه خطا می‌دهد و نه در لاگ چیزی می‌نویسد که اسمش «مشکل وب‌سرور» باشد.
در مدل رویداد‌محور، اتصال بی‌کار یک عدد در یک فهرست است، نه یک پروسه. حافظه و CPU مصرف نمی‌کند تا زمانی که دیتایی برسد. روی همان ترافیک، تعداد پروسه‌ها ثابت می‌ماند.
اما نکته‌ای که معمولاً جا می‌افتد: در وردپرس، کار واقعی را PHP انجام می‌دهد. هر درخواستی که کش نخورد، باید به lsphp (روی LiteSpeed) یا php-fpm (روی Nginx) برود و آنجا تجزیه و اجرا شود. اگر استخر PHP شما ۱۰ worker داشته باشد و سایت ۱۰ درخواست همزمانِ کش‌نخورده بگیرد، هیچ وب‌سروری معجزه نمی‌کند؛ صف شدن در backend اتفاق می‌افتد، نه در لایهٔ پذیرش اتصال. پس مقایسهٔ LiteSpeed با Nginx روی یک سایت وردپرسی بدون صحبت از تنظیم PHP و کش، مقایسهٔ ناقص است.
کش در لایهٔ وب‌سرور؛ تفاوت واقعی اینجاست
روی سی‌پنل با LiteSpeed، افزونهٔ LSCache صفحهٔ HTML کامل را در خودِ وب‌سرور ذخیره می‌کند. درخواست بعدی اصلاً به PHP نمی‌رسد؛ یعنی نه wp-load.php اجرا می‌شود، نه کوئری دیتابیس می‌رود، نه OPcache درگیر می‌شود. این بزرگ‌ترین اثر عملی است که روی وردپرس می‌توانی بگیری، و ربطی به «سریع‌تر بودن LiteSpeed در خاموش‌کردن PHP» ندارد: ربط به نردان آن دارد.
روی Nginx هم می‌شود همین را داشت، با fastcgi_cache. اما آن تنظیمات دستی است: تعریف zone، کلید کش، حذف از کش هنگام انتشار مطلب، قواعد رد کردن کوکی ورود و سبد خرید، و اعتبارسنجی اینکه کش به کاربر لاگین‌کرده نخورد. روی هاست اشتراکی معمولاً دسترسی به آن فایل‌ها نداری، پس عملاً این گزینه روی میز نیست. روی سرور اختصاصی، کاملاً روی میز است و نتیجه‌اش هم‌ارز است.
روی Apache هم mod_cache و mod_fcgi هست، ولی در عمل روی هاست‌های اشتراکی کمتر تنظیم شده می‌بینی. پس جمع‌بندی منصفانه این است: روی هاست اشتراکی سی‌پنل، LiteSpeed به‌خاطر کش آماده‌اش می‌برد، نه به‌خاطر معماری. روی سرور اختصاصی با یک مهندس ناظر، Nginx + PHP-FPM + FastCGI cache به همان نقطه می‌رسد و کنترل بیشتری می‌دهد.
HTTP/3، Brotli و آنچه عدد را عوض می‌کند
دو قابلیت وجود دارد که مستقیماً روی اتصال اثر می‌گذارند و در انتخاب وب‌سرور مهم‌اند:
HTTP/3 با QUIC روی لینک‌های پرتلاطم و موبایل تفاوت محسوس ایجاد می‌کند، چون سر‌ش‌بستگی بسته‌ها و اتصال مجدد را حذف می‌کند. LiteSpeed از اولین پیاده‌سازی‌های جدی HTTP/3 بود و روی سی‌پنل معمولاً با یک سوییچ فعال می‌شود. روی Nginx هم از نسخه‌های اخیر پشتیبانی اضافه شده ولی تنظیمش دستی است.
Brotli در برابر gzip روی محتوای متنی فارسی معمولاً حجم کمتری تولید می‌کند؛ این برای سایت‌های فارسی که متن زیاد دارند ارزش دارد. اما نکته‌ای که در فروش هاست گفته نمی‌شود: اگر کش صفحه فعال باشد، فشرده‌سازی تقریباً بی‌مصرف است؛ چون فایل فشرده‌شدهٔ آمادهٔ قبلی سرو می‌شود. پس Brotli روی سایتی که کش ندارد مهم است، نه روی سایتی که LSCache سالم کار می‌کند.
یک مثال عملی: سایتی را که فکر می‌کنی کند است با دو سناریو تست کن. یکی با کوکی لاگین (کش رد می‌شود، همه‌چیز از PHP می‌آید) و یکی بدون کوکی. اختلاف این دو عدد، اندازهٔ واقعی کار PHP است. اگر اختلاف بزرگ باشد، مشکل در افزونه‌ها و دیتابیس است، نه در وب‌سرور.
چطور اندازه بگیریم؛ عددی که بهت دروغ نمی‌گوید
پنج اندازهٔ ساده، ترتیب تشخیص را مشخص می‌کند.
۱) زمان پاسخ خام سرور. از خط فرمان، بدون کش مرورگر:
curl -s -o /dev/null -w 'ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}\n' https://example.com/سه بار بزن. اگر دو بار سریع و یک بار کند بود، به کش یا به warm-up OPcache فکر کن.
۲) همان عدد با کش‌رد‌کردن. اگر افزونهٔ کش کوکی مشخصی را رد می‌کند، با حذف کوکی یا با یک مسیر غیرکش‌یافته بسنج. اختلاف این با قبل، سهم PHP است.
۳) هزینهٔ افزونه‌ها. در یک محیط تست، افزونه‌ها را یکی‌یکی غیرفعال کن و همان عدد را بگیر. این خسته‌کننده است ولی تنها روش قطعی است؛ هیچ گزارشی به‌جای آن نمی‌آید.
۴) زمان کوئری‌ها. افزونه‌ای که SAVEQUERIES را فعال می‌کند در محیط تست عالی است و در پروداکشن هرگز. برای دیدن کندی دیتابیس، شمار rows و زمان هر کوئری را ببین.
۵) معیار واقعی کاربر. Core Web Vitals از مبنای «میدان» (دادهٔ کاربران واقعی) می‌آید نه از Lab. Lab عدد قابل‌تکرار می‌دهد؛ میدان نشان می‌دهد کاربر ایرانی با اینترنت خانگی چه تجربه‌ای دارد. برای تصمیم‌گیری، میدان را مبنا بگیر و Lab را برای بازتولید مشکل استفاده کن.
این پنج عدد، قبل از هر خریدی باید گرفته شوند. بیشترِ «سایت من کند است»ها با همین پنج عدد به «یک افزونهٔ خاص کند است» تبدیل می‌شود.
روی سی‌پنل چه چیزی دست‌ت را می‌گیرد
انتقال از Apache به LiteSpeed روی سی‌پنل در ظاهر یک کلیک است. اما سه مورد را باید بدانی، چون همه‌جا رخ می‌دهد و هیچ‌جا نوشته نمی‌شود.
اول: پروسه‌های PHP با نام lsphp دیده می‌شوند و آرگومان‌هایشان پنهان است. اگر بخواهی با فیلتر روی نام کامل پروسه، workerهای خودت را پیدا کنی، فهرست خالی می‌گیری و نتیجه‌اش این می‌شود که فکر می‌کنی چیزی اجرا نمی‌شود. راه درست، پرسیدن بر اساس نام‌کاربری است و خواندن مسیر باینری واقعی از /proc. این جزئیات را در مقالهٔ مخصوص خودش باز کرده‌ام.
دوم: واحد سرویس وب‌سرور lshttpd است. اگر با نام سرویس Apache آن را بپرسی، خروجی خالی می‌گیری و ممکن است نتیجه بگیری سرویس از کار افتاده، در حالی که سالم است. پیش از هر تصمیم، وضعیت سرویس درست را ببین.
سوم: چند سایت روی یک سرور با نسخه‌های PHP متفاوت. هر اکانت سی‌پنل نسخهٔ PHP خودش را دارد و هر نسخه php.ini خودش را. یعنی رفتار یک تغییر فایلی بین دو سایت می‌تواند فرق کند؛ و اگر تنظیم opcache.validate_timestamps روی یکی 0 و روی دیگری 1 باشد، دیپلوی روی یکی فوری اثر می‌کند و روی دیگری نه. این دقیقاً همان موردی است که ساعت‌ها وقت آدم را می‌گیرد.
جدول تصمیم: کدام را کجا انتخاب کنیم
| موقعیت | انتخاب منطقی | چرا | |—|—|—| | هاست اشتراکی سی‌پنل، وردپرس، تیم فنی نداریم | LiteSpeed با LSCache | کش صفحه آماده است؛ .htaccess کار می‌کند؛ تنظیم اضافه لازم ندارد | | سرور اختصاصی، تیم فنی دارد، ترافیک بالا | Nginx + PHP-FPM + FastCGI cache | کنترل کامل روی هر لایه؛ کش در وب‌سرور؛ تنظیم قابل‌کدزدن | | سرور اختصاصی با نیاز به سازگاری تنظیمات قدیمی | LiteSpeed Enterprise | رفتار Apache با معماری رویداد‌محور؛ ریسک انتقال پایین‌تر | | سایت چندزبانه با منطق شخصی‌سازی‌شده و کش پیچیده | هر سه، به‌شرط کش صحیح | مسئلهٔ اصلی انتخاب کلید کش و رد کردن کوکی است، نه وب‌سرور | | API یا پنل داخلی با درخواست‌های پست‌فراوان | وب‌سرور مهم نیست؛ PHP و دیتابیس مهم‌اند | کش صفحه اینجا کاربردی ندارد |
یک هشدار دربارهٔ جدول بالا: «سرعت» تنها معیار نیست. اگر به ماژول خاصی از Apache وابسته‌ای که روی LiteSpeed پیاده‌سازی نشده، یا به تنظیم سطح پایین Nginx نیاز داری، انتخاب عوض می‌شود. مقایسهٔ بدون قیدِ «برای چه سایتی» بی‌فایده است.
اشتباه‌های رایج در این تصمیم‌گیری
بنچمارک خالی را با سایت اشتباه گرفتن. درخواست به یک صفحهٔ استاتیک روی یک سرور خالی، هیچ‌چیز دربارهٔ وردپرس تو نمی‌گوید. تست باید با همان افزونه‌ها و همان دیتابیس باشد.
انتقال و فراموش‌کردن کش. LiteSpeed بعد از انتقال کش‌های قدیمی و CSS بحرانی از پیشین را نگه می‌دارد. اگر ظاهر به‌هم‌ریده دیدی، اول فایل CSS بحرانی تولیدشده در دورهٔ قبل را پاک کن، نه قالب را.
فعال‌کردن همهٔ گزینه‌ها یکجا. Delay JS، Combine، Minify، Critical CSS، و کش صفحه همزمان روشن شوند و سایت خراب شود، تشخیص سخت می‌شود. یک گزینه، یک تست، یک بازبینی.
باورکردن «LiteSpeed = ۵۰ برابر سریع‌تر». این ادعا معمولاً مقایسهٔ یک صفحهٔ کش‌شده با یک صفحهٔ کش‌نشده است. کش صفحه روی هر سه وب‌سرور می‌تواند باشد؛ تفاوت در آماده بودنش است.
نادیده‌گرفتن نسخهٔ PHP. ارتقا از یک نسخهٔ قدیمی PHP روی همان وب‌سرور، در خیلی از موارد بیشتر از تعویض وب‌سرور اثر می‌گذارد. پیش از هزینه‌کردن برای مهاجرت، این مسیر ارزان را تست کن.
چه زمانی این تصمیم ارزش ندارد
اگر سایتت کمتر از چند هزار بازدید روزانه دارد، کش صفحهٔ درست تنظیم‌شده، تصاویر بهینه، و یک قالب سبک، تقریباً همیشه کافی است. تفاوت LiteSpeed و Nginx در نقطه‌ای خودش را نشان می‌دهد که همزمانی بالا برود، کش رد شود (سبد خرید، ورود کاربر، پنل مشتری) یا کوئری‌های سنگین به‌میز برسند.
اگر در آن نقطه نیستی، وقتت را روی سه چیز دیگر بگذار: افزونه‌های اضافی را حذف کن، تصاویر را سبک کن، و دیتابیس را از رکوردهای بی‌استفاده تمیز کن. این سه کار هم ارزانت‌اند و هم زودتر اثرشان را در دادهٔ میدان نشان می‌دهند.
پیش از تعویض، این سه کار را بکن
نکته‌ای که در مقایسهٔ وب‌سرور گم می‌شود این است که سه کار بی‌هزینه‌تر، معمولاً بیشتر از تعویض وب‌سرور اثر دارند. اگر عجله داری برای بالا بردن سرعت، این سه را اول انجام بده و بعد عدد را دوباره بگیر.
اول: کش صفحه را درست تنظیم کن، نه فقط فعال. تفاوت بین «افزونهٔ کش نصب است» و «کش درست کار می‌کند» زیاد است. علامت‌های تنظیم غلط این‌ها هستند: کاربر واردشده هم نسخهٔ کش‌شده می‌بیند؛ سبد خرید ووکامرس روی صفحهٔ کش‌شده خالی می‌ماند؛ یا هر بار که مطلب تازه‌ای منتشر می‌کنی، صفحهٔ اصلی تا چند دقیقه قدیمی می‌ماند. سه تست ساده: یک بار با کوکی ورود، یک بار ناشناس، و یک بار دقیقاً بعد از ویرایش یک نوشته. اگر پاسخ‌ها منطقی بودند، کش سر جایش است. اگر نبود، هر وب‌سروری که انتخاب کنی همان مشکل را با همان سرعت برایت نگه می‌دارد.
دوم: تصاویر را واقعاً سبک کن. در خیلی از سایت‌های فارسی، تصویر شاخص و تصاویر محصول، بزرگ‌ترین بخش وزن صفحه‌اند؛ گاهی بیشتر از کل کد. تبدیل به فرمت مدرن، بریدن اندازهٔ اضافی، و تعیین عرض و ارتفاع مشخص تا صفحه هنگام بارگذاری لنگش نزند، سه کاری است که اثرشان را در معیارهای(Core Web Vitals) کاربر واقعی می‌بینی، نه فقط در عدد آزمایشگاهی. اگر لود تنبل روی تصویر نخستین صفحه هم روشن باشد، نتیجه برعکس می‌شود؛ این را در مقالهٔ مخصوص خودش باز کرده‌ام.
سوم: نسخهٔ PHP را بررسی کن. ارتقا به نسخه‌های تازه‌تر PHP روی همان هاست، در موقعیت‌های واقعی، جهش اندازه‌گیری‌شدنی ایجاد می‌کند و هزینه‌اش یک انتخاب در پنل است. اما این کار دو احتیاط دارد: افزونه‌ها و قالب باید با نسخهٔ هدف سازگار باشند، و بعد از تغییر باید کش PHP workerها تازه شود تا رفتار نو دیده شود. اگر بعد از تغییر نسخه، هیچ‌چیز عوض‌شده‌به‌نظر رسید، احتمالاً هنوز bytecode قدیمی در حافظه است؛ نه اینکه تنظیم اثر نکرده باشد.
سناریوی واقعی: از Apache به LiteSpeed روی سی‌پنل
فرض کن هاستت Apache بوده و حالا LiteSpeed فعال شده. این کارها را به همان ترتیب انجام بده، چون ترتیب‌شان اهمیت دارد:
۱. پشتیبان بگیر، و بازگردانی را امتحان کن. بکاپی که تست نشده، بکاپ نیست. اگر مهاجرت خراب شد، باید بتوانی در چند دقیقه برگردی.
۲. کش‌های قدیمی را پاک کن. CSS بحرانی، فایل‌های ترکیب‌شده، و نسخه‌های کش‌شده از دورهٔ قبلی، محتمل‌ترین علت به‌هم‌ریختگی ظاهر بعد از مهاجرت‌اند. در محیطی که کار می‌کنی این‌ها را بشکن، نه قالب را متهم کن.
۳. افزونهٔ کش وب‌سرور را نصب و اتصالش را تست کن. اگر افزونه به وب‌سرور وصل نباشد، پاک‌کردن کش از پیشخوان بی‌اثر است و تو فکر می‌کنی تغییرات اعمال نشده‌اند.
۴. چک‌لیست رفتاری را اجرا کن: صفحهٔ اصلی، یک نوشتهٔ منفرد، صفحهٔ دسته‌بندی، سبد خرید، تسویه، ورود کاربر، و پنل کاربری. این هفت مسیر، بیشترِ شکست‌های کش را نشان می‌دهند.
۵. عدد بگیر و با پیش از مهاجرت مقایسه کن. همان پنج اندازه‌ای که بالا گفتم، همان مسیرها، همان ساعت از روز. مقایسهٔ بی‌روش، فقط توهم پیشرفت می‌دهد.
۶. چند روز پایش کن. مهاجرت وب‌سرور می‌تواند خطاهای ۵xx پراکنده یا صف شدن درخواست‌ها ایجاد کند که در تست یک‌باره دیده نمی‌شوند. لاگ خطای دامنه را ببین، نه فقط صفحه را.
اگر بعد از این شش قدم عدد بهتر نشد، مشکل از وب‌سرور نبوده است؛ و برگشتن هم چیزی را درست نمی‌کند. در آن حالت باید به لایهٔ بعدی بروی: دیتابیس، افزونه‌ها، یا قالب.
چه چیزی را نمی‌توان با وب‌سرور حل کرد
مرزها را بدان، تا هزینهٔ اشتباه ندهی.
کندی دیتابیس با وب‌سرور حل نمی‌شود. کوئری سنگین روی جدول بزرگ، همان‌قدر طول می‌کشد؛ فرقی نمی‌کند چه چیزی جلوی آن ایستاده باشد. علامتش این است که صفحه‌های کش‌شده سریع‌اند ولی هر درخواستی که کش را رد می‌کند کند است.
افزونهٔ بد با وب‌سرور بدتر نمی‌شود و بهتر هم نمی‌شود. اگر افزونه‌ای در هر درخواست یک کار شبکهٔ خارجی انجام می‌دهد، وب‌سرور فقط تماشاچی است. اینجا تنها راه، حذف یا جایگزینی خود افزونه است.
ترافیک ربات و حملهٔ حجم‌محور، بحث دیگری است. وب‌سرورهای رویداد‌محور در برابر اتصال‌های نیمه‌باز مقاوم‌ترند، و این یک امتیاز واقعی LiteSpeed و Nginx در برابر مدل پروسه‌محور است. ولی این مقاومت به معنای مصونیت نیست؛ نرخ‌محدودسازی، فایروال، و کش در لبه، همان چیزهایی‌اند که بار را کم می‌کنند. اگر سایتت هدف این نوع فشار قرار گرفته، مسئلهٔ تو وب‌سرور نیست، معماری جلوی سایت است.
و هیچ‌کدام محتوای بی‌کیفیت را رتبه نمی‌دهند. سرعت، شرط لازم است نه کافی. سایت سریع با محتوای بی‌ارزش، سریع‌تر می‌آید و سریع‌تر می‌رود.
جمع‌بندی
روی هاست اشتراکی سی‌پنل با وردپرس، LiteSpeed انتخاب منطقی است و دلیلش واقعی است: کش صفحهٔ آماده در همان لایه، سازگاری با تنظیمات Apache، و در دسترس بودن HTTP/3 بدون تنظیم دستی. این به آن معنا نیست که در همهٔ موقعیت‌ها بهتر از Nginx است؛ روی سرور اختصاصی با تیم فنی، Nginx + PHP-FPM + FastCGI cache کنترل بیشتری می‌دهد و به همان نتیجه می‌رسد.
و مهم‌تر از انتخاب: قبل از هر تصمیمی، پنج عددی که بالا گفتم را بگیر. بدون عدد، انتخاب وب‌سرور فقط عوض‌کردن یک متغیر ناشناخته با یک متغیر ناشناختهٔ دیگر است.
مقالبی بخوانی
- کش OPcache و گزینه validate_timestamps؛ چرا بعد از آپلود فایل، سایت هنوز کد قدیمی را اجرا می‌کند؟
- چرا سایت وردپرسی کند است؛ اندازه‌گیری به‌جای حدس
- types-of-website-caching
- google-core-web-vitals
- cpanel-vs-directadmin-vs-plesk
- اعتبار موضوعی و لینک‌دهی خوشه‌ای؛ ساختار ستون و خوشه در عمل
- محتوای انبوه یا Scaled Content Abuse؛ سیاستی که سایت‌های پُرمقاله را تنبیه می‌کند
- شصت روز اول یک پروژهٔ سئو؛ ترتیب واقعی کار
- امن‌سازی وردپرس روی هاست سی‌پنل؛ پانزده کاری که واقعاً مانع می‌شوند
- MySQL یا MariaDB برای وردپرس؛ تفاوت عملی روی هاست سی‌پنل
- وب‌شل چیست و چطور روی هاست اشتراک پیدا می‌شود؟
- SPF و DKIM و DMARC؛ چرا ایمیل فرم‌های سایت به پوشه اسپم می‌رود؟
امید بداق
من متخصص سئو که عاشق اینه به کسب‌وکارها کمک کنه تو گوگل دیده بشن!از وردپرس گرفته تا سئو، هرچیزی که برای رشد آنلاین نیاز داری میتونم کمکت کنم.