چرا سایت بعد از انتقال هاست کند شده است؟ بررسی کامل دلایل فنی و راه‌حل‌ها

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

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

در این مقاله تمام دلایل مهمی که می‌توانند باعث کند شدن سایت پس از انتقال هاست شوند را بررسی می‌کنیم. علاوه بر توضیح هر عامل، روش عیب‌یابی، ابزارهای مناسب برای بررسی و راهکارهای رفع مشکل نیز ارائه می‌شود تا بتوانید علت واقعی افت سرعت را شناسایی کرده و عملکرد سایت را به حالت مطلوب بازگردانید.

۱- منابع هاست جدید ضعیف‌تر از هاست قبلی است

اولین موردی که باید بعد از انتقال هاست بررسی شود، منابع واقعی سرور جدید است. بسیاری از کاربران هنگام خرید هاست تنها به حجم فضای ذخیره‌سازی یا میزان RAM توجه می‌کنند، در حالی که سرعت یک وب‌سایت به عوامل متعددی وابسته است. ممکن است دو سرویس روی کاغذ مشخصات تقریبا مشابهی داشته باشند، اما به دلیل تفاوت در پردازنده، سرعت دیسک، کیفیت مجازی‌سازی یا میزان بار سرور، عملکرد کاملا متفاوتی ارائه دهند. به همین دلیل قبل از تغییر تنظیمات نرم‌افزاری، بهتر است مطمئن شوید زیرساخت سخت‌افزاری سرویس جدید پاسخگوی نیازهای سایت شما است.

قدرت CPU مهم‌تر از تعداد هسته‌ها است

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

برای مثال، ممکن است دو سرور هر دو چهار هسته پردازشی داشته باشند، اما یکی از پردازنده‌های جدید AMD EPYC یا Intel Xeon Scalable استفاده کند و دیگری به پردازنده‌ای چند نسل قدیمی مجهز باشد. در چنین شرایطی اختلاف عملکرد هنگام پردازش درخواست‌های سنگین کاملا محسوس خواهد بود؛ مخصوصا اگر سایت از وردپرس، ووکامرس یا افزونه‌های متعدد استفاده کند. به همین دلیل هنگام انتخاب سرویس، بررسی نوع پردازنده به اندازه میزان منابع اهمیت دارد و اگر قصد ارتقای زیرساخت را دارید، استفاده از سرور با پردازنده بهینه می‌تواند بسیاری از مشکلات شما با قدرت پردازنده را حل کند. 

تعداد Core و Thread چه تاثیری دارند؟

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

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

محدودیت‌های پردازشی در هاست اشتراکی

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

این مشکل معمولا در سایت‌هایی دیده می‌شود که تعداد زیادی افزونه نصب کرده‌اند، فروشگاه اینترنتی دارند یا همزمان کاربران زیادی در حال استفاده از سایت هستند. در چنین شرایطی ممکن است سایت در ساعات کم‌ترافیک کاملا عادی باشد اما در ساعات شلوغ، افت سرعت محسوسی را تجربه کند.

میزان RAM و سرعت Disk I/O

کمبود حافظه RAM یکی دیگر از عواملی است که می‌تواند عملکرد سایت را کاهش دهد. زمانی که حافظه کافی در اختیار PHP یا MySQL قرار نگیرد، سیستم ناچار می‌شود بخشی از اطلاعات را روی دیسک ذخیره کند که نسبت به حافظه اصلی سرعت بسیار کمتری دارد. این موضوع مخصوصا هنگام اجرای افزونه‌های سنگین یا پردازش همزمان چند درخواست خود را نشان می‌دهد.

علاوه بر RAM، سرعت خواندن و نوشتن اطلاعات روی دیسک یا Disk I/O نیز اهمیت زیادی دارد. اگر دیسک سرور نتواند اطلاعات را با سرعت کافی پردازش کند، حتی استفاده از پردازنده قدرتمند نیز تاثیر چندانی بر عملکرد نهایی سایت نخواهد داشت. به همین دلیل هنگام مقایسه دو سرویس، بهتر است نوع فضای ذخیره‌سازی نیز بررسی شود.

نوع فضای ذخیره‌سازی	عملکرد
HDD	پایین
SATA SSD	مناسب
NVMe SSD	بسیار سریع

در سایت‌هایی که تعداد زیادی فایل، تصویر یا کوئری دیتابیس دارند، استفاده از NVMe می‌تواند زمان بارگذاری صفحات را نسبت به SSDهای SATA به شکل محسوسی کاهش دهد.

Overselling منابع در هاست اشتراکی

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

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

تاثیر Load Server بر سرعت سایت

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

اگر از سرور مجازی یا اختصاصی استفاده می‌کنید، می‌توانید وضعیت Load را با دستور زیر بررسی کنید.

uptime

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

top

اگر مقدار Load به صورت مداوم بالا باشد، لازم است مصرف پردازنده، تعداد پردازش‌های فعال و سرویس‌هایی که بیشترین منابع را مصرف می‌کنند بررسی شوند. در بسیاری از موارد، همین بررسی ساده می‌تواند علت اصلی کند شدن سایت بعد از انتقال هاست را مشخص کند.

۲- تغییر موقعیت جغرافیایی سرور باعث افزایش زمان پاسخ شده است

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

Latency و فاصله جغرافیایی

Latency مدت زمانی است که یک بسته اطلاعات برای رفتن از دستگاه کاربر به سرور و دریافت پاسخ اولیه نیاز دارد. هرچه فاصله جغرافیایی بیشتر باشد، این زمان نیز افزایش پیدا می‌کند. البته فاصله تنها عامل موثر نیست و کیفیت زیرساخت شبکه، تعداد روترهای بین مسیر و نحوه مسیریابی اینترنت نیز روی این عدد تاثیر می‌گذارند.

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

افزایش TTFB بعد از انتقال هاست

یکی از اولین شاخص‌هایی که تحت تاثیر فاصله جغرافیایی قرار می‌گیرد، TTFB یا Time To First Byte است. این معیار نشان می‌دهد چه مدت طول می‌کشد تا مرورگر اولین بایت اطلاعات را از سرور دریافت کند. اگر قبل از انتقال مقدار TTFB حدود ۱۵۰ میلی‌ثانیه بوده و بعد از مهاجرت به ۵۰۰ یا ۶۰۰ میلی‌ثانیه رسیده است، احتمال دارد موقعیت سرور یا کیفیت مسیر شبکه عامل اصلی این افزایش باشد.

به همین دلیل همیشه توصیه می‌شود TTFB قبل و بعد از انتقال هاست ثبت شود تا بتوان تغییرات را به صورت دقیق مقایسه کرد.

کیفیت دیتاسنتر و Routing

دو دیتاسنتر که هر دو در یک کشور قرار دارند نیز ممکن است عملکرد کاملا متفاوتی داشته باشند. کیفیت ارتباط اپراتورها، تعداد مسیرهای بین‌المللی، ظرفیت شبکه و نحوه Routing می‌تواند روی سرعت دسترسی کاربران تاثیر قابل توجهی بگذارد.

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

اگر بیشتر بازدیدکنندگان سایت داخل ایران هستند، انتخاب زیرساختی که از نظر شبکه برای کاربران داخلی بهینه شده باشد اهمیت زیادی دارد. در چنین شرایطی استفاده از سرور با منابع اختصاصی ایران می‌تواند تاخیر شبکه را کاهش دهد و زمان پاسخ سرور را برای کاربران ایرانی بهبود ببخشد.

چگونه این مشکل را بررسی کنیم؟

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

۳- کش سایت بعد از انتقال به‌درستی فعال نشده است

یکی از رایج‌ترین دلایل افت سرعت بعد از انتقال هاست، غیرفعال شدن سیستم‌های کش است. در بسیاری از مهاجرت‌ها فایل‌ها و دیتابیس بدون مشکل منتقل می‌شوند، اما تنظیمات مربوط به کش سمت سرور، کش PHP یا افزونه‌های کش به درستی بازیابی نمی‌شوند. در نتیجه سایت همچنان بدون خطا اجرا می‌شود، اما هر درخواست باید دوباره توسط PHP و دیتابیس پردازش شود و همین موضوع باعث افزایش زمان بارگذاری خواهد شد.

Full Page Cache

Full Page Cache نسخه آماده صفحات را ذخیره می‌کند تا در درخواست‌های بعدی نیازی به اجرای مجدد PHP و کوئری‌های دیتابیس نباشد. اگر این قابلیت بعد از انتقال غیرفعال شود، سرور مجبور است برای هر کاربر صفحه را از ابتدا تولید کند که در سایت‌های پربازدید می‌تواند فشار قابل توجهی روی منابع ایجاد کند.

این موضوع به ویژه در فروشگاه‌های اینترنتی یا سایت‌های خبری که تعداد صفحات زیادی دارند، تاثیر بیشتری خواهد داشت.

Object Cache و Redis

Object Cache وظیفه ذخیره اطلاعاتی را بر عهده دارد که بارها توسط وردپرس یا افزونه‌ها مورد استفاده قرار می‌گیرند. Redis و Memcached دو مورد از رایج‌ترین ابزارهای پیاده‌سازی این نوع کش هستند.

گاهی افزونه Redis همچنان در وردپرس فعال است، اما سرویس Redis روی سرور جدید نصب یا اجرا نشده است. در چنین شرایطی سایت بدون نمایش خطای جدی کار می‌کند، اما تعداد زیادی از کوئری‌های دیتابیس دوباره اجرا می‌شوند و همین موضوع باعث کاهش سرعت خواهد شد.

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

LiteSpeed Cache

اگر هاست قبلی از LiteSpeed استفاده می‌کرد اما سرویس جدید بر پایه Apache یا Nginx راه‌اندازی شده باشد، ممکن است بخشی از قابلیت‌های افزونه LiteSpeed Cache دیگر قابل استفاده نباشند. در نتیجه با وجود فعال بودن افزونه، عملکرد آن مشابه قبل نخواهد بود.

به همین دلیل بعد از انتقال باید سازگاری افزونه کش با وب‌سرور جدید نیز بررسی شود و در صورت نیاز، از راهکارهای جایگزین استفاده شود.

Browser Cache

کش مرورگر نیز نقش مهمی در تجربه کاربران دارد. اگر هدرهای Cache-Control یا Expires به درستی تنظیم نشده باشند، مرورگر مجبور می‌شود در هر بار مراجعه دوباره فایل‌های CSS، JavaScript و تصاویر را از سرور دانلود کند. این موضوع به ویژه برای کاربرانی که چندین بار از سایت بازدید می‌کنند، باعث افزایش زمان بارگذاری خواهد شد.

تنظیم صحیح Browser Cache معمولا فشار روی سرور را نیز کاهش می‌دهد و پهنای باند کمتری مصرف خواهد شد.

چگونه مشکل کش را پیدا کنیم؟

بعد از انتقال هاست، بهتر است موارد زیر بررسی شوند:

• فعال بودن OPcache
• اجرای صحیح Redis یا Memcached
• عملکرد افزونه LiteSpeed Cache
• فعال بودن Full Page Cache
• تنظیم بودن Browser Cache
• پاک شدن کش قدیمی و تولید مجدد فایل‌های کش

در بسیاری از موارد، تنها فعال کردن دوباره یکی از این بخش‌ها می‌تواند سرعت سایت را به وضعیت قبل از انتقال بازگرداند.

۴- نسخه PHP یا تنظیمات آن تغییر کرده است

تغییر نسخه PHP یکی دیگر از عواملی است که می‌تواند عملکرد سایت را بهتر یا بدتر کند. بسیاری از شرکت‌های هاستینگ هنگام انتقال، به صورت خودکار از نسخه جدید PHP استفاده می‌کنند. اگرچه نسخه‌های جدید معمولا عملکرد بهتری دارند، اما ناسازگاری برخی افزونه‌ها یا تنظیمات اشتباه می‌تواند نتیجه معکوس ایجاد کند.

تفاوت PHP 8.1، 8.2 و 8.3

هر نسخه جدید PHP علاوه بر بهبودهای امنیتی، تغییراتی در موتور اجرای کد نیز ایجاد می‌کند. به همین دلیل معمولا PHP 8.3 نسبت به PHP 8.1 عملکرد بهتری دارد، اما این موضوع تنها زمانی صادق است که قالب و افزونه‌های سایت با نسخه جدید سازگار باشند.

اگر بعد از انتقال، بدون بررسی سازگاری افزونه‌ها نسخه PHP تغییر کرده باشد، ممکن است بخشی از کدها با سرعت کمتری اجرا شوند یا حتی باعث افزایش مصرف منابع شوند.

OPcache

OPcache یکی از مهم‌ترین قابلیت‌های PHP برای افزایش سرعت اجرای اسکریپت‌ها است. این قابلیت نسخه کامپایل‌شده فایل‌های PHP را در حافظه نگهداری می‌کند تا در درخواست‌های بعدی نیازی به کامپایل مجدد نباشد.

اگر OPcache روی هاست قبلی فعال بوده اما روی سرور جدید غیرفعال باشد، افزایش زمان پاسخ کاملا طبیعی خواهد بود؛ مخصوصا در سایت‌هایی که تعداد فایل‌های PHP زیاد است.

Memory Limit و Max Execution Time

مقدار Memory Limit تعیین می‌کند هر پردازش PHP چه میزان حافظه در اختیار داشته باشد. اگر این مقدار کمتر از نیاز سایت باشد، اجرای برخی افزونه‌ها یا عملیات سنگین با مشکل مواجه می‌شود و حتی ممکن است باعث کند شدن سایت شود.

همچنین مقدار Max Execution Time نیز باید متناسب با نیاز سایت تنظیم شود. اگر این مقدار بیش از حد پایین باشد، برخی پردازش‌ها قبل از تکمیل متوقف می‌شوند و اگر بیش از حد بالا باشد، پردازش‌های معیوب مدت بیشتری منابع سرور را اشغال خواهند کرد.

ناسازگاری افزونه‌ها

همه افزونه‌ها همزمان با انتشار نسخه‌های جدید PHP به‌روزرسانی نمی‌شوند. به همین دلیل اگر سایت بعد از انتقال با نسخه جدید PHP اجرا می‌شود، بهتر است لاگ‌های خطا بررسی شوند تا مشخص شود افزونه یا قالب خاصی باعث کاهش عملکرد نشده باشد. در بسیاری از پروژه‌ها، مشکل اصلی نه خود PHP، بلکه ناسازگاری یکی از افزونه‌های قدیمی با نسخه جدید است.

۵- تنظیمات وب‌سرور در هاست جدید متفاوت است

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

Apache، LiteSpeed و Nginx

هر وب‌سرور نقاط قوت و ضعف خود را دارد. Apache قدیمی‌ترین و شناخته‌شده‌ترین گزینه است و با بیشتر نرم‌افزارهای تحت وب سازگاری بالایی دارد، اما در مدیریت تعداد زیاد درخواست‌های همزمان نسبت به گزینه‌های جدیدتر ضعیف‌تر عمل می‌کند.

LiteSpeed از نظر سازگاری با Apache عملکرد مشابهی دارد، اما بهینه‌تر است و از قابلیت‌هایی مانند LiteSpeed Cache نیز پشتیبانی می‌کند. به همین دلیل بسیاری از شرکت‌های هاستینگ برای سایت‌های وردپرسی از این وب‌سرور استفاده می‌کنند.

در مقابل، Nginx معمولا مصرف منابع کمتری دارد و در مدیریت فایل‌های استاتیک و درخواست‌های همزمان عملکرد بسیار خوبی ارائه می‌دهد. البته نحوه پیکربندی آن با Apache تفاوت دارد و برخی تنظیمات باید متناسب با آن تغییر کنند.

وب‌سرور	مزیت اصلی	مناسب برای
Apache	سازگاری بالا	سایت‌های عمومی
LiteSpeed	سرعت بالا و کش داخلی	وردپرس و فروشگاه‌های اینترنتی
Nginx	مدیریت درخواست‌های همزمان	سایت‌های پرترافیک

HTTP/2 و HTTP/3

اگر سرور جدید همچنان از HTTP/1.1 استفاده کند، طبیعی است که سرعت بارگذاری نسبت به سروری که HTTP/2 یا HTTP/3 را فعال کرده بود کاهش پیدا کند. نسخه‌های جدید این پروتکل امکان ارسال همزمان چندین فایل را فراهم می‌کنند و تاخیر شبکه را کاهش می‌دهند.

برای سایت‌هایی که تعداد زیادی فایل CSS، JavaScript یا تصویر دارند، فعال بودن HTTP/2 و به ویژه HTTP/3 می‌تواند تاثیر محسوسی بر تجربه کاربران داشته باشد.

فشرده‌سازی فایل‌ها

فعال بودن Gzip یا Brotli باعث می‌شود فایل‌های متنی مانند HTML، CSS و JavaScript قبل از ارسال برای کاربر فشرده شوند. در نتیجه حجم اطلاعات منتقل‌شده کاهش پیدا می‌کند و صفحات سریع‌تر بارگذاری می‌شوند.

امروزه Brotli نسبت به Gzip نرخ فشرده‌سازی بهتری ارائه می‌دهد و اگر وب‌سرور از آن پشتیبانی کند، معمولا انتخاب مناسب‌تری خواهد بود.

Keep Alive

Keep Alive باعث می‌شود مرورگر برای دریافت چند فایل مختلف مجبور نباشد برای هر درخواست یک اتصال جدید با سرور ایجاد کند. اگر این قابلیت روی سرور جدید غیرفعال باشد، مخصوصا در صفحاتی که فایل‌های زیادی دارند، زمان بارگذاری افزایش پیدا خواهد کرد.

به همین دلیل بعد از انتقال هاست، بررسی تنظیمات مربوط به Keep Alive، Compression و نسخه HTTP می‌تواند بخش مهمی از فرآیند عیب‌یابی باشد.

۶-دیتابیس بعد از انتقال بهینه نیست

اگرچه انتقال فایل‌های سایت معمولا بدون مشکل انجام می‌شود، اما دیتابیس همیشه به همان شکل قبلی عمل نمی‌کند. تغییر نسخه MySQL، تنظیمات MariaDB یا حتی Fragment شدن جداول می‌تواند باعث افزایش زمان اجرای کوئری‌ها شود. در نتیجه ممکن است ظاهر سایت کاملا عادی باشد، اما هر صفحه برای تولید شدن به زمان بیشتری نیاز داشته باشد.

تفاوت MySQL و MariaDB

بسیاری از شرکت‌های هاستینگ به جای MySQL از MariaDB استفاده می‌کنند. هر دو سیستم سازگاری بالایی با یکدیگر دارند، اما نسخه‌های مختلف آن‌ها ممکن است در نحوه اجرای برخی کوئری‌ها یا استفاده از حافظه تفاوت داشته باشند.

به همین دلیل اگر بعد از انتقال نسخه دیتابیس تغییر کرده باشد، بهتر است عملکرد سایت دوباره بررسی شود و در صورت نیاز تنظیمات بهینه‌سازی اعمال شود.

InnoDB Buffer Pool

یکی از مهم‌ترین تنظیمات MySQL، مقدار InnoDB Buffer Pool است. این بخش اطلاعات پرکاربرد دیتابیس را در حافظه نگهداری می‌کند تا نیاز به خواندن مداوم از دیسک کاهش پیدا کند.

اگر این مقدار کمتر از حد نیاز باشد، تعداد دسترسی به دیسک افزایش پیدا می‌کند و زمان اجرای کوئری‌ها بیشتر خواهد شد. در سرورهای اختصاصی و مجازی، تنظیم صحیح Buffer Pool می‌تواند تاثیر قابل توجهی بر سرعت سایت داشته باشد.

کوئری‌های سنگین و Index های ناقص

گاهی خود انتقال هاست مشکلی ایجاد نمی‌کند، بلکه تغییر نسخه دیتابیس باعث می‌شود برخی کوئری‌ها دیگر مانند قبل بهینه اجرا نشوند. همچنین اگر جداول Index مناسبی نداشته باشند، دیتابیس برای پیدا کردن اطلاعات مجبور می‌شود حجم زیادی از داده‌ها را اسکن کند.

در سایت‌های فروشگاهی که محصولات و سفارش‌های زیادی دارند، این موضوع می‌تواند زمان تولید صفحات را به شکل محسوسی افزایش دهد.

Fragment شدن جداول

حذف و اضافه مداوم اطلاعات در دیتابیس باعث Fragment شدن جداول می‌شود. در این حالت اطلاعات به صورت پراکنده روی دیسک ذخیره می‌شوند و دسترسی به آن‌ها زمان بیشتری نیاز دارد.

اجرای عملیات Optimize روی جداول می‌تواند در برخی پروژه‌ها عملکرد دیتابیس را بهبود دهد، هرچند نباید از آن انتظار معجزه داشت.

۷-رکورد‌های DNS هنوز به طور کامل به‌روزرسانی نشده است

یکی دیگر از دلایلی که گاهی با کند شدن سایت اشتباه گرفته می‌شود، کامل نشدن فرآیند انتشار DNS است. پس از تغییر Nameserver یا رکوردهای DNS، همه کاربران به صورت همزمان به سرور جدید هدایت نمی‌شوند و ممکن است این فرآیند تا چند ساعت یا حتی ۴۸ ساعت زمان ببرد.

در این مدت، برخی کاربران سایت را از سرور جدید مشاهده می‌کنند و برخی دیگر همچنان به سرور قبلی متصل می‌شوند. به همین دلیل ممکن است گزارش‌های متفاوتی درباره سرعت سایت دریافت کنید.

DNS Propagation

DNS Propagation به فرآیند انتشار تغییرات DNS در سراسر اینترنت گفته می‌شود. این فرآیند به دلیل کش شدن اطلاعات روی سرورهای مختلف زمان‌بر است و سرعت آن در همه نقاط جهان یکسان نیست.

TTL

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

به همین دلیل معمولا توصیه می‌شود چند ساعت یا حتی یک روز قبل از انتقال، مقدار TTL کاهش پیدا کند تا تغییرات سریع‌تر منتشر شوند.

کش DNS در ISP

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

اگر تنها بخشی از کاربران کندی یا مشکلات اتصال را گزارش می‌کنند، بهتر است این احتمال نیز بررسی شود و قبل از ایجاد تغییرات دیگر، از کامل شدن انتشار DNS مطمئن شوید.

۸- تنظیمات CDN یا Cloudflare به‌درستی پیکربندی نشده است

اگر سایت از CDN یا Cloudflare استفاده می‌کند، انتقال هاست تنها به جابه‌جایی فایل‌ها و دیتابیس محدود نمی‌شود. در بسیاری از موارد، تنظیمات CDN نیز باید با زیرساخت جدید هماهنگ شوند. اگر این تنظیمات به درستی بررسی نشوند، ممکن است بخشی از درخواست‌ها همچنان از مسیر نامناسب عبور کنند یا فایل‌های استاتیک بدون استفاده از کش برای کاربران ارسال شوند. نتیجه چنین وضعیتی افزایش زمان بارگذاری صفحات و مصرف بیشتر منابع سرور خواهد بود.

تفاوت DNS Only و Proxied

در Cloudflare هر دامنه یا زیردامنه می‌تواند در حالت DNS Only یا Proxied قرار بگیرد. زمانی که حالت Proxied فعال باشد، درخواست‌ها ابتدا وارد شبکه Cloudflare شده و سپس به سرور اصلی ارسال می‌شوند. این موضوع علاوه بر افزایش امنیت، امکان استفاده از قابلیت‌هایی مانند کش، بهینه‌سازی تصاویر و HTTP/3 را نیز فراهم می‌کند.

اگر پس از انتقال هاست برخی رکوردها به اشتباه روی DNS Only قرار گرفته باشند، کاربران مستقیما به سرور متصل می‌شوند و دیگر از مزایای CDN استفاده نخواهند کرد. در سایت‌هایی که بازدید بالایی دارند، همین تغییر کوچک می‌تواند تاثیر محسوسی بر سرعت بارگذاری صفحات داشته باشد.

Cache Rules و Edge Cache

یکی از اشتباهات رایج، از بین رفتن یا غیرفعال شدن قوانین کش بعد از انتقال است. اگر Cache Rules به درستی تنظیم نشده باشند، Cloudflare مجبور می‌شود برای هر درخواست دوباره با سرور ارتباط برقرار کند. در نتیجه فشار بیشتری به هاست وارد می‌شود و زمان پاسخ نیز افزایش پیدا می‌کند.

در سایت‌هایی که بیشتر محتوای آن‌ها ثابت است، فعال بودن Edge Cache می‌تواند تعداد زیادی از درخواست‌ها را مستقیما از نزدیک‌ترین سرور Cloudflare پاسخ دهد. این موضوع هم باعث کاهش بار سرور می‌شود و هم تجربه بهتری برای کاربران ایجاد می‌کند.

Rocket Loader، HTTP/3 و SSL

قابلیت Rocket Loader در برخی پروژه‌ها باعث بهبود سرعت بارگذاری فایل‌های JavaScript می‌شود، اما در بعضی قالب‌ها یا افزونه‌ها نیز ممکن است مشکلات سازگاری ایجاد کند. اگر بعد از انتقال سایت با اختلال در بارگذاری فایل‌های JavaScript روبه‌رو شده‌اید، بهتر است این قابلیت نیز بررسی شود.

همچنین فعال بودن HTTP/3 و تنظیم صحیح SSL اهمیت زیادی دارد. اگر SSL به درستی پیکربندی نشده باشد یا ارتباط بین Cloudflare و سرور اصلی در حالت مناسبی قرار نگیرد، بخشی از زمان پاسخ صرف برقراری اتصال مجدد خواهد شد.

پاک شدن کش بعد از انتقال

پس از انتقال هاست، معمولا کش Cloudflare پاک می‌شود یا فایل‌های قدیمی دیگر اعتبار ندارند. تا زمانی که کش دوباره تولید شود، ممکن است کاربران افت سرعت موقتی را تجربه کنند. به همین دلیل بهتر است بعد از پایان مهاجرت، کش CDN به صورت دستی پاک شود تا نسخه جدید فایل‌ها در سریع‌ترین زمان ممکن در شبکه توزیع محتوا ذخیره شوند.

۹- فایل‌ها یا تنظیمات سایت به‌صورت کامل منتقل نشده‌اند

گاهی مشکل نه از سرور است و نه از تنظیمات نرم‌افزاری؛ بلکه بخشی از فایل‌های سایت هنگام انتقال به درستی منتقل نشده‌اند. این اتفاق بیشتر زمانی رخ می‌دهد که مهاجرت به صورت دستی انجام شده باشد یا فرآیند انتقال قبل از تکمیل متوقف شده باشد.

Permission و مالکیت فایل‌ها

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

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

فایل‌های کش قدیمی

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

به همین دلیل معمولا توصیه می‌شود بعد از انتقال، تمام فایل‌های کش حذف شده و دوباره از ابتدا تولید شوند.

تصاویر، فایل‌های استاتیک و Symlinkها

در برخی مهاجرت‌ها، تصاویر یا فایل‌های استاتیک به طور کامل منتقل نمی‌شوند یا ساختار پوشه‌ها تغییر می‌کند. در نتیجه مرورگر برای دریافت این فایل‌ها با خطاهای 404 یا تاخیرهای غیرعادی روبه‌رو می‌شود.

اگر سایت از Symlink استفاده می‌کند، باید مطمئن شوید این لینک‌ها روی سرور جدید نیز به درستی ایجاد شده‌اند. در غیر این صورت بخشی از فایل‌ها قابل دسترس نخواهند بود.

Cron Jobها

بسیاری از وب‌سایت‌ها برای ارسال ایمیل، اجرای بکاپ، بروزرسانی اطلاعات یا پاک‌سازی کش از Cron Job استفاده می‌کنند. اگر این وظایف زمان‌بندی‌شده بعد از انتقال دوباره ایجاد نشوند، ممکن است بخشی از عملکرد سایت مختل شود یا پردازش‌هایی که باید در پس‌زمینه اجرا شوند، به درخواست کاربران منتقل شوند و باعث افزایش زمان پاسخ شوند.

۱۰- محدودیت منابع سرور باعث ایجاد گلوگاه شده است

حتی اگر سخت‌افزار سرور مناسب باشد، محدودیت منابع اختصاص‌یافته به سرویس می‌تواند باعث ایجاد گلوگاه شود. این موضوع بیشتر در هاست اشتراکی یا VPSهایی دیده می‌شود که منابع مشخصی برای هر کاربر در نظر گرفته شده است.

CPU و RAM

اولین موردی که باید بررسی شود، میزان استفاده از CPU و RAM است. اگر مصرف پردازنده دائما نزدیک به حداکثر باشد یا حافظه سرور به طور کامل اشغال شده باشد، طبیعی است که زمان پاسخ افزایش پیدا کند.

بهتر است مصرف منابع در ساعات مختلف روز بررسی شود، زیرا بسیاری از مشکلات تنها هنگام افزایش بازدید خود را نشان می‌دهند.

IOPS و Disk Queue

IOPS تعداد عملیات خواندن و نوشتن روی دیسک را نشان می‌دهد. اگر تعداد درخواست‌های ورودی بیشتر از توان دیسک باشد، صفی از عملیات ذخیره‌سازی ایجاد می‌شود که به آن Disk Queue گفته می‌شود.

افزایش Disk Queue معمولا باعث کند شدن کل سرور می‌شود، زیرا پردازش‌ها باید منتظر تکمیل عملیات دیسک بمانند.

تعداد Processها و Connectionهای همزمان

هر درخواست جدید معمولا یک پردازش یا Thread جدید ایجاد می‌کند. اگر تعداد Processهای فعال از محدودیت تعیین‌شده بیشتر شود، درخواست‌های جدید در صف انتظار قرار می‌گیرند.

همین موضوع درباره تعداد Connectionهای همزمان نیز صادق است. اگر سرور نتواند تعداد زیادی اتصال را مدیریت کند، کاربران در زمان‌های شلوغ با افزایش زمان بارگذاری یا حتی خطاهای موقت روبه‌رو خواهند شد.

Entry Process و Inode

در هاست‌های اشتراکی معمولا محدودیت Entry Process تعیین می‌شود. اگر تعداد درخواست‌های همزمان از این مقدار بیشتر شود، بخشی از کاربران باید تا آزاد شدن منابع منتظر بمانند.

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

چگونه علت واقعی کند شدن سایت را پیدا کنیم؟

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

به عنوان مثال، اگر TTFB افزایش پیدا کرده اما زمان بارگذاری فایل‌های CSS و تصاویر تفاوتی نکرده است، احتمال دارد مشکل به منابع سرور، موقعیت جغرافیایی یا دیتابیس مربوط باشد. اما اگر TTFB طبیعی است و فقط دانلود فایل‌های استاتیک زمان زیادی می‌برد، بهتر است تنظیمات CDN، کش یا فشرده‌سازی فایل‌ها بررسی شوند. همین تفکیک ساده باعث می‌شود زمان زیادی صرف بررسی بخش‌های نامرتبط نشود.

ابزارهای بررسی عملکرد سایت

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

ابزار	کاربرد
GTmetrix	بررسی زمان بارگذاری صفحات و فایل‌ها
Google PageSpeed Insights	تحلیل Core Web Vitals و پیشنهادهای بهینه‌سازی
Pingdom	بررسی زمان پاسخ از نقاط مختلف جهان
WebPageTest	تحلیل دقیق مراحل بارگذاری صفحه
curl	اندازه‌گیری TTFB
top و htop	بررسی مصرف CPU و RAM
iostat	بررسی عملکرد دیسک
vmstat	بررسی وضعیت کلی منابع سیستم

بهتر است نتایج این ابزارها در کنار یکدیگر بررسی شوند. برای مثال، اگر GTmetrix زمان بارگذاری مناسبی را نشان می‌دهد اما TTFB بالا است، باید بررسی را روی سرور و دیتابیس متمرکز کنید، نه روی تصاویر یا فایل‌های CSS.

بررسی TTFB با curl

یکی از ساده‌ترین روش‌ها برای اندازه‌گیری زمان پاسخ سرور استفاده از دستور زیر است.

curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com

خروجی این دستور مدت زمانی را نمایش می‌دهد که طول کشیده تا اولین بایت اطلاعات از سرور دریافت شود. اگر این مقدار نسبت به قبل از انتقال افزایش قابل توجهی داشته باشد، باید منابع سرور، موقعیت جغرافیایی یا تنظیمات وب‌سرور بررسی شوند.

بررسی مصرف CPU

اگر به سرور مجازی یا اختصاصی دسترسی دارید، می‌توانید وضعیت پردازنده را با دستور زیر مشاهده کنید.

top

یا در صورت نصب بودن htop از دستور زیر استفاده کنید.

htop

در این بخش باید بررسی کنید کدام پردازش‌ها بیشترین مصرف CPU را دارند. گاهی یک افزونه، یک فرآیند بکاپ یا حتی یک ربات موتور جستجو می‌تواند باعث مصرف غیرعادی منابع شود.

بررسی Disk I/O

اگر احتمال می‌دهید گلوگاه عملکرد مربوط به دیسک باشد، دستور زیر اطلاعات مفیدی در اختیار شما قرار می‌دهد.

iostat -x 1

در خروجی این دستور باید به میزان استفاده از دیسک، تعداد عملیات خواندن و نوشتن و همچنین زمان انتظار دیسک توجه کنید. اگر مقدار Disk Utilization برای مدت طولانی نزدیک به صد درصد باشد، احتمال دارد مشکل از سرعت فضای ذخیره‌سازی یا تعداد زیاد درخواست‌های ورودی باشد.

بررسی وضعیت کلی سرور

برای مشاهده وضعیت کلی حافظه، پردازنده و پردازش‌های سیستم نیز می‌توانید از دستور زیر استفاده کنید.

vmstat 1

این ابزار دید مناسبی از وضعیت کلی سرور ارائه می‌دهد و می‌تواند مشخص کند که مشکل بیشتر به پردازنده، حافظه یا عملیات ورودی و خروجی دیسک مربوط است.

چک‌لیست قبل و بعد از انتقال هاست

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

چک‌لیست زیر می‌تواند قبل و بعد از انتقال هاست مورد استفاده قرار گیرد.

مورد بررسی	قبل از انتقال	بعد از انتقال
ثبت مقدار TTFB	✓	✓
ثبت Core Web Vitals	✓	✓
بررسی نسخه PHP	✓	✓
بررسی فعال بودن OPcache	✓	✓
بررسی Redis یا Memcached	✓	✓
تست LiteSpeed Cache	✓	✓
تست سرعت از داخل ایران	✓	✓
تست سرعت از خارج ایران	✓	✓
بررسی مصرف CPU و RAM	✓	✓
بررسی تنظیمات DNS	✓	✓
بررسی تنظیمات CDN	✓	✓
بررسی لاگ‌های سرور	✓	✓

اگر این اطلاعات قبل از مهاجرت ثبت شوند، بعد از انتقال به راحتی می‌توان تشخیص داد که دقیقا کدام بخش دچار تغییر شده است. برای مثال، اگر TTFB ثابت مانده اما Core Web Vitals افت کرده باشد، مشکل احتمالا به فایل‌های استاتیک یا تنظیمات فرانت‌اند مربوط است. در مقابل، اگر TTFB افزایش پیدا کرده اما سایر شاخص‌ها تغییر چندانی نداشته باشند، باید منابع سرور، دیتابیس یا مسیر شبکه بررسی شوند.

جمع بندی

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

به طور کلی، بیشتر مشکلات عملکردی پس از مهاجرت در سه دسته اصلی قرار می‌گیرند: منابع سخت‌افزاری نامناسب مانند پردازنده ضعیف، حافظه ناکافی یا سرعت پایین دیسک، تنظیمات نادرست نرم‌افزاری مانند غیرفعال بودن کش، تغییر نسخه PHP یا پیکربندی نامناسب وب‌سرور، و مشکلات شبکه شامل DNS، CDN، کیفیت Routing یا موقعیت جغرافیایی سرور. بررسی این سه بخش معمولا علت اصلی افت سرعت را مشخص می‌کند.

برای جلوگیری از بروز چنین مشکلاتی، بهتر است پیش از انتقال هاست شاخص‌هایی مانند TTFB، مصرف منابع سرور و Core Web Vitals ثبت شوند و پس از پایان مهاجرت، همان آزمون‌ها دوباره در شرایط یکسان تکرار شوند. این مقایسه ساده باعث می‌شود هرگونه تغییر در عملکرد سایت به سرعت شناسایی شود و بتوان پیش از تاثیرگذاری بر تجربه کاربران یا رتبه سایت در موتورهای جستجو، اقدامات لازم را انجام داد. همچنین اگر پس از انجام این بررسی‌ها همچنان مشکل برطرف نشد، بهتر است لاگ‌های سرور، گزارش‌های مانیتورینگ و تنظیمات سرویس میزبانی به صورت دقیق بررسی شوند تا هیچ عامل پنهانی از قلم نیفتد.