افزایش سرعت admin-ajax.php در وردپرس؛ ۷ روش کاربردی

اگه سایت وردپرسی دارید، حتماً یه بار پیش اومده که سرعت سایتتون رو تست کردید و وسط گزارش، یه ردیف قرمز دیدید به اسم admin-ajax.php که چند ثانیه وقت گرفته. اون لحظه معمولاً دو تا حس دارید: یکی اینکه «خب پس مقصر پیدا شد!» و یکی اینکه «حالا این دقیقاً چیه و من باهاش چیکار کنم؟»

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

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

فایل admin-ajax.php چیست؟

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

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

آشنایی با Heartbeat API

از نسخه ۳.۶ وردپرس، قابلیتی اضافه شد به اسم Heartbeat API. اسمش هم بی‌دلیل نیست؛ دقیقاً مثل ضربان قلب، هر چند ثانیه یه بار بین مرورگر کاربر و سرور یه پیام رد و بدل می‌شه تا هر دو طرف بدونن اوضاع چطوره.

این ارتباط از طریق همون admin-ajax.php انجام می‌شه. یعنی Heartbeat یکی از اصلی‌ترین مشتری‌های این فایله.

ذخیره خودکار نوشته‌ها

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

قفل ویرایش و اعلان ورود کاربران دیگر

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

تفاوت admin-ajax با REST API و wc-ajax

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

نکته مهم اینه که خیلی از افزونه‌های قدیمی هنوز روی admin-ajax موندن، در حالی که نسخه‌های جدیدترشون گزینه سوییچ به REST دارن. تو تنظیمات افزونه‌هاتون بگردید، شاید غافلگیر بشید.

چرا admin-ajax.php سرعت سایت را کاهش می‌دهد؟

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

مصرف بالای CPU و منابع سرور

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

تأثیر تأخیر لود بر تجربه کاربر

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

وقتی مقصر اصلاً کاربر نیست؛ ربات‌ها

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

علامتش اینه: تو گزارش GTmetrix چیز خاصی نمی‌بینید، اما مصرف CPU هاستتون بالاست و وقتی access log رو باز می‌کنید، صدها ردیف POST به admin-ajax.php از IPهای عجیب و غریب می‌بینید. پایین‌تر می‌گیم چطور اینو چک کنید و چیکارش کنید.

سه منبع اصلی مشکل

جمع‌بندی کنیم. کندی admin-ajax.php تقریباً همیشه از یکی از این سه تاست:

۱. افزونه‌های شخص ثالث که برای کارای مختلف (فیلتر محصولات، سبد خرید، آمار بازدید، چت آنلاین) مدام درخواست AJAX می‌فرستن.

۲. خود Heartbeat API توی بخش مدیریت، مخصوصاً وقتی چند نفر همزمان تو پیشخوان کار می‌کنن.

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

خبر خوب اینه که هر سه‌تاش قابل کنترله. بریم سراغ اینکه اول مقصر رو پیدا کنیم.

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

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

روش اول: تست سرعت با GTmetrix

می‌رید تو سایت GTmetrix، آدرس سایتتون رو وارد می‌کنید و روی دکمه تست کلیک می‌کنید. چند ثانیه صبر کنید تا آنالیز تموم بشه.

نمره کلی که بالا نشونتون می‌ده جالبه ولی چیزی که ما دنبالشیم پایین‌تره.

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

تحلیل چهار فیلد Headers، Parameters، Post و Response: روی همون ردیف کلیک کنید. چهار تا تب براتون باز می‌شه.

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

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

روش دوم: کنسول توسعه‌دهنده کروم

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

روی صفحه سایتتون راست‌کلیک کنید و Inspect رو بزنید. برید تو تب Network. توی فیلد فیلتر، عبارت admin-ajax رو بنویسید و بعد Ctrl + R بزنید تا صفحه دوباره لود بشه.

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

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

روش سوم: افزونه Query Monitor (دقیق‌ترین راه)

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

افزونه Query Monitor رو نصب و فعال کنید. بعد که یه درخواست AJAX تو سایت اتفاق افتاد، تو نوار بالای پیشخوان یه آیتم جدید ظاهر می‌شه. اونجا می‌تونید ببینید:

• هر درخواست چند تا کوئری به دیتابیس زده و کدومشون کند بودن
• کدوم هوک و کدوم فایل افزونه مسئول اجرا بوده
• چقدر حافظه مصرف شده

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

روش چهارم: نگاه به access log سرور

اگه شک دارید ترافیک ربات دارید، این تنها راه مطمئنه. تو cPanel یا دایرکت‌ادمین بخش Raw Access Logs رو دانلود کنید، یا اگه دسترسی SSH دارید این دستور رو بزنید:

bash

grep "admin-ajax.php" access.log | wc -l

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

bash

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

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

چک‌لیست تشخیص

اگر افزونه مقصر ضروری بود چه کنیم؟

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

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

تنظیماتش رو بگردید. بعضی افزونه‌ها گزینه‌ای دارن برای خاموش کردن بخش‌های AJAX (مثلاً ووکامرس گزینه AJAX add to cart داره).

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

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

روش‌های افزایش سرعت admin-ajax.php

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

کنترل Heartbeat API

اگه مشکلتون از پیشخوانه، این ساده‌ترین و مؤثرترین راهه.

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

روش بدون کد (افزونه Heartbeat Control):

افزونه Heartbeat Control رو از مخزن وردپرس نصب و فعال کنید، بعد برید به پیشخوان » تنظیمات » Heartbeat Control.

• توی بخش Heartbeat Behavior گزینه Modify Heartbeat رو انتخاب کنید. (گزینه Disable رو پیشنهاد نمی‌کنیم، چون ذخیره خودکار رو هم می‌کشه.)
• توی Locations مشخص کنید این قانون کجا اعمال بشه؛ معمولاً پیشخوان و ویرایشگر نوشته.
• توی Frequency بازه زمانی رو بذارید روی عدد بالاتر. پیش‌فرض ۱۵ ثانیه‌ست، بردنش روی ۶۰ ثانیه معمولاً تعادل خوبیه.
• آخرش هم ذخیره تغییرات رو بزنید.

روش با کد (بدون نصب افزونه):

اگه ترجیح می‌دید افزونه اضافه نصب نکنید، این کد رو تو فایل functions.php قالب فرزند یا یه افزونه اسنیپت بذارید:

php

// تغییر بازه زمانی Heartbeat به ۶۰ ثانیهadd_filter( 'heartbeat_settings', 'change_heartbeat_interval' );function change_heartbeat_interval( $settings ) {    $settings['interval'] = 60; // بین ۱۵ تا ۱۲۰ ثانیه قابل تنظیمه    return $settings;}

و اگه می‌خواید Heartbeat رو فقط توی صفحات سمت کاربر (فرانت) خاموش کنید و پیشخوان دست‌نخورده بمونه:

php

// غیرفعال کردن Heartbeat فقط در بخش کاربری سایتadd_action( 'init', 'disable_heartbeat_on_frontend', 1 );function disable_heartbeat_on_frontend() {    global $pagenow;    if ( ! is_admin() && $pagenow !== 'post.php' && $pagenow !== 'post-new.php' ) {        wp_deregister_script( 'heartbeat' );    }}

این دومی رو خیلی توصیه می‌کنیم. تو ۹۰ درصد سایت‌ها هیچ دلیلی نداره Heartbeat تو صفحه محصول یا مقاله اجرا بشه.

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

یه هشدار دوستانه: اگه فرکانس ویرایشگر رو خیلی زیاد کنید (مثلاً ۳۰۰ ثانیه)، ذخیره خودکار عملاً بی‌فایده می‌شه و اولین باری که مرورگرتون کرش کنه، حسابی حرص می‌خورید. ۶۰ ثانیه نقطه امنیه.

Cart Fragments ووکامرس (مخصوص فروشگاه‌ها)

اگه فروشگاه ووکامرسی دارید و admin-ajax کندتون کرده، با احتمال بالا مقصر اینه. اینقدر شایعه که لایق یه بخش جداست.

ووکامرس یه اسکریپت داره به اسم wc-cart-fragments که کارش اینه: بدون رفرش صفحه، تعداد آیتم‌های سبد خرید و مبلغ کل رو آپدیت نگه داره. برای همین آیکون سبد خرید گوشه هدر که عدد روش زنده تغییر می‌کنه.

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

راه‌حل اینه که فقط تو صفحات فروشگاهی نگهش دارید:

php

// غیرفعال کردن Cart Fragments در صفحات غیرفروشگاهیadd_action( 'wp_enqueue_scripts', 'disable_cart_fragments_outside_shop', 11 );function disable_cart_fragments_outside_shop() {    if ( function_exists( 'is_woocommerce' ) ) {        if ( ! is_woocommerce() && ! is_cart() && ! is_checkout() ) {            wp_dequeue_script( 'wc-cart-fragments' );        }    }}

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

کش کردن درخواست‌های AJAX در سمت کاربر

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

با Cloudflare (از طریق Page Rules یا Cache Rules) یا افزونه‌های کش پیشرفته می‌تونید این پاسخ‌ها رو تو لایه Edge نگه دارید. نتیجه‌اش اینه که درخواست اصلاً به PHP و دیتابیس نمی‌رسه و از حافظه موقت جواب داده می‌شه.

فقط خیلی حواستون باشه: هیچ‌وقت درخواست‌های مربوط به سبد خرید، حساب کاربری یا فرم‌های ورود رو کش نکنید. نتیجه‌اش می‌شه اینکه کاربر A سبد خرید کاربر B رو ببینه. بعد از هر تنظیم کش، حتماً یه بار با حالت ناشناس تست کنید.

جایگزینی AJAX با REST API

همون‌طور که اول گفتیم، بزرگ‌ترین ایراد admin-ajax.php اینه که هر بار کل وردپرس رو از صفر بالا میاره. REST API ساختار سبک‌تری داره و برای همین معمولاً محسوس‌تر سریع‌تره.

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

اگه خودتون کد می‌زنید، مهاجرت ساده‌تر از چیزیه که فکر می‌کنید:

php

// ثبت یک اندپوینت REST به جای اکشن admin-ajaxadd_action( 'rest_api_init', function () {    register_rest_route( 'mysite/v1', '/latest-posts/', array(        'methods'             => 'GET',        'callback'            => 'mysite_get_latest_posts',        'permission_callback' => '__return_true', // برای داده عمومی    ) );});function mysite_get_latest_posts( $request ) {    $posts = get_posts( array( 'numberposts' => 5 ) );    return rest_ensure_response( $posts );}

بعدش تو جاوااسکریپت به جای admin-ajax.php آدرس /wp-json/mysite/v1/latest-posts/ رو صدا می‌زنید. همین.

یه نکته امنیتی: permission_callback رو الکی روی __return_true نذارید. این فقط برای داده‌های کاملاً عمومیه. برای هر چیزی که به کاربر مربوط می‌شه، حتماً بررسی دسترسی بذارید.

بهینه‌سازی دیتابیس و پاکسازی جدول wp_options

اینو کمتر کسی چک می‌کنه ولی خیلی وقتا ریشه ماجراست. گاهی admin-ajax.php کند نیست، بلکه داره منتظر دیتابیس می‌مونه.

مشکل معمولاً از جدول wp_options هست، مخصوصاً ردیف‌هایی که autoload اون‌ها روی yes هست. این ردیف‌ها تو هر درخواست وردپرس از دیتابیس خونده می‌شن. اگه حجمشون زیاد باشه، هر فراخوانی admin-ajax هم همون بار رو می‌کشه.

برای اینکه ببینید وضعیتتون چطوره، تو phpMyAdmin این کوئری رو بزنید:

sql

SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options WHERE autoload = 'yes';

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

برای اینکه ببینید کدوم ردیف‌ها سنگین‌ترن:

sql

SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) AS size_kbFROM wp_options WHERE autoload = 'yes'ORDER BY LENGTH(option_value) DESC LIMIT 20;

معمولاً چند تا اسم آشنا اینجا می‌بینید؛ افزونه‌هایی که یه بار نصب کردید و پاک کردید ولی داده‌شون مونده، یا افزونه‌هایی که لاگ‌هاشون رو تو options می‌ریزن.

راه‌حل: با یه افزونه بهینه‌ساز دیتابیس، Transientهای منقضی و ریویژن‌های اضافی نوشته‌ها رو پاک کنید. برای ردیف‌های autoload سنگین که مربوط به افزونه‌های حذف‌شده‌ست، بعد از اطمینان می‌تونید دستی پاکشون کنید.

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

فعال‌سازی Object Caching با Redis یا Memcached

اگه فروشگاه اینترنتی دارید یا سایتتون ترافیک بالایی داره، این تقریباً واجبه.

با Object Cache، نتیجه کوئری‌های تکراری دیتابیس تو رم سرور ذخیره می‌شه. یعنی دفعه بعد که همون درخواست AJAX اومد، وردپرس به جای رفتن سراغ هارد و دیتابیس، جواب رو مستقیم از رم برمی‌داره. تفاوتش تو پیشخوان و سرعت پاسخ‌دهی کاملاً محسوسه.

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

محدودسازی و امنیت admin-ajax

برگردیم به بحث ربات‌ها. اگه از لاگ سرور فهمیدید ترافیک غیرعادی دارید، این کارا رو بکنید:

Rate Limiting با کلودفلر: تو پنل کلودفلر یه Rate Limiting Rule بسازید که مسیر /wp-admin/admin-ajax.php رو هدف بگیره. مثلاً بیشتر از ۲۰ درخواست در دقیقه از یه IP، بلاک بشه. این عدد رو بسته به سایتتون تنظیم کنید؛ سایت‌هایی که فیلتر محصول زنده دارن به سقف بالاتری نیاز دارن.

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

غیرفعال کردن دسترسی مهمان (با احتیاط): وردپرس دو نوع هوک AJAX داره: wp_ajax_ برای کاربران لاگین‌شده و wp_ajax_nopriv_ برای مهمان‌ها. اگه سایتتون هیچ قابلیت AJAX سمت کاربر نداره، می‌تونید مسیر رو برای کاربران غیرلاگین محدود کنید. ولی اول کاملاً مطمئن بشید که هیچ فرم تماس، جستجوی زنده یا فیلتری روی سایت به این وابسته نیست، وگرنه بخش‌هایی از سایت از کار می‌افته.

کدام روش برای سایت شما مناسب‌تر است؟

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

بعد از تغییرات، چطور بفهمیم نتیجه داده؟

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

۱. زمان ردیف admin-ajax در Waterfall: مستقیم‌ترین معیار. باید افت محسوسی داشته باشه.

۲. تعداد درخواست‌های admin-ajax در یک بار لود صفحه: تو تب Network کروم قابل شمارشه. اگه قبلاً ۴ تا بوده و حالا ۱ تا، موفق بودید.

۳. TTFB (زمان تا اولین بایت): تو گزارش GTmetrix هست. این نشون می‌ده سرورتون کلاً چقدر سریع‌تر شده.

۴. مصرف CPU در پنل هاست: این یکی رو باید ۲۴ ساعت بعد چک کنید، نه بلافاصله. نمودار مصرف باید نرم‌تر و پایین‌تر باشه.

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

سوالات متداول

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

غیرفعال کردن کامل Heartbeat API خطرناک است؟ خطرناک نه، ولی توصیه نمی‌شه. با غیرفعال کردنش ذخیره خودکار و قفل ویرایش رو از دست می‌دید. تنظیم فرکانس روی عدد بالاتر، یا غیرفعال کردنش فقط در بخش کاربری سایت، انتخاب عاقلانه‌تریه.

چرا admin-ajax.php در گزارش GTmetrix زمان بالایی نشان می‌دهد؟ معمولاً چون یه یا چند افزونه دارن پشت‌سرهم درخواست می‌فرستن، یا چون دیتابیستون کنده و پاسخ دیر آماده می‌شه. با روش Waterfall که بالاتر گفتیم می‌تونید منبعش رو پیدا کنید.

تفاوت admin-ajax.php با wp-cron.php چیست؟ این دو رو خیلی‌ها قاطی می‌کنن. admin-ajax.php درخواست‌های لحظه‌ای مرورگر رو مدیریت می‌کنه (وقتی کاربری روی صفحه‌ست). wp-cron.php کارهای زمان‌بندی‌شده رو اجرا می‌کنه، مثل انتشار نوشته زمان‌دار یا ارسال ایمیل خبرنامه. هر دو می‌تونن باعث کندی بشن ولی راه‌حلشون کاملاً فرق داره.

چرا حتی با غیرفعال بودن همه افزونه‌ها هنوز admin-ajax صدا زده می‌شه؟ چون خود هسته وردپرس (Heartbeat) و بعضی قالب‌ها هم ازش استفاده می‌کنن. اگه همه افزونه‌ها خاموشن و هنوز درخواست می‌بینید، اول Heartbeat رو چک کنید، بعد قالبتون رو موقتاً به یه قالب پیش‌فرض تغییر بدید.

آیا افزونه کش به‌تنهایی این مشکل رو حل می‌کنه؟ نه لزوماً. افزونه‌های کش معمولاً صفحات HTML رو کش می‌کنن، در حالی که درخواست‌های AJAX به‌طور پیش‌فرض از کش رد می‌شن. برای این کار به تنظیمات اختصاصی کش AJAX یا کش لایه Edge نیاز دارید.

آیا این تغییرات روی سئو تأثیر دارن؟ غیرمستقیم، بله. سرعت لود و Core Web Vitals از فاکتورهای رتبه‌بندی گوگلن. کاهش بار admin-ajax، مخصوصاً حذف Cart Fragments از صفحات بلاگ، می‌تونه امتیاز صفحات محتوایی‌تون رو بهتر کنه.

جمع‌بندی

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

اگه بخوایم کل مقاله رو تو پنج خط خلاصه کنیم:

1. با GTmetrix یا کنسول کروم بفهمید کی داره صداش می‌زنه، و حتماً هر دو حالت لاگین و ناشناس رو تست کنید.
2. اگه مشکل از پیشخوانه، Heartbeat رو کنترل کنید (نه غیرفعال).
3. اگه فروشگاه دارید، اول از همه سراغ Cart Fragments برید.
4. دیتابیس و جدول wp_options رو یه بار تمیز کنید.
5. اگه سایت سنگینی دارید، Object Cache رو جدی بگیرید.

قبل از هر تغییری بکاپ بگیرید و بعدش دوباره تست بگیرید تا مطمئن شید واقعاً چیزی بهتر شده.

موفق باشید 🙂

تیم تولید محتوا

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