کندی پیشخوان وردپرس گاهی حتی از کندی صفحه اصلی آزاردهنده‌تر است. وقتی بازکردن فهرست نوشته‌ها، ذخیره محصول یا ویرایش یک صفحه چندین ثانیه طول می‌کشد، روند مدیریت سایت مختل می‌شود؛ حتی ممکن است بازدیدکنندگان هیچ مشکلی در صفحه عمومی نبینند.
در این مقاله اترنوکلود، علت کندی پیشخوان وردپرس و روش‌های افزایش سرعت wp-admin را در هشت مرحله بررسی می‌کنیم. هدف، پیدا کردن گلوگاه واقعی است؛ نه فعال‌کردن تصادفی چند گزینه کش یا افزایش بی‌هدف منابع.
کندی پیشخوان وردپرس از کجا شروع می‌شود؟
پیشخوان وردپرس برخلاف یک صفحه عمومی که می‌تواند از کش کامل HTML تحویل داده شود، معمولاً برای کاربر واردشده درخواست‌های پویا اجرا می‌کند. پلاگین‌های مدیریتی، درخواست‌های Ajax، کوئری‌های دیتابیس و فراخوانی APIهای خارجی ممکن است هر بار فعال شوند. برای همین، بالا بودن امتیاز PageSpeed صفحه اصلی الزاماً به معنی سریع بودن wp-admin نیست.
وقتی گزارش می‌دهید پیشخوان کند است، محل دقیق کندی را مشخص کنید: ورود، فهرست نوشته‌ها، ویرایشگر المنتور، مدیریت سفارش‌های ووکامرس یا ذخیره تنظیمات؟ هر بخش می‌تواند علت متفاوتی داشته باشد.
مرحله اول: اندازه‌گیری TTFB و درخواست‌های کند در wp-admin
برای تحلیل کندی پیشخوان وردپرس باید زمان پاسخ سرور را از زمان دانلود فایل‌های مرورگر جدا کنید. گزارش Network در ابزار توسعه‌دهنده مرورگر و لاگ کندی PHP در تشخیص گلوگاه کمک می‌کنند.
پنل Network مرورگر را باز کنید، گزینه Preserve log را فعال کنید و صفحه کند را دوباره بارگذاری کنید. درخواست‌های مرتب‌شده بر اساس Duration یا Waterfall را ببینید. درخواست اصلی HTML با زمان پاسخ بالا اغلب به پردازش سرور یا پایگاه داده اشاره می‌کند؛ فایل JavaScript سنگین یا خطای Console نیز می‌تواند رابط کاربری را کند نشان دهد.
برای عیب‌یابی بهتر، یک‌بار در حالت ناشناس با افزونه‌های مرورگر غیرفعال آزمایش کنید. زمان اندازه‌گیری، کاربر آزمایشی و تعداد افزونه‌ها را ثبت کنید تا نتیجه قبل و بعد قابل مقایسه باشد.
چطور یک خط مبنا برای سنجش سرعت پیشخوان بسازیم؟
پیش از هر تغییری یک صفحه ثابت مانند «همه نوشته‌ها» را انتخاب کنید و سه بار با همان حساب کاربری و همان مرورگر باز کنید. زمان بارگذاری درخواست اصلی، مدت اجرای درخواست‌های Ajax و خطاهای Console را یادداشت کنید. بهتر است این آزمایش را یک بار در ساعت خلوت و یک بار هنگام ترافیک بیشتر انجام دهید. اگر فقط یک بار صفحه را اندازه‌گیری کنید، اثر کش مرورگر، ارتباط اینترنت یا عملیات هم‌زمان می‌تواند نتیجه را منحرف کند.
در ابزار توسعه‌دهنده مرورگر، ستون Waiting یا TTFB کمک می‌کند متوجه شوید زمان عمدتاً روی سرور سپری شده یا دانلود فایل‌ها کند است. اگر درخواست HTML سریع تمام می‌شود ولی کار با رابط چند ثانیه طول می‌کشد، سراغ جاوااسکریپت، افزونه‌های مدیریتی و پردازش مرورگر بروید. اگر زمان پاسخ خود HTML بالاست، ابتدا PHP، دیتابیس و فراخوانی‌های خارجی را بررسی کنید.
از این داده‌ها یک جدول ساده با نام صفحه، ساعت، مدت درخواست و آخرین تغییر ایجاد کنید. برای رفع کندی پیشخوان وردپرس، ثبت نتیجه قبل و بعد از هر اصلاح از حدس‌زدن بسیار مفیدتر است. هنگام اشتراک گزارش Network، کوکی‌ها، توکن‌ها و نشانی‌های دارای اطلاعات حساس را حذف کنید.
مرحله دوم: بررسی admin-ajax.php و درخواست‌های Heartbeat
اگر درخواست‌های تکراری به /wp-admin/admin-ajax.php مشاهده می‌کنید، نام Action و افزونه ایجادکننده را شناسایی کنید. WordPress Heartbeat برای بعضی امکانات مانند قفل ویرایش نوشته یا اطلاع‌رسانی‌های زنده کاربرد دارد. هر درخواست admin-ajax.php لزوماً مربوط به Heartbeat نیست.
به‌جای غیرفعال‌کردن سراسری Heartbeat، نرخ اجرا را براساس نیاز ویرایشگر، امنیت و ووکامرس تنظیم کنید. حذف بی‌محابای آن ممکن است هشدار ویرایش هم‌زمان یا قابلیت‌های پنل را مختل کند. اگر درخواست از افزونه‌ای خاص است، ابتدا تنظیمات همان افزونه را بررسی کنید.
تشخیص درخواست طبیعی از Ajax پرتکرار و پرهزینه
در تب Network، نوع Fetch/XHR را انتخاب کنید و بررسی کنید آیا یک درخواست مرتباً با فاصله کوتاه تکرار می‌شود یا فقط هنگام کلیک روی دکمه‌ای خاص اجرا می‌شود. در بخش Payload یا Form Data ممکن است نام action دیده شود. همین نام اغلب سرنخی است برای اینکه بفهمید کدام افزونه درخواست را آغاز کرده است. اگر یک درخواست خطای ۴۰۳ یا ۴۲۹ دارد، ابتدا محدودیت امنیتی، nonce منقضی‌شده یا نرخ درخواست را بررسی کنید؛ هر خطایی نشانه کندبودن سرور نیست.
Heartbeat به هماهنگ‌سازی بعضی قابلیت‌های ویرایشگر کمک می‌کند؛ ولی همه درخواست‌های admin-ajax.php از Heartbeat نیستند. از خاموش‌کردن سراسری این سازوکار صرفاً برای بهترشدن عددهای آزمایش خودداری کنید. در یک محیط آزمایشی می‌توان فاصله اجرای قابلیت‌های غیرضروری را تغییر داد و نتیجه را روی قفل ویرایش، ذخیره نوشته و بخش سفارش‌ها بررسی کرد.
در فروشگاه ووکامرس، درخواست مربوط به وضعیت سفارش یا ابزار مدیریتی ممکن است برای کارکرد صحیح ضروری باشد. برای رفع کندی پیشخوان وردپرس، خود درخواست سنگین یا تکراری را شناسایی و علت آن را اصلاح کنید؛ پنهان‌کردن تمام درخواست‌ها معمولاً درمان مناسبی نیست.
مرحله سوم: شناسایی افزونه‌های سنگین با Query Monitor
ابزار Query Monitor می‌تواند زمان اجرای درخواست، کوئری‌های کند و تکراری، هوک‌ها، درخواست‌های HTTP خارجی و خطاهای PHP را نشان دهد. این ابزار برای تشخیص مفید است، اما در شرایط اشکال‌زدایی خودش نیز سربار محدودی اضافه می‌کند؛ پس بهتر است موقتاً در محیط آزمایشی استفاده شود.
از جدول‌های Query و HTTP API Calls بررسی کنید کدام مؤلفه زمان بیشتری مصرف می‌کند. افزونه‌ای که تعداد کوئری بالا دارد، همیشه عامل اصلی نیست؛ زمان کل و مسیر اجرای همان صفحه اهمیت بیشتری از شمار خام درخواست‌ها دارد.
وقتی چند افزونه هم‌زمان فعال‌اند، مقصر را چطور پیدا کنیم؟
گاهی تصور می‌کنیم آخرین افزونه نصب‌شده باعث کندی شده، اما تنها دلیل، تداخل دو افزونه قدیمی یا کوئری تکراری یک ماژول است. در Query Monitor، درخواست مربوط به همان صفحه کند را باز کنید و مدت کوئری‌ها، نام مؤلفه، خطاهای PHP و درخواست‌های خارجی را یادداشت کنید. یک کوئری طولانی ارزش بررسی بیشتری از ده کوئری سریع دارد؛ بنابراین فقط به تعداد درخواست‌ها نگاه نکنید.
اگر محیط آزمایشی دارید، افزونه‌های غیرحیاتی را به‌صورت گروهی غیرفعال کنید، صفحه را بسنجید و سپس با فعال‌کردن تدریجی، مؤلفه مشکل‌ساز را مشخص کنید. این آزمایش را روی فروشگاه زنده با غیرفعال‌کردن درگاه پرداخت، امنیت یا سامانه سفارش انجام ندهید. در وردپرس می‌توان از عیب‌یابی محدود به نشست مدیر استفاده کرد، اما باید سازگاری ابزار و افزونه‌ها بررسی شود.
پس از شناسایی عامل کندی، به‌روزرسانی سازگار، اصلاح تنظیمات، رفع درخواست غیرضروری یا جایگزینی افزونه را ارزیابی کنید. افزایش PHP memory_limit برای یک کوئری ذاتاً کند، مشکل اصلی را حل نمی‌کند. اسکرین‌شات گزارش را همراه با نسخه افزونه و تاریخ ثبت کنید تا پشتیبانی بتواند آن را دقیق‌تر بررسی کند.
مرحله چهارم: منابع هاست، PHP و OPcache
اگر CPU، حافظه، I/O یا تعداد Entry Processها در ساعات اوج به سقف سرویس نزدیک می‌شود، زمان پاسخ پیشخوان افزایش پیدا می‌کند. در cPanel یا CloudLinux بخش Resource Usage را بررسی کنید؛ نمودارهای خطا و محدودیت را با ساعت کندی تطبیق دهید. گاهی افت سرعت فقط برای یک حساب و گاهی برای چند وب‌سایت مشترک روی سرور دیده می‌شود.
نسخه PHP باید با قالب و افزونه‌ها سازگار باشد. OPcache با نگهداری بایت‌کد PHP از کامپایل تکراری جلوگیری می‌کند؛ Redis Object Cache کاربرد دیگری دارد و نتایج برخی محاسبات و دسترسی‌های دیتابیس را ذخیره می‌کند. افزایش بی‌رویه حافظه OPcache بدون مشاهده مصرف و Hit Rate، الزاماً بهبود ایجاد نمی‌کند.
تفاوت محدودیت منابع با مشکل تنظیمات PHP
در CloudLinux، بخش Resource Usage می‌تواند رسیدن حساب به محدودیت CPU، حافظه فیزیکی، I/O، IOPS یا Entry Processes را نشان دهد. اگر هم‌زمان با کندی پیشخوان، نمودار محدودیت یا Fault ثبت شده باشد، موضوع ارزش بررسی دارد؛ ولی صرف بالابودن درصد مصرف، دلیل قطعی مشکل نیست. باید بدانیم کدام فرآیند منابع را استفاده کرده و آیا سایت هنگام همان رویداد کند بوده است.
روی وب‌سرور LiteSpeed، پردازش PHP ممکن است از LSAPI استفاده کند. در پیکربندی‌های دیگر PHP-FPM با مجموعه پردازش‌های خودش فعال است. تعداد پردازشگرها، صف درخواست‌ها، محدودیت حافظه و ظرفیت واقعی سرویس روی زمان انتظار اثر دارند؛ این تنظیمات بهتر است براساس آمار و با هماهنگی مدیر هاست اصلاح شوند، نه با افزایش بی‌محابای هم‌زمانی.
OPcache نسخه کامپایل‌شده کد PHP را در حافظه نگه می‌دارد و Redis Object Cache داده‌های قابل ذخیره کش را مدیریت می‌کند. این دو ابزار متفاوت‌اند؛ روشن‌بودن یکی مشکل دیگری را جبران نمی‌کند. اگر گلوگاه واقعی کمبود منابع است، ابتدا پردازش سنگین یا افزونه مشکل‌ساز را شناسایی کنید و بعد درباره ارتقای پلن تصمیم بگیرید.
مرحله پنجم: تنظیم WP-Cron و Scheduled Actions
در وردپرس، WP-Cron به‌صورت پیش‌فرض هنگام درخواست صفحات فرصت اجرای وظایف زمان‌بندی‌شده را بررسی می‌کند. اگر کارها روی هم انباشته شده‌اند یا فرآیند سنگینی در ساعت شلوغ اجرا می‌شود، می‌توان پس از بررسی و در صورت پشتیبانی هاست، آن را به اجرای منظم واقعی منتقل کرد. صرف غیرفعال‌کردن WP-Cron بدون جایگزین، خطر تأخیر در ایمیل، بروزرسانی و وظایف فروشگاه را دارد.
اگر ووکامرس فعال است، مسیر ووکامرس ← وضعیت ← Scheduled Actions را بررسی کنید. وظایف Failed و Pending فراوان ممکن است نشانه وابستگی کند، خطای افزونه یا اجرای ناموفق Cron باشند؛ به‌جای حذف کورکورانه صف، علت خطا را از لاگ همان Action پیدا کنید.
تشخیص صف عقب‌افتاده و وظایف تکرارشونده
بعضی افزونه‌ها وظایفی برای همگام‌سازی موجودی، ارسال ایمیل، تولید گزارش یا پاک‌سازی داده تعریف می‌کنند. اگر یک کار هر چند دقیقه با خطا تکرار شود، هم صف بزرگ‌تر می‌شود و هم زمان پردازش بقیه درخواست‌ها افزایش پیدا می‌کند. در WooCommerce بخش Scheduled Actions را براساس وضعیت Failed، Pending و زمان اجرا مرتب کنید. نام Hook و افزونه ایجادکننده را ثبت کنید تا مشخص شود وظیفه مربوط به کدام قابلیت است.
حذف یک‌باره همه وظایف منتظر اجرا می‌تواند باعث از دست‌رفتن اعلان‌ها، همگام‌سازی سفارش یا عملیات مالی شود. ابتدا علت خطا را برطرف کنید، سپس برای اجرای مجدد کارهای مهم برنامه داشته باشید. اگر قرار است WP-Cron داخلی غیرفعال شود، باید Cron واقعی جایگزین به‌درستی تنظیم شود؛ در غیر این صورت وظایف به‌موقع اجرا نمی‌شوند.
اگر کندی پیشخوان وردپرس هر روز تقریباً در ساعت ثابتی رخ می‌دهد، زمان اجرای بکاپ، اسکن امنیتی، واردکردن محصولات و وظایف زمان‌بندی‌شده را با آن تطبیق دهید. جابه‌جایی فرآیندهای سنگین به ساعت کم‌مصرف، پس از بررسی وابستگی‌ها، گاهی اثر چشمگیری دارد.
مرحله ششم: بهینه‌سازی wp_options و Autoload
گاهی کندی پیشخوان وردپرس به‌دلیل انباشته‌شدن گزینه‌های autoload ایجاد می‌شود. حذف رکوردهای ناشناس بدون بررسی مالک آن‌ها می‌تواند افزونه‌ها را مختل کند.
بخشی از تنظیمات افزونه‌ها و وردپرس در جدول گزینه‌ها نگهداری می‌شود. گزینه‌های Autoload در بسیاری از درخواست‌ها بارگذاری می‌شوند و بزرگی مجموع آن‌ها می‌تواند زمان و حافظه را تحت تأثیر قرار دهد. در Site Health، Query Monitor یا ابزار مدیریت دیتابیس، حجم کل و رکوردهای بزرگ را شناسایی کنید.
تغییر مستقیم مقدار autoload یا حذف رکوردهایی که نامشان ناشناخته است خطرناک است؛ برخی گزینه‌ها برای امنیت، پرداخت یا ورود کاربران ضروری‌اند. برای تغییر، ابتدا بکاپ بگیرید و با سازنده افزونه یا محیط آزمایشی هماهنگ کنید.
چرا داده‌های Autoload بزرگ، پنل را کند می‌کنند؟
وردپرس بخشی از گزینه‌های فعال را در ابتدای درخواست می‌خواند. وقتی افزونه‌ای داده حجیم را در گزینه‌ای با بارگذاری خودکار نگه می‌دارد، مصرف حافظه و زمان پردازش هر درخواست بیشتر می‌شود؛ حتی اگر همان صفحه به آن داده نیاز نداشته باشد. در ابزار Site Health یا گزارش تخصصی، حجم مجموع Autoload و نام گزینه‌های بسیار بزرگ را بررسی کنید. تکرار این بررسی پس از حذف یک افزونه نیز مفید است؛ بعضی افزونه‌ها داده‌هایشان را کامل پاک نمی‌کنند.
پیش از دستکاری مستقیم جدول wp_options مشخص کنید مالک هر گزینه کدام افزونه یا ماژول است. داده‌ها ممکن است Serialize شده باشند و تغییر دستی یک کاراکتر، ساختار آن‌ها را خراب کند. در صورت نیاز، تغییر باید با روش پشتیبانی‌شده افزونه، کد کنترل‌شده یا کمک توسعه‌دهنده و همراه بکاپ انجام شود. حذف انبوه رکوردهای نامعلوم برای کسب چند میلی‌ثانیه سرعت، ریسک منطقی ندارد.
در سایت‌های ووکامرسی، حجم گزینه‌های موقت و داده‌های پس‌زمینه را از داده‌های سفارش جدا کنید. افزایش سرعت واقعی زمانی ارزشمند است که صحت سفارش‌ها، تنظیمات پرداخت و حساب کاربران حفظ شود.
مرحله هفتم: شناسایی درخواست‌های خارجی و مشکلات DNS
برای بررسی کندی پیشخوان وردپرس، زمان فراخوانی APIهای خارجی، بروزرسانی افزونه‌ها و خطاهای DNS را هم بررسی کنید، به‌ویژه زمانی که سایت عمومی سریع است.
پیشخوان ممکن است برای بررسی لایسنس افزونه، دانلود بروزرسانی، فراخوانی API، بررسی امنیت یا بارگذاری منابع خارجی HTTP Request اجرا کند. کندی DNS، محدودیت اتصال اینترنتی یا Timeout مقصد می‌تواند پنل را متوقف کند. نام دامنه مقصد و مدت انتظار را در Query Monitor یا لاگ HTTP ثبت کنید.
قبل از غیرفعال‌کردن درخواست‌ها، ببینید آیا به امنیت، بروزرسانی یا عملکرد اصلی سایت وابسته‌اند. مسدودکردن همه ارتباطات خارجی یا دستکاری فایل میزبان بدون شناخت وابستگی‌ها می‌تواند مشکلات جدیدی بسازد.
وقتی یک سرویس خارجی پیشخوان را معطل می‌کند
بعضی افزونه‌های امنیتی، سئو، صفحه‌ساز و لایسنس هنگام ورود مدیر به پیشخوان با سرویس خارجی تماس می‌گیرند. اگر DNS مقصد پاسخ ندهد یا ارتباط HTTPS با Timeout مواجه شود، ممکن است ذخیره یک تنظیم ساده هم کند شود. از لاگ HTTP یا ابزار عیب‌یابی، نام مقصد، زمان اتصال، وضعیت پاسخ و تعداد تکرار درخواست را استخراج کنید. وجود نام یک سرویس در گزارش به معنای معیوب‌بودن آن نیست؛ باید زمان انتظار را هم دید.
در شبکه‌هایی با دسترسی بین‌المللی ناپایدار، این مسئله بیشتر به چشم می‌آید. تفاوت زمان پاسخ از داخل سرور و مرورگر کاربر را بررسی کنید و هرگز برای حل کندی، بررسی گواهی TLS یا به‌روزرسانی امنیتی را به‌طور کلی خاموش نکنید. اگر یک افزونه امکان زمان‌بندی یا کش نتیجه درخواست خارجی دارد، گزینه پشتیبانی‌شده آن را بررسی کنید.
برای رفع کندی پیشخوان وردپرس ناشی از درخواست خارجی، گاهی اصلاح DNS سرور، وضعیت فایروال خروجی یا Timeout درست، از تغییر تم یا افزونه کش مؤثرتر است. مشکل باید با لاگ و آزمایش کنترل‌شده ثابت شود.
مرحله هشتم: نقش قالب و صفحه‌ساز در کندی پنل
در ویرایشگر المنتور یا قالب‌های دارای پنل تنظیمات پیچیده، تعداد کنترل‌ها و دارایی‌های بارگذاری‌شده می‌تواند زیاد باشد. این کندی همیشه از سرعت هاست نیست. تغییر موقت به قالب پیش‌فرض در محیط Staging، خاموش‌کردن افزونه‌های غیرضروری و مقایسه زمان بازکردن یک صفحه مشابه در تشخیص مشکل کمک می‌کند.
اگر از وودمارت استفاده می‌کنید، مقاله افزایش سرعت قالب وودمارت مکمل این راهنماست. تغییرات قالب و تنظیمات کش را یکی‌یکی انجام دهید و نتیجه را ثبت کنید.
المنتور، وودمارت و صفحه‌های مدیریتی سنگین
گاهی فهرست نوشته‌ها سریع باز می‌شود، اما ویرایشگر المنتور یا پنل تنظیمات قالب وودمارت کند است. در این حالت احتمالاً مشکل به فایل‌های مدیریتی، داده صفحه، ویجت‌های متعدد یا افزونه‌های وابسته مربوط می‌شود و نباید آن را به تمام پیشخوان تعمیم داد. برای مقایسه یک برگه ساده و یک برگه دارای تعداد زیادی المان را با حساب یکسان باز کنید. گزارش مرورگر و Query Monitor نشان می‌دهند زمان بیشتر کجا سپری شده است.
به‌روزرسانی صفحه‌ساز و افزونه‌های مکمل باید با نسخه PHP و قالب سازگار باشد. اگر بعد از یک به‌روزرسانی عملکرد تغییر کرده است، ابتدا لاگ خطا، تغییرات نسخه و تعارض‌های احتمالی را بررسی کنید. برگرداندن نسخه قدیمی بدون ارزیابی آسیب‌پذیری‌ها انتخاب مناسبی نیست؛ برای تغییرات اساسی از Staging و بکاپ استفاده کنید.
در فروشگاه ووکامرسی، صفحه مدیریت سفارش‌ها و ویرایش محصولات ممکن است افزونه‌های مخصوص قیمت‌گذاری، حمل‌ونقل و موجودی را فراخوانی کند. برای چنین صفحاتی، راهکار رفع کندی پیشخوان وردپرس ممکن است به تنظیمات همان افزونه‌ها و عملکرد دیتابیس مربوط باشد.
راهکارهای فوری و کم‌خطر برای کندی پیشخوان وردپرس
| نشانه | بررسی اول | اقدام پیشنهادی |
|---|---|---|
| همه صفحات پنل کند هستند | Resource Usage و PHP Error Log | شناسایی سقف منابع یا خطای سراسری |
| فقط سفارش‌ها کندند | Scheduled Actions و وضعیت HPOS | بررسی افزونه‌های سفارش و سازگاری |
| فقط ویرایشگر کند است | Network و افزونه‌های صفحه‌ساز | عیب‌یابی افزونه و اسکریپت |
| admin-ajax طولانی است | Action و هوک مرتبط | رفع درخواست پرتکرار یا کند |
| کندی دوره‌ای است | Cron، بکاپ و HTTP خارجی | زمان‌بندی و لاگ‌گیری هدفمند |
یک مثال عملی از عیب‌یابی بدون تغییر کورکورانه
فرض کنید فهرست سفارش‌ها حدود هشت ثانیه زمان می‌برد، اما بخش نوشته‌ها در دو ثانیه باز می‌شود. ابتدا در همان ساعت گزارش شبکه مرورگر را ثبت کنید. اگر درخواست اصلی صفحه سفارش زمان بیشتری دارد، کوئری‌های همان صفحه و Hookهای مربوط به سفارش را بررسی کنید. اگر زمان اصلی کوتاه است اما یک درخواست Ajax طولانی باقی می‌ماند، نام Action را استخراج کنید. سپس یک تغییر محدود روی محیط آزمایشی انجام دهید و آزمون را تکرار کنید.
اعداد این مثال صرفاً برای توضیح روش هستند و نتیجه اندازه‌گیری اترنوکلود یا سایت خاصی محسوب نمی‌شوند. نکته اصلی این است که مسیر عیب‌یابی براساس نشانه انتخاب شود. بدون این کار، ممکن است چند افزونه بهینه‌سازی اضافه کنیم و به‌جای کاهش زمان پاسخ، باعث تداخل کش یا JavaScript شویم.
برنامه بازگشت پس از هر اصلاح
برای هر تغییر، وضعیت اولیه را نگه دارید: فایل تنظیمات، نسخه افزونه، مقدار قبل و نتیجه سنجش. فقط یک پارامتر را در هر مرحله تغییر دهید. بعد از اصلاح، علاوه بر سرعت صفحه، ذخیره نوشته، ورود مدیر، بارگذاری رسانه و در فروشگاه‌ها عملیات سفارش را نیز بررسی کنید. اگر عملکرد حیاتی مختل شد، همان تغییر را برگردانید و لاگ خطای جدید را نگه دارید.
آیا Redis Object Cache باعث سریع‌شدن پیشخوان می‌شود؟
کش شیء پایدار در برخی سایت‌ها می‌تواند تعداد درخواست‌های پایگاه داده را کم کند؛ به‌ویژه وقتی افزونه‌ها بارها داده مشابه می‌خوانند. اما اگر علت اصلی، CPU اشباع، خطای PHP یا API خارجی باشد، Redis به‌تنهایی درمان نیست. در مقاله آموزش Redis Object Cache در وردپرس شرایط و راه‌اندازی آن را توضیح داده‌ایم.
برای توضیح عمومی‌تر، مقاله دلایل کندی وردپرس را نیز ببینید.
چه زمانی کش شیء واقعاً کمک می‌کند؟
اگر یک صفحه مدیریتی بارها تنظیمات یا اطلاعات مشابهی را از دیتابیس می‌خواند، کش شیء پایدار ممکن است تعداد خواندن‌های تکراری را کاهش دهد. ولی کش نامناسب می‌تواند داده قدیمی نمایش دهد یا حافظه اضافی مصرف کند. پیش از فعال‌سازی، بررسی کنید سرویس Redis واقعاً در هاست فراهم است، فقط یک افزونه مدیریت object-cache.php را بر عهده دارد و راه بازگرداندن تنظیمات مشخص است.
برای سنجش نتیجه، زمان بازشدن یک صفحه ثابت و تعداد کوئری‌های مهم را قبل و بعد مقایسه کنید؛ در کنار آن سلامت سبد خرید، موجودی و تغییرات تنظیمات را بررسی کنید. اگر عامل اصلی کندی یک سرویس خارجی یا پردازش JavaScript است، فعال‌کردن Redis غالباً تأثیر مورد انتظار را ندارد. مقاله دلایل کندی وردپرس نیز برای بررسی کلی مکمل است.
پرسش‌های متداول کندی پیشخوان وردپرس
چرا سایت سریع است ولی wp-admin کند است؟
ممکن است صفحه عمومی از کش تحویل داده شود، اما پیشخوان هر بار PHP و کوئری و درخواست‌های پویا را اجرا کند.
آیا غیرفعال‌کردن Heartbeat همیشه خوب است؟
خیر. به قابلیت‌های ویرایش و همکاری وابسته است؛ ابتدا درخواست‌های مشکل‌ساز را شناسایی کنید.
آیا افزایش PHP memory_limit سرعت را زیاد می‌کند؟
فقط وقتی واقعاً محدودیت حافظه گلوگاه باشد؛ افزایش یک عدد به‌تنهایی الزاماً سرعت را بالا نمی‌برد.
جمع‌بندی: چگونه کندی پیشخوان وردپرس را رفع کنیم؟
برای رفع کندی پیشخوان وردپرس از اندازه‌گیری شروع کنید و به‌ترتیب Ajax، افزونه‌ها، گزارش‌ها، منابع هاست، Cron، دیتابیس و درخواست‌های خارجی را بررسی کنید. هر تغییر را جداگانه اجرا و اثر آن را در همان صفحه ثبت کنید.
منابع فنی: راهنمای بهینه‌سازی وردپرس، بهینه‌سازی PHP و WP-Cron، Scheduled Actions ووکامرس.
نظرات و دیدگاه کاربران (0 نظر)
هنوز نظری ثبت نشده است. اولین نفری باشید که نظر می‌دهد!
دیدگاه خود را بنویسید