چرا admin-ajax.php باعث مصرف بالای CPU می‌شود؟

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

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

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

فایل admin-ajax.php در وردپرس چیست؟

وردپرس برای بسیاری از درخواست‌های Ajax از مسیر زیر استفاده می‌کند:

/wp-admin/admin-ajax.php

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

در مستندات رسمی Ajax وردپرس، admin-ajax.php مسیر استاندارد پردازش این درخواست‌ها معرفی شده است. درخواست معمولاً پارامتری با نام action دارد و وردپرس براساس همین مقدار مشخص می‌کند کدام تابع باید اجرا شود.

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

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

وقتی درخواست به admin-ajax.php می‌رسد، وردپرس باید محیط لازم برای اجرای آن درخواست را آماده کند. افزونه‌های فعال، هوک‌ها و بخشی از فرایند راه‌اندازی وردپرس وارد کار می‌شوند. اگر خود اکشن هم چند کوئری سنگین به دیتابیس بزند یا پردازش زیادی انجام دهد، هزینه هر درخواست بیشتر می‌شود.

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

چرا admin-ajax.php باعث مصرف بالای CPU می‌شود؟

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

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

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

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

2. هر درخواست Ajax پردازش سنگینی دارد

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

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

3. Heartbeat وردپرس بیش از حد فعال است

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

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

اگر در بخش Payload مرورگر مقدار زیر را ببینید، یعنی درخواست مربوط به Heartbeat است:

action=heartbeat

4. دیتابیس وردپرس کند شده است

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

مستندات بهینه‌سازی وردپرس توضیح می‌دهد که وردپرس از نسخه 6.6 در بخش «سلامت سایت» مقدار داده‌های Autoload را بررسی می‌کند و اگر حجم آن از حد پیش‌فرض 800000 بایت بیشتر شود، هشدار عملکرد نمایش می‌دهد. بنابراین برای بررسی اولیه لازم نیست مستقیم وارد دیتابیس شوید؛ اول بخش سلامت سایت را ببینید.

5. ربات‌ها یا درخواست‌های مخرب مسیر admin-ajax.php را هدف گرفته‌اند

admin-ajax.php فقط مخصوص مدیر سایت نیست. بعضی اکشن‌ها برای کاربران مهمان هم در دسترس هستند و همین موضوع باعث می‌شود ربات‌ها بتوانند به این مسیر درخواست بفرستند. اگر یک افزونه آسیب‌پذیر باشد یا اکشنی طراحی ضعیفی داشته باشد، درخواست‌های زیاد می‌توانند منابع سرور را مصرف کنند.

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

6. منابع هاست برای تعداد درخواست‌های پویا کافی نیست

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

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

خلاصه علت‌ها و راه‌حل‌های مناسب

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

از کجا بفهمیم مشکل واقعاً از admin-ajax.php است؟

قبل از هر تغییری باید مطمئن شویم این مسیر واقعاً عامل مصرف منابع است. دیدن نام admin-ajax.php در یک گزارش به‌تنهایی کافی نیست؛ باید بفهمیم چند بار اجرا می‌شود، چقدر طول می‌کشد و کدام اکشن پشت آن قرار دارد.

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

ساده‌ترین راه برای بیشتر کاربران، استفاده از ابزارهای خود مرورگر Chrome است:

1. صفحه‌ای را که در آن مشکل احساس می‌کنید باز کنید.
2. کلید F12 را بزنید و وارد بخش Network شوید.
3. فیلتر Fetch/XHR را فعال کنید.
4. صفحه را تازه‌سازی کنید یا همان کاری را انجام دهید که باعث کندی می‌شود.
5. در فهرست درخواست‌ها دنبال admin-ajax.php بگردید.
6. روی درخواست کلیک کنید و در بخش Payload یا اطلاعات فرم، مقدار action را پیدا کنید.

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

یک تست مهم: حالت واردشده و حالت ناشناس را مقایسه کنید

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

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

روش دوم: استفاده از Query Monitor

اگر می‌خواهید بفهمید یک درخواست چرا طول کشیده است، افزونه Query Monitor ابزار مفیدی برای عیب‌یابی است. این افزونه می‌تواند کوئری‌های دیتابیس، خطاهای PHP، هوک‌ها، درخواست‌های Ajax و بخش مسئول در قالب یا افزونه را نشان دهد.

Query Monitor را بهتر است به‌عنوان ابزار عیب‌یابی موقت استفاده کنید، نه افزونه‌ای که بدون نیاز روی همه سایت‌ها دائماً فعال بماند. بعد از پیدا کردن مشکل، می‌توانید آن را غیرفعال کنید.

روش سوم: بررسی لاگ‌های هاست

اگر مصرف CPU بالا است اما در مرورگر درخواست زیادی نمی‌بینید، لاگ دسترسی سرور را بررسی کنید. در cPanel، DirectAdmin یا پنل‌های مشابه معمولاً بخشی برای گزارش دسترسی‌ها وجود دارد.

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

grep "admin-ajax.php" access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

توجه کنید که لاگ معمولی وب‌سرور اغلب محتوای درخواست POST و مقدار action را ثبت نمی‌کند. بنابراین این روش بیشتر برای پیدا کردن حجم درخواست، IPهای پرتکرار و الگوی حمله مفید است؛ نه تشخیص دقیق نام اکشن.

چک‌لیست عیب‌یابی مرحله‌به‌مرحله

برای اینکه بدون آزمون و خطای زیاد پیش بروید، این مراحل را به ترتیب انجام دهید و بعد از هر مرحله نتیجه را یادداشت کنید.

روش‌های کاهش مصرف CPU توسط admin-ajax.php

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

1. افزونه یا قابلیتی را که درخواست می‌سازد بررسی کنید

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

اگر افزونه ضروری است، این ترتیب منطقی‌تر است:

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

هدف این نیست که تعداد افزونه‌ها را فقط کم کنیم؛ هدف این است که افزونه‌ای را پیدا کنیم که درخواست‌های غیرضروری یا سنگین ایجاد می‌کند.

2. Heartbeat را کنترل کنید، نه اینکه کامل خاموش کنید

اگر مشخص شد مقدار action=heartbeat بیشترین درخواست را ایجاد می‌کند، می‌توانید فاصله ارسال Heartbeat را بیشتر کنید. خاموش کردن کامل آن معمولاً انتخاب خوبی نیست، چون قابلیت‌هایی مانند ذخیره خودکار نوشته و قفل ویرایش به آن وابسته‌اند.

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

add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

این کد را بهتر است در قالب فرزند یا افزونه مخصوص کدهای سفارشی قرار دهید، نه فایل اصلی قالب. قبل از استفاده نیز روی سایت آزمایشی تست کنید؛ مخصوصاً اگر سایت چندنویسنده یا آموزشی دارید.

3. در فروشگاه ووکامرسی، admin-ajax.php را با wc-ajax اشتباه نگیرید

در بعضی آموزش‌های قدیمی، قابلیت Cart Fragments ووکامرس به‌عنوان یکی از دلایل اصلی فشار admin-ajax.php معرفی شده است. اما این موضوع در نسخه‌های جدید ووکامرس نیاز به توضیح دقیق‌تری دارد.

ووکامرس از مسیر اختصاصی wc-ajax برای بخشی از درخواست‌های فروشگاهی استفاده می‌کند. همچنین طبق راهنمای فنی ووکامرس، از نسخه 7.8 به بعد اسکریپت Cart Fragments دیگر به‌صورت پیش‌فرض در همه صفحات فروشگاه بارگذاری نمی‌شود و فقط در شرایط لازم مانند حضور ابزارک مینی‌سبد یا وابستگی‌های مربوط فعال می‌شود.

بنابراین اگر فروشگاه ووکامرسی دارید و در گزارش فقط admin-ajax.php را می‌بینید، مستقیم سراغ غیرفعال کردن Cart Fragments نروید. اول همان درخواست را در مرورگر باز کنید و مقدار action را ببینید.

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

4. سلامت دیتابیس و Autoload را بررسی کنید

درخواست Ajax برای پاسخ دادن ممکن است چندین بار به دیتابیس مراجعه کند. اگر دیتابیس کند باشد، زمان هر درخواست هم بالا می‌رود. یکی از بخش‌هایی که ارزش بررسی دارد داده‌های Autoload در جدول wp_options است.

برای کاربران معمولی، امن‌ترین نقطه شروع این مسیر است:

1. وارد پیشخوان وردپرس شوید.
2. به مسیر «ابزارها ← سلامت سایت» بروید.
3. بخش وضعیت را بررسی کنید.
4. اگر هشدار مربوط به گزینه‌های Autoload نمایش داده شد، قبل از حذف هر داده‌ای مشخص کنید متعلق به کدام افزونه یا قالب است.

در نسخه‌های جدید وردپرس مقدار Autoload فقط yes و no نیست و مقادیر دیگری هم استفاده می‌شوند. به همین دلیل دستورهای SQL قدیمی که فقط autoload='yes' را بررسی می‌کنند ممکن است همه داده‌های واقعی را نشان ندهند.

همچنین هر داده Autoload شده‌ای «اضافی» نیست. بسیاری از تنظیمات لازم است در هر درخواست سریع در دسترس باشند. حذف دستی اطلاعات ناشناخته از wp_options می‌تواند تنظیمات افزونه یا سایت را خراب کند. قبل از تغییر دیتابیس حتماً نسخه پشتیبان داشته باشید.

5. از کش دائمی اشیا در سایت‌های سنگین استفاده کنید

اگر سایت پرترافیک یا فروشگاه بزرگی دارید، کش دائمی اشیا با ابزارهایی مانند Redis یا Memcached می‌تواند بعضی درخواست‌های تکراری دیتابیس را از حافظه پاسخ دهد و فشار روی دیتابیس را کمتر کند.

این قابلیت درمان مستقیم همه مشکلات admin-ajax.php نیست. اگر یک افزونه در هر ثانیه درخواست غیرضروری می‌سازد، Redis فقط بخشی از هزینه را کم می‌کند و علت اصلی همچنان باقی است. اول تعداد درخواست‌ها و اکشن سنگین را اصلاح کنید؛ بعد سراغ بهینه‌سازی زیرساخت بروید.

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

6. ربات‌ها و درخواست‌های غیرعادی را محدود کنید

اگر لاگ‌ها نشان می‌دهند تعداد زیادی درخواست از IPهای محدود یا الگوهای غیرعادی به admin-ajax.php می‌رسد، باید بخش امنیت و محدودسازی درخواست‌ها را بررسی کنید.

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

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

/wp-admin/admin-ajax.php

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

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

7. اگر سایت توسعه اختصاصی دارد، معماری درخواست را بازبینی کنید

اگر درخواست مربوط به کد اختصاصی شماست، چند سؤال ساده بپرسید:

• آیا واقعاً لازم است این درخواست در هر بار نمایش صفحه اجرا شود؟
• می‌توان آن را فقط بعد از تعامل کاربر اجرا کرد؟
• آیا نتیجه برای چند کاربر یکسان است و می‌توان آن را داخل وردپرس کش کرد؟
• آیا چند درخواست کوچک را می‌توان در یک درخواست منطقی جمع کرد؟
• آیا کوئری دیتابیس داخل اکشن نیاز به بهینه‌سازی دارد؟

برای توسعه‌های جدید، REST API وردپرس مسیر ساختاریافته‌تری برای بسیاری از ارتباطات داده‌ای فراهم می‌کند. با این حال مهاجرت از admin-ajax.php به REST به‌صورت خودکار CPU را کم نمی‌کند؛ چون REST هم وردپرس را اجرا می‌کند. مزیت اصلی آن ساختار بهتر و امکان طراحی تمیزتر درخواست‌هاست. بعد از هر تغییر باید نتیجه واقعی را اندازه بگیرید.

آیا باید admin-ajax.php را کامل غیرفعال کنیم؟

خیر. مسدود کردن کامل admin-ajax.php راه‌حل درستی برای کاهش مصرف CPU نیست. وردپرس و تعداد زیادی افزونه برای قابلیت‌های ضروری به آن وابسته‌اند.

مسدود کردن کامل ممکن است باعث خرابی موارد زیر شود:

• ذخیره خودکار و بعضی امکانات ویرایش نوشته؛
• بخش‌هایی از پیشخوان وردپرس؛
• فرم‌ها و جستجوی زنده بعضی افزونه‌ها؛
• قابلیت‌های پویا برای کاربران مهمان؛
• بخش‌هایی از قالب یا افزونه‌های سفارشی.

حتی مستندات امنیتی وردپرس هشدار می‌دهند که محافظت نادرست از کل پوشه wp-admin می‌تواند admin-ajax.php و قابلیت‌های وابسته به آن را مختل کند.

راه درست این است که درخواست اضافی یا سنگین را محدود کنید، نه اینکه مسیر اصلی Ajax وردپرس را ببندید.

بعد از تغییرات چطور مطمئن شویم مشکل حل شده است؟

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

• تعداد درخواست‌های admin-ajax.php: در Network مرورگر بررسی کنید.
• زمان پاسخ درخواست: ببینید همان اکشن نسبت به قبل سریع‌تر شده یا نه.
• مصرف CPU و پردازه‌های PHP: نمودار پنل هاست را در بازه مشابه بررسی کنید.
• خطاهای 503 و 504: ببینید در لاگ یا تجربه کاربران کمتر شده‌اند یا خیر.
• عملکرد واقعی سایت: فرم، جستجو، سبد خرید، ویرایش نوشته و بخش‌های مهم را دستی تست کنید.

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

جمع‌بندی

admin-ajax.php دشمن سرعت وردپرس نیست؛ این فایل فقط مسیر اجرای درخواست‌های Ajax است. مصرف بالای CPU معمولاً زمانی ایجاد می‌شود که درخواست‌ها بیش از حد تکرار شوند، یک اکشن پردازش سنگینی داشته باشد، Heartbeat در پیشخوان زیاد اجرا شود، دیتابیس کند باشد یا ربات‌ها درخواست‌های غیرعادی بفرستند.

بهترین مسیر حل مشکل این است که اول با Network مرورگر مقدار action را پیدا کنید، سپس با Query Monitor یا لاگ سرور علت را دقیق‌تر بررسی کنید. بعد فقط همان بخش را اصلاح کنید؛ نه اینکه چند افزونه بهینه‌سازی نصب کنید یا کل admin-ajax.php را ببندید.

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