چرا پیشخوان وردپرس کند است؟ عیب‌یابی wp-cron، Heartbeat و دیتابیس

اگر صفحات عمومی سایت سریع‌اند اما ورود به مدیریت، بازکردن فهرست نوشته‌ها، ذخیره محصول یا ویرایش سفارش زمان می‌برد، مشکل را نباید با یک برچسب کلی مثل «هاست کند است» جمع‌بندی کرد. کندی پیشخوان وردپرس معمولاً در یکی از مسیرهای مخصوص کاربران واردشده رخ می‌دهد: درخواست‌های بدون کش، admin-ajax و Heartbeat، اجرای WP-Cron، صف Scheduled Actions ووکامرس، پرس‌وجوهای سنگین دیتابیس، گزینه‌های autoload، افزونه یا قالب و در نهایت محدودیت CPU، حافظه، I/O یا پردازش‌های هم‌زمان. روش درست این است که ابتدا کندی را قابل‌اندازه‌گیری کنید، سپس هر لایه را با یک آزمایش کنترل‌شده حذف یا تأیید کنید.

این راهنما برای مدیر سایت، توسعه‌دهنده و خریدار هاست وردپرس نوشته شده است؛ یعنی کسی که می‌خواهد هم مشکل فعلی را پیدا کند و هم هنگام انتخاب سرویس بعدی سؤال‌های دقیق‌تری بپرسد. هدف، ارائه یک نسخه جادویی یا توصیه به خاموش‌کردن کورکورانه قابلیت‌ها نیست. Heartbeat، cron، autoload و صف‌های پس‌زمینه هرکدام وظیفه واقعی دارند. قبل از هر تغییر، باید بدانیم کدام درخواست کند است، چه افزونه‌ای آن را ساخته، در چه زمانی تکرار می‌شود و چه منبعی را مصرف می‌کند.

فهرست مطالب

• چرا ممکن است پیشخوان کند اما سایت سریع باشد؟
• ساخت خط مبنا و اندازه‌گیری درست
• زنجیره عیب‌یابی مرحله‌به‌مرحله
• بررسی WP-Cron و درخواست‌های loopback
• تحلیل Heartbeat و admin-ajax
• صف Scheduled Actions ووکامرس
• دیتابیس، autoload و پرس‌وجوهای کند
• افزونه، قالب و کد سفارشی
• منابع هاست و نشانه‌های کمبود ظرفیت
• چک‌لیست خرید هاست وردپرس
• پرسش‌های متداول

چرا پیشخوان وردپرس کند است اما سایت سریع باز می‌شود؟

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

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

نشانه	احتمال قوی‌تر	آزمایش بعدی
فقط کاربران واردشده کندی دارند	مسیر بدون کش، افزونه عضویت یا session	مقایسه ناشناس و واردشده با همان URL
فقط یک صفحه مدیریت کند است	hook یا query مخصوص همان صفحه	پروفایل‌کردن درخواست و آزمون افزونه‌ها
ذخیره نوشته کند است	متاباکس‌ها، autosave، REST/AJAX یا دیتابیس	Network مرورگر و لاگ PHP
کندی دوره‌ای است	cron، backup، اسکن یا Scheduled Actions	ثبت زمان رخداد و بررسی صف‌ها
هم سایت و هم مدیریت کندند	منابع، PHP، دیتابیس یا شبکه	TTFB، خطاهای منابع و لاگ سرور
پس از نصب افزونه شروع شده	کد یا migration افزونه	بازگشت در staging و تست کنترل‌شده

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

کش چگونه تصویر مسئله را تحریف می‌کند؟

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

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

پیش از اصلاح، یک خط مبنا بسازید

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

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

از پنل Network مرورگر چه بخوانیم؟

Developer Tools مرورگر را باز کنید و در تب Network صفحه کند را دوباره بارگذاری کنید. درخواست اصلی document، درخواست‌های admin-ajax.php، REST API، فایل‌های JS/CSS و سرویس‌های بیرونی را جدا ببینید. اگر document دیر پاسخ می‌دهد، احتمال اجرای PHP یا دیتابیس بیشتر است. اگر document سریع است اما صفحه منتظر یک API یا اسکریپت می‌ماند، مشکل سمت مرورگر، افزونه یا سرویس بیرونی است. ستون Initiator کمک می‌کند بفهمید کدام فایل جاوااسکریپت درخواست را آغاز کرده است.

درخواست‌های طولانی را با status code، مدت Waiting/TTFB و اندازه پاسخ ثبت کنید. تکرار زیاد یک درخواست کوچک نیز می‌تواند مهم باشد؛ چون ده‌ها درخواست هم‌زمان workerهای PHP را اشغال می‌کنند. خطاهای 401 و 403 ممکن است به nonce، session یا فایروال مربوط باشند، و 500 یا 503 نیازمند بررسی لاگ PHP و منابع است. صرفاً از روی نام admin-ajax نتیجه نگیرید؛ پارامتر action در payload معمولاً سرنخ بهتری از افزونه یا وظیفه مسئول می‌دهد.

چه اطلاعاتی را برای پشتیبانی ثبت کنیم؟

• URL صفحه مدیریت و نقش کاربری، بدون ارسال رمز یا cookie.
• ساعت دقیق رخداد و منطقه زمانی سایت.
• نام درخواست کند، action یا route آن و مدت پاسخ.
• گام‌های بازتولید؛ مثلاً «بازکردن سفارش و زدن به‌روزرسانی».
• تغییرات اخیر در افزونه، قالب، PHP، DNS یا هاست.
• بخش مرتبط از error log با حذف اطلاعات حساس.
• نمودار یا گزارش مصرف منابع در همان بازه زمانی.

زنجیره عیب‌یابی کندی wp-admin؛ از کم‌خطر به پرریسک

بهترین ترتیب، از مشاهده شروع می‌شود و به تغییر می‌رسد. ابتدا مرورگر و درخواست‌ها را بسنجید؛ سپس Site Health، cron و صف‌ها را ببینید؛ بعد query و autoload را تحلیل کنید؛ در مرحله بعد افزونه و قالب را در staging جدا کنید؛ و تنها پس از جمع‌شدن شواهد سراغ تغییر پیکربندی PHP، دیتابیس یا هاست بروید. این ترتیب جلوی پاک‌کردن بی‌هدف داده یا خاموش‌کردن قابلیتی را می‌گیرد که فقط پیام‌رسان مشکل بوده است.

مرحله	کار اصلی	اگر نتیجه مثبت بود
۱. بازتولید	صفحه، زمان و نقش را ثابت کنید	سناریوی قابل تکرار برای ادامه دارید
۲. مرورگر	document، AJAX و REST را جدا کنید	درخواست مسئول مشخص می‌شود
۳. سلامت و لاگ	Site Health و خطاهای PHP را بخوانید	loopback، timeout یا خطای کد آشکار می‌شود
۴. صف‌ها	cron و Scheduled Actions را بررسی کنید	hook یا job پرتکرار پیدا می‌شود
۵. دیتابیس	query و autoload را اندازه بگیرید	جدول یا گزینه پرهزینه مشخص می‌شود
۶. افزونه/قالب	در staging تست دودویی انجام دهید	عامل نرم‌افزاری محدود می‌شود
۷. منابع	CPU، RAM، I/O، EP و workerها را تطبیق دهید	بهینه‌سازی یا ارتقا با مدرک انجام می‌شود

تست دودویی افزونه‌ها چیست؟

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

این تست فقط «نام افزونه» را پیدا نمی‌کند؛ ممکن است ناسازگاری بین دو افزونه باشد. پس از یافتن مظنون، آن را به‌تنهایی و در ترکیب با افزونه‌های حیاتی بررسی کنید. نسخه، تنظیمات، حجم داده و hook کند را ثبت کنید. گاهی پاک‌کردن یک صف قدیمی یا اصلاح index مشکل را حل می‌کند و حذف دائمی افزونه لازم نیست. گاهی نیز کد افزونه در هر صفحه مدیریت query یا API call می‌زند و جایگزینی منطقی‌تر است.

WP-Cron چگونه بر کندی پیشخوان اثر می‌گذارد؟

WP-Cron یک daemon دائمی سیستم‌عامل نیست. WordPress رویدادهای زمان‌بندی‌شده را نگه می‌دارد و هنگام بارگذاری صفحه بررسی می‌کند آیا کاری موعدش رسیده است. در معماری عادی، برای اجرای کارها یک درخواست loopback به wp-cron.php ایجاد می‌شود. این سازوکار برای انتشار زمان‌بندی‌شده، بررسی به‌روزرسانی و وظایف افزونه‌ها ضروری است. مشکل زمانی رخ می‌دهد که job سنگین، پرتکرار، خطادار یا انباشته باشد، یا loopback به‌دلیل DNS، SSL، احراز هویت یا فایروال درست کار نکند.

نشانه‌های cron ناسالم شامل انتشار دیرهنگام نوشته، ایمیل یا webhook با تأخیر، صف بزرگ کارهای overdue، تکرار خطای یک hook و کندی دوره‌ای در زمان‌های تقریباً مشخص است. Site Health می‌تواند خطای loopback یا رویداد زمان‌بندی‌شده را نشان دهد. اگر job خاصی مشکوک است، نام hook و افزونه مالک را پیدا کنید. حذف همه رویدادها یا دست‌کاری مستقیم option cron بدون شناخت، ممکن است وظایف فروشگاه، بکاپ یا تمدید اشتراک را از کار بیندازد.

آیا باید WP-Cron را با cron واقعی جایگزین کنیم؟

برای سایت پرترافیک یا فروشگاه، اجرای برنامه‌ریزی‌شده از سمت سیستم می‌تواند رفتار قابل‌پیش‌بینی‌تری ایجاد کند؛ اما فقط وقتی دسترسی و پیکربندی سرویس اجازه می‌دهد. ترتیب امن این است که ابتدا اجرای زمان‌بندی‌شده بیرونی را بسازید و موفقیت آن را تأیید کنید، سپس اجرای WP-Cron در هر بار page load را غیرفعال کنید. اگر فقط خط DISABLE_WP_CRON را اضافه کنید و جایگزین واقعی نداشته باشید، انتشار زمان‌بندی‌شده، ایمیل‌ها و وظایف افزونه‌ها عقب می‌افتند.

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

loopback ناموفق را چطور جدا کنیم؟

اگر Site Health خطای loopback می‌دهد، ابتدا URL سایت، HTTPS، redirectها و DNS را بررسی کنید. Basic Auth روی staging، قانون امنیتی، CDN یا فایروال ممکن است درخواست خود سایت به خودش را مسدود کند. افزونه و قالب نیز می‌توانند پاسخ را تغییر دهند. مستندات WordPress پیشنهاد می‌کند تعارض افزونه و قالب بررسی شود و اگر ادامه داشت، میزبان از نظر قوانین امنیتی، DNS، SSL یا HTTP authentication مسیر داخلی را بررسی کند. نتیجه درخواست و متن خطا را ثبت کنید؛ «loopback failed» به‌تنهایی برای تشخیص کافی نیست.

مدرکی که قبل از تغییر cron لازم است

نام hook، زمان اجرای بعدی، تعداد رخدادهای عقب‌افتاده، مدت تقریبی اجرای job و افزونه مالک را کنار هم بگذارید. اگر افزایش صف دقیقاً با کندی هم‌زمان است، رابطه محتمل‌تر می‌شود. سپس در staging یا پنجره نگهداری یک اجرای کنترل‌شده انجام دهید و مصرف منابع و لاگ را ببینید. هدف این است که cron را متهم نکنیم؛ hook پرهزینه یا محیطی را پیدا کنیم که اجازه پایان سالم به آن نمی‌دهد.

معیار خروج از مرحله cron

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

Heartbeat و admin-ajax؛ مفید اما قابل سوءاستفاده

Heartbeat API برای به‌روزرسانی نزدیک به لحظه در وردپرس ساخته شده است. مرورگر در بازه‌هایی درخواست می‌فرستد، داده را از فیلترها و callbackهای سرور می‌گیرد و پاسخ را به صفحه برمی‌گرداند. قفل ویرایش نوشته، autosave و برخی اعلان‌ها می‌توانند به آن وابسته باشند. Heartbeat ذاتاً مشکل نیست؛ مشکل زمانی است که افزونه‌ای به هر ضربان پردازش سنگین اضافه کند، چند تب مدیریت هم‌زمان باز باشد یا پاسخ آن‌قدر طول بکشد که درخواست بعدی پیش از پایان قبلی برسد.

در Network درخواست admin-ajax.php را باز کنید و payload را ببینید. اگر action برابر heartbeat است، داده‌های ارسالی و زمان پاسخ را مقایسه کنید. اگر action نام دیگری دارد، احتمالاً یک افزونه درخواست AJAX مستقل ساخته است. تعداد تب‌های باز را کم کنید و آزمون را دوباره انجام دهید. اگر با بستن تب‌ها فشار کاهش یافت، نرخ درخواست و پردازش هر ضربان مهم است. اگر یک درخواست خاص حتی با یک تب بسیار کند است، کد سرور یا queryهای همان action را پروفایل کنید.

آیا غیرفعال‌کردن کامل Heartbeat درست است؟

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

در فروشگاه‌ها به درخواست‌های admin-ajax غیر Heartbeat نیز توجه کنید. جست‌وجوی محصول، اعلان پنل، همگام‌سازی موجودی، گزارش و افزونه امنیتی ممکن است از همان endpoint استفاده کنند. نام endpoint فقط کانال را می‌گوید، نه عامل را. action، stack یا hook و زمان queryها تعیین می‌کند چه چیزی باید اصلاح شود. اگر چند درخواست کند هم‌زمان‌اند، محدودیت PHP worker یا Entry Process می‌تواند اثر را تشدید کند.

REST API و سرویس‌های بیرونی

ویرایشگر بلوک و بسیاری از افزونه‌های جدید از REST API استفاده می‌کنند. اگر route خاصی کند یا با خطا پاسخ می‌دهد، nonce، مجوز، query و سرویس بیرونی مرتبط را بررسی کنید. افزونه‌ای که در پنل به API مجوز، آمار یا CRM وصل می‌شود ممکن است تا timeout منتظر بماند. این مشکل با ارتقای CPU همیشه حل نمی‌شود؛ کاهش timeout، cache مناسب، اجرای پس‌زمینه یا اصلاح سرویس بیرونی راه‌حل معماری است. دامنه مقصد و زمان انتظار را از لاگ درخواست HTTP استخراج کنید و کلیدها را در گزارش عمومی قرار ندهید.

Scheduled Actions ووکامرس؛ صفی که باید خوانده شود

WooCommerce و افزونه‌های آن برای ایمیل، webhook، تمدید، همگام‌سازی و کارهای پس‌زمینه از Action Scheduler استفاده می‌کنند. در بخش WooCommerce > Status > Scheduled Actions می‌توانید وضعیت pending، complete، failed و canceled را ببینید. وجود تعدادی عمل pending طبیعی است؛ نشانه مهم، رشد پیوسته صف، تعداد زیاد failed برای یک hook، اجرای طولانی یا عملی است که بارها با همان خطا تکرار می‌شود.

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

روش اولویت‌بندی صف

وضعیت	معنا	اقدام محتاطانه
Pending با زمان آینده	اغلب طبیعی	فقط نرخ رشد و زمان‌بندی را ببینید
Pending و overdue زیاد	اجرا عقب افتاده	WP-Cron، worker و hook مالک را بررسی کنید
Failed تکراری	یک علت پایدار وجود دارد	آخرین خطا و وابستگی بیرونی را تحلیل کنید
Complete بسیار زیاد	ممکن است housekeeping لازم باشد	طبق مستندات افزونه و با backup اقدام کنید
In-progress طولانی	job گیرکرده یا timeout	لاگ PHP، lock و منابع را بررسی کنید

مستندات WooCommerce توضیح می‌دهد که Action Scheduler در حالت معمول توسط WP-Cron تحریک می‌شود؛ بنابراین خرابی cron می‌تواند صف را عقب بیندازد. از سوی دیگر، اجرای دسته‌های سنگین خود صف نیز مصرف CPU و دیتابیس را بالا می‌برد. این رابطه دوطرفه را در نظر بگیرید. زمان شروع کندی، تعداد actionهای آماده و مصرف منابع را روی یک خط زمانی بگذارید تا هم‌بستگی واقعی پیدا شود.

دیتابیس، autoload و queryهای کند

هر درخواست پویا به کیفیت دسترسی به دیتابیس وابسته است. در wp-admin، شمارش‌ها، تنظیمات، متادیتا و گزارش‌ها ممکن است queryهای متفاوت از صفحه عمومی ایجاد کنند. جدول بزرگ به‌تنهایی الزاماً کند نیست؛ index مناسب، شکل query و تعداد ردیف اسکن‌شده اهمیت بیشتری دارد. قبل از optimize یا پاک‌سازی، query مسئول را پیدا کنید. ابزار پروفایل در staging می‌تواند زمان، caller و component را نشان دهد. در محیط زنده، slow query log یا گزارش میزبان با رعایت دسترسی‌ها مفید است.

autoload چیست و چه زمانی مسئله می‌شود؟

گزینه‌های autoload هنگام هر بار بارگذاری WordPress به‌صورت خودکار خوانده می‌شوند. این رفتار برای تنظیمات کوچک و پرتکرار مناسب است، اما افزونه‌ها ممکن است داده بزرگ یا گزینه منسوخ را autoload کنند. حجم زیاد باعث انتقال و نگهداری داده غیرضروری در هر درخواست می‌شود. راهنمای رسمی WordPress توصیه می‌کند مجموع autoload معمولاً زیر حدود ۸۰۰ کیلوبایت نگه داشته شود، اما این عدد تشخیص نهایی نیست؛ تعداد option، اندازه هرکدام، object cache و الگوی درخواست نیز اثر دارند.

اول مجموع حجم و بزرگ‌ترین گزینه‌ها را گزارش بگیرید. سپس مالک هر option را از نام، کد افزونه و مستندات مشخص کنید. option فعال را مستقیم حذف نکنید؛ ممکن است تنظیمات، license، route، cache یا داده ساختاری باشد. اگر افزونه حذف شده و داده orphan باقی مانده، باز هم backup و آزمون staging لازم است. تغییر autoload از yes به no نیز باید با شناخت الگوی خواندن انجام شود؛ وگرنه تعداد queryهای جداگانه می‌تواند بیشتر شود.

نمونه پرس‌وجوی فقط‌خواندنی برای اندازه‌گیری

نام prefix ممکن است wp_ نباشد. پرس‌وجوی زیر صرفاً نمونه مفهومی برای مدیر فنی است و باید روی staging یا توسط فرد آشنا اجرا شود. در نسخه‌های جدید، مقادیر autoload می‌توانند بیش از yes باشند؛ بنابراین از دستور حذف یا UPDATE عمومی استفاده نکنید و ساختار واقعی سایت را بررسی کنید.

SELECT autoload, COUNT(*) AS option_count, SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
GROUP BY autoload
ORDER BY total_bytes DESC;

خروجی را با وضعیت سالم مقایسه کنید و بزرگ‌ترین optionها را جداگانه بشناسید. اگر object cache پایدار فعال است، دسترسی تکراری می‌تواند سریع‌تر شود، اما cache جای پاکیزگی داده و query مناسب را نمی‌گیرد. برای شناخت مفهوم و کاربرد کش پایدار، مقاله Redis و Object Cache در وردپرس را ببینید؛ فعال‌سازی آن را فقط وقتی انجام دهید که سرویس واقعاً پشتیبانی می‌کند و تنظیمات افزونه با محیط هماهنگ است.

postmeta، سفارش‌ها و جست‌وجوی مدیریتی

در سایت قدیمی یا فروشگاه، wp_postmeta می‌تواند بسیار بزرگ شود. queryهایی که روی meta_key و meta_value با شرط‌های نامناسب اجرا می‌شوند، جست‌وجو یا فهرست مدیریت را کند می‌کنند. اما افزودن index دلخواه بدون بررسی query و طول ستون ریسک دارد. ابتدا query واقعی، execution plan و افزونه سازنده را مشخص کنید. در WooCommerce جدید، معماری HPOS می‌تواند داده سفارش را از جدول‌های عمومی پست جدا کند، ولی سازگاری افزونه‌ها و برنامه مهاجرت باید بررسی شود. راهنمای داخلی HPOS ووکامرس نقطه شروع مناسبی است.

پاک‌سازی revision، transient و session ممکن است حجم را کم کند، اما مشکل منطقی query را الزاماً حل نمی‌کند. همچنین transient منقضی‌شده همیشه به معنی خرابی نیست؛ WordPress و افزونه‌ها چرخه پاک‌سازی دارند. قبل از حذف انبوه، backup بگیرید، تعداد و حجم را ثبت کنید و پس از پاک‌سازی زمان همان سناریوی ثابت را بسنجید. اگر بهبود ناچیز است، به جای تکرار پاک‌سازی به query، index، افزونه یا منابع برگردید.

معیار خروج از مرحله دیتابیس

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

قانون تغییر داده

هر تغییری که option، meta، action یا جدول را حذف یا به‌روزرسانی می‌کند باید نسخه پشتیبان قابل‌بازیابی، محدوده دقیق، شمارش ردیف‌های اثرپذیر و آزمون بازگشت داشته باشد. «افزونه بهینه‌ساز انجام می‌دهد» جای این کنترل‌ها را نمی‌گیرد.

افزونه، قالب و کد سفارشی؛ مقصر را با شواهد پیدا کنید

تعداد افزونه به‌تنهایی معیار خوبی نیست. یک افزونه کوچک می‌تواند query یا API call سنگین داشته باشد و ده افزونه سبک بدون مشکل کار کنند. معیارهای بهتر عبارت‌اند از زمان اجرای hook، تعداد query، حافظه، درخواست بیرونی و فعالیت در صفحه‌ای که به آن نیاز ندارد. افزونه‌ای که در تمام صفحات مدیریت فایل بزرگ یا پردازش گزارش بارگذاری می‌کند، باید بارگذاری شرطی داشته باشد. افزونه‌های abandoned یا ناسازگار با نسخه PHP نیز احتمال warning، retry و خطا را بالا می‌برند.

کد functions.php، mu-plugin و snippet manager را فراموش نکنید. کد سفارشی ممکن است در admin_init، init، save_post یا heartbeat اجرا شود. اگر تست افزونه‌ها مشکل را رفع نکرد، قالب پیش‌فرض و mu-plugins را در staging بررسی کنید. لاگ deprecation و warning را بخوانید، اما نمایش خطا را روی سایت عمومی روشن نکنید. WP_DEBUG_LOG در محیط کنترل‌شده و با حفاظت فایل مفید است؛ داده حساس و مسیرها نباید در دسترس عمومی قرار گیرند.

نسخه PHP و OPcache

نسخه PHP باید هم پشتیبانی امنیتی مناسب داشته باشد و هم با هسته، قالب و افزونه‌های سایت سازگار باشد. ارتقای کورکورانه روی سایت زنده ممکن است خطای fatal ایجاد کند؛ ماندن روی نسخه قدیمی نیز عملکرد و امنیت را محدود می‌کند. در staging نسخه هدف را با سناریوهای ورود، ویرایش، خرید و cron آزمایش کنید. مقاله انتخاب نسخه PHP برای وردپرس و ووکامرس زمینه تصمیم را توضیح می‌دهد، اما نسخه نهایی را با نیاز واقعی سایت تطبیق دهید.

OPcache کد کامپایل‌شده PHP را نگه می‌دارد و می‌تواند سربار کامپایل را کاهش دهد، اما تنظیم آن در کنترل میزبان است و درمان query یا API کند نیست. اگر cache مرتب reset شود یا حافظه کافی نداشته باشد، اثر آن کم می‌شود. از پشتیبانی بخواهید وضعیت کلی را بررسی کند؛ درخواست افزایش یک عدد بدون گزارش hit rate یا خطا رویکرد دقیقی نیست.

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

اگر کندی با مصرف CPU، حافظه، I/O، IOPS، Entry Processes یا تعداد PHP workerها هم‌زمان است، منابع در زنجیره علت قرار می‌گیرند. اما حتی در این حالت باید عامل مصرف را بشناسید. افزونه معیوب می‌تواند هر پلنی را پر کند؛ از طرف دیگر، سایت سالم با ترافیک و وظایف واقعی ممکن است از ظرفیت پلن عبور کرده باشد. نمودار منابع را در همان دقیقه رخداد با درخواست و job تطبیق دهید. میانگین روزانه، جهش‌های کوتاه و صف worker را پنهان می‌کند.

CPU بالا با query، پردازش تصویر، اسکن، backup یا PHP loop مرتبط است. حافظه نزدیک حد ممکن است process را متوقف کند. I/O یا IOPS پایین باعث کندی خواندن فایل، session و دیتابیس می‌شود. EP یا worker اشباع یعنی درخواست‌های جدید منتظر می‌مانند، حتی اگر CPU میانگین پایین باشد. خطاهای 508، 503 و timeout سرنخ‌اند، اما تفسیر دقیق به محیط بستگی دارد. گزارش محدودیت منابع، error log و access log را کنار هم بگذارید.

بهینه‌سازی یا ارتقای پلن؟

وضعیت	تصمیم منطقی‌تر	دلیل
یک hook یا افزونه مصرف غیرعادی دارد	اصلاح یا جایگزینی کد	ارتقا علت را پنهان می‌کند
مصرف سالم با رشد کاربر به سقف می‌رسد	ارتقای منابع	بار واقعی از ظرفیت عبور کرده است
فقط زمان backup یا اسکن کند است	تغییر زمان‌بندی و شدت job	تداخل زمانی مسئله اصلی است
query شناخته‌شده کند است	اصلاح query/index یا معماری داده	CPU بیشتر الزاماً اسکن بد را حل نمی‌کند
workerها دائماً اشباع‌اند	کاهش درخواست پس‌زمینه و بررسی پلن	صف درخواست باید کوتاه شود
بدون نمودار یا لاگ	ابتدا اندازه‌گیری	خرید بدون مدرک قابل ارزیابی نیست

صفحه فعلی خرید هاست وردپرس وطن هاست مواردی مانند cPanel، LiteSpeed و گزینه‌های منابع را معرفی می‌کند. جزئیات جاری هر پلن، حد منابع، روش backup و امکاناتی مانند object cache را هنگام خرید از همان صفحه یا پشتیبانی تأیید کنید؛ زیرا مقاله نباید جای مشخصات لحظه‌ای سرویس را بگیرد. اگر نزدیکی کاربران و مسیر شبکه ایران برای شما مهم است، صفحه هاست وردپرس ایران را نیز جداگانه بررسی کنید.

چک‌لیست خرید هاست برای پیشخوان سریع وردپرس

فضای دیسک و پهنای باند به‌تنهایی سرعت wp-admin را پیش‌بینی نمی‌کنند. خریدار باید درباره سهم CPU و RAM، I/O و IOPS، هم‌زمانی پردازش، نسخه‌های PHP، دیتابیس، backup، staging و امکان دیدن گزارش منابع سؤال کند. پاسخ خوب باید قابل‌اندازه‌گیری و متناسب با پلن باشد. عبارت‌هایی مانند «نامحدود» یا «فوق‌سریع» بدون حد و روش پایش برای تصمیم فنی کافی نیستند.

• حد و سیاست CPU، RAM، I/O، IOPS، EP یا PHP worker را بپرسید.
• ببینید گزارش مصرف و Faultها در اختیار کاربر قرار می‌گیرد یا پشتیبانی می‌تواند ارائه کند.
• نسخه‌های PHP و مسیر تغییر کنترل‌شده آن را بررسی کنید.
• روش، تناوب، محل و مدت نگهداری backup و امکان restore را روشن کنید.
• درباره cron واقعی، حداقل فاصله اجرا و محدودیت jobهای طولانی سؤال کنید.
• اگر Redis یا object cache لازم است، وجود واقعی سرویس و روش اتصال را تأیید کنید.
• برای فروشگاه، سازگاری محیط با WooCommerce و تعداد درخواست‌های هم‌زمان را بسنجید.
• امکان staging یا روش ساخت محیط آزمایش را بررسی کنید.
• پاسخ‌گویی پشتیبانی به گزارش زمان‌دار، log و نمودار منابع را ارزیابی کنید.
• مسیر ارتقا را بدون مهاجرت پرریسک و با حفظ backup بپرسید.

سه سناریوی واقعی برای تصمیم خرید

سناریو اول: وبلاگ با چند مدیر

وبلاگ عمومی از کش سریع است اما سه نویسنده هم‌زمان ویرایش می‌کنند. کندی هنگام autosave رخ می‌دهد. قبل از ارتقا، Heartbeat، تعداد تب‌ها، متاباکس‌ها و افزونه ویرایش را بررسی کنید. اگر درخواست heartbeat سبک است ولی workerها با چند کاربر پر می‌شوند، ظرفیت هم‌زمانی پلن اهمیت پیدا می‌کند. در این سناریو خاموش‌کردن Heartbeat می‌تواند قفل ویرایش و autosave را خراب کند؛ انتخاب هاست باید بر اجرای پویای چند کاربر و بازیابی مناسب تمرکز کند.

سناریو دوم: فروشگاه با صف عقب‌افتاده

فروشگاه در ساعات خاص کند می‌شود و Scheduled Actions دارای actionهای overdue است. ابتدا hook مسئول، cron، webhook و خطای سرویس بیرونی را پیدا کنید. اگر jobها سالم‌اند اما در زمان اوج با درخواست مشتری رقابت می‌کنند، زمان‌بندی، batch و منابع اهمیت دارند. ارتقای پلن بدون اصلاح job تکراری ممکن است فقط زمان اشباع را عقب بیندازد. هاست مناسب باید امکان مشاهده منابع و اجرای قابل‌اعتماد وظایف پس‌زمینه را فراهم کند.

سناریو سوم: سایت قدیمی با دیتابیس متورم

پیشخوان فهرست نوشته‌ها کند است، autoload بزرگ و افزونه‌های حذف‌شده متعددند. ابتدا backup و گزارش فقط‌خواندنی تهیه کنید، گزینه‌های بزرگ را به مالک آن‌ها نسبت دهید و query همان صفحه را ببینید. پاک‌سازی مرحله‌ای در staging و سنجش قبل/بعد لازم است. اگر پس از پاک‌سازی و اصلاح query هنوز I/O یا حافظه به سقف می‌رسد، ارتقا مستند است. انتخاب پلن جدید باید بر عملکرد دیتابیس و visibility منابع استوار باشد، نه صرفاً حجم NVMe.

برنامه عملی ۶۰ دقیقه‌ای برای شروع عیب‌یابی

1. دقیقه ۰ تا ۱۰: سه صفحه کند و زمان پاسخ هرکدام را در سه نوبت ثبت کنید.
2. دقیقه ۱۰ تا ۲۰: Network مرورگر را برای document، admin-ajax و REST بررسی کنید.
3. دقیقه ۲۰ تا ۳۰: Site Health، error log و زمان دقیق خطاها را یادداشت کنید.
4. دقیقه ۳۰ تا ۴۰: رویدادهای WP-Cron و Scheduled Actions عقب‌افتاده یا failed را فهرست کنید.
5. دقیقه ۴۰ تا ۵۰: گزارش منابع همان بازه و وضعیت autoload را فقط‌خواندنی بررسی کنید.
6. دقیقه ۵۰ تا ۶۰: یک فرضیه، یک آزمایش کم‌خطر و معیار موفقیت برای staging تعریف کنید.

در پایان این یک ساعت شاید مشکل حل نشده باشد، اما باید یک سؤال دقیق داشته باشید: «درخواست heartbeat با action مشخص ۳٫۸ ثانیه طول می‌کشد»، «hook فلان ده هزار action عقب‌افتاده دارد» یا «در زمان ذخیره محصول EP به سقف می‌رسد». چنین گزارشی به توسعه‌دهنده و پشتیبانی اجازه می‌دهد اقدام قابل‌آزمون انجام دهند. گزارش «پنل کند است» معمولاً به توصیه‌های عمومی و رفت‌وبرگشت طولانی منجر می‌شود.

اشتباه‌های رایج که عیب‌یابی را سخت‌تر می‌کنند

اشتباه	ریسک	جایگزین
حذف همه transientها و optionها	از دست‌رفتن تنظیم یا بازتولید بار	گزارش، مالکیت و پاک‌سازی محدود
خاموش‌کردن کامل Heartbeat	اختلال autosave و قفل ویرایش	تحلیل action و تنظیم هدفمند
افزودن DISABLE_WP_CRON بدون جایگزین	عقب‌افتادن وظایف	cron بیرونی را اول تأیید کنید
تغییر هم‌زمان PHP، افزونه و هاست	نامعلوم‌شدن علت	هر بار یک متغیر
خرید پلن قوی‌تر بدون نمودار	تکرار مشکل پرهزینه	مدرک مصرف و درخواست مسئول
تست فقط روی سایت زنده	ریسک فروش و داده	staging و برنامه بازگشت

منابع فنی و مرز ادعاها

توضیح WP-Cron، loopback و اتصال آن به scheduler سیستم از مستندات رسمی توسعه‌دهندگان WordPress گرفته شده است. رفتار Heartbeat و ارسال دوره‌ای داده از مسیر admin-ajax نیز در Plugin Handbook توضیح داده شده است. بخش autoload بر راهنمای رسمی بهینه‌سازی WordPress و آزمون Site Health تکیه دارد. اطلاعات Scheduled Actions از مستندات WooCommerce است. اعداد و رفتار واقعی سایت شما باید با نسخه نصب‌شده، افزونه‌ها و گزارش میزبان تطبیق داده شود؛ این مقاله هیچ حد منبع یا قابلیت تأییدنشده‌ای را به یک پلن خاص نسبت نمی‌دهد.

جمع‌بندی: پیشخوان سریع نتیجه مشاهده‌پذیری و انتخاب درست است

کندی پیشخوان وردپرس یک علت واحد ندارد. مسیر درست از تفکیک سایت عمومی و مدیریت شروع می‌شود، سپس درخواست اصلی، AJAX و REST اندازه‌گیری می‌شوند. WP-Cron و Scheduled Actions از نظر صف و خطا بررسی می‌شوند؛ Heartbeat بدون دلیل خاموش نمی‌شود؛ autoload و queryها قبل از پاک‌سازی شناخته می‌شوند؛ افزونه‌ها در staging با آزمون کنترل‌شده جدا می‌شوند و منابع هاست با زمان رخداد تطبیق داده می‌شوند. این زنجیره هم ریسک را کم می‌کند و هم به شما می‌گوید بهینه‌سازی لازم است یا ارتقا.

اگر شواهد نشان می‌دهد سایت سالم با بار واقعی از ظرفیت فعلی عبور کرده یا مشاهده‌پذیری و پشتیبانی محیط کافی نیست، مشخصات جاری هاست وردپرس وطن هاست را ببینید. پیش از سفارش، سناریوی خود—تعداد مدیر هم‌زمان، فروشگاه، cron، صف، حجم دیتابیس و نیاز backup—را مطرح کنید و امکانات هر پلن را تأیید بگیرید. انتخاب درست زمانی فروش‌محور و منطقی است که بر نیاز فنی قابل‌اندازه‌گیری تکیه کند، نه وعده مبهم سرعت.

سؤالات متداول درباره کندی پیشخوان وردپرس